[08:39] <Cimi> tsdgeos, morning!
[08:40] <tsdgeos> Cimi: hi
[08:41] <tsdgeos> mzanetti: do you know what happened with that merge of yours?
[08:41] <tsdgeos> was supposed to be part of a CI train and failed to land?
[08:43] <Cimi> tsdgeos, was wondering what we plan of doing today :)
[08:43] <tsdgeos> Cimi: aren't you flying?
[08:44] <tsdgeos> like "now"?
[08:44] <Cimi> tsdgeos, I'm at the airport lounge, have to kill a couple of hours, then I'll work on the plane
[08:44] <tsdgeos> Cimi: so my plan is going back to making the qmltests/autopilot tests of  lp:~aacid/unity8/new-scopes-cleanup  finally pass
[08:45] <Cimi> you need help?
[08:45] <Cimi> want to split work?
[08:45] <tsdgeos> i still don't know what needs doing :D
[08:45] <tsdgeos> Cimi: but sure
[08:45] <Cimi> ahah ok
[08:45] <tsdgeos> Cimi: get it installled and let's both run qmluitests and autopilot
[08:45] <Cimi> ok
[08:45] <tsdgeos> and let's see if we both get the same errors (that'd be a good start)
[08:46] <tsdgeos> and once we know what fails we can see how we split it
[08:46] <tsdgeos> dednick: if you have some time could you review https://code.launchpad.net/~aacid/unity8/indicator_highlight_x_position/+merge/209400 ?
[08:46] <dednick> tsdgeos: sure
[08:48] <tsdgeos> dednick: added some what to do in the description of the MR
[08:52] <dednick> tsdgeos: hm. my indicators aren't showing up at all now (even without your MP).
[08:52] <tsdgeos> dednick: :S
[08:52] <tsdgeos> dednick: phone or desktop?
[08:53] <addiks> hi, is there a official git-repository for unity which gets regular updates?
[08:53] <dednick> tsdgeos: desktop
[08:53] <tsdgeos> right i had this
[08:53] <tsdgeos> i don't remember what i was missing
[08:53] <tsdgeos> try a build -s && build -c cycle
[08:53] <tsdgeos> just to make sure
[08:55] <dednick> tsdgeos: hm. i don't need to recompile things for 5.2 do I? (eg qmenumodel)
[08:55] <tsdgeos> dednick: you do
[08:55] <tsdgeos> dednick: but there's a ppa for that :D
[08:55] <tsdgeos> so you don't
[08:55] <tsdgeos> dednick: you using the ppa?
[08:55] <dednick> tsdgeos: yep
[08:55] <tsdgeos> if so it should give you all you nee
[08:55] <tsdgeos> just dist-upgrade
[08:59] <tsdgeos> Cimi: also i think you submitted a MR for merging against new-scopes? Saviq said we should target trunk with a pre-requisite in new-scopes
[08:59] <Cimi> tsdgeos, I did
[09:00] <Cimi> tsdgeos, https://code.launchpad.net/~unity-team/unity8/carouselTool-new-dash/+merge/209746
[09:00] <tsdgeos> meh, lots of dependencies there
[09:01] <Cimi> tsdgeos, FAIL!  : tst_DirectionalDragArea::sceneYAndY()
[09:01] <Cimi> fails for me
[09:01] <tsdgeos> Cimi: make -i so you run all of them
[09:02] <Cimi> tsdgeos, do we have log of fails?
[09:02] <Cimi> tsdgeos, or shall I play with bash?
[09:02] <tsdgeos> Cimi: wait, the gnome shell doesn't have searching?
[09:02] <Cimi> tsdgeos, maybe it does, but I expect long output
[09:03] <tsdgeos> you should switch to konsole :D
[09:03] <tsdgeos> infinite output and search
[09:03] <Cimi> tsdgeos, infinite ram usage
[09:03] <tsdgeos> not really
[09:03] <tsdgeos> there's a thing called, writing to disk ;-)
[09:05] <tsdgeos> Cimi: actually use lp:~unity-team/unity8/new-scopes-cleanup instead of  lp:~aacid/unity8/new-scopes-cleanup
[09:05] <tsdgeos> seems Saviq "stole" the branch and i didn't realize
[09:09] <tsdgeos> Cimi: also do you have 5.0 or 5.2 installed?
[09:09] <tsdgeos> i think we should go with 5.0 first
[09:09] <tsdgeos> and once it's clean there
[09:09] <tsdgeos> do the 5.2 dance
[09:14] <tsdgeos> Cimi: and i just merged trunk into new-scopes into new-scopes-clean-to-trunk and into new-scopes-cleanup, so update :D
[09:23] <Mirv> tsdgeos: just in case you're not aware, the upgrade instructions have new PPA:s: https://launchpad.net/~canonical-qt5-edgers/+archive/qt5-beta2 <- beta2 itself is legacy. not much functional difference, but still, final is final.
[09:23] <Cimi> tsdgeos, http://paste.ubuntu.com/7048948/
[09:23] <Cimi> tsdgeos, ok redoing all
[09:24] <Cimi> tsdgeos, your branch is updated?
[09:24] <Cimi> nope
[09:24] <Cimi> using unity-team
[09:31] <tsdgeos> Mirv: isn't that the same ppa?
[09:31] <tsdgeos> Cimi: this is mine http://paste.ubuntu.com/7048981/
[09:32] <tsdgeos> Type Shell unavailable looks werid
[09:32] <Mirv> tsdgeos: the front page I linked to has the new instructions, since I thought people still go to that page
[09:32] <tsdgeos> ah
[09:32] <tsdgeos> Mirv: so landing.006 has everything that ppa has?
[09:32] <tsdgeos> Saviq told me it didn't have everything
[09:33] <Mirv> tsdgeos: +beta1 like it says
[09:33] <tsdgeos> man i can't read
[09:33] <tsdgeos> sorry ^_^
[09:33] <Mirv> tsdgeos: currently landing-006 now has everything except unity-scope-click and unity8, and those come from the beta1 still until I've landed those two to the landing-006
[09:33] <Mirv> no problem :)
[09:33] <Cimi> tsdgeos, I'm rebuilding the branch from scratch
[09:35] <tsdgeos> i wonder how verticaljournal broke
[09:35] <tsdgeos> the damn thing is broken in trunk too :_S?
[09:36] <tsdgeos> that is weird
[09:36] <tsdgeos> isn't it passing in CI ?
[09:37] <tsdgeos> my computer is borked, getting all kind of horizontally flashing stuff on qmlscene, let me reboot
[09:38] <dednick> tsdgeos: any idea why your panel branch failed CI?
[09:45] <tsdgeos> ahhhh, i think i know what's wrong
[09:47] <mhr3> Mirv, 5.2 landing happening today?
[09:47] <tsdgeos> someone broke compiz
[09:47] <tsdgeos> or unity7
[09:47] <tsdgeos> and that's why verticaljournaltest is not passing anymore
[09:48] <tsdgeos> who do i complain to?
[09:49] <Mirv> mhr3: it can happen, but there are two requirements. 1. promote Qt 5.0.2 image (or decide not to promote), 2. fix bug #1207270 in acceptable way (it is now fixed as of today, but has two remaining smaller issues)
[09:49] <Mirv> ok, 3. SDK team finalizes QtC plugins so I can land them, but I have no doubt about that :)
[09:49] <tsdgeos> awesome, i'm now getting a crash in /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
[09:49] <tsdgeos> \o/ not
[09:49] <Mirv> mhr3: so Monday is slightly more probable
[09:50] <Mirv> but still, if all stars align, there's nothing preventing today either
[09:50] <mhr3> Mirv, sooo.. realistically tuesday? :)
[09:50] <Cimi> tsdgeos, http://paste.ubuntu.com/7049072/
[09:50] <tsdgeos> right
[09:50] <Cimi> tsdgeos, with new branch
[09:50] <tsdgeos> that is closer to what i get
[09:51] <Cimi> tsdgeos, tell me quickly which ones shall I do on flight :)
[09:51] <Cimi> I have to leave soon
[09:51] <tsdgeos> Cimi: note that VerticalJournalTest and OrganicGridTest are because of compiz regressions and they fail in trunk too
[09:51] <Mirv> mhr3: haha :) it's really tough debate at the moment
[09:51] <tsdgeos> Cimi: run them with xvfb-run -s "-screen 0 1024x768x24" make testOrganicGrid and the failures go away
[09:52] <Cimi> tsdgeos, let me do the first ones then
[09:52] <tsdgeos> Cimi: so run them all with xvfb-run first to be sure too
[09:52] <tsdgeos> and if not move onto autopilot
[09:54] <Cimi> tsdgeos, I'll do the first ones
[09:54] <tsdgeos> ok
[09:54] <tsdgeos> Cimi: do they fail with xvfb-run too?
[09:56] <Cimi> tsdgeos, I'll do in a bit, have to leave now
[09:56] <Cimi> tsdgeos, I'll talk back in London
[09:56] <tsdgeos> Cimi: sure, run!
[10:27] <Mirv> tsdgeos: locking down unity8 for Qt 5.2 landing
[10:28] <tsdgeos> Mirv: what does that exactly mean?
[10:28] <Mirv> tsdgeos: that means I have an empty merge proposal I'll include in the CI Train, so no other silo can build unity8 but Qt 5.2
[10:28] <tsdgeos> ok
[10:28] <Mirv> nothing else really
[10:29] <Mirv> it also means that the last two packages get to the landing-006, so after that it's self-sufficient
[10:29] <tsdgeos> this unity7 regression in view sizes is really a pain
[10:30] <tsdgeos> tst_DirectionalDragArea is also failing because of it
[10:30] <tsdgeos> sil2100: do you know who do i talk about unity7 regressions?
[10:30] <tsdgeos> didrocks: or you?
[10:31] <didrocks> tsdgeos: bregma is the first contanct
[10:31] <sil2100> tsdgeos: bregma I would say
[10:31] <Mirv> tsdgeos: breg_ma is leading the U7 team, I guess file bugs and ping
[10:31] <didrocks> tsdgeos: you can as well try Trevinho
[10:31] <didrocks> 3 for bregma, 1 Trevinho :)
[10:31] <Mirv> :D
[10:31] <didrocks> counts are opened!
[10:31] <sil2100> Place your bets! ..?
[10:31] <tsdgeos> he's on the americas, no?
[10:32] <didrocks> bregma is in canada, so same timezone yeah
[10:32] <Mirv> yes
[10:32] <didrocks> Trevinho has weird working hours, so if you are lucky… (italia)
[10:35] <tsdgeos> Mirv: because you didn't do any recent patch to qt 5.0.2, right?
[10:35] <Mirv> tsdgeos: "because"? no, no recent patches to 5.0.2
[10:36] <tsdgeos> Mirv: i'm gtting a regression in widget size including decoration size, and wanted to rule out qt being the culprit
[10:36] <Mirv> tsdgeos: two latest were 0001-Do-not-overwrite-basePixmap-of-QIconLoader-PixmapEnt.patch + fix_destroy_qapp_segfault.diff
[10:37] <tsdgeos> sight
[10:37] <tsdgeos> right
[10:37] <Mirv> those landed Feb 6th
[10:42] <dednick> tsdgeos: ping
[10:42] <tsdgeos> dednick: yes?
[10:43] <dednick> tsdgeos: you know why it's failing? https://jenkins.qa.ubuntu.com/job/unity-phablet-qmluitests-trusty/1298/console
[10:43] <tsdgeos> QXcbConnection: XCB error: 148 (Unknown), sequence: 149, resource id: 0, major code: 140 (Unknown), minor code: 20
[10:43] <tsdgeos> when that happens
[10:44] <tsdgeos> you need to retrigger a build
[10:44] <tsdgeos> may be related to the bug i fixed the other day in Qt
[10:44] <tsdgeos> https://codereview.qt-project.org/#change,80007
[10:44] <tsdgeos> Mirv: did you get the email about integrating ↑ in 5.2 packages?
[10:46] <tsdgeos> dednick: so just retrigger
[10:46] <dednick> tsdgeos: yup. doing
[10:48] <dednick> tsdgeos: otherwise the branch looks fine. If that issue was just a random one, I can just approve?
[10:48] <tsdgeos> dednick: sure
[10:54] <tsdgeos> Mirv: so how is this thing going to work? because trunk still has some tests that don't pass with 5.2
[11:06] <Mirv> tsdgeos: I saw it, but haven't had time for it. trunk seems to have built fine at least
[11:06] <tsdgeos> Mirv: sure, it builds, running the tests is a differnt thing altogether :D
[11:06] <Mirv> tsdgeos: some AP is failing?
[11:07] <tsdgeos> Mirv: https://code.launchpad.net/~unity-team/unity8/fix-5.2-tests/+merge/209058 fixes some qmluitests
[11:07] <tsdgeos> i think AP were working
[11:07] <Mirv> hmmkay..
[11:07] <tsdgeos> but it was Saviq trying them
[11:07] <tsdgeos> so i may be wrong
[11:09] <Mirv> we should have new PPA AP results soon. and it's not that 100% is green immediately. but that's good to know. if the landing will be postponed to Monday, I may get to make another qtbase upload
[11:09] <Mirv> or then afterwards
[11:47] <Mirv> tsdgeos: Tuesday's tests had 1 unity8 AP failure http://q-jenkins:8080/job/autopilot-release-gatekeeper/58/#showFailuresLink
[11:47] <Mirv> after that they've unfortunately had adb problems which still seem unresolved
[11:48] <tsdgeos> www.q-jenkins.com '?
[11:50] <tsdgeos> Mirv: what ip is that?
[11:51] <Mirv> tsdgeos: <IP_ADDRESS>
[11:54] <tsdgeos> Mirv: never seen that AP test fail
[11:56] <mhr3_> Mirv, if i'm looking correctly at the landing-006 ppa, it's no longer necessary to combine it with the beta ppa, right?
[12:00] <Mirv> mhr3_: yep, just updated the instructions too
[12:00] <Mirv> mhr3_: unity8 and unity-scope-click are now there, which were the last ones (well, aside from two QtC plugins)
[12:36] <mzanetti> lol... 50% of the new scopes code is "// TODO karni". I think I know why he left the unity team again :D
[12:37] <karni> mzanetti: lol, don't be like that! :D
[12:37] <mzanetti> karni: scnr
[12:37] <mzanetti> :)
[12:37] <karni> mzanetti: 70% of my TODOs is the damn Ubuntu Palette ;P
[12:38] <mzanetti> yeah...
[12:38] <Cimi> tsdgeos, can I push?
[12:38] <tsdgeos> Cimi: what where?
[12:38] <Cimi> fixed one test
[12:38] <karni> mzanetti: I'm well aware I left a lot of TODOs, but they were not something I could do immediately. I have no idea how we should upgrade Ubuntu Palette without regressing. new version (like, 2.0) for the Phone?
[12:38] <karni> mzanetti: :)
[12:38] <Cimi> the other one, directional drag area, is yet to be fixed
[12:39] <Cimi> I understood what's wrong
[12:39] <Cimi> but I need more time
[12:39] <tsdgeos> Cimi: i fixed it
[12:39] <tsdgeos> it's compiz that is silly
[12:39] <Cimi> I'm in london btw :)
[12:39] <karni> mzanetti: plus, it's not that I left really. I'm happy to help with any pending TODO that *I* can fix :)
[12:39] <mzanetti> karni: no worries... but doing the review those TODO's hit me all over  so I had to say this :)
[12:39] <tsdgeos> Cimi: https://code.launchpad.net/~aacid/unity8/vjog_compiz_workaround/+merge/209877
[12:39] <karni> mzanetti: every single TODO has been thoroughly discussed with tsdgeos and Saviq
[12:39] <karni> mzanetti: I understand :)
[12:39] <tsdgeos> i guess i can merge it to that branch to the cleanup thing
[12:40] <karni> mzanetti: so, it's not like I left those TODO's cuz I felt like so :)
[12:40] <tsdgeos> or new-scopes actually
[12:40] <tsdgeos> Cimi: which test did you fix?
[12:40] <karni> mzanetti: if there's any conflicts when merging, I'm also happy to help
[12:41] <mzanetti> karni: I think Saviq reverted 99% of the conflicting code so there shouldn't be much of an issue
[12:41] <karni> mzanetti: at least I have the balls to sign my TODOs, compared to the whole rest of 'em ;D
[12:42] <mzanetti> karni: haha :D
[12:42] <mzanetti> true
[12:42] <karni> mzanetti: I see. In any case, I'm still available if needed :)
[12:42] <mzanetti> ack, thanks
[12:42] <karni> :)
[12:52] <Cimi> tsdgeos, genericscopeview
[12:53] <Cimi> gonna fix dda if you didn't yet
[12:53] <tsdgeos> Cimi: read up
[12:53] <tsdgeos> i did, even gave you a link :D
[12:53] <tsdgeos> Cimi: what was wrong with genericscopeview?
[12:54] <Cimi> small bug
[12:54] <Cimi> i will push in 30 mins
[12:54] <Cimi> tsdgeos, same branch?
[12:54] <tsdgeos> sure
[12:54] <tsdgeos> i'd like to see the diff since it was working here :S
[12:55] <tsdgeos> maybe it was an unstable one?
[13:28] <Cimi> tsdgeos, pushed fix
[13:29] <Cimi> tsdgeos, was due to refactor of the visuals
[13:30] <Cimi> tsdgeos, http://bazaar.launchpad.net/~unity-team/unity8/new-scopes-cleanup/revision/715
[13:32] <Cimi> tsdgeos, which unity7/compiz regression?
[13:32] <Cimi> tsdgeos, can it be the CSS window decorator?
[13:32] <Cimi> Trevinho, we have bugs with height
[13:45] <dandrader> kgunn, so, should I take over https://bugs.launchpad.net/mir/+bug/1289058 ?
[14:05] <tsdgeos> Cimi: the decoration is "eating" into the window size
[14:05] <tsdgeos> Cimi: ah cool, thanks
[14:10] <tsdgeos> Cimi: can you run autopilot ones now?
[14:10] <tsdgeos> so we sync what's failing and not
[14:30] <mzanetti> @unity: standup
[14:37] <Trevinho> Cimi: yes, I know, it's a compiz thing... And well I actually just didn't push the correct change :/, anyway once I'm out the rush I?m now, i'll fix it.
[14:41] <greyback> dandrader: just to tell you, I'm not trying to fix the OSK bug any more, just was trying to assemble a list of MRs which can unblock mir0.1.6
[14:42] <dandrader> greyback, ok, so I can have all the fun for myself now! :)
[14:42] <greyback> dandrader: if you want :)
[14:42] <greyback> dandrader: how was unity8 with qtsg going?
[14:43] <dandrader> greyback, well, the simple stage is rock solid now
[14:43] <dandrader> greyback, simple as in it supports only one app/window at a time
[14:44] <dandrader> greyback, it's all pretty smooth. but there's a lot of work ahead still
[14:44] <greyback> dandrader: okay cool
[14:44] <dandrader> greyback, I'm not minding some low level bugs though. will leave them when we meet with mir folks on the sprint
[14:45] <dandrader> so I don't get stuck
[14:45] <greyback> dandrader: what kind of bugs?
[14:45] <greyback> should we make a list
[14:45] <greyback> ?
[14:47] <dandrader> greyback, https://docs.google.com/a/canonical.com/document/d/1IiHBDIW_e0qnGt-po1D2z5HJKrNhBwh6pdILeEN2sgA/edit#heading=h.u205ol3r35vr
[14:47] <dandrader> just put my local notes into this doc
[14:49] <greyback> dandrader: the "not respond to input" issue, did you try tapping the power key? Might be powerd powering down the input hardware, but leaving the screen up
[14:49] <greyback> -up+on
[14:51] <greyback> dandrader: also the lightdm thing, are you restarting lightdm (and unity8) to fix it?
[14:53] <dandrader> greyback, no, I didn't
[14:54] <dandrader> greyback, as for lightdm, didn't play much with it.
[14:55] <dandrader> greyback, I was just focusing on getting unity8 work done so that we have something nice to show asap.
[14:55] <greyback> dandrader: sure
[14:59] <greyback> dandrader: texture provider sounds like a race, as if mir hasn't set up the gl context in time
[15:01] <greyback> the lightdm thing is weird, I don't understand why you can see the app in 1 frame. qt should be only thing drawing that surface
[15:04] <dandrader> greyback, very weird indeed
[15:07] <tsdgeos> elopio: do you know who can i bug about autopilot? i'm seeing stuff in screen that autopilot vis is not
[15:09] <tsdgeos> or anyone for that matter :D
[15:10] <greyback> tsdgeos: veebers or thomi maybe, neither about tho
[15:12] <tsdgeos> :/
[15:14] <tsdgeos> i can try doing some ad-hoc debugging
[15:14] <tsdgeos> but it ain't gonna work :D
[15:18] <elopio> tsdgeos: cgoldberg on #ubuntu-autopilot
[15:18] <elopio> veebers and thomi are already getting drunk, they live in the future and it's weekend there.
[16:57] <Cimi> tsdgeos, enjoy weekend then :)
[16:57] <Cimi> tsdgeos, chat you monday
[18:09]  * greyback eow
[18:20] <dandrader> mzanetti, still there?
[19:33] <mhall119> Trevinho: do you know where the Unity defaults are defined? And how can I make a separate set of defaults for a separate non-Ubuntu session that uses Unity?
[19:39] <Trevinho> mhall119: there are definitions in the compiz-gnome package
[19:39] <Trevinho> mhall119: for most of settings...
[19:39] <Trevinho> mhall119: for the one on ccsm you can do a new compiz profile
[19:40] <Trevinho> for the "pure" gsettings one you probably need to use migration scripts to define the ones you want based on the session type
[19:40] <Trevinho> if there are no smarter ways using gsettings (that I never looked too in the deep)
[19:41]  * Trevinho about to leave


