Bug#871464: ITP: golang-github-montanaflynn-stats -- Statistics package for Go

[Anthony Fok]

Package: wnpp
Severity: wishlist
Owner: Anthony Fok 

* Package name: golang-github-montanaflynn-stats
  Version : 0.2.0+git20170729.66.4a16327-1
  Upstream Author : Montana Flynn
* URL : https://github.com/montanaflynn/stats
* License : Expat
  Programming Lang: Go
  Description : Statistics package for Go

 Stats is a statistics package with many functions missing
 from the Golang standard library.

Reason for packaging:
 The newly released Hugo v0.26 requires github.com/jdkato/prose
 which requires "github.com/montanaflynn/stats".

Bug#871472: ITP: golang-gopkg-neurosnap-sentences.v1 -- Golang package that converts a blob of text into a list of sentences

[Anthony Fok]

Package: wnpp
Severity: wishlist
Owner: Anthony Fok 

* Package name: golang-gopkg-neurosnap-sentences.v1
  Version : 1.0.6-1
  Upstream Author : Eric Bower
* URL : http://gopkg.in/neurosnap/sentences.v1
https://github.com/neurosnap/sentences
* License : Expat
  Programming Lang: Go
  Description : Sentence tokenizer for Go

 A golang package that converts a blob of text into a list of sentences.

Reason for packaging:
 The newly released Hugo v0.26 requires github.com/jdkato/prose
 which requires "gopkg.in/neurosnap/sentences.v1"

Bug#871474: ITP: golang-github-jdkato-prose -- Golang library for text processing

[Anthony Fok]

Package: wnpp
Severity: wishlist
Owner: Anthony Fok 

* Package name: golang-github-jdkato-prose
  Version : 0.0~git20170806.0.a678fc7-1
  Upstream Author : Joseph Kato
* URL : https://github.com/jdkato/prose
* License : Expat
  Programming Lang: Go
  Description : Golang library for text processing

 prose is Go library for text (primarily English at the moment)
 processing that supports tokenization, part-of-speech tagging,
 named-entity extraction, and more. The library's functionality is
 split into subpackages designed for modular use.  See the documentation
 at https://godoc.org/github.com/jdkato/prose for more information.

Reason for packaging:
 github.com/jdkato/prose is needed by the newly released Hugo 0.26

Bug in https://release.debian.org/transitions/ page?

[Vincent Lefevre]

The https://release.debian.org/transitions/ lists in
"Ongoing transitions":

  auto-golang-goleveldb (100%)
  auto-libratbag (100%)

which are actually finished. And in "(almost) Finished transitions",
one can see:

  auto-libevent (5%)

which has 3 packages in "good", 2 packages in "partial", and
60 packages in "bad"!

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: OpenSSL disables TLS 1.0 and 1.1

[Stephan Seitz]

On Mo, Aug 07, 2017 at 11:18:38 -0500, Michael Lustfield wrote:

Is there an actual need for the removal of TLS v1.{0,1}? Are either
considered broken or unsupported by upstream? If not, I'd be much more


That’s I like to know as well.

Doing a quick check on my appliances I could find the following 
TLSv1-only devices:

- some iDRAC (Dell)
- Netapp Filer
- Cisco Web Security Appliances

And what about mail appliances? If they offer only TLSv1 then the Debian 
mailserver will fallback to unencrypted transfer. I don’t think this is 
a good idea.


Shade and sweet water!

Stephan

--
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |


smime.p7s
Description: S/MIME cryptographic signature

Re: Bug in https://release.debian.org/transitions/ page?

[Mattia Rizzolo]

Trying to guess what your actual question is...

On Tue, Aug 08, 2017 at 01:05:03PM +0200, Vincent Lefevre wrote:
> The https://release.debian.org/transitions/ lists in
> "Ongoing transitions":
> 
> which are actually finished. And in "(almost) Finished transitions",
> one can see:
> which has 3 packages in "good", 2 packages in "partial", and
> 60 packages in "bad"!

"ongoing" means the new library has yet to migrate to testing, "almost
finished" means the new library already migrated to testing, but the old
one did not yet get removed.


Please consider using a more welcoming tone though, as reading your
email I nearly perceived something disrespectful…

-- 
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: DocBook 5 for Debian

[Vincent Lefevre]

Hi,

On 2017-08-01 23:24:20 -0700, Paul Hardy wrote:
> Therefore, I propose filing ITPs for packages "docbook5", "docbook5-xsl",
> and "docbook5-xml".  The packages initially would be based on DocBook 5.1,
> unless DocBook 5.2 is finalized in the meantime.

FYI, docbook5-xml has existed for years, but is not up-to-date
(last updated in 2009).

I've just submitted

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=871485

