Re: "Ask HN: What do you want to see in Ubuntu 17.10?"

[Steve Langasek]

On Sat, Jun 10, 2017 at 10:50:58AM +0200, Philipp Kern wrote:
> [*] Ubuntu doesn't bump the ABI on *every* new version, just the ones
> changing the ABI. In reality this is still very frequently and hence you
> achieve a rollback mechanism through it.

Actually, on account of things like the signing of kernel modules with
ephemeral keys, it's now guaranteed by the Ubuntu kernel team that each
kernel published to the Ubuntu archive will have its ABI bumped.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Re: Too many Recommends (in particular on mail-transport-agent)

[Russ Allbery]

Adam Borowski  writes:
> On Sun, Jun 11, 2017 at 03:43:45PM -0400, Jeremy Bicha wrote:
>> On Sun, Jun 11, 2017 at 3:30 PM, Adam Borowski  wrote:

>>> No, when taken alone, -dev packages Recommending -doc is just right.

>> https://anonscm.debian.org/cgit/dbnpolicy/policy.git/commit/?id=dc3b001

> This change talks about only "extra" documentation that's redundant with
> what's already shipped in -dev -- ie, cases where you have man pages and
> plain text in -dev then HTML and PDF in -doc.

> The case of _primary_ documentation being in -doc is still supposed to
> be Recommends, which I agree with (save for the transitional dependency
> issue).

The change was trying to canonicalize two best practices in Policy: extra
documentation being at most Suggests, as you say, but also that even
primary documentation should not be a *Depends*, but at most a Recommends.
I think that's uncontroversial, and it sounds like people are still
comfortable with primary documentation being a Recommends (well, with the
exception of texlive, which came up in this thread -- that's a hard case
since it's documentation that would fit the definition of Recommends
normally, but it's quite large, and texlive gets pulled in a lot by build
dependencies).

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

Bug#864634: ITP: php-klogger -- simple logging class

[James Valleroy]

Package: wnpp
Severity: wishlist
Owner: James Valleroy 

* Package name: php-klogger
  Version : 1.2.1
  Upstream Author : Kenny Katzgrau 
* URL : https://github.com/katzgrau/KLogger
* License : Expat
  Programming Lang: PHP
  Description : simple logging class

KLogger is a PSR-3 compliant logging class for PHP. It is designed to
be quickly included into a project and work right away.

This is a dependency for php-netscape-bookmark-parser, which is a
dependency for shaarli. I plan to maintain it within the
freedombox-pkg-team.

Re: Too many Recommends (in particular on mail-transport-agent)

[Adam Borowski]

On Sun, Jun 11, 2017 at 03:43:45PM -0400, Jeremy Bicha wrote:
> On Sun, Jun 11, 2017 at 3:30 PM, Adam Borowski  wrote:
> > No, when taken alone, -dev packages Recommending -doc is just right.
> 
> https://anonscm.debian.org/cgit/dbnpolicy/policy.git/commit/?id=dc3b001

This change talks about only "extra" documentation that's redundant with
what's already shipped in -dev -- ie, cases where you have man pages and
plain text in -dev then HTML and PDF in -doc.

The case of _primary_ documentation being in -doc is still supposed to be
Recommends, which I agree with (save for the transitional dependency issue).


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ A tit a day keeps the vet away.
⣾⠁⢰⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ (Rejoice as my small-animal-murder-machine got unbroken after
⠈⠳⣄ nearly two years of no catch!)

Re: Too many Recommends (in particular on mail-transport-agent)

[Jeremy Bicha]

On Sun, Jun 11, 2017 at 3:30 PM, Adam Borowski  wrote:
> No, when taken alone, -dev packages Recommending -doc is just right.

https://anonscm.debian.org/cgit/dbnpolicy/policy.git/commit/?id=dc3b001

Thanks,
Jeremy Bicha

Re: Too many Recommends (in particular on mail-transport-agent)

[Adam Borowski]

On Sun, Jun 11, 2017 at 11:16:23AM -0700, Russ Allbery wrote:
> Ivan Shmakov  writes:
> > That’s Abstract Syntax Notation One (or ASN.1), and while I use
> > it all the time (notation, that is; not this specific library at
> > the moment), I see no reason for a -dev package to depend on a
> > -doc one any stronger than with a mere Suggests:.
> 
> We have some specific Policy about this:
> 
> https://www.debian.org/doc/debian-policy/ch-docs.html#s-docs-additional
> 
> If package is a build tool, development tool, command-line tool, or
> library development package.  [...] package should declare at most a
> Recommends on package-doc.
> 
> If you feel that this should cap the dependency at Suggests across the
> board, feel free to submit a bug against debian-policy.  It seems at least
> worth a discussion.  Note that this does tend to make upstreams pretty
> unhappy, though, since they get questions from confused Debian users who
> don't know how to find the documentation that they're "supposed" to have.

