Re: X facts about Debian - some fact checking and looking for ideas.

[Raphael Hertzog]

Hi,

On Thu, 24 Aug 2017, shirish शिरीष wrote:
> As far as fact-checking goes, can anybody share about Debian and Kali
> Linux relationship in bit more detail. AFAIK Raphaël Hertzog is one of
> the main developers and there has been lot of symbiotic relationship
> between the two projects but how much both projects have benefited
> from this partnership has not been codified or told/shared anywhere
> AFAIK.
> 
> The only thing I could get is
> https://docs.kali.org/policy/kali-linux-relationship-with-debian which
> seems to be pretty dry and short as far as documentation goes.

You know, you could have sent me an email if you wanted to have some
information on my work. You can have a look at my blog, I post monthly
summaries where I report the work I did on Debian and Kali.

http://raphaelhertzog.com

There's also a section about the relationship with Kali in this book:
https://kali.training/chapter-1/relationship-with-debian/
https://kali.training/chapter-1/a-bit-of-history/

I also gave a talk last year in Debconf:
https://kali.training/chapter-1/a-bit-of-history/

I started the pkg-security team notably to help bring back Kali
packages into Debian and to make it easier to help maintain security
packages that we use in Kali and that come straight from Debian.

https://debconf16.debconf.org/talks/39/

HTH.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

make dpkg-buildpackage default locale UTF-8

[Hans-Christoph Steiner]

Package: dpkg-dev

More and more packages are adding unicode files as unicode support has
become more reliable and available.  The package building process is not
guaranteed to happen in a unicode locale since the Debian default locale
is LC_ALL=C, which is ASCII not UTF-8.  Reading UTF-8 filenames when the
system is using ASCII causes errors (Python makes them very visible, for
example).

mbiebl, youpi, wRAR, bunk, and I had a discussion in #debian-devel.  It
looks like setting the default locale to C.UTF-8 in dpkg-buildpackage is
an easy way to improve this situation a lot.  Any package that needs an
encoding besides UTF-8 could always set it by adding something like this
to debian/rules:

  export LC_ALL = C

Setting C.UTF-8 as the global default in Debian would be the best
solution to this and many other issues, but that's a much much larger
project:
https://sourceware.org/glibc/wiki/Proposals/C.UTF-8

Re: Bug#873919: make dpkg-buildpackage default locale UTF-8

[Guillem Jover]

Control: forcemerge -1 843776

Hi!

On Fri, 2017-09-01 at 10:23:59 +0200, Hans-Christoph Steiner wrote:
> Package: dpkg-dev
> 
> More and more packages are adding unicode files as unicode support has
> become more reliable and available.  The package building process is not
> guaranteed to happen in a unicode locale since the Debian default locale
> is LC_ALL=C, which is ASCII not UTF-8.  Reading UTF-8 filenames when the
> system is using ASCII causes errors (Python makes them very visible, for
> example).
> 
> mbiebl, youpi, wRAR, bunk, and I had a discussion in #debian-devel.  It
> looks like setting the default locale to C.UTF-8 in dpkg-buildpackage is
> an easy way to improve this situation a lot.  Any package that needs an
> encoding besides UTF-8 could always set it by adding something like this
> to debian/rules:
> 
>   export LC_ALL = C

As long as the project considers debian/rules the main entry point to a
package build, I'm not planning on predefining new general purpose
environment variables from dpkg-buildpackage that would otherwise not
be set by the builder.

The distinction here would be something like LC_*, against something
like CC on a cross-compilation, which you need to set no matter what.

But please, see the rationale on the other bug. I think I'll be adding
an entry to the dpkg FAQ, because it seems this has become a recurring
request. :)

> Setting C.UTF-8 as the global default in Debian would be the best
> solution to this and many other issues, but that's a much much larger
> project:
> https://sourceware.org/glibc/wiki/Proposals/C.UTF-8

That _might_ help on buildds, but not on maintainer systems for example.

Thanks,
Guillem

Re: Raising the severity of reproduciblity issues to "important"

[Guillem Jover]

Hi!

On Fri, 2017-09-01 at 09:26:44 +0300, Adrian Bunk wrote:
> AFAIK the only place where we currently still need binary packages that 
> have been built on a maintainer machine is for NEW, and after someone
> has implemented a solution for that there is no blocker left for 
> allowing only source-only uploads from maintainers.

Bootstrapping (either for new ports, or for build-dep cycles) is still
also a blocker. Although that is already being worked on, spearheaded
by Helmut Grohne as part of the great rebootstrap effort [R].

Thanks,
Guillem

[R] 

Re: Raising the severity of reproduciblity issues to "important"

[Holger Levsen]

On Fri, Sep 01, 2017 at 09:26:44AM +0300, Adrian Bunk wrote:
> AFAIK the only place where we currently still need binary packages that 
> have been built on a maintainer machine is for [...]
 
the fun part is that once a package builds bit by bit identically, it doesnt
matter anymore where it's been built…! :-)


-- 
cheers,
Holger


signature.asc
Description: Digital signature