against emacs25-common as it contains an obsolete DocBook RNC schema.
IMHO, Emacs should use the schema provided by the docbook*-xml packages.

So, I wonder whether there should be some form of catalog system
for the schemas (/etc/xml/catalog is for the DTD's only). Now that
DocBook 5 has its own namespace, this should be more reliable than
before.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: OpenSSL disables TLS 1.0 and 1.1

[Attila Szalay]

Hi,

My concern is less about https (hello iloms), but other kind of protocols.
Ssl vpn, rdp servers, voip, etc. And embedded devices implements this
protocols.

On Aug 8, 2017 7:35 AM, "Stephan Seitz" 
wrote:

> On Mo, Aug 07, 2017 at 11:18:38 -0500, Michael Lustfield wrote:
>
>> Is there an actual need for the removal of TLS v1.{0,1}? Are either
>> considered broken or unsupported by upstream? If not, I'd be much more
>>
>
> That’s I like to know as well.
>
> Doing a quick check on my appliances I could find the following TLSv1-only
> devices:
> - some iDRAC (Dell)
> - Netapp Filer
> - Cisco Web Security Appliances
>
> And what about mail appliances? If they offer only TLSv1 then the Debian
> mailserver will fallback to unencrypted transfer. I don’t think this is a
> good idea.
>
> Shade and sweet water!
>
> Stephan
>
> --
> | Public Keys: http://fsing.rootsland.net/~stse/keys.html |
>

Can Ubuntu font be added to a Debian repository?

[Garrett R.]

Is there a good reason why Ubuntu font is not found in Debian repositories? Is 
there a formal way to request that it be added to a repository?

http://font.ubuntu.com/

Re: Bug in https://release.debian.org/transitions/ page?

[Vincent Lefevre]

On 2017-08-08 14:13:31 +0200, Mattia Rizzolo wrote:
> Trying to guess what your actual question is...
> 
> On Tue, Aug 08, 2017 at 01:05:03PM +0200, Vincent Lefevre wrote:
> > The https://release.debian.org/transitions/ lists in
> > "Ongoing transitions":
> > 
> > which are actually finished. And in "(almost) Finished transitions",
> > one can see:
> > which has 3 packages in "good", 2 packages in "partial", and
> > 60 packages in "bad"!
> 
> "ongoing" means the new library has yet to migrate to testing, "almost
> finished" means the new library already migrated to testing, but the old
> one did not yet get removed.

Thanks for the explanations. I think that this should be documented.
There's nothing about that on this web page, and not either on the
following wiki pages:
  https://wiki.debian.org/Teams/ReleaseTeam/Transitions
  https://wiki.debian.org/OngoingTransitions

> Please consider using a more welcoming tone though, as reading your
> email I nearly perceived something disrespectful…

? Sorry if this is your perception. This was not intended.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: OpenSSL disables TLS 1.0 and 1.1

[Vincent Lefevre]

On 2017-08-08 13:26:52 +0200, Stephan Seitz wrote:
> On Mo, Aug 07, 2017 at 11:18:38 -0500, Michael Lustfield wrote:
> > Is there an actual need for the removal of TLS v1.{0,1}? Are either
> > considered broken or unsupported by upstream? If not, I'd be much more
> 
> That’s I like to know as well.

BTW, IMHO, as it can break things, this change should be announced
in NEWS.Debian, together with known problems with other Debian
software, and so on.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Automatic way to install dbgsym packages for a process?

[Stefan Fritsch]

On Mon, 7 Aug 2017, Paul Wise wrote:

> On Sun, Aug 6, 2017 at 12:14 PM, Stefan Fritsch wrote:
> 
> > Is there some tool that parses /proc/maps and the build-ids fields from
> > the apt repository to determine which dbgsym packages to install?
> 
> Not AFAIK but I guess that Fedora probably has a script for this somewhere.

Thanks for the pointer. I didn't find anything for /proc/$$/maps but there 
is eu-unstrip from elfutils which gives the list of Build-IDs from a core 
file.

I hacked together a perl script that uses that and grep-aptavail to get 
the list of packages (assuming you already have the correct entries in 
sources.list).

Now, where to put it? Into devscripts? The disadvantage is that devscripts 
already pulls in quite a few other packages via recommends. But I don't 
have a better idea. Unless we want to include it in reportbug or something 
like that?

> The service to map build-ids to snapshot.d.o packages is not fully
> implemented yet either.
> 
> http://build-id.debian.net/ (code on lw08.d.o)

That would be nice. But I don't think I have time to look into that in the 
forseeable future.

Cheers,
Stefan

Re: Can Ubuntu font be added to a Debian repository?

[Andrey Rahmatullin]

On Tue, Aug 08, 2017 at 01:40:27PM +, Garrett R. wrote:
> Is there a good reason why Ubuntu font is not found in Debian repositories? 
> Is there a formal way to request that it be added to a repository?
There is a formal way, and it was already done:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=603157

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Automatic way to install dbgsym packages for a process?

[Vincent Lefevre]

On 2017-08-08 15:53:34 +0200, Stefan Fritsch wrote:
> Now, where to put it? Into devscripts? The disadvantage is that devscripts 
> already pulls in quite a few other packages via recommends. But I don't 
> have a better idea. Unless we want to include it in reportbug or something 
> like that?

The one-line description of devscripts is:

  scripts to make the life of a Debian Package maintainer easier

So it's mainly targeted at Debian Package maintainers, while such
a script would be useful to end users.

Perhaps debian-goodies?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Can Ubuntu font be added to a Debian repository?

[Paul Wise]

On Tue, Aug 8, 2017 at 9:40 AM, Garrett R. wrote:

> Is there a good reason why Ubuntu font is not found in Debian repositories?

Looks like it requires proprietary software to build the font from source:

https://bazaar.launchpad.net/~sladen/ubuntu-font-family/midstream/view/head:/midstream/SOURCES.txt

> Is there a formal way to request that it be added to a repository?

Not sure if you are subscribed, so I quote from Andrey Rahmatullin's reply:

> There is a formal way, and it was already done:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=603157

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#871497: ITP: sambamba -- tools for working with SAM/BAM data

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: sambamba
  Version : 0.6.6
  Upstream Author : Artem Tarasov
* URL : https://github.com/lomereiter/sambamba
* License : GPL
  Programming Lang: D
  Description : tools for working with SAM/BAM data
 Sambamba provides tools for
  * Powerful filtering with sambamba view --filter
  * Picard-like SAM header merging in the merge tool
  * Optional for operations on whole BAMs
  * Fast copying of a region to a new file with the slice tool
  * Duplicate marking/removal, using the Picard criteria


Remark: The package is maintained by the Debian Med team at
https://anonscm.debian.org/git/debian-med/sambamba.git

Bug#871501: ITP: jellyfish1 -- count k-mers in DNA sequences

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: jellyfish1
  Version : 1.1.11
  Upstream Author : Guillaume Marçais1, Carl Kingsford
* URL : http://www.cbcb.umd.edu/software/jellyfish/
* License : BSD-like
  Programming Lang: C++
  Description : count k-mers in DNA sequences
 JELLYFISH is a tool for fast, memory-efficient counting of k-mers in
 DNA. A k-mer is a substring of length k, and counting the occurrences
 of all such substrings is a central step in many analyses of DNA
 sequence. JELLYFISH can count k-mers using an order of magnitude less
 memory and an order of magnitude faster than other k-mer counting
 packages by using an efficient encoding of a hash table and by
 exploiting the "compare-and-swap" CPU instruction to increase
 parallelism.
 .
 JELLYFISH is a command-line program that reads FASTA and multi-FASTA
 files containing DNA sequences. It outputs its k-mer counts in an
 binary format, which can be translated into a human-readable text
 format using the "jellyfish dump" command.
 .
 This is the latest version of the 1.x series of jellyfish which is
 used by some other applications that are not compatible with version
 2.x which is provided inside the jellyfish package.


Remark: Jellyfish1 is no new package.  It used to be in Debian but
 the code migrated to version 2 which is not compatible with all our
 tools.  So there is a need to keep the latest release of version 1.x
 which is packaged here.  The package is maintained by the Debian
 Med team at
https://anonscm.debian.org/git/debian-med/jellyfish1.git

Re: Automatic way to install dbgsym packages for a process?

[Stefan Fritsch]

On Tue, 8 Aug 2017, Vincent Lefevre wrote:

> On 2017-08-08 15:53:34 +0200, Stefan Fritsch wrote:
> > Now, where to put it? Into devscripts? The disadvantage is that devscripts 
> > already pulls in quite a few other packages via recommends. But I don't 
> > have a better idea. Unless we want to include it in reportbug or something 
> > like that?
> 
> The one-line description of devscripts is:
> 
>   scripts to make the life of a Debian Package maintainer easier
> 
> So it's mainly targeted at Debian Package maintainers, while such
> a script would be useful to end users.
> 
> Perhaps debian-goodies?

True, that's a better match. I will polish it a bug and then submit it.

Cheers,
Stefan

Re: sse{2,3,4.2}, altivec, neon, ...

[Adrian Bunk]

On Tue, Aug 08, 2017 at 04:47:26AM +0200, Adam Borowski wrote:
> On Sat, Aug 05, 2017 at 10:28:36PM +0200, Adam Borowski wrote:
> > It's easy to quite reliably detect the presence of such instructions
> > (probably no one JITs such code).  There's no real way to check if it's
> > executed unconditionally, though -- a lot of software has optimized code
> > paths that are chosen at runtime.
> > 
> > I guess we could apply such check to the archive: for example, if any of
> > these instructions are present in a code section: [snip]
> > then the program may need sse2.  But there's no good way to weed out false
> > positives automatically, so all we'd get is a list of candidates to check.
> 
> I went through the whole archive and disassembled all binaries in unstable
> in amd64 and i386 (not sure where to get a good list of neon instructions
> for armhf) -- results attached, and so is the script for analyzing a
> package[1].

Thanks, that's a really useful effort.

> Alas, there's way too many false positives to turn this into a lintian
> check.  There's 254 amd64 and 409 i386 sources which produce executables
> that include those instructions (I ignored other ISA extensions for now),
> most of them use proper runtime detection.  So unless someone can propose
> a better check, they'd need to be tested by hand.
>...

There are groups of packages (Go, gcl, haskell) that are either buggy 
due to one bug or can be whitelisted together.

The majority of packages in the amd64 list seem to be binaries built by Go.
I checked one case in a package, and that was code with proper runtime 
detection copied from golang-1.8 (Go doesn't have shared libraries).

Something like skipping binaries based on "objdump -t --section=.gosymtab" 
could whitelist these.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: Can Ubuntu font be added to a Debian repository?

[Steve Langasek]

On Tue, Aug 08, 2017 at 10:38:32AM -0400, Paul Wise wrote:
> On Tue, Aug 8, 2017 at 9:40 AM, Garrett R. wrote:

> > Is there a good reason why Ubuntu font is not found in Debian repositories?

> Looks like it requires proprietary software to build the font from source:

> https://bazaar.launchpad.net/~sladen/ubuntu-font-family/midstream/view/head:/midstream/SOURCES.txt

Which differs from the majority of fonts in Debian main only in that the
source is public.

-- 
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: Can Ubuntu font be added to a Debian repository?

[Garrett R.]

Would getting this project done help? (DSIG digitial signatures for Truetype 
.TTF and Opentype .OTF fonts). It sounds like it would open the possibility for 
allowing the signing block to be used with open tools.

https://github.com/sladen/fontsign


- Original Message -
From: "Steve Langasek" 
To: debian-devel@lists.debian.org
Sent: Tuesday, August 8, 2017 1:39:16 PM
Subject: Re: Can Ubuntu font be added to a Debian repository?

On Tue, Aug 08, 2017 at 10:38:32AM -0400, Paul Wise wrote:
> On Tue, Aug 8, 2017 at 9:40 AM, Garrett R. wrote:

> > Is there a good reason why Ubuntu font is not found in Debian repositories?

> Looks like it requires proprietary software to build the font from source:

> https://bazaar.launchpad.net/~sladen/ubuntu-font-family/midstream/view/head:/midstream/SOURCES.txt

Which differs from the majority of fonts in Debian main only in that the
source is public.

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

Re: sse{2,3,4.2}, altivec, neon, ...

[Bastien ROUCARIES]

On Tue, Aug 8, 2017 at 4:47 AM, Adam Borowski  wrote:
> On Sat, Aug 05, 2017 at 10:28:36PM +0200, Adam Borowski wrote:
>> It's easy to quite reliably detect the presence of such instructions
>> (probably no one JITs such code).  There's no real way to check if it's
>> executed unconditionally, though -- a lot of software has optimized code
>> paths that are chosen at runtime.
>>
>> I guess we could apply such check to the archive: for example, if any of
>> these instructions are present in a code section: [snip]
>> then the program may need sse2.  But there's no good way to weed out false
>> positives automatically, so all we'd get is a list of candidates to check.
>
> I went through the whole archive and disassembled all binaries in unstable
> in amd64 and i386 (not sure where to get a good list of neon instructions
> for armhf) -- results attached, and so is the script for analyzing a
> package[1].
>
> Alas, there's way too many false positives to turn this into a lintian
> check.  There's 254 amd64 and 409 i386 sources which produce executables
> that include those instructions (I ignored other ISA extensions for now),
> most of them use proper runtime detection.  So unless someone can propose
> a better check, they'd need to be tested by hand.

I will prefer to implement it on lintian. Even if false positive. BTW
could you print path ?

Bastien

>
> And no, presence of cpuid is not enough -- for example chromium:i386 checks
> it, yet requires sse2 (it even has proper runtime optimizations for sse4.2).
>
>
> Meow!
>
> [1]. pkgext needs to have the path to ext edited; I didn't bother adding
> fragile $0 logic.
> --
> ⢀⣴⠾⠻⢶⣦⠀
> ⣾⠁⢰⠒⠀⣿⡁ James Damore is a hero.  Even mild criticism of bigots these days
> ⢿⡄⠘⠷⠚⠋⠀ comes at great personal risk.
> ⠈⠳⣄

Re: Ubuntu font in debian repository

[Paul Sladen]

On Tue, 8 Aug 2017, Garrett R. wrote:
> Ubuntu font ... requires proprietary software to build
> (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=603157).
> Can a change be made ... ?

  debian-devel: "Can Ubuntu font be added to a Debian repository?"
  https://lists.debian.org/debian-devel/2017/08/msg00218.html
  https://lists.debian.org/debian-devel/2017/08/threads.html#00218

  ubuntu-devel-discuss: "Ubuntu font in debian repository"
  https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2017-August/017613.html

Hello Garrett,

Using a reproducible automated build, with a libre toolchain, for the
Ubuntu Font Family is the ultimate goal yes.  This needed/still needs:

  1. development of libre tool chains (== work usable by all fonts...)
  2. building the UFF fonts purely from source, using that toolchain
  3. pragmatically proving non-regression with existing binary-only 
 hand-built versions out there (as a precondition to switch-over)

For (1), there as been lots of work of libre toolchains in the last 18
months, via Dalton Maag and latterly a large push backed by the Google
Fonts team to make generic libre font toolchains, that are freely
usable by all.

For (2), there is an early test version **not ready for release** of a
open toolchain buildable 'Ubuntu' at:

  https://github.com/daltonmaag/ubuntu

Using a new-two feedback mechanism this branch was used to test and
create further required toolchain features---ultimately for the
benefit of all free/libre fonts.

(Please resist distributing builds from this until it is known to be
at the point of provable non-regression);

For (3): Proof of non-regression.  The Ubuntu Font Family is widely
used all over the place (including huge numbers of websites and from
within Google Docs).  This means there is an additional responsibility
to prove *non-regression* between the "new" automated-build-form-
source-development branch, against the prior binaries built by hand.

This type of testing requires tooling---Google Fonts has been working
on automated regression testing, which should help with this.

-*- -*- -*-

Yes it is taking a long time, but the world of libre fonts progressed
a lot in the last five years.  Once all of this pieces come together,
our collective dream can be fulfilled too.

Until this it is a work in progress,

-Paul

Bug#871533: ITP: uprightdiff -- examine differences between two images

[Kunal Mehta]

Package: wnpp
Severity: wishlist
Owner: Kunal Mehta 

* Package name: uprightdiff
  Version : 1.1.0
  Upstream Author : Tim Starling 
* URL : https://www.mediawiki.org/wiki/Uprightdiff
* License : BSD
  Programming Lang: C++
  Description : examine differences between two images

This utility examines the differences between two images.
It produces a visual annotation and reports statistics.

It is optimised for images which come from browser screenshots.
It analyses the image for vertical motion, and annotates connected
regions that have the same vertical displacement. Then it highlights
any remaining ("residual") differences which are not explained by
vertical motion on a pixel-by-pixel basis.

bind9 shipping outdated root hint file (etc.)

[Chris Lamb]

Hi -devel,

It was just mentioned "en passant" in a conversation at DebConf that
bind9 is shipping a root hint file from 2003.

I had a quick glance at the bug list and saw it was a little larger
than I would have liked for what is clearly a critical piece and
infrastructure. :)

Lamont, can you comment? Anyone interested in helping out here…?


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Re: Automatic way to install dbgsym packages for a process?

[Mike Hommey]

On Tue, Aug 08, 2017 at 04:02:59PM +0200, Vincent Lefevre wrote:
> On 2017-08-08 15:53:34 +0200, Stefan Fritsch wrote:
> > Now, where to put it? Into devscripts? The disadvantage is that devscripts 
> > already pulls in quite a few other packages via recommends. But I don't 
> > have a better idea. Unless we want to include it in reportbug or something 
> > like that?
> 
> The one-line description of devscripts is:
> 
>   scripts to make the life of a Debian Package maintainer easier
> 
> So it's mainly targeted at Debian Package maintainers, while such
> a script would be useful to end users.
> 
> Perhaps debian-goodies?

One would argue this should be a feature of apt. In Fedora land, you use
yum or dnf for debug packages, and btw, that's really something that's
missing in Debian.

Mike

Re: bind9 shipping outdated root hint file (etc.)

[Bernhard Schmidt]

Chris Lamb  wrote:

> It was just mentioned "en passant" in a conversation at DebConf that
> bind9 is shipping a root hint file from 2003.

FWIW, the bug about this is #860794. I have just upgraded it to grave
since DNSSEC validation will stop working in October, and it has not
been fixed anywhere.

> I had a quick glance at the bug list and saw it was a little larger
> than I would have liked for what is clearly a critical piece and
> infrastructure. :)
>
> Lamont, can you comment? Anyone interested in helping out here…?

