[06:23] <abeato> jgdx, hey, https://code.launchpad.net/~ken-vandine/libqofono/0.82/+merge/270812 needs approval too for silo 44
[06:23] <abeato> jgdx, also, jenkins integration is failing for https://code.launchpad.net/~ken-vandine/ubuntu-system-settings/availableTechnologies/+merge/270736
[06:27] <jgdx> abeato, I think libqofono is a package upload. Does that restriction still apply?
[06:27] <jgdx> abeato, ci fails due to the new libqofono version, so not much to do there.
[06:28] <abeato> jgdx, hmm, there is a MP so I do not think libqofono is a direct upload
[06:28] <abeato> jgdx, ack about jenkins
[06:37] <abeato> jgdx, anyway, do you mind if I approve libqofono branch to have QA happy?
[06:37] <jgdx> abeato, well, in that case, isn't that mp invalid? It says it drops a patch but I don't see that.
[06:39] <abeato> jgdx, hmm, yeah, that's weird
[06:40] <abeato> jgdx, I guess the patch changed availableTechnologies from upstream to modemTechnologies
[06:40] <abeato> jgdx, which is not necessary anymore
[06:40] <jgdx> abeato, but it's supposed to be in the diff, right?
[06:40] <abeato> jgdx, maybe the patch was a direct upload
[06:41] <abeato> jgdx, the mentioned patch is not in http://bazaar.launchpad.net/~phablet-team/libqofono/ubuntu/files/head:/debian/patches/
[06:42] <abeato> bad... it must have been a direct upload, let me get the source package
[06:46] <abeato> jgdx, the source package contains expose_modem_tech.patch
[06:47] <abeato> jgdx, at the same time there are a couple of patches that are not in the package but appear in the branch: connman-resetcontexts.patch and context-preferred.patch
[06:48] <abeato> jgdx, so basically the MP drops the patch simply by using the bzr branch as the patch is not there
[06:50] <abeato> jgdx, hmm, wait I think I did not download the overlay ppa package; connman-resetcontexts.patch and context-preferred.patch are probably there
[06:58] <abeato> jgdx, in the end I think all is fine: previously libqofono was a direct upload, but kenvandine created last week lp:~phablet-team/libqofono/ubuntu to integrate it with the CI-train I guess
[06:59] <abeato> jgdx, so I think the MP is fine, do you mind if I approve it?
[07:03] <jgdx> abeato, no, but one question, do you have the silo installed?
[07:04] <abeato> jgdx, yep, well, I had to download manually the packages, but installing things manually worked
[07:04] <jgdx> abeato, could you change the radio tech and check the system settings log output? That'd definitely ease my mind
[07:05] <jgdx> abeato, tail -f .cache/upstart/application-legacy-ubuntu-system-settings-.log
[07:05] <abeato> jgdx, sure
[07:08] <abeato> jgdx, no log output, but radio settings does change in ofono, and I see radio detaching and attaching again
[07:09] <jgdx> abeato, +01
[07:10] <jgdx> abeato, approved
[07:10] <abeato> jgdx, cool, thanks
[07:11] <abeato> jgdx, re: the jenkins failure, the build fails because the package dependency is in the PPA and jenkins does not get packages from there? just curious
[07:13] <jgdx> abeato, right, libqofono-0.82 is only in the silo ppa and the tests are run using rc-proposed (vivid+overlay).
[07:13] <jgdx> we really would like to be able to disable CI for these branches and instead run it against the silo.
[07:14] <abeato> jgdx, I see, thanks
[07:22] <Mirv> ogra_: sil2100: a core dev would be apparently needed to publish 035 https://ci-train.ubuntu.com/job/ubuntu-landing-035-2-publish/20/ - it seems train failed to do the diff, and therefore falls back to requiring a core dev for publishing (packaging changes or not)
[07:25] <robru> Mirv: source packages always require core dev even without diff.
[07:25] <robru> And man, i really gotta fix oxide diffing
[07:27] <robru> Mirv: the reason oxide fails is because the diff always ends up being several GB and the current diffing algo we use tries to have it all in memory at once, so it OOMs and then catches the error or something. There's a bug somewhere saying not to diff in memory
[07:28] <sil2100> Yeah, we had constant issues with publishing oxide
[07:30] <robru> It boggles my mind how oxide functions as a project with diffs that huge. Last time we successfully diffed it it was like 3.5GBs.
[07:30] <sil2100> The diff is really small this time anyway, so we can use the LP one instead: https://launchpadlibrarian.net/216837188/oxide-qt_1.9.1-0ubuntu<IP_ADDRESS>_1.9.2-0ubuntu<IP_ADDRESS>.diff.gz
[07:31] <Mirv> robru: oh, I thought I was still able to publish main packages if there are no packaging changes. that explains.
[07:31] <robru> Mirv: nah you can only publish if it's an MP and there's no packaging changes.
[07:31] <sil2100> ogra_: you have a moment to publish landing https://ci-train.ubuntu.com/job/ubuntu-landing-035-2-publish ? The changes are here: https://launchpadlibrarian.net/216837188/oxide-qt_1.9.1-0ubuntu<IP_ADDRESS>_1.9.2-0ubuntu<IP_ADDRESS>.diff.gz
[07:34] <robru> sil2100: is that the full diff? Why the hell didn't the train get that? Wtf?
[07:36] <sil2100> That's the full diff alright, still... even getting such a small diff by diffing two huge sources might cause trouble on the train machine or something
[07:37] <sil2100> robru: you! Go rest! It's unhealthy to use your holidays for work ;)
[07:37] <robru> sil2100: Hmmmmmmm but i thought i shelled out to make the diff and then only kept the diff in memory. It surely doesn't put the whole project in memory to do the diff...
[07:38] <robru> sil2100: OK OK I'm going ;-)
[07:51] <mardy> my root partition on the Nexus 4 is full, and I've just reflashed my phone yesterday (wily, devel-proposed). Any tricks to free some space?
[08:05] <Mirv> mardy: flash with --wipe?
[08:05] <Mirv> mardy: if that already done, maybe --bootstrap --wipe
[08:06] <Mirv> wipe should probably do what it says already
[08:06] <sil2100> There's not much difference between --bootstrap and --wipe, both do the same thing but in different ways IIRC
[08:08] <mardy> Mirv, sil2100: is there a way to flash the phone which completely resets the / to its original state, but keeps /home untouched?
[08:10] <mardy> sil2100: and another unrelated question about "wily" being skipped: does it mean that the 15.10 framework will be skipped too? Or will it come via the vivid + overlay channel?
[08:11] <sil2100> mardy: I don't think we have an easy way for doing that, I think the best way is to tar up /home and then do a wipe/bootstrap flash
[08:13] <sil2100> mardy: and for the framework - we'll be shipping it in our vivid overlay, we already have it there actually
[08:13] <sil2100> Rationale here:
[08:13] <sil2100> https://bugs.launchpad.net/ubuntu/+source/click/+bug/1456328
[08:13] <sil2100> Not released on stable phones yet though
[08:24] <Mirv> sil2100: I think the last --bootstrap changed my device id. but I also had a screen "this device needs to be brought to service center" or something so maybe it did something super extra. I hadn't seen that screen before.
[08:26] <sil2100> huh
[08:30] <ogra_> sil2100, did the publishing happen already ?
[08:32] <ogra_> ah, your link was just to short ... Mirv's is better :)
[08:33] <ogra_> done
[08:43] <sil2100> ogra_: eeek, ok, irssi cut it up
[08:43] <sil2100> Thanks!
[09:18] <abeato> rvr, hey, the branches for silo 44 are approved now
[09:19] <rvr> abeato: Cool
[09:24] <Mirv> 20 builds and weeks of autopilot later I'm wiser, but not exactly closer to landing anything...
[09:50] <rvr> morphis: ping
[10:04] <morphis> rvr: ping
[10:20] <rvr> morphis: I have a problem installing silo 22
[10:20] <rvr> morphis: Setting up bluez (4.101+15.04.20150914.2-0ubuntu1) ...
[10:20] <rvr> morphis: And stops there
[10:21] <morphis> rvr: ah
[10:21] <rvr> morphis: How did you install it?
[10:21] <morphis> http://paste.ubuntu.com/12416639/
[10:21] <morphis> it tries to restart the services on install which doesn't work
[10:22] <morphis> as that conflicts a bit with the android container for bluetooth
[10:22] <morphis> rvr: so either you pull http://paste.ubuntu.com/12416639/ and save that as citrain
[10:22] <morphis> then use it as normal to install the silo
[10:23] <morphis> or you do manually a echo "exit 101" | sudo -A tee /usr/sbin/policy-rc.d
[10:23] <morphis> before you install the silo
[10:23] <morphis> have a go a MP out against the citrain tool to fix that
[10:24] <rvr> Ok, let me see
[10:25] <abeato> sil2100, hi, I'd like to seed package gstreamer1.0-plugins-ugly-amr into the phone images (see bug #1386553)
[10:25] <abeato> sil2100, which steps should I follow?
[10:25] <sil2100> abeato: hey! Let me take a look at the bug first
[10:25] <abeato> sil2100, ok
[10:26] <davmor2> morphis: just to confirm bt is working on reboots
[10:27] <morphis> davmor2: ?
[10:28] <davmor2> morphis: you wanted confirmation that a connected device would reconnect on a reboot it does, I think in the end you realised it was an issue with you config, but I said I'd look for you and confirm if it worked or not :)
[10:28] <morphis> ah right
[10:28] <morphis> thanks!
[10:36] <rvr> morphis: The bash script doesn't work
[10:36] <morphis> ?
[10:36] <rvr> morphis: /bin/sh: 0: Illegal option -
[10:37] <morphis> rvr: you're running the script from your PC?
[10:37] <rvr> morphis: citrain works on the PC, yes
[10:39] <morphis> rvr: which arguments are you using?
[10:39] <michi> robru: Getting strange failure with silo 10: https://ci-train.ubuntu.com/job/ubuntu-landing-010-1-build/226/console
[10:39] <rvr> morphis: citrain.sh device-upgrade <silo> <password>
[10:40] <michi> + su -p pbuser -c './debian/rules clean'
[10:40] <michi> make: dh: Command not found
[10:40] <michi> make: *** [clean] Error 127
[10:40] <morphis> rvr: to make sure there is no copy-error: wget http://file.gravedo.de/citrain && chmod +x citrain
[10:41] <rvr> morphis: ERROR 404: Not Found.
[10:41] <morphis> ah sorry .. wget http://files.gravedo.de/citrain
[10:43] <sil2100> michi: robru is on holidays right now ;)
[10:44] <ogra_> michi, is you package missin a build-dep on debhelper perhaps ? :)
[10:45] <sil2100> michi: did your package in this state build before in the train?
[10:46] <michi> sil2100: Yes, it built just a few days ago.
[10:46] <michi> This is brand new.
[10:46] <michi> I don’t think this has anything to do with what I did?
[10:46] <michi> Hmmm...
[10:46] <michi> I’m using an absolutely minimal control file.
[10:47] <michi> Because the real control file is generated.
[10:47] <michi> But that works fine with bzr bd.
[10:47] <sil2100> michi: did you change anything in the packaging since the last time it built? I just want to first get the baseline here
[10:47] <morphis> rvr: https://code.launchpad.net/~morphis/phablet-tools/citrain-changes/+merge/271094
[10:47] <michi> sil2100: ...
[10:47] <michi> OK, I think I might know.
[10:47] <michi> Which package is dh in?
[10:47] <michi> debhelper?
[10:47] <sil2100> Yes
[10:47] <michi> Hmmm… I left that as the only build-dep.
[10:48] <michi> Basically, I reduced the dummy control file to the bare bones, so no-one would mistake it for the real thing.
[10:48] <michi> As part of that, I removed all build-deps except for debhelper.
[10:48] <michi> I wonder whether there is something else I should have left in place.
[10:48] <rvr> morphis: Nice, the one hosted in your website works :)
[10:48] <morphis> rvr: very good :)
[10:48] <michi> AARGH!
[10:48] <michi> I removed debhelper.
[10:48] <michi> Mea culpa.
[10:49] <michi> My apologies for the noise.
[10:49] <sil2100> michi: interesting that it's not really installing debhelper to build the source package
[10:49] <sil2100> heh
[10:49] <sil2100> Yeah
[10:49] <sil2100> No worries ;)
[10:49] <michi> Apparently, unless you have an explicit build dep, debhelper isn’t installed.
[10:50] <rvr> morphis: It's important to add any relevant installation information to silos
[10:53] <rvr> morphis: Ok, bluetooth seems to be working, approving 22
[10:53] <morphis> rvr: thanks!
[10:53] <morphis> rvr: will add that bit next time
[10:53] <rvr> morphis: Thanks :)
[10:53] <michi> ogra_: Thanks, yes, well spotted! :)
[10:54] <michi> sil2100, ogra_: Amazing how much difference one little line can make :)
[11:00] <ogra_> :D
[11:36] <greyback> trainguards: hey, I'm in silo27, I'm trying to dual-land qtubuntu-gles. Train seems to have only built the vivid+overlay package however. Any ideas?
[11:37] <sil2100> greyback: hey, let me take a quick look
[11:39] <sil2100> hm, looks like the wily source package was built at least, let me see why it didn't reach the PPA
[11:40] <sil2100> Ah, wait, I might have an idea
[11:51] <sil2100> greyback: interesting
[11:52] <greyback> :)
[11:54] <sil2100> greyback: I think I see the problem, but I wonder if this somehow worked before - do you know if you were dual landing qtubuntu with qtubuntu-gles previously?
[11:54] <sil2100> greyback: so I think the issue is this:
[11:55] <greyback> sil2100: honestly I don't think so.
[11:55] <sil2100> https://code.launchpad.net/~mir-team/qtubuntu/gles-sync/+merge/269178 <- this is the -gles sync merge, right?
[11:55] <greyback> but I didn't see any obvious reason why isn't not possible
[11:55] <greyback> sil2100: yeah
[11:55] <sil2100> It is possible, but it needs to be done a bit differently :)
[11:55] <greyback> ok, lead on!
[11:56] <sil2100> So how dual landings work - they take the selected merge proposal, build a source package of it for wily (the main series) and then the train copies that, re-versions the wily source package to vivid and uploads both to the PPA
[11:56] <sil2100> This implies that the original merge needs to target the wily branches
[11:57] <sil2100> Now, what happens here - the mp for the -gles sync actually targets vivid, as you can see the version number is 0.62+15.04.20150914-0ubuntu1 instead of 0.62+15.10.20150914-0ubuntu1 (15.04 vs 15.10)
[11:58] <greyback> yep, so I should retarget it to wily?
[11:58] <sil2100> So the train built that, created the 0.62+15.04.20150914-0ubuntu1 source package targetting wily (!), then copied it and wanted to reversion to vivid (which was a noop), so it overwritten the wily versions
[11:58] <sil2100> Yeah
[11:58] <sil2100> Just change the MP to have the wily version
[11:58] <sil2100> 0.62+15.10.20150914-0ubuntu1
[11:58] <sil2100> And I suppose this should help
[11:58] <sil2100> (if my understanding is correct)
[11:59] <greyback> ok, trying
[12:26] <pstolowski> robru, kenvandine hey guys, michi made some tweaks to the MP in silo 10 and also commented on the last NACK, can you give it another look?
[12:27] <michi> pstolowski: robru is on vacation.
[12:28] <Mirv> pstolowski: michi: there are no common files, but I believe what was wanted is that upon upgrade the no-longer-built-from-any-source-package binary packages would get removed from the systems via conflicts
[12:28] <michi> kenvandine: James and I discussed this at length. We don’t think there is any need for a Conflicts or Replaces entry for the Qt library because there are no binaries that are common.
[12:28] <michi> Mirv: Hmmm...
[12:28] <michi> So, if the Conflicts entry is missing, the old lib won’t be removed?
[12:28] <Mirv> or at least ken is saying "for the binaries that landed in wily that aren't built anymore"
[12:29] <michi> I really don’t know what he means there.
[12:29] <Mirv> yes, people will have the old libraries infinitely
[12:29] <michi> We are using Replaces/Conflicts for unity-scopes-api because that package installs executables, such as the scoperegistry
[12:29] <michi> OK.
[12:29] <michi> Can you help me here?
[12:30] <michi> What is the difference between Conflicts and Replaces when it comes to upgrading/uninstalling?
[12:31] <Mirv> michi: Conflicts = can't be installed at the same time, remove the other one. Replaces = allow the fact that there are identical files in two packages, ie don't fail even if the other package wasn't yet completely uninstalled. I don't see why Replaces would be needed here though if all the file paths are different.
[12:32] <michi> For the Qt lib, there are no common file paths.
[12:32] <Mirv> https://www.debian.org/doc/debian-policy/ch-relationships.html#s-conflicts
[12:32] <michi> And both old and new can be installed at the same time, as far as the Qt lib package is concerned.
[12:32] <michi> Although, they may well have conflicting prereqs.
[12:33] <michi> Thanks for the link!
[12:33] <michi> So, I don’t really mind.
[12:33] <michi> I can add a Conflicts entry, a Replaces entry, or both.
[12:33] <morphis> Mirv: can you publish https://requests.ci-train.ubuntu.com/#/ticket/314 ?
[12:33] <michi> But I honestly don’t know which one is right.
[12:33] <michi> All three options are equally easy to do.
[12:34] <Mirv> michi: I believe the correct thing would be Breaks: only :) not Replaces, and using Breaks since both can be unpacked at the same time (no same file paths)
[12:35] <Mirv> so Breaks: oldbinarypackagenamethatisnolongerinarchivesafterthissourceversion
[12:35] <michi> Checking the debian bible…
[12:35] <Mirv> yeah, me too... always takes a couple of re-readings..
[12:36] <michi> Mirv: “Normally, Breaks should be used in conjunction with Replaces.”
[12:37] <Mirv> and Breaks should be used "when moving a file from one package to another"
[12:37] <michi> Mirv: Section 76.1
[12:38] <michi> Mirv: Hmmm… Sounds like Breaks: is right.
[12:38] <michi> But does it need a Replaces: or not?
[12:38] <Mirv> michi: my interpretation would be that Conflicts + Replaces is a poor man's replacement for what should be usually Breaks :)
[12:39] <michi> Aha.
[12:39] <Mirv> only if some files are getting overwritten, Replaces would be needed (as it reads in 7.3)
[12:39] <michi> So, sounds like I should be adding a Breaks: entry then for the Qt lib
[12:39] <michi> Chapter and verse…
[12:40] <Mirv> morphis: probably not, as it has packaging changes. but I'll try
[12:40] <morphis> Mirv: what extra work would it need then?
[12:40] <Mirv> morphis: it'll need us to ping a core-dev to run the publishing job
[12:41] <Mirv> like... ogra_, please, https://ci-train.ubuntu.com/job/ubuntu-landing-022-2-publish/35/
[12:41] <morphis> interesting
[12:42] <Mirv> this changed a week/two ago, we can't anymore just verbally ask for an ack from a core-dev, the core-dev needs to run the publish job
[12:43] <morphis> ah I see
[12:43] <michi> Mirv: Thanks for your help. I’ll have another go at this tomorrow. It’s late here, and I’m too tired to make changes now without making a mistake.
[12:43] <michi> Another day, another chance…
[12:46] <ogra_> morphis, Mirv, done ...
[12:46] <morphis> ogra_: thanks!
[12:47] <sil2100> renatu: ping
[12:48] <sil2100> renatu: hey! The indicator-transfer landing that introduced indicator-transfer-download-manager - did that land already?
[12:51] <cjwatson> Mirv,michi: if it's just a library soname change, you should normally have none of Conflicts/Breaks/Replaces.  why is Breaks required here?
[12:52] <cjwatson> and no, Conflicts+Replaces is not a "poor man's replacement" for Breaks; that has a different purpose.
[12:52] <michi> cjwatson: I honestly don’t know.
[12:52] <michi> I’m just getting beaten up by the QA guys ;)
[12:52] <cjwatson> michi: which binary package is at issue here?
[12:52] <michi> Sec...
[12:53] <michi> cjwatson: libunity-scopes-qt<version>
[12:53] <michi> See silo 10
[12:55] <cjwatson> michi: AFAICS kenvandine is wrong.  None of Conflicts/Breaks/Replaces is necessary there.
[12:55] <kenvandine> cjwatson, oh?
[12:55] <michi> That’s what jamesh thinks too.
[12:55] <cjwatson> kenvandine: Justify your position :)
[12:55] <kenvandine> we should clean up the old binaries if they are installed...
[12:55] <cjwatson> No.
[12:55] <cjwatson> That's not the purpose of those fields.
[12:55] <cjwatson> Stop misusing them.
[12:56] <kenvandine> :)
[12:56] <kenvandine> we want the new binary to replace the old one
[12:56] <cjwatson> If you're misusing them in this way routinely, then you are making apt's job harder and in some cases harmfully so.
[12:56] <cjwatson> Stop it :)
[12:56] <seb128> the old ones should automatically drop from the image if nothing pull them in
[12:56] <oSoMoN> trainguards: can silo 21 be published, please?
[12:56] <kenvandine> and not leave a bunch of old version around... especially if they aren't compatable
[12:56] <sil2100> oSoMoN: on it now!
[12:56] <cjwatson> That is not the purpose of Conflicts/Breaks/Replaces.
[12:56] <seb128> kenvandine, compatible with what?
[12:56] <cjwatson> It's the purpose of other tools.
[12:56] <sil2100> oSoMoN: apologies, was on lunch
[12:56] <cjwatson> e.g. deborphan
[12:57] <renatu> sil2100, yes
[12:57] <oSoMoN> sil2100, no worries, I just came back from lunch myself :)
[12:57] <cjwatson> Misusing C/B/R for this causes upgrade problems.
[12:57] <seb128> if there is a e.g a dbus api that changed, it makes sense to force the removal of things that talk the old protocol
[12:57] <kenvandine> they renamed the lib package twice
[12:57] <kenvandine> one of which only landed in wily
[12:57] <kenvandine> and they are reverting that
[12:57] <cjwatson> Simple soname changes shouldn't have any of C/B/R.
[12:58] <cjwatson> If you add them, then apt has to do significant extra work to order changes in a way that's otherwise entirely unnecessary.
[12:58] <kenvandine> i think they wrap dbus apis
[12:58] <seb128> cjwatson, what if the old lib talks to a server over a protocol that changed and make them not work with the new service?
[12:58] <kenvandine> it's unity scope apis
[12:58] <kenvandine> iirc
[12:58] <cjwatson> seb128: I would still not expect to see lib0.2 conflicting with or breaking lib0.1!
[12:58] <michi> kenvandine: This has nothing to do with dbus or on-the-wire protocols.
[12:58] <seb128> cjwatson, right, but the new service with the old lib maybe?
[12:58] <pstolowski> hey trainguards, i'd like to abandon silo 57 (requested same stuff twice by mistake), but not sure how
[12:58] <michi> The library under discussion is a plain Qt API.
[12:59] <cjwatson> seb128: Maybe.  But that's not what was being argued ...
[12:59] <kenvandine> michi, i see... i thought it was a lib that wrapped dbus apis
[12:59] <cjwatson> "there needs to be a replaces/conflicts for the binaries that landed in wily that aren't built anymore"
[12:59] <cjwatson> which is a specious argument
[12:59] <seb128> cjwatson, I don't think kenvandine defends the current solution, just the fact that the old libs shouldn't be co-installable with the new service since they are incompatible
[12:59] <michi> pstolowski: Merge and Clean. Then ONLY_FREE_SILO
[12:59] <michi> That throws the whole thing away.
[12:59] <sil2100> pstolowski: as michi said
[12:59] <cjwatson> seb128: the thing I quoted above was the reason given, and it is not a good reason
[12:59] <seb128> agreed
[13:00] <seb128> just saying that there might be a need for some of those conflicts
[13:00] <seb128> in different places
[13:00] <michi> seb128: There is no issue about the old libs being compatible with the service.
[13:00] <kenvandine> perhaps i didn't explain my concern well enough, since it was for the scopes API i thought it was dbus
[13:00] <kenvandine> then that fine
[13:00] <michi> No, no dbus involved in any of this.
[13:00] <seb128> michi, so clients of the old soname keep working fine?
[13:00] <michi> Yes.
[13:00] <seb128> they don't need to ported/migrated to the new one
[13:00] <michi> Correct.
[13:00] <seb128> kenvandine, seems good then :-)
[13:01] <kenvandine> then that's fine
[13:01] <michi> OK, phew...
[13:01] <sil2100> kenvandine: hey! Could you publish https://ci-train.ubuntu.com/job/ubuntu-landing-021-2-publish/ ? There's this change: https://ci-train.ubuntu.com/job/ubuntu-landing-021-2-publish/92/artifact/webbrowser-app_packaging_changes.diff
[13:01] <sil2100> (so only a dep bump)
[13:01] <michi> One of these days, my debian Fu will hopefully increase to level 7, so I can actually claim that I more or less know what I’m doing...
[13:01]  * kenvandine checks
[13:02] <pstolowski> seb128, michi allright, thanks
[13:02] <cjwatson> OK, great.  I just try to nip confusion in this area in the bud so that some poor soul in foundations isn't left digging through apt debugging output in a month's time trying to make the upgrade sensible :)
[13:02] <cjwatson> (not that that is my problem any more ...)
[13:02] <sil2100> renatu: do you know if anyone pushed the seed changes, or should I do it now?
[13:03] <michi> cjwatson, Mirv, kenvandine: Thanks for all your help everyone, I truly appreciate it!
[13:05] <renatu> sil2100, I need to check, do you have the link for the the repository with the meta-package?
[13:05] <sil2100> renatu: no worries, I'll check it then :)
[13:05] <renatu> sil2100, ok thanks
[13:07] <sil2100> Wow
[13:09] <sil2100> renatu: ok, I see didrocks uploaded the wily change and Mirv did the overlay change
[13:09] <sil2100> Good
[13:09] <renatu> great thanks
[13:09] <kenvandine> sil2100, done
[13:09] <sil2100> kenvandine: \o/ Thanks!
[13:11] <sil2100> Mirv: hey, regardin indicator-transfer seed change, you could have removed indicator-transfer when adding the new package ;)
[13:11] <sil2100> As it pulls it in as a dependency
[13:11] <sil2100> kenvandine: hm, so you reviewed silo 10 already, right?
[13:12] <kenvandine> not 10
[13:12] <sil2100> Since I have the power to publish it, but it's a big diff - should I also take a look at it? Or will I be doubling work then?
[13:12] <kenvandine> 21
[13:12] <sil2100> kenvandine: right, but silo 10 is the silo that you NACKed earlier :)
[13:13] <kenvandine> ah
[13:13] <kenvandine> then i had reviewed it
[13:13] <sil2100> And seeing the discussion above, the NACK was invalidated - so is it completely reviewed now? :)
[13:13] <kenvandine> yeah
[13:13] <kenvandine> that was my only concern
[13:13] <sil2100> Thanks!
[13:13] <kenvandine> np
[13:22] <sil2100> kenvandine: I wonder - do soname bumps require us poking archive admins for permission?
[13:22] <sil2100> Or can we just publish those as is?
[13:22] <sil2100> Since there's that rule that new binary package additions require archive admin ACKs
[13:22] <sil2100> hmmm
[13:23] <kenvandine> i think you have to publish them so they show up in NEW
[13:24] <sil2100> New binary packages won't show up in the NEW queue, those go straight to the archive
[13:24] <sil2100> New source packages only show up in the NEW queue when published from the CI Train
[13:24] <sil2100> That was one of the issues of the train itself
[13:24] <kenvandine> sil2100, oh... i didn't know that
[13:25] <kenvandine> i thought the usual archive workflow would be maintained
[13:25] <sil2100> Sadly for new bins it's bypassing the normal workflow, which is why there's that warning on top of the packaging diff when there are new binary packages involved ;)
[13:28] <cjwatson> sil2100: technically that does require an archive admin ack yes
[13:28] <cjwatson> one of these days we will fix that LP bug :-/
[13:29] <sil2100> cjwatson: could you take a look? :) https://ci-train.ubuntu.com/job/ubuntu-landing-010-2-publish/80/artifact/unity-scopes-api_packaging_changes.diff <- it's from silo 10 that was discussed some moments ago, it's from the changes that make the packaging to generate packaging basing on what series the package builds for
[13:29] <sil2100> (I know how that sounds)
[13:31] <cjwatson> I have no problem with such things in principle, depends rather on how they're done :)
[13:31] <cjwatson> sil2100: ok, sorry, this is more than I have time for right now though.  could you ask in the usual places?
[13:32] <sil2100> hah, yeah, that's what I thought originally when I saw the diff
[13:32] <sil2100> Ok, let me bring that up on -release
[13:32] <sil2100> Thanks!
[13:35] <Mirv> cjwatson: thanks. I also thought nothing would be needed at the first sight but I tried to interpret (correctly) what kenvandine seemed to want (which turned out is not really wanted)
[13:37] <Mirv> sil2100: why remove?
[13:37] <kenvandine> Mirv, sorry, i'm just used to most of these types of changes being to handle incompatible dbus API changes under the covers, /me grumbles about indicators :)
[13:37] <Mirv> sil2100: oh right, I understand, not needed anymore, true
[13:37] <sil2100> Mirv: not a biggie, just redundant :)
[13:37] <Mirv> :)
[14:17] <rvr> abeato: Is silo 44 ready or not? :-/
[14:18] <abeato> rvr, it is, awe_ got confused :)
[14:18] <rvr> Ah, nice :)
[14:18] <abeato> rvr, just talking with him on hangouts
[14:18] <rvr> The comment disappeared just after I read it
[14:19] <abeato> hahaha
[14:19] <abeato> self-destroying message :p
[14:29] <morphis> sil2100: ping
[14:44] <sil2100> morphis: pong
[14:45] <morphis> sil2100: I just pushed a fix for phablet-tools which ogra_ already reviewed
[14:45] <morphis> question now is where to land this
[14:45] <morphis> wily only?
[14:47] <ogra_> morphis, in the phablet-tools PPA
[14:49] <morphis> ogra_: can I do that from bileto?
[14:50] <ogra_> morphis, no idea :)
[14:50] <ogra_> i guess sil2100 could tell
[14:50] <sil2100> morphis: you can do that with bileto too, at least that was possible in the past
[14:51] <sil2100> Let's experiment with that ;p
[14:51] <sil2100> ogra_: did you use the train to release phablet-tools in the past anyway?
[14:51] <morphis> sil2100: so I have to select another target ppa?
[14:51] <sil2100> morphis: yes, just write down the phablet-tools PPA in the same format as the overlay one is written
[14:52] <morphis> sil2100: good
[14:52] <morphis> do we need QA for that, I think so, right?
[14:52] <ogra_> sil2100, i dont think so, i always dput'ed to the PPA
[14:58] <sil2100> ogra_, morphis: if the train wasn't used for that, then I suppose a dput is enough - we don't usually do QA on it since it's not really on the image
[14:58] <morphis> sil2100: ok
[14:58] <morphis> ogra_: can you do the dput then?
[14:59] <ogra_> morphis, no guarantees i can manage that today, sorry ... snapp yrelease preparation is ongoing and i'm very behind on stuff
[14:59] <morphis> ogra_: np
[14:59] <morphis> no hurry
[15:04] <nuclearbob> plars: I
[15:04] <nuclearbob> 'm looking at the old desktop utah testing, and I have an old approved branch that I think I'd like to try to land
[15:04] <nuclearbob> are you the person to talk to about that?
[15:16] <plars> nuclearbob: I actually don't remember where that box landed... it's technically still in a maas cluster that CI controls, but probably not really in their scope or ours at the moment... one of those limbo things :)
[15:17] <nuclearbob> plars: I'm not actually looking for the box at the moment, I'd like to land a change to the utah code
[15:17] <plars> nuclearbob: where's the code?
[15:17] <nuclearbob> plars: https://code.launchpad.net/~nuclearbob/utah/psutil-2
[15:18] <nuclearbob> or maybe https://code.launchpad.net/~nuclearbob/utah/psutil-2/+merge/226313 makes more sense
[15:22] <plars> nuclearbob: right now, it's pulling lp:~canonical-ci-engineering/ubiquity/ubiquity-ci-testing but that's a ubiquity branch, not utah
[15:22] <plars> nuclearbob: iirc this thing never used utah
[15:22] <plars> nuclearbob: are we talking about the same tests?
[15:23] <nuclearbob> plars: this isn't about the ubiquity testing, this is about the desktop utah tests in lp:ubuntu-test-cases/desktop, but changed to psutil back in utopic have broken the utah vm provisioner
[15:23] <plars> nuclearbob: ah, no we're not talking about the same stuff then
[15:23] <plars> nuclearbob: that's definitely not me
[15:23] <nuclearbob> plars: okay. Do you know who it might be?
[15:24] <plars> nuclearbob: hmm, try josepht, fginther, or psivaa maybe? or better yet talk to Ursinha or ev. But this is very likely stuff they are looking to move over to your own jenkaas I would guess.
[15:24] <plars> ev: Ursinha: ^ this is *not* the ubiquity tests running in maas that he's talking about
[15:29] <pstolowski> sil2100, hey, i haven't been following entire discussion about silo 10; is it going to land soon?
[15:30] <nuclearbob> josepht, fginther, psivaa: right now I actually just want to land a branch to utah that psivaa approved more than a year ago
[15:31] <sil2100> pstolowski: hey! Yes, but it needs a review from the archive admins
[15:31] <sil2100> (waiting for someone to pick it up)
[15:31] <fginther> nuclearbob, looking
[15:33] <josepht> nuclearbob: The MP looks fine to land but I'd prefer psivaa have a chance to comment as he's done some utah cowboying that may need to be considered as well
[15:33] <nuclearbob> josepht: cool, I'll await his feedback
[15:33] <nuclearbob> fginther: thanks!
[15:34] <josepht> nuclearbob: how would you like to become the maintainer of utah?
[15:35] <nuclearbob> josepht: I'd have to ask jibel about that
[15:35] <josepht> nuclearbob: ack
[15:36] <psivaa> nuclearbob: josepht: fginther: i dont mind landing this. Was being curious how we're not seeing any issues without this change, though
[15:36] <fginther> psivaa, our host runs trusty
[15:36] <fginther> psivaa, this appears to only impact utopic and newer hosts
[15:37] <psivaa> fginther: right, just saw that. thank you
[15:39] <pstolowski> sil2100, great, thanks!
[17:11] <cyphermox> sil2100: you still around?
[17:12] <cyphermox> wondering whether we're at the point where robru needs help to cover trainguard duties :)
[17:28] <robru> cyphermox: yes please
[17:39] <cyphermox> robru: ok


