Re: More diagnostics data from desktop

2018-02-21 Thread Sven Schwedas
> We want to be able to focus our engineering efforts on the things that > matter most to our users Getting turned into Analytics fodder does not matter to us. That you're too clueless to know what your job is does not matter to us. > This would be checked by default. Please go back to your

Re: More diagnostics data from desktop

2018-02-21 Thread Will Cooke
On 15 February 2018 at 10:16, Ernst Sjöstrand wrote: > Hi, > > "Send diagnostics information to help improve Ubuntu" sounds like > you're continuously reporting things, but your proposal looks more > like a single "installation ping" or something. > I guess the apport and

Re: More diagnostics data from desktop

2018-02-21 Thread Will Cooke
On 19 February 2018 at 13:55, Matthew Paul Thomas wrote: > Will Cooke wrote on 14/02/18 15:22: > >… > > We want to be able to focus our engineering efforts on the things that > > matter most to our users, and in order to do that we need to get some > > more data about sort of

Re: More diagnostics data from desktop

2018-02-21 Thread J Fernyhough
On 15/02/18 10:05, Will Cooke wrote: > On 14 February 2018 at 18:37, Alistair Buxton > wrote: > > > * Information from the installation would be sent over HTTPS to a > service > > run by Canonical’s IS team.  This would be saved to

Re: More diagnostics data from desktop

2018-02-21 Thread Etienne Papegnies
Hello I'm already seeing some blowback from the community, so I'd like to suggest that a few things be made clear. There is three collection methods: 1) Post-Install report; 2) Popcon; and 3) Apport. - It'd be nice to have some insurance that Canonical does not have the ability to match these

Re: More diagnostics data from desktop

2018-02-21 Thread Will Cooke
On 15 February 2018 at 07:10, Juerg Haefliger wrote: > On 02/14/2018 04:22 PM, Will Cooke wrote: > > Dear all, > > > > We want to be able to focus our engineering efforts on the things that > > matter most to our users, and in order to do that we need to get some

Re: autopkgtest-build-lxd failing with bionic

2018-02-21 Thread Ryan Harper
On Thu, Feb 15, 2018 at 2:00 PM, Steve Langasek wrote: > On Thu, Feb 15, 2018 at 06:48:31PM +, Iain Lane wrote: > > [ autopkgtest-devel, this is > > https://lists.ubuntu.com/archives/ubuntu-devel/2018- > February/040138.html > > and thread FYI - Reply-To /

Re: More diagnostics data from desktop

2018-02-21 Thread flocculant
On 14/02/18 16:00, Cassidy James Blaede wrote: ... If Ubuntu uses GNOME Initial Setup for new users, that would be a great place for this. Cassidy That's great if they are only interested in Ubuntu - flavours who might want to see the results of it done via Ubiquity won't be having gnome

Re: More diagnostics data from desktop

2018-02-21 Thread Boris Pek
Hi there, Just a small note about Popcon: > * Popcon would be installed. This will allow us to spot trends in package > usage and help us to focus on the packages which are of most value to our > users. It is absolutely useless until its problems are not fixed. For example:

Re: More diagnostics data from desktop

2018-02-21 Thread Robie Basak
On Tue, Feb 20, 2018 at 11:10:36AM +, Will Cooke wrote: > We were thinking along the lines of something which would try to send the > data at login a number of times, let's say 10, and then give up. Note that if the user has defined a wifi connection that isn't available to all users,

Re: [ergonomy] opening a gif file

2018-02-21 Thread Ralf Meyer
Romain Goffe schrieb am Di., 20. Feb. 2018 um 19:23 Uhr: > Btw, here is the link: > > https://github.com/Javanaise/mrboom-libretro/raw/master/tests/screenshots/mrboom-5.gif > > Best regards, > > Romain > > I appreciate the amount of work you put into this post, BUT

Re: More diagnostics data from desktop

2018-02-21 Thread Will Cooke
Hi Cassidy, On 14 February 2018 at 16:00, Cassidy James Blaede wrote: > This makes sense from Ubuntu's perspective, and it will certainly be > interesting to see the resulting data. I have a few concerns, but nothing > insurmountable: > > How will this affect downstreams?

More diagnostics data from desktop

2018-02-21 Thread Chris Rainey
Great ideas! I've been _manually_ re-enabling these popcon reports at every install(Ubuntu gives me a $free OS and the least I can do is help 'em out w/ some telemetry!) via: $ sudo dpkg-reconfigure popularity-contest As a sys-admin, I do installs regularly and having so many apport notices

Golang Package.

2018-02-21 Thread Mike Lloyd
Hey team. I've noticed the golang package is always several major releases behind. What is the process for getting this package updated? I'd like to help if I can. Mike. Get Outlook for iOS -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com

Re: More diagnostics data from desktop

2018-02-21 Thread Jonty Gamao
Forwarding this because I sent it to the one only for developers From: Jonty Gamao Sent: Wednesday, February 21, 2018 12:32 PM To: ubuntu-de...@lists.ubuntu.com Subject: Re: More diagnostics data from desktop Hi, I noticed in

Re: Golang Package.

2018-02-21 Thread Michael Hudson-Doyle
It's up to date in Bionic. If you want a newer release in an older Ubuntu, there is this PPA: https://launchpad.net/~gophers/+archive/ubuntu/archive or you can use the snap (snap install --classic --channel 1.10/stable go). Cheers, mwh On 22 February 2018 at 11:36, Mike Lloyd

Re: More diagnostics data from desktop

2018-02-21 Thread Matthew Paul Thomas
Will Cooke wrote on 20/02/18 11:10: >… > We were thinking along the lines of something which would try to send > the data at login a number of times, let's say 10, and then give > up.  So if the machine never comes on line, then the data never gets > sent.  If the machine travels between

Re: autopkgtest-build-lxd failing with bionic

2018-02-21 Thread Martin Pitt
Antonio Terceiro [2018-02-21 10:39 -0300]: > > Cheers! I reworked it a bit, applied the same strategy to LXC (which is > > equally affected), tested it, and landed > > > > > > https://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/commit/?id=20f479254 > > Aren't _all_ types of testbed