[07:03] <Cimi> morning guys
[07:08] <Saviq> o/
[07:11] <Cimi> Saviq, how is your stupidly spicy *ehm*?
[07:11] <Saviq> Cimi, all gone ;P
[07:15] <Cimi> tsdgeos, do you have a way to print out generated code of card creator when using make trycard?
[07:15] <tsdgeos> Cimi: you need to add a console.log somewhere in the  .js file
[07:15] <Cimi> ok
[07:16] <tsdgeos> tell me if you can't find where
[07:43] <Cimi> who saw joshua's pic on hr.canonical.com? :D
[07:43] <Cimi> he changed a lot over the weekend :D
[07:45] <Saviq> lol
[07:47] <Saviq> oh, I got stripped of 5 days off :|
[08:18] <tsdgeos> so you guys can log in?
[08:18] <tsdgeos> i can't :/
[08:20] <mzanetti> o/
[08:20] <mzanetti> good morning
[08:20] <tsdgeos> morning
[08:27] <mzanetti> Saviq: how's your back?
[08:27] <mzanetti> mine was really bad yesterday
[08:28] <mzanetti> getting better today, still feeling it tho
[08:28] <Saviq> mzanetti, back is fine
[08:28] <Saviq> mzanetti, got blisters on my shoulder, though... sunscreen fail
[08:28] <mzanetti> oh really
[08:28] <mzanetti> ouch
[08:28] <Saviq> yesterday night was interesting
[08:29] <mzanetti> I guess so
[08:36] <tsdgeos> mhr3_: how's the departments thing going? need anything from my side?
[08:37] <mhr3_> tsdgeos, nope, think your side is fine, there were some requirements from mike - no departments during searches, so i'm changing stuff
[08:38] <tsdgeos> oki
[08:38] <tsdgeos> mhr3_: just tell me if you need me for anything
[09:48] <mardy> dednick: hi! Do you have a PPA with all the trusted session goodness?
[09:51] <dednick> mardy: it was here: https://launchpad.net/~ci-train-ppa-service/+archive/landing-001
[09:51] <dednick> mardy: not 100% sure if it still is. seems to be powerd there as well, which is a bit odd
[09:53] <Saviq> jibel, hey, I just checked the background setting and it worked fine here...
[09:54] <jibel> Saviq, with build 60?
[09:54] <Saviq> jibel, yes
[09:54] <jibel> Saviq, hm, I'll wipe the device and try again
[09:55] <Cimi> tsdgeos, http://paste.ubuntu.com/7571941/
[09:55] <dednick> Saviq: are you able check on the status of silo1? is was for trust sessions i think, but powerd is there for some reason.
[09:55] <Cimi> tsdgeos, before returning in createCardComponent - very handy
[09:56] <Saviq> dednick, I think it also has AlbertA's power management changes
[09:56] <Saviq> dednick, you should be able to read https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AuDk72Lpx8U5dFVHQ3FuMDJGLUZCamJfSjYzbWh3Wnc#gid=1
[09:56] <Saviq> dednick, and here's an overview http://people.canonical.com/~rbpark/citrain/
[09:57] <dednick> Saviq: thanks!
[09:58] <dednick> mardy: sorry, that wasn't correct then
[09:59] <dednick> Saviq: hm. somebody stole my silo. Can we make a separate ppa for trust sessions, or is it a major pain in the arse?
[10:00] <Saviq> dednick, it is
[10:00] <Saviq> dednick, we'd have to ask for it to be switched to non-virt, and increased its score to be usable at all
[10:01]  * Saviq wonders if we could be guinea pigs on the airline for this
[10:04] <dednick> mardy: let me see if i can build you some packages. for device testing?
[10:13] <jibel> Saviq, I completely reflashed my device and reproduced bug 1325505 . Are you sure you're on build 60?
[10:17] <Saviq> jibel, yeah, I just discovered a few mins ago that I was, indeed, not :|
[10:18] <Saviq> jibel, sorry for having you run after this...
[10:18] <jibel> Saviq, ah ok :)
[10:18] <jibel> Saviq, np
[10:18] <Saviq> jibel, just flashing now, will confirm once done
[10:28] <mardy> dednick: thanks, that would help a lot (yes, it's for the device)
[10:28] <dednick> mardy: might take some time! :)
[10:31] <Saviq> dednick, let me know which MPs, I'll try and cross-build stuff
[10:32] <mhr3_> Saviq, how do you x-build unity when there's the uitk issue?
[10:32] <Saviq> mhr3_, I have a local repo into which I put natively-built UITK
[10:32] <Saviq> jibel, huh, it works for me still...
[10:32] <mhr3_> i did not understand half of that sentence :)
[10:33] <Saviq> mhr3_, I've a local archive
[10:33] <Saviq> mhr3_, that sbuild picks up
[10:33] <Saviq> mhr3_, https://wiki.ubuntu.com/SimpleSbuild#Local_packages
[10:34] <mhr3_> you just put .debs in there?
[10:34] <Saviq> mhr3_, on that note https://code.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/trunk
[10:34] <Saviq> mhr3_, yes
[10:35] <mhr3_> oh, so it should just work now
[10:35] <mhr3_> yey?!
[10:36] <Saviq> mhr3_, yup
[10:36] <jibel> Saviq, ack, I'll check if someone else can confirm
[10:36] <jibel> or not
[10:41] <dednick> Saviq: https://pastebin.canonical.com/110959/
[10:42] <dednick> Saviq: might be easier to get the package created by CI for the mir one.
[10:51] <Saviq> dednick, conflict in u-s-c
[10:53] <dednick> Saviq: great. not usc is ahead of usc/devel ?
[10:53] <dednick> s/not/now
[10:54] <Saviq> dednick, it should be renamed to "mirdevel"
[10:54] <Saviq> dednick, it's only in place to follow mir dev
[10:54] <Saviq> dednick, so yeah, it needs manual merges from trunk from time to time
[10:54]  * Saviq does
[10:54] <Saviq> dednick, if your branch depends on it, it should target devel, though, not trunk directly?
[10:57] <Saviq> dednick, pushed, you need to resolve anyway
[10:58] <dednick> Saviq: yeah, it should target devel rather.
[10:59] <Saviq> dednick, we know it's not great, we kind-of got infected by mir devel on this
[11:15] <Saviq> xnox, could you have a look at platform-api for x-building? it seems to have some weird dep resolving issue
[11:26] <dednick> Saviq: hm. usc seems a bit out of date for mir/devel. not sure I'm qualified to update it. I'll check it out and maybe pass on to mir team for a pre-requisite branch.
[11:27] <Saviq> dednick, mhm
[11:27]  * Saviq just managed to loop byobu :D
[11:27] <dednick> it's all a bit cross buggered
[12:30] <Saviq> mzanetti, fwiw, it'd be better if you verified locally before pushing it to the PPA
[12:30] <mzanetti> Saviq: yeah, doing that currently
[12:30] <Saviq> mzanetti, ok great
[12:30] <Saviq> I'll shut up now
[12:34] <Saviq> dednick, greyback, what's the order in which one should build mir and papi?
[12:34] <greyback> Saviq: mir first, then papi
[12:37] <Saviq> greyback, but then I end up with libubuntu-application-api-mirserver1:armhf : Depends: libmirserver19:armhf
[12:37] <Saviq> greyback, when mir bumped to libmirserver20
[12:38]  * Saviq smells a circular dep
[12:42]  * mzanetti is really struggling with getting Shell.qml merged between QtComp and trunk
[12:43] <mzanetti> seems dandrader removed a lot of stuff which I think would still be required
[12:44] <greyback> mzanetti: such as?
[12:44]  * greyback having bad wifi day
[12:44] <mzanetti> first use demo for instance
[12:44] <mzanetti> hiding indicators in certain circumstances
[12:44] <greyback> hmm, no idea why he's done that
[12:45] <greyback> I say put it back
[12:45] <mzanetti> yeah... still the whole file is a single conflict basically
[12:46] <greyback> sadly yeah
[12:54] <Saviq> greyback, so yeah, it looks like it's "papi, mir, papi" to make it all play together...
[12:55] <greyback> Saviq: that sonud very wrong. Mir has no dependence on papi
[12:55] <mzanetti> Saviq: for some reason we seem to pull in qt 4 now. do you know why?
[12:56] <Saviq> greyback, no, but unity-mir does, and papi builds against mir
[12:56] <Saviq> greyback, so I ended up with unity-mir pulling papi, papi pulling mirserver19, when mirserver20 was built against the new papi
[12:57] <Saviq> so it tried to have both mirserver19 and 20, which is obviously not good
[12:58] <Saviq> dednick, are you doing anything with u-s-c then?
[13:11] <dednick> Saviq: was just at lunch, so will get sorted now. But for mardy i think cross build without merging is needed.
[13:12] <Saviq> dednick, just of your branch? that might not work with the split greeter landed...
[13:12] <Saviq> let's see
[13:13] <dednick> Saviq: hmm. maybe i should just build packages on my device
[13:13] <Saviq> dednick, I don't mean x-build won't work
[13:14] <Saviq> dednick, rather that if there's things that u-s-c in trunk has, but your branch doesn't
[13:14] <Saviq> dednick, that will be tricky
[13:14] <dednick> Saviq: right. well let me just check out what's missing then
[13:15] <Saviq> dednick, if you just merge devel in your branch, shouldn't that be good enough?
[13:15] <dednick> Saviq: there are changes in mir/devel for the scene, which usc overrides
[13:16] <dednick> devel is not up to date apparently
[13:16] <Saviq> dednick, you mean mir/devel? ouch
[13:16] <dednick> Saviq: sorry, i mean, there something NEW that is being overrided in usc/trunk is not in usc/devel, but there have been changes to that interface in mir/devel
[13:17] <dednick> Saviq: so need to merge usc/trunk -> usc/devel first.
[13:18] <Saviq> dednick, I did that this morning
[13:18] <Saviq> dednick, it was a clean merge, and it only conflicts in two small instances with your stuff
[13:18] <Saviq> dednick, so should be good I think
[13:19] <dednick> Saviq: hm. let me try again
[13:19] <Cimi> ouch https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1325580
[13:24] <Saviq> dednick, heads up, kgunn's renaming the (mir)devel branches
[13:26] <kgunn> dednick: are you in the middle of something...
[13:26] <kgunn> ?
[13:26] <kgunn> i can wait till my afternoon
[13:26] <kgunn> when its quiet
[13:26] <dednick> kgunn: nope. should be ok
[13:31] <tsdgeos> guys
[13:31] <tsdgeos> does make xvfbtestLazyImage succeed for you?
[13:31] <tsdgeos> or is it a 5.3 brokenness thing?
[13:31] <dednick> Saviq: ok, so now usc/devel is now out of date from mir/devel. :( I'll see if i can re-jig it.
[13:31] <kgunn> dednick: i'll mess with it after my lunch....as not to disturb
[13:32] <dednick> kgunn: thanks
[13:32] <Saviq> dednick, yay for devel branches :|
[13:32] <kgunn> hater
[13:32] <tsdgeos> same for xvfbtestShell
[13:32] <kgunn> :)
[13:36] <dednick> this overriding of mir interfaces in usc is kind of mad. should export some decorators from mir or something...
[13:48] <mzanetti> greyback: Saviq: ok have unity8 running without greeter now. I think we need to add rotation/locked landscape to the greeter stuff still
[13:49] <Cimi> i hate the cardcreator code
[13:49] <Cimi> I understand is fast, but is a puzzle
[13:49] <Cimi> we must come up with a smarter solution - ideas welcome
[13:49] <greyback> mzanetti: probably yeah. Though now there's a process divide between unity8 & greeter, we will eventually need a channel to communicate orientation state between them
[13:50] <Saviq> Cimi, right back at you
[13:50] <Cimi> Saviq, ?
[13:50] <Saviq> Cimi, "ideas welcome"
[13:50] <Cimi> Saviq, yes I am thinking too
[13:51] <Saviq> Cimi, bear in mind you're not the first one
[13:51] <mzanetti> greyback: yep. but for MAE I guess we'll just fix it to landscape too
[13:51] <greyback> mzanetti: yeah, that'll do
[13:51] <Cimi> Saviq, I know I was chatting with mzanetti last week about cards
[13:51] <Cimi> and alber
[13:52] <mhr3> clearly it's time to write a dynamic generator for the dynamic generator
[13:52] <mzanetti> Saviq: tsdgeos is renaming some tests (tst_Phone.qml, tst_Tablet.qml). your opinion?
[13:52] <mzanetti> tst_GreeterPhone.qml etc ok?
[13:53]  * Cimi the next fly stopping on my legs I will kill the first person next to me
[13:53] <Saviq> mzanetti, I asked him to
[13:53] <mzanetti> or rather tst_GreeterSmall.qml, tst_GreeterWithLoginList.qml etc?
[13:53] <Saviq> mzanetti, ah well, the names... the difference is really single vs. multiuser
[13:53] <mzanetti> yeah, the fact he's doing it is fine... but we shouldn't have "Phone" "Tablet" etc as per your speech
[13:54] <Saviq> ;)
[13:54] <mzanetti> Saviq: not really tbh
[13:54] <Saviq> well, right, it's not
[13:54] <Saviq> wide vs. narrow?
[13:54] <mzanetti> I think also the phione one has multiuser if LightDM says so
[13:54] <mzanetti> sounds good to me
[13:54] <mzanetti> tsdgeos: ^
[13:54] <dednick> this overriding of mir interfaces in usc is kind of mad. should export some decorators from mir or something...
[13:54] <mzanetti> Wide, Narrow etc it is
[13:54] <dednick> damnit
[13:54] <Saviq> so portrait vs. landscape is the real difference
[13:54] <tsdgeos> :D
[13:55] <tsdgeos> so wide/narrow or portrait/landscape?
[13:55] <Saviq> ;)
[13:55]  * mzanetti is fine with any of those
[13:55] <Saviq> they should get merged is what I'd be fine with ;)
[13:55] <mzanetti> lol
[13:55] <Saviq> dednick, you're repeating yourself
[13:55] <mzanetti> fair point
[13:55] <dednick> Saviq: i'm just that upset :)
[13:56] <mzanetti> Saviq: actually the reason they're split into 2 files is just that the narrow one doesn't need most of it...
[13:56] <mzanetti> Saviq: so we're saving memory by loading a smaller subset
[13:56] <mzanetti> seems legit to me
[13:56] <tsdgeos> Saviq: "It's a trap!"
[13:56] <Saviq> mzanetti, yeah I know, but what will you do with a multi-user phone? ;)
[13:57] <Saviq> mzanetti, I mean that that distinction is wrong
[13:57] <mzanetti> we still load the one with the loginlist
[13:57] <mzanetti> I guess its really singleuser vs multiuser
[13:57] <Saviq> yeah, even if multiuser is used in singleuser scenarios
[13:58] <Saviq> mzanetti, on the "saving memory" side with the split greeter... you saw the bug ;)
[13:58] <mzanetti> I did
[13:59] <mzanetti> that's quite *ouch*
[13:59] <mzanetti> :D
[13:59] <Saviq> I just noticed something that might be related, just rebooted to check
[13:59] <Saviq> s/rebooted/reflashed/
[13:59] <mzanetti> so... what should albert do with those names?
[13:59] <Saviq> mzanetti, tsdgeos, SingleGreeter vs. MultiGreeter?
[14:00] <tsdgeos> Saviq: ok for me
[14:00] <mzanetti> ack
[14:00] <Saviq> /food
[14:00] <Saviq> jeez it's 4pm already
[14:00] <mzanetti> yeah... crazy
[14:00]  * Saviq is 8h in today...
[14:00] <Saviq> already
[14:00] <mzanetti> Saviq: did you just directly start working after leaving the plane or what?
[14:01] <dednick> Saviq: i have no idea how usc got so out of date. It's like something has been overwritten
[14:01] <Saviq> mzanetti, I just couldn't sleep much... guess why ;)
[14:01] <Saviq> mzanetti, started at 8
[14:01] <Saviq> dednick, is trunk in the same state?
[14:01]  * mzanetti pities Saviq
[14:02] <Saviq> dednick, or maybe it's basically that devel didn't get updated after the last mir release?/
[14:02] <Saviq> -/
[14:02]  * mzanetti slept like a baby... and could do for another 10 hours I guess
[14:02] <dednick> Saviq: well trunk is find against mir trunk, so it's probably ok
[14:02] <dednick> but devel hasn't been changed in over a month, but i've been building against trust sessions.
[14:02] <Saviq> dednick, yeah, so I'm thinking usc just never got the love
[14:02] <dednick> which are on mir/devel
[14:02] <dednick> :/
[14:03] <Saviq> yay for devel branches, again
[14:03] <dednick> unless maybe my dodgey build script has a bug in it :)
[14:03] <mzanetti> greyback: heads up, gonna push a merge with trunk to unity8/mirCompositor soon
[14:04] <greyback> mzanetti: go for it, was keeping well away
[14:08] <Saviq> mzanetti, on Saturday I just put the hotel balm on ice and used it ~ every hour, which was how often I woke up ;)
[14:08] <Saviq> mzanetti, so yeah, fun times ;) last night was much easier already
[14:08] <mzanetti> Saviq: you should have taken ours... its some special after sun stuff
[14:09] <mzanetti> but I guess at this stage it wouldn't have done miracles any more either
[14:09] <Saviq> mzanetti, indeed
[14:09] <Saviq> mzanetti, helped anyway
[14:09] <Saviq> mzanetti, found a pharmacy in the morning and got an after-sun gel thingy
[14:09] <mzanetti> its kinda weird.. you looked ok all day long
[14:09] <mzanetti> and from one minute to the other you were turning red
[14:09] <Saviq> indeed
[14:09] <Saviq> I just need to spend more time outside ;)
[14:10] <Saviq> with more sunscreen!
[14:10] <larsu> Saviq: aloe!
[14:10] <mzanetti> when I do stuff like this I always put sunscreen on before breakfast already, to make sure it enters the skin properly by the time I reach the sun
[14:11] <Saviq> mzanetti, I got some from greyback when I left the room
[14:11] <mzanetti> so greyback's sun screen sucks :D
[14:11] <Saviq> mzanetti, so that was fine, I think I didn't do enough to update it during the day ;)
[14:11] <mzanetti> probably
[14:12] <Saviq> mzanetti, right, and looking at him you can't see how that's possible, right!
[14:12] <greyback> it has succeeded in protecting my irish skin from getting burned many times,  so I suspect E_USER here
[14:12] <dednick> probably 10 years out of date
[14:12] <dednick> no sun in ireland
[14:12] <mzanetti> lol
[14:12] <Saviq> ;D
[14:13] <Saviq> PEBTAS
[14:13]  * greyback has no stinging reply at hand....
[14:13] <Saviq> but I can only imagine what the sun does to you in Malta... in July
[14:14] <mzanetti> better stay away from there at that time
[14:15] <mhr3> it's fine ;)
[14:17] <dednick> good think it's june
[14:41] <mzanetti> dednick: can you please send me a mail with all the branches you need in that ppa?
[14:41] <dednick> mzanetti: so not too sure about the ppa at the moment. i've got to get everything up to date first. usc isn't at mir/devel, and neither is qtmir.
[14:42] <mzanetti> dednick: ok, no worries. Just send the mail when you're ready and I'll get going then
[14:42] <dednick> mzanetti: thanks. will do
[14:50] <mzanetti> going to the grocer's shop now. bbiab
[15:04] <Cimi> Saviq, how do I get the vertical center of the first line of text of a two lines label?
[15:05] <Cimi> Saviq, trying to align the emblem, easy with 1 line, but with two... boh
[15:05] <Saviq> Cimi, you probably want to align with baseline
[15:06] <Cimi> Saviq, baseline for two lines is the first?
[15:06] <Saviq> Cimi, yes
[15:07] <Cimi> Saviq, so emblem... anchors.baseline = ?
[15:08] <Saviq> Cimi, title.baseline
[15:08] <Cimi> ok
[15:08] <Cimi> trying
[15:17] <Saviq> Cimi, FWIW it looks like it's not documented
[15:17] <Cimi> Saviq, that's why I asked you
[15:17] <Cimi> Saviq, I googled, no info, so Saviqoogle
[15:20] <Saviq> Cimi, yeah, it looks like http://qt-project.org/doc/qt-5/qml-qtquick-item.html#baselineOffset-prop is the doc for baseline (there's no point in having baselineOffset there)
[15:20] <Saviq> Cimi, it's just at the wrong prop
[15:21] <Saviq> otoh Item.{top,bottom,left,right,{horizontal,vertical}Center} aren't documented either
[15:21] <Saviq> at least not as properties of Item, that is
[15:34]  * tsdgeos goes back to 5.2
[15:35] <tsdgeos> don't want to fight what may or may not be a 5.3 bug :/
[16:47] <mhall119> Saviq: ping
[16:47] <mhall119> bregma: ping
[16:48] <bregma> mhall119, pong?
[16:48] <mhall119> bregma: hey, I asked on G+ what sessions people wanted for Ubuntu Online Summit and I got two suggestions:
[16:48] <mhall119> 1) Progress report on convergence (Unity 8 desktop)
[16:49] <mhall119> 2) Maximizing productivity using Unity
[16:49] <mhall119> are either of those something you could give a presentation on with a Q&A after?
[16:52] <mhall119> Saviq: ^^ you were going to get the same question :)
[16:53] <mhall119> Maybe Trevinho can done one about using Unity 7
[16:53] <bregma> mhall119, I can probably do a progress report on desktop convergence (although it would be failrly short at this point), I think Marco Trevisan would be better for talking about improving your productivity
[16:53] <bregma> if he's willing
[17:01] <mhall119> bregma: sounds good, can I go ahead and create a session for you on summit?
[17:08] <bregma> mhall119, OK, go ahead
[17:12] <mhall119> bregma: please register for UOS so I can set you as the presenter: http://summit.ubuntu.com/uos-1406/registration/