[02:38] <duflu> RAOF: I take it an Android backend (or stub) for subpixel is coming?
[02:38] <duflu> Or not required?
[02:39] <duflu> Maybe x11 too
[03:34] <duflu> Awesome. Kernel 4.7 fixes my black screen by turning it into an equally plain orange screen
[04:40] <RAOF> duflu: Nested is up next. Android already sets it to _unknown, which might be as good as we can do?
[04:47] <duflu> RAOF: I would hope Android can do better. Will grep later. Also x11 should be able with xrandr info..?
[04:47] <RAOF> Yup. X11 should be reasonably easy.
[05:59] <duflu> RAOF: I can't find any such option for Android/HAL... Probably just as well while unity8 does client-side screen rotation, which would need work in that case
[06:00] <RAOF> unity8 could certainly make the appropriate changes.
[06:00] <RAOF> Of course, that requires the nested platform to do the right thing, which it doesn't at the moment :)
[06:00] <duflu> RAOF: I think it's mostly desktop monitors that U8 just isn't ready for
[06:01] <duflu> "low" DPI
[06:01] <RAOF> Indeed.
[06:01] <RAOF> Sub-400DPI :)
[06:01]  * duflu is reminded to investigate FRC
[06:01] <duflu> again
[06:04] <RAOF> FRC?
[06:05] <duflu> RAOF: I think it's also known as DRM_MODE_DITHERING_*  (https://en.wikipedia.org/wiki/Frame_rate_control)
[06:05] <RAOF> Oh, temporal dithering?
[06:05] <duflu> Yes
[06:05] <duflu> RAOF: I noticed recently Macbook Airs still need it
[06:05] <duflu> In 2016 just as they did in 2010 :P
[06:06] <RAOF> Seriously? I thought Apple tended to ship non-terrible hardware.
[06:06] <duflu> Yep, seriously.
[06:07] <duflu> It looks extra bad in Ubuntu like spatial dithering. I think we need to flip a switch
[06:08] <RAOF> Yay! Trade colour terribleness for 30Hz flicker!
[06:08] <duflu> Yep... and I only just convinced John Lea to stop shipping pre-dithered wallpaper
[08:04] <duflu> RAOF: What was it you said about relating surfaces to output info before? I have a plan, but don't want to conflict if you have one
[08:43] <RAOF> duflu: Pass a MirOutput* as a part of the surface-output event.
[08:43] <duflu> RAOF: That's won't work if you need to abstract it to a non-real MirOutput
[08:44] <duflu> ie. clone mode or overlapping multiple outputs
[08:44] <RAOF> ??
[08:44] <duflu> So you should probably wait for my general solution
[08:44] <duflu> Or go have dinner...
[08:45] <RAOF> True, but overlapping outputs don't make sense, and clone mode you can happily pick whichever you choose.
[08:46] <duflu> RAOF: In clone mode, two physically different arrangements should surely be generalized to disabling sub-pixel?
[08:46] <duflu> Similarly I need to proxy frame timing info
[08:47] <duflu> So it's not that we should say a surface is on output X, but the common traits of the outputs it is on are A,B and C
[08:53] <duflu> RAOF: I meant a surface "overlapping" multiple outputs. In such a case what is its subpixel arrangement, and frame interval, and physical resolution etc
[08:53] <duflu> The answer may not match any 'real' output
[08:59] <RAOF> In such a case, you pick one output.
[09:00] <RAOF> (Specifically, you pick the output with the highest scale factor ☺)
[09:02] <duflu> RAOF: Yeah I get that we can survive with that compromise. And in the single monitor case the answer is absolutely correct. I'm just trying to future-proof
[09:03] <RAOF> Surfaces should generally span multiple outputs only transiently, and you can't render them correctly anyway.
[09:03] <duflu> RAOF: I used to believe that. Till we were asked to do a monitor "wall" project
[09:04] <duflu> One surface, many monitors
[09:04] <duflu> Although in that case everything except the phase of display would match
[09:05]  * duflu now remembers what he was looking at
[10:30] <RAOF> For a video wall wouldn't you just do multiple surfaces?
[10:30] <RAOF> Or, alternatively, multiple buffer streams in a single surface.
[10:34]  * ogra_ would just make vlc work :P


