Re: Common configuration of Debianish build etc. tools

[Marcin Kulisz]

On 11 September 2019 20:24:07 BST, gregor herrmann  wrote:
>On Wed, 11 Sep 2019 16:22:18 +0100, Ian Jackson wrote:
>
>> One example is:
>>export-dir (gbp)
>>buildresult (pbuilder)
>>build-products-dir (dgit)
>>build-dir (sbuild)
>> 
>> So, it would be good for there to be a single way to configure these
>> things.  Every tool ought to look in this single place as well as its
>> own configuration.
>
>Ack.
>Using export-dir in gbp, I had to set build-products-dir for dgit
>recently, which felt a bit boring.

I went through exactly the same issue a few weeks back, so +1 from me to Ian 
proposal with Russ suggestion about xdg.

I'd like to add that one line or two, added into each tool man page about this 
config file option would also be nice.

Re: Common configuration of Debianish build etc. tools

[Paul Wise]

On Thu, Sep 12, 2019 at 3:24 AM gregor herrmann wrote:

> ~/.devscripts already exists (typically) which similar variables,
> maybe this could be re-used?

Using ~/.devscripts means running shell and passing variables out of
it, which is quite hard to get right. The devscripts config loading
module got it wrong until recently, is still a bit hacky really (but
there is a patch) and still needs migration of many of the scripts
from their own bad config loading implementations to the config
loading module. I think it would be best to avoid code (especially
shell) as configuration in favour of static configuration files with
dynamic overrides added via environment variables where needed.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Handling of entropy during boot

[Ben Hutchings]

On Wed, 2019-09-11 at 15:52 -0400, Paul Thomas wrote:
> Hi All,
> 
> First off, I want to acknowledge how great system Debian is, very nice work!
> 
> I know the issue with Entropy Starvation is understood, and I
> understand the security concern:
> https://wiki.debian.org/BoottimeEntropyStarvation
> https://daniel-lange.com/archives/152-hello-buster.html
> 
> However, I would just like to indicate how nuts this has been driving
> me. First, with a new Buster install it took me a little while just to
> figure out what was going on with sshd. I did install haveged, and
> this helps for general cases. But then I have corner cases like when
> the root filesystem is readonly then haveged doesn't work.
> 
> I'm not using ancient hardware I'm on a modern arm64 processor, but it
> is an embedded environment with no keyboard or mouse.

And no hardware RNG?

Ben.

-- 
Ben Hutchings
Unix is many things to many people,
but it's never been everything to anybody.




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

Re: Handling of entropy during boot

[Paul Thomas]

Hi All,

First off, I want to acknowledge how great system Debian is, very nice work!

I know the issue with Entropy Starvation is understood, and I
understand the security concern:
https://wiki.debian.org/BoottimeEntropyStarvation
https://daniel-lange.com/archives/152-hello-buster.html

However, I would just like to indicate how nuts this has been driving
me. First, with a new Buster install it took me a little while just to
figure out what was going on with sshd. I did install haveged, and
this helps for general cases. But then I have corner cases like when
the root filesystem is readonly then haveged doesn't work.

I'm not using ancient hardware I'm on a modern arm64 processor, but it
is an embedded environment with no keyboard or mouse.

-Paul

Re: Common configuration of Debianish build etc. tools

[gregor herrmann]

On Wed, 11 Sep 2019 16:22:18 +0100, Ian Jackson wrote:

> One example is:
>export-dir (gbp)
>buildresult (pbuilder)
>build-products-dir (dgit)
>build-dir (sbuild)
> 
> So, it would be good for there to be a single way to configure these
> things.  Every tool ought to look in this single place as well as its
> own configuration.

Ack.
Using export-dir in gbp, I had to set build-products-dir for dgit
recently, which felt a bit boring.
 
> If this is a good idea then we need to agree on a filename and format.
> The format must be easy to parse in a variety of programming languages
> including, in particular, shell scripts.  Any suggestions ?

~/.devscripts already exists (typically) which similar variables,
maybe this could be re-used?
 
Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature

Bug#940049: ITP: pd.build-cmake-module -- Pure Data CMake Module

[IOhannes m zmoelnig]