[20:27] <pizzadude> hi
[20:28] <pizzadude> is the mainline kernel going to be compiled with retpoline for spectre mitigation in the future?
[20:28] <pizzadude> i mean the kernels at http://kernel.ubuntu.com/~kernel-ppa/mainline/
[20:35] <pizzadude-> right now it's "Minimal generic ASM retpoline" but not full protection
[20:35] <apw> pizzadude, we don't even have retpoline compilers in the main archive yet, so we need those first
[20:36] <apw> beyond that if it needs configurations we can sort that out and rebuild some of the key kernels
[20:36] <pizzadude-> ok but is it gonna be fixed in mainline eventually (i know its mainly used for debugging, but i hate waiting for kernel fixes to be backported)
[20:37] <pizzadude-> ^thats not me
[20:38] <pizzadude-> well, it's my nick but
[20:38] <apw> ?
[20:38] <pizzadude-> nvm
[20:38] <pizzadude-> but yeah is it gonna be fixed eventually or is the mainline kernel "ppa" a red headed stepchild that canonical doesnt care about
[20:41] <apw> the mainline ppa builds there are for debugging, we keep a weather eye on them, they are not official in any sense
[20:42] <pizzadude-> yeah i know but some people use them
[20:42] <apw> with meltdown/spectre we are likely to make more effort to get them working
[20:43] <pizzadude-> them being "ubuntu kernels", mainline, or both?
[20:43] <pizzadude-> sorry if im being annoying
[20:43] <apw> the mainline builds test builds
[20:44] <pizzadude-> thanks
[20:45] <pizzadude-> .