[11:35] <chrisjrob> I've been testing Edubuntu 8.04 and noticed that the thin client manager is not installed by default and must be added by installing thin-client-manager-gnome (the backend is already installed), could anyone advise whether this is a bug and if so where I should log it?
[11:36] <ogra> its no bug
[11:37] <ogra> we dropped tcm in favour of italc for which the client is installed by default and the control app is shipped on the edubuntu addon CD
[11:37] <chrisjrob> thanks ogra!
[11:37] <chrisjrob> I guess the documentation is lagging a little behind development...!
[11:38] <ogra> as always (sadly)
[11:38] <ogra> sorry for that
[11:38] <ogra> it shoudl probably be mentioned on http://wiki.ubuntu.com/HardyClassroomServer
[11:40] <chrisjrob> yes, that was the page I had followd.  thanks for the info ogra.
[13:50] <edistar> hello, anyone here using italc? it doesn't seem to work here..
[13:50] <edistar> do I need to start the italc client manually on every client?
[13:56] <edistar> and the clients all run locally on the server, how do I connect to them?
[13:58] <ogra> there is a special port you need to connect to
[13:58] <ogra> use: external_server_ip:port for that
[13:58]  * ogra forgot which port that was ....
[14:01] <edistar> ogra: ok, I'll check that then
[14:01] <edistar> external_server_ip =?
[14:02] <ogra> well, if you have two NICs in your server, the one facing the outside world, not the client network
[14:02] <edistar> I only need one NIC
[14:02] <ogra> well, then that one i guess
[14:02] <edistar> ok
[14:02] <ogra> i only tested with a two NIC setup
[14:02] <ogra> and it didnt work with the TC network IP
[14:07] <edistar> well, I just put the router/gateway into the same network so that other clients not booting via LTSP could also access the internet
[14:08] <edistar> so now I don't need the second NIC for internet anymore
[14:27] <edistar> ogra: doesn't the port change every time the person logs on?
[14:29] <edistar> I don't understand how to set it up..
[14:32] <edistar> http://italc.sourceforge.net/wiki/index.php?title=ITALC_in_a_ThinClient_environment I tried this
[14:32] <edistar> but an echo $DISPLAY does not output the same at all..
[14:35] <ogra> thats al ltsp4.x which is obsolete since 3 years
[14:35] <edistar> ogra: ah, ok
[14:37] <ogra> stgraber, do you remember the port number for italc (that really needs to go on https://wiki.ubuntu.com/iTalc) i cant find your mail to RichEd where you outlined it
[14:37] <ogra> and thats my only reference for the port :(
[14:38] <edistar> ogra: isn't it 11 + last bit of ip?
[14:38] <ogra> something like that
[14:38] <ogra> i think it was 10+last bit for ltsp5
[14:40] <edistar> ogra: and localhost doesn't work for ip?
[14:42] <edistar> ogra: don't the ips change every boot? or do I need to setup fixed ips for certain MAC addresses then?
[14:46] <ogra> they usually dont change unless you have more clients than your IP range defines in dhcpd.conf
[15:16] <edistar> ogra: okey..
[15:17] <edistar> ogra: do you think the wiki entry will be updated soon?
[15:17] <ogra> if someone updates it :)
[15:17] <edistar> then I'll look into that program again in a few days..
[15:17] <ogra> its a wiki, anyone can (*hint*) :)
[15:17] <edistar> stgraber could do that ;)
[15:18] <edistar> ogra: I don't know exactly what to do, otherwise I'd edit it
[16:34] <stgraber> edistar: hi
[16:35] <stgraber> edistar: did you try the release we have in the PPA ? it has avahi support and should solve all your ports problem
[16:36] <stgraber> italc uses two different ports, one of ISD (service daemon) and one for IVS (vnc server). With LTSP I'm using 10000+last-byte-of-ip and 11000+last-by-of-ip
[16:37] <stgraber> the iTalc wiki page still needs a lot of work, the idea would be to have an howto for all possible way of installing it (that's a lot :)). Feel free to update it with your own experience.
[17:12] <edistar> stgraber: thanks, will try that
[17:16] <edistar> stgraber: I added the repos but it doesn't find any updates
[17:18] <edistar> stgraber: so it won't install the ppa version
[17:21] <stgraber> you are using Hardy right ?
[17:34]  * ogra would assume so for everyone since ltsp in intrepid doesnt work currently
[18:55] <edistar> stgraber: yes, I am
[19:57] <stgraber> so you should have a proposed upgrade to 1.0.9-rc4
[20:04] <edistar> stgraber: no, dist-upgrade told me that there was nothing to upgrade
[20:53] <edistar> stgraber: thanks for your help anyway :) I'll be off.. I'll have another look around in a few days


