Re: Installation help (libindicator7)

[David Britton]

On Thu, Feb 15, 2018 at 10:44:23AM -0500, Jerome Wiley Segovia wrote:
> Hi,

Hi Jerome!

> 
> I'm having trouble installing *libindicator7*.
> 
> I'm running Ubuntu 16.04 on my local development box and need to install
> Chrome. However, I'm getting a message saying that I have an unmet
> dependency on libappindicator1, which in turn requires libindicator7.

I suspect you are hitting something like this:

https://askubuntu.com/questions/868272/unable-to-install-google-chrome-and-libappindicator1


-- 
David Britton 

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Installation help (libindicator7)

[Jerome Wiley Segovia]

Hi,

I'm having trouble installing *libindicator7*.

I'm running Ubuntu 16.04 on my local development box and need to install
Chrome. However, I'm getting a message saying that I have an unmet
dependency on libappindicator1, which in turn requires libindicator7.

I found your page at https://packages.ubuntu.com/artful/libindicator7, but
wasn't sure what architecture I'm running (I have an i5 processor?) or how
to install this.

Please advise.

Thanks!

Jerome
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Artsy testing

[Helios Martinez Dominguez]

Greetings.

After trying Artsy system, everything seems alright with the exception of
long standing hard disk activity which drops responsive behavior when web
browsing, even just closing the web browser, mouse and keyboard drop
functionality for long standing terms while there should be no connection
between driver's requests, hard disk activity should take a different
interruption request than mouse activity and keyboard activity, and it
probably does, even video memory seems affected as there is no response
from periferials devices, not even to switch between windows, they simply
freeze or slow down heavily. There is deactivation of swap memory (sudo
swapoff --all), web browser is configured with 0 KB cache and no files are
deliveratedly being accessed from any application, there is not any
application loading in memory at the time so unresponsive behavior coming
from hard disk activity seems unjustified. I am running Artsy over an AMD
Dual-Core E-450 with 2 GB RAM, SATA Disk Drive and 100BaseT NIC over 10Mbps
connection.

*Helios Martínez Domínguez*

Director General | Senior Designer.
Consorcio Cooperativo Cinematográfico Artístico Musical (CCCAM).

WORLD CONSTITUTION AND PARLIAMENT ASSOC. (WCPA) MEMBERSHIP.

UNITED NATIONS -- VNU822996