[02:15] <mup> PR snapd#11070 opened: gadget/gadget.go: include disk schema in the disk device volume traits too <Simple 😃> <Skip spread> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/11070>
[06:37] <mborzecki> morning
[07:37] <mup> Issue core18#162 closed: Beef up build instructions <Created by WillNilges> <Closed by Meulengracht> <https://github.com/snapcore/core18/issues/162>
[07:57] <pstolowski> morning
[08:31] <mardy> hi mborzecki, mvo, pstolowski!
[08:32] <mborzecki> hey
[09:10] <juliank> experimental.refresh-app-awareness seems a bit suboptimal atm, it asks me to close apps to prevent disruptions and seems to not do any update. I'd have expected it to download the update and apply it when I close the app/reboot; as it stands now, there's basically no advantage as the apps run continously
[09:11] <juliank> like now I have to close the app, run snap refresh manually to get it over with?
[09:17] <pstolowski> juliank: that, or it will get retried on next auto-refresh (which will happen in whatever refresh window you have set (4 times a day by default)
[09:17] <juliank> pstolowski: right but the app runs all the time, the only time it's not running is during boot
[09:18] <juliank> (or shortly if it got borked)
[09:22] <juliank> optimally I guess it would do the refresh as usual, except for switching the current version over, then do the switch of current at boot/when app is closed
[09:22] <juliank> WOuld work nicer :D
[09:25] <pstolowski> juliank: yes i see your point, it's not as simple as just switching current revision over unfortunately because we run hooks for example
[09:26] <juliank> yeah hooks are evil :D
[09:27] <pstolowski> juliank: i suggest you take it to https://forum.snapcraft.io/t/wip-refresh-app-awareness/10736
[09:28] <pstolowski> to get more input and rationale, also from our architect
[09:40] <pstolowski> jamesh: hi, not sure if you saw it, but I proposed 2 PRs for notifications - https://github.com/snapcore/snapd/labels/refresh%20app%20awareness
[09:40] <pstolowski> jamesh: your feedback would be great
[09:40] <pstolowski> (but also, no rush)
[09:41] <jamesh> pstolowski: yeah. I saw one of the emails last night, but didn't get round to it this morning. Will have a look
[09:42] <pstolowski> thanks
[11:12] <mup> PR snapd#11071 opened: data/env: provide profile setup for fish shell <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/11071>
[11:27] <mborzecki> jamesh: hi, still around? https://github.com/snapcore/snapd/pull/11023 failed on shellchecks, i can push a fix for this and a unit test for strv if you don't mind
[11:27] <mup> PR #11023: cmd/snap-confine: do not include libglvnd libraries from the host system <⛔ Blocked> <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/11023>
[11:30] <jamesh> mborzecki: I'll push a fix for that now. I also need to add the gl-core20 test as well: was waiting to see if the first change passed.
[11:30] <mborzecki> jamesh: ok, thanks!
[11:31] <mborzecki> jamesh: since i already have it, the patch with unit test: https://pastebin.ubuntu.com/p/JMf4ctkCsn/
[11:39] <jamesh> mborzecki: thanks.  I've got to head out, but I'll integrate it when I get home (the pastebin doesn't apply cleanly, since it seems to have converted tabs to spaces)
[11:48] <pstolowski> jamesh: thanks for the feeback on the notifications PR
[13:03] <mup> PR snapd#11072 opened: usersession/client: provide a way for usersession client to send messages only to a subset <refresh app awareness> <Created by stolowski> <https://github.com/snapcore/snapd/pull/11072>
[13:03] <pstolowski> jamesh: i created a separate PR for what you suggested ^
[13:18] <mup> PR snapd#11073 opened: tests/lib/prepare: allow word splitting of EXTRA_FUNDAMENTAL <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/11073>
[13:23] <mup> PR snapd#11070 closed: gadget/gadget.go: include disk schema in the disk device volume traits too <Simple 😃> <Skip spread> <Created by anonymouse64> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/11070>
[13:48] <mup> PR snapd#11074 opened: tests: reorganize the debug-each on the spread.yaml <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/11074>
[16:54] <mup> PR snapd#11075 opened: tests: use --snap instead of --extra-snaps to create the core image <Simple 😃> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/11075>
[17:04] <mup> PR snapd#11076 opened: snapcraft.yaml: fix advanced grammar & 20.04 packaging <Created by xnox> <https://github.com/snapcore/snapd/pull/11076>
[20:00] <mup> PR snapd#11077 opened: tests: use ubuntu-image from stable channel which uses go 1.11 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/11077>


[05:57] <bkerensa> philipballew_: u there
[07:04] <bkerensa> philipballew_:
[07:06] <bkerensa> philipballew_:  so maybe you could meet me at my place tomorrow before heading to OSCON?
[07:07] <bkerensa> I found out I have far more stuff for the booth than anticipated
[07:11] <philipballew__> bkerensa, sure if I know hoow to get there
[07:12] <bkerensa> philipballew_: u have a bus pass right?
[07:12] <philballew> bkerensa, totally do yes
[07:13] <bkerensa> philballew: you guys are on 102nd ave?
[07:14] <philballew> 82nd
[07:14] <philballew> right next to the max station
[07:15] <bkerensa> LOL
[07:15] <bkerensa> LOL
[07:15] <bkerensa> >.<
[07:15] <bkerensa> ok
[07:15] <bkerensa> so why dont uhm
[07:15] <bkerensa> I meet you at the MAX station?
[07:15] <philballew> that sounds good.
[07:15] <philballew> what time?
[07:17] <bkerensa> philballew: uhh what time did you usually leave?
[07:17] <bkerensa> http://awesomescreenshot.com/03aaoqy79
[07:17] <darthrobot> Title: [Google Maps | Awesome Screenshot]
[07:17] <bkerensa> I live in the area where the circle is
[07:18] <bkerensa> where as the green lines are borders as to where things get shady
[07:18] <bkerensa> :P
[07:18] <bkerensa> I was thinking about being at the MAX around 9am ish?
[07:19] <bkerensa> but if u PM ur # I can just text u in the morning
[07:19] <philballew> that should work
[07:19] <philballew><PHONE_NUMBER>
[07:19] <philballew> i can throw the # here
[07:20] <philballew> I left here at 730 today
[07:20] <philballew> but can leave anytime
[07:22] <bkerensa> boom got it
[07:22]  * bkerensa going to sleeeep
[07:22] <philballew> alright. peace!
[07:24] <DonkeyHotei> reminder: this channel is publicly logged and googleable
[07:41] <philballew> DonkeyHotei, All the more reason to give out my number! I can make more friends that way!
[14:25] <bkerensa> philipballew_:  u awake?
[16:26] <raevol> http://blogs.valvesoftware.com/linux/steamd-penguins/
[16:26] <darthrobot> Title: [Steam’d Penguins | Valve]
[20:47] <DonkeyHotei> anyone in the market for storage of any kind?
[20:48] <raevol> the free kind
[20:48] <DonkeyHotei> that's not a market
[20:48] <raevol> ;P
[20:49] <akk> A cheap, fast and power-efficient laptop SSD.
[20:50] <DonkeyHotei> akk: that would be the SanDisk Ultra SDSSDH-120G-G25 but it's not what i need to unload
[20:51] <DonkeyHotei> i managed to buy a disk i can't really use
[20:52] <DonkeyHotei> Seagate FreeAgent GoFlex USM-SATA 1.5TB USB 3.0
[20:56] <akk> That's a bit more specific than "storage of any kind" :)
[20:57] <DonkeyHotei> yes, but it would fit that market


[19:25] <bdx> https://bugs.launchpad.net/juju/+bug/1730228
[19:25] <mup> Bug #1730228: enable-ha doesn't apply zone directive to subsequent instances <juju:New> <https://launchpad.net/bugs/1730228>


[04:37] <pitti> Good morning
[11:09] <jamespage> jibel, pitti: have we considered switching over to using debci for DEP-8 test reporting? I find ci.debian.net much easier to access than jenkins
[13:20] <pitti> jamespage: yes, I've been working on and off on a next-gen cloud-based system
[13:21] <pitti> jamespage: I worked on debci itself quite a lot to support multiple backends, mutliple arches, etc. if you are interested: https://wiki.debian.org/debci/DistributedSpec
[13:21] <pitti> jamespage: vila works on CI airline autopkgtest integration too
[13:22] <pitti> jamespage: I expect that the next thing that we'll switch to will be this, plus using the debci web UI for viewing the results (the swift data format should be compatible)
[14:33] <elfy> balloons: you about?
[14:39] <balloons> elfy, perhaps
[14:39] <elfy> lol
[14:40] <elfy> got issues booting both xubuntu and ubuntu dailies today - have to go to vt1 and startx - loginctl show-seat seat0 shows CanGraphical=no for both
[14:40] <balloons> yikes
[14:41] <elfy> bug 1365336 is one I've been working on with an issue I had - what's confusing me is surely the livesession uses nouveau or the amd opensource one
[14:41] <elfy> why would livesession crash?
[14:41] <elfy> and I've neither the knowledge to dig into that nor any idea who else to tell :p
[14:42] <balloons> elfy, what machine are you trying on?
[14:42] <elfy> vm personally - with nvidia card
[14:42] <slickymasterWork> hey balloons o/
[14:42] <elfy> slickymasterWork: what are you trying it  on?
[14:43] <balloons> ahh alberto is already on it
[14:43] <balloons> hey slickymasterWork
[14:43] <slickymasterWork> that's why I stepped in, here you go ballons -> http://phillw.net/hardware/Ed3c22qV´
[14:43] <slickymasterWork> http://phillw.net/hardware/Ed3c22qV
[14:44] <elfy> balloons: yea - I have received the fixed file here - removed my chucked together .rules file and it the machine is fine
[14:44] <elfy> I'm more concerned with the livesession now
[14:44] <slickymasterWork> balloons: FWIW see https://bugs.launchpad.net/ubuntu/+source/xubuntu-default-settings/+bug/1365815
[14:44] <elfy> not sure where to go with that
[14:45] <elfy> slickymasterWork: that's possibl;y a different issue altogether - I've seen that and it still works ok
[14:45] <slickymasterWork> the INSTALL option works like a charm balloons, the issue just exists in the LiveSession
[14:46] <elfy> that bug is just the wallpaper missing like it does every cycle
[14:46] <elfy> The try option would work if CanGraphical=no was yes
[14:47]  * elfy is positive about that - having been affected by both :)
[14:48] <elfy> balloons: would it be better to create a livesession bug for the cangraphical issue?
[14:53]  * balloons is trying to follow
[14:53] <balloons> ok, so the first bug is about your lightdm desktop update that broke things
[14:54] <balloons> interesting bug, but looks solved, and I get it
[15:00] <elfy> but is it solved - this is what I'm trying to ascertain - why is the livesession even interested in an nvidia package?
[15:01] <elfy> the second bug is something else I'm sure
[15:02] <balloons> there's some udev rules that seem to be the issue
[15:02] <elfy> yea for fglrx and nvidia*
[15:03] <balloons> yea, it's interesting.
[15:03] <elfy> I guess if tomorrow's daily still has the same issue then it's something extra and needs reporting
[15:03] <balloons> my guess is they are consulted regardless of use
[15:04] <elfy> balloons: ok - well I will hold fire on saying anything else for the time being
[15:05] <elfy> why does jenkins not report the live as a fail - or does it not look at that sort of thing?
[15:07] <balloons> elfy, graphical issues are hard to determine..no attempt is made by the AP tests to do so
[15:07] <balloons> that said, I find it interesting the tests made it through the checks
[15:07] <elfy> ok - thanks for that - was a bit confused :)
[15:07] <balloons> if it appears to install ok, but then fails to load up after we won't see it
[15:07] <balloons> we should detect boot failures, but nothing beyond
[15:08] <balloons> it would be interesting to have a test for a live session. I don't know that we have one
[15:09] <elfy> it boots fine, if you choose install rather than try - that works as expected
[15:09] <elfy> it's just livesession
[15:09] <balloons> right.. and nothing goes after try :-)
[15:09] <elfy> yep - CanGraphical=you have to be joking :D
[15:10] <balloons> elfy, for giggles, open a bug against ubiquity and ask for an autopilot test to be run against the live session
[15:10] <elfy> :)
[15:10] <balloons> seriously, so the idea won't be lost at least
[15:10] <elfy> I'm just doing so now
[15:11] <balloons> I think it could basically just check that the greeter started and stays running for a few mins, and the desktop session starts and stays running
[15:15] <elfy> bug 1366079
[15:15] <elfy> there you go balloons
[15:16] <balloons> elfy, excellent thanks
[15:16] <elfy> yw
[15:17] <elfy> balloons: so - just quickly going back to issue #1 here - if I do get the same issue tomorrow - what should I report it against do you think?
[15:17] <balloons> the same issue? I would report against lightdm if it's the same
[15:17] <elfy> ok - thanks then :)
[15:51] <elopio> balloons: review please: https://code.launchpad.net/~canonical-platform-qa/ubuntu-calendar-app/fix1351319-swipe_to_get_current_day/+merge/229356
[16:07] <balloons> elopio, lol.. this is perfect. I was just looking at this
[16:09] <balloons> elopio, so the only confusion is on https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1365674
[16:10] <elopio> balloons: yes. But I think it's not a big deal, I
[16:10] <elopio> 'll just add the optional argument and calendar will keep working.
[16:10] <balloons> I don't see the issue. You are calling a private helper, from a private helper
[16:11] <balloons> ohh, lol, I get it now
[16:11] <balloons> sorry :-)
[16:11] <elopio> calling a private helper on one project from a private helper on a different project.
[16:11] <balloons> yes, lol
[16:11]  * balloons rattles head
[16:12] <balloons> approved. Thanks elopio
[16:12] <elopio> thanks
[16:26] <elopio> balloons: what about a new release of weather to the store?
[16:26] <balloons> elopio, we can do one, I take it there's something you need to release
[16:27] <elopio> balloons: this one: https://bugs.launchpad.net/ubuntu-weather-app/+bug/1365279
[16:27] <balloons> elopio, ohh, I see 358 is in there
[16:27] <balloons> so that fix should be in
[16:28] <balloons> so latest trunk is in store
[16:29] <elopio> balloons: ok, thanks. So maybe next run will pass.
[16:29] <balloons> yep
[16:31] <knome> balloons, ping.
[16:32] <balloons> knome, pong
[16:32] <knome> balloons, we need to talk about the trackers... you will see pleia2 next week, and we will gather her a list of things that sucks, and you better be prepared to assure her you will get somebody to fix those issues :)
[16:33] <pleia2> I think sitting down and going through them will be helpful
[16:33] <balloons> knome, we had a pre-cursor to this yesterday. In thinking about it, I think it's the biggest obstacle atm
[16:33] <knome> well that's the nice way to say it i guess
[16:33] <balloons> so what we don't have is someone who knows django and can make the fixes and has the time to do so
[16:34] <balloons> I know you have lots of good stuff I'd like to see implemented knome
[16:34] <knome> well, i have *implemented* a bunch of stuff, but they are waiting to be pushed to production
[16:34] <knome> which also sucks
[16:34] <knome> implemented meaning implemented in the most literal sense you could imagine; the code is sitting in the trunk.
[16:36] <pleia2> balloons: some of the pain points are pretty bad, I love and am committed to Xubuntu and it's making *me* not want to do testing, this needs attention
[16:38] <balloons> elopio, just fyi from my perspective I'm trying to fix-up calculator, trying to land reminders mp's, and trying to tweak rssreader tests to land the new header
[16:38] <balloons> I'd appreciate your thoughts on the calculator mp, I'll share soon
[16:38] <elopio> balloons: ack.
[16:38] <elopio> balloons: I will try to focus on the fake home for reminders, copying what you did on music.
[16:40] <balloons> yea, I was a bit surprised to see it worked, lol.. I had thought it didn't after all our tests :-)
[16:41] <balloons> elopio, so while I have you, you may as well have a look: https://code.launchpad.net/~nskaggs/ubuntu-calculator-app/ap-fix-missing-keypress/+merge/233534
[16:41] <balloons> There's some trouble with missing key presses, and you can see I have a try block catching them atm
[16:42] <balloons> the test suites can certainly use more cleanup in many ways, I'm just trying to unblock there landings
[16:43] <knome> elfy, pleia2: can we schedule some time to sit down and go through what's wrong with the tracker piece by piece?
[16:44] <knome> elfy, pleia2: then make sure they are reported as bugs, and have (clear) enough information for somebody to potentially start working on them?
[16:44] <pleia2> wfm
[16:44] <balloons> knome, this I did not know.. So you simply need someone to review and push the code?
[16:44] <knome> elfy, pleia2: then we could poke balloons and let him find a django expert with time
[16:44] <elfy> knome: I'm about from 2 hours time until Sunday evening
[16:44]  * balloons feels like this conversation happened before
[16:44] <elfy> so does elfy :)
[16:45] <knome> balloons, i only need stgraber to double-check the code is fine and push it to production.
[16:45] <knome> or anybody else that can review and push..
[16:45] <knome> but i believe it all falls down on this one poor guy
[16:47] <knome> pleia2, was saturday your off-from-FOSS day?
[16:47] <pleia2> knome: yeah, I'm available sunday
[16:47] <knome> me too. tomorrow is semi-bad
[16:47] <knome> pleia2, what's your sunday wakeup time?
[16:47] <balloons> so I'll work on unblocking us on the code front. I'll work with stephane to do so
[16:48] <pleia2> knome: nowish
[16:48] <knome> right..
[16:48] <knome> is 16UTC completely out of question?
[16:48] <pleia2> I can make that work
[16:49] <knome> good! elfy, does 16UTC on sunday work for you?
[16:53] <knome> oh elfy...
[16:59] <elopio> balloons: I don't like the retry. Things like this or the select_many_retry generally don't help us getting tests to stable, and don't help us by hiding underlying issues.
[16:59] <pleia2> balloons: thanks re: code unblock
[16:59] <elopio> why are we missing some key presses?
[17:00] <balloons> elopio, yes, I have the retry in there to see what other issues might exist and to try and figure out why the presses are being missed. The app misses keypresses on load, I'm not sure where else, I'm reviewing the log
[17:00] <balloons> anyways, I'll have you look later when it's done
[17:01] <balloons> i'm going to try checking the calc keyboard state before pressing
[17:01] <balloons> or perhaps the button itself even
[17:01] <balloons> if those don't work, I'll come find you
[17:01] <elopio> balloons: I've left you my comments on the branch.
[17:01] <elopio> sure, I'll help you debug, just ping me.
[17:03] <elfy> knome pleia2 - 16UTC is good for me
[17:03] <knome> great :)
[17:04] <knome> added to the team calendar
[17:04] <elfy> okey doke - I'm sure to remember to check that :p
[17:04] <knome> http://xubuntu.org/team-calendar/ :P
[17:04] <knome> or you can sync it with thunderbird...
[17:04] <elfy> I know *where*
[17:04] <elfy> and I do sync with tbird :p
[17:05] <knome> heh
[17:05] <elfy> it's remembering to read it :D
[17:05] <knome> yep
[17:09] <elfy> balloons: if I requested rebuild on tracker for our images - would they get respun with all relevant updates - I'm assuming so
[17:10] <balloons> indeed
[17:11] <elfy> ta - just checking :)
[17:11] <knome> achtung! elfy is cross-posting!
[17:11] <elfy> he's a goblin that elfy guy