[00:52] <liuxg>  I am now trying to development a simple snap app on 16.04 desktop. I met a problem. whenever install my snap app onto my desktop, it takes quite a lot of space since I get all of the Qt stuff. the problem is that it get different versions in my hard disk, and each takes that space. How can I remove the versions that i do not need any more? thanks
[03:26] <nhaines> ls
[06:33] <zyga> o/
[07:55] <shuduo> ogra_: hello, may i know where is official kernel repo for rpi2 snappy image?
[08:37] <ogra_> shuduo, ppisati maintains it on kernel.ubuntu.com (i always forget the exact branch name)
[08:37] <shuduo> ogra_: got it. let me find it. :)
[08:46] <shuduo> ppisati: ping
[10:37] <ppisati> shuduo: pong
[11:17] <shuduo> ppisati: may i know what kernel tree and branch is being used for snappy on raspberry pi 2?
[11:37] <shuduo> ppisati: i cloned it from  git://git.launchpad.net/~p-pisati/ubuntu/+source/linux and see   remotes/origin/x-raspi2
[11:37] <shuduo>   remotes/origin/x-raspi2_rtlfix
[11:37] <shuduo>   remotes/origin/x-raspi2_rtlwififix
[12:07] <kyrofa> Good morning
[12:10] <qengho> jdstrand: what does the "unconfined" security plug look like these days? Still old-security?
[12:40] <jdstrand> qengho: it looks like --devmode :)
[12:41] <jdstrand> qengho: more seriously, it was decided that unconfined isn't a thing any more
[12:41] <jdstrand> people can use --devmode to be unblocked and file a bug for what they need (please add snapd-interface tag)
[12:45] <ppisati> shuduo: that's my personal git tree
[12:46] <ppisati> shuduo: use this:
[12:46] <ppisati> shuduo: https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/xenial/log/?h=raspi2
[12:59] <shuduo> ppisati: got it. thanks.
[13:38] <morphis> jdstrand: first step towards slot support in the pulseaudio interface: https://github.com/morphis/snappy/commit/08da30f860ab68cf9ed866e10874e8b353894d36
[13:38] <morphis> needs cleanup and then I will push that as PR next week
[13:40] <niemeyer_> ssweeny: ping
[13:42] <jdstrand> morphis: nice! :)
[13:44] <morphis> jdstrand: however policy might be too in open in some points, we need to figure those things out once I open the PR
[13:45]  * jdstrand nods
[14:37] <Kristbaum> Hello people, is it intentional that the same snap can be run multiple times at once? E.g the Telgram-Snap can be executed 50 times on my system.
[14:39] <ogra_> file a bug ... i guess that needs some discussion
[14:40] <ogra_> (if it was a terminal app you probabl ywould want it to start multiple times .... apps that use login credentials probably not so much ... might need a field in snap.yaml/snapcraft.yaml for the dev to define)
[14:58] <Kristbaum> Can I also file a bug, concerning the "repoducable Builds" thing, or would this be more anoying, than helpful?
[15:01] <kyrofa> Kristbaum, are you talking about bug #1582417
[15:05] <Kristbaum> Oh, very nice, I thought I needed to create one first ;) Is there also one about linking to sources, so that you can verify, that you are running the correct software (in case it's opensource), or did I also miss that?
[15:10] <kyrofa> Kristbaum, not that I know of
[15:12] <ogra_> thats really up to the developer, iirc the store app page pffers you to specify a source url and homepage when you register your snap
[15:14] <Kristbaum> ogra_: But the source on the Website doesn't have to macht the final snap image, right?
[15:14] <ogra_> nothing has to match a snap ... but if you are OSS developer you can indeed specify your git tree and homepage
[15:15] <ogra_> snaps really only care about binary ...
[15:15] <ogra_> everything else would be added meta data for the store side
[15:16] <ogra_> there arent even any requirements that you have the source for what you put inside your snap (assumed you are allowed to distribute it indeed)
[15:21] <Kristbaum> Okay, and we can agree that is a problem? Because, e.g. there is a Telegram app out there (wich I cant find the source for), how do I know it isn't sending out all I write to somebody? Or another example: The Keepassx snap, can't send anything because it has no network plug, but but how do I know if it really encrypts it correctly?
[15:29] <ogra_> you dont
[15:32] <ogra_> (afaik that telegram app is actually the binary from telegram.org ...)
[15:33] <Kristbaum> ogra_: okay so this is a problem.. Should I bug report this, or is this more of a management decision?
[15:33] <ogra_> i dont see where it is a problem
[15:34] <ogra_> the snap design is only built around binaries ... how you produce them is in your responsibility
[15:34] <ogra_> it tries to give everyone the most freedom it can ... by not enforcing such stuff
[15:35] <ogra_> what it enforces is the security model ... no app should be able to access any data or service you havent explicitly authorized
[15:37] <ogra_> weather the source code that binary was initially built from is open or not doesnt matter ... a good OSS dev would indeed mention where the code comes from and give you a reciepe how it is built ... but thats totally not mandatory
[15:39] <Kristbaum> I think the whole concept (at the moment), works really great for proprietary software. But for Free Software people, and Security minded ones it isn't really a step forward, because you can't check the software you are using. Isn't this a contrast to the whole security story?
[15:39] <ogra_> well, you cant check whet the single binary does, but you have full control about its outside connections
[15:40] <ogra_> be it disk, network, sensors on your phone or whatever
[15:41] <Kristbaum> Thats right, but in a OSS binary I want to trust the binary too. And I can't if i can't verify if it's the same code as on the website.
[15:42] <ogra_> you can if the developer tells you how it was built and points you to the source code
[15:43] <ogra_> if you are concerned about that you will have to check the details of the respective snaps you use
[15:44] <ogra_> but after all, do you actually do that for ... say the desktop you use ?
[15:44] <ogra_> i.e. do you know the filemanager you use doesnt come with a keylogger inside
[15:47] <Kristbaum> Thats right, but considering that it's quite easy in apt, snaps are kind of a step back. There is a really high chance that somebody will build a malicous e.g. Telegram app and there will be no checks possible, and when sobody finds out it will be a mess etc.. And no ofcource I am to lazy to ever check the source of my software, but I trust you and all the other Ubuntu/Debian developers that they have access to th
[15:48] <ogra_> well, the hope is indeed that telegram uses a snapcraft.yaml in its tree and simply provides an official snap
[15:54] <Kristbaum> We woudn't need to hope on every company to to this, if there would be something like a automated trustet OSS snap build service, where oss developers provide a link to the source and a .yaml file, and it gets built, and we can check it if needed with something like snap source telegram-sergiusens.
[15:55] <ogra_> thats called launchpad ;)
[15:55] <ogra_> (such an LP feature exists already)
[15:55] <ogra_> but still, it is optional
[15:56] <ogra_> the telegram-sergiuens snapcraft.yaml wouldnt help you much though ... i'm 90% sure it doesnt build the source
[15:56] <ogra_> afaik it just pulls the latest binary from upstream and snaps it
[15:57] <Kristbaum> But the Version in the store already is behind?
[15:57] <ogra_> and there will likely be many snapcraft.yaml files like this
[15:57] <oparoz> LP snap builders, when they work, are great. You can even build partials
[15:57] <ogra_> did they stop working ?
[15:58]  * ogra_ hasnt had issues yet
[15:58] <ogra_> Kristbaum, well, ask sergiusens :)
[15:58] <ogra_> if he feels like updating
[15:59] <ogra_> or just hit the update button inside the running app ;)
[15:59] <Kristbaum> But still, can people check if they want to, with this LP plugin?
[15:59] <ogra_> sure
[15:59] <Kristbaum> the Update Button chrashes it :D
[16:00] <Kristbaum> Maybe it is malicions :D
[16:00] <ogra_> it gets updated, but cant restart for whatever reason
[16:00] <ogra_> if you start it newly it is up to date
[16:01] <Kristbaum> Nope, it's the same as before
[16:01] <ogra_> https://code.launchpad.net/~ogra/+junk/ircproxy is a branch of mine (bit outdated, i'm waiting for "snap config" to come back) ...
[16:01] <ogra_> https://code.launchpad.net/~ogra/+snap/ircproxy are the snap packages created from that branch
[16:01] <ogra_> on the branch summary page i have a "build snap" button ...
[16:08] <Kristbaum> Interesting indeed. But there is still the risk of a malicous person taking x/y oss app (modify it in a bad way), load it up in the store, and noone would notice. Snaps are a redirection of trust in the hands of the person that uploads it, and non officail app can be trusted.
[16:09] <ogra_> it depends ... i assume if you woulld use a snappy based desktop install you would still trust canonical as much as you do today
[16:09] <jdstrand> Kristbaum: to expand on/reiterate what ogra said: snappy itself doesn't enforce anything regards to sources or builds from source, just like debs don't either. snaps and debs are a packaging format. Launchpad is used to build Ubuntu binaries from deb source packages. Launchpad has facilities for building snaps from source packages as well
[16:10] <ogra_> and that PPA guy from whom you install packaages to your system ... you trust him enough to give him root on your machine
[16:10] <jdstrand> Kristbaum: and aiui there are plans to make building from sources even easier for open source projects and devs
[16:10] <ogra_> it shuffles the trust around indeed ... but also adds a massive amount of safety and security in the end
[16:11] <Kristbaum> No way :D That also no a good solution but at least I can go to the launchpad site and check it, and I know it is the same, as is running on my system.
[16:13] <jdstrand> Kristbaum: then there *will* be a way to verify the origin-- there will be sha512 sums of the generated snap that can be compared against Launchpad, etc
[16:13] <ogra_> and if an OSS dev wants you to have that info today he can already put a link to the tree and a build HOWTO in the package description
[16:13] <jdstrand> and aiui, all this is going to get easier and better
[16:13] <ogra_> jdstrand, well, the origin for the binary
[16:14] <ogra_> i can slap a bunch of downloaded binaries together in a snap and just upload them from my desktop ... you can probably track it to me via that ... but you wont know if i built a thing of it from source
[16:14] <jdstrand> ogra_: I'm saying that if someone uploads a source/build from source, the resulting binary's sum can be verified against what is installed on the device
[16:14] <ogra_> indeed
[16:14] <jdstrand> uploads and builds on LP that is
[16:14] <ogra_> but so can my binary blob collection
[16:15] <ogra_> ah
[16:15] <ogra_> right, if you build it there too, thats indeed different
[16:15] <jdstrand> so a security minded person might make a personal or site-specific decision-- I will only install snaps that are built on LP, etc
[16:15] <ogra_> right
[16:16] <jdstrand> I can imagine snapd and the store gaining functionality to make that all convenient
[16:16] <Kristbaum> Okay, thats a start ;) I really love the snappy concept in every way, this is the only thing that still bothers me. I think it's great that I will be able to at least check projects build on lp,
[16:16] <Kristbaum> And marking the trusted OSS snaps would be nice to
[16:17] <jdstrand> reproducible builds and builds from source are important concepts that will be supported. the minimum bits are, more will come
[16:19] <Kristbaum> I know you have a lot to do these days, I just hope noone gets bad ideas and builds malicious snaps. Because this could really damage the reputation early one, despite it beeing a grat idea.
[16:20] <ogra_> i actually hope people do :)
[16:20] <ogra_> it will prove the security setup
[16:20] <Kristbaum> Maybe we should do a challenge to try and test the limity of snappy.
[16:20] <ogra_> definitely ... and indeed file bugs for everything
[16:22] <Kristbaum> The snappy challenge, who can get the most keyloggers to people :D Has UBuntu-Marketing an IRC channel?
[16:22] <ogra_> well, keylogger and Xorg vulnerabilities would be a bit unfair until Mir is there
[16:22] <ogra_> since it is a known open hole
[16:22] <Kristbaum> okay, fair point
[16:23] <ogra_> i'd start with a headless challenge ;)
[16:27] <Kristbaum> Would In-App-Keyloggers be allowed?
[16:28] <ogra_> why not
[16:29] <Kristbaum> ok, maybe I find somebody in marketing that likes the idea :D
[16:31] <ogra_> :)
[17:01] <ssweeny> niemeyer_, sorry I missed your ping earlier
[17:32] <slvn> Hello! Just wondering about this issue which seems to lack attention. Some snap can't be validated because of invalid checksum ... https://bugs.launchpad.net/ubuntu/+source/squashfs-tools/+bug/1577333
[17:33] <kyrofa> jdstrand, how do the review tools check that ^^? Uncompress and recompress and compare checksums?
[17:34] <ogra_> do you need to uncompress ?  the sum should be in the meta data ...
[17:34] <ogra_> so you just need to compare the squashfs sum vs meta
[17:35] <kyrofa> ogra_, ah, I didn't realize that. What would cause them not to match?
[17:35] <ssweeny> jdstrand, if I'm writing a dbus rule to allow getting/setting a particular property what would that look like? Would the interface be /com/ubuntu/location/service/<property> or would it be /org/freedesktop/dbus/properties with the destination com.ubuntu.location.service.<property>?
[17:35] <ogra_> recompressing them ??
[17:35] <ogra_> dunno
[17:38] <jdstrand> kyrofa: there are 3 bugs related to this that I'll be getting to after the interfaces, doc and devmode work
[17:38] <kyrofa> jdstrand, ah, okay. I just noticed that you reassigned to squashfs-tools, so you must know what's going on there. I wasn't sure if snapcraft was doing something wrong or what
[17:39] <kyrofa> slvn, ^^ FYI
[17:39] <jdstrand> kyrofa: to answer your question specifically, I updated squashfs-tools to add an option to unsquashfs to grab the fs time from a snap. then I added an option to mksquashfs to injuect that time into the superblock. in this manner, we can resquash
[17:39] <jdstrand> kyrofa: however, there are a couple of issues where timestamps are causing trouble, and perhaps something not timestamp related
[17:40] <jdstrand> no, snapcraft is fine
[17:40] <kyrofa> jdstrand, ah, I see, okay
[17:40] <jdstrand> it works a lot of the time but unfortunately it isn't 100% yet
[17:42] <slvn> kyrofa, I don't fully understand ... it seems to me *all* my packages systematically fails the checksum test.
[17:43] <jdstrand> slvn: you might be hitting one of the three different bugs
[17:44] <slvn> jdstrand, hmm ok! so all is under control :)
[17:44] <jdstrand> I'll be updating the review tools for something else, I should turn this check off until it is reliable
[17:45] <jdstrand> well, yes, though it'll still be a little while before it is fixed. but let me make it better for people
[17:45] <jdstrand> (ie, make the check temporarily non-fatal
[17:45] <jdstrand> )
[17:54] <jdstrand> tyhicks, beuno: fyi, I just committed 'turn resquash test into info for now until the squashfs-tools bugs are fixed and this is a reliable check' to address ^
[17:58] <tyhicks> jdstrand: ack - I hope we can get to those bugs soon and reenable the checks
[17:58] <jdstrand> me too :|
[18:15] <beuno> jdstrand, ack
[18:29] <ssweeny> jdstrand, for the location-control interface I have apparmor rules that enable "{Get,Set}" for properties. You mentioned expanding the dbus rules as well but I'm not sure what that should look like
[18:39] <jdstrand> ssweeny: I was only saying that in general-- ie, whatever org.freedesktop.... accesses you might need to have Get and Set work
[18:39] <jdstrand> ssweeny: maybe that is nothing beyond what the dbus abstractions already give (I just didn't know)
[18:39] <jdstrand> ssweeny: (when location-control is standalone)
[18:39] <ssweeny> jdstrand, ah, that makes more sense. I don't think it's possible to do what I thought you meant (i.e. enumerate the properties themselves in the policy)
[18:40] <jdstrand> ssweeny: oh no, we can't mediate on message contents, no
[18:41] <ssweeny> jdstrand, ok, thanks!
[21:17] <jdstrand> roadmr (cc beuno, nessita and tyhicks): can you pull r664 of the review tools for devmode support?
[21:17] <jdstrand> roadmr: and hi! :)
[21:18] <roadmr> jdstrand: sure! I'll work on it, hello :)
[21:18] <jdstrand> roadmr: it can be next week if needed
[21:18] <jdstrand> roadmr: thanks :)
[21:18] <roadmr> jdstrand: well it's fri evening so unless we escalate the hell out of it, it will be next week :(
[21:18] <roadmr> jdstrand: I'll get the ball rolling though :)
[21:19] <jdstrand> hehe
[21:20] <jdstrand> roadmr: right, please don't escalate the hell out of it :)
[21:20] <jdstrand> hehe
[21:20] <roadmr> \o/ thanks :)