No, when taken alone, -dev packages Recommending -doc is just right.  There
are very limited cases when you're writing code for a library's API but
don't have an use for its primary documentation.  A person who downloads
the source to mess with the code you've written is also well served by
having the docs available.  On the other hand, the buildds have no use for
documentation (no human in the chroot), and here our policies again work
fine.

The problem is only, once again, with transitive dependencies.  I don't use
libtasn1-dev directly, it's merely required by one of libraries I'm using.

This one isn't a good example (399KB is negligible), but we have some
dependency chains from hell elsewhere.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ A tit a day keeps the vet away.
⣾⠁⢰⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ (Rejoice as my small-animal-murder-machine got unbroken after
⠈⠳⣄ nearly two years of no catch!)

Re: Too many Recommends (in particular on mail-transport-agent)

[Jeremy Bicha]

On Sun, Jun 11, 2017 at 2:16 PM, Russ Allbery  wrote:
> We have some specific Policy about this:
>
> https://www.debian.org/doc/debian-policy/ch-docs.html#s-docs-additional
>
> If package is a build tool, development tool, command-line tool, or
> library development package, package (or package-dev in the case of a
> library development package) already provides documentation in man,
> info, or plain text format, and package-doc provides HTML or other
> formats, package should declare at most a Suggests on
> package-doc. Otherwise, package should declare at most a Recommends on
> package-doc.

By the way, that paragraph is new in Policy 4.0.0.

Thanks,
Jeremy Bicha

Bug#864621: ITP: racket-mode -- emacs support for editing and running racket code

[David Bremner]

Package: wnpp
Severity: wishlist
Owner: David Bremner 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: racket-mode
  Version : 20161103+0+gab6255718
  Upstream Author : Greg Hendershott 
* URL : https://github.com/greghendershott/racket-mode
* License : GPL2+
  Programming Lang: racket, emacs-lisp
  Description : emacs support for editing and running racket code

Provides a major mode to edit Racket source files, as well as a major
mode for a Racket REPL. The edit/run experience is similar to
DrRacket.

This will be maintained as part of the pkg-emacsen-addons team.

-BEGIN PGP SIGNATURE-

iQGzBAEBCAAdFiEE3VS2dnyDRXKVCQCp8gKXHaSnniwFAlk9lu0ACgkQ8gKXHaSn
nizx/Av/TQ1/LMouhVfA6VJdfwMgQo6E8+7xBMg7gQ1f/v5Pwoc2FZTj7aTGFl6b
wBMotced4/G7ikcpOw3xw1o7ObqvElvGetFctueIJoQw3yhvY2RsqrH5Uk25SeKx
iU96/rBuuRzM4h4GGFO14cWFZOkvoHMENhUcwcyjmUWdQNVIVZnC8cwlKDIy3aV5
kFKZPxg2G/xYuxsY4GP1lX65ZwcXJXClvU+r8junUdIynaXpzyo2ZBT7RY7BO0Kj
Aym6ZB1vABCh96dYmOSi1IvhBRKTDJJXRXLZofQtDNrVNE9HPCMo1eqLdAqWqLHn
zTaflR1omT4LNDMmJlB4AgMeB81haNB/Uwj8MUft71SYOo4qivhXVU2jbKeHqahP
fEScWo3lw2pP98UA/pLpojtzL6nbxRgemcSw2edKhkBj2bkI277Oo7o1RenBtrBz
exbU8017Oa9p2m20fabWMWeJkJjOYC4RqKMqsYpSeQpD1ZNuEYQS1DVfl5g3poEK
7+SjNnif
=/0ar
-END PGP SIGNATURE-

Re: DEP 15: Reserved namespace for DD-approved non-maintainer changes

[Sean Whitton]

Christian Seiler  writes:

> Your goal in wanting to stop people from having to deal with
> patch files manually is laudable, but I see the following way
> forward to achieve that goal:
>
>  - Pull requests.
>
>  - Make it easier to create personal copies of remote (!)
>repositories in one's own space. (Currently it's still a bit
>cumbersome.)

This would cover most of the use cases I had in mind.  Thanks for
bringing it up.  Let's see what Ian thinks.