[01:52] <Eickmeyer[m]> OvenWerks: The good news is that Ardour will be heading back to the repos. teward and I fixed it.
[01:53] <Eickmeyer[m]> I'll try to figure out if idjc can be salvaged.
[02:43] <Eickmeyer[m]> Yeah, that's way over my head. I don't think I can get that one to patch properly.
 @Eickmeyer orrrrrrrrrr not
 Rejected: … File ardour_5.12.0-3ubuntu1.debian.tar.xz already exists in Primary Archive for Ubuntu, but uploaded version has different contents. See more information about this error in https://help.launchpad.net/Packaging/UploadErrors. … Files specified in DSC are broken or missing, skipping package unpack verification.
 sorry my mail died because my residential network exploded, I had to switch over to my business connection
 but yeah, I'm assuming you didn't version bump it
 so I'm going to version bump it
 which i'd have to do anyways thanks to doko's failures
 @Eickmeyer I've pushed the version change to the repo, can you tag it?
 assuming you do version tagging
 Yeah, I can.
 okay THAT looks better
 ```ardour (1:5.12.0-3ubuntu2) focal; urgency=medium …   * This upload does NOT include the changes introduced in 1:5.12.0-3ubuntu1 …     which is in focal-proposed due to those changes FTBFSing entirely and …     requiring the changes applied here in -3ubuntu2. …   * Update to waf 2.0.19, patch to build with python 3 …     * 0010-waf.pa
[03:56] <studiobot> tch updated by Erich Eickmeyer …     * 0020-fix-wscripts.patch by Erich Eickmeyer, …       code by David Runge (Ardour Developer) …     * 0025-point-to-custom-autowaf.patch by Erich Eickmeyer …       code by Robin Gareus (Ardour Developer) …     * 0028-Patch-waf-to-actually-build-install-properly.patch …       by Erich Eickmeyer, code by Robin Gare
[03:56] <studiobot> us (Ardour Developer) …   * Patch to build against fluidsynth 2 …     * 0027-fluidsynth2.patch by Andreas Müller …   * Drop wiimote support as recommended from upstream Ardour … Date: Fri, 24 Jan 2020 09:36:23 -0800 … Changed-By: Erich Eickmeyer<EMAIL_ADDRESS>… Maintainer: Ubuntu Developers<EMAIL_ADDRESS>… Sig
[03:56] <studiobot> ned-By: Thomas Ward<EMAIL_ADDRESS>… https://launchpad.net/ubuntu/+source/ardour/1:5.12.0-3ubuntu2```
 Accepted
 Probably a result of doko uploading a version that fully FTBFS due to the python 3 thing. #shocker
 Uhhh... you comitted the removal of libs/ardour/config_text.cc and libs/ardour/revision.cc. That might cause problems.
 @teward001 ^
 😐
 okay that's a mistake
 i'll fix that
 git revert
 Yup.
 git revert then nitpick my changelog changes only
 :P
 please :)
 (including the note that it skipped -3ubuntu1 because that's a relevant note)
 (I did the git commit after the source build oops)
 Yeeep, but you're going to have to go 3ubuntu3 because you uploaded 3ubuntu2 and it was accepted.
 ... or we stage the changes for next upload
 -3ubuntu2 the removal of stuff was because of the sbuild run
 debuild run*
 Yeah, I know. I had to discard those changes EVERY time I ran debuild.
 Do you want to do the dirty work or should I?
 i've already reverted.
 Ok. I'll pull.
 just... tag it as -3ubuntu2 if you haven't already.
 then i'll pull and debuild -S it again.  The commit of the removal wasn't intentional
 but debuild *does* remove the files during source vuild run so
 Yeah, but we don't want to screw that up.
 or are you saying that removal is 'bad" because debuild removed them and we need -3ubuntu3 anyways?
 E:UNCLEAR
 well, the git revert reverted the removals so 😜
 the git commit was *after* I did the `debuild -S -sa` call
 sooooo
 that's probably the issue there
 Yeah, I'm not worried about it now, but I would be worried if something got angry about the files not being there to remove.
 You know, unexpected FTBFS and all due to two files not being able to be deleted.
 true, but the `clean` step is called anyways
 and it has `rm -f`
 which means whether it exists or not it won't error
 called during debuild -S and called during build time
 which is why it didn't FTBFS in local testing
 because it was already purged from the source package.
 https://git.launchpad.net/~ubuntustudio-dev/+git/ardour/tree/debian/rules#n96
 and line 98 under it
 there's several clean calls it seems
 Ah, I guess I didn't see that.
 yeah it has multiple nasty clean calls in here
 but the clean phase purges the config_text.cc and version.cc files anyways
 i agree committing that change is *bad*
 but sbuild *will* clean those files
 debuild*
 Right, but we shouldn't be modifying the source files directly. I guess that's probably the biggest objection.
 as i said that's why git revert is helpful
 again
 Yeeep.
 this was just a minor misstep which we can fix because we didn't tag anything yet
 Right.
 extract the changelog bits, revise changelog, commit JUST that
 tag after that
 problem solved
 Yep. So, are we uploading 3ubuntu2 or 3 ubuntu 3? I just want to know what we're doing so as to version properly.
 @teward001 ?
 Nevermind.
 @Eickmeyer [Yep. So, are we uploading 3ubuntu2 or 3 ubuntu 3? I just want to know what we're …], 3ubuntu2
 k
 because the .cc files would be removed anyways
 Right
 That's what occurred to me, hence the nevermind.
[18:30] <RikMills> Eickmeyer: did you seed scribus-ng? if so I think you can go back to scribus normal package now so we can get rid of the ng one
[18:34] <Eickmeyer[m]> RikMills: It's like you read my mind. I'm updating the seed now. haha
[18:35] <RikMills> :)
[18:35] <Eickmeyer[m]> Had to get some ardour stuff fixed in the meantime.
[18:35] <Eickmeyer[m]> That's all sorted now.
[18:35] <Eickmeyer[m]> Just didn't want to update the seed without ardour and raysession.
[18:44] <RikMills> all cool. I was poked by the debian maintainer as they thought it was seeded somewhere
[18:50] <Eickmeyer[m]> It was, is now not.
[19:17] <RikMills> :)