I'd be willing to help here. I rely on BIND at work and we have started
to roll our own packages anyway, mostly due to 9.11 not making it into
Stretch which we need for DNSSEC key management. But I think bind9
deserves a larger team.

Bernhard

Re: bind9 shipping outdated root hint file (etc.)

[LaMont Jones]

On Tue, Aug 08, 2017 at 04:47:27PM -0400, Chris Lamb wrote:
> It was just mentioned "en passant" in a conversation at DebConf that
> bind9 is shipping a root hint file from 2003.

The version of db.root in stretch is from Feb 17, 2016.  I suspect that the
comment originates from the fact that I've never done any backports to
stable releases, nor do I particularly want to do so.  Others have been
doing that.

> I had a quick glance at the bug list and saw it was a little larger
> than I would have liked for what is clearly a critical piece and
> infrastructure. :)
> 
> Lamont, can you comment? Anyone interested in helping out here…?

There are a couple of people who are working with me on it, as per the
control file in the package.  Many of the bugs are more minor, or asking
for upstream development, or asking when some feature will be backported
to a stable release.  I tend to not close those bugs out of hand, so the
bug list is both accurate and overstating.

lamont

Re: bind9 shipping outdated root hint file (etc.)

[Bernhard Schmidt]

Bernhard Schmidt  wrote:
> Chris Lamb  wrote:
>
>> It was just mentioned "en passant" in a conversation at DebConf that
>> bind9 is shipping a root hint file from 2003.
>
> FWIW, the bug about this is #860794. I have just upgraded it to grave
> since DNSSEC validation will stop working in October, and it has not
> been fixed anywhere.

