Re: RFC: Ubuntu Seeded Snaps
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
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
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: More diagnostics data from desktop
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
Re: More diagnostics data from desktop
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
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 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. > > So you ask the user during install. Then the data is sent on first > boot. At what point can the user inspect the data, given that some of > it can't be collected until after installation is finished? It seems > like the first opportunity will be after it has been sent, unless you > ask the user a second time. So why not just ask them on first boot, > when you have already gathered all the data? That way user can inspect > the data there and then before deciding how to answer. > Yes, I think the first opportunity would be after it has been sent. I'm generally against asking more questions on login though, I think it would be clunky. We're considering ways to make the tool a stand-alone snap which could be much more interactive and could be installed and run independently of the "Send diagnostics" checkbox. > >* Screen(s) resolution > > This won't be correct after first boot on my system. I have to reboot > at least one more time to install working graphics drivers. > Good point, thanks. We're more interested in general trends than the specifics, so this might skew the data a bit, I think it will work out in the end. -- 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
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
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: autopkgtest-build-lxd failing with bionic
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: autopkgtest-build-lxd failing with bionic
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
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
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
On 15.02.2018 18:04, Julian Andres Klode wrote: > 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. True, I added a 'sleep 10' in front of the apt-get update line, and now it works.. filed a bug: https://bugs.launchpad.net/ubuntu/+source/autopkgtest/+bug/1749736 -- t -- 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
[ 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: autopkgtest-build-lxd failing with bionic
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: More diagnostics data from desktop
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: More diagnostics data from desktop
On Thu, Feb 15, 2018 at 1:10 AM, 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 >> 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? Only once. > >> 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? There is currently no "enable popcon" install question in Ubuntu (maybe there is in Debian)? In Will's proposal, there's a single, simple, clear checkbox, along the lines of "[X] Send diagnostic information", which, if enabled, would: (1) post this initial list of installation options and hardware capability, (2) enable popcon to periodically report lists of installed packages, and (3) enable Apport to post crash reports Declining to send diagnostics, would disable all 3. >> * 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. Indeed. DockerHub does a nice job of making their statistics publicly available, and many, interesting 3rd party tools exist to treat that data. Here, you can see how many times the Ubuntu (or any other) Docker image has been pulled, updated in real time: $ wget -q -O- https://hub.docker.com/v2/repositories/library/ubuntu/ | python -m json.tool >> 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)? Understanding the sample size, as a ratio to the total population, is an essential characteristic in determining statistical validity, and required to draw accurate inferences based on the data. >> 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. I do believe that quality, stability, security, usability, and free availability are what matters most to Ubuntu users. We can drastically improve the quality of Ubuntu through tastefully, anonymously gathered diagnostics. We can significantly improve the stability of Ubuntu by automatically processing crash reports. We can seriously improve the security of Ubuntu by analyzing the package sets most frequently installed and focusing our resources on the software that matters most. Cheers! Dustin > ..
Re: autopkgtest-build-lxd failing with bionic
Hello Iain, all,
Iain Lane [2018-02-15 18:48 +]:
> 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.
I wouldn't pick on any of these: network-online.target is a sloppily defined
shim for SysV init backwards compatibility, and may not ever get started (in
fact, that's the goal ☺); and the container might not use networkd, so I
wouldn't use s-n-wait-online either. I think querying
[ -n "$(ip route show to 0/0)" ]
is asking the question more directly, i. e. "do I have a default route", and is
ignorant of exactly how the network is brought up (by networkd, NM, ifupdown,
or not explicitly at all as the container might share the host's network
namespace).
> 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
I agree that just adding it into this existing polling loop is the right place.
Adding the above default route test here should do nicely?
Also, this polling loop is still using a "runlevel == 2" test, which by now
might get a bit rusty. But I figure that's another story.. :-)
Pitti
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
