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

2017-04-01 Thread Niels Thykier 
Chris Lamb:
> Hi -devel,
> 
> There's a very active conversation happening on Hacker News right
> now entitled «What do you want to see in Ubuntu 17.10?»:
> 
>   https://news.ycombinator.com/item?id=14002821
> 
> I haven't read every comment yet, but are there any feature requests
> that seem particularly relevant to us?
> 
> (As a meta-comment, I was quite struck by the number of requests that
> should "obviously" be requested upstream instead. I wouldn't want to
> label this as "wrong" but I think this might speak to the different
> perception we have towards the upstream → distro → user relationship.)
> 
> 
> Regards,
> 


I noticed one request for binary diffs (I assume a la debdelta) with an
explicit mention of it being upstreamed to Debian[1].

~Niels


[1]

"""
- FLAVOR: Ubuntu Any (preferred this to be in upstream Debian)
- HEADLINE: binary diff updates for apt-get.
- DESCRIPTION:

I have seen Fedora updates as binary diffs. It is very small, uses
less bandwidth and space, and gets installed faster.

This request isn't really for Ubuntu 17.10 though (I don't know if
there is enough time for this). And I don't wish (actually I hate)
this to be an Ubuntu specific feature. I wish this to be an upstream
(Debian) feature.

Thanks
"""

Bug#859291: ITP: r-cran-viridislite -- Default Color Maps from 'matplotlib' (Lite Version)

2017-04-01 Thread Dirk Eddelbuettel 

Package: wnpp
Owner: Dirk Eddelbuettel 
Severity: wishlist

* Package name: r-cran-viridislite
  Version : 0.2.0
  Upstream Author : Simon Garnier
* URL or Web page : 
https://cloud.r-project.org/web/packages/viridisLite/index.html
* License : MIT
  Description : Default Color Maps from 'matplotlib' (Lite Version)

The already-existing fuller-scale package r-cran-viridis now has a
Build-Depends on this ligher version.