[06:38] <Unit193> Just making a note that ubot2` is open to registration.
[17:41] <dholbach> can somebody help with the patch pilot bot in #ubuntu-devel? (@pilot (in|out))
[19:49] <AlanBell> anyone know what that bot is called? not sure if it is running
[20:28] <jussio1> AlanBell: its udevbot
[20:28] <AlanBell> it isn't there :(
[20:53] <tsimpson> udevbot is back once again
[20:54] <AlanBell> \o/
[20:54] <AlanBell> thanks tsimpson
[20:54] <AlanBell> tsimpson: should it be opped, or should the channel topic be open?
[20:55] <tsimpson> AlanBell: the topic isn't locked, so there's no need for the bot to be +o
[20:56] <AlanBell> oh, ok I thought it was locked a while back, I had to op the bot
[20:57] <tsimpson> they decided there a while ago they'd rather not have the topic locked, the bot is really just a useful way to easily change the topic
[20:57] <jussi> its +ZncC in there only
[23:20] <niko> !member


[21:18] <alo21> Hi in new-ish here. I read articles and guide on how to package. But where the list of prgramm to be packaged is?
[22:18] <acheronuk> Hi. kubuntu needs a kirigami2 package uploaded fairly urgently, so if anyone can help please see the following bug report
[22:18] <acheronuk> https://bugs.launchpad.net/ubuntu/+bug/1662011


[21:01] <randomuser123> I am having trouble upgrading from gnome-ubuntu 17.04 to Standard Ubuntu 17.10. Getting some errrors related to mirrors when I do "sudo apt-get update": https://paste.ubuntu.com/26418866/


[06:07] <sbeattie> bjf: Hi. I just looked at the apparmor failure log in http://kernel.ubuntu.com/testing/onibi__3.13.0-53.88__2015-05-18_17-33-00/console_output.txt.html ; it looks like it pulled in the apparmor packages in trusty-proposed, which means you shouldn't see the apparmor apport hook failure anymore (yay!), but it it looks like the trusty-proposed deb-src line wasn't enabled in apt's sources.list.
[06:09] <sbeattie> bjf: that may be the cause of the different failures seen this time, as part of the apparmor qrt test script downloads the source package and runs make check in it.
[06:11] <bjf> sbeattie, ack, i'll look at it tomorrow. thanks
[06:14] <sbeattie> bjf: no worries, thanks.
[06:22] <sbeattie> ah, yep, I've reproduced the the failures with the sources from apparmor 2.8.95~2430-0ubuntu5.1 while binary packages from 2.8.95~2430-0ubuntu5.2 are installed.
[06:41] <FourDollars> sforshee: Hi, did you remember the patch you made for Dell New XPS 13? https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/hid/hid-multitouch.c?id=2c6e0277e1eab3df5db81c59e408b7b1c14b1b72
[06:41] <FourDollars> sforshee: Does it fix any problem?
[09:16] <pkern> The new 3.13 contains "tcp: make connect() mem charging friendly" but doesn't seem to contain "tcp: Fix crash in TCP Fast Open", is that intentional?
[09:17] <pkern> I didn't check if it crashes in the same way as 3.16 did, but it's somewhat concerning that the fixup wasn't picked up if it's needed. |:
[09:21] <pkern> Yeah, it's dead on arrival for us.
[09:22] <apw> pkern, new 3.13 stable or new 3.13 in -updates in trusty ?
[09:22] <pkern> 3.13 in -updates in trusty.
[09:22] <apw> henrix, ^
[09:22] <pkern> Of course it relies on things to use fast open. Which probably just Google does? I don't know.
[09:23] <apw> yes, you are likely the only people in the world advertising that feature sadly
[09:23] <pkern> And using it in clients, I guess.
[09:23]  * henrix goes have a look
[09:24] <apw> that patch shows applied across the board (as it was a cve) but it was behind the other releases in trusty
[09:24] <apw> but i had assumed that meant the introducing commit was also not released either ... hmmm
[09:25] <henrix> ugh
[09:25] <henrix> yeah, that's correct
[09:28] <henrix> pkern: thanks for spotting that!  i'll go work on fixing that ;)
[09:28] <infinity> henrix: Hrm.  Should we do a single-commit respin to pick that up?
[09:28] <pkern> henrix: ta!
[09:29] <infinity> According to Ben's commit message, it should only affect 3.13 and 3.16.
[09:29] <infinity> And it was fixed in 3.16 already, so just 3.13.
[09:30] <apw> yeah somehow we paired it up in 3.16 and not in 3.13
[09:30] <henrix> infinity: yeah, i believe a quick respin will be needed.  i go finish the V respin and start with fixing T
[09:30] <infinity> henrix: +1 from me for a single-commit resping of T and lts-T.
[09:30] <infinity> respin, too.
[09:30] <infinity> Typing hard.
[09:31] <infinity> pkern: Since you seem to be a pro at reproduction, can I get you to test henrix's kernel when he does the deed, so we can turn it around ASAP?
[09:32] <pkern> infinity: Sure.
[09:36] <genkgo> infinity: last week you helped me out with getting cloud tools for kernel 3.19. we switched to this kernel for our problems with creating vss snapshots on our hyperv machine.
[09:37] <genkgo> infinity: unfortunately, it did not solve the issue. our vps goes read-only sometimes while creating these vss snapshots. now we have switched to a new kernel, the error is different than before.
[09:37] <infinity> genkgo: You want apw, not me.
[09:37] <genkgo> blk_update_request i/o error, dev sa, sector xxx
[09:37] <infinity> genkgo: I was just helping with the packaging mysteries, not the hyperv madness.
[09:37] <genkgo> infinity: ok :)
[09:38] <genkgo> apw: i still have some hyperv madness :)
[09:38] <apw> genkgo, ok add that info to the bug, and the new dmesg, and remind me of the bug number, and i'll see if we can get someone to reproduce it
[09:39] <pkern> henrix: Just drop me a mail at<EMAIL_ADDRESS>if you have something to test for me. I take it that a respin would likely be released earlier than next Sunday? :)
[09:40] <henrix> pkern: yeah, for sure before Sunday :)
[09:40] <henrix> pkern: i hope to have it uploaded and building later today, i'll email you once we have a test kernel
[09:41] <pkern> henrix: Thank you :)
[09:41] <genkgo> apw: i did not report a bug before, because we thought it was related to the kernel version. if i run "ubuntu-bug linux" i get "This is not an official Ubuntu package. Please remove any third party package and try again." (*** Problem in linux-image-3.19.0-17-generic)
[09:43] <infinity> pkern: If all goes well, I'd expect to release it in < 24h.
[10:23] <genkgo> apw: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1456985
[10:34] <genkgo> apw: While browsing through other bugs related to Hyper-V in the Ubuntu kernel, I found this one https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1445195. These patches will solve my problem. The reported problem here https://social.technet.microsoft.com/Forums/windowsserver/en-US/8807f61c-565e-45bc-abc4-af09abf59de2/ubuntu-14042-lts-generation-2-scsi-errors-on-vss-based-backups is an exact copy of the problem we are having.
[10:52] <infinity> genkgo: Ahh, lovely, thanks.
[10:53] <infinity> apw: Bonus points if you can get those on to all the master-nexts before the next SRU cycle happens. :)
[10:54] <genkgo> infinity: for me this also great news. i had the feeling i was on my own with this problem. now fortunately i see there are many others that have the problem. and there is already a patch it.
[10:54] <infinity> genkgo: Always nice to see that it's ultimately not our fault, too. :P
[10:55] <genkgo> hehe, i totally understand that!
[11:19] <apw> sigh, i believe we are waiting on some testing for those from microsoft, will chace that up
[11:30] <genkgo> apw: if there is any testing we can do: please let me know. i'd love to help.
[11:31] <apw> genkgo, yep, will make sure you get some test kerenls
[11:31] <genkgo> apw: wonderful, thanks for the good work
[12:08] <jsalisbury> genkgo, Should have test kernels for each release in about 15 to 20 minutes
[12:08] <genkgo> jsalisbury: wonderful!
[12:09] <genkgo> jsalisbury: should build a kernel myself then or is it apt-get install? i am not extremely familiar with building a kernel.. :)
[12:10] <jsalisbury> genkgo, I'll have the kernels as a .deb file, then you can dpkg -i them
[12:10] <genkgo> jsalisbury: aight, that would be no problem :)
[12:11] <jsalisbury> genkgo, there is already a vivid kernel here: http://kernel.ubuntu.com/~jsalisbury/lp1445195/vivid/  Building the other releases now
[12:12] <genkgo> jsalisbury: we are on trusty with vivid kernel, so i can use those already
[12:13] <genkgo> jsalisbury: i am still working on something else now, but will make sure to install today. last time it took 36 hours before we had a machine crashed on backup, and then we were creating backups every hour.
[12:13] <jsalisbury> genkgo, great.  You just need to install the linux-image and linux-image-extra .deb packages.
[12:14] <jsalisbury> genkgo, ok, thanks
[12:14] <genkgo> jsalisbury: great, thanks for the work
[12:14] <jsalisbury> genkgo, np
[12:15] <jsalisbury> genkgo, thanks for offering to test!
[12:18] <genkgo> jsalisbury: sure, we would like to get rid of the problem asap. i am going to run the tests on a production machine. on machines with not enough activity (test machine) we were not able to reproduce the bug. or we did not wait long enough (4 days, backup every hour).
[12:36] <sforshee> FourDollars: that patch gets INPUT_PROP_BUTTONPAD set for the xps 13 touchpad in i2c mode, though 015fdaa9f8edd89a456b3331088e1b77ebdad9d0 does as well
[12:45] <genkgo> jsalisbury: could you say which patches are applied to that build?
[12:47] <jsalisbury> genkgo, yes, they are the following:
[12:47] <jsalisbury> scsi: storvsc: Increase the ring buffer size
[12:47] <jsalisbury>   scsi: storvsc: Size the queue depth based on the ringbuffer size
[12:47] <jsalisbury>   scsi: storvsc: Always send on the selected outgoing channel
[12:47] <jsalisbury>   scsi: storvsc: Retrieve information about the capability of the target
[12:47] <jsalisbury>   scsi: storvsc: Fix a bug in copy_from_bounce_buffer()
[12:47] <jsalisbury>   scsi: storvsc: Don't assume that the scatterlist is not chained
[12:47] <jsalisbury>   scsi: storvsc: Set the tablesize based on the information given by the
[12:47] <genkgo> jsalisbury: thanks, how about this one: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1454758?
[12:50] <jsalisbury> genkgo, that particular commit is not in that test kernel.  It was cc'd to upstream stable and should come down through the normal stable process.
[12:51] <jsalisbury> genkgo, I can build a test kernel the that commit and the previous 7 I posted
[12:52] <genkgo> jsalisbury: i am not able to qualify whether the particular bug we are having (backups with hyperv) is related to that one, or to the storvsc onw. can you?
[12:53] <jsalisbury> genkgo, I don't believe it is related to eh backups bug, which is why it was requested in a seperate bug report
[12:54] <genkgo> jsalisbury: just to be sure: the build you created fixes a.o. the backup bug, right?
[12:54] <jsalisbury> genkgo, correct
[12:54] <genkgo> jsalisbury: lovely :)
[12:55] <jsalisbury> genkgo, I'll be building Utopic and Trusty test kernels as well, the commits are requiring a little backporting, so taking a little longer than expected.
[12:56] <genkgo> jsalisbury: ok, but i need the one you already have builded, so that is no problem
[12:56] <jsalisbury> genkgo, cool
[12:56] <genkgo> jsalisbury: at least, i do not see a reason why i should go back to 3.13 kernel
[13:08] <FourDollars> sforshee: So what's the difference between yours and the original one? I mean if there is no your commit, what's going to happen?
[13:11] <sforshee> FourDollars: basically they arrived on the list at about the same time, and they went ahead and took both. For the xps 13 the results are identical; possibly for some other touchpads one or the other might not work.
[13:13] <FourDollars> sforshee: I see
[13:13] <FourDollars> sforshee: Thanks for your explanation.
[13:13] <sforshee> FourDollars: obviously I like my approach better ;-)
[13:13] <FourDollars> sforshee: haha
[16:38] <genkgo> jsalisbury: i am having dependency problems
[16:39] <jsalisbury> genkgo, I now have test kernels for Trusty and Utopic if your willing to test?  All the test kernels are available from: http://kernel.ubuntu.com/~jsalisbury/lp1445195/
[16:39] <jsalisbury> genkgo, Can you post any errors you are seeing
[16:40] <genkgo> jsalisbury: http://paste.ubuntu.com/11247594/
[16:40] <genkgo> jsalisbury: while runing sudo dpkg -i *.deb
[16:41] <jsalisbury> genkgo, try only installing one package at a time.  First the linux-image package then the linux-image-extra package
[16:42] <genkgo> jsalisbury: no difference
[16:43] <genkgo> jsalisbury: could it be the same dependency errors that i was having before?
[16:43] <genkgo> apw: could this be the same dependency problem?
[16:44] <genkgo> jsalisbury: there is only a problem with tools and cloud tools
[16:44] <genkgo> image headers and extra are doing fine
[16:45] <jsalisbury> genkgo, you won't need linux-tools or linux-cloud for this testing, only linux-image and linux-image-extra
[16:45] <jsalisbury> genkgo, So these two .debs:
[16:45] <jsalisbury> linux-image-3.19.0-17-generic_3.19.0-17.17~lp1445195_amd64.deb
[16:46] <apw> jsalisbury, yes if you are installing a "standard" kernel, not lts-foo, then you need to switch to the default linux-tools-common things
[16:46] <jsalisbury> 	linux-image-extra-3.19.0-17-generic_3.19.0-17.17~lp1445195_amd64.deb
[16:46] <genkgo> jsalisbury: those are installed
[16:47] <jsalisbury> apw, is linux-tools needed for testing these hyper-v commits?  I didn't think so
[16:48] <genkgo> jsalisbury: microsoft is saying they are required
[16:49] <genkgo> jsalisbury: they are required, in which sense (backuping or otherwise) is unknown
[16:51] <genkgo> jsalisbury: http://paste.ubuntu.com/11247689/
[16:52] <genkgo> jsalisbury: so i still have the linux-lts-vivid-cloud-tools-common package
[16:53] <jsalisbury> genkgo, Hmm, I wonder if we need to remove that first.  Is this on a non-production system, so we can remove it first.  Then run:
[16:53] <jsalisbury> sudo apt-get install -f
[16:53] <jsalisbury> sudo apt-get clean
[16:53] <jsalisbury> sudo dpkg -i linux-tools-3.19.0-17-generic_3.19.0-17.17~lp1445195_amd64.deb
[16:55] <genkgo> jsalisbury: this is production :)
[16:56] <genkgo> jsalisbury: not working, same error: linux-tools-3.19.0-17-generic depends on linux-tools-3.19.0-17; however: linux-tools-3.19.0-17-generic depends on linux-tools-3.19.0-17; however:
[16:59] <jsalisbury> genkgo, let me see if I can install it locally
[17:00] <apw> i think you need to remove the lts-foo versions of the common tools packages, which in fixed packages wont exist
[17:00] <apw> and then you ought to get the appropriate ones installed instead, the ones that got removed last time when installing lts-vivid
[17:00] <jsalisbury> genkgo, so remove this one:  linux-lts-vivid-cloud-tools-common
[17:01] <genkgo> jsalisbury: already did
[17:01] <genkgo> no differece
[17:02] <jsalisbury> genkgo, can you run the dpkg -l command again, to see what else is there
[17:04] <genkgo> jsalisbury:
[17:04] <genkgo> jsalisbury: http://paste.ubuntu.com/11247908/
[17:06] <jsalisbury> genkgo, can you purge all of the linux-tools pacakges then reinstall just linux-tools-3.19.0-17-generic_3.19.0-17.17~lp1445195_amd64.deb
[17:06] <jsalisbury> sudo dpkg --purge PACKAGENAME
[17:07] <genkgo> jsalisbury: sorry, but same issue
[17:08] <genkgo> http://paste.ubuntu.com/11247941/
[17:08] <genkgo> you can see, all purged, won't install
[17:08] <genkgo> hmm
[17:08] <jsalisbury> genkgo, It looks like it did install, see line 586
[17:08] <jsalisbury> iU  linux-tools-3.19.0-17-generic       3.19.0-17.17~lp1445195              amd64        Linux kernel version specific tools for version 3.19.0-17
[17:09] <genkgo> no, it got errors while installing
[17:10] <jsalisbury> genkgo, same dependency error:
[17:10] <jsalisbury> ?
[17:11] <jsalisbury> genkgo, hmm, I wound if it's because I added ~lp1445195 onto the package name.  It doesn't cause issues with the kernel, but maybe the tools package doesn't like it
[17:11] <jsalisbury> genkgo, let me build one more kernel without that extra text
[17:15] <genkgo> jsalisbury: ok, i will wait for that, my system is pretty clean now: http://paste.ubuntu.com/11248013/.
[17:16] <jsalisbury> genkgo, ok, building now, it should only take 15minutes or so
[17:36] <genkgo> jsalisbury: i just got a reply from microsoft on my bug report
[17:36] <genkgo> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1456985
[17:37] <genkgo> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1456985
[17:37] <genkgo> jsalisbury: he is telling we also need https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1454758, which is not included in your build
[17:38] <jsalisbury> genkgo, Ok, I'll add it to my next build.
[17:38] <genkgo> jsalisbury: ok, thanks a lot
[17:39] <genkgo> i will wait for that before testing, thanks for the stuff you have already done
[17:41] <jsalisbury> genkgo, np
[18:30] <jsalisbury> genkgo, I have an updated kernel available at: http://kernel.ubuntu.com/~jsalisbury/lp1445195/vivid/
[18:54] <infinity> pkern: The trusty kernel with that fix should be hitting -proposed on mirrors over the next 15-30 minutes (it just hit disk on ftpmaster).
[20:14] <genkgo-> jsalisbury: still have dependency problems: Package linux-cloud-tools-3.19.0-18 is not installed.
[20:15] <genkgo-> Same for the tools package
[20:18] <jsalisbury> genkgo, I'll have to investigate further.  We may be able to just use the --ignore-depends with dpkg since this is only a test kernel.
[20:18] <genkgo-> apw: can this be related to dependency problems we had before?
[20:19] <infinity> No, it's not related to the previous issue, it's that jsalisbury builds his test kernels a bit differently from how they're built in the archive, I'd guess.
[20:19] <infinity> Oh, and it's a vivid kernel, not an lts-vivid kernel, which changes things somewhat.
[20:21] <infinity> Hrm.  That tools package is indeed useless. :P
[20:22] <infinity> Just a bunch of symlinks into the missing package that you don't have built.
[20:24] <jsalisbury> genkgo, we might get away without installing tools just to test this bug, but I'll test locally to see if I can get it to install.
[20:25] <infinity> jsalisbury: AFAIK, he needs the tools for the backup thingee to work.
[20:25] <infinity> jsalisbury: And your build didn't produce all the right packages.
[20:25] <genkgo-> infinity: that is what i believe too
[20:25] <infinity> jsalisbury: Did you just do a binary-generic build instead of a full build?
[20:26] <genkgo-> i dont know how ignore depends works
[20:26] <infinity> genkgo-: Don't bother, ignoring deps will just leave you a bunch of dangling symlinks.
[20:26] <jsalisbury> infinity, I used this:
[20:26] <infinity> No actual binaries.
[20:26] <jsalisbury> fakeroot debian/rules clean && fakeroot debian/rules binary-headers && fakeroot debian/rules binary-generic
[20:26] <jsalisbury> so thats probably it
[20:26] <infinity> jsalisbury: Yeah.  Do a full build instead.
[20:26] <infinity> jsalisbury: THen you'll get the common packages, etc.
[20:27] <jsalisbury> infinity, ack, thanks.  First time someone needed the tools package from me :-)
[20:29] <jsalisbury> infinity, do you happen to know the option for a full build off hand?  If not, I'll dig it up
[20:30] <apw> jsalisbury, to make the tools you need binary-tools as well
[20:31] <jsalisbury> apw, got it, Thanks!
[20:33] <jsalisbury> genkgo, I should have an updated tools package for you shortly
[20:35] <genkgo-> jsalisbury: aight, i will make sure to go ahead with it right away, thanks again!
[20:36] <jsalisbury> apw, doing a 'fakeroot debian/rules binary-tools' produced an error:
[20:36] <jsalisbury> dpkg-gencontrol: error: package linux-image-3.19.0-18-tools not in control info
[20:36] <jsalisbury> dh_gencontrol: dpkg-gencontrol -plinux-image-3.19.0-18-tools -ldebian/changelog -Tdebian/linux-image-3.19.0-18-tools.substvars -Pdebian/linux-image-3.19.0-18-tools returned exit code 255
[20:36] <jsalisbury> debian/rules.d/2-binary-arch.mk:407: recipe for target 'binary-tools' failed
[20:36] <jsalisbury> make: *** [binary-tools] Error 2
[20:40] <flexiondotorg> infinity, I've had a few sponsor requests turned down.
[20:40] <flexiondotorg> infinity, Please take a peek at this - https://bugs.launchpad.net/ubuntu-mate/+bug/1456591
[20:41] <flexiondotorg> infinity, I'm just wanting to know if this is standard practice?
[20:41] <flexiondotorg> infinity, https://bugs.launchpad.net/ubuntu-mate/+bug/1456597
[20:43] <flexiondotorg> sorry. Wrong channel.
[21:25] <jsalisbury> apw, ah ha.  This what is needed to build the tools: fakeroot debian/rules binary-perarch
[21:32] <jsalisbury> genkgo, There is a new tools package called linux-tools-3.19.0-18_3.19.0-18.18_amd64.deb at the URL:
[21:32] <jsalisbury> http://kernel.ubuntu.com/~jsalisbury/lp1445195/vivid/
[21:45] <garrettr> I'm working on building Ubuntu kernels w/ grsecurity
[21:46] <garrettr> The command I use to build the kernel is make-kpkg --initrd --overlay-dir=../ubuntu-package kernel_image kernel_headers
[21:46] <garrettr> Where ubuntu-package is a copy of /usr/share/ubuntu-package from an up-to-date version of Ubuntu trusty (currently running 3.13.0-53)
[21:48] <garrettr> I have seen other guides recommend download the ubuntu-trusty git repo from kernel.ubuntu.com, and replace some of the Debian control scripts from /usr/share/kernel-package with the ones in the git repo
[21:49] <garrettr> My questions are: 1. why do this? 2. why don't the control scripts in ubuntu-trusty/debian/control-scripts match those in /usr/share/kernel-package/{image,headers}?
[22:37] <bjf> sbeattie, i'm following up on the apparmor tests
[22:37] <bjf> sbeattie, i'm looking at: http://kernel.ubuntu.com/testing/dagmar__3.13.0-53.89__2015-05-20_21-43-00/ubuntu_qrt_apparmor/results/ubuntu_qrt_apparmor.test-apparmor.py/debug/ubuntu_qrt_apparmor.test-apparmor.py.DEBUG.html
[23:23] <cyking> jsalisbury, let me know when/if you have time to assist with that bug report. thanks :)
[23:26] <jsalisbury> cyking, sorry, I got side tracked today, I'll have the next kernel built shortly.
[23:27] <cyking> jsalisbury, all good! thanks.


 curious https://www.reddit.com/r/pop_os/comments/11sfmiv/looking_for_help_creating_the_pop_kde_community/
 looks like they are currently looking at the experimental ppa!
 Ooo I'll take a look
 Mostly the are talking on their discord
 Mostly they are talking on their discord
 /me is lurking
 totally unofficial thing
 Interesting.. I think S76 are driving towards their RUST based desktop. Seems like a lot of effort to go to
 Pop_OS offers some nice user features, like gaming and hardware matching. But I guess we have the same with the Focus spin..
 It's community people trying it. But a s76 dev is pitching in a bit with advice
 I'm trying to get a magazine out the door, for another hobby project of mine, but once I get done with that. I'm going to pick up on those Packaging docs Rik shared, and also have a crack at the new Flutter Subiquity installer
 kool
 Glad you're lurking Rik, keep sharing


[16:00] <rbalint> o/
[16:00] <sil2100> o/
[16:01] <rcj> o/
[16:01] <philroche> o/
[16:01]  * slangasek waves
[16:01] <Tribaal> o/
[16:01] <infinity> \o
[16:01] <cyphermox> ~o~
[16:02] <slangasek> #startmeeting
[16:02] <meetingology> Meeting started Thu Nov  9 16:02:07 2017 UTC.  The chair is slangasek. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[16:02] <meetingology> Available commands: action commands idea info link nick
[16:02] <slangasek> [TOPIC] Lightning round
[16:02] <slangasek> $ echo $(shuf -e slangasek bdmurray xnox tdaitx doko sil2100 rbalint infinity cyphermox mwhudson rcj philroche Odd_Bloke tribaal fginther)
[16:02] <slangasek> mwhudson fginther sil2100 slangasek philroche doko tdaitx bdmurray cyphermox xnox tribaal infinity rcj rbalint Odd_Bloke
[16:03] <gaughen> o/
[16:03] <slangasek> fginther:
[16:04] <slangasek> sil2100:
[16:04] <sil2100> - Fixing Bileto autopkgtest breakage
[16:04] <sil2100> - SRU help on ubuntu-advantage-tools and modemmanager
[16:04] <sil2100> - Lot's of regular SRU work
[16:04] <sil2100> - Kernel SRU reviews
[16:04] <sil2100> - +1 maintenance:
[16:04] <sil2100>   * Fixing dbus-cpp FTBFS
[16:04] <sil2100>   * Processing the removal of biometryd and folks
[16:04] <sil2100> - Diving into T-Systems additional NIC hotplugging, proposing hack
[16:04] <sil2100> - ubuntu-image:
[16:05] <sil2100>   * Some fixes in preparation for the release, testing on bionic with livecd-rootfs
[16:05] <sil2100>   * SRUing livecd-rootfs changes to stable series, blocked on those hitting -proposed
[16:05] <sil2100> - Interviewing preparations
[16:05] <sil2100> (done)
[16:05] <fginther> ugh, fail
[16:05] <fginther> * Partner image work.
[16:05] <fginther> * Testing images for lp: #1729046.
[16:05] <fginther> * Other unmentionable things
[16:05] <fginther> (done)
[16:06] <bdmurray> slangasek:
[16:06] <slangasek>  * haskell transition in bionic
[16:06] <slangasek>  * some babysitting of autopkgtest infra following the cloud redeploy
[16:06] <slangasek>  * livecd-rootfs SRU again
[16:06] <slangasek>  * discussions around automation of stable channel ubuntu-core images
[16:06] <slangasek>  * sprint loads done this week
[16:06] <slangasek>  * off tomorrow: national holiday
[16:06] <slangasek> (done)
[16:06] <slangasek> philroche:
[16:06] <philroche> * Cloud images build system vanguard
[16:06] <philroche> * Updates to cloud images build system publication tools
[16:06] <philroche> (done)
[16:06] <slangasek> doko:
[16:06] <doko> - more incoming transitions, second icu transition
[16:06] <doko> - binutils, gcc-7 update, gcc-8 updates
[16:06] <doko> - normal archive-admin work
[16:06] <doko> - trying to escalate some buildd stuff
[16:06] <doko> - waiting on autopkg testers ...
[16:06] <doko> (done)
[16:07] <slangasek> tdaitx:
[16:07] <tdaitx> [HIGHLIGHT] OpenJDK 8u151 has been released on Xenial, Zesty, and Artful with the latest security fixes. A JIT enabled VM for armhf - from the aarch32 port - has replaced the interpreted ZeroVM (zero is still available in the openjdk-8-jre-zero package).
[16:07] <tdaitx> * Check, reproduce (or try to), and look upstream for fix to a few reported OpenJDK 8 errors. (LP: #1714698, LP: #1729991, LP: #1591758, and other reports on errors.ubuntu.com)
[16:07] <tdaitx> * OpenJDK 7 security backports almost done, one final patch has required quite a few additional backports and changes.
[16:07] <tdaitx> Other:
[16:07] <tdaitx> * upgraded to Bionic
[16:07] <tdaitx> * handling IRC proxy/client issues (missing history/playback)
[16:07] <slangasek> doko: are there more transitions getting tangled right now due to autosyncs?
[16:08] <slangasek> tdaitx: done?
[16:08] <tdaitx> gah, yeah
[16:08] <tdaitx> (done)
[16:09] <bdmurray> resolved issue with update of errors code on production
[16:09] <bdmurray> submitted RTs re staging, production update of the Error Tracker
[16:09] <bdmurray> replied to email regarding Cassandra 3.10 migration
[16:09] <bdmurray> submitted MP regarding adding bionic to LP retracer config
[16:09] <slangasek> bdmurray:
[16:09] <bdmurray> updated daisy retracer configs for bionic
[16:09] <bdmurray> submitted RT re staging, production updates of daisy on the ET
[16:09] <bdmurray> updated meta-release files for artful-updates, bionic
[16:09] <bdmurray> uploaded ubuntu-release-upgrader to allow upgrades to bionic
[16:09] <bdmurray> investigation into apport-retrace failure w/ dpkg-deb
[16:09] <bdmurray> uploaded fix for rsyslog bug LP: #1673717
[16:09] <bdmurray> investigation into & discussion re LP: #1728760
[16:09] <bdmurray> discussions re release upgrade testing
[16:09] <bdmurray> submit RT re ubuntu-archive chroot access on osageorange
[16:09] <bdmurray> switched amd64 LP retracers to xenial
[16:09] <bdmurray> ✔ done
[16:09] <cyphermox> bionic:
[16:09] <cyphermox> - investigate gnome-shell crash on my system apparently due to fwupd
[16:09] <cyphermox> - merge localechooser / migrate to git
[16:09] <cyphermox> - merge partman-auto-crypto / migrate to git
[16:09] <cyphermox> - finish grub2 merge and build/boot testing
[16:09] <cyphermox> - [HIGHLIGHT] upload grub2 2.02
[16:09] <cyphermox> - prepare new shim for signing by Microsoft / pre-signing tests
[16:10] <cyphermox> - submit shim 13-0ubuntu2 for signing
[16:10] <cyphermox> netplan:
[16:10] <cyphermox> - debug nplan autopkgtests
[16:10] <cyphermox> - review ddstreet's replug blacklist addition
[16:10] <cyphermox> - [HIGHLIGHT] netplan release 0.31 & SRUs
[16:10] <cyphermox> xenial:
[16:10] <cyphermox> - verifying SRU for linux-kvm DMI (bug LP: #1724359)
[16:10] <cyphermox> zesty:
[16:10] <cyphermox> - verifying DOMAINSEARCH SRU for IPv4 DHCP settings in initramfs (bug LP: #1713747)
[16:10] <cyphermox> other stuff:
[16:10] <cyphermox> - DMB meeting & budgie packageset setup
[16:10] <cyphermox> - investigating signtool.exe behavior for shim signing
[16:10] <cyphermox> (done)
[16:10] <slangasek> no xnox today
[16:10] <slangasek> Tribaal:
[16:10] <cyphermox> keep up, ubottu
[16:10] <doko> slangasek: some universe ones, yes, but afaics, no others. the new qt packages are entangled as well
[16:10] <Tribaal> * Delivered (*minimized*) GKE image to Google \o/
[16:10] <Tribaal> * Discovered and fixed a couple of problems with our build and testing pipeline with regards to minimized images/testing on GKE
[16:10] <Tribaal> * Investigated how to consolidate our code to use python to write swift metadata (instead of python + shell), but it turned out not to be a good solution (we are looking into snapping our dependencies instead)
[16:10] <Tribaal> (Done)
[16:10] <infinity>  * finish pushing the ocaml transition through over the weekend
[16:10] <infinity>  * random FTBFS fixes
[16:10] <infinity>  * got ISO dailies building
[16:10] <infinity>  * generic AA/SRU tasks
[16:10] <infinity>  * trying to find disk space on ftpmaster to keep us going
[16:10] <infinity> (done)
[16:11] <slangasek> doko: I'm less concerned about whether it's main vs. universe than whether it's entangled and causes more things to get stuck :)
[16:11] <slangasek> rcj:
[16:11] <rcj> * Cloud image publication test for Oracle Compute Cloud with new publication tooling
[16:11] <rcj> * Cloud image publication system care and feeding after testing cloud redeploymednts
[16:11] <rcj> * Xenial cloud image base build failure fixes
[16:11] <rcj> * Cloud partner bespoke test image build/publication and debugging
[16:11] <rcj> * Assisting the vanguard to keep things running smootly
[16:11] <rcj> \,,/(^_^)\,,/
[16:11] <rcj> rbalint:
[16:12] <rbalint> * only things i can't disclose yet
[16:12] <rbalint> (done)
[16:12] <Odd_Bloke> * Off last week, playing catch up this week
[16:12] <Odd_Bloke> * Identified workaround for bionic cloud images infrastructure issue; started working on getting bionic cloud images
[16:12] <Odd_Bloke> * Out for a few days next week attending an internal meeting
[16:12] <Odd_Bloke> (done)
[16:14] <slangasek> any questions on status?
[16:15] <gaughen> no.
[16:15] <slangasek> [TOPIC] Bugs
[16:16] <slangasek> [LINK] http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-bb-incoming-bug-tasks.html#foundations-bugs
[16:19] <bdmurray> bug 1693948
[16:20] <bdmurray> so not that one
[16:20] <slangasek> https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1725861
[16:24] <cyphermox> I tend to agree that installing and upgrading should yield something that is roughly equivalent, modulo what a user has installed by themselves
[16:26] <slangasek> punting for now
[16:26] <slangasek> https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1637180
[16:26] <cyphermox> sounds like a papercut that would be really nice to fix for an LTS.
[16:26] <bdmurray> yes, lets target it
[16:27] <slangasek> agreed
[16:27] <sil2100> +1
[16:27] <slangasek> https://bugs.launchpad.net/ubuntu/+source/update-notifier/+bug/1641671
[16:29] <cyphermox> to me that's as above, an ugly wart that could be fixed easily (since there's a patch), lots of people might install ttf-* on bb
[16:29] <bdmurray> let's do take it
[16:30] <slangasek> https://bugs.launchpad.net/ubuntu/+source/shim-signed/+bug/1726803
[16:31] <slangasek> this needs doing
[16:31] <cyphermox> +10
[16:31] <slangasek> shall we go over the undecided-prio ones?
[16:32] <bdmurray> sure
[16:32] <slangasek> https://bugs.launchpad.net/apport/+bug/1208508
[16:32] <slangasek> bdmurray set the tag
[16:34] <sil2100> +0
[16:35] <slangasek> -1
[16:36] <cyphermox> +0, I'd use this, but it's not like it's an everyday thing
[16:36] <slangasek> https://bugs.launchpad.net/ubuntu/+source/whoopsie/+bug/1424768
[16:38] <bdmurray> Does network-manager keep track of on-line / off-line state now?
[16:38] <cyphermox> kinda
[16:38] <bdmurray> Would that kinda help then?
[16:38] <cyphermox> I don't know that it's the point of that bug
[16:38] <cyphermox> whoopsie already asks NM for whether online, I think?
[16:39] <slangasek> how does that relate to the reported symptom (constantly running daemon when there are no crash files to report)?
[16:39] <bdmurray> Ah, got it.
[16:39] <cyphermox> there's not much use to starting whoopsie on boot until you have something that changed in /var/carsh
[16:39] <bdmurray> So if .upload in /var/crash run whoopise?
[16:39] <slangasek> yeah
[16:40] <bdmurray> +1
[16:42] <slangasek> [TOPIC] AOB
[16:42] <slangasek> anything else for the meeting?
[16:42] <rcj> nothing
[16:42] <gaughen> no
[16:42] <sil2100> Nothing
[16:42] <gaughen> stop
[16:42] <slangasek> :)
[16:42] <Tribaal> nope
[16:42] <bdmurray> I'm out tomorrow
[16:42] <sil2100> ;p
[16:42] <slangasek> #endmeeting
[16:42] <meetingology> Meeting ended Thu Nov  9 16:42:36 2017 UTC.
[16:42] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting/2017/ubuntu-meeting.2017-11-09-16.02.moin.txt
[16:42] <cyphermox> nope
[16:42] <gaughen> I'm out tomorrow too
[16:42] <slangasek> thanks!
[16:42] <rcj> Me too and Monday


[11:21] <ginggs> hi slangasek, can we demote elkcode to proposed please? it needs a rebuild for libxc transition, but it will FTBFS (see RC debian bug #825934)
[11:22] <slangasek> ginggs: not demote; I'll remove it
[11:22] <ginggs> slangasek: thanks
[11:23] <slangasek> ginggs: (done)
[13:08] <ginggs> would someone take at why supercollider won't migrate please? http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#supercollider 'old binaries left on armhf: supercollider-supernova (from 1:3.7.0~repack-1)'
[13:11] <ginggs> and also please remove the old armhf build of singular, armhf is now dep-wait on python-polybori


[15:17] <smoser> lotia, yes, you can do that or give user-data to do it.
[15:17] <smoser> ie, something that isn't well understood / known is that cloud-config provided by userdata == cloud-init configuration files in /etc/cloud/cloud.cfg.d/
[21:10] <harmw> harlowja: I read yahoo switching to https on e-mail, probably related :)
[21:43] <harlowja> harmw i think so :-P
[21:46] <alevy> HI all, my ssh key does not seam to get imported from openstack when cloud-init runs. How would I debug this?
[21:47] <harlowja> alevy which datasource are u using with openstack?
[21:48] <harlowja> config drive?
[21:48] <harlowja> other?
[21:48] <harlowja> what version of cloud-init
[21:51] <alevy> harlowja: im not sure what data source, how do I check? 0.7.3
[21:52] <harmw> cloudinit will tell you which sources it tried
[21:52] <harlowja> do u know how the openstack u are using is setup?
[21:52] <harlowja> that will affect which datasource cloud-init should try
[21:52] <harlowja> but as harmw said, the console log of openstack should also tell u what was being tried
[21:53] <harmw> you didn't forget to pass --key mykeyname on booting the instance alevy :)
[21:53] <harlowja> and if not /var/log/cloud-init.log usually has more
[21:53] <alevy> harmw: started it from the console
[21:54] <alevy> harlowja: it is a nebula one openstack cloud
[21:54] <alevy> one image is working the other isn't...
[21:54] <harmw> nova boot --flavor bla [..] --key-name thisismykey
[21:54] <harmw> ah
[21:54] <harlowja> alevy hmmm, then it could vary, do u know what the nebular people recommend for images?
[21:54] <smoser> alevy, you can check to see if your key is there in 'ec2metadata'
[21:54] <harlowja> is that image known to work (that they are providing)
[21:54] <harmw> which image works, which one doesn't?
[21:54] <alevy> the one someone downloaded but I am trying to build my own (for certain rrsons)
[21:55] <smoser> i think nebula use ubuntu cloud images (even pull them in by default)
[21:55] <alevy> both centos 6.4 with the same cloud-init package installed and same config
[21:56] <harlowja> alevy build your own, hmmm
[21:56] <alevy> Can i run it interactively to see what is happening, I dont understand what is in the logs...
[21:56] <harlowja> alevy is it possible for u to pastebin the logs somewhere (filter out anything u don't want to show?)
[21:56] <alevy> smoser: how do I check that
[21:56] <alevy> harlowj: sure
[21:58] <smoser> alevy, in ubuntu you'd have a package 'ec2metadata'
[21:58] <smoser> just run it and it will crawl the metadata
[21:58] <smoser> from inside the system (assuming you got in, but you clearly might not bee able to)
[22:01] <alevy> smoser: bash: ec2metadata: command not found
[22:01] <alevy> smoser: centos
[22:01] <smoser> ah. well then
[22:02] <harlowja> logs at /var/log/cloud-init.log should be useful here
[22:02] <harlowja> *if any
[22:02] <smoser> $ curl -q http://<IP_ADDRESS>/latest/meta-data/public-keys; echo
[22:02] <smoser> 0=brickies
[22:03] <alevy> curl -q http://<IP_ADDRESS>/latest/meta-data/public-keys;
[22:03] <alevy> 0=alevy
[22:03] <alevy> looks ok there...
[22:07] <alevy> does cloud-init care about selinux?
[22:09] <harlowja> define 'care'?
[22:11] <smoser> it should handle it.
[22:11] <smoser> i have to run
[22:11] <smoser> later.
[22:16] <alevy> harlowja: i noticed one image has it enabled and the other doesn't, just looking for differences...
[22:17] <harlowja> kk, can u also check the diff between the cloud.cfg files @  /etc/cloud/cloud.cfg
[22:17] <harlowja> a diff there might be part of the issue
[22:18] <alevy> harlowja: nothing commented out matters right?
[22:18] <harlowja> right
[22:19] <alevy> ok they are identical then
[22:19] <harlowja> hmmm, k, thats pretty odd
[22:20] <alevy> harlowja: is there a way to run cloud-init and see if it is puking or something?
[22:20] <harlowja> ya, u can run cloud-init just via $ cloud-init
[22:20] <alevy> do indents matter?
[22:20] <alevy> i.e. "-" vs. " -"
[22:21] <harlowja> potentially
[22:21] <harlowja> yaml is white space sensitive
[22:21] <alevy> gr
[22:21] <alevy> ok i see what may be the problem then
[22:21] <harlowja> kk
[22:27] <alevy> yaml is valid and nothing changed when I re-ran cloud-init
[22:31] <harlowja> valid yaml could still mean the yaml isn't right, if the spacing is right thats usually valid, but it might still be off
[22:31] <harlowja> u should be able to run $ cloud-init single 'module-name'
[22:31] <harlowja> and then see if one is dying
[22:31] <harlowja> perhaps run just the ssh one
[22:33] <alevy> harlowja: cloud-init single --name ssh ?
[22:34] <harlowja> i think so
[22:35] <alevy> cloud-init single --name 'ssh' --frequency once
[22:35] <alevy> that did something...
[22:36] <alevy> generated public private keypair
[22:36] <alevy> how do I test the fetch of keys from openstack?
[22:37] <harlowja> so i think u should be able to run $ cloud-init init
[22:37] <harlowja> and that will rerun the fetching part
[22:37] <alevy> does not seem to
[22:38] <harlowja> any output at all?
[22:38] <alevy> just prints out the networking stuffs
[22:38] <harlowja> k, its probably noticing u already fetched the data
[22:38] <harlowja> can u check /var/lib/cloud/
[22:38] <harlowja> if u temporarily move that directory to somewhere else, it should re-run
[22:39] <harlowja> that directory is where cloud-init stores alot of its data
[22:39] <harlowja> especially under /var/lib/cloud/instance
[22:40] <alevy> ok moved it and now it prints the networking and generates the keys again but says Failed to generate ecdsa key
[22:41] <harlowja> ok, afaik rhel has issues with the ecdsa key, but the rest of the keys should be getting made,
[22:41] <harlowja> the question i guess is did it put your keys in place
[22:41] <harlowja> maybe try the cloud-init single --name ssh  again
[22:42] <alevy> it makes the ones in /etcssh/ for sure i just checked the fingerprint
[22:43] <harlowja> k
[22:43] <alevy> is the ssh module the one that fetches the key from openstack?
[22:44] <alevy> http://cloudinit.readthedocs.org/en/latest/topics/modules.html
[22:44] <alevy> that is totally empty.. ha ha
[22:45] <harlowja> hmmm, ya, thought that had some data in it
[22:45] <harlowja> the modules are @ http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/files/head:/cloudinit/config/
[22:48] <alevy> https://gist.github.com/8326025
[22:48] <alevy> that is the log btw, gist came back up
[22:48] <harlowja> ah, k
[22:50] <harlowja> hmmm, ya, its using 'iid-datasource-none' which confuses me
[22:51] <alevy> what does that mean?
[22:51] <harlowja> its supposed to find the ec2 one
[22:51] <harlowja> datasources provide where cloudinit gets info from, ec2 being one
[22:51] <harlowja> the none one is like a fallback
[22:53] <alevy> do i need to set that in cloud.cfg?
[22:53] <alevy> let me paste that too
[22:53] <alevy> https://gist.github.com/8326105
[22:54] <harlowja> u can, it might help reduce the set of ones it will try
[22:54] <harlowja> adding the following will help reduce the options
[22:54] <harlowja> # Only these datasources will be attempted (in order)
[22:54] <harlowja> datasource_list:
[22:54] <harlowja>  - ConfigDrive
[22:54] <harlowja>  - Ec2
[22:54] <harlowja>  - None
[22:54] <harlowja> or something like that
[22:55] <harlowja> u are running the '- disable-ec2-metadata' module though
[22:55] <harlowja> that alters iptables, so that means u can't probably run cloud-init twice
[22:55] <harlowja> without unblocking that iptables filter
[22:55] <harlowja> probably for testing disable that module running
[22:59] <alevy> ok i disabled that module
[22:59] <alevy> and ran again
[22:59] <alevy> still not fetching any keys
[23:00] <alevy> https://gist.github.com/8326270
[23:00] <alevy> https://gist.github.com/8326272
[23:01] <harlowja> did u make a new instance? or the same one?
[23:01] <alevy> same one. should I make a new one?
[23:02] <harlowja> ya, if that module already ran, it turned on an iptables rule that stops the metdata from being fetched
[23:02] <alevy> can i just flush iptables?
[23:03] <harlowja> probably
[23:04] <alevy> seems to still be using None
[23:05] <alevy> ok I have to run
[23:05] <alevy> i guess i just need to keep looking?
[23:06] <harlowja> ya, make sure u are removing /varl/lib/cloud each time u try to re-run
[23:06] <harlowja> i'd restrict what datasources are allowed to
[23:06] <harlowja> to avoid all these other ones being activated
[23:07] <alevy> ok


[00:19] <jerone-mobile> https://bugs.launchpad.net/bugs/487979
[00:19] <ubot4> jerone-mobile: Error: This bug is private
[00:19] <jerone-mobile> ubot4, wrong channel
[00:19] <ubot4> Factoid 'wrong channel' not found
[00:19] <jerone-mobile> ubot4, sorry about that
[00:19] <ubot4> jerone-mobile: Error: I am only a bot, please don't think I'm intelligent :)
[01:39] <Ramiz> hello
[01:39] <Ramiz> any one know ETM 3.2?
[01:45] <Ramiz> any one know ETM 3.2?
[01:50] <Ramiz> hi
[01:54] <Ramiz> hi
[01:54] <Ramiz> any one know ETM 3.2?
[01:55] <Ramiz> any one know ETM 3.2?
[01:57] <Ramiz> any one know ETM 3.2?
[02:00] <ojn> Ramiz: Repeating your question over and over will not give you a quicker answer
[02:00] <Ramiz> no i am so sorry
[02:01] <Ramiz> i repeted cuz i did not sure if it sent or not cuz i am not login
[02:01] <Ramiz> sorry
[02:01] <Ramiz> i am wating
[02:01] <ojn> ah. What's ETM anyway?
[02:01] <Ramiz> Embedded Trace Macrocell
[02:08] <ojn> ok, figured it was but was but wanted to make sure. I'm guessing most people here aren't working with tools that low level
[02:08] <ojn> you might be better off asking in a group related to the specific SoC you're trying to debug
[02:09] <Ramiz> where i can find this on irc u think?
[02:13] <ojn> depends. what chip are you working on?
[02:13] <Ramiz> it is arm11 cutome one
[02:13] <Ramiz> it is like omap
[02:14] <ojn> custom? so your own soc?
[02:14] <Ramiz> it is not mine
[11:32] <lool> ogra, asac: I see https://blueprints.launchpad.net/ubuntu/+spec/mobile-lucid-multiarch-execution-environment just got a work item: research possibility of integrating the build-arm-chroot script
[11:32] <lool> functionallity directly into debootstrap (2 days): TODO
[11:32] <lool> Isn't that what I just did?
[11:34] <ogra> lool, well, sending that patch to colin, getting it approved upstream etc ... see the spec now, we postponed it
[11:35] <lool> Is it research or is it implementation then?
[11:35] <ogra> if we keep binfmt as well as the build-arm-chroot script for now the world wont end
[11:35] <ogra> well, actually both, i could have formulated it better
[11:36] <lool> This work item doesn't mention the static versus shared bit
[11:36] <asac> the work items are kind of void as we pushed it back for lucid
[11:36] <ogra> lets just keep it as is... if one gets to create the code beyond a proof of concept it gets implemented ... i consider it nice to have
[11:36] <asac> if you want to fill stuff in in the spec go ahead
[11:36] <ogra> s/it gets implemented/and it gets implemented/
[11:36] <lool> I've put down my research; did you guys check it out?
[11:37] <lool> I was surprized not to hear back from any of you two
[11:37] <ogra> i read it, yes
[11:37] <asac> ogra: right. thats what "Low" means. if someone gets to it fine. otherwise no problem
[11:37] <lool> s/put/written
[11:38] <asac> lool: will read it later today. needed to work full-time on spec stuff esterday ;)
[11:39] <ogra> lool, if you feel like implementing what you found, feel free (i'm not really happy with the idea to fiddle with binfmt on the fly, but as long as it doesnt stop working i dont care)
[11:39] <lool> What would really rock is doing it with multiarch, but it's not clear it will happen this cycle
[11:39] <ogra> right
[11:39] <lool> ogra: Well I'm not happy with relying on the host setup instead   :-)
[11:39] <ogra> until then i'm happy to keep it as is
[11:39] <ogra> right, i know
[11:40] <lool> Frankly where the binfmt stuff happens is just a technical detail; I hate the requirement that the chroot pathname needs to match the host pathname though
[11:40] <ogra> as i said, as long as the functionallity persists i dont really care, if you have spare cycles to implement it your way, feel free
[11:40] <lool> Moving binfmt to this script is the only thing I didn't research -- as noted -- I dont know whether it's container friendly
[11:41] <lool> It's probably though to do it in the chroot without a special helper: you can't run anything in the chroot without the wrapper and you need to setup the wrapper from withing the chroot for the container stuff to work  :-/
[11:41] <ogra> i think the container stuff happens at another level ... i wouldnt see why it shouldnt work
[11:42] <ogra> the kernels binfmt module just reacts on the magic number ... i dont think it cares if that happens in a container or not
[11:43] <ogra> as long as the wrapper is found at least
[11:43]  * suihkulokki has a way to execute arm binaries in a chroot using a dynamically linked qemu-arm without binfmt_misc
[11:43] <lool> suihkulokki: I can do that for a single binary as well, but not one that forks
[11:44] <suihkulokki> including forks
[11:44] <lool> suihkulokki: Oh scratchbox2?
[11:44] <ogra> lool, anyway, if you find a way thats as easy as buiold-arm-chroot for the user, feel free to go ahead and implement it
[11:44] <suihkulokki> well, sb2 can do that too
[11:44] <lool> suihkulokki: Would love to hear your way then
[11:44] <suihkulokki> my way is just much more lightweight
[11:44] <lool> suihkulokki: I've documented what I tried in https://wiki.ubuntu.com/Specs/Mobile/QemuStaticExecutionEnv/Research
[11:44] <ogra> what i dont want is that the user needs to type in a chain of commands and options to create a chroot
[11:45] <lool> ogra: That can always be reduced to a script    :-)
[11:45] <ogra> as i said, feel free :)
[11:45] <lool> ogra: My worries with the proposals I heard at UDS were: specific to Ubuntu, package proliferation
[11:45] <ogra> i will only put time into it if i actually have a lazy day before FF ...
[11:45] <ogra> which is unlikely
[11:45] <suihkulokki> I hope to show my way next weekend latest
[11:46] <lool> suihkulokki: Well you said too much now; mind sharing the high-level idea?
[11:46] <lool> suihkulokki: Did you patch qemu to spawn itself on forks?
[11:46] <lool> or exec rather
[11:48] <suihkulokki> basicly a LD_PRELOAD a library that executes qemu on exec if the binary to be executed is not host arch
[11:48] <lool> Ok; I thought of something similar by patching qemu's syscall emulation of the exec() syscall
[11:49] <lool> Your approach is probably more self-contained and might also allow calling into a host binary more easily
[11:49] <lool> Hmm not sure actually
[11:50] <lool> LD_PRELOAD has to be inherited by all childs; it fails with env -i and the new childs will look for the preload data in the chroot
[11:50] <lool> But still more self contained
[11:50] <Stskeeps>  ld.so.preload maybe?
[11:50] <dpb> and will fail for static binaries..
[11:51] <suihkulokki> dpb, look, the ld_preload only affects qemu, not the binaries running inside qemu so it doesn't matter if the muck the env or are static
[11:52] <suihkulokki> s/look/lool/
[11:54] <lool> suihkulokki: Oh so it's a ld_preload trick to change qemu's behavior for exec(); ok that's exactly what I thought of except I envisionned that in the qemu code itself
[11:54] <lool> That would work very well I think; good idea
[11:59] <suihkulokki> lool: yeah. if some hardcoding is acceptable it would be easy to do the same modifying qemu's exec
[12:00] <lool> suihkulokki: Is hardcoding really necessary?  can't qemu-arm exec() into itself with enough info to proceed to the target binary?
[12:00] <dpb> suihkulokki: ah, right. I'm tired. :)
[12:00] <lool> (I didn't look at the qemu syscall emulation itself at all, so feel free to call that impossible or very hard!)
[12:20] <lool> asac: glib > we want to get rid of swp uses for v7 in any case, a short term stop gap would be to change the build flags of glib to build in arm mode; that would at least avoid failing a gazillion of builds, images etc.
[12:21] <asac> lool: right. we dont want arm mode ... unles we cant find a patch quickly ;)
[12:21] <lool> Well I'm only suggesting that as a stopgap
[12:22] <lool> glib impacts a lot of packages
[12:22] <lool> Of course we want thumb2
[12:22] <ogra> lool, do you know swp will fail with -Wa,-mimplicit-it=thumb ?
[12:22] <asac> lool: right. i just hope we can have a patch really quick ;)
[12:22] <asac> (this afternoon)
[12:22] <lool> I think it's not available in t2 mode
[12:22] <asac> otherwise i agree we hsould upload with -marm
[12:22] <ogra> hrm
[12:23] <lool> Which would seem logical since v7 introduced thumb2 AND new stuff to get rid of swp
[12:24] <asac> http://paste.ubuntu.com/333081/
[12:24] <asac> thats the code
[12:26] <lool> SWP instruction
[12:26] <lool> is not supported in Thumb2 mode at all
[12:26] <asac> i know
[12:26] <lool> As confirmed from the Slide 5 notes in https://wiki.ubuntu.com/Mobile/ARMv7AndThumb
[12:26] <asac> ;)
[12:26] <lool> You were asking whether implicit-it=arm would help, it will not
[12:26] <lool> I just double checked
[12:27] <asac> its also here: https://wiki.ubuntu.com/ARM/Thumb2
[12:27] <asac> lool: right. thats what i suspected
[12:27] <lool> or here https://wiki.ubuntu.com/Mobile/ARMv7AndThumb
[12:27] <lool> Well since ogra was about to fire a build with implicit-it=, I figured it was worth mentionning that it wouldn't help
[12:27] <lool> Anyway, /me hops to pressing stuff
[12:28] <ogra> well, i'm still writing on a spec
[12:28] <asac>   __sync_val_compare_and_swap
[12:28] <ogra> i wouldnt have fired it off right away :)
[12:47] <asac> is there a good resource to track armel build failures?
[13:08] <lool> ubuntuwire
[13:08] <lool> http://qa.ubuntuwire.com/ftbfs/
[13:28] <asac> th
[13:28] <asac> x
[16:40] <lool> that's the failing qt4-x11 code http://paste.ubuntu.com/333247/
[16:40] <lool> The #else
[16:41] <ogra> ../../corelib/io/qfsfileengine_unix.cpp:1309: error: unrecognizable insn:
[16:41] <ogra> (insn 636 635 218 23 ../../corelib/io/qfsfileengine_unix.cpp:1286 (set (reg:SI 9 r9 [+4 ])
[16:41] <ogra> set reg sounds like assembler to me, surely not like C++
[17:29] <ojn> Hm, what's the reason for using softfp? I thought all supported platforms today had proper implementations?
[17:29] <ojn> oh, nevermind. that's just the abi
[17:35] <fta> asac, do you need -Wa,-mimplicit-it=thumb or is -mthumb good enough?
[17:43] <ogra> fta, https://wiki.ubuntu.com/ARM/Thumb2
[17:43] <ogra> i dont think -mthumb is enough
[17:44] <fta> i get /tmp/ccRUIN1V.s:131: Error: thumb conditional instruction should be in IT block -- `moveq ip,#8'
[17:44] <fta> but as it happens after 19h+ of build, i prefer to ask ;)
[17:45] <fta> i should probably setup a crosscompile env
[17:48] <ogra> no, that gets painful
[17:48] <ogra> since you need to cross build all the deps first
[17:49] <ogra> crossbuilding is fine for packages with only a few deps ... i wouldnt build something with lots of deps in a cross way
[18:27] <fta> ogra, upstream provides this recipe: http://code.google.com/p/chromium/wiki/LinuxChromiumArm
[18:27] <fta> looks possible but could be easier :P
[18:31] <ogra> well, as long as you are sure the cross toolchain they provide uses the same options, that might work
[18:32] <zumbi> ogra: our cross toolchain is not sysrooted
[18:34] <ogra> zumbi, well, does it default to the options documented on https://wiki.ubuntu.com/ARM/Thumb2 ?
[18:34] <zumbi> ogra, no, i do not think so
[18:34] <ogra> right, thats what i suspected
[18:35] <ogra> so it doesnt help much unless you hack around it in debian/rules since fta wants to fix build errors happening on the buildds
[18:36] <zumbi> btw, which cross tool do you use? lool PPA?
[18:36] <ogra> none
[18:36]  * ogra is highly anti cross :) i build on real HW
[18:37] <zumbi> ogra: do you native build kernels for new bootstraps?
[18:37] <ogra> for small packages i use the ubuntu qemu-arm-static package
[18:38] <ogra> oh, for test kernels i sometimes use codesourcery ...
[18:38] <zumbi> yes, qemu is nice and helpful, also cross building
[18:38] <ogra> but most of the time i simply use my dove board :)
[18:39] <zumbi> which is fine and if you have the time and the power, it is best practice :-)
[18:39] <ogra> but cross building does only cut down buildtime in half or so ... and i usually dont touch kernels
[18:39] <zumbi> ogra: you can not native build a uclibc based device (no space)
[18:40] <ogra> we dont use uclibc in our ubuntu images
[18:40] <ogra> all devices we support have at least 800MHz and 512MB
[18:40] <ogra> and usually a SATA port
[18:40] <armin76> ricer board
[18:40] <zumbi> yes, in those cases, cross building is not needed
[18:41] <zumbi> but, i can not native build on my lynksys
[18:41] <ogra> armin76, still envious, eh ?
[18:41] <ogra> zumbi, well, i did native builds on my nslu2 ... but i agree its no fun
[18:41] <ogra> armin76, just wait for the next gen sheeva plug :)
[18:42] <armin76> boo
[18:42] <armin76> ogra: why do i have to wait?!
[18:42] <ogra> it will be dove based
[18:42] <ogra> at least thats what roumours said :)
[18:42] <zumbi> armin76: still you have not got an armv7?
[18:43] <armin76> zumbi: nope
[18:43] <armin76> zumbi: ogra doesn't wanna share *g*
[18:43] <zumbi> armin76: get a beagleboard :)
[18:44] <ogra> or if you are rich, get a babbage board
[18:45] <zumbi> ogra: cross building is needed when you have to maintain a distro which runs on 4MB devices up to several GB
[18:45] <ogra> indeed
[18:45] <ogra> luckily ubuntu went beyond that :)
[18:45] <zumbi> also uclibc would enter in thecocktail
[18:45] <Stskeeps> zumbi: or compiling qt and not waste several days on it :P
[18:46] <zumbi> qt-embedded ?
[18:46] <armin76> ogra: i could get your babbage *g*
[18:46] <ogra> Stskeeps, https://launchpad.net/ubuntu/+source/qt4-x11/4.5.3really4.5.2-0ubuntu1/+build/1292073 22h :) not even a day
[18:48] <ogra> armin76, sure, i could sell it to you :) it being used i would even go down with the price by $50 ... so it would only be $700 :P
[18:48] <ogra> afaik freescale sells them now
[18:52] <ojn> genesi are shipping their pegatron smarttop rebranded device too (with u-boot as firmware)
[18:53] <ogra> right, but you could only use ubuntu userspace with it
[18:53] <ogra> there is no pegatron kernel
[18:53] <ogra> and its stuck on 2.6.28 ...
[18:53] <ojn> yeah i know. nice gpl compliance there.
[18:53] <ogra> heh
[18:54] <ogra> lucid will use uboot on the babbage too ...
[18:56]  * ogra calls it a day
[18:56] <ojn> yikes, 800 bucks from arrow
[18:56]  * zumbi wonders if any of you know mpc8548 ppc processors
[18:57] <ojn> zumbi: plenty of people on #mklinux do
[19:00] <zumbi> ojn: yes, i just went there
[21:14] <fta> ogra, i'm confused by the "-Wa,-mimplicit-it=thumb is not implemented as of gcc-4.4 4.4.2-3ubuntu1".. does it mean that passing it is useless as won't work, or that it's just not yet the default?
[21:14] <fta> +it