[07:15] <acheronuk> xnox: daily isos fail with 'cpio: premature end of archive' again after the 'fix' in initramfs-tools 0.133ubuntu8
[07:52] -queuebot:#ubuntu-release- Unapproved: gcc-defaults-ports (cosmic-proposed/universe) [1.178ubuntu1.1 => 1.178ubuntu<IP_ADDRESS>] (no packageset) (sync)
[08:10] -queuebot:#ubuntu-release- Unapproved: accepted gcc-defaults-ports [sync] (cosmic-proposed) [1.178ubuntu<IP_ADDRESS>]
[08:22] <sil2100> cjwatson: hey! Thanks for pointing out and dealing with the gcc-defaults-ports binary issues, I just pushed a new version that hopefully shouldn't conflict anymore
[08:28] <cjwatson> thanks
[08:37] <doko> cjwatson, sil2100: I think your upload won't help
[08:37] <doko> I'm trying to understand why this only shows up with gcc-defaults-ports, and not with the other cross packages
[08:37] <cjwatson> That upload does help
[08:38] <cjwatson> I mean, maybe not permanently, but its binary versioning scheme is such that it won't collide
[08:38] <doko> how? it
[08:38] <doko> hmm
[08:38] <cjwatson> Because it has .18.10.1 on the end
[08:38] <sil2100> I don't understand the build process, but I did try to make sure the ubuntu part of the version is non-collidable with bionic
[08:39] <doko> ahh, ok, such a version bump would not help for gcc-N-cross and gcc-N-cross-ports
[08:53] -queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (bionic-proposed) [4.15.0-1041.46]
[09:01] -queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (disco-proposed) [2.39.2+19.04]
[09:01] -queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (cosmic-proposed) [2.39.2+18.10]
[09:02] -queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (bionic-proposed) [2.39.2+18.04]
[09:02] -queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (xenial-proposed) [2.39.1]
[09:03] -queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (xenial-proposed) [2.39.2]
[09:32] <LocutusOfBorg> what is preventing src:papi from being accepted? it is not built on s390x, but neither the previous version is...
[09:33] <cjwatson> nothing?
[09:33] <ginggs> @LocutusOfBorg new binaries
[09:34] -queuebot:#ubuntu-release- New: accepted papi [amd64] (eoan-proposed) [5.7.0+dfsg-1]
[09:34] -queuebot:#ubuntu-release- New: accepted papi [armhf] (eoan-proposed) [5.7.0+dfsg-1]
[09:34] -queuebot:#ubuntu-release- New: accepted papi [ppc64el] (eoan-proposed) [5.7.0+dfsg-1]
[09:34] -queuebot:#ubuntu-release- New: accepted papi [arm64] (eoan-proposed) [5.7.0+dfsg-1]
[09:34] -queuebot:#ubuntu-release- New: accepted papi [i386] (eoan-proposed) [5.7.0+dfsg-1]
[09:34] <ginggs> cjwatson: thanks :)
[09:34] <LocutusOfBorg> cjwatson, the question is: does the "auto accept tool" check if all archs are built, and becomes manual if some of them are missing, or does check if previous version were missing too?
[09:34] <cjwatson> auto-accept is not a thing for NEW
[09:34] <LocutusOfBorg> thanks for accepting :D
[09:35] <LocutusOfBorg> oh, I remember you talking about some half made auto accept script, but I admit I lost the context probably
[09:35] <cjwatson> there is new-binary-debian-universe, but that's a helper that archive admins can run by hand
[09:35] <cjwatson> just saves a bit of time when processing the obvious bulk stuff in NEW
[09:36] <apw> the other auto accept bot is for unapproved late in the cycle
[09:36] <cjwatson> and it has no particular architecture checks
[09:36] <LocutusOfBorg> yeah probably that one, but does it work if some arch is not built yet?
[09:36] <cjwatson> it works fine, I just ran it
[09:37] <LocutusOfBorg> how does it work if some of the stuff in new is built on some arch and is not yet built on others?
[09:37] <cjwatson> it cares not
[09:37] <cjwatson> proposed-migration will sort that sort of thing out
[09:37] <LocutusOfBorg> sure thing :D thanks!
[09:38] <cjwatson> also, it prompts - if there's some kind of complicated layered rebuild in process then an archive admin can choose to wait
[09:38] <cjwatson> but it's up to the human in the loop
[09:41] <LocutusOfBorg> ack thanks
[10:44] -queuebot:#ubuntu-release- Unapproved: kazam (disco-proposed/universe) [1.4.5-2.1 => 1.4.5-2.1ubuntu0.1] (no packageset)
[11:38] -queuebot:#ubuntu-release- Unapproved: u-boot (disco-proposed/main) [2018.07~rc3+dfsg1-0ubuntu2 => 2018.07~rc3+dfsg1-0ubuntu3] (core)
[11:40] -queuebot:#ubuntu-release- Unapproved: u-boot (cosmic-proposed/main) [2018.07~rc3+dfsg1-0ubuntu2~18.10.1 => 2018.07~rc3+dfsg1-0ubuntu3~18.10.1] (core)
[11:41] -queuebot:#ubuntu-release- Unapproved: u-boot (bionic-proposed/main) [2018.07~rc3+dfsg1-0ubuntu2~18.04.1 => 2018.07~rc3+dfsg1-0ubuntu3~18.04.1] (core)
[11:49] -queuebot:#ubuntu-release- Unapproved: u-boot (xenial-proposed/main) [2016.01+dfsg1-2ubuntu3 => 2016.01+dfsg1-2ubuntu4] (desktop-core, ubuntu-server)
[12:15] -queuebot:#ubuntu-release- Unapproved: accepted u-boot [source] (disco-proposed) [2018.07~rc3+dfsg1-0ubuntu3]
[12:24] -queuebot:#ubuntu-release- Unapproved: accepted u-boot [source] (cosmic-proposed) [2018.07~rc3+dfsg1-0ubuntu3~18.10.1]
[12:25] -queuebot:#ubuntu-release- Unapproved: accepted u-boot [source] (bionic-proposed) [2018.07~rc3+dfsg1-0ubuntu3~18.04.1]
[12:49] -queuebot:#ubuntu-release- Unapproved: accepted u-boot [source] (xenial-proposed) [2016.01+dfsg1-2ubuntu4]
[13:04] <ahasenack> hi release team, diaspora-installer cannot be installed in the machines used for autopkgtests because its postinst actually downloads diaspora at install time: https://pastebin.ubuntu.com/p/N9MqVKvN4Q/
[13:04] <ahasenack> hm, but why did it fail only on armhf, and not the other arches...
[13:04]  * ahasenack puzzled now
[13:05] <ahasenack> huh
[13:06] <ahasenack> armhf is on lxd, others are vms?
[13:06]  * ahasenack switches to #ubuntu-devel
[13:07] <LocutusOfBorg> ahasenack, hey!
[13:07] <LocutusOfBorg> I reported it already!
[13:07] <LocutusOfBorg> [16:32:41] <LocutusOfBorg> hello, can we please have diaspora-installer/<IP_ADDRESS>+debian1/armhf hinted? it is regressed in release (it is just a downloader), and I have reported it upstream https://github.com/codahale/bcrypt-ruby/issues/201
[13:07] <LocutusOfBorg> [16:33:05] <LocutusOfBorg> but not something we can easily fix in Ubuntu side, since gems are handled on rubygems.org website, not internally
[13:08] <ahasenack> LocutusOfBorg: oh, thx
[13:08] <ahasenack> LocutusOfBorg: but it worked in the other arches,
[13:08] <ahasenack> LocutusOfBorg: it looks like our armhf lxd just can't resolve squid.internal
[13:08] <ahasenack> the other arches can
[13:08] <ahasenack> https://pastebin.ubuntu.com/p/RVQFSwXS8F/ for a good run, same version
[13:09] <ahasenack> oh, you reported a build failure
[13:09] <ahasenack> something different
[13:24] <ahasenack> LocutusOfBorg: MP for the diaspora-installer armhf hint: https://code.launchpad.net/~ahasenack/britney/diaspora-installer-armhf-hint/+merge/368655
[13:26] <ahasenack> oh, hm, dns was just a temporary issue
[13:43] <xnox> acheronuk:  of course they are! because the fix needs to be on the nusakan.
[13:46] <acheronuk> xnox: makes sense. I'm not really too familiar with what gets pulled in on the fly in each build on that, and what needs to be already there
[13:51] <xnox> acheronuk:  it is a bit of a mess
[13:57] -queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (bionic-proposed/partner) [1:20190514.1-0ubuntu<IP_ADDRESS> => 1:20190611.1-0ubuntu<IP_ADDRESS>] (no packageset)
[13:57] -queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (disco-proposed/partner) [1:20190514.1-0ubuntu<IP_ADDRESS> => 1:20190611.1-0ubuntu<IP_ADDRESS>] (no packageset)
[13:57] -queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (cosmic-proposed/partner) [1:20190514.1-0ubuntu<IP_ADDRESS> => 1:20190611.1-0ubuntu<IP_ADDRESS>] (no packageset)
[13:57] -queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (xenial-proposed/partner) [1:20190514.1-0ubuntu<IP_ADDRESS> => 1:20190611.1-0ubuntu<IP_ADDRESS>] (no packageset)
[14:40] -queuebot:#ubuntu-release- Unapproved: debian-installer (disco-proposed/main) [20101020ubuntu570 => 20101020ubuntu570.1] (core)
[15:31] -queuebot:#ubuntu-release- Unapproved: initramfs-tools (disco-proposed/main) [0.131ubuntu19 => 0.131ubuntu19.1] (core)
[15:33] -queuebot:#ubuntu-release- Unapproved: initramfs-tools (cosmic-proposed/main) [0.131ubuntu15.2 => 0.131ubuntu15.3] (core)
[15:39] <xnox> acheronuk:  we upgraded nusakan, so tomorrow's build should be fine.
[15:39] <xnox> acheronuk:  thank you for paying attention.
[15:39] <xnox> and thank you sil2100 for fixing everything.
[15:40] <acheronuk> xnox & sil2100: thank you!
[15:50] -queuebot:#ubuntu-release- Unapproved: debian-installer (bionic-proposed/main) [20101020ubuntu543.7 => 20101020ubuntu543.8] (core)
[16:40] <blackboxsw> bdmurray: or RAOF  if there is availability today, there is a curtin SRU queued in unapproved for xenial, bionic, cosmic and disco https://bugs.launchpad.net/ubuntu/+source/curtin/+bug/1831772
[16:40] <blackboxsw> if either of you get a chance to peek at it. that'd be excellent
[16:40] -queuebot:#ubuntu-release- Unapproved: keystone (cosmic-proposed/main) [2:14.0.1-0ubuntu3 => 2:14.1.0-0ubuntu1] (openstack, ubuntu-server)
[17:50] -queuebot:#ubuntu-release- Unapproved: debian-installer (cosmic-proposed/main) [20101020ubuntu557.1 => 20101020ubuntu557.2] (core)
[17:59] -queuebot:#ubuntu-release- Unapproved: bash (bionic-proposed/main) [4.4.18-2ubuntu1.1 => 4.4.18-2ubuntu1.2~bionic1] (core)
[17:59] -queuebot:#ubuntu-release- Unapproved: bash (cosmic-proposed/main) [4.4.18-2ubuntu3 => 4.4.18-2ubuntu3.1~cosmic1] (core)
[18:53] <coreycb> hello, can an archive admin please remove python-oslo.log 3.44.0-0ubuntu2 from eoan-proposed? we have some circulary dependency issues and this is the easiest resolution.
[19:48] -queuebot:#ubuntu-release- Unapproved: systemd (bionic-proposed/main) [237-3ubuntu10.22 => 237-3ubuntu10.23] (core)
[20:59] <vorlon> coreycb: done
[20:59] <coreycb> vorlon: thanks
[22:20] <xnox> vorlon:  https://code.launchpad.net/~ahasenack/britney/diaspora-installer-armhf-hint/+merge/368655


