[07:16] <Mirv> cihelp: cleaning up Ubuntu's sponsoring queue, can you set the following to Work in Progress or Rejected? https://code.launchpad.net/~om26er/ubuntu-test-cases/fix_minimal_image_size_test/+merge/235298  and  https://code.launchpad.net/~psivaa/ubuntu-test-cases/remove-ceph-lxc-floodlight/+merge/240144  and  https://code.launchpad.net/~psivaa/ubuntu-test-cases/lvm-grub-preseed-fix/+merge/258620 (or otherw
[07:16] <Mirv> ise handle them)
[07:28] <blr> t
[07:28] <blr> err nevermind that, screen misbehaving. :)
[08:31] <jibel> infinity, could you have a look at bug 1516526 ?
[08:31] <ubot5`> bug 1516526 in Canonical System Image "devel-proposed images fail to build" [Critical,New] https://launchpad.net/bugs/1516526
[08:38] <infinity> jibel: That's ogra's mess, generally.
[08:38] <infinity> (And you also share a timezone :P)
[08:39] <jibel> infinity, okay :)
[08:40] <jibel> ogra_, can you look at ^^
[08:40]  * infinity goes to bed.
[09:10] <psivaa> Mirv: I'll reject my MP's out of them. If the server team need them, they'll have to do it themselves then. Have notified them a few times
[09:19] <Mirv> psivaa: thanks!
[09:22] <psivaa> Mirv: for the other MP, that om26er, you'd need him or QA team
[09:22] <psivaa> s/that  om26er/that  om26er's MP/
[09:23] <om26er> Mirv, psivaa deleted.
[09:23] <Mirv> om26er: thanks for that too!
[09:23]  * Mirv is patch piloting today
[10:09] <bzoltan> Mirv: I need help with that silo55
[10:19] <Mirv> bzoltan: ok
[10:19] <Mirv> sil2100: ok I now got raof to copy-package last xenial package from stable overlay :) needs to be kept watching still if someone happens to land something there.
[10:20] <Mirv> bzoltan: you plan to later ship the new source that ships identically named "ubuntu-sdk-qmake-extras" binary package?
[10:21] <Mirv> I think that was the plan. In that case I don't think we even need to remove the old binary from archives.
[10:23] <bzoltan> Mirv:  we have this project and can land it anytime to anywhere - https://code.launchpad.net/~ubuntu-sdk-team/ubuntu-sdk-qmake-extras/trunk
[10:23] <bzoltan> Mirv:  And yes, it should be landed on the archive too
[10:25] <Mirv> bzoltan: ok. so 055 was published now, feel free to land that next at some point when you have time.
[10:25] <bzoltan> Mirv:  thanks
[11:48] <alf_> cihelp: Hi! All mir-mediumtests-vivid-touch jobs are failing due to what seems to be a CI infrastructure issue (perhaps due to the upgrade?), and this is blocking all Mir CI/autolanding jobs. For example, http://s-jenkins.ubuntu-ci:8080/job/mir-mediumtests-vivid-touch/4821/console . Any idea what's going on?
[11:50] <psivaa> alf_: looking
[11:50] <alf_> psivaa: thanks
[12:00]  * cjwatson truncates the apt-mirror history (used for creating archive snapshots) to 2015-04-01, in an attempt to avoid periodically killing snakefruit
[12:04] <sil2100> cjwatson: ok!
[12:42] <psivaa> alf_: jfyi, i've made a change to that job config and testing that atm
[12:42] <alf_> psivaa: ack, thanks
[12:59] <greyback_> trainguards: any ideas why qtmir isn't migrating: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qtmir ?
[12:59] <greyback_> "invalidated by dependency"?
[12:59] <sil2100> greyback_: looks to me it's caused by liburcu
[13:00] <sil2100> greyback_: I suppose invalidated by dependency means that it's not a valid candidate because one of its dependencies cannot migrate
[13:00] <sil2100> greyback_: in this case it's mir, which is invalidated by liburcu
[13:00] <sil2100> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#liburcu
[13:01] <sil2100> But that's my guess, I didn't really see the 'invalidated by dependency' sign before
[13:01] <greyback_> sil2100: understood, thanks for looking. I shall be patient so
[13:02] <cjwatson> sil2100: yes, that's what it means
[13:03] <cjwatson> greyback_: Ah, so liburcu needs us to upgrade the ppc64el builder guests to wily
[13:03] <greyback_> aha ,now I follow what "not considered" actually implies
[13:03] <cjwatson> greyback_: That's in gradual progress, but I didn't realise it was going to be blocking mir
[13:04] <greyback_> I didn't expect that either tbh
[13:04] <cjwatson> greyback_: Let me see if I can move that on today
[13:04] <greyback_> cjwatson: no big hurry, but thanks
[13:06] <cjwatson> Oh, I know where that ticket stopped, there was a failure to deploy wily guests on arm64 which we needed to look into ... sigh, getting back to downloading a cloud image there
[14:03] <nerochiaro> cihelp: any idea why the logs on the CI run on this MR are not accessible ? https://code.launchpad.net/~uriboni/messaging-app/stickers/+merge/277446
[14:07] <josepht> nerochiaro: jenkins.qa.ubuntu.com currently has the CLI disabled due to a zero-day security issue hence our private jenkins aren't able to publish to it.  If you have VPN access you should be able to replace 'jenkins.qa.ubuntu.com' with 's-jenkins.ubuntu-ci:8080' to see the logs
[14:07] <nerochiaro> josepht: thanks
[14:07] <josepht> nerochiaro: and http:// rather than https://
[14:09] <nerochiaro> josepht: An error occurred during a connection to s-jenkins.ubuntu-ci:8080. SSL received a record that exceeded the maximum permissible length. (Error code: ssl_error_rx_record_too_long
[14:09] <nerochiaro> josepht: on firefox
[14:09] <josepht> nerochiaro: did you use http:// ?
[14:13] <kgunn> trainguards is something wrong with silo 49 ? "in proposed" would have thot it'd be landed this morning
[14:15] <rvr> mardy: ping
[14:15] <nerochiaro> josepht: my mistake. works with hhp
[14:15] <nerochiaro> http, even
[14:15] <nerochiaro> thanks
[14:15] <mardy> rvr: pong
[14:15] <rvr> mardy: Hey
[14:16] <rvr> mardy: I just finished testing the pending silo
[14:16] <rvr> mardy: With silo 1, it doesn't crash with the old and new click, so it's ok
[14:16] <rvr> mardy: However, it doesn't propmpt to create any Flickr account
[14:16] <rvr> mardy: Can you confirm that is right?
[14:17] <mardy> rvr: yes, because of the apparmor denial that you saw
[14:18] <rvr> mardy: I see ... Error: "An AppArmor policy prevents this sender from sending this message to this recipient; type="method_call", sender=":1.230"
[14:18] <rvr> mardy: Another question. Test ubuntu-system-settings-online-accounts/password-query has been failing for a while. Can you fix it or update the test case?
[14:18] <mardy> rvr: the apparmor thing is bug 1512667
[14:19] <ubot5`> bug 1512667 in apparmor-easyprof-ubuntu (Ubuntu) "Enable Online Accounts v2 on vivid overlay PPA" [Undecided,New] https://launchpad.net/bugs/1512667
[14:19] <psivaa> alf_: so http://s-jenkins.ubuntu-ci:8080/job/mir-mediumtests-vivid-touch/4823/console now ran the jobs that were required but one of them has failuers
[14:19] <mardy> rvr: it's actually fixed with silo 58
[14:20] <mardy> rvr: the test is correct, the current trunk is wrong
[14:20] <rvr> mardy: Ah, great. Approving this silo :)
[14:20] <psivaa> alf_: the actual failure is in http://s-jenkins.ubuntu-ci:8080/job/mir-mediumtests-runner-touch/7404/consoleText
[14:20] <mardy> rvr: cool, thanks!
[14:21] <psivaa> alf_: could have caused due to '/bin/bash: line 1: 5897 Segmentation fault (core dumped) mir_demo_server --test-client /usr/bin/mir_demo_client_eglflash' and the likes
[14:22] <alf_> psivaa: Thanks, that's a known/pre-existing failure. As long as the build runs I am happy. Thanks for fixing this.
[14:24] <psivaa> alf_: np
[14:28] <kgunn> trainguards just fyi, silo 49 sticking in proposed causing some issues for high priority item behind it...effecting silo 20
[14:39] <cjwatson> kgunn: I explained the current blocker for that above, not sure what you expect trainguards to do ...
[14:40] <kgunn> cjwatson: thanks, sorry for the noise
[14:41] <mterry> sil2100, how come devel-proposed hasn't had images in a week? (if because of the fail-to-boot bug, that is recently maybe fixed?)
[14:41] <kgunn> cjwatson: as for expectations, what is the best practice for getting help when things get stuck in proposed (in a generic sense)
[14:41] <kgunn> ?
[14:42] <cjwatson> kgunn: well it entirely depends.  greyback_ asked here and that was reasonable enough.  learning more about how to debug it yourselves is good too (e.g. https://wiki.ubuntu.com/ProposedMigration)
[14:42] <jibel> mterry, it's bug 1516526
[14:42] <ubot5`> bug 1516526 in livecd-rootfs (Ubuntu) "xenial ubuntu-touch rootfs fail to build" [Critical,In progress] https://launchpad.net/bugs/1516526
[14:43] <cjwatson> kgunn: but it's a bit like asking what the best practice for getting help with a build failure is, there can be a variety of causes
[14:43] <cjwatson> kgunn: this one is unusually opaque, I'll admit
[14:43] <mterry> jibel, ah cool thanks.  Poor devel-proposed can't catch a break
[14:43] <ogra_> jibel, mterry, i'll merge that in a moment (sorry, was busy weith meetings)
[14:44] <cjwatson> kgunn: (the question I asked to Odd_Bloke on #ubuntu-devel just now pertains to this, a little indirectly)
[14:44] <jibel> sil2100, can you rebuild a devel-porposed image once it's fixed, better know sooner than later if there is anything left to have a bootable image
[14:47] <ogra_> sil2100, jibel, mterry livecd-rootfs fix uploaded
[16:26] <jibel> bfiller, Kaleo ^
[16:26] <sil2100> \o/
[16:26] <sil2100> Should I publish?
[16:26] <bfiller> sil2100: ppa hasn't published yet
[16:27] <bfiller> sil2100: actually it has
[16:27] <bfiller> sil2100: yes please
[16:27] <sil2100> bfiller: could you upload to the store? Or do you need this to land first?
[16:28] <sil2100> Publishing in progress
[16:28] <bfiller> sil2100: I need it to land in trunk then need to build a click from trunk
[16:33] <bfiller> sil2100: can you force merge please on the camera silo?
[16:34] <sil2100> bfiller: hm, ok, in this case let's do that
[16:36] <bfiller> sil2100, jibel : building final click now
[16:37] <sil2100> \o/
[16:40] <sil2100> jibel, davmor2, robru, rvr: I suppose all OTA-8 related work is known now, let's skip the meeting and just concentrate on getting an image built and copied to RC
[16:40] <rvr> sil2100: Ok
[16:42] <jibel> sil2100, soulds like a plan
[16:42] <jibel> sounds*
[16:50] <bfiller> jibel, sil2100: camera-app uploaded to store, needs approval from popey
[16:50] <popey> on it
[16:51] <popey> bfiller, approved
[16:52] <bfiller> popey: ty
[16:55] <Kaleo> bfiller, jibel: outstanding!
[16:56] <Kaleo> popey, thank you :)
[16:58] <oSoMoN> rvr, hey man, how is testing of silo 39 going? need anything from me?
[16:58] <rvr> oSoMoN: Finished
[16:58] <rvr> oSoMoN: It's ok
[16:58] <oSoMoN> excellent, thanks a lot!
[17:00] <jibel> bfiller, sil2100 for next OTA it is not 2 days earlier wee need for freeze but 2 weeks ;)
[17:01] <oSoMoN> jibel, what’s this "Requesting autopkgtests for this silo..." status on silo 39? is this new? should I wait for something to complete before I request publication?
[17:01] <jibel> oSoMoN, it's a bug in the UI apparently
[17:02] <jibel> oSoMoN, I tried the new autopkgtest feature robru added to the train, but apparently it is not ready for prime time
[17:02] <jibel> oSoMoN, you can publish if it's ready
[17:02] <oSoMoN> ok, thanks!
[17:04] <oSoMoN> trainguards: who can publish silo 39 for me?
[17:05] <sil2100> oSoMoN: hmm... I think we need to poke mterry or kenvandine again :)
[17:05] <sil2100> kenvandine, mterry: ^
[17:05] <oSoMoN> sil2100, can you confirm that with the configuration of the request, the packages will land in the xenial archive and in the overlay PPA for vivid?
[17:05] <oSoMoN> (never too sure about it)
[17:10] <robru> oSoMoN: you ned a core dev, I usually poke kenvandine at this time of day
[17:10]  * oSoMoN pokes kenvandine
[17:11] <robru> oSoMoN: yes it's configured correctly. all you need to remember is that the vivid half of a dual always goes to overlay, so the destppa field controls only where xenial goes.
[17:12] <oSoMoN> robru, that’s what I thought, thanks for confirming
[17:12] <robru> oSoMoN: you're welcome
[17:12] <robru> kgunn: if you are particularly blocked by silo 49 we can force merge the silo but would rather not if we can avoid it
[17:15] <mterry> sil2100, I can look
[17:15] <mterry> sil2100, 39?
[17:18] <robru> mterry: yeah, thanks
[17:20] <sil2100> bfiller: did the click get approved?
[17:20] <bfiller> sil2100: yes
[17:20] <sil2100> Can I kick a new image then?
[17:20] <sil2100> hmmm
[17:22] <sil2100> Copying to the stable snapshot now
[17:24] <sil2100> Will be kicking the image shortly...
[17:25] <kgunn> robru: we gotta workaroudn
[17:25] <kgunn> thanks tho
[17:26] <cjwatson> kgunn: https://portal.admin.canonical.com/85976 if you want to track the work we're doing to fix liburcu
[17:26] <kgunn> ta
[17:33] <oSoMoN> mterry, thanks!
[18:15] <robru> sil2100: slangasek: is there anything for the meeting? I propose we skip
[18:15] <slangasek> robru: how's silo autopkgtest coming?
[18:15] <robru> slangasek: you mean britney?
[18:15] <slangasek> yes
[18:16] <robru> slangasek: still in the investigation phase. a little behind on the silo status rework I started last week
[18:16] <slangasek> robru: ok.  I'm ok to cancel for today if sil2100 is, then, but let's sync up later in the week
[18:17] <robru> slangasek: alright
[18:21] <dobey> did ota8 get released yet?
[18:24] <robru> brb
[18:25] <sil2100> ACK here
[18:28] <sil2100> I'm anyway busy with preparing the OTA-8 re-spin now ;)
[18:54] <kenvandine> cihelp: anyone know why the jenkins links to CI jobs are broken?
[19:05] <fginther> kenvandine, There are some pending updates needed to the public jenkins service that is preventing the internal jenkins from publishing out to the public one. This is all after having to apply a critical update
[19:05] <kenvandine> that's what i was wondering
[19:06] <kenvandine> but trying to find the same on the private jenkins looks weird
[19:07] <kenvandine> fginther, looking at the downstream build view of the latest failed, shows a bunch of NOT_BUILT status
[19:07] <kenvandine> fginther, http://s-jenkins.ubuntu-ci:8080/job/ubuntu-system-settings-ci/lastFailedBuild/downstreambuildview/
[19:07] <fginther> kenvandine, oh, there was a secondary problem too
[19:08] <fginther> kenvandine, I think that's the other problem, but am looking
[19:08] <kenvandine> ok
[19:08] <kenvandine> fginther, is there a way to find the failed jobs?
[19:09] <kenvandine> http://s-jenkins.ubuntu-ci:8080/job/ubuntu-system-settings-ci/2483/
[19:09] <kenvandine> for example
[19:14] <fginther> kenvandine, you can just do a string replace from "https://jenkins.qa.ubuntu.com" to "http://s-jenkins.ubuntu-ci:8080/"
[19:15] <fginther> kenvandine, the other problem I mentioned was that the jobs to execute the autopilot tests on phones was missing from some of the job configurations (and showing up as missing jobs)
[19:27] <kenvandine> fginther, thx
[19:28] <kenvandine> fginther, ah... looks like there was a configuration issue for settings
[19:28] <kenvandine> ERROR: Build aborted. No projects to trigger. Check your configuration!
[19:29] <kenvandine> fginther, is that being worked on already?
[19:29] <fginther> kenvandine, that was caused by the second problem, which has been fixed. Retriggering the parent job should work to re-run everything now
[19:32] <kenvandine> fginther, thx


[00:20] <wallyworld> menn0: only took 3 attempts, but fix has landed, will take a bit to wash through CI, but critical regression fix committed
[00:21] <menn0> wallyworld: glad it's in
[00:21] <wallyworld> must. not. comment.
[00:22] <wallyworld> sadly we still have work to do to make out test suite reliable
[00:27] <bodie_> rick_h_, simply that a change to the charm repo in master is causing juju core tests written against the bit that was removed, to fail
[00:28] <bodie_> it's not really critical to what I'm trying to do right now, but I want to land some changes to charm, and if v4 master isn't working perhaps I shouldn't rebase my changes on master
[00:29] <bodie_> I'll try to get ahold of rogpeppe / uros (who's that?)
[00:42] <menn0> hmmm, although LP shows no critical regressions the buildbot is still blocking merges due to bug 1388493']
[00:42] <mup> Bug #1388493: generate-tools --streams loses content of other streams <ci> <metadata> <regression> <juju-core:Fix Committed by wallyworld> <https://launchpad.net/bugs/1388493>
[00:42] <menn0> and bug 1388073
[00:42] <mup> Bug #1388073: set-env no longer accepts empty values <ci> <compatibility> <regression> <set-env> <juju-core:Fix Committed by tasdomas> <https://launchpad.net/bugs/1388073>
[00:43] <rick_h_> bodie_: urulama sorry
[00:44] <rick_h_> bodie_: roger's lead, the two have been working with charm for some charmstore stuff/etc and are up on the charm package info these days.
[00:52] <bodie_> ah, okay.  thanks rick_h_ :)
[02:58] <menn0> wallyworld_: do we officially support concurrent local provider environments on the one host machine?
[02:59] <wallyworld_> um, no
[02:59] <wallyworld_> not to my knowledge
[02:59] <wallyworld_> i'm not sure it would even work
[02:59] <davecheney> menn0: it works
[02:59] <davecheney> but you'd be bonkers to try
[02:59] <davecheney> we did it in japan
[02:59] <davecheney> 27 local providers
[02:59] <wallyworld_> \o/
[02:59] <davecheney> * footnote: that was in versino 1.14
[03:00] <davecheney> gawdknows what's changed since then
[03:00] <menn0> wallyworld_, davecheney: the reason I ask is that i've just figured out why the rsyslog worker works for all but 1 environ
[03:00] <stokachu> im going to try it
[03:01] <menn0> wallyworld_, davecheney: it writes out configuration files using different certs but all listening on the same rsyslog port
[03:01] <menn0> wallyworld_, davecheney: so only one environment has working logging
[03:01] <davecheney> menn0: rump-row
[03:01] <wallyworld_> menn0: ah, i'm currently wondering why juju debug-log is broken
[03:01] <menn0> and even if you go back to one env
[03:02] <wallyworld_> nodes are failing to send stuff to machine 0 due to certificate issues
[03:02] <menn0> the old rsyslog config doesn't appear to get removed
[03:02] <menn0> so logging is broken from then on
[03:02] <menn0> you need to clean up /etc/rsyslog.d manually
[03:02] <menn0> it's taken me quite some time to figure that out :)
[03:02] <wallyworld_> menn0: i'm seeing this
[03:02] <wallyworld_> 2014-11-03 02:56:34 ERROR juju.worker runner.go:219 exited "rsyslog": x509: certificate is valid for ip-10-46-174-79.ec2.internal, not juju-rsyslog
[03:02] <menn0> wallyworld_: that's the one
[03:03] <wallyworld_> menn0: this is a critical regression for alpha3
[03:03] <wallyworld_> as debug log is just broken
[03:03] <menn0> wallyworld_: it's only for the local provider though
[03:03] <wallyworld_> menn0: nope, also aws
[03:03] <wallyworld_> and probably evrything else too :-(
[03:03] <menn0> wallyworld_: sorry
[03:03] <wallyworld_> that line i just pasted was from an aws deploy
[03:04] <menn0> wallyworld_: I just re-read that error.
[03:04] <menn0> wallyworld_: I was seeing something different
[03:04] <wallyworld_> ah, ok
[03:04] <menn0> x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "juju-generated CA for environment \"rsyslog\"")
[03:04] <wallyworld_> it may well be the same root cause, not sure
[03:04] <menn0> wallyworld_: don't think so
[03:05] <wallyworld_> regardless rsyslog and hence debug log is stuffed
[03:05] <menn0> wallyworld_: the thing i've been investigating is definitely local provider specific when you have multiple environments set up
[03:05] <menn0> sure
[03:05] <wallyworld_> :-(
[03:08] <menn0> wallyworld_: the client side of the connection sets the expected server name to a hardcoded value of "juju-rsyslog"
[03:09] <menn0> wallyworld_: see composeTLS() in worker/rsyslog/worker.go
[03:09] <wallyworld_> menn0: yeah, i'm backing out that change to see if it works
[03:09] <wallyworld_> was changed 10th october
[03:09] <wallyworld_> so recently
[03:10]  * wallyworld_ waits imatiently for aws to start up an instance or two
[03:11] <davecheney> %  git push --set-upstream origin 100-fix-issue-69
[03:11] <davecheney> fatal: https://gopkg.in/juju/charm.v4/info/refs not valid: is this a git repository?
[03:11] <davecheney> I hate gopkg.in
[03:11] <davecheney> https://github.com/juju/charm/pull/70
[03:11] <davecheney> anyone ?
[03:14] <davecheney> wallyworld_: thanks for the review
[03:14] <davecheney> i'm going to wait for rog
[03:14] <davecheney> this is his baby
[03:14] <davecheney> and I have just slapped it, soundly
[03:15] <wallyworld_> sure, looked ok to me.... but im not 100% familiar with it
[03:18] <davecheney> wallyworld_: i'm changing the semantics of the method from what it promised, but didn't deliver
[03:19] <davecheney> to what it does
[03:19] <wallyworld_> right :-)
[03:19] <davecheney> i tried to do it the other way, ie make the methods return a *copy* of the receiver
[03:19] <davecheney> but of course all the tests expect the current behavioru
[03:19] <davecheney> so all broke
[03:19] <davecheney> so, this change renames the method to _say_ what they _do_
[03:20] <davecheney> as well as making them thread safe
[03:20]  * wallyworld_ nods
[03:24] <wallyworld_> davecheney: do you know anything about unit tags gaining a suffix? eg unit-flannel-2[2016]
[03:25] <wallyworld_> menn0: that one line change to remove "juju-rsyslog" worked
[03:25] <wallyworld_> but i'm not sure of the implications of just removing it
[03:26] <menn0> wallyworld_: good.
[03:27] <wallyworld_> the commit message says
[03:27] <wallyworld_> tls.Config clients should use a meaningful ServerName This also fixes an issue with the rsyslog tls.Config not using a ServerName at all.
[03:27] <wallyworld_> well, trouble is, if the rsyslog tls.Config uses a service name, it breaks
[03:27] <menn0> wallyworld_: the docstring for composeTLS (added in that rev) says that setting ServerName is required to support pre-1.20.9 certs
[03:28] <menn0> wallyworld_: so I suspect taking that line out is going to bring back the problem of rsyslog cert issues when upgrading from 1.20 to 1.21
[03:28] <menn0> wallyworld_: better check with wayne i guess
[03:28] <wallyworld_> yeah
[03:28] <menn0> i have to run some errands
[03:28] <wallyworld_> i'm not an expert on this stuff
[03:29] <menn0> neither am i
[03:29]  * wallyworld_ raiss a criitical bug
[03:29] <menn0> sigh
[03:29] <menn0> back in a bit
[03:36] <davecheney> wallyworld_: tag ? nope
[03:37] <davecheney> 'fraid I wasn't watching
[03:37] <davecheney> smells like an actions thing
[03:37] <wallyworld_> davecheney: np. unit agent logs now have tags like "unit-mysql-0[15930]"
[03:37] <wallyworld_> could be actions related i guess, not sure
[03:38] <wallyworld_> davecheney: a quick look at the names package doesn't seem to reveal any related changes
[03:39] <davecheney> yup
[03:40] <davecheney> doesn't look like that is whyere they are coming from
[03:40] <davecheney> it is rsyslog ?
[03:40] <davecheney> putting the PID on the end ?
[03:41] <wallyworld_> yeah, i just came to the same conclusion ook at the code, so it must be a logging artifact
[03:42] <davecheney> [$PID] is the smell
[03:44] <wallyworld_> the whle rsyslog thing has been radically changed recently
[05:50] <wallyworld_> davecheney: what's the official way to construct a name from a tag? eg if I have "unit-mysql-1", I want to get "mysql/1"
[06:58] <wallyworld_> jam: connection dropped, sorry if this comes twice, how's your TLS knowledge? i'm not sure what to do with bug 1388688 - 1.21 is broken, but apparently the change was made so that 1.20.9 could be connected to
[06:58] <mup> Bug #1388688: juju debug-log is broken <debug-log> <regression> <rsyslog> <juju-core:Triaged> <https://launchpad.net/bugs/1388688>
[07:01] <jam> wallyworld_: it didn't, looking
[07:02] <jam> wallyworld_: is this a fresh bootstrap, an upgrade, an ... ?
[07:03] <wallyworld_> jam: fresh bootstrap
[07:03] <wallyworld_> 1.21 tip
[07:03] <davecheney> wallyworld_: names.NewUnitTag(string).String()
[07:03] <davecheney> wallyworld_: it depends
[07:03] <davecheney> if you have "unit-mysql-1"
[07:03] <davecheney> where did you get it from ?
[07:03] <jam> wallyworld_: I worked with wwitzel a bit on trying to figure out what the right fix was for this.
[07:04] <wallyworld_> davecheney: it's the prefix of a log file entry
[07:04] <jam> specifically we have a variety of issues around TLS and cert names
[07:04] <jam> they want you to either put a hostname in the field
[07:04] <jam> or put IP addresses in another field
[07:04] <jam> but if we do IP addresses we have to create a new certificate anytime any IP addresses change
[07:04] <wallyworld_> for juju < 1.20.9 only?
[07:05] <jam> we *were* putting the phrase "anything" as the server hostname for API connections, but nothing for stuff like rsyslog
[07:05] <jam> and then generating certs with "Hostname: *"
[07:05] <jam> which matches "anything"
[07:05] <jam> at one point, someone switched us to start using IP addresses
[07:05] <jam> but then upgrade breaks
[07:05] <wallyworld_> oh :-(
[07:06] <jam> because it uses one cert that doesn't have IP addresses
[07:06] <jam> and when we discussed it
[07:06] <jam> it felt a lot better to use
[07:06] <jam> Hostname: *
[07:06] <jam> and meaningful "ServerName" fields
[07:06] <jam> and then maybe we could eventually migrate to Hostname: juju-meaningfulname instead of *
[07:06] <jam> now, it looks like the cert that existed actually put a DNSName into the Hostname field
[07:07] <jam> instead of Hostname: *
[07:07] <wallyworld_> and we generate the cert?
[07:07] <jam> but (a) not all clouds give you DNS names, and (b) the DNS name is specific to a machine, and not to all of the API servers in HA mode
[07:07] <jam> wallyworld_: yeah, we generate the cert and how we connect to it
[07:07] <jam> but it looks like we're having trouble because we changed it, and now we need to support all the possible ways it could have been generated.
[07:08] <jam> I thought the IP address stuff was only in the 1.21-alpha stuff
[07:08] <jam> I'd have to dig deep to know what was done when and whereb
[07:08] <jam> because we seem to have changed these things in *micro* releases, which isn't a very good practice
[07:08] <jam> wallyworld_: is it possible to wait for wwitzel, or do you need it asap ?
[07:09] <wallyworld_> jam: i've marked it as a critical regression and in my view, we cannot release alpha3 till it's fixed. we can talk to wayne when he comes online
[07:09] <wallyworld_> cause debug log is broken
[07:10] <jam> wallyworld_: to be clear, the issue you are seeing is that 1.21-alpha3 agents are unable to talk to a 1.21-alpha3 API server's rsyslog daemon, correct ?
[07:10] <wallyworld_> jam: yes, a fresh bootstrap with upload tools
[07:10] <davecheney> wallyworld_: you can use names.ParseTag(...)
[07:10] <wallyworld_> on local provider and AWS
[07:11] <wallyworld_> davecheney: thanks, will look into that
[07:23] <dimitern> morning
[08:31] <TheMue> morning
[09:06] <voidspace> morning all
[09:24] <mattyw> morning everyone
[09:29] <fwereade> tasdomas, ping
[09:30]  * fwereade waves at everybody
[09:52] <voidspace> fwereade: hah, when I started reviewing wayne's branch there were no reviews for it
[09:52] <voidspace> fwereade: when I publish my review some have appeared...
[09:52] <fwereade> voidspace, extra reviews are not in any way a problem
[09:53] <voidspace> heh :-)
[10:02] <jam> hi fwereade
[10:02] <fwereade> jam, heyhey
[10:55] <voidspace> jam: I'm there
[11:55] <mattyw> fwereade, just noticed you pinging tasdomas  - I think he's off today
[11:58] <fwereade> mattyw, cheers
[12:06] <mattyw> fwereade, do we have a way to enabling client logging to a file?
[12:07] <fwereade> mattyw, I *think* we do but I don't recall offhand
[12:23] <mattyw> fwereade, --log-file thing.log
[12:24] <fwereade> mattyw, heh, thanks
[12:40] <fwereade> bah, so, the bot's complaining about 1388073 and 1388493 -- both of which STM to be fix committed
[12:40] <fwereade> anyone?
[12:46] <jam> fwereade: bot only lets go once it is Fix Released for a while now
[12:47] <jam> fwereade: which IIRC, is Curtis seeing the actual CI test runs pass
[12:47] <fwereade> jam, ah, ok, makes sense
[12:50] <wallyworld_> fwereade: one remaining critical bug open on 1.21 is bug 1388688
[12:50] <mup> Bug #1388688: juju debug-log is broken <debug-log> <regression> <rsyslog> <juju-core:Triaged> <https://launchpad.net/bugs/1388688>
[12:50] <wallyworld_> sorta need to ask wayne about it
[12:50]  * fwereade sees `tls.Config` in the first few lines and grumbles expressively to himself
[12:51] <wallyworld_> if not for that, we could release 1.21 alpha i think/hope according to the dashboard
[12:51] <fwereade> wallyworld_, ok, does he have a mail waiting for when he wakes up?
[12:52] <wallyworld_> no, i was waiting for him to show up
[12:52] <wallyworld_> i talked to jam a little also
[12:52] <fwereade> wallyworld_, that's very good of you, but isn't it late?
[12:52] <wallyworld_> well, kinda
[12:52] <wallyworld_> i also want to talk to curtis
[12:53] <wallyworld_> to make sure everything else is ok for the release
[13:39]  * fwereade points wwitzel3 and wallyworld_ in each other's direction
[13:40] <wallyworld_> wwitzel3: bug 1388688 is a critical regression because debug log is broken, i'm not sure how to fix to make both 1.21 and 1.20 happy
[13:40] <mup> Bug #1388688: juju debug-log is broken <debug-log> <regression> <rsyslog> <juju-core:Triaged> <https://launchpad.net/bugs/1388688>
[13:40] <wwitzel3> wallyworld_: ok, taking a look
[13:40] <wallyworld_> ty
[13:42] <wallyworld_> wwitzel3: here's some discussion from earlier http://pastebin.ubuntu.com/8803081/
[13:45] <wwitzel3> wallyworld_: thank you
[13:45] <wallyworld_> np, thanks for looking
[14:10] <wwitzel3> I should of never upgraded, ugh
[14:11] <wwitzel3> my xmonand broke, my graphics is no longer using hardware rendering, my system python installation broke, I get weird kernel errors randomly, oh and the whole machine freezes up every 2-4 hours
[14:42] <sinzui> jam, alexisb can you arrange for someone to address bug 1388853. We still haven't had a single blessed revision for alpha3
[14:42] <mup> Bug #1388853: ppc64el unittests consistently fails <ci> <ppc64el> <regression> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1388853>
[14:56] <wwitzel3> wallyworld_: ok, well I have a "fix" for it based on what jam was saying.
[14:56] <wwitzel3> wallyworld_: keeps both the clients happy
[15:08] <wwitzel3> natefinch, perrito666: ping
[15:08] <natefinch> wwitzel3: coming
[15:08] <natefinch> wwitzel3: perrito666 is at ods
[15:08] <wwitzel3> thumper and me are on-call reviewers today, so will need someone to take a look at http://reviews.vapour.ws/r/324/, it fixes bug #1388688
[15:08] <mup> Bug #1388688: juju debug-log is broken <debug-log> <regression> <rsyslog> <juju-core:Triaged by wwitzel3> <https://launchpad.net/bugs/1388688>
[15:19] <wwitzel3> ping fwereade, wallyworld_, voidspace ^
[15:22] <fwereade> wwitzel3, tests?
[15:23] <fwereade> wwitzel3, (and are you sure it'll work across all the versions in play?)
[15:25] <wwitzel3> fwereade: yes, I confirmed it works for both versions
[15:25] <fwereade> wwitzel3, awesome
[15:25] <fwereade> wwitzel3, needs a unit test too, would lgtm with that
[15:25] <wwitzel3> fwereade: as for tests, no idea how we would test it
[15:26] <voidspace> wwitzel3: are you appending * inside the body of the loop?
[15:26] <fwereade> wwitzel3, and that's a good point too
[15:26] <wwitzel3> voidspace: oops, I was, need to push the updated diff, I noticed it after I initially pushed :)
[15:27] <voidspace> cool :-)
[15:28] <fwereade> wwitzel3, it looks like we're writing that stuff out somewhere
[15:28] <fwereade> wwitzel3, can the tests not read the certs back in and check their properties?
[15:28] <wwitzel3> fwereade: yep, we can do that
[15:29] <wwitzel3> fwereade: you're right, that is better than nothing
[15:29] <fwereade> wwitzel3, cool, thanks
[15:32] <alexisb> sinzui, looking
[15:37] <alexisb> sinzui, I am not seeing the attachment on that bug
[15:39] <sinzui> alexisb, :( I will try again
[15:43] <sinzui> alexisb, I added the log this time
[15:43] <alexisb> awesome, thanks sinzui
[15:48] <wwitzel3> fwereade, voidspace: added tests that check the issuer, subject, and dnsnames for the cert.
[15:50] <voidspace> wwitzel3: did you push the tests?
[15:50] <voidspace> wwitzel3: don't think they're showing on RB yet
[15:50] <voidspace> checking github
[15:50] <alexisb> all, please consider  bug 1388853 top priority
[15:50] <mup> Bug #1388853: ppc64el unittests consistently fails <ci> <ppc64el> <regression> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1388853>
[15:50] <wwitzel3> voidspace: weird, yeah, they aren't showing in RB
[15:50] <alexisb> as 1.21 is still blocked and release was targeted for last weds
[15:51] <voidspace> wwitzel3: yeah, I'm looking at it on github
[15:51] <voidspace> wwitzel3: github sometimes throttles (drops) API calls
[15:51] <mgz> alexisb: I have a plan of sorts of that bug
[15:51] <alexisb> mgz, please share
[15:52] <mgz> I'm going to change the compiler version that runs the tests
[15:52] <mgz> we fixed the juju parts of the bug on friday,
[15:53] <mgz> it's just the current version of gccgo on trusty blows up with these tests - that's a change since brussels
[15:55] <alexisb> mgz ack, how can the core team help at this stage?
[15:55] <voidspace> wwitzel3: looks good to me
[15:56] <voidspace> wwitzel3: the code adds a * after any HostPorts
[15:56] <voidspace> wwitzel3: worth having a hostport in the test, so that code is exercised?
[15:57] <mgz> alexisb: will yell if I need it
[15:57] <alexisb> mgz, ack, thanks
[16:01] <voidspace> dimitern: ping
[16:02] <dimitern> voidspace, pong
[16:02] <voidspace> dimitern: I have ec2-api-tools installed
[16:02] <voidspace> dimitern: and the right AWC environment variables set
[16:03] <dimitern> voidspace, yeah?
[16:03] <voidspace> dimitern: and I can access the account using those credentials from code (goamz)
[16:03] <voidspace> dimitern: the command line client always reports
[16:03] <voidspace> Client.Unauthorized: Not Authorized
[16:03] <voidspace> dimitern: do you have any idea why that might be?
[16:03] <voidspace> the intarwebz are not helping on this
[16:03] <voidspace> the only references I can find are to Java exceptions
[16:04] <bodie_> who should I discuss changes to charm with? rogpeppe?
[16:04] <rogpeppe> bodie_: if you like :)
[16:04] <dimitern> voidspace, not sure if this can be the cause, but I had to set a couple of additional env vars for aws:
[16:04] <voidspace> dimitern: ah
[16:04] <voidspace> maybe
[16:05] <voidspace> dimitern: you remember which ones?
[16:06] <bodie_> rogpeppe, there is a change in charm v4 that breaks juju core state/charm_test TestTestingCharm, which tests against the "metered-custom" dummy charm that was removed from charm in 190b3a5d
[16:06] <bodie_> rogpeppe, I want to make some additions to charm but I wasn't sure what to base them on since it seems like v4 is now not compatible (the commit in godeps is fine)
[16:07] <dimitern> voidspace, try these - http://paste.ubuntu.com/8804761/
[16:08] <bodie_> rogpeppe, should I just open a PR to replace the missing piece?  I think we might want to move to v5 anyway since I have some Actions related changes I want to make charm more correct.  I don't want deprecated bad bits to build up, but they are not serious... just irritating
[16:08] <rogpeppe> bodie_: are you saying that there have been some backwardly incompatible changes made to v4, or that you want to make some backwardly incompatible changes in the charm package?
[16:08] <voidspace> dimitern: that worked!
[16:08] <voidspace> dimitern: it might be worth updating the container addressability doc, which only mentions the key pair
[16:08] <voidspace> dimitern: I can do that
[16:09] <voidspace> dimitern: I think it was the EC2_KEYPAIR one which did it
[16:09] <voidspace> but I'll verify
[16:09] <bodie_> rogpeppe, both.  but the backwards incompatibility that was added to v4, can easily be reversed.  and my changes don't have to be backwardly incompatible, but I would ideally like to remove the pieces they deprecate.
[16:09] <voidspace> dimitern: nope, that on its own wasn't enough
[16:09] <bodie_> rogpeppe, does that clarify?
[16:09] <voidspace> dimitern: it was EC2_URL
[16:10] <rogpeppe> bodie_: in a call currently, will get back to you in 15 mins or so
[16:10] <bodie_> sure thing :)
[16:12] <dimitern> voidspace, I think it was one of the key vars
[16:12] <dimitern> voidspace, one name is deprecated, but accepted the other is the "new" one you're supposed to use
[16:12] <dimitern> voidspace, I have some connection issues - did you see what I sent last?
[16:12] <dimitern> voidspace, ah, ok
[16:12] <dimitern> voidspace, please update the doc then :)
[16:12] <voidspace> dimitern: no, I have the key vars in my env already - just adding EC2_URL is sufficient to make it work
[16:12] <voidspace> dimitern: done
[16:12] <dimitern> voidspace, cheers!
[16:13] <wwitzel3> voidspace: yeah, probably, it is funny .. we have NewRsyslogConfigHandler = newRsyslogConfigHandler in export_test.go, but then we never actually override or test it :P
[16:13] <voidspace> wwitzel3: hah
[16:13] <wwitzel3> voidspace: I was hoping that wasn't the case, guess I'll have to write a suite for it
[16:14] <bodie_> rogpeppe, fwiw, I think it would be good to roll forward to v5 since there are some old half-baked Actions definitions in a dummy charm in v4, that I want to remove, not deprecate.  but as long as it is clear that they are old and smelly, it doesn't change the actual behavior of charm.  it's testing-related only.
[16:14] <bodie_> same goes for the breaking commit in v4.
[16:14] <rogpeppe> bodie_: i'm not sure we need to hold to quite such a stringent backwards compatibility policy for testing-related code
[16:15] <bodie_> rogpeppe, I think TheMue had a good point: tests shouldn't be written against implementation details (dummy charms) of v4 anyway :)
[16:16] <bodie_> but, maybe that's a little bit of a funky point (dummy charms) which I'm not sure how to approach
[16:17] <bodie_> anyway, I will make my changes compatible, but there is some cruft building up and I'd like the charmers to have a proper example of what Actions should look like in a charm
[16:17] <rogpeppe> bodie_: out of the call now
[16:18] <rogpeppe> bodie_: i'm generally in agreement with TheMue's point, and i've been pondering a good direction for a while now.
[16:19] <bodie_> yeah, it is a pretty subtle and maybe small pothole
[16:19] <rogpeppe> bodie_: i recently made a backwardly incompatible change to one of the testing repo charms too
[16:19] <rogpeppe> bodie_: i don't think we need to count the testing-related packages as part of the v4 contract.
[16:20] <rogpeppe> bodie_: although it's good to keep backwardly compatible when we can, obviously
[16:21] <bodie_> my only concern is that if I want to make changes, I can't work on top of charm master if it's breaking juju master
[16:41] <voidspace> dimitern: the task breakdown and estimates in the Juju Container Addressability document are based
[16:41] <voidspace> dimitern: on AllocateAddress picking an address for us, and not on us managing addresses (and picking one from the right subnet)
[16:42] <voidspace> dimitern: I'm not sure that changes a lot regarding estimates - except it means more work in the container provisioner
[16:42] <voidspace> dimitern: unless I'm reading it wrong
[16:42] <dimitern> voidspace, that's correct, we might need to inflate the estimate there
[16:42] <voidspace> dimitern: right
[16:42] <voidspace> dimitern: there is a "Track the IP addresses we have allocated for each subnet" which could cover it
[16:43] <dimitern> voidspace, does the estimate there seem sane to you?
[16:44] <voidspace> dimitern: 2-3wks probably has enough wiggle room to cover it :-)
[16:44] <voidspace> dimitern: the other estimates seem ok to me
[16:44] <voidspace> in a hand-wavy kind of way...
[16:44] <dimitern> voidspace, :) cheers!
[16:48] <rogpeppe> bodie_: sure you can - juju master is only broken when the juju-core deps are updated, no?
[16:48] <rogpeppe> bodie_: the most important thing about compatibility is keeping go get working
[16:48] <bodie_> gotya :)
[16:50] <rogpeppe> bodie_: with the testing deps, the broken deps are usually only one level, between tests and testing package
[16:50] <rogpeppe> bodie_: so, just to summarise, your backwardly incompatible changes only involved changes to the testing charms repo?
[16:52] <bodie_> that's right, but they don't have to be backwardly incompatible.  I would just like them to be :)
[16:54] <rogpeppe> bodie_: i think you should go for it
[16:55] <rogpeppe> bodie_: for bonus points, check that the charmstore repo passes its tests with the new package
[16:56] <rogpeppe> bodie_: and we should perhaps think about moving toward entirely removing testing/repo
[16:57] <rogpeppe> bodie_: there will be places where it's still useful, but i think a better way would be to have charm testing repos inside the packages/repos that *use* the charm package
[16:58] <bodie_> rogpeppe, perhaps a good approach would be for charm to expose some methods for generating mock charms for core tests that need to integrate with charm
[16:58] <bodie_> (looking forward)
[16:59] <rogpeppe> bodie_: that's another decent approach that might be good
[16:59] <rogpeppe> bodie_: the only down side is that if every test is doing that, it can lead to a lot of disk churn
[17:00] <rogpeppe> bodie_: a lot of tests don't really care about the details of the charms - they just need *some* example charm to reploy
[17:00] <rogpeppe> deploy
[17:00] <bodie_> heh, was still mid comprehending your thoughts
[17:01]  * bodie_ scribbles "listen better" note with all the others
[17:02] <bodie_> I'm not really seeing how that solves the problem since it's like turning the deps inside out, where clients must define the interactions they expect with charm.  but I don't really have an opinion either way yet -- I was thinking of generating in-memory fake charms though, but I didn't think about how much file interaction there is with charm
[17:02] <rogpeppe> bodie_: another thing it might be interesting to do is make it easier to have an all in-memory charm
[17:03] <rogpeppe> bodie_: ha
[17:03] <bodie_> +1!  brb, meeting
[17:03] <rogpeppe> bodie_: i think it depends how one thinks of the testing charms
[17:04] <rogpeppe> bodie_: i think of them like they're testing data - a test wants to see what will happen when we do something with a given charm. it could specify that charm in the testing code, or as external data.
[17:05] <rogpeppe> bodie_: the external-data approach is arguably more readable, as the charm's in the form that it is usually specified
[17:06] <bodie_> rogpeppe, maybe it's as simple as having a function that cranks out a memory representation of the charm files, and then loads them as if they were a "real" charm file
[17:06] <rogpeppe> bodie_: but the in-testing-code is more flexible
[17:06] <bodie_> it's dumb, but it could be an easy out
[17:07] <rogpeppe> bodie_: it's easy enough to do
[17:07] <rogpeppe> bodie_: apart from the 100s of tests that would need changing in juju-core
[17:08] <rogpeppe> bodie_: and it's the thought of that that leads me to suggest a half-way house, where juju-core has its own charm testing repo
[17:08] <rogpeppe> bodie_: so then we don't need to change all those tests
[17:08] <rogpeppe> bodie_: (assuming we get juju-core to prime the charm package on the location of the juju-core charm repo)
[18:08] <wwitzel3> voidspace: updated the test to exercise the rsyslogHosts conditional logic
[18:10] <voidspace> wwitzel3: looking
[18:11] <voidspace> wwitzel3: LGTM
[18:13] <wwitzel3> voidspace: thanks
[18:13] <mgz> update on ppc blocker, bug 1388853
[18:13] <mup> Bug #1388853: ppc64el unittests consistently fails <ci> <ppc64el> <regression> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1388853>
[18:14] <mgz> the crash stuff is dealt with by having a newer compiler than is available in trusty, our test machine has this
[18:15] <mgz> if needed, ppa:ubuntu-toolchain-r/ppa can get you one as well
[18:15] <mgz> the remaining failures documented in that bug seem like ppc-specific test issues which just need fixing, naming of arch/tools issues and such like
[18:16] <alexisb> natefinch, can someone in the appropriate timezone take a look? ^^^
[18:16] <mgz> I can tell anyone who wants to take it up how to get on our actual ppc machine if needed
[18:16] <alexisb> mgz, can you make sure there is an updateint he bug
[18:17] <mgz> alexisb: yeah, I'm also going to close the previous bug as that just got very confused
[18:19] <natefinch> alexisb: yep
[18:19] <natefinch> mgz: writing up how to get on our PPC machine in a place we can easily find it would be very useful
[18:20] <mgz> natefinch: we don't have a general machine for playing on, just the one we use as the jenkins slave
[18:33] <mgz> alexisb, natefinch: added details to the bug
[18:41] <natefinch> mgz: thanks
[18:59] <voidspace> g;night all
[19:43] <katco> ericsnow: i may be looking at this wrong, but it looks like my review request didn't have a diff generated? http://reviews.vapour.ws/r/327/
[19:43] <ericsnow> katco: yeah, look like it :(
[19:43] <ericsnow> katco: that still happens infrequently
[19:44] <katco> ericsnow: did i do something wrong/different, or is that a known issue?
[19:44] <ericsnow> katco: it happens infrequently enough that I haven't looked into it
[19:44] <ericsnow> katco: not your fault
[19:44] <katco> ericsnow: k, ty sir :)
[19:45] <ericsnow> katco: you can still use rbt to post the patch
[19:45] <katco> ericsnow: righty-o
[20:17] <menn0> waigani: morning
[20:19] <waigani> menn0: morning
[20:19] <katco> am i correct in assuming landings are blocked?
[20:19] <menn0> yes they are
[20:19] <menn0> due to bug 1388853
[20:19] <mup> Bug #1388853: ppc64el unittests consistently fails <ci> <ppc64el> <regression> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1388853>
[20:19] <katco> ok, thanks menn0
[20:19] <katco> yeah, figured, but wanted to ask just to be sure
[20:19] <menn0> martin has done a good analysis. the problems looks pretty simple to fix so i'm going to have a go.
[20:20] <katco> good luck, menn0. may the source be with you.
[20:21] <mwhudson> good morning
[20:21] <menn0> mwhudson: howdy
[20:22] <mwhudson> someone put "dummy-admin dummy-admin just now just now" in the expected output of a test?
[20:22] <menn0> mwhudson: someone has
[20:23] <mwhudson> oh dear
[20:23] <mwhudson> (well, unless the test uses a synthetic time source, which it apparently doesn't...)
[20:23] <menn0> mwhudson: and it could even be thumper ...
[20:23] <menn0> mwhudson: although I think I might have reviewed that one
[20:24] <mwhudson> in a way that's good because i have no problems with telling thumper that he's done something stupid :)
[20:24] <menn0> LOL
[20:25] <mwhudson> whereas i might be a bit more circumspect with someone i didn't know so well :)
[20:25] <menn0> i'll fix that and have a look at the other problem too
[20:25] <menn0> although I can't get that to happen on my machine
[20:26] <menn0> I suspect you actually need to be on a ppc64 host
[20:26] <mgz> menn0: I can tell you how to access the jenkins build slave if that would help
[20:28] <menn0> mgz: i have a few ideas to try first but could you send me the details anyway
[20:30] <mwhudson> menn0, waigani, davecheney: email standup i guess?
[20:31] <menn0> mwhudson: unless you would prefer otherwise?
[20:31] <waigani> I'm easy either way
[20:31] <mwhudson> i am currently in a cafe on extremely slow 3g so email sounds good :)
[20:31] <waigani> email it i
[20:31] <waigani> s
[20:33] <menn0> cool
[20:40] <mgz> menn0: https://pastebin.canonical.com/119817
[20:44] <menn0> mgz: cheers
[21:24] <waigani> menn0: I may have hit a chicken and egg
[21:24] <menn0> waigani: in what way
[21:24] <menn0> ?
[21:25] <waigani> menn0: there is a settings doc which uses a global env key as it's key
[21:25] <waigani> menn0: it holds the configuration for the environment
[21:26] <waigani> menn0: the key is now perpended with the env-uuid
[21:27] <waigani> menn0: and the doc exists, with a docID _id, before the upgrade step is run
[21:29] <waigani> menn0: so during the upgrade step, it gets perpended with the env-uuid again
[21:30] <waigani> menn0: and the test also fails as len(oldDocs) != len(newDocs) - that one I can fix easy enough
[21:30] <katco> wallyworld_: noooot sure what happened, rejoining
[21:30] <menn0> waigani: give me a sec
[21:32] <menn0> waigani: ok
[21:32] <waigani> menn0: yep, went you get a sec - does it jog anything from the workarounds you had to do?
[21:33] <menn0> waigani: sounds like you might need to add another little hack
[21:33] <menn0> waigani: but i'm not clear on why the env-uuid gets added twice
[21:33] <menn0> waigani: can you explain that?
[21:34] <waigani> menn0: good question, give me a sec I'll see...
[21:36] <waigani> menn0: because I used the global env key in one of the dummy docs to migrate.
[21:37] <waigani> menn0: so if I remove that and make the test expect len(oldDocs) + 1, the test should pass
[21:39] <waigani>  or remove the envion doc from the newIDs returned...
[21:40] <waigani> ah no, okay I'll stop thinking out loud and sort this
[21:40] <menn0> waigani: ok. let me know if you need a sounding board again :)
[21:43] <waigani> menn0: thanks :)
[21:48] <menn0> This is one half of fixing the CI blocker. can someone PTAL? http://reviews.vapour.ws/r/329/
[21:49] <davecheney> menn0: can you just delete the check fo rthe duration
[21:49] <davecheney> it's unknowable
[21:50] <natefinch> +1
[21:50] <menn0> davecheney, natefinch: but I've made the test accept any possible duration. is that not ok?
[21:51] <menn0> at least then the test ensure that we're getting the right shaped output
[21:51] <davecheney> menn0: fells like solving the wrong problem
[21:51] <davecheney> now that test will fail when tim changes the printing of an _arbitrary_ duration
[21:54] <menn0> but if I do that there's nothing testing that the duration emitted by "user list" is sanely formatted at all!
[21:55] <menn0> davecheney: ^
[21:55] <menn0> davecheney: or put another way, there's nothing test that the duration formatting function is in use
[21:56] <menn0> testing even
[21:57] <natefinch> this is why I like internal tests ;)
[21:59] <menn0> davecheney, natefinch: as this is becoming yet another testing debate and I just want to get this CI blocker sorted so that I can get back to useful work I will just do as you ask
[21:59] <natefinch> menn0: for the record, I'm ok with either fix
[22:02] <davecheney> menn0: natefinch same
[22:03] <menn0> natefinch, davecheney: so what, leave the branch as it is?
[22:03] <menn0> I just started relaxing the regex further
[22:03] <natefinch> menn0: I put a ship it on it
[22:03] <menn0> ok
[22:06] <davecheney> menn0: do the absolute minimum required to get the test passing
[22:06] <davecheney> as you say
[22:06] <davecheney> this is a pointless testing debate
[22:06] <davecheney> one of N
[22:07] <menn0> thanks. i've sent that off for merging.
[22:07] <menn0> now for the other half of the ticket.
[22:23] <wallyworld_> menn0: i can pick up the ppc64 test failure
[22:23] <katco> wallyworld_: fwiw i had to clear out my cookies... looks like time-changes mess with something w/ google apps
[22:23] <wallyworld_> \o/
[22:23] <katco> wallyworld_: the time changes from brussels probably triggered it on my laptop, daylight savings time for my main comp
[22:23]  * katco shrugs
[22:24]  * wallyworld_ shrugs too
[22:24] <katco> software!
[22:24] <menn0> wallyworld_: ok. it looks related to your changes from yesterday.
[22:25] <wallyworld_> menn0: yep - i had to add extra metadata to account for 1.20 being wrong but clearly when run on non amd64, the expected list of metadata entries is different
[22:27] <menn0> wallyworld_: the fix for the other part of the ticket (TestUserList) just landed
[22:27] <wallyworld_> menn0: awesome, ty
[23:34] <lazyPower> Ran into an interesting AWS issue with a customer that I've not seen before - if anyone has a moment to take a look - https://launchpad.net/bugs/1389014
[23:34] <mup> Bug #1389014: juju AWS EC2 "unit-get public-address" gives private address  <juju-core:New> <https://launchpad.net/bugs/1389014>
[23:41] <davecheney> lazyPower: is the custoemr using vpc
[23:41] <davecheney> ?
[23:41] <davecheney> themonk@redqueen:~$ juju run -e amazon --service my-charm1 "unit-get public-address"
[23:41] <davecheney> <IP_ADDRESS>
[23:41] <davecheney> ^ how did this work
[23:41] <lazyPower> davecheney: no idea its themonk in #juju though
[23:41] <lazyPower> exactly!
[23:42] <lazyPower> a) how do you get an IP, b) how do you get the *same* ip
[23:42] <davecheney> how was their server able to contact <IP_ADDRESS> ?
[23:42] <davecheney> that is a private ip
[23:42] <lazyPower> and c) how do you get a private ip
[23:42] <davecheney> lazyPower: juju just returns whatever the aws metadata services tells it
[23:42] <davecheney> so if aws says you'r ip address is <IP_ADDRESS>
[23:42] <davecheney> that's why juju knows as well
[23:44] <lazyPower> davecheney: <themonk> lazyPower, what is 'provisioned in a VPC' ?
[23:44] <lazyPower> i'm going to say the answer is probably no...
[23:46] <lazyPower> davecheney: do you have a minute to pop in #juju and interface with themonk over his AWS issue? If not no biggie - he's got an open bug that he can track.
[23:46] <davecheney> curl http://<IP_ADDRESS>/latest/public-ipv4
[23:46] <davecheney> this is what juju does
[23:46] <davecheney> join #juju
[23:46] <davecheney> urgh
[23:46] <davecheney> sorry, i thought I was in that channel
[23:46] <davecheney> i have so many called #juju
[23:47] <lazyPower> all good davecheney :) I have the same issue between canonirc and freenode. so i know the feeling.


[12:00] <ghostcube> hi guys, running 14.04 kubuntu and it seems if you start systemsettings then go to kdm design download, tick any design to install it didnt get installed. any idea?
[12:00] <ghostcube> starting systemsettings as root?
[12:02] <ghostcube> it works if you manually dowmnload the tar files from open desktop and then install it into the kdm designs
[12:03] <BluesKaj> Hiyas all
[12:03] <ghostcube> hi
[12:04] <ghostcube> just testet to run systemsettings as root and now everything works fine for installing kdm theme by download from opendesktop
[12:04] <BluesKaj> yup, well known secret :)
[17:04] <attrapereves> Hi, after running updates this morning, a white box has appeared around the desktop icon text. What caused this?
[17:07] <attrapereves> This is the box: http://i.imgur.com/VJdIQ9h.png
[17:14] <holstein> attrapereves: i would test as another user, or the guest user
[17:47] <attrapereves> holstein, good news. The screen is now turning off and the computer is going into standby after time. I'm guessing updates fixed some things.
[22:20] <Fudge> anyone else get a KP from alsa-utils today


[02:02] <arges> smoser: I didn't see qemu-kvm in http://ubuntu-cloud.archive.canonical.com/ubuntu/pool/main/ when I checked
[03:04] <infinity> doko_: Fixed binutils uploaded (for libiberty, and restoring the lost changes from vorlon and pitti), so you don't have to worry about it.
[05:17] <OdyX> tkamppeter_: I'll prepare a 1.7 branch for you today and keep you posted.
[06:27] <dholbach> good morning
[06:35] <pitti> Good morning
[06:35] <pitti> infinity: cheers
[06:44] <Noskcaj> jbicha__, ping
[07:00] <tkamppeter> OdyX, OK.
[07:22] <tvoss> didrocks, ping
[07:23] <didrocks> tvoss: pong
[10:07] <sil2100> Wellark: ping
[10:40] <zyga> pitti: ping
[10:40] <pitti> zyga: pong
[10:41] <zyga> pitti: my google foo and memory are failing me, could you please point me to some place that explains the changes to dbus session bus, I recall reading that some kind of new bus type is coming (user bus?)
[10:41] <pitti> zyga: that hasn't landed yet; I'm not sure when that's being planned upstream (or whether it's systemd specific)
[10:41] <pitti> maybe it also got obsoleted with logind, I'm not sure; in any way it's been a long time since I've heard about it
[10:42]  * pitti asks desrt
[10:42] <zyga> pitti: so it's not something super defined yet, ok
[10:42] <zyga> thank you
[10:43] <pitti> zyga: I asked Ryan, but probably he's asleep
[11:09] <didrocks> @pilot in
[11:09]  * dholbach hugs didrocks
[11:10]  * didrocks hugs dholbach back, couldn't do my shift the other day with unity7/touch apps and so on :)
[11:10] <dholbach> no worries :)
[11:14] <infinity> doko: Does the binutils shlibs need to be so painfully restrictive?  We're going to have to reupload every kernel that builds a tools package for every new binutils snapshot...
[11:14] <doko> infinity, there is no abi
[11:15] <doko> sometimes even if I keep it, and add a patch, it doesn't build anymore. maybe you do remember ...
[11:15] <infinity> doko: Yeah, I get that.  I guess this is something we get to suffer with if we use snapshots.  I hope you don't plan to upload a bunch of them before 2.24
[11:16] <infinity> Not that I mind a bunch of mini-transitions, it's just a bunch of mini-transitions involving rebuilding a bunch of kernels could get annoying. :)
[11:17] <doko> too late, just uploaded. but yes, trying to keep this soversion as stable as possible
[11:17] <pitti> infinity, doko: any chance that the "Depends: build-essential" fix can get committed to Debian as well, to avoid losing it again? (also, it's necessary for Debian, too)
[11:17] <doko> so why did the kernel needs this?
[11:17] <doko> I thought that was just for libiberty?
[11:17] <infinity> doko: "too late, just uploaded", as in you uploadd a new snapshot again? :/
[11:18] <doko> yes
[11:18] <doko> pitti, debian binutils never had the autopkg tests
[11:18] <pitti> doko: ah, ok; I thought it was a victim of merging; so, nevermind
[11:19] <infinity> doko: britney claims that linux and linux-grouper, at least, depend on binutils.  I'd have to look at why.  My assumption would have been libbfd.
[11:20] <doko> is this gperf?
[11:21] <infinity> (saucy-amd64)root@cthulhu:~# ldd /usr/bin/perf_3.9.0-5 | grep bfd
[11:21] <infinity> 	libbfd-2.23.52-system.20130611.so => /usr/lib/libbfd-2.23.52-system.20130611.so (0x00007fbaa6cea000)
[11:24] <infinity> doko: Oh, bah.  This is a direct result of the libiberty-gone-missing oops.
[11:25] <infinity> doko: I'll get it fixed up with the kernel team.
[11:25] <infinity> doko: perf only needs bfd in the alternate linkage case rtg forced because iberty was gone.
[11:26] <seb128> infinity, just curious, what's the status of the unity SRU for raring?
[11:26] <doko> infinity, I asked wookey to build a libiberty-dev package from a separate source
[11:29] <infinity> seb128: I was waiting for someone to figure out how to upload a package with a fixed changelog, but I've given up on that.  I'll re-review today, and reject the one(s) I don't like.
[11:29] <seb128> infinity, thanks
[11:31] <doko> infinity, there is still libiberty_pic.a
[11:32] <didrocks> infinity: AFAIK, Mirv is preparing/have a bamf with a fixed changelog (it's the only one I know about)
[11:33] <infinity> doko: Well, there's both now.
[11:34] <Mirv> didrocks: I put it into the google doc, https://launchpad.net/~unity-team/+archive/sru/+files/bamf_0.4.0daily13.05.31%7E13.04-0ubuntu2%7Etest1.dsc
[11:34] <didrocks> Mirv: ah, good! so infinity: bamf fix on the way :)
[11:34] <didrocks> (in this patch pilot shift)
[11:34] <Mirv> so it could be uploaded, although I'm not sure with which version since the ubuntu1 sync request is in the queue
[11:35] <didrocks> Mirv: reuse the same version, I'm going to reject the one in the queue
[11:35]  * soren realises that pxe-kexec can be used to trigger d-i in the cloud and falls out of his chair
[11:35] <Mirv> didrocks: ok, well take that ubuntu2~test1 and upload as ubuntu1 instead.. since it's a dget from a superseded daily-build PPA content, I don't have any bzr or such anyhow
[11:35] <didrocks> Mirv: ok, will do!
[11:35]  * infinity gets soren a seatbelt for his extreme computing.
[11:35] <Mirv> thanks
[11:36] <didrocks> thanks to you :)
[11:43] <stokachu> whats the best way to get a BuildID from a kernel image?
[11:46] <stokachu> for example i can get it from a binary with file
[11:46] <stokachu> /bin/zsh4: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=0x336c8162902093067f2186b7e6ac233b74d7ce77, stripped
[11:50] <stokachu> if i do a eu-readelf there is a section in .notes about a GNU_BUILD_ID though not sure if that is the same thing
[11:52] <cjwatson> stokachu: use scripts/extract-vmlinux from the kernel source tree to extract the uncompressed vmlinux (scripts/extract-vmlinux /path/to/vmlinuz >vmlinux)
[11:52] <stokachu> cjwatson: ah nice ill check that out
[11:53] <cjwatson> It doesn't have a .note.gnu.build-id section though; I wonder where file gets it from
[11:54] <stokachu> cjwatson: should i use the eu-readelf instead?
[11:54] <stokachu> there is a build id in the .notes section but nothing about .note.gnu.build-id like the others
[11:55] <infinity> I'm vaguely confused by file's output there anyway...
[11:56] <infinity> (base)adconrad@cthulhu:~$ file /bin/mv
[11:56] <infinity> /bin/mv: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=0xe438743eb3051f02aff0dd6e051e7ad7d035c286, stripped
[11:56] <infinity> (base)adconrad@cthulhu:~$ readelf -a /bin/mv | grep Build
[11:56] <infinity>     Build ID: 3e7438e4021f05b36eddf0afd77a1e0586c235d0
[11:56] <stokachu> exactly!
[11:56] <cjwatson> well, just readelf would do
[11:57] <stokachu> i think ill stick to readelfs build id
[11:57] <stokachu> eu-readelf -n /boot/vmlinuz-3.2.0-45-generic
[11:57] <stokachu> that gives me a build id
[11:57] <cjwatson> like I say, readelf will do and is more widely installed
[11:58] <stokachu> sounds good to me
[11:58] <cjwatson> the build IDs printed by readelf and file are the same, just byte-swapped
[11:58] <stokachu> ok
[11:58] <cjwatson> (flip four-byte chunks, you'll get the same answer)
[12:08] <didrocks> pitti: mind marking https://code.launchpad.net/~darkxst/ubuntu/raring/gnome-shell/lp1064584/+merge/165828 as merged?
[12:25] <OdyX> tkamppeter: pushed the master-experimental branch to cups.git, feel free to push nicely isolated commits on there; no need to include paths for all commits, remember ;) .
[12:25] <OdyX> tkamppeter: beware, the master-experimental branch is based off master, which has the staged changes for jessie/unstable.
[12:45] <pitti> didrocks: done
[12:45] <didrocks> pitti: thanks :)
[13:03] <pitti> where would I file a bug against the kernel that is running on the phablet image? the chroot doesn't have a kernel package
[13:03] <pitti> 3.1.10-3-grouper
[13:03] <ogra_> pitti, linux-grouper for nx7, linux-maguro for galaxy nexus, manta for n4 and mako for n10
[13:04] <ogra_> they are all in the archive
[13:04] <pitti> https://launchpad.net/ubuntu/+source/linux-grouper/+bugs
[13:04] <pitti> "no open bugs"
[13:04] <pitti> wow :)
[13:04]  * pitti is going to add the first one then
[13:04] <ogra_> well, its pretty new
[13:05] <pitti> I stumbled over a reboot command without any confirmation or security checks :)
[13:05] <pitti> cat /sys/devices/platform/tegra-i2c.4/i2c-4/4-006a/reg_status
[13:05] <pitti> (as user)
[13:05] <ogra_> note that HW bugs you might experience can be android bugs ... :)
[13:06] <ogra_> ah, well, sysfs cat reboot sounds actually like kernel, yeah
[13:07] <pitti> filed, thanks
[13:48] <RoyK> hi all. any clue about bug 1189567?
[13:56] <roadmr> hello folks! I used to be able to rsync rsync://old-releases.ubuntu.com/old-releases/ but as of this morning I can't (@ERROR: Unknown module 'old-releases'). Does anybody know what changed, or who should I ask about this?
[13:58] <Laney> roadmr: IS might be a good first port of call
[13:58] <roadmr> Laney: thanks, I'll ask over there
[14:04] <xnox> smoser: did you get a chance to test cloud-init in saucy with updated upstart? are there saucy daily or weekly cloud-init images available somewhere for me to try?
[14:10] <didrocks>  pitti: and to be marked as merged: https://code.launchpad.net/~timo-jyrinki/ubuntu/precise/compiz-plugins-main/fix_755842/+merge/162934 that will be the last for today, I can handle the other ones :)
[14:10] <pitti> didrocks: done
[14:15] <didrocks> thanks :)
[14:38] <didrocks> @pilot out
[14:48] <smoser> xnox, still around ?
[14:48] <xnox> smoser: yeap.
[14:49] <smoser> we had issues yesterday.. it seems that the upgrade isn't working as i had desired.
[14:49] <smoser> did you see that info ?
[14:49] <xnox> smoser: no, i didn't see that. Where, what?
[14:50] <smoser> http://irclogs.ubuntu.com/2013/06/11/%23ubuntu-devel.html#t19:10
[14:50] <smoser> it seems to me that the problem is that during the upgrade, upstart thought it *was* at runlevel 2.
[14:50] <smoser> as i understood it, the idea was to only restart upstart if runlevel 2 had been reached (or suitable older version found)
[14:52] <xnox> smoser: correct, so it must have been at runlevel 2 already. It performed stateful re-exec, and rightfully did not preserve "pending" / "blocked" events if old upstart was still running as pid 1.
[14:53] <xnox> smoser: is there a way for me to execute cloud-init image in an lxc container with upgrade to see how it behaves and what's wrong?
[14:54] <smoser> probably.
[14:54] <stgraber> xnox: yes, that's how I've been doing testing of those
[14:54] <xnox> smoser: do cloud-init jobs actually block runlevel 2 event? reaching runlevel 2?
[14:54] <smoser> you can probably recreate with 'lxc-create -t ubuntu-cloud'
[14:54] <xnox> right, ack.
[14:54] <smoser> xnox, they dont' block runlevel 2
[14:54] <smoser> that is what i noticed.
[14:54] <xnox> hm. but I need to use some old image.
[14:55] <xnox> smoser: =(((((( we assumed that cloud-init does all of it's stuff before runlevel 2 is emitted.
[14:55] <xnox> well reached.
[14:55] <smoser> $*%#ing parallelism !
[14:55] <smoser> rc-sysinit.conf is : start on (filesystem and static-network-up) or failsafe-boot
[14:56] <smoser> and cloud-config.conf is: start on (filesystem and started rsyslog)
[14:56] <stgraber> xnox: IIRC what I did was create a new cloud container (lxc-create -t ubuntu-cloud -n p1 -- -r raring), then chroot into the container, downgrade some stuff, then make sure /var/lib/cloud is empty except for /var/lib/cloud/seed, then start the container.
[14:57] <stgraber> xnox: oh, and you need a userdata file (or whatever it's called) to set the update flag, otherwise cloud-utils won't apply updates at boot time
[14:57] <smoser> right.
[14:57] <smoser> but basically, nothing is going to stop rc-sysinit from running.
[14:58] <smoser> i'm not sure if its a bug or not that rc possibly runs parallel to cloud-config.conf. its not ever been a problem itself.
[14:58] <stgraber> xnox: unfortunately I didn't really take much notes about this, I mostly did that based on directions from jibel and smoser and removed the container from my machine a week ago (otherwise I'd just have given you a compressed version of it)
[14:59] <xnox> smoser: so which of the jobs runs dist-upgrade, cause that's the one that should be either running after everything else cloud-initish is done? or it should run whilest runlevel 2 has not been reached.
[14:59] <smoser> xnox, kvm recreate is at https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1103881
[14:59] <xnox> smoser: k, thanks.
[14:59] <smoser> you cnan just download a few-day-old saucy
[15:00] <smoser> xnox, i'm not sure how to do this well.
[15:01] <smoser> well... one way (possibly hackish)
[15:01] <smoser> is to say "if cloud-config is running, do not upgrade"
[15:01] <smoser> er... do not re-exec
[15:01] <smoser> that'd solve this specific problem
[15:01] <xnox> smoser: http://cloud-images.ubuntu.com/saucy/ only has back to 20130609.
[15:02] <smoser> xnox, that has upstart 1.8-0ubuntu4
[15:02] <smoser> is that not old enough ? otherwise you'll have to downgrade
[15:02] <smoser> i can show you how i'd do that if you needed.
[15:02] <xnox> smoser: nah, that has full serialisation already.
[15:03] <xnox> smoser: must downgrade. or start raring container and dist-upgrade =)))))
[15:03] <smoser> yeah. so you should be able to reproduce this in lxc or in kvm. but either way will require you to downgrade.
[15:03] <smoser> i use: http://bazaar.launchpad.net/~smoser/+junk/backdoor-image/revision/15#mount-callback-umount
[15:03] <smoser> to "mount - run some code - umount" of a qcow image.
[15:04] <smoser> better link: http://bazaar.launchpad.net/~smoser/+junk/backdoor-image/view/head:/mount-callback-umount
[15:12] <xnox> k, thanks. I'll try that and get back with better fix.
[15:26] <hallyn> infinity: would you mind kicking the libcgroup precise-proposed upload for version 0.37.1-1ubuntu11 ?
[15:26]  * hallyn lost the version number choosing game again
[15:27] <infinity> hallyn: "kicking" as in rejecting from the queue?
[15:27] <hallyn> infinity: yes
[15:27] <infinity> hallyn: Done.
[15:27] <hallyn> infinity: thanks
[15:59] <tvoss> cjwatson, ping
[15:59] <cjwatson> tvoss: hi
[15:59] <tvoss> cjwatson, can you join us on https://plus.google.com/hangouts/_/a0a4f88494fc4074198be533bd959ae80e43303a
[15:59] <cjwatson> tvoss: what's the topic?
[16:00] <tvoss> cjohnston, an app centric world
[16:00] <cjwatson> um, ok, that sounds like marketing ... ;-)
[16:01] <Laney> O_O
[16:36] <cjwatson> stgraber,xnox: is there anything preventing us cherry-picking the apparmor patches to upstart into saucy?
[16:37] <xnox> cjwatson: well it was aimed to be part of upstart 1.9 release for saucy once jodh comes back.
[16:38] <xnox> cjwatson: it could be uploaded to saucy soonish. But I was hoping to fully resolve "full-serialisation & cloud-init bug" in saucy & SRU into raring first.
[16:38] <cjwatson> hm, ok
[16:38] <cjwatson> jdstrand: ^-
[16:38] <cjwatson> the serialisation thing is indeed best to sort out before the next upload
[16:38] <xnox> (if i will have luck with lxc/cloud-init containers tomorrow, and sru goes through quickly, we can look into getting apparmor into saucy friday going on next week)
[16:45] <jdstrand> waiting til jodh comes back is ok with me
[16:45] <jdstrand> we can work with ppas/etc in the meantime
[16:46] <cjwatson> ok
[16:49] <slangasek> jdstrand: in that case, you can probably take the upstart upstream daily-build ppa?
[16:49] <jdstrand> slangasek: does that have armhf enabled?
[16:49] <slangasek> I believe so
[16:49] <jdstrand> slangasek: thanks, I'll look into it
[16:49] <slangasek> https://launchpad.net/~upstart-devel/+archive/upstart-daily-build
[16:50] <slangasek> hmmm nope, not that one
[16:50] <slangasek> at least, there's no armhf there
[16:50] <jdstrand> and no saucy
[16:50] <jdstrand> np
[16:51] <slangasek> jdstrand: ah, here we go. https://launchpad.net/~canonical-foundations/+archive/upstart-daily
[16:52] <jdstrand> slangasek: nice. would you be able to enable saucy build there too?
[16:52] <slangasek> jdstrand: it seems to be built for raring, but it's still the right code and should be installable on saucy.  Moving it to build for saucy means changing the recipe build, I guess
[16:52] <slangasek> I'm not sure I know where that lives
[16:52] <jdstrand> I thought it was just a checkbox
[16:53] <slangasek> stgraber: ^^ do you know where the upstart daily recipe build is?
[16:53] <jdstrand> let me see if I can conjure up a url
[16:54] <stgraber> slangasek: https://code.launchpad.net/~canonical-foundations/+recipe/upstart-daily-nonvirt
[16:54]  * jdstrand was >< close to giving that :)
[16:55] <jdstrand> slangasek: under Distribution series, you should have a way to enable saucy and any other releases you want
[16:55] <slangasek> hmmm, so it's under code.launchpad.net, but is not a branch, ok
[16:55] <slangasek> changed to saucy going forward
[16:56] <slangasek> stgraber: does this recipe pull in the Ubuntu packaging delta?
[16:56] <slangasek> ah, it does
[16:56] <stgraber> slangasek: right, the recipe is owned by ~canonical-foundations but we're using the ~upstart-dev branch as the source. We had to move the recipe to ~canonical-foundations so it could use the non-virt PPA
[16:56] <slangasek> but it uses the raring packaging :)
[16:56]  * slangasek moves this to lp:ubuntu/upstart
[16:57] <stgraber> slangasek: I'm pretty sure I had that set to lp:ubuntu/upstart back in raring, I suspect LP is very good at changing all references when we create the new series and so we'll have to keep on updating it every time a new series open
[16:58] <slangasek> ah, fiddlesticks
[16:58] <slangasek> ok
[17:56] <geser> does somebody know if/when we get apache 2.4 into saucy? there is a bunch of packages waiting on dh-apache2 from apache2-dev
[17:57] <mterry> @pilot on
[17:57] <udevbot> (pilot (in|out)) -- Set yourself an in or out of patch pilot.
[17:57] <mterry> @pilot in
[17:57] <cjwatson> It was waiting for the libgd2/net-snmp transition to clear, but that's done now.  However, I'd request that if you're doing this you try to work out *first* whether enough of the transition is done in Debian that we could clear it through -proposed in Ubuntu within a week or so
[17:57] <cjwatson> Otherwise it gets even harder to land changes
[17:58] <cjwatson> Some of these transitions are started in Debian and then not pursued as aggressively as would be ideal (I had to fix a fair bit of libgd2 myself)
[17:59] <RoyK> bug 1189567 seems to be easy to fix - anyone into xfs here?
[18:01] <geser> considering that there is RC-bug on apache2 to prevent it from migrating to testing, it seems more modules need to transition first before it gets cleared
[18:03] <geser> lets hope it gets done soon before we (the ubuntu release team?) decides to stay with 2.2 and we need a solution for those build-depending packages on dh-apache2
[18:12] <infinity> geser: Feature Freeze is a looong way out, I think we'll be alright holding off a little bit.
[18:12] <ogra_> heh, feature freeze
[18:13] <geser> infinity: yeah, just noticed it too, that FF is end of August
[18:13] <cjwatson> geser: well, *a* solution is to leave them in -proposed
[18:14] <cjwatson> obviously not necessarily ideal if we need to change them
[18:17] <geser> would it be possible to SRU a package if a newer version it stuck in -proposed till after release?
[18:17] <cjwatson> Well, we'd move it to <next>-proposed after release
[18:17] <infinity> geser: We'd remove it from -proposed if it never migrated (as we did last release)
[18:17] <infinity> Well, s/remove/move/, as Colin says.
[18:17] <cjwatson> But I'm not sure whether LP will forbid -proposed from going backwards
[18:18] <infinity> Hrm.  It probably does.
[18:18] <infinity> That could be fixed, though.
[18:19] <cjwatson> Looks like the relevant ancestry check only looks for PUBLISHED and PENDING.
[18:19] <cjwatson> So it should work.
[18:19] <cjwatson> You just don't get to *reuse* a version.
[18:20] <geser> so it's still nice to resolve all those FTBFS and DEPWAIT in -proposed till release but as important as in last releases (before the introduction of -proposed migration) for SRUs and security updates?
[18:21] <infinity> I feel like that sentence might have been missing some words.
[18:21] <cjwatson> We have a bit more flexibility, at least.
[18:21] <cjwatson> Once I get round to fixing a bug in the LP copier, I plan to start demoting stuff from release to -proposed when it's sufficiently broken.
[18:23] <geser> infinity: ... but not as important ... (I hope I didn't miss any more words)
[18:23] <infinity> cjwatson: I'm still trying to sort out when that would be a good idea.
[18:23] <infinity> cjwatson: We can't force users to downgrade afterall, so removing a package from the release pocket doesn't really remove it from the wild in any meaningful way.
[18:24] <cjwatson> We remove packages in other cases ...
[18:24] <infinity> We remove because we're removing things completely, sure.
[18:24] <infinity> But that's a bit different from a "temporary demotion" that should usually just be someone fixing it.
[18:24] <cjwatson> Also, there's still a handful of sources with no binaries for one reason or another that got into release pre-proposed-migration, but where I'd rather not remove the source entirely because they still ought to get fixed.
[18:24] <infinity> The exception to that being the group of packages with only source in the release pocket, but that's a one-time fix.
[18:24] <cjwatson> And of course there's a chunk of uninstallables in the release pocket.
[18:25] <cjwatson> Each of those has the effect of making proposed-migration a bit less reliable (because it only checks for lower uninstallable count, not a strict subset)
[18:25] <cjwatson> Anyway, I do expect it to be rare-ish, but I'd like to have the option
[18:26] <infinity> cjwatson: Do we have britney output for the full archive somewhere readable?
[18:26] <cjwatson> I don't think so.  It's years since I tried, but I gave up after six hours
[18:26] <infinity> cjwatson: saucy_probs being main-only is a bit unhelpful for clearing up the remaining uninstallables.
[18:26] <cjwatson> Maybe it'd be faster now, dunno
[18:27] <cjwatson> Feel free to have a go and see if it completes in finite time nowadays
[18:27] <infinity> Heh.
[18:27] <infinity> I'd probably be happy to manually run it a few times over a few months while we fix and/or demote what's still broken.
[18:27] <infinity> Cause after that, other than people forcing things in (ugh), we should be able to stay clean.
[18:39] <geser> ubuntuwire has a debcheck page but it isn't updated anymore since Nov 2012
[19:08] <smoser> hey..
[19:08] <smoser> i'm looking at http://archive.ubuntu.com/ubuntu/dists/precise-updates/main/installer-i386/current/images/SHA256SUMS
[19:08] <smoser> what is "gtk" there?
[19:08] <smoser> in things like 'cdrom/gtk/initrd.gz'
[19:08] <smoser> what does that indicate ?
[19:13] <psusi> hrm... debian seems to have added a new X/gtk frontend to d-i... I wonder if that's it
[19:15] <jpds> smoser: Well, booting its mini.iso brings up a little GTK installer.
[19:16] <psusi> I've been wondering why we haven't adopted that in our cds yet
[19:16] <psusi> last time I set up a debian vm with it, it was quite nice
[19:16] <jpds> smoser: wget http://archive.ubuntu.com/ubuntu/dists/precise-updates/main/installer-i386/current/images/netboot/gtk/mini.iso
[19:18] <infinity> arges: \o/
[19:18] <infinity> arges: Yay for a simple patch for that instead of backporting madness.
[19:18] <infinity> arges: (re: qemu qcow2 issues)
[19:26] <qengho> Hi all.  I am trying to use pbuilder-dist to build some package for armhf.  It complains that it can't satisfy "cdbs" build dependency, even though I see it as installable if I "pbuilder-precise login" and "apt-cache policy cdbs".  I can install it manually, too. My debian/control has no version specified for cdbs. I think I need help debugging it.
[19:34] <arges> infinity: thanks! yea i was happy about it too
[20:33] <slangasek> psusi: hi, if you're going to do triage work on acpi-support bugs, it would be more useful to assign them somewhere else entirely :)
[20:34] <slangasek> psusi: because the acpi-support package is legacy and contains only a handful of event handlers in saucy, all of which we want to see moved elsewhere as we find places to land them
[21:03] <alesage> fginther, ted had a question about where he should assign his new project
[21:03] <alesage> sorry tedg :) ^^
[21:04] <alesage> where tedg's new proj probably belongs in a couple of stacks--how should one choose, fginther?
[21:04] <fginther> alesage, tedg, you mean which stack should it go into?
[21:04] <alesage> fginther, yes
[21:04] <tedg> fginther, Yes, it needs to get into the phablet PPAs but I'd rather do the standard distro targets.
[21:05] <fginther> alesage, it comes down to if it has any dependencies that need to build first and if it needs to be built with anything...
[21:05] <tedg> fginther, No, none of those.
[21:06] <tedg> fginther, Eventually Unity 7 and 8 will dep on it, but not yet.
[21:06] <fginther> tedg, the phablet stack files are really just a crutch until things are in distro. So if we can put it under 'head' all the beter
[21:07] <tedg> fginther, Sounds fine to me
[21:07] <tedg> fginther, It's the phablet guys that don't like hearing that their builds are a demoware ;-)
[21:07] <alesage> tedg stop rattling cages jeez ;)
[21:08] <alesage> can't we all just get along
[21:08] <alesage> thx fginther for your advice
[21:08] <tedg> alesage, That's no fun!
[21:08] <tedg> :-)
[21:08] <fginther> tedg, I'm looking at the stack dependencies. Right now unity.cfg might be the best answer.
[21:09] <tedg> fginther, I put it in misc for now.
[21:09] <fginther> tedg, the integration team will need to review, they may have a better answer
[21:09] <tedg> fginther, I figured that was easier to get started.
[21:09] <anon^_^> is there a preferred method of contact to reach the admin of packages.ubuntu.com
[21:09] <fginther> tedg, works for me
[21:09] <tedg> fginther, alesage, thanks guys!
[21:09] <alesage> tedg np!
[21:10] <anon^_^> it doesn't appear that the website is reflecting updates/security updates over the past month to multiple Ubuntu releases
[21:12] <sarnold> anon^_^: indeed, at least libx11 is missing raring's security update
[21:12] <anon^_^> yeah the entire package db looks like it hasn't been updating since late april
[21:13] <sarnold> anon^_^: ah, at the bottom there's an "email<EMAIL_ADDRESS>can't hurt as a place to start. :)
[21:13] <anon^_^> i'd prefer irc
[21:13] <anon^_^> lol
[21:13] <anon^_^> maybe i'll just wait for cjwatson to appear
[21:17] <cjwatson> qengho: If you mean building armhf packages on an x86 host, I doubt you'll get far using pbuilder for cross-building - as far as I know it hasn't been taught how to do it.  Use a recent version of sbuild instead, as per https://wiki.ubuntu.com/CrossBuilding
[21:17] <cjwatson> anon^_^: I have no control over packages.ubuntu.com
[21:17] <cjwatson> anon^_^: Try #canonical-sysadmin
[21:17] <anon^_^> rhonda's online just not in chan
[21:18] <anon^_^> sending her a pm
[21:18] <sarnold> don't forget that freenode isn't only ubuntu..
[21:20] <qengho> cjwatson: I figured it out. eatmydata works for native, but for qemu-emulated architectures, it fails, in a weird, weird way:  Can't satisfy cdbs build-dep. Obviously.
[21:34] <chiluk> smoser mterry can you guys look at https://bugs.launchpad.net/compiz/+bug/1083186  ?
[21:34]  * mterry looks
[21:34] <chiluk> the sru is seriously stalled.
[21:34] <chiluk> and I'm not sure how else to push on it .
[21:36] <slangasek> chiluk: unity and compiz packages were uploaded to precise-proposed just today; you can reasonably expect them to be accepted into precise-proposed sometime this week
[21:37] <chiluk> thanks slangasek
[22:49] <mterry> @pilot out


[10:58] <mup> Bug #1878932 changed: 2.7 - I have to configure network devices twice <ui> <MAAS:Fix Released> <maas-ui:Fix Released> <https://launchpad.net/bugs/1878932>
[11:07] <mup> Bug #1878932 opened: 2.7 - I have to configure network devices twice <ui> <MAAS:Fix Released> <maas-ui:Fix Released> <https://launchpad.net/bugs/1878932>
[11:10] <mup> Bug #1878932 changed: 2.7 - I have to configure network devices twice <ui> <MAAS:Fix Released> <maas-ui:Fix Released> <https://launchpad.net/bugs/1878932>
[11:13] <mup> Bug #1878932 opened: 2.7 - I have to configure network devices twice <ui> <MAAS:Fix Released> <maas-ui:Fix Released> <https://launchpad.net/bugs/1878932>
[11:16] <mup> Bug #1878932 changed: 2.7 - I have to configure network devices twice <ui> <MAAS:Fix Released> <maas-ui:Fix Released> <https://launchpad.net/bugs/1878932>
[23:06] <mup> Bug #1981379 changed: MAAS http-server failed to start post 3.2 upgrade <maas3.2> <regioncontroller> <MAAS:In Progress by troyanov> <MAAS 3.2:In Progress by troyanov> <https://launchpad.net/bugs/1981379>
[23:18] <mup> Bug #1982984 opened: reverse-proxy service is not displayed for region controller <ui> <MAAS:Triaged> <https://launchpad.net/bugs/1982984>
[23:24] <mup> Bug #1982984 changed: reverse-proxy service is not displayed for region controller <ui> <MAAS:Triaged> <MAAS 3.2:Triaged> <https://launchpad.net/bugs/1982984>
[23:27] <mup> Bug #1982984 opened: reverse-proxy service is not displayed for region controller <ui> <MAAS:Triaged> <MAAS 3.2:Triaged> <https://launchpad.net/bugs/1982984>
[23:30] <mup> Bug #1982984 changed: reverse-proxy service is not displayed for region controller <ui> <MAAS:Triaged> <MAAS 3.2:Triaged> <https://launchpad.net/bugs/1982984>
[23:33] <mup> Bug #1982984 opened: reverse-proxy service is not displayed for region controller <ui> <MAAS:Triaged> <MAAS 3.2:Triaged> <https://launchpad.net/bugs/1982984>


[00:41] <zmoylan-pi> sometimes cheapo generic hardware is wonderful.
[00:47] <penguin42> true - it doesn't try and be overly smart
[07:07] <MooDoo> morning all
[08:10] <MooDoo> morning
[08:14] <davmor2> Morning all
[08:15] <davmor2> diddledan, MooDoo: Cher Believe this morning :)
[08:16] <MooDoo> morning davmor2
[08:38] <bigcalm> Good morning peeps :)
[08:52] <MooDoo> any one come accross an issue when logging into a  LTS server via ssh it kicks you straight out after typing in the password?
[08:53] <MooDoo> http://paste.ubuntu.com/11913362/ is the pastebin of my ssh -v well the last bit
[08:55] <JamesTait> Good morning all; happy Viking 1 Landing Day! 😃
[08:55] <ujjain> our mysql prod shows mysql failed with "hostname ...is blocked because of many connection errors". Any ideas what can cause max_connect_errors? MySQL seems to have been fine and no errors in the mysql error log.
[09:08] <brobostigon> morning boys and girls.
[09:09] <bashrc> morning
[09:10] <brobostigon> morning bashrc
[09:10] <davmor2> MooDoo: no but then I use keys not passwords they so antiquated ;)
[09:11]  * bashrc also uses keys
[09:13] <TwistedLucidity> MooDoo: Have you made changes to .bashrc or (possibly) permissions recently?
[09:14] <MooDoo> TwistedLucidity: no i had a gluster issue and had to restore from a backup, it's possible the login is set to /bin/false or something like that but I can't get into to check i lol
[09:15] <MooDoo> bashrc: davmor2 I use keys for my major servers, but this a little beastie i'm not worried about loosing it, I'm just curious how to fix it :D
[09:19] <TwistedLucidity> MooDoo: Try something like this - ssh you@there bash --norc --noprofile -i
[09:20] <TwistedLucidity> MooDoo: Source - https://lists.debian.org/debian-user/2013/04/msg01105.html and the thread - https://lists.debian.org/debian-user/2013/04/msg01090.html
[09:21] <TwistedLucidity> Go no VM console thing you can jump on to? Avoid the whole SSH shenanigans.
[09:22] <MooDoo> TwistedLucidity: no console pmsl, it was before i set it up on my servers
[09:34] <MooDoo> TwistedLucidity: yeah non of that works, I'm not even able to pass commands to the login....not to worry, thanks all :D
[09:35] <foobarry> wow. pc rebooted in the middle of wine install
[09:36] <bashrc> feature?
[09:36] <bashrc> often when that happens it's an overheating problem
[09:36] <bashrc> fan or heatsink
[09:36] <foobarry> it seems fine
[09:38] <bashrc> I had a laptop which used to do that years ago, and it was because sometimes the graphics card would draw more power than the psu could supply
[09:39] <bashrc> when playing games with 3d graphics
[09:44]  * zmoylan-pi is writing a quick script in perl on windows system.  the constant nagging notifications/beeps/bongs is very annoying...
[09:44] <zmoylan-pi> thank goodness for rasp pi i can ssh into for logical system...
[14:43] <Azelphur> Haha nice, just bought a refurbished printer and it came with a stack of 50 Ubuntu print test pages in the tray.
[14:44] <Azelphur> spose that means I won't have any problems getting this thing working :)
[14:56] <awilkins> Logical choice really, using Ubuntu to test refurbs
[14:57] <foobarry> lubotu3: test
[14:57] <awilkins> Getting the drivers for Windows is fraught with multi-100-MB downloads and bloatware
[14:57] <foobarry> lubotu3: bug 123
[15:13] <Azelphur> speaking of said printer, it came with toner cartridges ... and uhh https://owncloud.azelphur.com/owncloud/index.php/s/kJ9yXjVS8FBL36p and https://owncloud.azelphur.com/owncloud/index.php/s/tUrfMZyYw61gpKQ
[15:13] <Azelphur> ...return / ask for new toner cartridge time?
[15:15] <popey> did they waste it printing test sheets? :)
[15:16] <Azelphur> popey: probably since it is supposed to come with "part used consumables" (it's a refurb from a company)
[15:17] <Azelphur> I really don't know much about printers so I'm not sure whether this is normal and I should clean them and put them in, or what
[15:17] <popey> just chuck them in :)
[15:17] <popey> they're clealy taken out part used
[15:18] <Azelphur> really? even with ink all over them?
[15:18] <Azelphur> I didn't think they were meant to leak like that
[15:22] <Azelphur> It even has a big-ass warning sign saying "Don't touch the rollers" and the roller has dust all over it
[15:23]  * Azelphur prods popey
[15:25] <popey> hm?
[15:26] <popey> I'd be inclined to take it outside and blow it :)
[15:28] <Azelphur> called them, they said send photos and they'll replace them, I guess that works :)
[15:30] <popey> heh
[15:32] <Azelphur> maybe I'll get some new cartridges outta it :)
[15:44] <awilkins> I ruined my printer trying to fix it's toner feed issues
[15:45] <awilkins> Well, scratched up the imaging drum
[15:45] <awilkins> Replacing it was more expensive than a shiny new printer
[15:45] <awilkins> Even if it was a networked colour laser!
[15:49] <Azelphur> yea mine is a networked colour laser
[15:49] <Azelphur> got a good deal, only £50 refurb
[16:23] <Myrtti_> I still ♥ our Samsung SCX-4500W, or The Sentinel as we lovingly call it
[17:17] <diddledan> when did heatsinks get so complex to install?
[17:17] <diddledan> this one I got delivered today has a bracket that you need to put on the back of the board (I gather that's normal now?)
[17:18] <diddledan> I guess it's because they've got heavy?
[17:18] <diddledan> you don't want the weight pulling the cpusocket off
[17:26] <diddledan> nice update from Miguel de Icaza about efforts to unify mono and .net core: http://tirania.org/blog/archive/2015/Jul-21.html
[17:43] <knightwi1e> hey everyon e
[17:50] <brobostigon> evenning knightwise
[17:50] <diddledan> allo
[17:50] <knightwise> hey diddledan how are you tonight ?
[17:50] <diddledan> I'm good thanks
[17:50] <knightwise> playing around with my nagiospi here
[17:50] <knightwise> managed to get it up and working AND get the email notifications working with SendEmail
[17:50] <diddledan> if anyone's running windows: https://grahamcluley.com/2015/07/update-windows/
[17:51] <diddledan> knightwise: nice
[17:51] <knightwise> yep , now I just need to figure out how to add a service.
[17:51] <knightwise> i want it to check a specific website for specific content
[17:52] <knightwise> that way I can see if my RSS feed for the podcast is still alive
[20:53] <diddledan> "Apple stock sinks because they 'only' earned $49.6 billion in revenues. Makes sense."  ref: @thurott
[20:53] <diddledan> @thurrott
[20:53] <diddledan> double arr
[20:53] <daftykins> :D
[20:54] <diddledan> and @bbcrorycj says: "Apple shares plunging after record results - markey hoping for even more from iPhone, China"
[20:55] <diddledan> yikes, the aapl stock graph on google shows massive drop
[20:56] <diddledan> down from ~132 to ~122
[20:56] <daftykins> lawl
[20:56] <diddledan> so that's 10$ per share of a drop?
[20:57] <diddledan> or is that cents per share?
[20:57] <diddledan> I don't understand the markets :-p
[20:57] <diddledan> after-hours is showing a 6.7% drop for today
[20:58] <diddledan> now 6.8
[20:58] <diddledan> you'd think they'd choose a figure and stick with it. I don't get why it keeps changing :-p
[20:58] <daftykins> so now could be the time to buy some
[20:59] <diddledan> if you have 122$ you can buy a whole 1share
[21:00] <daftykins> yay
[21:00] <diddledan> fun: http://ma.tt/2015/07/licenses-going-dutch/
[21:04] <diddledan> MS have released some ninja-cat wallpapers and a kit to make your own: http://blogs.windows.com/bloggingwindows/2015/07/21/a-fun-surprise-for-windows-insiders/?linkId=15735507
[21:05] <diddledan> so @thurrott made his own: https://twitter.com/thurrott/status/623598998771892224/photo/1
[21:07] <ali1234> you shouldn't try to catch a falling knife, so they say
[21:07] <diddledan> lol
[21:08] <ali1234> and yes that is $ not cents
[21:09] <diddledan> seems to be hovering around 121.25
[21:12] <diddledan> apparently tim cook says the iphone grew 3times as fast as market - that's because they increased the screen dimensions to match those of android </troll> :-p
[21:12] <diddledan> as in , the growth he speaks of is the increase in dimensions of screen
[21:13] <diddledan> it doesn't matter how many thingies you sell. it's the size of your thingy that counts!
[21:13] <shauno> lol @ the bacon narwhal
[21:16] <shauno> I really wish they'd just release numbers for the watch
[23:54] <diddledan> err.. http://www.bbc.co.uk/news/technology-33508830


[14:42] <studiobot> ldotsdot was added by: ldotsdot
[14:46] <ldotsdot210> anybody know what font i have to install to get the presets showing on synth1 under wine?
[14:48] <OerHeks> maybe that windows ttf installer?
[14:48] <OerHeks>  ttf-mscorefonts-installer
[14:49] <OerHeks> you might want to reask in the wine channel, #winehq
[14:53] <ldotsdot210> no need. your suggestion worked. thank you very much.
[17:02] <studiobot> Catur Jati P was added by: Catur Jati P
[20:02] <studiobot> jfc007 was removed by: jfc007


[15:39] <michele_> what is the quickest and scriptable way to launch virtual machines without any kind of customization? virsh or multipass?
[15:43] <rbasak> multipass or lxd
[15:43] <rbasak> "lxd launch --vm ubuntu:jammy" for example
[15:44] <rbasak> But also, take away --vm and you get a system container, which will behave mostly the same and is often preferable. Unless you actually require the kernel and RAM separation of VMs.
[15:58] <michele_> rbasak: I will just need some vms to deploy kubernetes on it
[15:58] <michele_> so I guess a system container won't work
[16:04] <rbasak> michele_: it does work - see https://ubuntu.com/kubernetes/install
[17:39] <michele_> rbasak: where do I see that I don’t need a VM to install microk8s?
[17:49] <rfm> michele_, https://microk8s.io/docs/install-lxd is a walkthrough of installing microk8s on a lxd container (not a vm)
[17:50] <michele_> thanks rfm, I thought it was on ubuntu.com website linked by rbasak
[18:00] <rfm> michele_, yeah, the ubuntu.com link just said install on lxd, didn't distinguish container or vm. I kinda wonder if it was written before lxd did vms, that's "relatively" recent, 2020 or so