-- 
Sean Whitton

Re: DEP 15: Reserved namespace for DD-approved non-maintainer changes

[Sean Whitton]

Christian Seiler  writes:

> Your goal in wanting to stop people from having to deal with
> patch files manually is laudable, but I see the following way
> forward to achieve that goal:
>
>  - Pull requests.
>
>  - Make it easier to create personal copies of remote (!)
>repositories in one's own space. (Currently it's still a bit
>cumbersome.)

This would 

-- 
Sean Whitton

Re: DEP 15: Reserved namespace for DD-approved non-maintainer changes

[Henrique de Moraes Holschuh]

On Sun, 11 Jun 2017, Sean Whitton wrote:
> Henrique de Moraes Holschuh  writes:
> 
> > Not just that.  If it is for NMUs, one also has to ensure it matches
> > what got uploaded (regardless of method: NMU patch, PR, branch...).
> 
> I'm not sure what you're getting at here -- this DEP is for changes that
> *aren't* to be uploaded as part of an NMU.

The (thread?) naming is unfortunate, then.  Anyway, if it does not
involve NMUs, my comment does not apply.

-- 
  Henrique Holschuh

Re: DEP 15: Reserved namespace for DD-approved non-maintainer changes

[Christian Seiler]

On 06/11/2017 07:44 PM, Sean Whitton wrote:
> Christian Seiler  writes:
> 
>> To me this looks like a very complicated technical solution
>> to something that I've never encountered as a problem myself.
> 
> Could you explain which parts of the proposal you find to be "very
> complicated"?  Possibly I've made them seem much more complicated than
> they actually are.

Well, the "very complicated" was mostly geared at the required
infrastructure behind it. Sure, you can reuse some dgit server
code, but in the end someone needs to maintain this.

> If a package does not have a repo on alioth, the only way for me to
> contribute a fix is to NMU, which always creates work for the
> maintainer, or file a bug report with patches.
> 
> With this DEP, I can push a next/foo branch, and file a bug pointing to
> it.  This means neither the maintainer nor contributor need mess around
> with patch files.

You can already create user repositories on Alioth where you can
push stuff. And I suspect that the successor of Alioth will
provide something similar.

My perspective is the following:

 - Most contributions to packages I'm (co-)maintaining have come
   from non-DDs.

 - I don't care whether a contribution comes from a DD or not. I
   always review it before committing it to the package.

So from this perspective you're trying to solve a non-problem,
and throwing a lot of infrastructure at it to do so.

Your goal in wanting to stop people from having to deal with
patch files manually is laudable, but I see the following way
forward to achieve that goal:

 - Pull requests.

 - Make it easier to create personal copies of remote (!)
   repositories in one's own space. (Currently it's still a bit
   cumbersome.)

Whether changes were done by a DD or not is not relevant for
anything that's not an archive upload, IMHO. In the archive it
_is_ relevant as packages get accepted automatically with a
proper signature. But any time there's a person doing manual
review of something (and every maintainer should!), I really
don't see any advantage whatsoever.

Regards,
Christian

[1] You mentioned that DMs with upload permissions for specific
packages would also be allowed, but I think you could ignore
that completely: a DM will either have permissions to upload
a specific package, in which case they're already a (co-)
maintainer of said package and should have access rights to
the packaging repository, or they don't, in which case they
won't be able to push there.

Re: Too many Recommends (in particular on mail-transport-agent)

[Russ Allbery]

Ivan Shmakov  writes:

>   That’s Abstract Syntax Notation One (or ASN.1), and while I use
>   it all the time (notation, that is; not this specific library at
>   the moment), I see no reason for a -dev package to depend on a
>   -doc one any stronger than with a mere Suggests:.

We have some specific Policy about this:

https://www.debian.org/doc/debian-policy/ch-docs.html#s-docs-additional

If package is a build tool, development tool, command-line tool, or
library development package, package (or package-dev in the case of a
library development package) already provides documentation in man,
info, or plain text format, and package-doc provides HTML or other
formats, package should declare at most a Suggests on
package-doc. Otherwise, package should declare at most a Recommends on
package-doc.

If you feel that this should cap the dependency at Suggests across the
board, feel free to submit a bug against debian-policy.  It seems at least
worth a discussion.  Note that this does tend to make upstreams pretty
unhappy, though, since they get questions from confused Debian users who
don't know how to find the documentation that they're "supposed" to have.

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

Re: DEP 15: Reserved namespace for DD-approved non-maintainer changes