[00:17] <Tooncenator> hello studio community. another qjackctl question. thanks to holstein, i've made much progress in learning the audio interface setup. I've run into another snag, however. My maudio box has two buses in it. Please forgive my newbie understanding of things...
[00:18] <Tooncenator> I think you would call it two buses. Of course I have both left and right inputs/outputs, but I also have an A/B switch for another set up inputs, etc...
[00:19] <Tooncenator> so my question is - I've recorded a few tracks in Ardour from my keyboard. Woohoo! Now when I play them back, it comes out of the B channel instead of the A channel.
[00:20] <Tooncenator> ...which is a problem because that means I can't play live and hear it at the same time with ardour output. anyone run into this sort of setup before? any advice?
[00:28] <Tooncenator> ...or maybe that's by design??? Because if I try to hear it while layering another track on top of it, wouldn't that also record both the playback AND the live stuff I'm playing? Hmmm....maybe this is more of a "basics" discovery process for me right now.
[01:18] <holstein> Tooncenator: i run my outs to a mixer, and route them, externally, as i pleaser
[01:18] <holstein> please*
[01:19] <holstein> i dont know what maudio hardware you have, but, it could be either only 2 channel, stereo, or, you just need to route to a different pair of outputs in JACK
[01:20] <holstein> i will get something that i know plays, such as, my studio reference tracks playing in audacious via jack, and route them to literally* all* the outputs on the right side of "connect" in qjackctl.. i will then see what outputs are what
[04:11] <Tooncenator> ok holstein. thanks. that's kinda what i was doing - just playing with all the outs. experimenting until i found the right combo. thanks again.
[04:31] <Tooncenator> holstein - any particular open source mixer you recommend?
[05:48] <Tooncenator> oh wait. you're talking about an external mixer - hardware. my little 12-channel mackie is analog only.
[06:17] <OvenWerks> Tooncenator: analog should be fine for monitor mixing, I use an old mackie 1604
[15:13] <holstein> Tooncenator: correct.. analog only
[15:14] <holstein> so, when i need to hear 2 things at once, that im not able to do with software, or with the audio hardware, i run them to 2 (or 4 for stereo sources) channels on the analog mixer, and listen to them
[19:25] <carl_> ubuntu logo derivation
[19:26] <carl_> ubuntu logo derivation
[19:36] <carl_> ubuntu logo
[19:37] <carl_> ubuntu logo history
[19:37] <carl_> ubuntu history'
[19:38] <carl_> canonical
[19:39] <Unit193> carl_: This is a support channel, do you have a support question?