[18:58] <koko_> hi evry body
[18:59] <koko_> have a MacPPC G5 2x processors and want to install Unbuntu
[18:59] <koko_> need last distrocompatible with this baby
[18:59] <koko_> plsd help
[19:03] <koko_> Hi live chat
[19:03] <koko_> i am new to this
[19:04] <koko_> have a old Mac G5 2x cpu x 2Ghz   2 G RAM
[19:04] <koko_> and want to install Ubuntu
[19:05] <koko_> need last compatible distro to instal on this baby
[19:05] <koko_> someone could help ?
[19:05] <koko_> tring sonme distro but canot boot
[19:06] <koko_> pls help


[11:20] <silly> https://www.youtube.com/watch?v=14giLbM4rhk
[11:20] <datase> ^  ► YouTube :: Google maps on the Commodore 64 - Even street view! The WiC64 revisited - What's new ?


[00:29] <n-iCe> well
[00:29] <n-iCe> gonna try other distro
[00:29] <n-iCe> to check if that's the issue
[00:29] <n-iCe> since can't find the driver or codec I need
[00:37] <n-iCe> ok
[00:44] <n-iCe-> Lets see
[00:44] <n-iCe-> Installibg manajaro
[02:22] <EleanorEllis> How can I change the default GUI text editor to gedit instead of mousepad in xfce?
[05:09] <xubuntu16i> join
[10:15] <Bischoop> Elo
[10:16] <Bischoop> Guys I just went back to Xfce - love it :-)
[10:16] <Bischoop> I just need now change language input options, where to look for it?
[10:17] <diogenes_> Bischoop, ty tu robisz?
[10:18] <diogenes_> settings - keyboard - layout
[13:04] <Bischoop> Well I'll need use few language inputs, should I go with XKB?