[image: http://cccam.esy.es/] 


helios.url.ph  cccam.esy.es
onu.url.ph


AVISO LEGAL

La información que contiene esta cuenta y este correo es privilegiada,
confidencial, y se encuentra protegida por la Ley.
Su contenido y archivos adjuntos son para uso exclusivo
de los destinatarios arriba mencionados y su emisor.
Cualquier intercepción, acceso, apertura, uso, difusión
o copia no autorizada están estrictamente prohibidas.
En caso de haber recibido su contenido por error u otra circunstancia,
elimínelo
y notifique inmediatamente a las autoridades pertinentes y al propietario
del correo.

Gracias.

Ley_especial_contra_los_delitos_informaticos (Venezuela)


Privacidad y secreto de las telecomunicaciones - Incibe (España)


CONVENTION ON THE PRIVILEDGES AND INMUNITIES OF THE UNITED NATIONS

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: [ubuntu-studio-devel] Artsy testing

[lukefromdc]

There have been long-standing complaints about Linux systems in general becoming
unresponsive when waiting on the hard drive for something. Pretty sure this 
can't be
fixed at the distro level. 

On 2/14/2018 at 10:34 PM, "Helios Martinez Dominguez" 
 wrote:
>
>Greetings.
>
>After trying Artsy system, everything seems alright with the 
>exception of
>long standing hard disk activity which drops responsive behavior 
>when web
>browsing, even just closing the web browser, mouse and keyboard 
>drop
>functionality for long standing terms while there should be no 
>connection
>between driver's requests, hard disk activity should take a 
>different
>interruption request than mouse activity and keyboard activity, 
>and it
>probably does, even video memory seems affected as there is no 
>response
>from periferials devices, not even to switch between windows, they 
>simply
>freeze or slow down heavily. There is deactivation of swap memory 
>(sudo
>swapoff --all), web browser is configured with 0 KB cache and no 
>files are
>deliveratedly being accessed from any application, there is not any
>application loading in memory at the time so unresponsive behavior 
>coming
>from hard disk activity seems unjustified. I am running Artsy over 
>an AMD
>Dual-Core E-450 with 2 GB RAM, SATA Disk Drive and 100BaseT NIC 
>over 10Mbps
>connection.
>
>*Helios Martínez Domínguez*
>
>Director General | Senior Designer.
>Consorcio Cooperativo Cinematográfico Artístico Musical (CCCAM).
>
>WORLD CONSTITUTION AND PARLIAMENT ASSOC. (WCPA) MEMBERSHIP.
>
>UNITED NATIONS -- VNU822996
>
>[image: http://cccam.esy.es/] 
>
>
>
>helios.url.ph  cccam.esy.es
>onu.url.ph
>
>
>AVISO LEGAL
>
>La información que contiene esta cuenta y este correo es 
>privilegiada,
>confidencial, y se encuentra protegida por la Ley.
>Su contenido y archivos adjuntos son para uso exclusivo
>de los destinatarios arriba mencionados y su emisor.
>Cualquier intercepción, acceso, apertura, uso, difusión
>o copia no autorizada están estrictamente prohibidas.
>En caso de haber recibido su contenido por error u otra 
>circunstancia,
>elimínelo
>y notifique inmediatamente a las autoridades pertinentes y al 
>propietario
>del correo.
>
>Gracias.
>
>Ley_especial_contra_los_delitos_informaticos (Venezuela)
>contra-los-delitos-
>informaticos_html/Ley_especial_contra_los_delitos_informaticos.pdf>
>
>Privacidad y secreto de las telecomunicaciones - Incibe (España)
>
>
>CONVENTION ON THE PRIVILEDGES AND INMUNITIES OF THE UNITED NATIONS
>


-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: More diagnostics data from desktop

[Dustin Kirkland]

On Thu, Feb 15, 2018 at 4:16 AM, 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 popcon reports would be continuous though?

The list that Will shared would be a one-time shot, after install,
asynchronously after networking is up on first boot (unless
opted-out).

Popcon would report periodically, and Apport would report crashes
(again, unless opted out).

> If you do this you should really make sure everything has http proxy
> (set in user session only?) support, so you can pick up some extra
> corporate users.

For sure!  Good catch.

> Sending it from the user session fits well with the privacy settings.
>
> Sounds reasonable otherwise. Are trackpads enought trouble to collect data on?

Potentially.  That's the exact sort thing that we need data on, to
help make Ubuntu better :-)

Cheers,
Dustin

> Regards
> //Ernst
>
> 2018-02-14 16:22 GMT+01:00 Will Cooke :
>> 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 more
>> data about sort of setups our users have and which software they are running
>> on it.
>>
>> We would like to add a checkbox to the installer, exact wording TBD, but
>> along the lines of “Send diagnostics information to help improve Ubuntu”.
>> This would be checked by default.
>>
>> The result of having that box checked would be:
>>
>> * Information from the installation would be sent over HTTPS to a service
>> run by Canonical’s IS team.  This would be saved to disk and sent on first
>> boot once there is a network connection.  The file containing this data
>> would be available for the user to inspect.
>>
>> That data would include:
>>* Ubuntu Flavour
>>* Ubuntu Version
>>* Network connectivity or not
>>* CPU family
>>* RAM
>>* Disk(s) size
>>* Screen(s) resolution
>>* GPU vendor and model
>>* OEM Manufacturer
>>* Location (based on the location selection made by the user at install).
>> No IP information would be gathered
>>* Installation duration (time taken)
>>* Auto login enabled or not
>>* Disk layout selected
>>* Third party software selected or not
>>* Download updates during install or not
>>* LivePatch enabled or not
>>
>> * 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.
>>
>> * Apport would be configured to automatically send anonymous crash reports
>> without user interruption.
>>
>> The results of this data would be made public.  E.g. People would be able to
>> see that X% of Ubuntu users are based in .de vs Y% in .za.  Z% of our users
>> run Dell hardware, and so on.
>> The Ubuntu privacy policy would be updated to reflect this change.
>>
>> Any user can simply opt out by unchecking the box, which triggers one simple
>> POST stating, “diagnostics=false”.  There will be a corresponding checkbox
>> in the Privacy panel of GNOME Settings to toggle the state of this.
>>
>> And to reiterate, the service which stores this data would *never* store IP
>> addresses.
>>
>> We value your feedback and comments!
>>
>> Cheers, Will
>> On behalf of the Ubuntu Desktop Team
>>
>>
>> --
>> ubuntu-devel mailing list
>> ubuntu-devel@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
>>
>
> --
> ubuntu-devel mailing list
> ubuntu-devel@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: autopkgtest-build-lxd failing with bionic

[Steve Langasek]

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 / Mail-Followup-To set to exclude
>   ubuntu-devel from this subthread so reviews go to the right place ]