[07:48] -SwissBot:#ubuntu-news- ::Planet:: Ubuntu Blog: Design and Web team summary – 17 September 2019 @ http://ubuntu.com/blog/design-and-web-team-summary-17-september-2019
[15:02] -SwissBot:#ubuntu-news- ::OMG!Ubuntu:: Oracle Built a Raspberry Pi Super Computer That Looks like a TARDIS @ https://www.omgubuntu.co.uk/?p=153192 (by Joey Sneddon)
[15:40] -SwissBot:#ubuntu-news- ::OMG!Ubuntu:: Ubuntu Devs Outline Plans for 32-bit Support in Ubuntu 19.10 @ https://www.omgubuntu.co.uk/?p=153213 (by Joey Sneddon)
[16:39] -SwissBot:#ubuntu-news- ::OMG!Ubuntu:: Firefox is Switching to a Monthly Release Cycle @ https://www.omgubuntu.co.uk/?p=153237 (by Joey Sneddon)


[00:50] <nater> howdy
[20:55] <kurly> fwiw, asus seems to have pulled the latest bios update, not sure if i should downgrade to the latest published or if it will even allow a downgrade
[20:56] <kurly> and after 5.17.8 and 5.17.9 mainline failing on my wifi, 5.18.0 works again. 5.17.7 was the last known working 5.17 kernel for me.
[20:57] <kurly> hopefully asus will release a new bios update soon because even if i try different windows versions in the grub entry, i still get lots of ACPI warnings and errors
[20:57] <Jeremy31> What is the wifi chipset
[20:59] <kurly> 05:00.0 Network controller: MEDIATEK Corp. Device 7922
[21:00] <kurly> uses mt7921e
[21:00] <kurly> if it matters: Subsystem: AzureWave Device 5300
[21:00] <Jeremy31> kurly: try using it on an Ubuntu kernel like 5.15?
[21:01] <kurly> works there, but then audio controls don't. that's why I went mainline in the first place, but wouldn't mind moving back if the hardware is supported
[21:02] <kurly> audio is very loud and no volume control
[21:03] <Jeremy31> kurly: Might be best off to file a bug report on the audio issue