[Sean Whitton]

Christian Seiler  writes:

> To me this looks like a very complicated technical solution
> to something that I've never encountered as a problem myself.

Could you explain which parts of the proposal you find to be "very
complicated"?  Possibly I've made them seem much more complicated than
they actually are.

> Again, sorry that I'm so negative here, and of course I have my own
> biases, but maybe you could provide an example work- flow where your
> proposal actually helps the maintainer and/ or the contributor?

Don't apologise for providing feedback :)  I'm grateful for it.

After reading comments in this thread, I think that the main use of
next/foo branches is likely to be for packages which lack repos on
alioth.  Otherwise, as you say, the contributor could use a PR.

If a package does not have a repo on alioth, the only way for me to
contribute a fix is to NMU, which always creates work for the
maintainer, or file a bug report with patches.

With this DEP, I can push a next/foo branch, and file a bug pointing to
it.  This means neither the maintainer nor contributor need mess around
with patch files.

-- 
Sean Whitton

Re: DEP 15: Reserved namespace for DD-approved non-maintainer changes

[Sean Whitton]

Ansgar Burchardt  writes:

> What about contributions to non-packaged parts of Debian?

This DEP isn't about those -- are you saying that it ought to be
extended?

> I also don't like having more systems only a subset of contributors
> can use.

I share this concern, but it is easier for a DD to review a change and
submit it to a next/foo branch than it is for a DD to review an NMU and
try to figure out whether it makes sense for an upload to happen right
now.  So it's more accessible to those without upload rights than NMUs
are at present.

> Having a place where every contributor can publish merge requests is
> nicer (one can still have a tool to make it easier to check commit
> signatures using the Debian keyrings if one so desires).

Not all packages have a repo on alioth, so even when alioth runs pagure
and gains PRs, there won't always be a place to submit changes.  With
this DEP, there is a place to submit a next/foo branch for any package
in the archive.

-- 
Sean Whitton

Re: DEP 15: Reserved namespace for DD-approved non-maintainer changes

[Sean Whitton]

Henrique de Moraes Holschuh  writes:

> Not just that.  If it is for NMUs, one also has to ensure it matches
> what got uploaded (regardless of method: NMU patch, PR, branch...).

I'm not sure what you're getting at here -- this DEP is for changes that
*aren't* to be uploaded as part of an NMU.

-- 
Sean Whitton

Re: Too many Recommends (in particular on mail-transport-agent)

[Stephen Kitt]

On Sun, 11 Jun 2017 06:12:23 +, Ivan Shmakov  wrote:
> > Adam Borowski  writes:
>  > gfortran-mingw-w64: gcc-mingw-w64  
> 
>  > * BAD: seriously, Fortran?  
> 
>   Fortran is still widely used (in niche applications; WRF comes
>   to mind), but I see no good reason for this dependency.

Backwards-compatibility, gcc-mingw-w64 used to include the Fortran compiler.
I meant to leave the Recommends there for one cycle and remove it, but forgot
— it will be gone in Buster.

>  > gnat-mingw-w64: gcc-mingw-w64  
> 
>  > * BAD: see Fortran.  
> 
>   Agreed.

See above.

Regards,

Stephen


pgptw6LGk16se.pgp
Description: OpenPGP digital signature

Bug#864610: ITP: php-netscape-bookmark-parser -- generic Netscape bookmark parser

[James Valleroy]

Package: wnpp
Severity: wishlist
Owner: James Valleroy 

* Package name: php-netscape-bookmark-parser
  Version : 2.0.2
  Upstream Author : Kafene , VirtualTam 
 
* URL : https://github.com/shaarli/netscape-bookmark-parser
* License : MIT Expat
  Programming Lang: PHP
  Description : generic Netscape bookmark parser

This library provides a generic NetscapeBookmarkParser class that is
able of parsing Netscape bookmarks as exported by common Web browsers
and bookmarking services.

This is a dependency for shaarli. I plan to maintain it within the
freedombox-pkg-team.

Re: Too many Recommends (in particular on mail-transport-agent)

[Ivan Shmakov]

> Adam Borowski  writes:
> On Mon, Jun 05, 2017 at 05:39:41PM -0700, Russ Allbery wrote:

 >> Maybe someone has a list of things they view as Recommends inflation
 >> that have (a) been reported as bugs to the appropriate package
 >> maintainers, and (b) have been rejected by those package
 >> maintainers?  Those are the controversial ones that we'd need to
 >> talk about.