normal bugs (Re: Raising the severity of reproduciblity issues to "important")

[Holger Levsen]

On Fri, Sep 01, 2017 at 09:34:53AM +0300, Adrian Bunk wrote:
> On Sun, Aug 23, 2015 at 12:48:50PM +0200, Chris Lamb wrote:
> >...
> > However, based on an informal survey at DebConf (and to reflect the
> > feeling towards software reproducibility in the free software community
> > in general) unless there are strong objections I intend to raise the
> > severity of these wishlist issues to "important" once the toolchain
> > changes to dpkg and debhelper land in sid.
> I would strongly object to raising the severity to "important" for 
 
sigh. you are replying to a mail from 2015, were you aware of that?

Last thing Chris (and we all) said (at+during DebConf, so just 2 weeks ago),
is that we plan to treat such bugs as severity "normal" bugs.


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Re: Raising the severity of reproduciblity issues to "important"

[Simon McVittie]

On Fri, 01 Sep 2017 at 09:40:25 +, Holger Levsen wrote:
> On Fri, Sep 01, 2017 at 09:26:44AM +0300, Adrian Bunk wrote:
> > AFAIK the only place where we currently still need binary packages that 
> > have been built on a maintainer machine is for [...]
>  
> the fun part is that once a package builds bit by bit identically, it doesnt
> matter anymore where it's been built…! :-)