[00:02] <smoser> hm..
[00:03] <smoser> for virtual nics. the hotplug network item should trigger the cloud-init query to MD
[00:03] <smoser> and then ifup and away we go.
[00:03] <smoser> for physical...
[00:03] <smoser> i dont know
[00:03] <JayF> physical in our world, we'd add a vlan to a trunk, and somehow send a signal in out of band
[00:03] <JayF> this is still in the hand-wavy portions of planning
[00:04] <JayF> hence the hand waving
[00:04] <smoser> yeah
[00:04] <smoser> well, in physical world it could also be "ok, configure that nic now"
[00:04] <smoser> (that was previously un-configured).
[00:04] <JayF> how does cloud-init know to check?
[00:04] <JayF> you'd have to have something persistent or cron'd to check
[00:04] <smoser> but yours is an interesting case for thought also. essentially "hot plug vlan".
[00:04] <JayF> because no event to the host, like hotplugging
[00:04] <JayF> yup
[00:04] <smoser> right. i wouldn't want to do cron. we could... but
[00:05] <JayF> this is explicitly "I want you to do something without you having any other indication you should do it other than me telling you"
[00:05] <JayF> which seems out of cloud-init scope a little
[00:05] <smoser> we could long-poll
[00:05] <smoser> i'd not be completely opposed to that.
[00:05] <JayF> do you want a model, ever, where cloud-init runs forever?
[00:05] <smoser> in the past i've very much said "cloud-init is init".
[00:06] <JayF> yeah that was my impression as well
[00:06] <smoser> but it seems less of a stretch here because i *want* to be able to handle the event driven portion
[00:06] <JayF> smoser: btw, you should really merge the branch I pointed you at earlier. Nasty nasty bug.
[00:06] <smoser> udev hotplug -> cloud-init-query of MD -> ifup
[00:06] <JayF> smoser: something I was hunting for a while :)
[00:06] <smoser> which branch ?
[00:06] <smoser> i might have missed it.
[00:07] <smoser> so what i was saying is that since i want cloud-init to have code to do the hotplug based on an event , i'm not entirely opposed to somethign in cloud-init's source code being the source of the event.
[00:07] <smoser> or you coudl have an agent that generated the event to cloud-init.
[00:08] <JayF> 14:43:32 <JayF> smoser: harmw: harlowja_a*: https://code.launchpad.net/~jason-oldos/cloud-init/bug-1338614/+merge/234749 should fix 1338614. I was unable to
[00:08] <JayF>                 run tests due to local enviornment problems but will run them as soon as my VM recovers :)
[00:08] <JayF> If we run an agent, it'll be an agent smart enough to do everything
[00:08] <smoser> i thought i had fixed that
[00:08] <JayF> Like I said, I can't get my bzr to HEAD, so it's possible you did
[00:08] <JayF> but it's absolutely broken in the current release
[00:09] <JayF> or at least what I'm building against, which I think is current release
[00:09] <smoser> how can you "not get your bzr to head"
[00:09] <JayF> I'm at 'revno 1009' according to my cloud-init, and that's with the two commits I wrote today
[00:10] <JayF> I want the equivalent of 'git pull' or 'git reset --hard origin/master'
[00:10] <JayF> I can't get bzr to just give me a clean working copy of HEAD
[00:12] <smoser> well you could just : bzr branch lp:cloud-init
[00:12] <smoser> again
[00:12] <smoser> or bzr pull --overwrite
[00:12] <smoser> that git reset --hard
[00:12] <JayF> the bzr branch command didn't work
[00:12] <smoser> bzr branch lp:cloud-init
[00:12] <smoser> did not  work ?
[00:13] <JayF> it didn't appear to do anything to my current working copy
[00:13] <JayF> bzr pull --overwrite is exactly what I wanted
[00:13] <JayF> smoser: that bug exists in HEAD :(
[00:14] <smoser> irght.
[00:14] <smoser> bzr branch lp:cloud-init
[00:14] <smoser> is equivalent to
[00:14] <smoser>  git clone git://foo.git
[00:15] <smoser> so in a working copy, you probably got a new cloud-init/ dir underneithy
[00:15] <JayF> aha
[00:15] <JayF> that's exactly what it did
[00:16] <JayF> okay I understand a bit better now
[00:16] <JayF> I just like after I push something being able to get my working copy back to 'master'
[00:17] <smoser> you dont explicitly need the kwargs portion
[00:17] <smoser> of that MP.
[00:17] <smoser> right ?
[00:18] <JayF> Locally it didn't work until I had that
[00:18] <JayF> and that was suggested by someone smarter than I (comstud)
[00:18] <smoser> hm..
[00:19] <JayF> I know that I had not-working. Apply that patch, it works. Apply that patch sans **kwargs on the function signature, and it fails
[00:28] <smoser> ok. pushed.
[00:28] <smoser> thanks
[00:31] <smoser> JayF, the idea of "add a vlan" is interesting as itself.
[00:31] <smoser> as i dont have anything that would generate such an event.
[00:32] <smoser> ie, for virtio ethernet . i could see getting the nic added, and cloud-init reading the config and the config saying "make a vlan" and cloud-init configuring correctly.
[00:32] <smoser> but the core event was the nic added.
[00:32] <JayF> yeah that's what I'm saying
[00:32] <JayF> in bare metal, no hypervisor, it takes a physical action to generate a hardware event
[00:32] <JayF> or much fancier bmcs than I have :)
[00:33] <JayF> [insert hypervisors are for the weak joke here]
[00:33] <smoser> ok. so i have to think about that some more.
[00:33] <smoser> have you ever used hackpad ?
[00:33] <smoser> https://hackpad.com/Cloud-init-Networking-1gtK434RgVg
[00:33] <smoser> that seemed like a bit more mark-uppy version of etherpad. dont know how i feel
[00:34] <smoser> but i put some headers in there.
[00:34] <smoser> i have some content too , but is all very rough
[00:34] <smoser> i just can't stand typing in anything other than vi
[00:34] <JayF> ever looked at floobits?
[00:34] <JayF> their vim plugin is... lacking
[00:35] <smoser> i'd not seen that.
[00:35] <smoser> no content there :)
[00:35] <JayF> yeah I can tell now, lol
[00:35] <smoser> i was trying to write how i'd want stuff to work
[00:36] <smoser> basically,
[00:36] <JayF> my answer to that, more or less, is 'well' and 'reliably'
[00:36] <smoser> cloud-init-local comes up, and blocks hotplug events until its done.
[00:36] <JayF> hehehe
[00:36] <smoser> once its done, it "releases" the nic that it deemed (or found in a local datasource) to be the "metadata service link"
[00:37] <smoser> then once that comes up
[00:37] <smoser> all the others are un-blocked
[00:37] <smoser> and they come up via getting information from the MD.
[00:37] <JayF> I was thinking more that
[00:37] <smoser> in the case of no network MD, and only provided by config-drive, the "releasing" of those blocked events would then cause read from that cached data
[00:38] <JayF> you'd add a new stage to cloud-init
[00:38] <smoser> and they'd come up too
[00:38] <JayF> that's possibly persistent
[00:38] <JayF> that handles post-boot events by re-running the relevent part of the other stage
[00:38] <JayF> i.e. network json changed; call that module to regenerate network from md service
[00:39] <smoser> i'd liek to not just have "network json changed"
[00:39] <smoser> but "nic AA:BB:CC:DD:EE:FF added"
[00:39] <smoser> rather than determining what changed.
[00:39] <JayF> see I think there are dragons there
[00:39] <JayF> because by doing it that way you *are* determining what changed
[00:40] <JayF> or requiring someone outside of cloud-init to give you a specific trigger
[00:40] <JayF> if you're doing a long poll on a md service
[00:40] <JayF> you'll be able to quickly know what changed
[00:40] <smoser> right.
[00:40] <smoser> unles sthe long poll is given explicit updates
[00:40] <smoser> ie, rather than just getting a new version of the json
[00:40] <JayF> but the idea of trying, on the fly, to 'diff' the old and new config in some meaningful way seems scary
[00:40] <smoser> it would get the element that changed.
[00:40] <JayF> yeah but then you've introduced a second api interface
[00:40] <JayF> one for init and one for ongoing
[00:41] <smoser> yeah.
[00:41] <JayF> which I personally dislike
[00:41] <smoser> well, only added the second api
[00:41] <smoser> because there was not an event
[00:41] <smoser> so we had to essentialy receive the event
[00:41] <smoser> but then i guess what happens if you miss it
[00:41] <smoser> so it would be good to determine what changed.
[00:42] <smoser> and *that* is easy enough , at least its seemingly possible.
[00:42] <smoser> but figuring out what that means in terms of 'ifdown X, ifup Y' is more complex.
[00:42] <JayF> I'd say roughly determine what changed
[00:42] <JayF> like in categories
[00:42] <JayF> like 'ssh keys changed, kickoff add_ssh_keys module'
[00:42] <JayF> 'network changed, kickoff network module"
[00:42] <JayF> etc
[00:43] <smoser> ah. i wasn't goign to go that far.
[00:43] <JayF> then you make the ability to update part of each module
[00:43] <smoser> i was only going to take events on network config.
[00:43] <JayF> they can either do everything over again or just generate a diff
[00:43] <JayF> why not go the whole way?
[00:43] <JayF> why not accept an event saying "you have a new cinder volume that wants to be mounted"
[00:43] <smoser> well, some are not idempotent.
[00:43] <JayF> assuming cloud-init would know how to react to some things
[00:44] <JayF> make modules opt in to being event-driven and wrk to make the modules idempotent
[00:44] <JayF> anything in config management (cloud init kinda is) should strive to be idempotent where possible anyway imo
[00:45] <smoser> i dont have strong feelings against what you're syaing.
[00:45] <smoser> but i'd like to have networking first :)
[00:45] <smoser> as i think that is where we *need* a solution
[00:45] <JayF> yes, I would like to have networking too
[00:45] <JayF> I need to get those changes written and up :x
[00:45] <smoser> the rest of it, i think ihave a fair argument in "let something else do that"
[00:45] <JayF> well, edited and up, mostly
[00:45] <JayF> yeah, but the thing is
[00:46] <smoser> but nothing else really plays in the automatically-configure-hot-plug-netowrking world.
[00:46] <JayF> *someone* is going to want a conduit for setting up arbitrary things via event
[00:46] <JayF> and if cloud-init doesn't do it, someone will
[00:46] <JayF> and I'm trying really hard to not be someone
[00:46] <smoser> well, there are lots of things that do that arlready.
[00:46] <JayF> lol
[00:46] <smoser> juju does it
[00:46] <smoser> puppet does it
[00:47] <smoser> rackspace guest agent does it/
[00:47] <JayF> Nothing does it from the perspective of a provider
[00:47] <JayF> ugh, lets not bring nova-agent into this :(
[00:47] <JayF> I try to forget it exists and have success most days
[00:47] <smoser> so i kind of see the network stuff as cloud-init's job .
[00:48] <JayF> but like "mount me a network volume at boot" doesn't fit?
[00:48] <smoser> but beyond that, i struggle.
[00:48] <smoser> well at boot, that is there.
[00:48] <JayF> then just add general support for event-driven do stuff
[00:48] <JayF> and maybe a certain JayF would end up writing the event provider for cinder
[00:48] <smoser> how would we get an event on cinder ?
[00:49] <JayF> I'd presume we'd model drives to mount as an object in user_data+vendor_data
[00:49] <smoser> oh. duh.
[00:49] <smoser> sorry
[00:49] <smoser> well, there is a dataformat for mounts and what to do with mounts in cloud-init as it is.
[00:49] <JayF> so lets imagine rackspace, we'd just update vendor_data.json to add ['volumes']['my_fancy_volume'] = { 'place': '/data
[00:49] <JayF> you get the idea
[00:49] <smoser> it just only fires on those in the block-device-mapping.
[00:49] <smoser> so it would be very annalogus to networking solution
[00:49] <smoser> to have it respond to the newly attached disk
[00:49] <JayF> so if you saw that piece of data change, you'd trigger an event to revaluate that data
[00:50] <JayF> exactly
[00:50] <smoser> and hit the MD for "what should i do with that"
[00:50] <JayF> everything fits this model fairly well
[00:50] <smoser> so yeah
[00:50] <smoser> ok. you sold me there on that.
[00:50] <smoser> but i'm not sold on ssh keys yet :)
[00:50] <JayF> ssh keys is my personal #1 use case
[00:50] <JayF> because nova (or Rackspace Cloud, IDK the difference) only lets you inject one in the nova boot command
[00:51] <JayF> so the ability to trigger more keys gettting added post-boot seems nice
[00:51] <JayF> and I know of at least one group in Rackspace that's doing something that'd fit this workflow, but in a more gross way
[00:51] <harlowja_> hmmmm, seems like a job for mr.puppet or mr.chef
[00:51] <JayF> again though, I'm not the owner of the node
[00:51] <JayF> I'm just the service provider trying to make my customer click pretty buttons in a panel and make things happen
[00:51] <smoser> monkeyspeere
[00:52] <smoser> http://web.monkeysphere.info/getting-started-ssh/
[00:52] <JayF> smoser: a google of that takes me here first http://www.cracked.com/article_14990_what-monkeysphere.html
[00:52] <JayF> smoser: which was really perplexing, hahaha
[00:52] <JayF> smoser: that's amazing
[00:54] <JayF> This was a good chat, thanks :) I may be away mostly for a couple of days, but I'll be back
[00:54] <smoser> i was thinking that monkeyspehere had something to manage keys installed
[00:54] <smoser> but i guess not
[00:54] <smoser> anyway
[00:54] <smoser> later JayF thanks for you patch and your patience
[10:28] <m01> smoser: remember my networking issue yesterday (only my first ethernet connection is setup)? I looked at the OpenStack nova sourcecode. They do have a template for the interfaces file, but it looks like it's only used for bare metal targets (e.g. PXE-booted nodes), it doesn't appear to be used in general..
[14:10] <smoser> m01, you appear to be correct.
[14:10] <smoser> it definitely does that in some cases.
[14:10] <smoser> its not only for bare metal.
[14:11] <smoser> harmw, https://code.launchpad.net/~smoser/cirros/buildroot-upgrade
[14:11] <smoser> i think that builds for i386
[14:11] <smoser> running bin/bundle now
[14:12] <smoser> hopefully that'd get us to buildroot-2014.08
[14:15] <m01> hey
[14:16] <m01> hmm
[14:27] <m01> Are you saying that nova uses the /etc/network/interfaces template in environments other than baremetal?
[14:27] <m01> (e.g. libvirt, kvm etc)
[14:28] <m01> if cloud-init requires nova to stage that template in, then I guess I need to take it up with the openstack community?
[15:36] <smoser> how did you detemrine that it does not do that ?
[15:36] <smoser> it was not clear to me.
[15:36] <smoser> the interface that it uses right now is silly... it declares networking configuration in /etc/network/interfaces format.
[15:36] <smoser> which is very limited and guest-specific
[15:36] <smoser> we're wanting to do it in a more generic way. that is something that JayF is working on and pquerna also.
[15:37] <smoser> see https://review.openstack.org/#/c/85673/
[15:37] <m01> so I looked in the config drive, and didn't find it there (see http://pastebin.com/p3PLXjvj)
[15:38] <m01> and then I went and looked at the nova code
[15:38] <m01> https://github.com/openstack/nova/search?utf8=%E2%9C%93&q=net-dhcp&type=Code
[15:39] <m01> that's the search for net-dhcp.ubuntu.template
[15:39] <m01> which is here: https://github.com/openstack/nova/blob/master/nova/virt/baremetal/net-dhcp.ubuntu.template
[15:39] <m01> I believe that's the file you're referring to, and that you're expecting in the config drive, right?
[15:39] <m01> I only found that in the baremetal directory under virt, and I didn't spot anything equiavelent for the other "drivers", or whatever they're called
[15:42] <m01> and yes, I agree that's a silly format..
[15:55] <JayF> m01: you really shouldn't be using nova-bm at this point
[15:55] <JayF> m01: it's being deprecated in Juno in favor of Ironic
[15:55] <m01> I'm not using it
[15:56] <m01> I just noted that it's the only driver I've identified that actually stages the /etc/networks/interfaces file
[15:56] <m01> and (therefore) I don't have one in my config drive
[15:56] <m01> so my non-first network interfaces don't get IP addresses
[15:56] <m01> (and I'm confused about how this is meant to work)
[15:57] <JayF> Ah, Ironic driver does too
[15:57] <JayF> at least it does in my install of it; but it's always possible we patched it downstream
[15:57] <m01> I'm using libvirt anyway I think
[16:01] <smoser> well, we need to fix it.
[16:01] <smoser> i'm sorry for leading you on a goose hunt. but looking at code i dotn see why it would not get rendered.
[16:01] <smoser> dont obviously see why
[16:02] <m01> smoser: which code are you looking at?
[16:02] <smoser> nova/api/metadata/base.py
[16:03] <smoser> bah. someone busted that.
[16:09] <m01> CONF.injected_network_template
[16:09] <m01> aha
[16:09] <m01> interesting
[16:09] <m01> let me see what that's set to
[16:10] <m01> nova.conf:#injected_network_template=/usr/share/nova/interfaces.template
[16:10] <m01> hmmmm
[16:14] <smoser> m01, its busted.
[16:14] <smoser> the metadata service (used by config drive or metadata server)
[16:14] <smoser> will never call netutils.get_injected_network_template
[16:14] <smoser> with a template
[16:14] <smoser> oh wait.
[16:15] <smoser> no.. yeah, so you were right.
[16:15] <smoser> see, not sure why it doenst work
[16:15] <m01> I'll uncomment that setting
[16:15] <m01> and try it
[16:51] <m01> hmm
[16:51] <m01> I uncommented that, restarted all nova services, and my config drive still doesn't have the file
[17:12] <m01> so, I guess it is busted
[17:49] <harmw> smoser: cool
[17:49] <harmw> though I did some work in that area already
[17:49] <smoser> well this builds. just got the build.
[17:50] <smoser> it doesnt run particularly well.
[17:50] <smoser> noticing 2 things:
[17:50] <harmw> ok
[17:50] <smoser> a.) no lsblk or sfdisk
[17:50] <smoser> b.) dropbear is broken
[17:50] <smoser> doesnt start
[17:50] <harmw> ah
[17:50] <harmw> i fixed just that 2nd issue
[17:50] <harmw> and missing lsblk... sounds like some new BB knob
[17:51] <harmw> dropbear needs to be started with some other argument, iirc
[17:51] <harmw> please look at my branch, there should hopefully be something good in it :P
[17:51] <harlowja_> http://online.mirantis.com/openstack-sv-live-feed if u guys interested
[17:51] <harlowja_> from http://openstacksv.com
[17:52] <harmw> whats that?
[17:52] <harlowja_> a sv openstack minidaysummit kind of thing
[17:52] <harlowja_> if u interested
[17:52] <harlowja_> with livestream
[17:52] <harmw> ok, so just what is sv :p
[17:52] <harmw> the rest was obvious :p
[17:52] <harlowja_> *silicon valley
[17:52] <harmw> super vilain?
[17:52] <harmw> ah
[17:52] <harlowja_> lol, super vilan
[17:53] <harmw> :>
[17:54] <harlowja_> :)
[17:55] <harmw> smoser: https://code.launchpad.net/~harmw/cirros/cirros-buildroot-2014.02
[19:29] <harmw> smoser: new c-i tag
[19:29] <harmw> when! :p
[19:30] <smoser> we're closer .
[19:31] <smoser> maybe i should just call it.
[19:31] <harmw> +1
[19:31] <smoser> i was really hoping to get the network config in
[19:31] <harmw> nah, who needs networking