[00:07] <jwi> ogasawara: around?
[00:07] <AddJim> Will supply massive beer supply to whoever fixes this ticket. Should be pretty easy as there's already work done on it for another package https://bugs.launchpad.net/ubuntu/+source/linux/+bug/824304
[00:07] <ubot2`> Ubuntu bug 824304 in linux "Divide by zero in find_busiest_group/update_sg_lb_stats (on physical hardware)" [Undecided,Confirmed]
[08:18] <adrenalink> I'm going to write kernel modules. What are the issues I'll encounter if I make a mistake in coding a module? a total corruption of my system?
[09:19] <sharat> i am interested in contributing to ubuntu, how should i get started with understanding the kernel source code?
[13:35]  * ogasawara back in 20
[14:54] <bdmurray> ogasawara: when do you want kerneloops turned off?
[14:55] <ogasawara> bdmurray: hrm, good question.  maybe around beta-2 ish?
[14:55] <ogasawara> bdmurray: I'm trying to remember when we usually turn it off
[14:56] <bdmurray> 14 Apr 2011
[14:56] <bdmurray> 28 Sep 2010
[14:56] <bdmurray> 19 Apr 2010
[14:57] <ogasawara> bdmurray: cool, so beta-2 sounds about right then
[14:58] <bdmurray> ogasawara: roger
[17:57] <kristian-aalborg> hi all
[17:58] <kristian-aalborg> does jjohansen still come around here?
[17:59] <ogasawara> kristian-aalborg: he does, but he's away at linux plumbers conference this week so not likely as available as usual
[17:59] <ogasawara> kristian-aalborg: probably best to reach him next week if possible
[18:00] <kristian-aalborg> ok
[19:53]  * ogasawara lunch
[20:07]  * GrueMaster enters the lion's den.


[08:10] <RikMills> tjaalton: is a libdrm merge/sync due to happen for kinetic?
[08:11] <RikMills> next KDE plasma version may need 2.4.112
[08:11] <tjaalton> RikMills: already done
[08:11] <tjaalton> last week
[08:12] <tjaalton> huh, didn't upload it
[08:12] <RikMills> yeah, kinetic is at 2.4.110
[08:12] <Unit193> tjaalton: Sorry to ping you twice, but did you happen to see my other ping on the other network?
[08:12] <tjaalton> Unit193: yes, but it was late saturday or such
[08:13] <Unit193> Sure, not time sensitive, just hoped you didn't miss it or something. :)
[08:13] <tjaalton> RikMills: oh now I remember, lp didn't accept uploads at the time
[08:13] <RikMills> aha
[08:15] <RikMills> as long as it is on the way, that is grand :)
[08:15] <tjaalton> uploaded now
[08:15] <RikMills> ty :D
[08:16] <tjaalton> Unit193: so, as they were available before and no-one complained about patents, I guess they can be enabled...
[08:17] <Unit193> tjaalton: Thanks!
[08:18] <Unit193> I was hoping for such an outcome, wasn't really sure how it was going to turn out though.
[11:32] <luis220413> What architectures are supported by each Ubuntu desktop flavor?
[11:37] <tarzeau> luis220413: 22.04: amd64 arm64 armhf ppc64el s390x
[11:37] <tarzeau> same for kinetic, 21.10, 20.04, 18.04
[11:39] <luis220413> tarzeau: Thanks!
[11:43] <ogra> ... and soon riscv ... 🙂
[11:53] <jbicha> tarzeau: only amd64 & arm64 are supported for desktop. There aren't installers for the other architectures. Packages are generally built for other architectures but people are on their own then
[11:54] <jbicha> The ubuntu-desktop metapackage is currently built for "amd64 arm64 armhf ppc64el" in part because test and build issues were common on s390x for gjs and gnome-shell
[12:00] <tarzeau> jbicha: oh thanks for correcting me, didn't know (don't have anything else than amd64 and arm64)
[12:01] <tarzeau> ogra: do you have any riscv hardware? which one & cost of it?
[12:03] <ogra> tarzeau, i have a visionfive board ... cost was around 130€ ...
[12:03] <ogra> https://shop.allnetchina.cn/products/starfive-visionfive-ai-single-board-computer
[12:04] <ogra> seems the price rised ? weird ...
[12:04] <tarzeau> ogra: could you run https://github.com/alexmyczko/autoexec.bat/blob/master/benchmark and post output?
[12:04] <tarzeau> how many cores/memory?
[12:04] <ogra> note that it does not have a GPU, so not useful for desktop stuff
[12:04] <tarzeau> i don't mind no GPU. as long as it has video output, and keyboard/mouse input
[12:05] <tarzeau> and fast i/o + memory. no active cooling needed?
[12:05] <ogra> it is dualcore 1GHz, 8GB RAM
[12:05] <ogra> it comes with a fan, have not tried runing it without yet
[12:06] <tarzeau> nice, raspberry pies have more cpu power and similar ram, but sd card goes brrr everytime i want to use it, and it's so slow, it's pointless (ok if you don't need to read/write data)
[12:06] <ogra> I/O and memory are fine, CPU speed is noticeable slow (like with all current RISC boards i think)
[12:07] <tarzeau> what's also a pity is, 1 gbit only :( 2.5, 5, 10gbit would be such a killer these days
[12:08] <ogra> well, i actually use wifi only with it ....
[12:08] <tarzeau> ogra: if you get a chance to run my benchmark, i'm only interested in the memory+cpu outputs
[12:08] <tarzeau> what do you use yours for? (sorry this is getting offtopic)
[12:09] <ogra> i'll try ... though my board currently runs Ubuntu Core exclusively ... (would need a snap of yor benchmark first, r i can run it in lxd but then there is potentially some overhead from the container)
[12:09] <tarzeau> i don't mind, run it as you wish, might want to read it first, and comment out the parts about network+disk
[12:41] <luis220413> How can I force the expiry of a bug?
[12:41] <luis220413> How can I force the expiry of an incomplete bug?
[12:42] <ogra> incomlete auto-expires after 60 days
[12:42] <ogra> +p
[12:42] <ogra> there is nothign you need to do
[12:42] <luis220413> ogra: But there is a bug task for a project without bug tracking configured that is apparently blocking the expiration.
[12:43] <luis220413> This bug has not expired in 7 years.
[12:43] <ogra> close it as invalid ?
[12:43] <ogra> (that particular task)
[12:43] <luis220413> ogra: Done
[12:53] <rbasak> Different projects in LP have different bug expiration settings. It's a boolean - a project may choose not to expire inactive Incomplete bug tasks.
[13:25] <Eickmeyer[m]> luis220413: #launchpad is for asking for help with launchpad itself. Don't go in there asking for changes to individual bugs please.
[13:38] <luis220413> Eickmeyer[m]: Yes, but this is an operational issue with Launchpad (a bug watch is not updating).
[13:38] <Eickmeyer> luis220413: That takes time.
[13:38] <luis220413> Eickmeyer: But the change was done almost 2 years ago.
[13:40] <Eickmeyer> luis220413: But going in there and telling someone to do something is not the way. Maybe you should ask them why it's not doing the thing it's supposed to do so they can investigate a possible bug?
[13:41] <luis220413> Eickmeyer: OK
[13:41] <Eickmeyer> luis220413: People don't like to take orders, and you tend to try to give orders around here a lot, and we're not taking kindly to that.
[13:42] <luis220413> Eickmeyer: I will stop giving orders now.
[13:42] <Eickmeyer> luis220413: Thank you.
[13:53] <schopin> The package pktanon is stuck in -proposed because it doesn't have an armhf binary, but the -proposed version explicitly removed that arch. What'd be the correct way to solve this?
[13:55] <dbungert> schopin: as I hear it, you should request a_rchive remove the existing armhf binary.
[13:57] <schopin> dbungert: makes sense, thanks
[15:12] <bdmurray> Bug expiry is a little more complicated than just being Incomplete - https://help.launchpad.net/BugExpiry
[18:33] <arraybolt3[m]> This might be a silly question, but Ubuntu Kylin is still considered to be an official Ubuntu flavor, right? It's not listed on https://ubuntu.com/desktop/flavours.
[18:59] <icey[m]> hey coreycb - by chance, do you know how CMAKE_INSTALL_LIBDIR gets set in package builds (specifically: Ceph)?
[19:05] <krytarik> arraybolt3[m]: https://github.com/canonical/ubuntu.com/pull/11852 - I'm seeing this, but unfortunately the referenced issue (along with the whole "commercial-squad" project it is on) is set to private, so we can't tell from that what really the rationale is.. :3
[19:07] <sarnold> wow, when yo'ure accustomed to the launchpad big bright red banner that takes half a second extra to render into place, it's *super* easy to overlook the very small unobtrusive "private" marker
[19:12] <coreycb> icey[m]: it looks to be expansion of _libdir by cmake which it may get from ceph.spec.
[19:20] <icey[m]> ah, good spot, thanks :)
[19:20] <arraybolt3[m]> krytarik: Weird. We still treat it like an official flavor AFAIK, I wonder why they did that.
[19:21] <arraybolt3[m]> I asked because of a comment I noticed on Ask Ubuntu stating that Kylin used to be an official flavor, and I was like, "Used to be? Still is, right?"
[19:23] <arraybolt3[m]> And this was only 30 days ago.
[19:23] <krytarik> Yeah, if it wasn't anymore, that'd be totally new to me too - only their website is slightly inaccesible recently..
[19:25] <arraybolt3[m]> krytarik: The release team probably knows - do you think it's worth asking them or would that just be needless noise?
[19:26] <icey[m]> coreycb: any idea where _libdir is created?
[19:26] <icey[m]> the only reference I see creating it is buried in the jerasure part of the source
[19:27] <coreycb> icey[m]: I think cmake may be generating that
[19:27] <coreycb> well, expanding it
[19:27] <krytarik> arraybolt3[m]: Well, I definitely think this needs clarification, because I slightly feel like the community is being left out here.
[19:33] <arraybolt3[m]> krytarik: OK, I'll ask.
[20:31] <ItzSwirlz> hai, is feature freeze (the 25th) the last day we sync from debian unstable or is the actual last sync a earlier? Cinnamon packages have had patches and fixes that have been pushed to unstable and less requestsyncs would be nice :)
[20:39] <Fallen> Quick note on the above, community team is investigating the Kylin issue. We hope to get this resolved quickly, it was a surprise for some folks internally as well but I'm in touch with the right people now and will find out what happened.
[20:49] <jbicha> ItzSwirlz: yes, the autosync is turned off then, at "Debian Import Freeze" on the schedule
[20:50] <jbicha> last year, Debian Import Freeze was on an earlier day than Feature Freeze but that was a unique situation
[20:50] <ItzSwirlz> Thanks
[21:44] <Fallen> Hey folks, I've been able to get to the bottom of the situation. First off, there has been no decision to remove Kylin as a flavor.  We had been waiting for updated assets for that page and did not receive any from Kylin so far, which had inadvertently caused the removal. We're going to go ahead and revert the change and continue efforts to get up to date information from the Kylin folks. Thank you so much for flagging this!
[21:48] <Unit193> arraybolt3[m], krytarik: ↑ "Assests not updated, removed instead.  Oops" but is still official.
[22:16] <Eickmeyer[m]> Bear in mind, from a governance standpoint, it's up to the Technical Board to remove a flavor. It doesn't just happen overnight.
[22:28] <arraybolt3[m]> Fa
[22:28] <arraybolt3[m]> Fallen: Thanks for the update!


[07:38] <fragy>  Hi. I have Kubuntu in VMware player and every time I press copy on a file in host machine and then open Kubuntu window it auto-pastes the file. Any idea how to disable the auto-pasting? I have disabled Klipper in KDE but it's the same behaviour
[12:04] <BluesKaj> Hi all


[00:05] <mup> Bug #1841694 opened: [UI/Papercut] Deploy: Selecting "Register as MAAS KVM host" overrides user OS selection without confirmation <MAAS:New> <https://launchpad.net/bugs/1841694>
[08:35] <cervigni> any news on the release date of 2.6.1 ?
[16:28] <mup> Bug #1841807 opened: maas cli: rack-controller list-boot-images Connection to the other side was lost in a non-clean fashion <cdo-qa> <foundations-engine> <MAAS:New> <https://launchpad.net/bugs/1841807>
[16:40] <mup> Bug #1841807 changed: maas cli: rack-controller list-boot-images Connection to the other side was lost in a non-clean fashion <cdo-qa> <foundations-engine> <MAAS:New> <https://launchpad.net/bugs/1841807>
[16:43] <mup> Bug #1841807 opened: maas cli: rack-controller list-boot-images Connection to the other side was lost in a non-clean fashion <cdo-qa> <foundations-engine> <MAAS:New> <https://launchpad.net/bugs/1841807>
[17:37] <mup> Bug #1672414 changed: Custom storage on Centos <MAAS:Fix Released> <https://launchpad.net/bugs/1672414>
[17:40] <mup> Bug #1672414 opened: Custom storage on Centos <MAAS:Fix Released> <https://launchpad.net/bugs/1672414>
[17:43] <mup> Bug #1672414 changed: Custom storage on Centos <MAAS:Fix Released> <https://launchpad.net/bugs/1672414>
[20:38] <mup> Bug #1835823 changed: Juju incorrectly placed a unit onto an existing machine <cdo-qa> <juju:New> <MAAS:Invalid by newell-jensen> <https://launchpad.net/bugs/1835823>