The problem with maintainer-built binaries around NEW is that if they
wait in the NEW queue for (let's say) 1 month, then by the time they
reach the archive, they were built with a 1 month old toolchain and
build-dependencies, not an up-to-date toolchain and dependencies.
Reproducible builds don't help with this, because a package can
typically only be reproducible when holding the toolchain and
dependencies constant.

S

Re: normal bugs (Re: Raising the severity of reproduciblity issues to "important")

[Adrian Bunk]

On Fri, Sep 01, 2017 at 09:43:54AM +, Holger Levsen wrote:
> On Fri, Sep 01, 2017 at 09:34:53AM +0300, Adrian Bunk wrote:
> > On Sun, Aug 23, 2015 at 12:48:50PM +0200, Chris Lamb wrote:
> > >...
> > > However, based on an informal survey at DebConf (and to reflect the
> > > feeling towards software reproducibility in the free software community
> > > in general) unless there are strong objections I intend to raise the
> > > severity of these wishlist issues to "important" once the toolchain
> > > changes to dpkg and debhelper land in sid.
> > I would strongly object to raising the severity to "important" for 
>  
> sigh. you are replying to a mail from 2015, were you aware of that?
>...

No, I have too many emails in my debian-devel folder
and did not have enough black tea in the morning.

Sincere apologies and please ignore my emails, it is my fault that
I failed to read the year of the emails I replied to and responded
to an obsolete proposal.

Sorry
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: Raising the severity of reproduciblity issues to "important"

[Helmut Grohne]

On Fri, Sep 01, 2017 at 11:07:17AM +0100, Simon McVittie wrote:
> The problem with maintainer-built binaries around NEW is that if they
> wait in the NEW queue for (let's say) 1 month, then by the time they
> reach the archive, they were built with a 1 month old toolchain and
> build-dependencies, not an up-to-date toolchain and dependencies.
> Reproducible builds don't help with this, because a package can
> typically only be reproducible when holding the toolchain and
> dependencies constant.

I fail to see the problem here. Of course the maintainer-built binaries
should be accompanied with the relevant .buildinfo file telling what
versions of dependencies were used - just like any buildd-built package.

Packages can sit in unstable for months - even years - without being
updated and thus their binaries do use years old toolchain and
build-dependencies. What you describe does happen to buildd-built
packages. The key to reproducibility here is using the .buildinfo and
replicating the installation used for the original build (using
snapshot.d.o).

Whatever point you were trying to make around NEW, your argument is not
very convincing. I think Holger is right here: Where the package is
built should not matter. Presence of .buildinfo and reproducibility
does.

Regarding Guillem's point: I don't think disallowing binary uploads is
going to be a problem to bootstrapping. Ubuntu has been doing this for
years. They have a small set of people who can (carefully) inject binary
packages and that mechanism is sufficient. Restricting binary uploads to
a small subgroup of Debian Developers does make sense to me from a
bootstrap pov, because uploading binaries could be a rare thing to do.

We should be less shy in copying the good stuff from Ubuntu. :)

Helmut

Status of the ACE package | Is the ACE team still active ?

[Sebastian Andrzej Siewior]

Hi,

I am trying to figure out if someone knows about the whereabouts of the
Debian ACE packaging team. Johnny Willemsen contacted me because he had
problems to get in touch with the ACE team[0]. He is part of the upstream
team and is interested in getting the package in shape again. It
currently suffers from one RC bug (#853299).

The members of ACE team are:
- Thomas Girard 
  last activity Nov 2015 (PGP upload)
  Martin Borgert orphaned omnievents which they both co-maintained.

- Pau Garcia i Quiles 
  last activity Nov 2016 (PGP upload)

- Marek Brudka 
  last activity Oct 2010 (BTS)

Does anyone have an idea about their current status?

[0] http://lists.alioth.debian.org/pipermail/pkg-ace-devel/2017-June/003534.html

Sebastian

Bug#873939: ITP: libjose -- Jose is a C-language implementation of the Javascript Object Signing and Encryption standards?=

[Christoph Biedl]

Package: wnpp
Severity: wishlist
Owner: Christoph Biedl 

* Package name: libjose
  Version : 9
  Upstream Author : Nathaniel McCallum https://github.com/npmccallum
* URL : https://github.com/latchset/jose
* License : Apache-2.0
  Programming Lang: C
  Description : José is a C-language implementation of the Javascript 
Object Signing and Encryption standards

Quoting the project homepage:

| José is a C-language implementation of the Javascript Object Signing
| and Encryption standards. Specifically, José aims towards implementing
| the following standards:
| 
| RFC 7515 - JSON Web Signature (JWS)
| RFC 7516 - JSON Web Encryption (JWE)
| RFC 7517 - JSON Web Key (JWK)
| RFC 7518 - JSON Web Algorithms (JWA)
| RFC 7519 - JSON Web Token (JWT)
| RFC 7520 - Examples of ... JOSE
| RFC 7638 - JSON Web Key (JWK) Thumbprint
| 
| José is extensively tested against the RFC test vectors.

Jose is a dependency for tang which I've just ITP'd (#854409).

Christoph


signature.asc
Description: Digital signature

Re: [Pkg-ace-devel] Status of the ACE package | Is the ACE team still active ?

[Thomas Girard]

hello,

I don't have much time for ACE packaging and I don't use it anymore. I should 
probably remove myself from uploaders. 

Are you willing to step in?

Unless Pau has some time for it the package should be RFA'ed. I can find time 
to sponsor an upload though.

Regards,

Thomas 

Le 1 septembre 2017 13:09:06 GMT+02:00, Sebastian Andrzej Siewior 
 a écrit :
>Hi,
>
>I am trying to figure out if someone knows about the whereabouts of the
>Debian ACE packaging team. Johnny Willemsen contacted me because he had
>problems to get in touch with the ACE team[0]. He is part of the
>upstream
>team and is interested in getting the package in shape again. It
>currently suffers from one RC bug (#853299).
>
>The members of ACE team are:
>- Thomas Girard 
>  last activity Nov 2015 (PGP upload)
>  Martin Borgert orphaned omnievents which they both co-maintained.
>
>- Pau Garcia i Quiles 
>  last activity Nov 2016 (PGP upload)
>
>- Marek Brudka 
>  last activity Oct 2010 (BTS)
>
>Does anyone have an idea about their current status?
>
>[0]
>http://lists.alioth.debian.org/pipermail/pkg-ace-devel/2017-June/003534.html
>
>Sebastian
>
>___
>Pkg-ace-devel mailing list
>pkg-ace-de...@lists.alioth.debian.org
>http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-ace-devel

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.

Bug#873940: ITP: libluksmeta -- LUKSMeta is a simple library for storing metadata in the LUKSv1 header

[Christoph Biedl]

Package: wnpp
Severity: wishlist
Owner: Christoph Biedl 

* Package name: libluksmeta
  Version : 7
  Upstream Author : Nathaniel McCallum https://github.com/npmccallum
* URL : https://github.com/latchset/luksmeta
* License : LGPL-2.1+
  Programming Lang: C
  Description : LUKSMeta is a simple library for storing metadata in the 
LUKSv1 header

LUKSmeta is a dependency for clevis which I've just ITP'd (#854410), and
probably needed by tang as well (ITP is #854409).

Christoph



signature.asc
Description: Digital signature

Re: source-only uploads

[Emmanuel Bourg]

> and after someone
> has implemented a solution for that there is no blocker left for 
> allowing only source-only uploads from maintainers.

I'm all for source-only uploads and I adopted them recently, but I hope
this restriction won't happen, or at least not without a derogation
mechanism. Just yesterday I completely broke a key package used to build
many Java packages, and I couldn't even rebuild it to fix the issue. I
had to install a missing package locally and rebuild the binary on my
machine. It would have been very difficult to fix that without binary
uploads.

Emmanuel Bourg

Bug#873942: ITP: node-stream-splicer -- streaming pipeline with a mutable configuration

[Bastien ROUCARIES]

Package: wnpp
Severity: wishlist
Owner: ro...@debian.org
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-stream-splicer
  Version : 2.0.0
  Upstream Author : James Halliday  (http://substack.net)
* URL : https://github.com/substack/stream-splicer
* License : Expat
  Programming Lang: JavaScript
  Description : streaming pipeline with a mutable configuration

 This modules allows one to create a pipeline duplex stream given an
 array of streams. Each stream will be piped to the next.
 .
 Stream could also be added and removed dynamically at runtime.
 .
 Node.js is an event-based server-side JavaScript engine.

Re: source-only uploads

[Andrey Rahmatullin]

On Fri, Sep 01, 2017 at 12:47:41PM +0200, Emmanuel Bourg wrote:
> Just yesterday I completely broke a key package used to build
> many Java packages, and I couldn't even rebuild it to fix the issue.
Why? Does it B-D on itself?

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#873963: ITP: node-immediate -- cross browser microtask library

[Kartik Kulkarni]

Package: wnpp
Severity: wishlist
Owner: Kartik Kulkarni 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-immediate
  Version : 3.2.3
  Upstream Authors : Donavon West, Domenic Denicola, Brian Cavalier
* URL : https://github.com/calvinmetcalf/immediate
* License : Expat
  Programming Lang: JavaScript
  Description: Cross browser microtask library
  Immediate is a microtask library decended from
  NobleJS's setImmediate package and includes ideas
  from Cujo's When and RSVP package.
  .
  Immediate takes tricks from setImmedate and RSVP
  and combines them with the schedualer inspired by whens.
  .
  Tricks are tasks mentioned from setImmediate package
  which are run as necessary.
  .
  Node.js is an event-based server-side JavaScript engine.

  It is a dependency of gitlab 9

  I am not a debian member and would like to maintain this package for
a long term and would like to join the javascript maintainers group,
Praveen had agreed to sponsor this package.

let's drop non-UTF-8 locales

[Adam Borowski]

On Fri, Sep 01, 2017 at 10:23:59AM +0200, Hans-Christoph Steiner wrote:
> More and more packages are adding unicode files as unicode support has
> become more reliable and available.  The package building process is not
> guaranteed to happen in a unicode locale since the Debian default locale
> is LC_ALL=C, which is ASCII not UTF-8.  Reading UTF-8 filenames when the
> system is using ASCII causes errors (Python makes them very visible, for
> example).
> 
> Setting C.UTF-8 as the global default in Debian would be the best
> solution to this and many other issues

I'd go farther: make UTF-8 guaranteed, and drop all support for ancient
encodings as LC_*.

Unlike exim vs postfix vs ssmtp, systemd vs sysvinit, vi or emacs or a
better editor, xfce vs mate, etc, where each alternative has its upsides,
UTF-8 is basically strictly[1] better for text transmission[2].

As for use, lemme repeat the pretty graphs from January's bug mining:

max=51%; X scale: 1 dot = 1 month
⠀⠀⢠⠀⠀⠀⣀⠀⠀⠀
⠀⣄⣾⠀⠀⣦⣿⣿⡄⠀⡆⠀⠀⠀
⢠⣿⣿⣄⡇⣿⣿⣿⡇⠀⡇⠀⠀⠀
⣷⣿⣿⣿⣇⡄⡇⠀⠀⠀
⣿⡇⡇⠀⠀⠀
⣿⣷⡇⡀⢀⠀
⣿⣿⣿⣷⢸⡀
⣸⣿⣀⠀⠀⠀
⣿⣿⣿⡇⠀⠀
⣶⡀
⣿⣧
⣿⣿⣾⣧⣤⣶⡀⠀⠀⠀
⣿⣿⡇⡀⠀⠀⡀⠀⠀⠀
⣿⣿⣿⣷⣤⣾⣇⡀⠀⠀
⣿⣿⣿⣧⣿⣦⣠⣷⣄⣰⣠⡀⢀⠀⡀⠀⠀⠀
⣿⣿⣿⣷⣾⣷⣷⣠⡀⠀⠀⡀⢸⣿⡄⠀⡄⣠⡀⠀⠀⠀
⣿⣿⣾⣿⣾⣿⣿⣶⣴⣤⣠⣷⣷⣿⣧⣰⣴⡄⣤⣠⣄⣀⣄⢀⢰⡀⣀⣀⣀⢀
Oct 2004  Jan 2017

Enlarged:
max=7%; X scale: 1 dot = 1 month
⠀⡄⡆
⠀⣿⡇⠀⠀⠀⡀
⠀⣿⣧⠀⢰⢀⡇
⡀⣿⣿⡄⠀⠀⠀⢰⢸⢸⣿
⣷⣿⣿⣷⡆⡄⠀⢸⣸⣸⣿⠀⡀⡄⠀⠀⠀⡄⠀
⣷⣿⡆⡄⣿⣷⢠⡄⢠⠀⡀⡀⣦⠀⢰⠀⠀⡇⠀
⣿⣿⣼⣷⣿⣿⣾⣦⣧⣿⣼⣶⣶⣆⡆
Jan 2012   Jan 2017
Avg for 2016+: 0.8%.


Ancient encodings don't grant any extra functionality, merely provide compat
for a connector issue -- and per the above graphs, I believe we can drop it. 
During a recent house renovation, my father insisted on having every second
electricity socket have no earthing pin, because it makes it impossible to
use old Soviet-style plugs.  I challenged him to show me one he uses, and it
turned out he did not even have any anywhere on storage.  Here, keeping
compat makes you lose functionality (no earthing when you need it), adds
extra complexity, etc.  Any support for alternatives has such costs: the
question is, do we anything in return?  For MTAs, inits, editors, desktop
environments -- we do.  For locale encodings?  I can't think of an upside.

On the other hand, gains from such droppage would be nice.  An example:
dash, while striving for 100% POSIX compliance, wontfixed a "must"
requirement that ${#variable} returns length in characters not bytes.
If we assume UTF-8, all you need to do is count bytes outside 0x80..0xBF;
if you want to detect malformed data and reinvent the wheel, it takes a page
of code.  But to support ancient encodings, you need complex machinery to
locate and read a file from disk and call such pluggable code.  This was
deemed to be too costly for dash.

There's a lot of other insanity we'd get rid of: what would you say about
people demanding for every /etc/passwd entry to allow a different encoding? 
Or see how badly random Python programs started failing recently because of
some changes to locale handling.  And so on, so on...


Thus, I propose: let's declare all non-UTF-8 locales unsupported. 
Code-wise, a program that doesn't call setlocale() may still use "C"
(changes as to its meaning are up to glibc's upstream[3]), but setting the
env vars to anything non-UTF-8 by the user would no longer be supposed to
work.  We close all such bugs, and ensure that if the user fails to specify
a locale, C.UTF-8 is used.

What would you folks say?



Meow!

[1]. For non-strictly, you need to seek obscure scenarios, such as as purely
Chinese plain text with no markup nor formatting might take slightly less
space when encoded in a two-byte encoding vs usually-three-byte UTF-8.

[2]. Internal processing, such as random access array of codepoints, might
want a fixed-width encoding, but that's orthogonal

Re: Raising the severity of reproduciblity issues to "important"

[Ian Campbell]

On Fri, 2017-09-01 at 12:43 +0200, Helmut Grohne wrote:
> Whatever point you were trying to make around NEW, your argument is not
> very convincing. I think Holger is right here: Where the package is
> built should not matter. Presence of .buildinfo and reproducibility
> does.

Appollogies if this is covering well worn ground but does this mean we
therefore need to check that everything referenced in .buildinfo was
present in the archive at some point as a step during accepting a
package (new or not new) into the archive?

Where "was present in the archive at some point" is a proxy for "is
present on snapshots.d.o". If that can also be checked directly that
might be cool, although it might be considered a bit rude to a
maintainer to reject a package for what was a snapshot.do.o issue.

https://wiki.debian.org/ReproducibleBuilds/BuildinfoFiles suggests that
the build environment contains the versions of packages but not their
hashes -- so there is a possibility that a developer might be building
with a non-canonical version of the package. Perhaps they installed a
local dev version of the build-dep, perhaps because they maintain both
and we doing a quasi-simultaneous upload. That's perhaps not indicative
of best practice, but mistakes do happen.

Ian.

Re: source-only uploads

[Ian Jackson]

Andrey Rahmatullin writes ("Re: source-only uploads"):
> On Fri, Sep 01, 2017 at 12:47:41PM +0200, Emmanuel Bourg wrote:
> > Just yesterday I completely broke a key package used to build
> > many Java packages, and I couldn't even rebuild it to fix the issue.
>
> Why? Does it B-D on itself?

And, if it does, can it not be built using stretch ?

Ian.

Re: make dpkg-buildpackage default locale UTF-8

[Ian Jackson]

Hans-Christoph Steiner writes ("make dpkg-buildpackage default locale UTF-8"):
> More and more packages are adding unicode files as unicode support has
> become more reliable and available.  The package building process is not
> guaranteed to happen in a unicode locale since the Debian default locale
> is LC_ALL=C, which is ASCII not UTF-8.  Reading UTF-8 filenames when the
> system is using ASCII causes errors (Python makes them very visible, for
> example).

I think this is a bug in Python.  The default "C" locale should be
just-send-8 for filenames and data.

Ian.

Re: [Pkg-ace-devel] Status of the ACE package | Is the ACE team still active ?

[Sebastian Andrzej Siewior]

I dropped Marek from Cc because the email delivery times out.

On 2017-09-01 13:41:18 [+0200], Thomas Girard wrote:
> hello,
Hi,

> I don't have much time for ACE packaging and I don't use it anymore. I should 
> probably remove myself from uploaders. 
Okay.

> Are you willing to step in?
no, not really but I would like to see it built against openssl1.1 :)

> Unless Pau has some time for it the package should be RFA'ed. I can find time 
> to sponsor an upload though.
Okay, good to know.
Johnny, are you interrested in packaging ACE?

> Regards,
> 
> Thomas 

Sebastian

Re: source-only uploads

[Andrey Rahmatullin]

On Fri, Sep 01, 2017 at 07:18:58PM +0100, Ian Jackson wrote:
> Andrey Rahmatullin writes ("Re: source-only uploads"):
> > On Fri, Sep 01, 2017 at 12:47:41PM +0200, Emmanuel Bourg wrote:
> > > Just yesterday I completely broke a key package used to build
> > > many Java packages, and I couldn't even rebuild it to fix the issue.
> >
> > Why? Does it B-D on itself?
> 
> And, if it does, can it not be built using stretch ?
How will that help?

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: make dpkg-buildpackage default locale UTF-8

[Ivan Shmakov]

> Hans-Christoph Steiner  writes:

 > Package: dpkg-dev

 > More and more packages are adding unicode files

I assume you mean “UTF-8 filenames” here (per below), right?

 > as unicode support has become more reliable and available.

What are the use cases for such filenames?

FWIW, I more than just occasionally use Debian in environments
with fonts lacking good (as in: ≥ 90%) Unicode, or even BMP,
coverage.  (Specifically, I’m for the most part interested in
Latin-1, -3, and Cyrillic characters only.)

Do you suggest that there’re filenames in Debian packages that
cannot be rendered in such environments?  If so, that’d
certainly be a nuisance for me.

 > The package building process is not guaranteed to happen in a unicode
 > locale since the Debian default locale is LC_ALL=C, which is ASCII
 > not UTF-8.  Reading UTF-8 filenames when the system is using ASCII
 > causes errors (Python makes them very visible, for example).

[…]

-- 
FSF associate member #7257  np. Fear of the Dark — Iron Maiden  B6A0 230E 334A

Bug#873970: ITP: gtksourceview4: GTK+ syntax highlighting widget

[Jeremy Bicha]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org
Owner: jbi...@ubuntu.com

Package Name: gtksourceview4
Version: 3.99.4
Upstream Author : Ignacio Casal Quinteiro,
  Jesse van den Kieboom, Paolo Borelli, Sébastien Wilmet and others
License : LGPL-2.1+ except for a few GPL-2+ files
Programming Lang: C

Description: shared libraries for the GTK+ syntax highlighting widget
 GtkSourceView is a text widget that extends the standard GTK+ 3.x text widget
 GtkTextView. It improves GtkTextView by implementing syntax highlighting and
 other features typical of a source editor.

Other Info
--
Somewhat confusingly, gtksourceview4 is a new API for GTK+ 3.
gtksourceview5 is planned for release in a few years for GTK+ 4.

For more information, see
https://wiki.gnome.org/Projects/GtkSourceView/TransitionToGtkSourceView4
https://developer.gnome.org/gtksourceview/unstable/

The Debian GNOME team intends to maintain this package.

I'm uploading to experimental for now.

Packaging is currently at
https://anonscm.debian.org/viewvc/pkg-gnome/desktop/experimental/gtksourceview4/

Thanks,
Jeremy Bicha

Bug#873983: ITP: nanook -- pre- and post-alignment analysis of nanopore sequencing data

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: nanook
  Version : 1.26+dfsg-1
  Upstream Author : Richard M. Leggett 
* URL : https://documentation.tgac.ac.uk/display/NANOOK/NanoOK
* License : GPL
  Programming Lang: Java
  Description : pre- and post-alignment analysis of nanopore sequencing data
 NanoOK is a flexible, multi-reference software for pre- and post-
 alignment analysis of nanopore sequencing data, quality and error
 profiles.
 .
 NanoOK (pronounced na-nook) is a tool for extraction, alignment and
 analysis of Nanopore reads. NanoOK will extract reads as FASTA or FASTQ
 files, align them (with a choice of alignment tools), then generate a
 comprehensive multi-page PDF report containing yield, accuracy and
 quality analysis. Along the way, it generates plain text files which can
 be used for further analysis, as well as graphs suitable for inclusion
 in presentations and papers.


Remark: This package will be maintained by the Debian Med team at
   https://anonscm.debian.org/git/debian-med/nanook.git

Re: let's drop non-UTF-8 locales

[Adam Borowski]

On Fri, Sep 01, 2017 at 06:31:57PM +0200, Adam Borowski wrote:
> and ensure that if the user fails to specify a locale, C.UTF-8 is used.

Fun thing: build the attached program with glibc then with musl.

glibc:
"C.UTF-8" iswalpha: 1 (want 1), mbtowc: 2 (want 2)
"C"   iswalpha: 0 (want 1), mbtowc: -1 (want 2)
unset iswalpha: 0 (want 1), mbtowc: -1 (want 2)
musl:
"C.UTF-8" iswalpha: 1 (want 1), mbtowc: 2 (want 2)
"C"   iswalpha: 1 (want 1), mbtowc: 1 (want 2)
unset iswalpha: 1 (want 1), mbtowc: 2 (want 2)

Ie, if none of LC_ALL, LANG, LC_CTYPE are set, musl considers this to mean
C.UTF-8, exactly what I wanted here.  This does match POSIX:

http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08_02

# 4. If the LANG environment variable is not set or is set to the empty
#string, the implementation-defined default locale shall be used.


This looks drastically more robust than what I had in mind (mucking with
login defs and env of daemons), and is all standards-kosher.

Ie, if you don't choose a locale at all (as opposed to picking C or
ko_KP.ISO-8859-1), you'll get UTF-8.  

Any thoughts?  As this idea has distro-wide effects, I'm asking you guys
first before annoying glibc maintainers (ours or upstream).


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢰⠒⠀⣿⡁ Vat kind uf sufficiently advanced technology iz dis!?
⢿⡄⠘⠷⠚⠋⠀ -- Genghis Ht'rok'din
⠈⠳⣄ 
#include 
#include 
#include 
#include 
#include 

int main()
{
const char *in="ą\n";
wchar_t out;

setlocale(LC_CTYPE, "");
printf("iswalpha: %d (want 1), mbtowc: %d (want 2)\n",
iswalpha(0x105), mbtowc(&out, in, strlen(in)));
return 0;
}

Re: Whether remotely running software is considered "software" for Debian.

[Tollef Fog Heen]

]] "Dr. Bas Wijnen" 

> On Thu, Aug 31, 2017 at 11:16:36AM +0200, Ansgar Burchardt wrote:
> > python-digitalocean, ruby-azure*, waagent, twittering-mode,
> > probably HBCI clients, python3-googleapi,
> > python3-pyicloud, python-yowsup, youtube-dl,
> > libgfbgraph-0.2-dev
> 
> Thank you for this list.  I removed servers that cannot run on a general
> purpose system, because for obvious reasons they cannot be included in main
> even if they were free software.

Then you shouldn't remove usbmuxd for instance.  iOS devices are general
purpose computing devices, they just run another OS, and there's nothing
stopping somebody from implementing the same interfaces using free
software and, say, the Linux USB APIs.

I'm not sure what OS modern HP printers run, but I would also not be
surprised if they run a pretty straightforward Linux.  Somebody could
implement the APIs and produce, say, PDFs, or print using a hand-built
printer.  For the first case, you could easily run that on a general
purpose system.

You say that the requirement for an implementation to be useful is
orthogonal to whether it's suitable for main.  Does that also hold with
s/useful/functional/?

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Re: [Pkg-ace-devel] Status of the ACE package | Is the ACE team still active ?

[Johnny Willemsen]

Hi,


>> Are you willing to step in?
> no, not really but I would like to see it built against openssl1.1 :)
The code changes for that are now part of master, trying to get a new
x.4.5 release next week which should add this support

Johnny

Bug#874011: ITP: core-moos -- Mission Oriented Operating Suite

[Kyle Fazzari]

Package: wnpp
Severity: wishlist
Owner: Kyle Fazzari 

* Package name: core-moos
  Version : 10.0.2.a
  Upstream Author : Paul Michael Newman 
* URL : 
http://www.robots.ox.ac.uk/~mobile/MOOS/wiki/pmwiki.php/Main/HomePage
* License : GPL-2+
  Programming Lang: C++
  Description : Mission Oriented Operating Suite

Light, fast, cross-platform middleware for robotics. CoreMOOS is the most
fundamental layer, providing a very robust network based communications
architecture (two libraries and a lightweight communications hub called
MOOSDB) which for very little effort lets you build applications which
communicate with each other.

This software is often used in marine robotics, but users typically run
from source. This is an attempt to rectify that situation, at least for
Debian-based distributions. I'm planning on maintaining it, although
co-maintainers would not be turned down. I have a sponsor.

Summary of the 2038 BoF at DC17

[Steve McIntyre]

Hi folks,

As promised, here's a quick summary of what was discussed at the 2038
BoF session I ran in Montréal.

Thanks to the awesome efforts of our video team, the session is
already online [1]. I've taken a copy of the Gobby notes too,
alongside my small set of slides for the session. [2]

We had a conversation about the coming End of The World, the 2038 problem.

What's the problem?
---

UNIX time_t is 31 bits (signed), counting seconds since Jan 1,
1970. It's going to wrap.. It's used *everywhere* in UNIX-based
systems. Imagine the effects of Y2K, but worse.

What could go wrong?


All kinds if disasters! We're not trying to exaggerate this *too*
much, but it's likely to be a significat problem. For most of the
things that needed fixing for Y2K, they were on big obvious computers,
typically mainframes. Y2K was solved by people doing a lot of work; to
many outside of the direct work, it almost came to be an anti-climax.

In 20 years' time, the systems that we will be trying to fix for the
2038 problem are likely to be much harder to track. They're typically
not even going to look like computers - look at the IoT devices
available today, and extrapolate. Imagine all kinds of devices with
embedded computers that we won't know how to talk to, let alone verify
their software.

When does it happen?


Pick the example from the date(1) man page:

$ date --date=@$((2**31-1))
Tue 19 Jan 03:14:07 GMT 2038

At that point, lots of software will believe it's suddenly 1902...

What needs doing?
-

Lots of fixes are going to be needed all the way up the stack. 

Data formats are often not 2038-safe. The filesystems in use today are
typically not ready. Modern ext4 *is*, using 34 bits for seconds and
30 bits for nanoseconds. btrfs uses a 64-bit second counter. But data
on older filesystems will need to be migrated.

There are many places in the Linux kernel where 32-bit time_t is
used. This is being worked on, and so are the interfaces that expose
32-bit time_t.

Lots of libraries use 32-bit time_t, even in places where it might not
be obvious. Finally, applications will need fixing.

Linux kernel


There's project underway to fix Linux time-handling, led by Deepa
Dinamani and Arnd Bergmann. There's a web site describing the efforts
at https://kernelnewbies.org/y2038 and a mailing list at
y2...@lists.linaro.org. They are using the y2038 project as a good way
to get new developers involved in the Linux kernel, and those people
are working on fixing things in a number of areas: adding core 64-bit
time support, fixing drivers, and adding new versions of interfaces
(syscalls, ioctls).

We can't just replace all the existing interfaces with 64-bit
versions, of course - we need to continue suporting the existing
interfaces for existing code.

There are lots of tasks here where people can join in and help.

Glibc
-

Glibc is the next obvious piece of the puzzle - almost everything
depends on it. Planning is ongoing at

  https://sourceware.org/glibc/wiki/Y2038ProofnessDesign

to provide 64-bit time_t support without breaking the existing 32-bit
code. There's more coverage in LWN at

  https://lwn.net/Articles/664800/

The glibc developers are obviously going to need the kernel to provide
64-bit interfaces to make much progress. Again, there's lot of work to
be done here and help will be welcome.

Elsewhere?
--

If you're working further up the stack, it's hard to make many fixes
when the lower levels are not yet done.

Kernels other than Linux are also going to have the same problems to
solve - not really looked at them in much detail. As the old time_t
interfaces are POSIX-specified, hopefully we'll get equivalent new
64-bit interfaces that will be standard across systems.

Massive numbers of libraries are going to need updates, possibly more
than people realise. Anything embedding a time_t will obviously need
changing. However, many more structures will embed a timeval or
timespec and they're also broken. Almost anything that embeds
libc-exposed timing functions will need updating.

We're going to need mass rebuilds to find things that break with new
interfaces, and to ensure that old interfaces still work. An obvious
thing to do here also is automated scanning for ABI compliance as
things change.

Things to do now


Firstly: developers trying to be *too* clever are likely to only make
things worse - don't do it! Whatever you do in your code, don't bodge
around the 32-bit time_t problem. *Don't* store time values in weird
formats, and don't assume things about it to "avoid" porting
problems. These are all going to cause pain in the future as we try to
fix problems.

For the time being in your code, *use* time_t and expect an ABI break
down the road. This is the best plan *for now*.

In terms of things like on-disk data structures, don't try to
second-guess future interfaces by simply adding padding space for a
64

Re: Summary of the 2038 BoF at DC17

[Henrique de Moraes Holschuh]

On Sat, 02 Sep 2017, Steve McIntyre wrote:
> Massive numbers of libraries are going to need updates, possibly more
> than people realise. Anything embedding a time_t will obviously need
> changing. However, many more structures will embed a timeval or
> timespec and they're also broken. Almost anything that embeds
> libc-exposed timing functions will need updating.

Let's not forget about several archive formats, too, such as cpio.  They
have to be extended/replaced.

-- 
  Henrique Holschuh

Re: Summary of the 2038 BoF at DC17

[Adam Borowski]

On Sat, Sep 02, 2017 at 12:58:54AM +0100, Steve McIntyre wrote:
> What's the problem?
> ---
> 
> UNIX time_t is 31 bits (signed), counting seconds since Jan 1,
> 1970. It's going to wrap.. It's used *everywhere* in UNIX-based
> systems. Imagine the effects of Y2K, but worse.

> Glibc is the next obvious piece of the puzzle - almost everything
> depends on it. Planning is ongoing at
> 
>   https://sourceware.org/glibc/wiki/Y2038ProofnessDesign
> 
> to provide 64-bit time_t support without breaking the existing 32-bit
> code.

I find it strange that you don't mention x32 anywhere.  Dealing with
assumptions that time_t = long was the majority of work with this port; a
lot of software still either did not apply submitted patches or accepted
only dumb casts to (long) instead of a proper y2038-proof solution.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢰⠒⠀⣿⡁ Vat kind uf sufficiently advanced technology iz dis!?
⢿⡄⠘⠷⠚⠋⠀ -- Genghis Ht'rok'din
⠈⠳⣄ 

Re: make dpkg-buildpackage default locale UTF-8

[Tollef Fog Heen]

]] Ivan Shmakov 

> > Hans-Christoph Steiner  writes:
> 
>  > Package: dpkg-dev
> 
>  > More and more packages are adding unicode files
> 
>   I assume you mean “UTF-8 filenames” here (per below), right?
> 
>  > as unicode support has become more reliable and available.
> 
>   What are the use cases for such filenames?

Accurate representation of what they contain.  wnorwegian contains a
file «bokmål» which is the word list for the form of Norwegian known as
bokmål.  There's a convenience link between it and bokmaal so that
people without Norwegian keyboard (or without compose keys) can type it
too, but the canonical name is bokmål, not bokmaal.

(I see there's a small bug where the symlink is the wrong way around,
I'll get that fixed.)

å is in latin1, though so fonts should not be a problem in your
particular case.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are