Err, not the root hint, but the very much more severe DNSSEC root key.

I think the current versions default to managed-keys which means they
should keep working on the rollover event as long as they have been
running for some time before, but new installations will break.

Bernhard

Re: bind9 shipping outdated root hint file (etc.)

[Robert Edmonds]

Chris Lamb wrote:
> It was just mentioned "en passant" in a conversation at DebConf that
> bind9 is shipping a root hint file from 2003.

No, this is just wrong. The hints file shipped in the bind9 package in
stretch is from 2016:

;   This file holds the information on root name servers needed to
;   initialize cache of Internet domain name servers
;   (e.g. reference this file in the "cache  .  "
;   configuration file of BIND domain name servers).
;
;   This file is made available by InterNIC 
;   under anonymous FTP as
;   file/domain/named.cache
;   on server   FTP.INTERNIC.NET
;   -OR-RS.INTERNIC.NET
;
;   last update:February 17, 2016
;   related version of root zone:   2016021701
[…]

There are now 26 root server addresses, and root servers are renumbered
slowly enough that the normal Debian release process is more than
adequate for keeping up with those renumbering events. Over the past
decade or more the DNS root server network has added IPv6 addresses, and
has renumbered out of network prefixes used by larger networks into
network prefixes dedicated solely to root DNS service. So my guess is
that renumbering events will become even more rare over time.