[…]

 > bash-completion: bash dput-ng licensecheck

 > * DEBATABLE: I like the Tab key to do something reasonable,
 > "bash-completion" means you never know what you'll get.

FWIW, I agree wholeheartedly with this one.  (The only reason I
don’t have ‘complete -r’ in my ~/.bashrc is that bash-completion
is rarely if ever installed on the systems I frequently use.)

[…]

 > freedoom | game-data-packager: prboom-plus

 > * DEBATABLE: freedoom is too ugly to live, shareware Doom has assets
 > missing for running pretty much anything Doom-related (and AFAIK its
 > license forbids add-ons).  On the other hand, this is an excuse for
 > Doom engines in main.

The latter seems like a good enough reason for this dependency.

 > freepats: libwildmidi-config timidity

 > * BAD: freepats is too ugly to live: abysmal quality, lacks
 > instruments for pretty much any .mid file in the wild.  We do have a
 > bunch of good alternatives.  timgm6mb-soundfont for one is 5.6 times
 > smaller yet is complete.

Probably a relic of the days long gone; I guess it should be
updated to include some more alternatives (in preference to
freepats) – so long as timidity can (be made to) actually use
any of them “out-of-box.”

Package: freepats
Version: 20060219-1
…
Description-en: Free patch set for MIDI audio synthesis
…
 It is, however, the sole DFSG-compliant patch set in existence so far.
 New patches (including those in better formats, such as SF2 SoundFont banks)
 are welcome.

[…]

 > gfortran-mingw-w64: gcc-mingw-w64

 > * BAD: seriously, Fortran?

Fortran is still widely used (in niche applications; WRF comes
to mind), but I see no good reason for this dependency.

 > ghostscript: gimp imagemagick-6.q16 libmagickcore-6.q16-3 netpbm

 > * BAD: why would editing images care about a grossly obsolete
 > _document_ format?

So that one can $ convert  pic.ps pic.png?  Or (I suspect)
$ convert  file.pdf file.png, for that matter.

(Or perhaps more sensibly: $ display  pic.ps pic.pdf.)

Moreover, PostScript is a programming (code) language – not a
(data) format.

I’m neutral on this dependency, though.  I do like PostScript
for a document format as much as I do like JavaScript for the
same, but I see how it may be nice to support .ps (and .pdf?)
rasterization in ImageMagick and Gimp “out-of-box.”

[…]

 > gnat-mingw-w64: gcc-mingw-w64

 > * BAD: see Fortran.

Agreed.

 > gnupg-l10n: gnupg

 > * DEBATABLE: I don't think anyone tech skilled enough to use GPG
 > would have problems with English, but localization is important.
 > On the other hand, this is 4.5MB in the default install.

Well, ‘locales’ is about 9 MiB in the same, so…

[…]

 > libhtml-format-perl: libhtml-tree-perl libwww-perl

 > * : wut?

… Me neither.

 > libhttp-daemon-perl: libwww-perl

 > * TRANSITIVELY BAD: dependency comes from a client package; if I want
 > to run a http server I know where to find it

That’s only Installed-Size: 71, so I don’t see much of a
problem.  AIUI, libwww-perl (as per upstream) had the
HTTP::Daemon library for decades, thus not installing one by
default in Debian may easily surprise an unsuspecting user.

[…]

 > libpackage-stash-xs-perl: libpackage-stash-perl

 > * TRANSITIVELY BAD: dependencies pulling more dependencies, why?

I suppose that’s so one’s Perl script can be Architecture: all,
instead of depending on either pure-Perl or an XS (binary)
implementation of the package – depending on the architecture.

[…]

 > libpurple-bin: libpurple0

 > * BAD: a library has no reason to install programs

My exact reaction on seeing that Mutt transitively Depends: on
GnuPG – all thanks to libgpgme11 depending on the latter.

I do not know about this specific case, but I very much agree
with the principle.

[…]

 > libtasn1-doc: libtasn1-6-dev

 > * TRANSITIVELY BAD: probably useful if you do TASN (whatever it is),
 > pulled in by a very-widespread library (gnutls)

That’s Abstract Syntax Notation One (or ASN.1), and while I use
it all the time (notation, that is; not this specific library at
the moment), I see no reason for a -dev package to depend on a
-doc one any stronger than with a mere Suggests:.

[…]

 > transfig: inkscape

 > * BLOAT: a badly obsolete image format, pulls in ghostscript and
 > other crap

Curiously enough, I still find XFig – with all its nume