Package: wnpp
Severity: wishlist
Owner: IOhannes m zmölnig (Debian/GNU) 

* Package name: pd.build-cmake-module
  Version : 0.1
  Upstream Author : Pierre Guillot
* URL : https://github.com/pierreguillot/pd.build
* License : GPL-3
  Programming Lang: CMake
  Description : Pure Data CMake Module

 Pure Data (also known as Pd) is a real-time graphical programming environment
 for audio and graphics processing.
 It can be easily extended with so called 'externals'
 .
 This package contains a CMake Module for building such externals.

This package is part of the ongoing attempt to package the Pure Data microcosm
for Debian (and a prerequisite of the update of the src:jsusfx package).
I intend to maintain the package under the multimedia-team umbrella.

Re: Common configuration of Debianish build etc. tools

[Johannes Schauer]

Quoting Russ Allbery (2019-09-11 18:15:45)
> I think this is a good idea.

+1

Patches to sbuild welcome!

I wonder which configuration should take precedence in case a setting is
specified in the common configuration file as well as in another way that the
program understands -- probably the latter should overrule the former?

Thanks!

cheers, josch


signature.asc
Description: signature

Re: Common configuration of Debianish build etc. tools

[Russ Allbery]

I think this is a good idea.

Ian Jackson  writes:

> It shouldn't just be an environment variable because that clutters the
> environment unnecessarily.  I think it should probably be a config
> file in ~, overrideable with an environment variable.  (Or perhaps the
> config filename could be overrideable with an environment variable.)

The currently popular bikeshed color (with widespread support in multiple
languages) is to use the XDG Base Directory Specification, which defaults
to looking in ~/.config and honors XDG_CONFIG_HOME as an environment
variable to move those files elsewhere.  I personally much prefer this
because it reduces clutter in $HOME and also moves config files into a
separate directory (which one can then easily keep in version control)
from other crap that programs want to write in the home directory but that
I don't particularly care about, like cache files, .lesshst, .history,
.viminfo, and so forth.

All of the logic is implemented for you in Perl in File::BaseDir, in Rust
in the xdg crate, in Python in python3-xdg, and so forth.

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

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

[Ulrike Uhlig]

Hi!

Thank you for raising this topic!

On 09.09.19 07:56, Ondřej Surý wrote:

> We can discuss (and it has been discussed) ad nauseam, but the point is that 
> nobody (certainly I am not) is asking for crippling DoH, but I just strongly 
> believe it’s in the line with other Debian work that we should not send data 
> to 3rd party DNS service without explicit user consent.

I have a question besides the DOH discussion: How is this technically
done to target "only" US users?

Note: I have not looked up any documentation provided by Mozilla, I was
just wondering.

Cheers!
Ulrike

Common configuration of Debianish build etc. tools

[Ian Jackson]

Hi.

Our rich ecosystem of packaging tools has a large number of
configuration options.  In some cases, different tools need to have
the same option set in the same way.  But we have no common place to
put this information and often not even common terminology.

One example is:
   export-dir (gbp)
   buildresult (pbuilder)
   build-products-dir (dgit)
   build-dir (sbuild)

When one of these tools invokes others, it can sometimes pass down an
option, but unless we are to have a kind of universal wrapper program,
this is not always possible.  (And we have too many wrappers already.)

So, it would be good for there to be a single way to configure these
things.  Every tool ought to look in this single place as well as its
own configuration.

It shouldn't just be an environment variable because that clutters the
environment unnecessarily.  I think it should probably be a config
file in ~, overrideable with an environment variable.  (Or perhaps the
config filename could be overrideable with an environment variable.)

What do people think ?

If this is a good idea then we need to agree on a filename and format.
The format must be easy to parse in a variety of programming languages
including, in particular, shell scripts.  Any suggestions ?

Also there should be a registry document in some package somewhere,
which declares the format and lists the known config keys and their
semantics.

Thanks,
Ian.

PS Note that we are talking here about settings which relate to
personal preferences, or machine-local setup.  Not ones which are
properties of the package and which must therefore be done the same
way by all of a package's maintainers - that latter information must
be elsewhere (in the source package, recorded in salsa, or something.)

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#940039: ITP: ocplib-endian -- optimised functions to read and write int16/32/64