The consequences for having an out-of-date root hints file are fairly
minimal. All modern recursive DNS servers employ a "priming" technique
where the initial hints list is used to obtain the latest set of root
server addresses at server startup. See RFC 8109, "Initializing a DNS
Resolver with Priming Queries".

An up-to-date set of root hints is shipped in the dns-root-data package,
but I believe only a few DNS software packages have been updated to take
advantage of it. Some DNS servers also embed a copy of root server
addresses in compiled binaries as a hedge against missing or obsolete
hints files, and this practice is fine as long as the upstream
developers keep that list up-to-date and make regular releases. Priming
will ensure that those binaries obtain an up-to-date set of addresses at
startup.

The only package in the archive that I know of that has a seriously
deficient set of root hints is djbdns; it has 11/13 of the current set
of IPv4 root server addresses, and 0/13 IPv6 root server addresses.
(However, I don't believe the 'djbdns' binary package ships with the
IPv6 patch applied.)

> I had a quick glance at the bug list and saw it was a little larger
> than I would have liked for what is clearly a critical piece and
> infrastructure. :)

It may have been true in 2003 that bind9 was a critical piece of DNS
infrastructure for Linux distributions, but it has become much less true
over time: there are multiple, modern implementations of authoritative
and recursive DNS servers in the Debian archive today. On the recursive
side: PowerDNS Recursor, Knot Resolver, and Unbound. On the
authoritative side: Power DNS Authoritative, Knot DNS, and NSD.