> On Thu, Feb 15, 2018 at 10:28:05AM -0500, Stéphane Graber wrote:
> > […]
> > And confirmed that networking inside both of them works fine here.

> > I wonder if it's a netplan vs ifupdown thing hitting autopkgtest in this 
> > case?

> I can build images: images(!) quite fine here, but when actually using
> them I see these temporary resolution failures most of the time during
> the initial apt-get update.

> I tracked this down to a race condition - basically we try to do the
> `apt-get update' before networking is fully up. (OK, I just saw Julian's
> post which came in while I was writing this and says the same thing...)

> There's a patch attached here which fixes the problem for me. I'm not
> sure if there's a better way to do this - basically it starts
> network-online.target and waits for it to become active, with a timeout.
> Review appreciated.

It's a bit odd to be "start"ing a target in this manner.  Is it even
necessary to start the target, or would it be sufficient to just check
is-active in a loop?

In that case, I would suggest:

timeout=60
while ! lxc exec "$CONTAINER" -- systemctl is-active 
network-online.target \
  && [ $timeout -ge 0 ]
do
timeout=$((timeout - 1))
sleep 1
done
[ $timeout -ge 0 ] || {
echo "Timed out waiting for network to come up" >&2
exit 1
}


-- 
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
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: autopkgtest-build-lxd failing with bionic

[Iain Lane]

[ autopkgtest-devel, this is
  https://lists.ubuntu.com/archives/ubuntu-devel/2018-February/040138.html
  and thread FYI - Reply-To / Mail-Followup-To set to exclude
  ubuntu-devel from this subthread so reviews go to the right place ]

On Thu, Feb 15, 2018 at 10:28:05AM -0500, Stéphane Graber wrote:
> […]
> And confirmed that networking inside both of them works fine here.
> 
> I wonder if it's a netplan vs ifupdown thing hitting autopkgtest in this case?

I can build images: images(!) quite fine here, but when actually using
them I see these temporary resolution failures most of the time during
the initial apt-get update.

I tracked this down to a race condition - basically we try to do the
`apt-get update' before networking is fully up. (OK, I just saw Julian's
post which came in while I was writing this and says the same thing...)

There's a patch attached here which fixes the problem for me. I'm not
sure if there's a better way to do this - basically it starts
network-online.target and waits for it to become active, with a timeout.
Review appreciated.

Cheers,

-- 
Iain Lane  [ i...@orangesquash.org.uk ]
Debian Developer   [ la...@debian.org ]
Ubuntu Developer   [ la...@ubuntu.com ]
From c1924280973123c618fc07762b063abaf64d9d26 Mon Sep 17 00:00:00 2001
From: Iain Lane 
Date: Thu, 15 Feb 2018 16:21:59 +
Subject: [PATCH] lxd: If we're running systemd, wait until the network is up