[Stéphane Glondu]

Package: wnpp
Severity: wishlist
Owner: Stéphane Glondu 

* Package name: ocplib-endian
  Version : 1.0
  Upstream Author : Pierre Chambart
* URL : https://github.com/OCamlPro/ocplib-endian
* License : LGPL-2.1
  Programming Lang: OCaml
  Description : optimised functions to read and write int16/32/64

 Optimised functions to read and write int16/32/64 from strings, bytes
 and bigarrays, based on primitives added in version 4.01.
 .
 The library implements three modules:
  * EndianString works directly on strings, and provides submodules
BigEndian and LittleEndian, with their unsafe counter-parts;
  * EndianBytes works directly on bytes, and provides submodules
BigEndian and LittleEndian, with their unsafe counter-parts;
  * EndianBigstring works on bigstrings (Bigarrays of chars), and
provides submodules BigEndian and LittleEndian, with their unsafe
counter-parts.

This package is a new dependency of lwt >= 4.

It will be maintained in ocaml-team.

Bug#940020: ITP: golang-github-gofrs-flock -- thread-safe file locking library in Golang

[Dmitry Smirnov]

Package: wnpp
Severity: wishlist
Owner: Dmitry Smirnov 
X-Debbugs-CC: debian-devel@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org
Control: affects -1 gitlab-ci-multi-runner

   Package name: golang-github-gofrs-flock
Version: 0.7.1
Upstream Author: Tim Heckman
License: BSD-3-Clause
URL: https://github.com/theckman/go-flock
Vcs-Browser: 
https://salsa.debian.org/go-team/packages/golang-github-gofrs-flock
Description: thread-safe file locking library in Golang
 flock implements a thread-safe sync.Locker interface for file locking.
 It also includes a non-blocking TryLock() function to allow locking
 without blocking execution.
 .
 This library is formerly known as "github.com/theckman/go-flock".


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

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

[Andy Simpkins]

On 11/09/2019 06:16, Ingo Jürgensmann wrote:

Am 10.09.2019 um 07:50 schrieb Florian Lohoff :


On Mon, Sep 09, 2019 at 03:31:37PM +0200, Bjørn Mork wrote:

I for one, do trust my ISPs a lot more than I trust Cloudflare or
Google, simply based on the jurisdiction.

There are tons of setups which are fine tuned for latency because they
are behind sat links etc or low bandwidth landlines. They have dns
caches with prefetching to reduce typical resolve latency down to sub
milliseconds although your RTT to google/cloudflare is >1000ms.

Switching from your systems resolver fed by DHCP to DoH in Firefox will
make the resolve latency go from sub ms to multiple seconds as the
HTTP/TLS handshake will take multiple RTT. This will effectively break
ANY setup behind Sat links e.g. for example all cruise ships at
sea.


I can confirm (based on experiences on my day job) that this can be a real 
problem and affecting thousands and hundredthousands of users.

Having the *option* to use DoH is maybe a good idea, but making it the default 
is not.




I appreciate that Mozilla are trying to enhance privacy by introducing 
DoH as an option (but clearly not for children! [0][1]), but are we not 
missing the major point here?  DNS does not belong in the browser


If we wish to deploy DoH (I think it would get my vote) then it should 
be system wide and transparent to applications, using the same methods 
already available.  If every application were to deploy its own resolver 
service then total chaos will ensue.


Yes I know browsers offer alternative resolve / and proxy methods 
already, unfortunately that ship has already sailed. Providing that they 
are turned OFF by default then that is acceptable.  With in-browser DoH 
again, as long as it is OFF by default I don't see an issue.


/Andy

[0] "Respect user choice for opt-in parental controls and disable DoH if 
we detect them" 
https://blog.mozilla.org/futurereleases/2019/09/06/whats-next-in-making-dns-over-https-the-default/


[1] In browser DoH will break a lot of 'parental control / supervisor' 
applications that block traffic based on black & white lists.  IMO this 
is another reason why DoH shouldn't be inside the browser - already 
Mozilla are deploying work arounds for certain use cases...