-- 
Robert Edmonds
edmo...@debian.org

Bug#871541: ITP: libplibsys0 -- Highly portable C system library

[Alexander Saprykin]

Package: wnpp
Severity: wishlist
Owner: Alexander Saprykin 

* Package name: libplibsys0
  Version : 0.0.3
  Upstream Author : Alexander Saprykin 
* URL : https://github.com/saprykin/plibsys
* License : LGPL
  Programming Lang: C
  Description : Highly portable C system library

plibsys is a cross-platform system C library with some helpful routines.
It has zero third-party dependencies and uses only native system calls.

plibsys provides:

- Platform independent data types
- Threads, mutexes, condition variables, RW locks
- Syste-wide semaphores and shared memory
- Optimized spinlock, atomic operations
- Socket support (UDP, TCP) with IPv4 and IPv6
- Hash functions (MD5, SHA-1, SHA-2, SHA-3, GOST)
- Binary trees (RB, AVL)
- INI file parser
- High resolution time profiler
- Files and directories operations
- Shared library loading
- Macros to detect CPU architecture, OS and compiler
- Some other useful routines to manage linked lists, strings, hash tables

To achieve maximum native performance on each platform several implementation
models are used:

- Threading models: POSIX, Solaris, OS/2, BeOS, AtheOS, Win32
- IPC models: POSIX, System V, OS/2, Win32
- Time profiler models: POSIX, Solaris, Mach, OS/2, BeOS, Win32, generic
- Directory iterating models: POSIX, OS/2, Win32
- Shared library loading models: POSIX, HP-UX, OS/2, BeOS, Win32
- Atomic operations models: sync (GCC), C11, DECC, Win32, simulated
- Sockets: BSD with Win32 support