It provides color scales from (Python's) matplotlib which are becoming quite
popular.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Convenient access to Debian keyrings

2017-04-01 Thread Sean Whitton 
Hello,

I'd like to ask for tips and ideas to make more convenient use of the
keyrings installed by the debian-keyring package.

Currently, I have mutt pass `--keyring /usr/share/keyrings/...` for each
of the keyrings, so that I can verify signatures on e-mails.  It would
be more natural to just add `keyring /usr/share/keyrings/...` to
~/.gnupg/gpg.conf, but when I tried this I often got errors from gpg
trying to write to the keyrings in /usr/share/keyrings.  Is there some
way to mark a keyring as read-only?

Another issue is that I'd like to mark the keys in the Debian keyrings
as trusted.  The default way of using PGP requires quite short trust
paths in order to consider a key trusted, but since our keyring is
curated, it is much less important for there to exist a short trust path
between my key and a DD's key -- if it's in the keyring, I have very
good reason to believe it really belongs to the person named in the
UID.  Is there some way to mark a whole keyring as trusted?

Thanks!

--
Sean Whitton


signature.asc
Description: PGP signature

Re: Convenient access to Debian keyrings

2017-04-01 Thread gregor herrmann 
On Sat, 01 Apr 2017 15:40:17 -0700, Sean Whitton wrote:

> Currently, I have mutt pass `--keyring /usr/share/keyrings/...` for each
> of the keyrings, so that I can verify signatures on e-mails.  It would
> be more natural to just add `keyring /usr/share/keyrings/...` to
> ~/.gnupg/gpg.conf, but when I tried this I often got errors from gpg
> trying to write to the keyrings in /usr/share/keyrings.  Is there some
> way to mark a keyring as read-only?

I'm using the keyrings from keyring.debian.org instead of the
packaged ones. That way they are up to date and I don't have the
write errors:

% crontab -l | grep debian-keyring
30 17 * * * /usr/bin/rsync -rlptDq 
"keyring.debian.org::keyrings/keyrings/*.gpg" /home/gregoa/.gnupg/debian-keyring

(copied from someone/somewhere)

% grep debian-keyring ~/.gnupg/gpg.conf 
keyring /home/gregoa/.gnupg/debian-keyring/debian-keyring.gpg
keyring /home/gregoa/.gnupg/debian-keyring/debian-maintainers.gpg
keyring /home/gregoa/.gnupg/debian-keyring/debian-nonupload.gpg
keyring /home/gregoa/.gnupg/debian-keyring/debian-role-keys.gpg
keyring /home/gregoa/.gnupg/debian-keyring/emeritus-keyring.gpg


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 of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Status Quo: Caroline


signature.asc
Description: Digital Signature

Re: Convenient access to Debian keyrings

2017-04-01 Thread Paul Wise 
On Sun, Apr 2, 2017 at 7:06 AM, gregor herrmann wrote:

> % crontab -l | grep debian-keyring
> 30 17 * * * /usr/bin/rsync -rlptDq 
> "keyring.debian.org::keyrings/keyrings/*.gpg" 
> /home/gregoa/.gnupg/debian-keyring

The rsync protocol is unencrypted, I'd suggest switching this to SSH
(one colon instead of two). You could also use rsync over TLS on port
1873 (uses the same cert as via http). I couldn't easily work out how
to do it with stunnel but the following works with socat. I thought
there was also a way to verify the keyring when it was at rest but
can't find where I saw that.

rsync --rsh 'sh -c "socat OPENSSL:keyring.debian.org:1873 STDIO"'
keyring.debian.org::keyrings .

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Convenient access to Debian keyrings

2017-04-01 Thread Jonathan McDowell 
On Sun, Apr 02, 2017 at 11:29:22AM +0800, Paul Wise wrote:
> On Sun, Apr 2, 2017 at 7:06 AM, gregor herrmann wrote:
> 
> > % crontab -l | grep debian-keyring
> > 30 17 * * * /usr/bin/rsync -rlptDq 
> > "keyring.debian.org::keyrings/keyrings/*.gpg" 
> > /home/gregoa/.gnupg/debian-keyring
> 
> The rsync protocol is unencrypted, I'd suggest switching this to SSH
> (one colon instead of two). You could also use rsync over TLS on port
> 1873 (uses the same cert as via http). I couldn't easily work out how
> to do it with stunnel but the following works with socat. I thought
> there was also a way to verify the keyring when it was at rest but
> can't find where I saw that.

If you do an rsync of keyring.debian.org::keyrings (no second keyrings/)
you get a sha512sums.txt file as well which will be signed by one of
keyring-maint.

J.

-- 
   Give me liberty or I will cut   |  .''`.  Debian GNU/Linux Developer
   you.| : :' :  Happy to accept PGP signed
   | `. `'   or encrypted mail - RSA
   |   `-key on the keyservers.


signature.asc
Description: Digital signature

Re: Convenient access to Debian keyrings

2017-04-01 Thread Teemu Likonen 
Sean Whitton [2017-04-01 15:40:17-07] wrote:

> Currently, I have mutt pass `--keyring /usr/share/keyrings/...` for each
> of the keyrings, so that I can verify signatures on e-mails.  It would
> be more natural to just add `keyring /usr/share/keyrings/...` to
> ~/.gnupg/gpg.conf, but when I tried this I often got errors from gpg
> trying to write to the keyrings in /usr/share/keyrings.  Is there some
> way to mark a keyring as read-only?

Perhaps --primary-keyring will help because it marks one keyring for use
with key-importing commands. I haven't tried it but it would seem that
all other keyrings are then read-only.

~/.gnupg/gpg.conf:

primary-keyring ~/.gnupg/pubring.kbx
keyring /usr/share/...
keyring /usr/share/...
keyring /usr/share/...


-- 
/// Teemu Likonen   - .-..    //
// PGP: 4E10 55DC 84E9 DFF6 13D7 8557 719D 69D3 2453 9450 ///


signature.asc
Description: PGP signature

Re: Bug#859199: ITP: dh-curl-sudo-bash -- debhelper tools for automated non-packaging

2017-04-01 Thread Dmitry Bogatov 

[2017-03-31 15:48] Adam Borowski 
>
> part   text/plain 975
> On Sat, Apr 01, 2017 at 12:00:35AM +1100, Stuart Prescott wrote:
> > * Package name: dh-curl-sudo-bash
> >   Upstream Author : Lars Wirzenius  and Stuart Prescott 
> > 
> > * URL : http://deb.li/U67E
> >   Description : debhelper tools for automated non-packaging
> >
> > The dh-curl-sudo-bash package provides a build-system method for debhelper
> > that automates the non-packaging of programs for which the preferred form of
> > distribution is the sequence
> >
> > "curl http://example.com/setup.sh | sudo bash -"


> I think you should also convert all https URLs to http, to make sure the
> download works over restrictive firewalls and when the user's connection is
> poorly MitMed.  It would also avoid unexpected FTBFS when a certificate
> expires.

Wait a minute. Is it a joke? Are we going to provide tools to download
code over HTTP and execute it?

-- 
X-Web-Site: https://sinsekvu.github.io | Note that I process my email in batch,
Accept-Languages: eo,ru,en | at most once every 24 hours. If matter
Accept: text/plain, text/x-diff| is urgent, you have my phone number.


pgpfkfQId6OJq.pgp
Description: PGP signature

Re: Bug#859199: ITP: dh-curl-sudo-bash -- debhelper tools for automated non-packaging

2017-04-01 Thread Geert Stappers 
On Sun, Apr 02, 2017 at 08:27:17AM +0300, Dmitry Bogatov wrote:
> [2017-03-31 15:48] Adam Borowski 
> > On Sat, Apr 01, 2017 at 12:00:35AM +1100, Stuart Prescott wrote:
> > > * Package name: dh-curl-sudo-bash
> > > * URL : http://deb.li/U67E
> > >   Description : debhelper tools for automated non-packaging
> > >
> > >
> > > "curl http://example.com/setup.sh | sudo bash -"
> > 
> > I think you should also convert all https URLs to http, to make sure the
> > download works over restrictive firewalls and when the user's connection is
> > poorly MitMed.  It would also avoid unexpected FTBFS when a certificate
> > expires.
> 
> Wait a minute. Is it a joke? Are we going to provide tools to download
> code over HTTP and execute it?

And even execute it with root privilges.

Awareness is never a joke.


echo ZWNobyAiWW91J3ZlIGJlZW4gQXByaWwgRm9vbGVkISIK | base64 -d