[11:27] <arun__> HELP
[11:27] <arun__> I am trying to setup maas
[11:28] <arun__> and adding one machine node
[11:29] <arun__> but unable to commision the same
[16:57] <JJ__> Trying to troubleshoot a problem with my maas setup relating to the public interface
[16:58] <JJ__> My private interface is managed by MAAS along with DHCP and it seems to work fine, I can run conjure-up and it tries to bootstrap a juju node
[16:59] <JJ__> however it gets stuck at running machine configuration scripts
[16:59] <JJ__> I can ping google.com from the maas server on the public interface, I can't ping google.com from the juju node after ssh in
[17:03] <roaksoax> Calvin`: not supported today unfortuantely
[17:03] <roaksoax> Calvin`: err sorry
[17:04] <roaksoax> arun__: that sound slike the machine cannot access the maas metadata. Make sure /etc/maas/rackd.conf points to itself in an IP that the machine can communicate to
[17:06] <roaksoax> JJ__: so either you setup NAT'ing
[17:06] <roaksoax> JJ__: or you tell juju to use MAAS as a proxy
[17:07] <JJ__> hmmm... currently have 2 subnets in maas
[17:07] <JJ__> one is private with dhcp managed by maas
[17:08] <JJ__> other is public with dns and dhcp provided by switch downstream
[17:09] <mup> Bug #1750884 opened: [2.4, bionic] /etc/resolv.conf not configured correctly in Bionic, leads to no DNS resolution <cloud-init:New> <MAAS:Triaged> <nplan (Ubuntu):New> <systemd (Ubuntu):New> <https://launchpad.net/bugs/1750884>
[17:12] <roaksoax> JJ__: right, but MAAS can install things from the archive because they use the apt proxy, aka MAAS
[17:12] <roaksoax> JJ__: the system itself cannot reach the internet because it doens't have a global proxy configured
[17:13] <roaksoax> JJ__: which is why either you enable NAT'ing, or tell the services you deploy with juju to use the proxy
[17:13] <JJ__> for maas dashboard under settings I have proxy set for MAAS built-in
[17:14] <JJ__> so you can enable NAT'ing through MAAS?
[17:14] <roaksoax> JJ__: yes, that's APT proxy
[17:14] <roaksoax> JJ__: that's not  a "system" proxy
[17:14] <roaksoax> JJ__: https://askubuntu.com/questions/852154/juju-2-0-proxy-for-bootstrap/852931
[17:15] <JJ__> Ok, not that familiar with conjure-up open stack kvm install.  How do you tell the services deployed with juju to use the maas proxy?
[17:15] <roaksoax> JJ__: so you can do two things. IF you want machines to have access to the internet regardless of wether juju deployed them
[17:16] <roaksoax> JJ__: you need to enable NAT
[17:16] <roaksoax> how would you do that? If MAAS is your gateway, you need iptables rules to forward traffic
[17:16] <roaksoax> from your public net, to hte internal net
[17:16] <roaksoax> if you dont want to do that, you can tell juju to use a proxy. And that proxy would be MAAS
[17:20] <JJ__> Like this? https://askubuntu.com/questions/590449/maas-network-and-nat
[17:26] <roaksoax> JJ__: yeah similar
[17:26] <roaksoax> JJ__: personally, I always use NAT
[17:26] <roaksoax> but i jsut run a test environment
[18:23] <JJ__> roaksoax__: in reading both links about proxying and NAT, it seems they apply to a situation where the maas server is the only server with 2 nic's
[18:24] <JJ__> roaksoax__: in my situation all nodes have 2 nic's with one for the private subnet managed by MAAS and the other for public network.
[18:38] <catbus> roaksoax: Hi, wondering if you got my question yesterday and whether I missed the reply because I was on and off the chat.
[19:06] <catbus> roaksoax: I think I found the answer, https://github.com/maas/maas/blob/master/src/provisioningserver/drivers/pod/virsh.py only attach one interface. Even though I have two defined for the VM node (cloud-init is configured accordingly) but only one interface is created along with the VM creation.
[19:30] <JJ__> anyone know why maas wouldn't pass the gateway or allow the gateway to be passed from an external DHCP server?
[19:31] <roaksoax> catbus: we dont use the templates from kvm/libvirt, we use our own
[19:32] <JJ__> after commissioning I have tried auto assign, DHCP & Static for the public interface and none seem to allow the gateway to be passed to the node in its cloud config file
[19:33] <JJ__> maas correctly passes the gateway for the private managed interface
[19:37] <JJ__> if a gateway is passed it appears that NAT works, without a gateway - no NAT
[19:47] <catbus> roaksoax: I don't follow. What do you mean we don't use the templates from kvm/libvirt?
[19:47] <roaksoax> catbus: we dont create vm's based on what you have manually defined in libvirt
[19:47] <roaksoax> e.g. if you have multiple networks in libvirt
[19:47] <roaksoax> we dont use that
[19:48] <catbus> roaksoax: yeah, I have to manually attach the second nic to the VM to use the second bridge I create on the kvm host.
[19:49] <catbus> thanks for the confirmation.
[20:17] <JJ__> roaksoax__: do you know if there is an issue with maas passing gateways ending in .254 instead of .1
[20:41] <roaksoax> JJ__: no known issues, shouldn't really be an issue if maas is the gateway or is not the gateway
[20:41] <roaksoax> JJ__: when you configure DHCP you should tell it where the gateway is
[20:43] <mup> Bug #1711203 opened: Deployments fail when Secure Boot enabled <blocks-hwcert-server> <id-5a28802797729aedf99dcd37> <curtin:Invalid> <dellserver:New> <MAAS:Triaged
[20:43] <mup> by andreserl> <MAAS 2.3:Triaged by andreserl> <maas-images:Fix Released by ltrager> <grub2 (Ubuntu):In Progress by cyphermox> <https://launchpad.net/bugs/1711203>
[21:13] <JJ__> roaksoax__:  I have the gateway configured in maas and in an external dhcp for the public internet interface, it is unmanaged and although I can get maas to assign an ip address from a  range, the gateway doesn't pass through.
[21:13] <JJ__> I tested the external dhcp and it does pass the gateway
[21:18] <JJ__> roaksoax__: is it possible to deploy a node with 2 fabric's, one on a private subnet with dhcp managed by maas and one on a public subnet with dhcp provided externally
[21:24] <JJ__> roaksoax__: according to the maas docs unless I am reading it wrong, it appears for the public subnet where dhcp is not managed by maas it doesn't pass the gateway to the node during deployment.
[21:46] <roaksoax> JJ__: yes it is possible
[21:46] <roaksoax> JJ__: you just have to set the interface to DHCP
[22:01] <JJ__> roaksoax__: when I set the public interface to dhcp then maas doesn't pass the gateway in the cloud config file and I haven't found a persistent way to modify the interface on the node to add it in.