plibsys is fully covered with unit tests and was tested on the following
platforms:

- GNU/Linux
- macOS
- Windows
- Cygwin, MSYS
- FreeBSD, NetBSD, OpenBSD, DragonFlyBSD
- Solaris
- AIX
- HP-UX
- Tru64
- OpenVMS
- OS/2
- IRIX
- QNX Neutrino
- UnixWare 7
- SCO OpenServer 5
- Haiku
- Syllable
- BeOS

It also supports the following modile platforms:

- BlackBerry 10

plibsys was tested with the following compilers:

- MSVC (x86, x64) 2003 and above
- MinGW (x86, x64)
- Open Watcom (x86)
- Borland (x86)
- GCC (x86, x64, PPC32be, PPC64be/le, IA-64/32, IA-64, Alpha,
  HPPA2.0-32, MIPS32, AArch32, SPARCv9)
- Clang (x86, x64, PPC32be)
- Intel (x86, x64)
- QCC (x86, AArch32)
- Oracle Solaris Studio (x86, x64, SPARCv9)
- MIPSpro (MIPS32)
- XL C (PPC64le)
- DEC C (Alpha)
- PGI (x86, x64)

This library provides most of the functionality you need when
writing cross-platform system software. It doesn't have any other
dependencies, thus is very lightweight. The build system is
written completely using modern CMake. It was already used in
some proprietary mission-critical projects. Probably, the
closest package would be GLib, but plibsys supports more
operating systems (especially if you need to support old ones),
more compilers, much easier to port on new platforms and compilers.

I'm planning to add and maintain native support for Debian packages.
Actually I have already had a draft version of Debian package
support, but I still need someone to check and verify it, and also
correct my first steps in making packages for Debian.

Bug#871547: general: Can't change to any other background.

[Default User]

Package: general
Severity: normal

Dear Maintainer,

Running Debian Unstable, with Cinnamon Desktop Environment, default Display
Manager. Upgraded from Debian 9 Stable. Was okay.  Updated last on 2017-08-07,
then shut down. Upon reboot 2017-08-08, background has reverted to the
softwaves-theme wallpaper image installed by default upon installation of
Debian 9 Stable. This is the same image that displays behind grub menu during
startup.

Using the Change Background GUI (just like in Gnome 3), clicking on any
backgound or other image highlights the image preview, but then nothing else
happens.

Tried rebooting, using the Cinnamon, Sofware rendering, and Default Xsession
choices at the login screen.

Sent this email to debian-u...@lists.debian.org:

-

Hi.

- Debian Unstable.
- Cinnamon desktop environment.
- Updated 2017-08-07, then shut down.
- On 2017-08-08, booted up.

Now, background is the Debian 9 default "Flipper" image.  Background can not be
changed.

What to check / what to do?

--

Did not receive any reply, so do not know which package(s) may be involved.

Also checked Debian forums, did not see similar problem posted.  Did not post
problem to forum.s