[13:14] <rbasak> So I'm changing the owner of ~6000 git repositories with a small script (https://paste.ubuntu.com/p/kPRzPKr7dQ/) but iterating over the repositories using the Launchpad API, AFAICT the iterator keeps stopping for no apparent reason.
[13:14] <rbasak> It's idempotent so I'm just rerunning it to get some more done, but I wonder if I'm missing something?
[13:14] <rbasak> Down to 1000 now, so I think I can just keep rerunning it until it's done.
[13:16] <rbasak> In the first attempt I got ~3000 before it stopped IIRC. Now the stoppages seem to be getting more frequent.
[13:20] <cjwatson> Are you effectively modifying the iterator while iterating over it?
[13:20] <cjwatson> Yeah, you are
[13:21] <cjwatson> lazr.restfulclient iterates over collections in batches, each of which is a separate HTTP request
[13:21] <cjwatson> So if you change a bunch of repository owners, you're effectively changing the results of the "repositories with this owner" query while iterating over it, and you're going to get very confusing results
[13:22] <cjwatson> rbasak: For this sort of thing, I'd suggest "for repo in list(packages_imported(lp)):" to materialize the whole collection up-front before making any changes
[13:29] <rbasak> Ah. I see, thanks!
[13:34] <mijn> Hi, I've registered a git code import about an hour ago, it's still scheduled 'ASAP', usually it's been just a few minutes for import to start or sometimes even finish - is there any issue currently? anything I can do?
[13:47] <cjwatson> mijn: A URL to the code import in question is normally helpful.  The code import queue is being processed, though one of the four import workers seems to have got stuck, which perhaps isn't helping - I've asked for it to be killed so it can restart
[13:53] <mijn> cjwatson,  i've killed original import and replaced it since, but it's still under this repo: https://code.launchpad.net/openloco
[13:53] <mijn> thanks
[13:53] <cjwatson> mijn: OK, don't kill it again please
[13:54] <cjwatson> (It won't help and will only put you further back in the queue)
[13:55] <mijn> I suspect as much, still went ahead
[13:56] <cjwatson> The missing worker is back now, so the queue should process more quickly.  There are about 1.7K overdue imports at the moment, so I can't give you a very exact ETA, but maybe a couple of hours
[13:57] <mijn> :o
[13:57] <mijn> that's a lot
[13:57] <cjwatson> The queue is at least diminishing now
[13:57] <mijn> still, thanks for getting it unstuck
[13:57] <cjwatson> Most of those imports will be no-op or very small updates to existing imports, so it's not as bad as it sounds
[14:04] <mijn> is the queue public?
[14:06] <cjwatson> https://code.launchpad.net/+code-imports/+machines sort of shows it, but it only shows "pending" and not "overdue" - "pending" is nearly all imports so it's not very informative
[14:07] <cjwatson> Must get around to fixing that at some point
[14:07] <cjwatson> At the moment we rely on internal graphs
[14:16]  * cjwatson requests adding two more code import workers
[16:15] <cjwatson> mijn: I see your import ran about an hour ago, BTW
[16:16] <mijn> yup, working on overlay already, thanks!
[19:09] <mijn> hi, i'm trying to use a recipe to build a i386-only package. It works fine on Bionic, but anything newer fails to upload. Recipe in question: https://code.launchpad.net/~janisozaur/+recipe/openloco-daily-test
[19:09] <mijn> error message was: Cannot build any of the architectures requested: i386
[19:10] <mijn> but the same happened when I specified `Architecture: any`, which works with another recipe I maintain (although the working one isn't limited to i386)
[19:12] <cjwatson> mijn: Ubuntu >= 20.04 only supports i386 as a very limited partial architecture
[19:12] <mijn> I can build this easily in a docker with 20.04
[19:12] <cjwatson> mijn: Are you sure you had the same problem when you specified `Architecture: any`?  Can I see some evidence?
[19:13] <mijn> and then actually launch this docker-built binary on amd64
[19:13] <cjwatson> Why are you building on i386?
[19:13] <mijn> the project calls into a binary which is i386
[19:14] <cjwatson> Ugh.  Support for this is only going to deteriorate further
[19:14] <mijn> I know, there is progress being made towards removing this dependency - but it works for now, only not when trying to use a recipe
[19:15] <cjwatson> I can see why you want to do this in that case, but as a consequence of https://bugs.launchpad.net/launchpad/+bug/1855069 (more or less), you very probably can't
[19:15] <mijn> proof with `Architecture: any`: https://launchpad.net/~janisozaur/+archive/ubuntu/openloco-debian-test/+recipebuild/2883381
[19:16] <cjwatson> Oh I see, that's because the target PPA (https://launchpad.net/~janisozaur/+archive/ubuntu/openloco-debian-test) is configured i386-only
[19:16] <cjwatson> So basically the same deal
[19:17] <cjwatson> Until bug 1855069 is fixed I don't think you'll be able to build this on anything newer than bionic
[19:17] <cjwatson> Are the dependencies of the bionic-built binaries compatible with newer Ubuntu series?  Perhaps you can build it only on bionic and then copy it forward including the binaries?
[19:17] <mijn> I did so to not get errors about failed builds - if I enabled amd64, would it be able to get built?
[19:18] <cjwatson> It would build but I have no idea whether the build would work
[19:18] <mijn> ok, let me try
[19:18] <cjwatson> I mean, the build would be dispatched (if you enabled the arch in the PPA's config and also used "Architecture: any")
[19:21] <mijn> how do i build the deb package locally?
[19:25] <cjwatson> sbuild (some setup work required: https://wiki.ubuntu.com/SimpleSbuild)
[19:27] <mijn> oh, I think I understand now what that bug was about - there are no i386 builds scheduled at all for post-bionic
[19:27] <cjwatson> Right
[19:29] <cjwatson> We had to take some moderately brutal steps so that Ubuntu wouldn't have to implement its demotion of i386 to a partial architecture by editing several thousand source packages one by one
[19:29] <cjwatson> So there's a specific list of which sources can be built on i386
[19:29] <cjwatson> And for the most part it makes sense to apply that to PPAs as well, but this is one of the exceptions
[19:33] <mijn> ok, will have to think of some other way for getting it packaged then
[19:33] <mijn> thanks once again
[19:36] <cjwatson> Mm, and I checked, the dependencies of your bionic build aren't all directly compatible with >=focal, unfortunately
[19:36] <cjwatson> (there's been a yaml-cpp ABI change, at least)
[19:43] <mijn> yaml-cpp is a thorn in my side, I work with multiple projects using it and there's always something wrong with it
[19:45] <cjwatson> Well, it's common enough for there to be ABI changes between Ubuntu series regardless of the specifics


[04:28] <mup> Bug #1284131 changed: Feature Request: maas-cli change ownership of machine <maas-shared-lab> <uosci> <MAAS:Expired> <https://launchpad.net/bugs/1284131>
[08:26] <mup> Bug #1681477 changed: Clicking in the disk selection dropdown (for storage hardware testing parameters) in the far right doesn't open the dropdown <ui> <MAAS:Invalid> <https://launchpad.net/bugs/1681477>
[08:29] <mup> Bug #1681477 opened: Clicking in the disk selection dropdown (for storage hardware testing parameters) in the far right doesn't open the dropdown <ui> <MAAS:Invalid> <https://launchpad.net/bugs/1681477>
[08:32] <mup> Bug #1681477 changed: Clicking in the disk selection dropdown (for storage hardware testing parameters) in the far right doesn't open the dropdown <ui> <MAAS:Invalid> <https://launchpad.net/bugs/1681477>
[08:35] <mup> Bug #1681477 opened: Clicking in the disk selection dropdown (for storage hardware testing parameters) in the far right doesn't open the dropdown <ui> <MAAS:Invalid> <https://launchpad.net/bugs/1681477>
[08:38] <mup> Bug #1681477 changed: Clicking in the disk selection dropdown (for storage hardware testing parameters) in the far right doesn't open the dropdown <ui> <MAAS:Invalid> <https://launchpad.net/bugs/1681477>
[08:38] <mup> Bug #1738436 changed: [2.3,  UI] No way to disable DHCP relaying <MAAS:Fix Released> <https://launchpad.net/bugs/1738436>
[08:41] <mup> Bug #1738436 opened: [2.3,  UI] No way to disable DHCP relaying <MAAS:Fix Released> <https://launchpad.net/bugs/1738436>
[08:44] <mup> Bug #1738436 changed: [2.3,  UI] No way to disable DHCP relaying <MAAS:Fix Released> <https://launchpad.net/bugs/1738436>
[09:53] <mup> Bug #1849166 changed: Support root on software raid in UEFI mode <MAAS:Invalid> <https://launchpad.net/bugs/1849166>
[10:05] <mup> Bug #1785314 changed: maas spaces are mis-translated <track> <juju:Triaged> <MAAS:Invalid> <https://launchpad.net/bugs/1785314>
[10:08] <mup> Bug #1785314 opened: maas spaces are mis-translated <track> <juju:Triaged> <MAAS:Invalid> <https://launchpad.net/bugs/1785314>
[10:11] <mup> Bug #1785314 changed: maas spaces are mis-translated <track> <juju:Triaged> <MAAS:Invalid> <https://launchpad.net/bugs/1785314>
[16:52] <inure> how are credentials passed from the MAAS db to the rack controller when authenticating to a OOB device?
[17:54] <mup> Bug #1864686 opened: Dropdown does not go away after selection <ui> <MAAS:New> <https://launchpad.net/bugs/1864686>
[17:57] <mup> Bug #1864686 changed: Dropdown does not go away after selection <ui> <MAAS:Incomplete> <https://launchpad.net/bugs/1864686>
[18:03] <mup> Bug #1864686 opened: Dropdown does not go away after selection <ui> <MAAS:Incomplete> <https://launchpad.net/bugs/1864686>
[18:21] <mup> Bug #1864691 opened: Traceback from cloud-init during enlistment ipmitool no such file or directory <MAAS:New> <https://launchpad.net/bugs/1864691>
[19:24] <inure> roaksoax: quick question?
[20:11] <roaksoax> inure: shoot... (although I no longer work on MAAS/Canonical/Ubuntu)
[20:14] <inure> roaksoax: well that is unfortunate but if you don't  know maybe you can direct me to someone who does.    I am trying to determine how OOB credentials are passed from the MAAS DB, to the OOB device, during actions to control the OOB.   What I am looking for specifically is, is this traffic encrypted or are credentials passed from Region to Rack ove
[20:14] <inure> r plain text?
[20:21] <roaksoax> inure: is largely unencrypted. THe assumption was that you'd never put MAAS public facing, hence, region <-> rack communication is largely unencrypted. A deploying (and deployed) get data from MAAS over HTTP (so not encrypted)
[20:23] <roaksoax> what *is* encrypted, is the protocol created for rack to rack internal communication to perform neighbor discovery, but otherwide, Region <-> to rack communication, which is RPC, and machine to MAAS communication (which was PXE/HTTP) is unencrypted
[20:43] <inure> roaksoax: we were hoping to manage a PCI/SOX network with rack controller on buy region controller out.  neither public
[20:44] <inure> roaksoax: would it be officially recommend to avoid this, or would it be acceptable to wrap the RPC across SSL tunnel?
[20:54] <roaksoax> inure: you mean a VPN ?
[21:03] <inure> no.  We have core networks which have normal security, and PCI/SOX networks which have heavily locked down networks
[21:03] <inure> roaksoax:
[21:03] <inure> all are internal to the data center
[21:03] <roaksoax> inure: i dunno if that would work, we've never really tried that. But a VPN... I do believe that would work
[21:04] <inure> like a site 2 site vpn configuration?
[21:05] <inure> or just a vpn tunnel?
[21:05] <roaksoax> inure: whatever makes it transparent for the machine, it should just work for MAAS
[21:06] <inure> ok
[21:06] <inure> ty for the advice


[20:44]  * seattlegaucho wonders why 'kormoc' doesn't hang out here too
[20:45] <Salt> don't feel bad, he isn't in #gslug either
[22:38] <seattlegaucho> Salt: wanted to chat about SeaGL ... I guess email will have to do
[22:38] <seattlegaucho> ... or risk being kicked out of the channel where he hangs out


[03:21] <Kilos> morning superfly and others
[04:18] <superfly> morning Kilos
[05:27] <nuvolari> mornings oom Kilos, superfly
[05:28] <superfly> hi nuvolari
[05:28] <Kilos> lo nuvolari
[06:03] <superfly> morning maiatoday
[06:04] <maiatoday> hi superfly, how is zak?
[06:04] <superfly> seemed to be better this morning when I left
[06:05] <maiatoday> ok that's a relief
[06:07] <Kilos> hiyatoday maiatoday
[06:09] <maiatoday> hi Kilos
[06:10]  * superfly wishes he could go back to bed
[06:51] <Kilos> hi walterl
[06:56] <sakhi> moonin
[06:56] <Kilos> hi sakhi
[06:56]  * sakhi missed Kisternbosch Gardens... how was it?
[07:23] <linuxboy_> sakhi: green
[07:25] <sakhi> envy :)
[07:25] <linuxboy_> (I wasn't there)
[07:28] <corrie206> good morning all
[07:28] <Kilos> Good morning corrie206
[07:29] <Kilos> hi linuxboy_
[07:29] <Kilos> hiya confluency
[07:31] <confluency> orning
[07:58]  * inetpro happy to say that kubuntu netbook edition is also running smoothly on the Acer Aspire One A110
[07:58] <inetpro> installed last night on friends netbook
[08:16] <Kerbero> oo
[08:16] <Kerbero> good to know
[08:55] <nlsthzn> Hi all
[08:56] <Kilos> hi nlsthzn
[08:57] <nlsthzn> Kilos: Hi. Whats happening?
[08:57] <Kilos> nothing. all same as last time
[09:01] <nlsthzn> guess thats cool
[13:25] <Kilos> looks like ian whitfield has to do the chown /media/home and then copy his original /home to the second hard drive and maybe rename or something his first home right?
[13:25] <Kilos> juat checking if i got something right
[13:26] <Kilos> just
[13:26] <Kilos> i wont advice him so dont worry
[13:36] <Kilos> ah i see the answer\
[14:36] <zerlgi> Maaz coffee on
[14:36]  * Maaz washes some mugs
[14:36] <Kilos> hiya zerlgi howzit
[14:36] <Kilos> Maaz, coffee please
[14:36] <Maaz> Kilos: Okay
[14:40] <Maaz> Coffee's ready for zerlgi and Kilos!
[14:40] <Kilos> Maaz, ty
[14:40] <Maaz> You're Welcome I'm sure
[15:02] <Esquire> Howdy!
[15:07] <Kilos> hi Esquire
[15:08] <Kilos> either you guys are all working hard or busy recovering from the weekend
[15:08] <Kilos> or there are no probs today
[15:10] <Esquire> check this wacko online radio http://www.linux.fm/
[15:10] <Esquire> Howzit going Kilos ?
[15:10] <Kilos> good thanks and you
[15:13] <Esquire> I'm all well thanks
[18:15] <nlsthzn> hey again to anybody still here
[18:16] <Kilos> hi nlsthzn been kinda dead here today
[18:16] <nlsthzn> Kilos: It happens I guess... I am fluish so not been on the PC to much, can't concentrate on anything
[18:17] <Kilos> go sleep it off
[18:17] <Kilos> oh you at work?
[18:21] <nlsthzn> nope, on leave... will go sleep soon I guess... don't have the right meds which suck... must get some tomorrow
[18:22] <Kilos> get well soon
[18:23] <nlsthzn> Kilos: thx :)
[18:28] <sakhi> I'm looking for a command line back up application that can do incremental backups (besides rsync) Any ideas where I can get it? it should be as easy as aptitude install --package and work on it from there, and it should not have a heavy GUI.
[18:48] <linuxboy_> sakhi: the only one that springs to mind is backuppc
[18:48] <linuxboy_> sakhi: not sure if it fits your needs
[18:49] <sakhi> I will try it thanks, I have been trying out Mondo too.
[19:30] <nuvolari> hello
[19:30] <nuvolari> g'night
[19:30] <nuvolari> bedtime
[19:30] <nuvolari> :/
[19:30] <Kilos> night nuvolari
[19:31] <Kilos> sleep tight
[19:31] <nuvolari> thanks oom, you too :)
[19:31] <Kilos> thank you
[19:56] <Kilos> night all. sleep tight