We execute `apt-get update' more or less as soon as the container is
started. In some situations this is too early: it can be before network
is fully working.

If we have systemd, use network-online.target to wait until it thinks
networking is up.
---
 tools/autopkgtest-build-lxd | 19 ++-
 virt/autopkgtest-virt-lxd   |  2 ++
 2 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/tools/autopkgtest-build-lxd b/tools/autopkgtest-build-lxd
index 623d5eb..9350a81 100755
--- a/tools/autopkgtest-build-lxd
+++ b/tools/autopkgtest-build-lxd
@@ -68,7 +68,7 @@ setup() {
 lxc exec "$CONTAINER" -- chmod 644 /etc/apt/apt.conf.d/01proxy
 fi
 
-# wait until it is booted: lxc exec works and we get a numeric runlevel
+# wait until it is booted: lxc exec works, we get a numeric runlevel and networking is up
 timeout=60
 while [ $timeout -ge 0 ]; do
 timeout=$((timeout - 1))
@@ -81,6 +81,23 @@ setup() {
 exit 1
 }
 
+# only if we're running systemd
+if lxc exec "$CONTAINER" -- test -d /run/systemd/system; then
+lxc exec "$CONTAINER" -- systemctl start network-online.target
+timeout=60
+while [ $timeout -ge 0 ]; do
+timeout=$((timeout - 1))
+if lxc exec "$CONTAINER" -- systemctl is-active network-online.target; then
+break
+fi
+sleep 1
+done
+[ $timeout -ge 0 ] || {
+echo "Timed out waiting for network to come up" >&2
+exit 1
+}
+fi
+
 ARCH=$(lxc exec "$CONTAINER" -- dpkg --print-architecture /dev/null || . /etc/os-release; echo "${NAME% *}"' /dev/null || awk "/^deb/ {sub(/\\[.*\\]/, \"\", \$0); print \$3; quit}" /etc/apt/sources.list' 

signature.asc
Description: PGP signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Ubuntu-devel-discuss Digest, Vol 135, Issue 13

[Technical Clarity]

I hope you reconsider, maybe you like me find irc not the best place to get
or give support anymore. However that doesn't mean they're aren't other
avenues.

On Thu, Feb 15, 2018 at 7:00 AM, <
ubuntu-devel-discuss-requ...@lists.ubuntu.com> wrote:

> Send Ubuntu-devel-discuss mailing list submissions to
> ubuntu-devel-discuss@lists.ubuntu.com
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
> or, via email, send a message with subject or body 'help' to
> ubuntu-devel-discuss-requ...@lists.ubuntu.com
>
> You can reach the person managing the list at
> ubuntu-devel-discuss-ow...@lists.ubuntu.com
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Ubuntu-devel-discuss digest..."
>
>
> Today's Topics:
>
>1. arrivederci (Xen)
>
>
> --
>
> Message: 1
> Date: Wed, 14 Feb 2018 15:35:33 +0100
> From: Xen 
> To: Ubuntu Development Discussion
> 
> Subject: arrivederci
> Message-ID: 
> Content-Type: text/plain; charset=US-ASCII; format=flowed
>
> Hi folks,
>
> I just wanna say goodbye.
>
> I will stop (trying to) contribute to open source.
>
> No more wiki writing, no more patches, no more bug reports.
>
> No more (eventually) trying to get packages into distributions.
>
> For me a sudden turn of events but I have had it with the treatment you
> generally get on IRC.
>
> Even as I was recently spending a lot of time helping out in Ubuntu
> support, even getting appreciated (gasp) for it now and then.
>
> So no hard feelings, I actually feel pretty light now.
>
> Goodbye sometimes means "maybe we meet again" but I don't think it
> should have that feeling to it.
>
> Plenty of people are probably happy to see me go, whatever they think
> "me" means.
>
> So no "sayoonaraba, mata aimashoo", just "sayonara".
>
> See ya.
>
>
>
> --
>
> Subject: Digest Footer
>
> --
> Ubuntu-devel-discuss mailing list
> Ubuntu-devel-discuss@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/ubuntu-devel-discuss
>
>
> --
>
> End of Ubuntu-devel-discuss Digest, Vol 135, Issue 13
> *
>
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: autopkgtest-build-lxd failing with bionic

[Julian Andres Klode]

On Thu, Feb 15, 2018 at 04:10:01PM +0100, Martin Pitt wrote:
> Hello Timo,
> 
> Timo Aaltonen [2018-02-15 16:50 +0200]:
> > On 14.02.2018 22:03, Dimitri John Ledkov wrote:
> > > Hi,
> > > 
> > > I am on bionic and managed to build bionic container for testing using:
> > > 
> > > $ autopkgtest-build-lxd ubuntu-daily:bionic/amd64
> > > 
> > > Note this uses Ubuntu Foundations provided container as the base,
> > > rather than the third-party image that you are using from "images"
> > > remote.
> > > 
> > > Why are you using images: remote?
> > 
> > Because that's what the manpage suggests :)
> 
> Right, and quite deliberately. At least back in "my days", the ubuntu: and
> ubuntu-daily: images had a lot of fat in them which made them both
> unnecessarily slow (extra download time, requires more RAM/disk, etc.) and 
> also
> undesirable for test correctness, as having all of the unnecessary bits
> preinstalled easily hides missing dependencies.
> 
> The latter can be alleviated by purging stuff of course, and that's what
> happens for the cloud VM images in OpenStack:
> 
>   
> https://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/tree/setup-commands/setup-testbed#n242
> 
> But this takes even more time, and so far just hasn't been necessary as the
> images: ones were just right - they contain exactly what a generic container
> image is supposed to contain and are pleasantly small and fast.
> 
> > > Is the failure reproducible with ubuntu-daily:bionic?
> > > 
> > > If you can build images with ubuntu-daily:bionic, then you need to
> > > contact and file an issue with images: remote provider.
> > 
> > ubuntu-daily: works, images: fails for artful and bionic while xenial
> > works, and the image server is:
> > 
> > https://images.linuxcontainers.org/
> 
> These are being advertised and used a lot, so maybe Stephane's LXD team can
> help with fixing these? Them having no network at all sounds like a grave bug
> which should be fixed either way.

That's not what's going on at all. They do have working networking, but the
network does not come up fast enough. The apt update is not retried because
it exits with 0 because all it sees are transient errors.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: autopkgtest-build-lxd failing with bionic

[Stéphane Graber]

On Thu, Feb 15, 2018 at 04:10:01PM +0100, Martin Pitt wrote:
> Hello Timo,
> 
> Timo Aaltonen [2018-02-15 16:50 +0200]:
> > On 14.02.2018 22:03, Dimitri John Ledkov wrote:
> > > Hi,
> > > 
> > > I am on bionic and managed to build bionic container for testing using:
> > > 
> > > $ autopkgtest-build-lxd ubuntu-daily:bionic/amd64
> > > 
> > > Note this uses Ubuntu Foundations provided container as the base,
> > > rather than the third-party image that you are using from "images"
> > > remote.
> > > 
> > > Why are you using images: remote?
> > 
> > Because that's what the manpage suggests :)
> 
> Right, and quite deliberately. At least back in "my days", the ubuntu: and
> ubuntu-daily: images had a lot of fat in them which made them both
> unnecessarily slow (extra download time, requires more RAM/disk, etc.) and 
> also
> undesirable for test correctness, as having all of the unnecessary bits
> preinstalled easily hides missing dependencies.
> 
> The latter can be alleviated by purging stuff of course, and that's what
> happens for the cloud VM images in OpenStack:
> 
>   
> https://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/tree/setup-commands/setup-testbed#n242
> 
> But this takes even more time, and so far just hasn't been necessary as the
> images: ones were just right - they contain exactly what a generic container
> image is supposed to contain and are pleasantly small and fast.
> 
> > > Is the failure reproducible with ubuntu-daily:bionic?
> > > 
> > > If you can build images with ubuntu-daily:bionic, then you need to
> > > contact and file an issue with images: remote provider.
> > 
> > ubuntu-daily: works, images: fails for artful and bionic while xenial
> > works, and the image server is:
> > 
> > https://images.linuxcontainers.org/
> 
> These are being advertised and used a lot, so maybe Stephane's LXD team can
> help with fixing these? Them having no network at all sounds like a grave bug
> which should be fixed either way.
> 
> That said, it could of course be that the setup script just needs some
> adjustments for the netplan changes:
> https://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/tree/setup-commands/setup-testbed
> As this doesn't know about netplan at all, just ifupdown.
> 
> Martin

stgraber@castiana:~$ lxc launch images:ubuntu/bionic/amd64 bionic
Creating bionic
Starting bionic

stgraber@castiana:~$ lxc launch images:ubuntu/artful/amd64 artful
Creating artful
Starting artful

stgraber@castiana:~$ lxc list
+-+-++--++---+
|NAME |  STATE  |  IPV4  | 
IPV6 |TYPE| SNAPSHOTS |
+-+-++--++---+
| artful  | RUNNING | 10.204.119.187 (eth0)  | 
2001:470:b368:4242:216:3eff:fe27:799b (eth0) | PERSISTENT | 0 |
+-+-++--++---+
| bionic  | RUNNING | 10.204.119.248 (eth0)  | 
2001:470:b368:4242:216:3eff:fe8c:7741 (eth0) | PERSISTENT | 0 |
+-+-++--++---+


And confirmed that networking inside both of them works fine here.

I wonder if it's a netplan vs ifupdown thing hitting autopkgtest in this case?

-- 
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com


signature.asc
Description: PGP signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: autopkgtest-build-lxd failing with bionic

[Martin Pitt]

Hello Timo,

Timo Aaltonen [2018-02-15 16:50 +0200]:
> On 14.02.2018 22:03, Dimitri John Ledkov wrote:
> > Hi,
> > 
> > I am on bionic and managed to build bionic container for testing using:
> > 
> > $ autopkgtest-build-lxd ubuntu-daily:bionic/amd64
> > 
> > Note this uses Ubuntu Foundations provided container as the base,
> > rather than the third-party image that you are using from "images"
> > remote.
> > 
> > Why are you using images: remote?
> 
> Because that's what the manpage suggests :)

Right, and quite deliberately. At least back in "my days", the ubuntu: and
ubuntu-daily: images had a lot of fat in them which made them both
unnecessarily slow (extra download time, requires more RAM/disk, etc.) and also
undesirable for test correctness, as having all of the unnecessary bits
preinstalled easily hides missing dependencies.

The latter can be alleviated by purging stuff of course, and that's what
happens for the cloud VM images in OpenStack:

  
https://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/tree/setup-commands/setup-testbed#n242

But this takes even more time, and so far just hasn't been necessary as the
images: ones were just right - they contain exactly what a generic container
image is supposed to contain and are pleasantly small and fast.

> > Is the failure reproducible with ubuntu-daily:bionic?
> > 
> > If you can build images with ubuntu-daily:bionic, then you need to
> > contact and file an issue with images: remote provider.
> 
> ubuntu-daily: works, images: fails for artful and bionic while xenial
> works, and the image server is:
> 
> https://images.linuxcontainers.org/

These are being advertised and used a lot, so maybe Stephane's LXD team can
help with fixing these? Them having no network at all sounds like a grave bug
which should be fixed either way.

That said, it could of course be that the setup script just needs some
adjustments for the netplan changes:
https://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/tree/setup-commands/setup-testbed
As this doesn't know about netplan at all, just ifupdown.

Martin

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: autopkgtest-build-lxd failing with bionic

[Timo Aaltonen]

On 14.02.2018 22:03, Dimitri John Ledkov wrote:
> Hi,
> 
> I am on bionic and managed to build bionic container for testing using:
> 
> $ autopkgtest-build-lxd ubuntu-daily:bionic/amd64
> 
> Note this uses Ubuntu Foundations provided container as the base,
> rather than the third-party image that you are using from "images"
> remote.
> 
> Why are you using images: remote?

Because that's what the manpage suggests :)

> Is the failure reproducible with ubuntu-daily:bionic?
> 
> If you can build images with ubuntu-daily:bionic, then you need to
> contact and file an issue with images: remote provider.

ubuntu-daily: works, images: fails for artful and bionic while xenial
works, and the image server is:

https://images.linuxcontainers.org/




-- 
t

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: More diagnostics data from desktop

[Ernst Sjöstrand]

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 popcon reports would be continuous though?

If you do this you should really make sure everything has http proxy
(set in user session only?) support, so you can pick up some extra
corporate users.
Sending it from the user session fits well with the privacy settings.

Sounds reasonable otherwise. Are trackpads enought trouble to collect data on?

Regards
//Ernst

2018-02-14 16:22 GMT+01:00 Will Cooke :
> 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 more
> data about sort of setups our users have and which software they are running
> on it.
>
> We would like to add a checkbox to the installer, exact wording TBD, but
> along the lines of “Send diagnostics information to help improve Ubuntu”.
> This would be checked by default.
>
> The result of having that box checked would be:
>
> * Information from the installation would be sent over HTTPS to a service
> run by Canonical’s IS team.  This would be saved to disk and sent on first
> boot once there is a network connection.  The file containing this data
> would be available for the user to inspect.
>
> That data would include:
>* Ubuntu Flavour
>* Ubuntu Version
>* Network connectivity or not
>* CPU family
>* RAM
>* Disk(s) size
>* Screen(s) resolution
>* GPU vendor and model
>* OEM Manufacturer
>* Location (based on the location selection made by the user at install).
> No IP information would be gathered
>* Installation duration (time taken)
>* Auto login enabled or not
>* Disk layout selected
>* Third party software selected or not
>* Download updates during install or not
>* LivePatch enabled or not
>
> * 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.
>
> * Apport would be configured to automatically send anonymous crash reports
> without user interruption.
>
> The results of this data would be made public.  E.g. People would be able to
> see that X% of Ubuntu users are based in .de vs Y% in .za.  Z% of our users
> run Dell hardware, and so on.
> The Ubuntu privacy policy would be updated to reflect this change.
>
> Any user can simply opt out by unchecking the box, which triggers one simple
> POST stating, “diagnostics=false”.  There will be a corresponding checkbox
> in the Privacy panel of GNOME Settings to toggle the state of this.
>
> And to reiterate, the service which stores this data would *never* store IP
> addresses.
>
> We value your feedback and comments!
>
> Cheers, Will
> On behalf of the Ubuntu Desktop Team
>
>
> --
> ubuntu-devel mailing list
> ubuntu-devel@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
>

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: merge-o-matic: Filtering for status pages

[David Britton]

Thanks Julian!  This is great.  :)

-- 
David Britton 

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: More diagnostics data from desktop

[Juerg Haefliger]

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
> more data about sort of setups our users have and which software they
> are running on it.
> 
> We would like to add a checkbox to the installer, exact wording TBD, but
> along the lines of “Send diagnostics information to help improve
> Ubuntu”.  This would be checked by default.

Please make this an opt-in rather than an opt-out. This just smells like
a trend towards a Windows/Android installation where you have to unset
gazillions of check boxes to prevent the machine from posting your life
to the vendor. We shouldn't go there.


> The result of having that box checked would be:
> 
> * Information from the installation would be sent over HTTPS to a
> service run by Canonical’s IS team.  This would be saved to disk and
> sent on first boot once there is a network connection.

So sent only once or after every reboot?


> The file
> containing this data would be available for the user to inspect.
> 
> That data would include:
>    * Ubuntu Flavour
>    * Ubuntu Version
>    * Network connectivity or not
>    * CPU family
>    * RAM
>    * Disk(s) size
>    * Screen(s) resolution
>    * GPU vendor and model
>    * OEM Manufacturer
>    * Location (based on the location selection made by the user at
> install).  No IP information would be gathered
>    * Installation duration (time taken)
>    * Auto login enabled or not
>    * Disk layout selected
>    * Third party software selected or not
>    * Download updates during install or not
>    * LivePatch enabled or not
> 
> * 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.

Are you saying that popcon is automatically installed and enabled? I
haven't performed an Ubuntu install lately but isn't there an install
question asking whether to enable popcon or not (with the default being
no). Or is that Debian?


> * Apport would be configured to automatically send anonymous crash
> reports without user interruption.

I hope this will be clearly articulated during install time.


> The results of this data would be made public.

Same here. People need to know that their data is publicly (yet
anonymously) visible.


> E.g. People would be
> able to see that X% of Ubuntu users are based in .de vs Y% in .za.  Z%
> of our users run Dell hardware, and so on.
> The Ubuntu privacy policy would be updated to reflect this change.
> 
> Any user can simply opt out by unchecking the box, which triggers one
> simple POST stating, “diagnostics=false”.

Why does this require a POST (over the network)?


> There will be a corresponding
> checkbox in the Privacy panel of GNOME Settings to toggle the state of this.
> 
> And to reiterate, the service which stores this data would *never* store
> IP addresses.
> 
> We value your feedback and comments!

I don't believe that sending data by default is 'a thing that matters
most to our users'. Quite the opposite in fact. MS was/is getting a lot
of heat for their data collection and we shouldn't go down that very
same route by making data gathering the default.

...Juerg


> Cheers, Will
> On behalf of the Ubuntu Desktop Team
> 
> 
> 



signature.asc
Description: OpenPGP digital signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: More diagnostics data from desktop

[Ian Bruntlett]

Hi Will,

On 14 February 2018 at 15:22, Will Cooke  wrote:

> 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 setups our users have and which software they are
> running on it.
>
> We would like to add a checkbox to the installer, exact wording TBD, but
> along the lines of “Send diagnostics information to help improve Ubuntu”.
> This would be checked by default.
>

Fine by me.I refurbish old donated laptops and PCs and pass them on to
people with mental health problems, their family and carers - this is the
Computer Wombling Project. Enabling the above by default would be a good
idea as quite a few of the end users would struggle to cope with this sort
of thing.

BW,


Ian

-- 
-- ACCU - Professionalism in programming - http://www.accu.org
-- My writing - https://sites.google.com/site/ianbruntlett/
-- Free Software page -
https://sites.google.com/site/ianbruntlett/home/free-software
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: RFC: Ubuntu Seeded Snaps

[Marcos Alano]

IMHO, Snap Store is more like an app store (like Google Play Store),
than a regular package repository (archive.ubuntu.com, a PPA or a
third party repository).
I think some ground rules and some policies are necessary, but we must
avoid burocracy and give freedom to developer, so he/she can create
what he wants. So things like licensing should weaker enforced. The
idea is: think as an app store, not a package repository.

On Fri, Feb 9, 2018 at 2:32 PM, Ross Gammon  wrote:
> On 02/09/2018 12:18 PM, Colin Watson wrote:
>> On Fri, Feb 09, 2018 at 11:20:53AM +0100, Oliver Grawert wrote:
>>> Am Freitag, den 09.02.2018, 09:37 + schrieb Robie Basak:
 Should this be a side effect subject to change of store policy
 (which I think is outside the scope of the Ubuntu project?), or
 should we define "no devmode" as an Ubuntu policy now?
>>> this is an already existing store policy ... if your snap was built
>>> with "confinement: devmode" you can not release it to stable, the store
>>> checks this and blocks. so the "only stable" policy on the ubuntu side
>>> should be enough.
>> Regardless of the question of governance of that policy, there's also
>> the fact that the spec calls for following a per-series channel, for
>> which I don't think a "no devmode" store policy is currently configured.
>>
> Maybe not related to the policy as such, but one thing I have always
> wondered about, but not had the time to investigate (as I have only
> installed one snap deliberately on my system), is the release upgrade path.
>
> When I installed my "one and only" snap, I had to manually remove the
> old deb package manually.
>
> Will this be managed automagically if a flavour chooses a snap in their
> seed rather than the old deb package?
>
> Cheers,
>
> Ross
>
>
>
> --
> ubuntu-devel mailing list
> ubuntu-devel@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel



-- 
Marcos H. Alano
Linux System Administrator
marcoshal...@gmail.com

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: RFC: Ubuntu Seeded Snaps

[Mark Shuttleworth]

On 02/09/2018 11:48 AM, Colin Watson wrote:
> For better or worse, the snap store doesn't have teams. Should this be
> rephrased in terms of collaboration or something? 

Well, I'd rather we set the expectation that the snap store learn to use
LP teams.

Mark

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: More diagnostics data from desktop

[Cassidy James Blaede]

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? Downstreams/non-official-flavors may
want to disable or remove any diagnostics. Keep them in mind when
designing the implementation.
Users are not always installers. Will additional users be prompted of
the diagnostics upon first login? Are these diagnostics intended to be
system-wide or user-wide? If Ubuntu uses GNOME Initial Setup for new
users, that would be a great place for this.
Cassidy
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel