[13:32] <oruE-htraD> Hey I had an idea for ubuntu, would it be possible to create a program similar to ps home?
[18:32] <int_ua> Was the OMAP3 support dropped?
[18:32] <int_ua> there are no OMAP3 images in the daily cdimages for today
[18:52] <int_ua> Anybody home?...
[19:25] <int_ua> So, someone knows something about OMAP3 support in the 12.04?


[03:28] -queuebot:#ubuntu-release- Unapproved: gnome-logs (zesty-proposed/universe) [3.24.1-0ubuntu1 => 3.24.2-0ubuntu0.1] (ubuntugnome)
[10:41] <apw> slangasek, well even if the kernel i have just promoted would have helped with binutils ... the fact it has now been uploaded again negates any benefit there
[10:41] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (artful-proposed/main) [4.11.0-12.17] (core, kernel)
[10:42] <apw> (i assume)
[10:43] -queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (artful-proposed) [4.11.0-12.17]
[12:28] <apw> slangasek, ok confirmed with adam ... a no change rebuild uploaded for that
[13:00] <xnox> slangasek, i see a lot of s390x: regression but so far they are due to uninstallable test depends, i'm retrying those with all-proposed to see actual failures =/
[13:08] <xnox> retriggered all perl regressions on s390x with the right triggers and all-proposed=1 will check back the status of that.
[13:09] <doko> xnox: hmm, why just s390x?
[13:10] <xnox> "<slangasek> xnox: there appear to be a couple of genuine regressions on s390x autopkgtests with perl 5.26" to find these
[13:11] <xnox> slangasek, also do backdoor runs with all-proposed actually achieve anything w.r.t. britney? as everything still needs to have the right triggers to get the status updated for the right combo, no? or does all-proposed tests update any status of any tests?
[13:12] <xnox> using script from ubuntu-archive-tools i get requests that list _both_ triggers and all-proposed.
[13:39] -queuebot:#ubuntu-release- Unapproved: base-files (xenial-proposed/main) [9.4ubuntu4.4 => 9.4ubuntu4.5] (core)
[13:51] -queuebot:#ubuntu-release- Unapproved: accepted base-files [source] (xenial-proposed) [9.4ubuntu4.5]
[15:29] <xnox> I fixed http://autopkgtest.ubuntu.com/packages/ruby-httpclient =) it failed adt tests because of proxies set in the environment =)
[16:06] <ginggs> anyone have any ideas about eigensoft autopkgtest failure on amd64 http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#openblas ?  Removing autopkgtest-satdep:amd64 because I can't find eigensoft:amd64
[16:10] <nacc> ginggs: have you retried it? i see the one for perl at the same version of eigensoft passed
[16:14] <ginggs> nacc: i have retried it
[16:17] <slangasek> apw: -12 is the kernel we're after for binutils, not -11 :)
[16:19] <slangasek> apw: no change rebuild of the kernel in the archive?  weird :)
[16:19] <slangasek> xnox: you seem to have been looking at something different than I was.  I was talking about the autopkgtest failures shown under perl itself that were s390x-specific
[16:20] <slangasek> xnox: I have already done all the retriggers and there were s390x-specific failures, what I'm looking for here is analysis
[16:21] <slangasek> ginggs: you and me both, then?  The eigensoft autopkgtest is failing because for some reason the runner is failing to find packages that are in multiverse, despite a log file showing that it's downloaded the Packages file
[16:21] <slangasek> eigensoft was not the only example of this, and it's amd64-only
[16:21] <slangasek> Laney: ^^ do you have any insight here?
[16:24] <xnox> slangasek, ah.
[16:24]  * xnox goes to look again
[16:24] <slangasek> xnox: it's also possible that something changed in between my last retry and yours, since now there are zero s390x-specific failures listed <shrug> :)
[16:24] <slangasek> fwiw my approach here has been "work through the pile on perl, to get perl considered as a candidate; then work through the revdeps"
[16:25] <slangasek> we only have "interesting" autopkgtests failing now with the new perl - cacti, and all the databases
[16:25]  * xnox ponders if those have any users
[16:25] <xnox> *giggle*
[16:25] <apw> slangasek, yeah that one was prepped in a -security compatible PPA ie missed binutils ... we need to change our proceedures for queueing uploads for devel specificially
[16:25] <apw> slangasek, so that they are built in a ppa which has -proposed enabled
[16:26] <slangasek> (not counting auto-multiple-choice, which I fixed in -proposed but FTBFS because of TeX; arename, which is currently rerunning; libchi-perl, which I've bugged Debian; libtest-aggregate-perl, which I've just removed)
[16:26] <slangasek> apw: ah indeed
[16:27] <slangasek> xnox: oh, and there are test regressions against systemd; what do we do about those?
[16:28] <slangasek> (I assume systemd/{amd64,i386} will pass against new perl if we just run it with the right version)
[16:28] <xnox> slangasek, it seems to me that boot-smoke is not reliable in containers; thus i should blacklist to run only on full VMs / machines.
[16:28] <xnox> and there is an extra armhf regression which i thought is fixed (because it is fixed on arm64) bot alas that didn't fix it on armhf.
[16:28] <slangasek> xnox: so am I waiting for a new upload of systemd?
[16:29] <nacc> ginggs: hrm, i don't know, sorry
[16:29] <slangasek> nacc: see my reply to ginggs
[16:29] <nacc> slangasek: ah sorry, i missed that!
[16:29] <nacc> slangasek: yeah that does seem like an oddity
[16:30] <xnox> slangasek, si senior
[16:31] <slangasek> xnox: k.  one of the failing revdeps of systemd is unity8 still, so there's also that to drill into
[16:35] <xnox> slangasek, rm pay-service; rm ubuntu-push; rm unity8
[16:35] <xnox> https://bugs.launchpad.net/ubuntu/+source/pay-service/+bug/1707680
[16:38] <xnox> slangasek, full updated with the chain https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1707680
[16:40] <slangasek> xnox, infinity: how is this apt SRU supposed to DTRT when the corresponding unattended-upgrades piece does not appear to have landed in SRU?
[16:41] <slangasek> xnox, infinity: I am concerned that by half-landing we have in fact regressed the distribution of downloads throughout the day
[16:41] <slangasek> which if true is critical and needs reverted
[16:45] <xnox> slangasek, we disucssed this in detail
[16:45] <xnox> slangasek, unattended-upgrades fixes are independant of the apt-timers fixes.
[16:46] <xnox> slangasek, this apt update does the right thing, w.r.t. timers. With current, or future unattended upgrades.
[16:46] <xnox> slangasek, the split of apt-timer into update step and upgrade step is the only critical piece, that the current apt in proposed resolves.
[16:46] <xnox> slangasek, it is critical, as there are affected partners w.r.t. timers.
[16:47] <xnox> there will be unattended-upgrades SRU in the future, which is decoupled from apt SRUs.
[16:50] <slangasek> xnox: ok, have satisfied myself that the unattended-upgrade piece is separate, thanks
[16:52] <slangasek> (what I don't understand is why you need to call unattended-upgrade --download-only at all, if the updates are already being handled in the previous section with 'apt-get -y -d dist-upgrade')
[16:53] <slangasek> xnox: hmmm except I find APT::Periodic::Download-Upgradeable-Packages "0"; in grep: /etc/apt/auth.conf: Permission denied
[16:53] <slangasek> no, not there
[16:53] <slangasek> in /etc/apt/apt.conf.d/10periodic
[16:57] <slangasek> xnox: how did you confirm that updates were actually downloaded when apt-daily.service ran, as opposed to being downloaded at 6am?
[17:12] <xnox> slangasek, i did not check that in my test, because my container was up to date with respect to security updates. Let me downgrade things, to make that happen.
[17:12] <xnox> 1) downgrade package 2) clean caches 3) manually start apt-daily.service 4) verify that it download things
[17:12] <slangasek> xnox: yes please
[17:13] <slangasek> without that check, my reading of the code has me wary that w/o the unattended-upgrades fix we are indeed going to be doing all the downloads at 6
[17:13] <xnox> right, it is tricky, as the code above unatteded-upgrades should do ~= apt-get --download-only
[17:13] <xnox> but not obvious.
[17:14] <slangasek> xnox: yes, that's what the code does, but only if /configured/ to do so, using a flag that is set to 0 by default in apt
[17:15] <slangasek> AFAIK we were not using that code path at all and were only using unattended-upgrades; so now, since the u-u piece hasn't landed, we're a no-op in apt-daily.service and doing all the downloads in apt-daily-upgrade.service (AIUI)
[17:27] <xnox> slangasek, and we would have saved so much time, if we would have assumed that you are right.
[17:28] <xnox> downgraded systemd to release pocket, because there is a systemd in security pocket.
[17:28] <xnox> wiped all the apt periodic timers
[17:28] <xnox> launched apt-daily.service -> it did not download anything
[17:29] <xnox> launchped apt-daily-upgrade.service, no-block, with watch -d over /var/cache/apt/archives/, and noticed how systemd and libsystemd0 got downloaded, (installed), and removed from the cache.
[17:29] <xnox> so yeah, apt lists are downloaded randomly, but the heavy downloads are done at 6am.
[17:30] <xnox> so we really need unattended-upgrades SRU too
[17:34] <xnox> slangasek, it would fix the customer problem, but regress the IS concern.
[17:34] <infinity> The unattended-upgrades --download-only thing is trivial, isn't it?  Can we JFDI?  Or should we revert apt?
[17:35] <xnox> well there is a pending unattended-upgrades SRU from steve
[17:35] <xnox> oh no, that is in updates
[17:35]  * xnox is blind
[17:39] -queuebot:#ubuntu-release- Unapproved: gnome-applets (zesty-proposed/universe) [3.22.0-2ubuntu0.1 => 3.22.0-2ubuntu0.2] (desktop-extra, edubuntu)
[17:42] <xnox> infinity, slangasek: so we would need - https://github.com/mvo5/unattended-upgrades/commit/2e5deed4a3ef77fb0dcc02525eb32ed134b98a91 and https://github.com/mvo5/unattended-upgrades/commit/f26edb4425e488d7acdb825b0b6e8e327d2d51e6
[17:43] <xnox> is that landable? shall I prepare SRUs and test it?
[17:55] <slangasek> xnox: yes to those commits; apt also needs a versioned breaks: against unattended-upgrades
[17:55] <slangasek> infinity: ^^
[18:03] <infinity> slangasek: Cat's out of the bag a bit on the versioned Breaks.  People who already upgraded won't benefit, and the next round of upgrades would bring in unattended-upgrades.
[18:03] <infinity> slangasek: (and it doesn't technically "break" it, just gives you behaviour that's not perfectly ideal)
[18:04] <infinity> slangasek: But we can delete that update right now if you'd prefer it not go out to more people yet.
[18:04] <slangasek> infinity: "the next round of upgrades" - except that people may or may not install all of the updates together, and what if at a later date there's an updated apt in the security pocket
[18:04] <slangasek> infinity: the fact that this is all in -updates rather than -security leaves me confident that we don't need to revert anything if unattended-upgrades will happen ASAP
[18:04] <slangasek> but it does need to be in a coherent state before the point release
[18:05] <infinity> slangasek: Sure, I'm all for pushing out the u-a fix quickly.
[18:05] <xnox> u-a for Apgrades =)
[18:05] <infinity> slangasek: I was arguing that the versioned breaks doesn't buy us much at this point.
[18:06] <slangasek> infinity: yes, it's not a huge benefit and the versioned breaks don't even matter for the point release, but I think we should follow through on it all the same
[18:06] <infinity> xnox: The download-only commits indeed look trivial.  I can haz?
[18:07] <infinity> slangasek: Perhaps.  Though you're then asking for a time bomb on the next apt security update, unless someone copies u-a over there today.
[18:07] <xnox> infinity, sure. but later tonight. I'm like need to go to volleyball in 8minutes.
[18:07] <infinity> xnox: Okay, maybe I'll pick it up, then.  Or get $someone to, so I can do the review.
[18:08] <xnox> infinity, i'll be back in like 3h or so to do it.
[18:09] -queuebot:#ubuntu-release- Unapproved: cloud-init (xenial-proposed/main) [0.7.9-153-g16a7302f-0ubuntu1~16.04.2 => 0.7.9-233-ge586fe35-0ubuntu1~16.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
[18:09] <slangasek> infinity: the alternative would be a time bomb that on the next apt security update, we regress unattended-upgrades behavior again for all the u-u security-only users (i.e. everyone with the default 16.04 config) and spike the load on archive.u.c
[18:10] <infinity> slangasek: Yeah.  I'm not convinced more than 3 users actually run security-only (though, indeed, most people run security-only-automatic, as it were).
[18:10] <slangasek> infinity: millions of cloud instances by default :)
[18:11] <infinity> slangasek: They're the latter, but not the former.
[18:12] <slangasek> right
[18:15] -queuebot:#ubuntu-release- Unapproved: cloud-init (zesty-proposed/main) [0.7.9-153-g16a7302f-0ubuntu1~17.04.2 => 0.7.9-233-ge586fe35-0ubuntu1~17.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
[18:22] <smoser> can someone NACK both of my cloud-init uploads ?
[18:22] <smoser> i want to update the changelogs a bit
[18:24] <jdstrand> infinity: I meay be weird and 1 of the 3, but I've been known to run security only on a machine or two
[18:26] <slangasek> smoser: done
[18:26] -queuebot:#ubuntu-release- Unapproved: rejected cloud-init [source] (zesty-proposed) [0.7.9-233-ge586fe35-0ubuntu1~17.04.1]
[18:27] -queuebot:#ubuntu-release- Unapproved: rejected cloud-init [source] (xenial-proposed) [0.7.9-233-ge586fe35-0ubuntu1~16.04.1]
[18:29] <infinity> jdstrand: You're weird.
[18:29] <slangasek> :)
[18:29] <infinity> jdstrand: I dunno.  mdselaur and I have discussed it many times, usually in the context of "oh, look at that bug that's existed for the last 2 months for anyone who's security-only, and literally zero people reported it".
[18:29] <jdstrand> I never claimed otherwise :P
[18:32] <infinity> jdstrand: And while I'm aware that we have millions of users who don't report bugs, I'd also suspect that the sort of paranoid people who would deliberately choose tha tconfiguration would also have a higher representation in the "users that actually file bugs" cross-section.
[18:32] <jdstrand> I agree it is likely a small number and me as an example is obviously anecdotal
[18:33] <jdstrand> but, I do understand the desire and suspect there are enough to continue to support security only, which was really the only reason I brought it up
[18:34] <jdstrand> obviously I don't have any hard data
[18:34] <infinity> Yeah, we have something close to zero data.
[18:34] <infinity> Which is why we've not brought up the inverse seriously either.
[18:34] <infinity> THough we privately discuss "hey, maybe 18.04 should merge the security and updates pockets".
[18:36] <jdstrand> I suspect Dustin might be able to get something slightly better than anecdotal data for at least UA customers
[18:36]  * jdstrand shrugs
[19:36] -queuebot:#ubuntu-release- Unapproved: unattended-upgrades (xenial-proposed/main) [0.90ubuntu0.6 => 0.90ubuntu0.7] (desktop-core, ubuntu-server)
[19:37] <slangasek> infinity: ^^ unattended-upgrades for review at your convenience
[19:38] <slangasek> xnox: I've also updated the test case to mention the 'manually trigger apt-daily.service' bit, please check that I have expressed this correctly
[19:41] -queuebot:#ubuntu-release- Unapproved: unattended-upgrades (zesty-proposed/main) [0.93.1ubuntu2.2 => 0.93.1ubuntu2.3] (desktop-core, ubuntu-server)
[19:44] -queuebot:#ubuntu-release- Unapproved: linux (artful-proposed/main) [4.11.0-12.18 => 4.11.0-12.18] (core, kernel)
[19:50] <slangasek> xnox: unity8 out.  are we now unblocked wrt the Qt transition?
[19:53] <slangasek> tsimonq2: ^^ are all of the ubuntu-touch qt packages gone that *you're* expecting to see removed in order to unblock Qt?
[20:19] -queuebot:#ubuntu-release- Unapproved: cloud-init (xenial-proposed/main) [0.7.9-153-g16a7302f-0ubuntu1~16.04.2 => 0.7.9-233-ge586fe35-0ubuntu1~16.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
[20:21] -queuebot:#ubuntu-release- Unapproved: cloud-init (zesty-proposed/main) [0.7.9-153-g16a7302f-0ubuntu1~17.04.2 => 0.7.9-233-ge586fe35-0ubuntu1~17.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
[20:42] -queuebot:#ubuntu-release- Unapproved: cloud-init (xenial-proposed/main) [0.7.9-153-g16a7302f-0ubuntu1~16.04.2 => 0.7.9-233-ge586fe35-0ubuntu1~16.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
[20:56] -queuebot:#ubuntu-release- Unapproved: snapcraft (zesty-proposed/universe) [2.31+17.04 => 2.33+17.04] (no packageset)
[20:58] -queuebot:#ubuntu-release- Unapproved: snapcraft (xenial-proposed/universe) [2.31 => 2.33] (no packageset)
[20:59] <sergiusens> infinity: hi. Mind taking a look at those two? ^
[21:07] -queuebot:#ubuntu-release- Unapproved: cloud-init (zesty-proposed/main) [0.7.9-153-g16a7302f-0ubuntu1~17.04.2 => 0.7.9-233-ge586fe35-0ubuntu1~17.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
[22:18] <xnox> slangasek, slight adjustment to the test case #1 remove periodic stamp files #2 after apt-daily.service systemd should be downloaded, but not upgraded. starting apt-daily-upgrade should upgrade it only /without/ downloading.
[22:25] <xnox> slangasek, you have unattended-upgrades in progress are you preparing the srus? /me checks the queue.
[22:26] <xnox> ah, it is.
[22:26] <xnox> looking good.
[22:30] <xnox> uploaded into artful, to fix the bugs there. and to test it there.
[22:30] <xnox> if and when infinity accepts unattended-upgrade i'll test it.
[23:00] <Laney> slangasek: Just want to say that I'm at a conference, so very limited ability to investigate stuff atm
[23:00] <slangasek> Laney: ack (DebConf?)
[23:00] <Laney> suggest trying it locally and seeing if it reproduces (commandline at the top, tweak that)
[23:01] <Laney> if so, then you have somewhere to start from to debug
[23:01] <Laney> no, GUADEC --- but will be at Debconf from Wednesday
[23:01] <slangasek> Laney: I didn't try the exact commandline, but fwiw it seems to only have trouble finding the multiverse packages on amd64, not on other archs... I will have a look though
[23:01] <Laney> yeah, not sure ottomh, sorry :(
[23:01] <slangasek> no worries
[23:02] <slangasek> gcc: error: unrecognized command line option '-mno-red-zone'; did you mean '-fno-regmove'?
[23:02] <slangasek> now, if someone could explain to me why git bisect of ffmpeg on s390x gives me *that* gem... :P
[23:04] <slangasek> mm that may not be the actual failure, n/m
[23:04] <slangasek> anyway, merge commits for git bisect == teh suck
[23:06] <xnox> yeah, people should use nice and linear history.
[23:08] <nacc> heh
[23:26] <xnox> slangasek, more removals https://bugs.launchpad.net/ubuntu/+bugs?field.tag=u8rm those that are trianged are good to go, to help towards removing UOA
[23:26] <xnox> not sure about the Qt5.6 removals.
[23:28] <xnox> i think we will not be able to remove ubuntu-ui-toolkit, until the mir kiosk people drop content-hub.
[23:28] <xnox> Saviq, what's the status around keeping content-hub? and can it be made to not depends on ubuntu-ui-toolkit or some such? (via libertine i think)
[23:29] <xnox> or rather i mean make libertine not depend on content-hub, such that we can remove liberitne.
[23:30] <xnox> looking at https://bugs.launchpad.net/ubuntu/+bugs?field.tag=qt5.6
[23:31] <xnox> i think there are circular dependenices around libertine.
[23:31] <xnox> libertine and content-hub build-depend on each other.


[12:20] <juliank> I'm super confused by ubuntu-release-upgrader in xenial
[12:20] <juliank> the tests are passing on autopkgtest.u.v
[12:20] <juliank> s/v$/c/
[12:20] <juliank> Yet, when running locally for my SRU, pep8 is failing everywhere
[12:20] <juliank> pep8 version is the same though, and most code did not change (just s/http/https)
[12:22] <juliank> I guess I'll just upload it anyway, as something must be going wrong locally
[12:23] <juliank> oh, hmm there are a lot of symlinks
[12:35] <ahasenack> hi, I need some help in interpreting update_output.txt for iptables,
[12:35] <ahasenack> skipped: iptables (86, 158, 16)
[12:35] <ahasenack>     got: 939+0: a-3:a-2:a-922:i-8:p-2:s-2
[12:35] <ahasenack> and a huge list of packages
[12:36] <ahasenack> I checked some packages again, but they all seem to have been built in proposed with the new iptables already
[12:36] <ahasenack> keepalived, miniupnpd, strongswan*
[12:36] <ahasenack> systemd too
[12:38]  * ahasenack checks armhf
[12:38] <ahasenack> hm, not easily done, I don't have access to armhf
[12:43] <ahasenack> ah, found it
[12:43] <ahasenack> iptables-nftables-compat
[12:43] <ahasenack> no that comes from iptables itself
[12:44] <ahasenack> ah, was dropped
[13:02] <ahasenack> it looks line in armhf some of these packages weren't rebuilt at the right time
[14:53] <kfunk> hey ho. just upgraded to 19.10 and I was wondering what the upgrade path re. settings/etc. regarding the Chromium DEB->Snap switch is? -- problem right now: I managed to copy over my original chromium settings dir from ~/.config to ~/snap. but now my saved passwords are gone. running KDE/Plasma Desktop...
[14:53] <kfunk> any idea how to fix this?
[14:54] <kfunk> I guess I'll need to copy over some secret key or sth, but I guess I can't be the only one who got bit by this...
[15:05] <RikMills> kfunk: did you do this? https://discourse.ubuntu.com/t/intent-to-provide-chromium-as-a-snap-only/5987
[15:17] <kfunk> RikMills: that's what I did (after digging a bit through my $HOME), but that didn't "import" my passwords.
[15:17] <kfunk> I guess that Chromium is no longer able to talk to KWallet or sth; as it also mentions a problem with the Plasma Browser Integration host
[15:20] <RikMills> sadly doesn't look like the chromium uploader (oSoMoN) is in here at the moment
[15:20] <kfunk> I'm debugging it a bit, but given Chromium's complexity this isn't going to be fun
[15:34] <kfunk> oh, okay. so a colleague of mine helped. the fix seems to be running: snap connect chromium:password-manager-service :password-manager-service
[15:36] <kfunk> also now found: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1832786
[15:44] <juliank> bdmurray: ^^ about 3 hours ago, I mentioned that I can't get ubuntu-release-upgrader's pep8 check to pass in xenial locally for my SRU
[15:44] <juliank> bdmurray: I'm confused by that, because it seems passing on autopkgtest.u.c
[15:45] <juliank> bdmurray: do you happen to have an idea what's going on there? It seems it's failing on files that are symlinks from python-apt and apt-clone
[15:46]  * juliank could just upload it and then we'll see if it fails there too, but not sure
[15:48] <juliank> Oh, it seems it's running in a built tree, maybe that's a difference
[15:53] <juliank> it's always good to just let problems rest for a few hours and get back to them
[15:54] <juliank> uploaded.
[15:54] <bdmurray> juliank: great, I'm glad I could help ;-)
[19:23] <The_LoudSpeaker> just curious, is there any record of how many ubuntu users are present worldwide? I mean something like ____ number of people actively use ubuntu.
[19:24] <genii> There is no definitive way to establish number of users
[19:25] <The_LoudSpeaker> atleast no of downloads of latest lts ?
[19:25] <The_LoudSpeaker> or 19.04 ?
[19:37] <alkisg> Since 18.10, Ubuntu's initramfs-tools switched to calling dhclient instead of ipconfig. But dhclient-script is broken and generates invalid net-eth0.conf files, calls chown --reference= which isn't supported by busybox etc.
[19:37] <alkisg> I reported this in https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1840965; I can send code if someone's going to commit it; or, if there are thoughts to switch back to ipconfig, then everything will work again...
[21:30] <vorlon> alkisg: we definitely don't want to revert to ipconfig.  Patches certainly welcome
[22:14] <rcj> Could I get someone to nominate tracks on a livecd-rootfs SRU? LP: #1837254  I need disco, bionic, and xenial.
[22:15] <sarnold> rcj: done
[22:15] <rcj> Thank you sarnold
[22:50] <vorlon> cjwatson: for your awareness, /usr/sbin/update-initramfs appears to be broken in the cpc-produced launchpad-buildd chroots https://launchpad.net/ubuntu/+source/diffoscope/121/+build/17428383
[23:12] <mwhudson> oops


[07:55] <Aaron> hello
[07:59] <Aaron> ll
[14:03] <ludovicc> hello, any meeting today?
[14:08] <ttx> ludovicc: in progress in #ubuntu-meeting
[14:08] <ttx> ludovicc: come, quick :)
[14:08] <ttx> <-- Thierry here
[14:09] <ludovicc> ;-)
[14:09] <ludovicc> tx
[22:44] <lordwicho> hi
[22:46] <lordwicho> I have a problem with backtracking, can someone help me
[22:47] <lordwicho> ?
[22:50] <lordwicho> I have to solve this problem and no where to initiate
[22:54] <lordwicho> say the problem..
[22:54] <lordwicho> a dealer wants to make its way in the best possible way, this has a set of sites you must deliver any package and the distance to be traveled from one place to another. must deliver all packages and indicate which was the shortest route
[23:24] <maxb> Err... isn't that the classic "Travelling Salesman" problem, which has been proven impossible to solve for the absolute shortest route in the general case?
[23:25] <maxb> erm, impossible to solve without checking every possible route, I mean


[07:49] <daftykins> mornin'
[07:50] <zmoylan-pi> o/
[07:50] <daftykins> cor, well if this goes to plan i'm going to venture north for a change... i've booked to see The Cranberries in Glasgow
[07:51] <zmoylan-pi> have you packed you english - scottish phrasebook? :-P
[07:52] <daftykins> hahaha
[07:52] <daftykins> i'm still recovering from discovering that whilst our postcodes begin 'GY' theirs appear to be 'G' or 'GI'
[07:54] <zmoylan-pi> https://www.wildernessscotland.com/blog/essential-pocket-phrasebook-scottish-vocabulary/
[07:55] <daftykins> heh i know a few o' those
[08:11] <brobostigon> morning boys and girls.
[08:15] <SuperEngineer> o/
[08:40] <foobarry> are there any good wikis out there that support markdown?
[08:41] <foobarry> (as the main wiki language format or has native support)
[08:45] <foobarry> wikis don't seem to be getting much love nowadays. lots of stale projects out there
[08:48] <SuperMatt> Wikis are *really* easy to write
[08:48] <SuperMatt> you could have one written in python/flask in an afternoon, with full markdown support
[08:55] <foobarry> enterprise ones with privileges and security are harder
[09:03] <zmoylan-pi> 2-3 here mention markdown... https://en.wikipedia.org/wiki/Comparison_of_wiki_software
[09:09] <zmoylan-pi> but it does seem that as wikis have stagnated markdown came along later and is not been implemented in them much
[11:54] <SuperMatt> quiet here today
[11:54] <zmoylan-pi> IS THIS BETTER? :-P
[11:54] <SuperMatt> MUCH
[11:54] <zmoylan-pi> OK
[11:54] <popey> GREAT!
[11:55] <daftykins> someone in another chan said it's so quiet they thought it was Sunday
[11:56] <brobostigon> it is a sunny day, maybe everyone has bunked off work and is in the pub already? lol.
[11:56] <daftykins> :>
[11:56] <zmoylan-pi> it's a monday... people are getting through a weekends worth of idiot emails...
[11:56] <daftykins> noon day cannon went off over on the castle here today, might even have been the first day of the season for it!
[11:57] <popey> BOOOOOOOOOOM!
[11:57] <daftykins> :D punctuated by fog horn today, too
[11:58] <zmoylan-pi> hmmmm, does your lifeboat service their use maroons?
[11:58] <zmoylan-pi> they do here and even 2 miles away i can hear them go off...
[12:07] <SuperEngineer> I think most lifeboat stations still use maroons... beats shit out of mobile phones with flat batteries!
[12:08] <zmoylan-pi> i have seen pagers still in use around dublin so they could use those... months of battery from a single aa...
[12:08] <daftykins> my bad, i wasn't sure what that meant and had swanned off to another channel
[12:10] <SuperEngineer> ...& you only get a flash in the sky from a bang bang.... unless you own a samsung of course ;-)
[12:10] <zmoylan-pi> hmmm, thought they would be in use more... https://en.wikipedia.org/wiki/Maroon_(rocket)
[12:12] <SuperEngineer> daftykins: re "noon day cannon went off": I didn't realise you lived in Gibralta!
[12:12] <daftykins> :> nah just Guernsey
[12:12] <SuperEngineer> ;-)
[12:12] <daftykins> the Queen gets honoured across a good row of cannons too, when the events occur
[12:15] <zmoylan-pi> a lot of cannons dotted around... i pass 2 on walk yesterday... would have been 3 but yacht club seems to have moved their small starting gun
[12:15]  * SuperEngineer is glad is a "good row of cannons" rather than a "naughty set of cannons"
[12:17] <daftykins> :>
[12:22] <SuperEngineer> ooo... just turned firm's tablet on for 1st time in 3 weeks.  It's now doing an Andriod system update....
[12:23] <daftykins> ooh-err
[12:23] <SuperEngineer> ....should have checked battery level first, I suppose...
[12:23] <SuperEngineer> ...could even walk over to the socket and plug it in to charger...
[12:24] <SuperEngineer> but decided on the "fun" option instead! [a.k.a couldn't give a s**t]
[12:26] <daftykins> not one sooty and not one sweep!
[12:26] <SuperEngineer> BOSS: "what d'yu mean the tablet failed during an upgrade and now you can't it on?!"
[12:26] <SuperEngineer> ME: "cba"
[12:27] <zmoylan-pi> the entire office can now gather around and start betting on the outcome of the update... put me down for a fiver on bricks the device :-P
[12:27] <daftykins> ooh bold call
[12:27] <SuperEngineer> I accept your £5 with gratitude
[12:28] <SuperEngineer> [would it help to know I'm signed off work sick?
[12:28] <zmoylan-pi> phew, by the time you collect that will be less than €5 :-P
[12:28] <SuperEngineer> like I said... cba
[12:28] <daftykins> such disdain for office equipment ;_;
[12:29]  * zmoylan-pi takes daftykins red stapler...
[12:29] <SuperEngineer> yup. my bad, me bad
[12:29] <daftykins> uh that'th my red thtapler, thank you...
[12:30] <SuperEngineer> daftykins: quick, grab the selotape and secure it!
[12:30]  * daftykins stretches a couple of metres around zmoylan-pi and the nearest lamp post
[12:31] <SuperEngineer> DAMN! firm's tablet update got to the "optimising aps" stage [or as I call it, "aptimising ops"]
[12:38] <SuperEngineer> zmoylan-pi: you now owe me that fiver. I'll use it for my "couldn't even brick it when trying to brick it" consolation prize ;-)
[12:38] <zmoylan-pi> send an address in pm...
[12:39] <SuperEngineer> grrrrrrr
[12:39] <zmoylan-pi> is that grrrrr road or drive? :-P
[12:40] <SuperEngineer> lol
[15:07] <SuperEngineer> http://www.bbc.com/news/world-europe-39481770
[15:51] <diddledan> daftykins: noon cannon boom combined with horn .. isn't that the "michael bay" sound?
[15:52] <diddledan> https://www.youtube.com/watch?v=c4itJv_DXhI <-- the michael bay sound
[20:08] <m0nkey_> Right, so PornHub is hiring in my city. Product Manager, PHP dev and front-end/js dev. I should totally apply for it.
[21:57] <diddledan> m0nkey_: wow
[22:34] <diddledan> funny people are funny : https://www.dropbox.com/s/dqrdphdwudq557o/Screenshot%202017-04-03%2023.33.36.png?dl=0


[13:58] <swtshoulder> hi can any one tell me if I have to disable my DHCP on my router if I want to use MaaS DHCP server to boot my nodes or my router's DHCP won't have a conflict with MaaS's DHCP?
[15:32] <wojtek_dev__> hi, I got a lot of errors running make test (log: https://gist.githubusercontent.com/skarab7/f764ae115e07ecc395f3/raw/1afa5f9e6459d6051ab87baa39a46ea82523d825/maas_dev_make_test_log) on fresh ubuntu utopic (see https://github.com/skarab7/maas-dev-vagrant-env). I was following the hacking maas page. Did I miss something?
[15:38] <wojtek_dev__> steps I took: https://github.com/skarab7/maas-dev-vagrant-env/blob/master/Vagrantfile#L56
[16:08] <roaksoax> /qu/win 9
[16:29] <blake_r> swtshoulder: you will need to disable your routers DHCP server if you want MAAS to deploy your ndoes
[17:56] <aslaen> Hello, does claim-sticky-ip-address work? It doesn't seem to DHCPREQUEST even after I set it.


[03:06] <elky> Pici: yeah we should probably see what happens. i've not had anything in over a day
[03:07] <elky> Unit193: thoughts?
[06:39] <Unit193> elky: Seems fine to me, depends on if someone is going to be around for a bit to re-set if needed.
[09:29] <bazhang> may68> My Ubuntu got hacked
[09:29] <bazhang> more fun from this one
[09:29] <bazhang> yesterday was wanting to make ubuntu look like windows ten
[09:35] <bazhang> fl00dbuckets> I am going to flood this channel!
[09:35] <bazhang> he never met drone
[10:08] <yofel> who would one need to ask about the server ubottu runs on? Supposedly kubuntu's old bot 'kubotu' ran on that too and I'm wondering if there's any data of that left somewhere.
[10:08] <dax> yofel: Pici
[10:09] <yofel> thanks


[00:04] <smoser> askb, did larsks not respond?
[00:47] <smoser> blackboxsw, https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/324274
[01:21] <askb> smoser, yes ... thanks for the update on the bug!
[01:22] <askb> smoser, so if this is an issue with selinux, then disabling selinux should allow cloud-init to proceed with passwd lock issue correct ?
[01:23] <askb> smoser, I could do another run trying to selinux disabled
[02:19] <smoser> askb, i'd expect that disabled selinux would fix that yes, but the proper fix is to fix your image to have the correct filesystem settings.
[02:22] <askb> smoser, we don't know what is overriding the /etc/shadow permissions, possibly nova-agent which brings up the service
[02:22] <askb> smoser, any issue with the fs settings I may have missed out ?
[14:16] <smoser> o/
[14:19] <sauloaislan> Hi!!
[15:17] <Odd_Bloke> smoser: rharper: How is (ds-identify|cloud-id) run in systemd?  (i.e. how can I work out when in boot it ran?)
[15:17] <rharper> it runs at generator time
[15:18] <rharper> which is prior to any units running (generators help determine if a unit should run or not)
[15:18] <Odd_Bloke> Aha, OK.
[15:18] <Odd_Bloke> So that would (necessarily?) be before some mounts, right?
[15:19] <rharper> so, ds-identify (cloud_id) will write a .unit file in /run/systemd/targets/multiuser.target/wants/cloud-init.target or something like that to indicate that cloud-init units should run
[15:19] <rharper> well, rootfs has to be moutned for systemd to run
[15:19] <Odd_Bloke> It looks like on Softlayer it's running before the config drive mount is in-place, so it isn't detecting ConfigDrive as an option.
[15:19] <rharper> we don't mount config drive
[15:19] <rharper> ConfigDrive checks udev fs labels IIRC
[15:20] <Odd_Bloke> It checks FS labels, but does also check the path if an FS label isn't found.
[15:20] <Odd_Bloke> Because some clouds (e.g., of course, Softlayer) don't present a standard FS label.
[15:21] <rharper> I'm not sure I understand what is different about softlayer's config drive
[15:22] <rharper> cloud_id will check it in the same way we always have;  that said, the config drive device may be *slow*, or *not present* at the time;  which is one of the concerns that smoser raised in the past
[15:22] <Odd_Bloke> So there are two parts to the issue.  Firstly, Softlayer only presents a config drive if metadata is specified for the instance.
[15:22] <Odd_Bloke> So we have to do boot-time determination of the appropriate DS to use.
[15:23] <Odd_Bloke> The second problem is that the config drive doesn't present in a standard way, so ds-identify doesn't recognise it.
[15:24] <rharper> ds choice is between config drive and URL ?
[15:24] <Odd_Bloke> ConfigDrive and NoCloud.
[15:24] <rharper> a cloud using NoCloud
[15:25] <rharper> I suppose this is more bare metally though IIRC
[15:25] <Odd_Bloke> Yep and yep.
[15:26] <rharper> nocloud is present in the filesystem they laydown; that's straight forward, I suppose if you have running instances with the configdrive, we can experiement with ds-identify on such a system
[15:27] <rharper> and expand/update the configdrive detection, or possible introduce a ds_check_softlayer with the differences contained therein
[15:27] <Odd_Bloke> So the code in question is https://git.launchpad.net/cloud-init/tree/tools/ds-identify#n557
[15:27] <Odd_Bloke> 561 onwards is intended to handle this case.
[15:28] <Odd_Bloke> But I'm not sure it ever will anywhere, because of mount ordering.
[15:28] <Odd_Bloke> (Well, except in cases where people are baking config drive data in to their images, but that is not an interesting case. :p)
[15:30] <rharper> mount ordering
[15:30] <rharper> you believe that the device won't be present ?
[15:30] <Odd_Bloke> The device is present, but we check the actual paths.
[15:30] <Odd_Bloke> I believe it won't be mounted.
[15:30] <rharper> it doesn't have to be
[15:30] <Odd_Bloke> 558-560 could be modified to include the Softlayer "METADATA" disk label.
[15:31] <rharper> FS labels are populated via blkid
[15:31] <rharper> https://git.launchpad.net/cloud-init/tree/tools/ds-identify#n183
[15:31] <rharper> so, if the block device is present, and readable, and it has a filesystem label that blkid can detect, it should get listed
[15:31] <Odd_Bloke> Right, agreed.
[15:31] <Odd_Bloke> But that's the first three lines of the function.
[15:31] <Odd_Bloke> I'm talking about the rest of the function. :p
[15:32] <rharper> well, the mount part is not related then
[15:32] <rharper> we find all of the filesystem labels present and check for known config drive labels;  if there is a *new* one for softlayer, then I suppose we should add that
[15:33] <rharper> I see
[15:34] <rharper> the expectation is that it is mounted to /config_drive .
[15:34] <Odd_Bloke> Or /var/lib/cloud/seed/config_drive
[15:34] <rharper> yes, I see; hrm;  I don't know without looking at the code what would mount it there
[15:35] <rharper> in the datasource code, there are some test mount paths
[15:35] <Odd_Bloke> But nothing will be mounted at ds-identify time so the specific location is irrelevant, no?
[15:35] <Odd_Bloke> *nothing other than /
[15:35] <rharper> well, the path that ds-identify checks matters; but if nothing is going to mount it then no it does not matter
[15:35] <rharper> practically
[15:36] <rharper> so
[15:36] <rharper> here's what happens, (Or can);  if the filesystem label is present) then we return that we've found a ConfigDrive and that enables cloud-init to run
[15:36] <rharper> when cloud-init runs, it has code that will do the mount and read the contents
[15:36] <rharper> for config drives
[15:37] <rharper> it's not clear to me why ds-identify also has the same content checks but I suspect there may be some that populate a directory (but do not have a fs lable)
[15:37] <rharper> label)
[15:37] <rharper> smoser: may confirm
[15:38] <rharper> so for softlayer, it should be sufficient that they attach a config drive with the 'config-2' label; and ds-identify will see that from blkid label parsing, and *enable* cloud-init to run later;  when cloud-init runs it will mount and consume the datasource
[15:38] <rharper> if cloud-init isn't running when a config drive is present on softlayer, then we need to examine the filesystem labels that were found
[15:39] <smoser> "METADATA" is kind of garbage
[15:39] <smoser> which is why i've avoided it. its not at all unreasonable for someone to have a block device with a filesystem label of 'METADATA'
[15:40] <Odd_Bloke> rharper: Yeah, the problem is that Softlayer _don't_ present a "config-2" label, they present a "METADATA" label.
[15:40] <rharper> =(
[15:41] <Odd_Bloke> Sorry, I should have been more explicit about that previously.
[15:42] <smoser> so... i think that extending the ConfigDrive to notice 'METADATA' as a valid filesystem label would probably work.
[15:42] <smoser> but i really don't like that without some other piece of identification
[15:43] <smoser> just because its such a generic term.
[15:43] <smoser> if i had to do ConfigDrive again (the openstack implementation) i would have picked os-cfg-2 or something as the label to namespace it some as even 'config-2' is arguably generic
[15:44] <smoser> even if we did etend config drive to support 'METADATA" then we'd still have a wierd situation wehre there were 2 valid datasources.... which should be preferred ?
[15:44] <Odd_Bloke> smoser: NoCloud is always put last, right?
[15:45] <Odd_Bloke> (That's the appropriate ordering on SL.)
[15:45] <smoser> well, in the default list...
[15:45] <smoser> datasource_list: [ NoCloud, ConfigDrive, OpenNebula, DigitalOcean, Azure, AltCloud, OVF, MAAS, GCE, OpenStack, CloudSigma, SmartOS, Bigstep, Ec2, CloudStack, None ]
[15:46] <smoser> but id' really rather not build any (more) dependency on order.
[15:46] <smoser> we're *almost* to a point where these dont have to rely on order.
[15:46] <smoser> Ec2 is the last big one... once it turns strict on, then order doesnt really matter.
[15:47] <smoser> and if i had the option, i think i'd give preference to things in /var/lib/cloud/seed over any other source...
[15:47] <smoser> just because "well, don't put stuff there if you dont want it there."
[15:48] <smoser> it wasn't ever really meant to be a full scale "datasource", but more for testing and such.
[15:48] <Odd_Bloke> If we can work out some way of identifying SL, we could extend check_configdrive_v2 to do 'if SL and METADATA FS label found: yes'.
[15:49] <smoser> yes. i think so.
[15:49] <smoser> thats essentially what we do for brightbox now
[15:49] <smoser> (with ec2)
[15:49] <smoser> i realize we want/need to support softlayer, but i dont want doing so to really screw me later.
[15:50] <Odd_Bloke> Agreed.
[15:50] <smoser> and i'm kind of feeling like we're not in a good situation because of some decisions that were made in the past, and i dont want to make it worse.
[15:50] <Odd_Bloke> smoser: Are you saying that you're worried this path would screw you later, or you're saying that this is our only viable option?
[15:50] <Odd_Bloke> (Or both? >.<)
[15:51] <smoser> if we get a positive identification "running on softlayer", then we're in reasonable shape
[15:51] <smoser> if we don't get one, then there are a whole lot of heuristics that crossing our fingers and hoping for the best.
[15:52] <Odd_Bloke> smoser: Am I right in thinking that you have a script that will harvest a bunch of data that I can pick through?
[15:52] <smoser> well if you look at /run/cloud-init/ds-identify.log you'll see what it collects now
[15:53] <smoser> sudo sh -c 'cd /sys/class/dmi/id && grep -r . *'
[15:53] <smoser> i think they're xen
[15:53] <Odd_Bloke> There isn't any DMI data.
[15:53] <Odd_Bloke> ;.;
[15:53] <smoser> so there might be some stuff in /sys/hypervisor
[15:53] <smoser> but iirc i dont think there was
[15:54] <Odd_Bloke> http://paste.ubuntu.com/24727582/ is what's in there at first-boot.
[15:54] <smoser> disapointed in myself that i didnt grab that info when i had an instance up in bug 1689890
[15:55] <smoser> sudo sh -c 'cd /sys/hypervisor && grep -r . *'
[15:55] <smoser> ^ Odd_Bloke run that
[15:55] <Odd_Bloke> http://paste.ubuntu.com/24727590/
[15:55] <Odd_Bloke> I have a meeting to get to.
[15:55] <Odd_Bloke> So I'll have to pick this up again later.
[15:56] <smoser> ec2 says that their uuid i 'uuid' there will start with 'ec2'
[15:56] <smoser> i'd accept the crappy solution that 'uuid' there will start with '367fb048-'
[15:59] <rharper> didn't realize it was a xen stack
[16:00] <rharper> wonder if we should be doing xenstore-ls on xen platforms
[16:00] <smoser> i'm more willing to take low-chance-of-false-positive solutions like collision on the first 8 chars of a uuid on xen than i am on kvm.
[16:00] <smoser> due to the built in future proofing of xen
[16:00] <rharper> well, if they don't want to control their UUID space, they can inject an arbitrary key into the store
[16:01] <smoser> yeah.
[16:01] <rharper> it would be nice to see what's currently in there
[16:01] <rharper> xenstore-ls
[16:01] <rharper> on softlayer
[16:02] <rharper> do we have a dmesg from one ?
[16:05] <smoser> i dont have one.
[16:06] <smoser> and xenstore-ls (package xenstore-utils) is not in an Ubuntu image by default.
[17:19] <smoser> blackboxsw, https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/324640
[17:19] <smoser> thoughts on my response ?
[17:20] <blackboxsw> sure smoser so what would the main run? Maybe move the tools/cloudconfig-schema functionality into schema.py?
[17:21] <blackboxsw> so argparsing etc?
[17:23] <smoser> thats what i was saying, and then just a small entry point thing in tools/ that is something like:
[17:23] <blackboxsw> I think that's what you meant. Yeah I'll hoist the main out of tools/cloudconfig-schema and into schema.py
[17:23] <smoser>  http://paste.ubuntu.com/24728389/
[17:23] <blackboxsw> opps too late
[17:23] <smoser> yeah, so cloudconfig-schema then ends up being like ^
[17:24] <blackboxsw> yeah makes sense. I might add another unit test or two to handle arg parse behavior etc (as I left tools without coverage as it wasn't officially part of the delivered cloudinit package/modules)
[17:25] <blackboxsw> just put up the azure ds-id from chassis-asset-tag too. https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/324875   and was about to work on SRU templates
[17:25] <blackboxsw> cleaning up the schema right now
[17:28] <smoser> yeah, was reading that now.
[17:58] <Odd_Bloke> rharper: http://paste.ubuntu.com/24728642/
[17:58] <Odd_Bloke> ^ dmesg from SL
[18:01] <Odd_Bloke> smoser: We do actually install xenstore-utils on our SL images.
[18:06] <smoser> Odd_Bloke, doesnt really help. if ds-identify or cloud-init used it... then reasonably we'd have to at least Recommends it.
[18:07] <smoser> fixing CPC provided Ubuntu images is only half a fix. Ubuntu should just work.
[18:08] <smoser> blackboxsw, reviewed chassis-asset-tag
[18:17] <rharper> Odd_Bloke: thanks, I see that xen procfs  ... not sure what that is, but maybe that has some info without using the tools
[18:18] <smoser> Odd_Bloke, can you ssh-import-id ?
[18:18] <smoser> if you have one up.
[18:18] <Odd_Bloke> smoser: rharper: You're both on<EMAIL_ADDRESS>[18:31] <rharper> Odd_Bloke: thanks
[18:32] <rharper> so, xenstore has bios-string options, http://paste.ubuntu.com/24728907/
[18:32] <rharper> it's very possible that they could set Softlayer specific stuff in there that can be read via xenstore-read
[18:32] <rharper>  the whole set of  key/values with this:  xenstore-ls /local/domain/`xenstore-read domid`
[18:34] <rharper> # xenstore-read /local/domain/`xenstore-read domid`/bios-strings/bios-vendor
[18:34] <rharper> Xen
[18:34] <rharper>
[18:41] <smoser> we should write up a "Why we recommend you identify your cloud platform, and how best to do it."
[18:44] <rharper> ack
[18:51] <mak2> Hi !!
[18:52] <mak2> smoser i have problems with cloud-init, this my log http://paste.ubuntu.com/24729092/
[18:53] <mak2> I can not login on vm
[18:55] <mak2> My environment is openstack master i'm  trying perfomer a deploy with de network interface flat and/or neutron (ironic.conf)
[18:58] <blackboxsw> thanks smoser on the asset-tag review just pushed the updates to https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/324640
[18:58] <blackboxsw> and additional unit tests
[19:02] <mak2> smoser this is cloud-init-output.log http://paste.ubuntu.com/24729173/
[19:02] <mak2> Can someone help me?
[19:05] <smoser> mak2, this is 12.04 ?
[19:05] <smoser> 14.04
[19:06] <smoser> mak2, well, your image is configured to search only the Ec2 datasource, but your'e running on openstack
[19:06] <smoser> openstack provides a compatible ec2 metadata service at <IP_ADDRESS>
[19:06] <smoser> so that *should* be ok
[19:07] <smoser> but when cloud-init is trying to read from that url, its getting
[19:07] <smoser> 2017-05-31 18:06:59,187 - url_helper.py[WARNING]: Calling 'http://<IP_ADDRESS>/2009-04-04/meta-data/instance-id' failed [0/120s]: bad status code [500]
[19:07] <smoser> i suspect you can recreate that simply with
[19:07] <smoser> curl 'http://<IP_ADDRESS>/2009-04-04/meta-data/instance-id'
[19:07] <smoser> and i suspect your nova api server has stack traces
[19:07] <mak2> is 14.04
[19:10] <smoser> blackboxsw, i thin i like iut.
[19:10] <smoser> it
[19:10] <smoser> biab
[19:11] <mak2> smoser this comand into VM curl 'http://<IP_ADDRESS>/2009-04-04/meta-data/instance-id'and return 500 Internal Server Error
[19:18] <mak2> smoser nova-placement-api-error.log http://paste.ubuntu.com/24729333/
[19:25] <mak2> why do you know the image is configured to search only the Ec2 datasource?
[19:26] <mak2> smoser ?
[19:30] <smoser> i dont know where you got your image from
[19:30] <smoser> but it has (i think) config in /etc/cloud/cloud.cfg that says datasource_list: ['Ec2', 'None']
[19:31] <mak2> smoser I created the diskimage-builder :D
[19:31] <smoser> in theory that should work, as i said, openstack does provide a ec2 api endpoint.
[19:32] <smoser> but your cloud platform is broken and gives 500 errors when someone tries to access it
[19:32] <smoser> so thats busted
[19:32] <smoser> almost entirely unrelated, but i'd really suggest just using the ubuntu images (http://cloud-images.ubuntu.com/)
[19:33] <smoser> while disk image builder could/should/may work, the cloud-images are official ubuntu output, *and* you dont' have to bother building them.
[19:34] <smoser> my feeling on building your own images is similar to my feelings on building your own glibc, gcc or kernel.
[19:34] <smoser> sure, you can do it. its probably mostly supported, but ... unless you really know why you want to do such a thing, you probably dont want to do such a thing.
[19:34] <smoser> all that make sense ?
[19:35] <smoser> blackboxsw, https://jenkins.ubuntu.com/server/job/cloud-init-ci/nodes=metal-amd64/433/console
[19:35] <smoser> you understand that ?
[19:36] <smoser> (use six.StringIO)
[19:36] <mak2> ahhhhh great I trying using export DIB_CLOUD_INIT_DATASOURCES=OpenStack
[19:38] <blackboxsw> smoser from six import StringIO py3 changed locations used to be io.StringIO in py2
[19:39] <blackboxsw> smoser: I'll put up a trivial
[19:39] <blackboxsw> my bad
[19:39] <blackboxsw> thanks CI :)
[19:39] <smoser> mak2, that said i really suspect that changing the image wont help in any way
[19:39] <smoser> your openstack is busted.
[19:40] <blackboxsw> we probably could/should chanage tests/unittests/helpers.py to avoid the try/ImportError dance on that too
[19:41] <smoser> yeah
[19:41] <mak2> smoser thx :D
[19:43] <smoser> mak2, if you just want to see things fail faster you can use cirros
[19:43] <smoser> i'm pretty sure it'd boot faster and show you this same error
[19:47] <mak2> smoser ok I will try it! :D
[19:48] <blackboxsw> smoser: here's the diff http://paste.ubuntu.com/24729567/   shall I put up another review for it or push to cc-ntp-schema-validation?
[19:48] <blackboxsw> there were no other abuses. just what I had added for the with_logs stuff
[19:52] <smoser> just push is fine.
[19:52] <smoser> what is cStringIO versus StringIO
[19:53] <smoser> >>> import cStringIO
[19:53] <smoser> >>> cStringIO
[19:53] <smoser> <module 'cStringIO' from '/usr/lib64/python2.6/lib-dynload/cStringIO.so'>
[19:53] <smoser> >>> import StringIO
[19:53] <smoser> >>> StringIO
[19:53] <smoser> <module 'StringIO' from '/usr/lib64/python2.6/StringIO.pyc'>
[19:53] <smoser> i guess just performant.
[19:55] <blackboxsw> smoser: pushed
[19:58] <smoser> blackboxsw, https://jenkins.ubuntu.com/server/job/cloud-init-ci/nodes=metal-amd64/434/console
[19:58] <smoser> :?
[19:59] <smoser> that ran against af370e135e8b9873ac8182ab6250aca061b420d1
[20:04] <blackboxsw> smoser:turns out you actually need to add the file
[20:04] <blackboxsw> af370e1..f85cd6c should have it
[20:10] <smoser> k
[20:20] <blackboxsw> meh one more fix.
[20:26] <Odd_Bloke> smoser: cStringIO is StringIO written in C, but with some limitations.
[20:26] <Odd_Bloke> (Historically including problems with UTF-8.)
[20:26] <Odd_Bloke> Which is to say, "it's Python". :p
[20:30] <blackboxsw> :) . smoser ci test runs agree I'm officially done w/ that branch
[20:30] <smoser> \o/
[20:30] <blackboxsw> also officially done w/ the azure  instance
[21:40] <blackboxsw> minor review comments on https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/324677
[21:40] <blackboxsw> and I was seeing merge conflicts when trying to merge w/ trunk
[21:48] <akaris> smoser hi! qq for you - do you know how ubuntu cloud-init handles the presence of multiple default routes? e.g. eth0 has a default route, eth1 has a default route. as the kernel will only accept one default route, do you guys configure PBR or something similar, or are you simply blindly implementing the multiple default routes in the configuration files and have the kernel reject all additional default routes?
[21:51] <akaris> to be more precise:   if I create a neutron network with a router and default route, and a second network with a default gateway as well, and I attach both to an instance .. IMO there are 3 ways to handle this: implement PBR (for the inbound case) and for traffic from the instance outbound "role the dice" ... reject multiple default routes with an error message ... accept multiple default routes but role the dice for the one that wins (which is the fir
[21:51] <akaris> st default rotue that gets configured)


[14:37] -queuebot:#ubuntu-ci-eng- coreycb, https://bileto.ubuntu.com/#/ticket/3076 Dependency wait (bionic/senlin). Failed to build (bionic/manila-ui). Needs rebuild due to higher version at destination (bionic/horizon, bionic/ironic, bionic/manila, bionic/mistral, bionic/python-openstacksdk, bionic/sahara, bionic/watcher)
[14:43] -queuebot:#ubuntu-ci-eng- morphis, https://bileto.ubuntu.com/#/ticket/2162 Needs rebuild due to higher version at destination (zesty/aethercast). Ready to build (/: Failed to update local lp:aethercast cache., xenial/isc-dhcp, zesty/isc-dhcp). Successfully built (xenial/aethercast)
[14:45] -queuebot:#ubuntu-ci-eng- tdaitx, https://bileto.ubuntu.com/#/ticket/2924 Ready to build (/: Failed to update local lp:~tdaitx-bileto/autopkgtest/+git/autopkgtest cache.). Successfully built (zesty/autopkgtest)
[14:50] -queuebot:#ubuntu-ci-eng- tdaitx, https://bileto.ubuntu.com/#/ticket/2930 Needs rebuild due to higher version at destination (artful/autopkgtest). Ready to build (/: Failed to update local lp:~tdaitx-bileto/autopkgtest/+git/autopkgtest cache.)
[14:54] -queuebot:#ubuntu-ci-eng- morphis, https://bileto.ubuntu.com/#/ticket/2393 Failed to build (xenial/aethercast). Needs rebuild due to higher version at destination (zesty/aethercast). Ready to build (/: Failed to update local lp:aethercast cache.)
[14:56] -queuebot:#ubuntu-ci-eng- coreycb, https://bileto.ubuntu.com/#/ticket/3076 Failed to build (bionic/manila-ui, bionic/sahara-dashboard, bionic/senlin). Needs rebuild due to higher version at destination (bionic/horizon, bionic/ironic, bionic/manila, bionic/mistral, bionic/python-openstacksdk, bionic/sahara, bionic/watcher)
[15:03] -queuebot:#ubuntu-ci-eng- morphis, https://bileto.ubuntu.com/#/ticket/2162 Needs rebuild due to higher version at destination (zesty/aethercast). Ready to build (/:, /: Failed to update local lp:aethercast cache., xenial/Failed, xenial/cache., xenial/isc-dhcp, xenial/local, xenial/lp:aethercast, xenial/to, xenial/update, zesty/Failed, zesty/cache., zesty/isc-dhcp, zesty/local, zesty/lp:aethercast, zesty/to, zesty/update). Successfully built (xenial/aethercast)
[15:05] -queuebot:#ubuntu-ci-eng- tdaitx, https://bileto.ubuntu.com/#/ticket/2924 Ready to build (/:, /: Failed to update local lp:~tdaitx-bileto/autopkgtest/+git/autopkgtest cache., zesty/Failed, zesty/cache., zesty/local, zesty/lp:~tdaitx-bileto/autopkgtest/+git/autopkgtest, zesty/to, zesty/update). Successfully built (zesty/autopkgtest)
[15:10] -queuebot:#ubuntu-ci-eng- tdaitx, https://bileto.ubuntu.com/#/ticket/2930 Needs rebuild due to higher version at destination (artful/autopkgtest). Ready to build (/:, /: Failed to update local lp:~tdaitx-bileto/autopkgtest/+git/autopkgtest cache., artful/Failed, artful/cache., artful/local, artful/lp:~tdaitx-bileto/autopkgtest/+git/autopkgtest, artful/to, artful/update)
[15:14] -queuebot:#ubuntu-ci-eng- morphis, https://bileto.ubuntu.com/#/ticket/2393 Failed to build (xenial/aethercast). Needs rebuild due to higher version at destination (zesty/aethercast). Ready to build (/:, /: Failed to update local lp:aethercast cache., xenial/Failed, xenial/cache., xenial/local, xenial/lp:aethercast, xenial/to, xenial/update, zesty/Failed, zesty/cache., zesty/local, zesty/lp:aethercast, zesty/to, zesty/update)
[15:36] -queuebot:#ubuntu-ci-eng- coreycb, https://bileto.ubuntu.com/#/ticket/3076 Diff missing (bionic/senlin). Failed to build (bionic/manila-ui, bionic/sahara-dashboard). Needs rebuild due to higher version at destination (bionic/horizon, bionic/ironic, bionic/manila, bionic/mistral, bionic/python-openstacksdk, bionic/sahara, bionic/watcher)
[15:54] -queuebot:#ubuntu-ci-eng- morphis, https://bileto.ubuntu.com/#/ticket/2393 Failed to build (xenial/aethercast). Needs rebuild due to new commits (zesty/aethercast). Ready to build (/:, xenial/Failed, xenial/cache., xenial/local, xenial/lp:aethercast, xenial/to, xenial/update, zesty/Failed, zesty/cache., zesty/local, zesty/lp:aethercast, zesty/to, zesty/update)
[16:03] -queuebot:#ubuntu-ci-eng- morphis, https://bileto.ubuntu.com/#/ticket/2162 Needs rebuild due to new commits (zesty/aethercast). Ready to build (/:, xenial/Failed, xenial/cache., xenial/isc-dhcp, xenial/local, xenial/lp:aethercast, xenial/to, xenial/update, zesty/Failed, zesty/cache., zesty/isc-dhcp, zesty/local, zesty/lp:aethercast, zesty/to, zesty/update). Successfully built (xenial/aethercast)
[16:05] -queuebot:#ubuntu-ci-eng- tdaitx, https://bileto.ubuntu.com/#/ticket/2924 Ready to build (/:, zesty/Failed, zesty/cache., zesty/local, zesty/lp:~tdaitx-bileto/autopkgtest/+git/autopkgtest, zesty/to, zesty/update). Successfully built (zesty/autopkgtest)
[16:11] -queuebot:#ubuntu-ci-eng- tdaitx, https://bileto.ubuntu.com/#/ticket/2930 Needs rebuild due to new commits (artful/autopkgtest). Ready to build (/:, artful/Failed, artful/cache., artful/local, artful/lp:~tdaitx-bileto/autopkgtest/+git/autopkgtest, artful/to, artful/update)
[16:17] -queuebot:#ubuntu-ci-eng- coreycb, https://bileto.ubuntu.com/#/ticket/3076 Diff missing (bionic/horizon). Failed to build (bionic/manila-ui, bionic/sahara-dashboard). Needs rebuild due to higher version at destination (bionic/ironic, bionic/manila, bionic/mistral, bionic/python-openstacksdk, bionic/sahara, bionic/senlin, bionic/watcher)
[16:57] -queuebot:#ubuntu-ci-eng- coreycb, https://bileto.ubuntu.com/#/ticket/3076 Failed to build (bionic/horizon, bionic/manila-ui, bionic/sahara-dashboard). Needs rebuild due to higher version at destination (bionic/ironic, bionic/manila, bionic/mistral, bionic/python-openstacksdk, bionic/sahara, bionic/senlin, bionic/trove-dashboard, bionic/watcher)
[18:17] -queuebot:#ubuntu-ci-eng- coreycb, https://bileto.ubuntu.com/#/ticket/3076 Failed to build (bionic/manila-ui, bionic/sahara-dashboard). Needs rebuild due to higher version at destination (bionic/ironic, bionic/manila, bionic/mistral, bionic/python-openstacksdk, bionic/sahara, bionic/senlin, bionic/trove-dashboard, bionic/watcher). Pending binary packages (bionic/horizon)
[18:37] -queuebot:#ubuntu-ci-eng- coreycb, https://bileto.ubuntu.com/#/ticket/3076 Diff missing (bionic/horizon). Failed to build (bionic/manila-ui, bionic/sahara-dashboard). Needs rebuild due to higher version at destination (bionic/ironic, bionic/manila, bionic/mistral, bionic/python-openstacksdk, bionic/sahara, bionic/senlin, bionic/trove-dashboard, bionic/watcher)
[18:55] -queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/3074 Proposed pocket (bionic/python-oslo.cache, bionic/python-oslo.db, bionic/python-oslo.i18n, bionic/python-oslo.messaging, bionic/python-oslo.middleware, bionic/python-oslo.policy, bionic/python-oslo.privsep, bionic/python-oslo.serialization, bionic/python-oslo.service, bionic/python-oslo.utils, bionic/python-oslo.versionedobjects). Release pocket (bionic/python-oslo.config, bionic/python-oslo.c
[19:37] -queuebot:#ubuntu-ci-eng- coreycb, https://bileto.ubuntu.com/#/ticket/3076 Diff missing (bionic/horizon). Needs rebuild due to higher version at destination (bionic/ironic, bionic/manila, bionic/mistral, bionic/python-openstacksdk, bionic/sahara, bionic/senlin, bionic/trove-dashboard, bionic/watcher). Pending binary packages (bionic/manila-ui, bionic/sahara-dashboard)
[19:55] -queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/3074 Release pocket
[19:56] -queuebot:#ubuntu-ci-eng- coreycb, https://bileto.ubuntu.com/#/ticket/3076 Needs rebuild due to higher version at destination
[21:49] -queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/3078 Preparing packages
[22:20] -queuebot:#ubuntu-ci-eng- jbicha, https://bileto.ubuntu.com/#/ticket/3078 Successfully built


[22:30] <idnar> I have a bzr / bzr-svn repository that appears to be corrupt: http://pb.codehash.net/husanaug.txt
[22:30] <idnar> should I bother trying to repair it? (and if so, how do I go about doing that?)
[22:36] <PaulePanter> Hi.
[22:36] <PaulePanter> In http://paste.debian.net/250738/ I want to revert to 4826.
[22:37] <PaulePanter> $ bzr checkout -r 4826
[22:37] <PaulePanter> bzr: ERROR: A control directory already exists: "file:///tmp/grub-ahci/".
[22:38] <PaulePanter> Any idea how I can go back to tha revision?