Also tried on IRC (freenode - #Dbian channel). Received only one vague
suggestion:
"downgrade gnome-settings-daemon gsettings-desktop-schemas to testing
versions". Chose not to try suggested action, as determined to have excess risk
of operator error.

Have waited for spontaneous fix by further update, still waiting.

Will provide additional information to the extent that I can.

Thank you for your indulgence.





-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.11.0-2-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Sudah waktunya, jangan tunda Qurbanya... Udah tau belum sekarang ada SGQ?

[Yatim Mandiri]

**Program Super Gizi Qurban (SGQ)**

 ![](http://i.imgur.com/tizxiNY.jpg)

**Untuk anda yang kerepotan dalam menyiapkan hewan kurban secara langsung?**

Tenang kami memberikan solusi kemudahan bagi anda yang ingin menyalurkan kurban 
anda melalui uang tunai.

Bahkan bisa transfer melalui rekening loh!!! Tidak perlu repot harus mencari 
sapi yang ingin dibuat kurban nanti !!!

**Kini telah ada paket praktis untuk anda**  
 Dengan perinciannya :

Qurban 1 Ekor Sapi = Rp 17.500.000,-  
 Qurban 1/7\* Ekor Sapi = Rp 2.500.000,-

Biaya tersebut sudah termasuk pengolahan dan distribusi.  
 Hewan qurban anda akan disembelih secara syar'i dan diolah menjadi sosis untuk 
didistribusikan kepada mereka yang benar-benar membutuhkan

  
![](http://i.imgur.com/Qe4vzJK.jpg)

Keunggulan Super Gizi Qurban bersama Yatim Mandiri

1\. Sesuai Syariah

2\. Praktis dan Higienis

3\. Sarana Peningkatan Gizi Anak Yatim Dhuafa

4\. Distribusi Hingga Pelosok Negeri

5\. Tahan Lama

  
 Simak juga video proses penyembelihan, pengolahan dan distribusinya 
[Disini](https://aplikasi.kirim.email/redir/orG1fpDdTPEUSWb20170809094018OGM/b536acaf5b24395ddd6c6a6593980879d28c27c7d4014977edb864840b983645)

https://www.youtube.com/embed/odD_ZoOzuYA"; 
style="position:absolute;top:0;left:0;width:100%;height:100%" 
width="450">Info Selengkapnya :  
 Yayasan Yatim Mandiri  
 Jl. Raya Jambangan 135-137 Surabaya 60232  
 WA : 0811 1343 577  
 Telp. (031) 828 3488  
[www.yatimmandiri.org](https://aplikasi.kirim.email/redir/sbf3IHaEpCFmQ2520170809094018dEw/b536acaf5b24395ddd6c6a6593980879d28c27c7d4014977edb864840b983645)

Yatim Mandiri  
Jalan Raya Jambangan 135-137  
Surabaya - 60232  
Indonesia  
[(031) 823 3488](tel:(031) 823 3488)

- - - - - -

[Unsubscribe](https://aplikasi.kirim.email/unsub/sk1XwWdHVSnv6By20170809094018vCU/b536acaf5b24395ddd6c6a6593980879d28c27c7d4014977edb864840b983645)
  
 E-mail ini dikirim menggunakan 
[Kirim.Email](https://kirim.email/kue/aff/go/patriawijaya?i=12&utm_source=Yatim+Mandiri&utm_medium=email-footer&utm_campaign=Super+Gizi+Qurban)![](https://facebook.com/tr?id=http://www.facebook.com/yatim.mandiri&ev=KirimEmailView&noscript=1&cd[type]=bc&cd[message_subject]=Sudah+waktunya%2C+jangan+tunda+Qurbanya...+Udah+tau+belum+sekarang+ada+SGQ%3F&cd[campaign_name]=Super+Gizi+Qurban)![](https://aplikasi.kirim.email//image/sk1XwWdHVSnv6By20170809094018vCU/b536acaf5b24395ddd6c6a6593980879d28c27c7d4014977edb864840b983645)

Re: bind9 shipping outdated root hint file (etc.)

[James Andrewartha]

[not subscribed, please cc:]

Hi Robert, LaMont,

I'm familiar with the original conversation, so I had a look and found
that the server had been installed in 2003, and that /etc/bind/db.root
is a conffile, so perhaps there's historically a packaging problem where
it's not being updated automatically. The server is running jessie 8.9
with bind9 1:9.9.5.dfsg-9+deb8u13.

Thanks,

-- 
James Andrewartha

Bug#871552: ITP: golang-github-shogo82148-go-shuffle -- Primitives for shuffling slices and user-defined collections in Go

[Anthony Fok]

Package: wnpp
Severity: wishlist
Owner: Anthony Fok 

* Package name: golang-github-shogo82148-go-shuffle
  Version : 0.0~git20170808.0.5982909-1
  Upstream Author : Ichinose Shogo
* URL : https://github.com/shogo82148/go-shuffle
* License : Expat
  Programming Lang: Go
  Description : Primitives for shuffling slices and user-defined 
collections in Go

 Package shuffle provides primitives for shuffling slices and user-defined
 collections in Go.

Reason for packaging:
 github.com/shogo82148/go-shuffle is imported by github.com/jdkato/prose,
 which in turn is needed by the newly released Hugo 0.26