[09:18] <tsdgeos> mzanetti: are these the errors you got or different?
[09:18] <tsdgeos> FAIL!  : qmltestrunner::OrientedShell::test_appSupportingOnlyPrimaryOrientationWillOnlyRotateInLandscape(manta) 'verify()' returned FALSE. ()
[09:18] <tsdgeos> FAIL!  : qmltestrunner::OrientedShell::test_appSupportingOnlyPrimaryOrientationWillOnlyRotateInLandscape(flo) 'verify()' returned FALSE. ()
[09:18] <tsdgeos> because i just go those :D
[09:19] <tsdgeos> yeah those are the ones that fai
[09:19] <tsdgeos> l
[09:19] <tsdgeos> so i guess i can try to fix it now that i can reproduce it?
[09:20] <tsdgeos> "reproduce"
[09:26] <ltinkl> tsdgeos, mzanetti at dentist :)
[09:26] <tsdgeos> k
[09:27] <tsdgeos> kind of answered myself anyway :D
[12:22] <mterry> mzanetti: morning, how go things?
[12:29] <mterry> Oh at dentist
[12:29]  * mterry notices silo 41 failed its automated signoff
[12:29] <mterry> Does anyone know what the automated signoff does?
[12:29] <mterry> @unity ^
[12:31] <dandrader> mterry, no idea what's that
[12:39] <kgunn> mterry: it's some kind of package checking, so things don't get stuck in excuses
[12:39] <kgunn> there should be a log somewhere to check the validity
[12:39] <mterry> kgunn: yeah, I found the link the results in the silo page.  Exactly, it's a migration run through
[12:41] <mzanetti> mterryhey
[12:42] <mzanetti> mterry, I just came back from the dentist (and picking up turbo which obviously would've been shipped while I was away)
[12:42] <mterry> mzanetti: how was dentist?
[12:42] <mzanetti> lasted longer than expected, but all ok...
[12:42] <mterry> mzanetti: we failed automated signoff due to stale binaries in ppa.  I just now cleaned that up.  How do we restart automated signof checks?
[12:42] <mterry> mzanetti: only need to restart vivid if we can
[12:43] <mzanetti> mterry, I don't know tbh... need to ask robru or sil
[12:43] <mterry> ok
[12:43] <mzanetti> ah, I see you're on it in ci-eng
[13:48] <mterry> mzanetti: I'm watching these autopkg tests happen.  I think we're making progress
[13:48] <mzanetti> phew
[13:48] <mzanetti> mterry, in the meantime I was asked to look into some critical issues at turbo and frieza
[13:49] <mterry> mzanetti: ok I'll keep babysitting
[13:49] <mzanetti> mterry, thanks a bunch
[13:56] <mterry> what the...  FAIL!  : qmltestrunner::Lockscreen::test_clear(animated PIN) Compared values are not the same
[13:56] <mterry>    Actual   (): false
[13:56] <mterry>    Expected (): true
[13:56] <mterry>    Loc: [/data/adttmp/adt-virt-lxc.shared.p0kzgds_/downtmp/build.8Oh/unity8-8.12+15.04.20160316.7/tests/qmltests/Components/tst_Lockscreen.qml(308)]
[13:56] <mterry> that's like the most basic test
[14:02] <kgunn> dandrader|afk: did this get addressed through some other branches?
[14:02] <kgunn> https://bugs.launchpad.net/qtubuntu/+bug/1511530
[14:02] <kgunn> i'm just confused with all the supercedes
[14:06] <mzanetti> kgunn, hell yeah, me too
[14:06] <mzanetti> kgunn, during the last weekend, Saviq resubmitted like all of them :D
[14:06] <kgunn> :)
[14:07] <mzanetti> kgunn, I think those are fixed now tho... at least I can't resize some apps any more in windowed mode bigger than some certain width, which feels totally weird
[14:07] <mzanetti> given that we ignore those maximum values when clicking fullscreen
[14:07] <kgunn> mzanetti: ok, gonna mark as fix committed then
[14:08] <tsdgeos> mzanetti: mterry: the dlaky test you were seeing, was failing in the verify? i could reproduce it failing in the verify and https://code.launchpad.net/~aacid/unity8/enableDisabledOrientedShellTest/+merge/289336 fixes it
[14:11] <mzanetti> tsdgeos, http://paste.ubuntu.com/15407747/
[14:15] <tsdgeos> mzanetti: yeah my patch fixes that, bascically the rotation is not always instantaneous if your cpu is busy, so need a trycompare
[14:17] <mzanetti> thanks tsdgeos
[14:17] <tsdgeos> but i guess we can wait for the next silo anyhow
[14:17] <mzanetti> yeah, 41 is in qa already
[14:17] <mzanetti> wasn't in the mood any more at 2am to try and figure why it would fail remotely
[14:19] <tsdgeos> mzanetti: usually with those things, i can get them to fail if i start a make -j10 loop while running the test
[14:19] <tsdgeos> makes the cpu busy enough that things are not as "fast" as usual in the test itself
[14:20] <mzanetti> tsdgeos, there was also a second one I could not repro
[14:20] <mzanetti> in the dash Header somewhere
[14:23] <dandrader|afk> kgunn, yes, that's released
[14:23] <kgunn> thanks da
[14:23] <kgunn> thanks dandrader|afk
[15:23] <mterry> mzanetti: silo 41 isn't really in QA until we get the autopkg tests to pass
[15:24] <mzanetti> mterry, hmm. but they must be passing
[15:24] <mzanetti> :D
[15:24] <mterry> mzanetti: eh...
[15:24] <mzanetti> I have prove
[15:24] <mzanetti> https://unity8-jenkins.ubuntu.com/job/test-ppa-autopkgtest/
[15:25] <mterry> mzanetti: right now I'm fighting with https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-041/excuses.html
[15:26] <mterry> mzanetti: most of those are retrying now
[15:26] <mterry> mzanetti: but it's hard to figure out current state, that page updates so rarely, even after tests seemingly complete
[15:26] <mterry> http://autopkgtest.ubuntu.com/running.shtml shows current running tests
[15:28] <mzanetti> mterry, so far each and every red link I've clicked says dependency issue
[15:28] <mzanetti> not a single real test failure
[15:28] <mterry> mzanetti: right, which doesn't makes sense and I think is left over from the stale packages.  Because that page hasn't updated in 30m or so and I'm not sure the test results links are right
[15:29] <mterry> mzanetti: I've tried purging and installing everything in the ppa on my xenial laptop
[15:29] <mterry> mzanetti: can't see an actual dependency issue
[15:29] <mzanetti> yeah... it wouldn't have built if there were real dep issues
[15:29] <mzanetti> or at latest explode when installing the silo on a device
[15:29] <mzanetti> but it works fine
[15:31] <mzanetti> mterry, not sure why britney says "always failed" for uinty8 armhf tests
[15:32] <mterry> mzanetti: on vivid we get an actual test failure, but it won't let me retry it right now, last time I tried.  Waiting for i386 test to finish to see if that changes things
[15:32] <mterry> mzanetti: and now britney seems stuck on creating some nova instances
[16:14] <mterry> josharenson: your greeter branches need to be rebased on trunk
[16:14] <josharenson> mterry: :-D ok thanks
[17:08] <josharenson> mterry: all 4 branches should be current now
[17:09] <mterry> josharenson: sweet thanks
[17:39]  * dandrader finds out that applying his diff by hand is easier than trying to understand the mess tha bzr made out of his TabletStage.qml merge conflict


[00:30] <slangasek> bjf[afk]: so bug #900522 is a fun bot corner case.  If I reboot to the new kernel, it's possible I won't be able to reproduce the bug at all because I don't know how the kernel routing table has gotten into this state to begin with ;)
[00:30] <ubot2> Launchpad bug 900522 in linux "cached route that can't be removed with 'ip route flush cache'" [Low,Incomplete] https://launchpad.net/bugs/900522
[00:35] <slangasek> bjf[afk]: do you know who might be interested / able to help debug the kernel side of this?  If not, I guess I'll just reboot at some point and probably close the bug
[01:54] <bjf> slangasek: tgardner would probably be the best but i'm not sure
[01:55] <bjf> slangasek: you can add the "bot-stop-nagging" tag if you want
[01:56] <slangasek> I know... I'm just not sure that's a useful thing to do in this case :)
[01:56] <bjf[afk]> slangasek: agreed
[08:26] <smb> morning .+
[08:26] <ppisati> morning
[09:44]  * apw yawns
[09:53]  * abogani waves all
[09:53] <abogani> BenC: ping
[10:36] <apw> ppisati, when you have ti-omap4 'fixed' i can probabally test it, so push it up somewhere i an grab it
[10:58] <ppisati> yep
[10:58] <ppisati> it's baking...
[10:59] <apw> chocolate cake ?
[10:59]  * smb gets hungry
[10:59] <ppisati> uhmm... i should make tiramisu one of this day... :)
[10:59] <apw> bring it to rally
[11:00] <ppisati> uhm...
[11:00]  * apw likes tiramisu
[11:00] <smb> Guess it would count as "liquid"
[11:00]  * smb +1
[11:00] <ppisati> actually if i froze it but then it will turn crap i guess...
[11:01] <apw> heh yeah i bet it would, sigh
[11:01] <apw> i know we can just have a sprint at paolo's place
[11:01] <smb> Right, have a look at his new flat
[11:02] <apw> he can sleep on the floor
[11:03] <ppisati> but before the sprint i'll have to disassemlbe all the boxes... way too hard... :)
[11:04] <apw> we can use the boxes as desks, no problem
[11:04] <smb> No problem we are good at disassembling...
[11:04] <smb> ...assembling is another problem
[11:04] <cking> especially when the pieces have been lost and the manuals are wrong
[11:05] <smb> the what?
[11:05]  * apw swings his hammer widly "this screw will go in this square hole I am sure"
[11:06]  * cking notes that when ever he reassembles furniture there is always one critical bolt or screw missing
[11:06] <apw> cking, though that is probabally triggered by offspring
[11:07] <smb> cking, Can't be critical if things still hold together
[11:07]  * apw notes wobbly is ok
[11:08] <smb> Remembers a shelf that survived quite a bit of time after moving and having a handful of pieces of unknown destination in my hands
[11:10] <cking> DIY kernel team style sounds a bit hacky to me
[11:11] <apw> cking, we could do your extension if you like
[11:11] <smb> back to the essentials
[11:11] <cking> back to rubble more like
[11:11] <apw> always need rubble
[11:11] <cking> not when I need to live in it
[11:11] <smb> hey , things usually do work and hold together
[11:12] <cking> not with kids about
[11:12] <smb> Though in that case those few screws don't help much either
[11:13] <apw> na just more sharps for them to find
[11:13] <cking> "..but daddy you made it and it's your fault" is what I expect to hear
[11:16] <smb> cking, It is your fault anyway
[11:16] <cking> yeah, that's very true
[11:16] <apw> you should not buy anything, so there is nothing to break
[11:16] <cking> I can imagine being a hermit...
[11:20] <apw> cking, it'd be cheaper
[11:20] <cking> no beer though
[11:20] <apw> those hermit types are the ones who invented beer
[11:26] <ppisati> beer was invented by monks AFAIK
[11:26] <ppisati> apw: http://kernel.ubuntu.com/git?p=ppisati/ubuntu-precise.git;a=shortlog;h=refs/heads/ti-omap4
[11:26] <ppisati> apw: last commit, the kernel compiled here
[11:28] <apw> ppisati, ok ta, will test
[11:28] <ppisati> back in 10mins
[11:44] <apw> ppisati, where are we with bug #861296 ?
[11:44] <ubot2> Launchpad bug 861296 in linux-ti-omap4 "mmap fails to allocate 2030Mb heap on ARM" [Undecided,Fix committed] https://launchpad.net/bugs/861296
[11:45] <ogra_> apw, i think we missed the two weeks SRU window (at least thats what i gathered from GrueMaster's complaints yesterday)
[11:45] <ppisati> should be in every omap4 and imx51 branch
[11:46] <ogra_> (ask him for more detail)
[11:46] <ppisati> except for P/omap4
[11:46] <ppisati> which is based off O/omap4
[11:46] <apw> ppisati, ok so it should be available, and it is with stable to roll out
[11:46] <ppisati> so, next sync with will get it
[11:46] <ppisati> yep
[11:46] <apw> ogra_, as its for the buildds we could get them a kernel potentially out of band i guess ?
[11:47] <ppisati> we did it indeed
[11:47] <ogra_> i guess lamont already runs it (not sure though, second hand info)
[11:47] <ppisati> i handed custom kernels to #is with that fix way back
[11:47] <apw> ok then we are good
[11:47] <ogra_> apw, but GrueMaster needs to test them again
[11:47] <ogra_> to have them in the next SRU batch
[11:47] <apw> yep, there is always new batches to test
[11:47] <ogra_> (which is quite annoying for him)
[11:48] <ppisati> apw: with the armhf i'll sync with O so P will get that fix too
[11:48] <ogra_> apw, well, he tested them two weeks ago already
[11:48] <apw> ogra_, well there would be a new kernel to test next two weeks whether that is in or not
[11:48] <apw> as there will be security fixes in those kernels every cycle as well
[11:48] <ogra_> sure
[11:48] <apw> so i don't think there is any more or less testing to do
[11:48] <apw> ppisati, ok good news, my full build of your branch looks good
[11:49] <ogra_> well, its just bad if he is told to test something that doesnt get uploaded in time and then he has to start over
[11:49] <ogra_> the test means to build java stuff which is really time consuming
[11:49] <apw> ahh i see, sorry about that then
[11:50] <ogra_> yeah, not to me :) ...
[11:50]  * ogra_ is just the cassandra here :)
[11:50] <apw> ppisati, is this branch 'good' ... do we want it pushed and uploaded?
[11:51] <ppisati> apw: not yet, let me sync it with O first
[11:51] <ppisati> apw: then i'll send the entire batch of changes
[11:51] <apw> ppisati, ok, back to you :)
[11:52] <apw> ogra_, are you waiting on armhf ti-omap4 at all ?
[11:52] <ogra_> yep
[11:52] <apw> how much is it holding you up
[11:52] <ogra_> omap4 and ac100 kernels are the last nits missing before we can start armhf images
[11:52] <ogra_> *bits
[11:52] <ogra_> everything else is ready
[11:53] <apw> ppisati, how long i the resync going to take ?
[11:53]  * apw is considering whether to upload the unresynced version
[11:53] <ppisati> half an hour, one hour max
[11:54] <apw> oh then... that is an easy decision
[11:54] <apw> if it is going to be today then cool
[11:54] <apw> ogra_, are you on the hook for ac100
[11:54] <ogra_> apw, infinity is just testbuilding a changed package
[11:55] <ogra_> should be uploaded once he gets up again
[11:56] <apw> ok cool, ppisati poke me when you are done so we can expedite this thing into the queue
[11:56] <ogra_> my expectation is that we can build hf images weekendish ...
[11:57] <apw> ppisati, have we uploaded ti-omap4 to P at all yet ?
[11:57] <ogra_> once i think
[11:58] <ogra_> yup, on nov 21
[12:12] <apw> oh now i see why i am confused
[12:13] <apw> infinity, did you just invent a linux-meta for ti-omap4 ?
[12:15] <ogra_> apw, he uploaded it ahead of the kernel it seems, yep
[12:15] <apw> but where the heck did he get it from
[12:15] <ogra_> (there was a conversation in #ubuntu-arm about it )
 ppisati: I uploaded meta that assumes 1401 will build on armhf.  So, now I just need a kernel. ;)
[12:16] <apw> ogra_, great, that just throws all the kernel team process into a cocked hat
[12:19] <apw> ogra_, and is liable to bollox anyone who is an upgrader from oneiric
[12:20] <ogra_> yup
[12:20] <ogra_> dont blame me :)
[12:20] <apw> infinity, *slap*
[12:23]  * apw just has no idead what infinity has been doing to ti-omap4 meta, this is an utter mess
[12:23]  * apw stomps off to sulk in the corner
[12:30] <infinity> apw: Invent it?  It's always been there.
[12:30] <apw> infinity, you didn't use one of our source trees to make it
[12:30] <infinity> apw: All I did was add armhf to it (and rev it to the correct ABI)
[12:30] <infinity> apw: Uhh.
[12:30] <infinity> apw: It was apt-get source linux-omap4. :P
[12:30] <apw> so now i have to unf*ck all our trees
[12:31] <infinity> apw: It's been in the archive for eons.
[12:31] <apw> yeah the package is fine, its that we nolonger have a tree we can build meta from
[12:31] <infinity> apw: And I based it on what was in the archive, not much to "unfuck".  debdiff, apply, done.
[12:31] <apw> so if i naievly uploaded the top of ours, your changes would go poof
[12:32] <infinity> apw: See above, then?
[12:32] <apw> infinity, but the bigger issue is you shouldn't upload meta before the binaries are built
[12:32] <apw> as now anyone with the thing installed is liable to end up with no kernel and in a heap of trouble
[12:32] <infinity> apw: I uploaded it for armel, where the binaries have been built for weeks but no one updated the meta.
[12:32] <infinity> apw: No one has armhf installed with a kernel, cause there are none.
[12:32] <infinity> apw: (-meta was out-of-date on armel, and has been for a long time)
[12:32] <apw> ok then we are ok
[12:33]  * apw whines
[12:33] <infinity> apw: Whine less?
[12:33] <apw> na bad for me
[12:33] <apw> maybe i could be andy whine-house
[12:33] <ogra_> want to join the arm team ?
[12:33] <ogra_> :P
[12:34] <apw> ogra_, heh no you are all mad, i'd not fit in
[12:35] <infinity> apw: Is it really that tough to apply my delta to git?  Cause, I can provide you with a branch to merge, if you want.
[12:36] <infinity> apw: I just have no zinc access anymore to actually commit it.
[12:36] <apw> infinity, nope its not hard, i am moaning about not knowing as i nearly broke things
[12:36] <infinity> apw: Meh, if you broke things, I'd just whine right back. ;)
[12:36] <apw> :)
[12:36] <apw> i would hope so too
[12:37] <ogra_> whiners
[12:37] <ogra_> all you !
[12:37] <infinity> (And, for the record, anyone who uploads anything without checking the current state of the archive, and diffing current:new should probably rethink their workflow)
[12:37] <apw> infinity, that'd be us for sure :)
[12:37] <infinity> I figured. ;)
[12:37] <apw> infinity, i have also taken a note to slap tim for uploading the kernel and never uploading -meta to match
[12:37] <apw> well actually, i clearly do check cause i just noticed :)
[12:38] <apw> infinity, aside of that, meta looks good
[12:38] <infinity> S'ok.  I'll go back to mangling unsupported kernels now. ;)
[12:38] <apw> ac100 i assume
[12:38] <infinity> Yeah.
[12:39] <apw> if you have a tip somewhere i can test build it before you upload it, takes about 10mins
[12:39] <apw> (test building the packaging as it were)
[12:39] <ppisati> ok, pull req sent to the kernel ml
[12:39] <infinity> Oh, it's already building on my Panda.
[12:39] <apw> ppisati, ok will do
[12:39]  * ppisati goes to find some food (aka lunch)
[12:39] <apw> infinity, well it takes a lot less time my way
[12:39] <infinity> I don't do kernel iterations often enough to have a cross environment set up for it.  Don't care.
[12:40] <infinity> It's an excuse to get caught up on Dexter.
[12:40] <ogra_> heh
[12:40] <apw> heh ok, i found building udebs painful as it takes sooo long to fail
[12:40] <ogra_> we dont ahve udebs for ac100
[12:40] <apw> ahh then you are likely to work then
[12:40] <ogra_> (i think ... unless jani recently added them)
[12:41] <infinity> Also, you're assuming it will fail.
[12:41] <infinity> You should know me better than that. ;)
[12:41] <ogra_> it cant fail, its maintained by the arm team :D
[12:41] <infinity> ogra_: We have udebs for ac100, yes.
[12:41] <ogra_> ah, thats new then
[12:41] <ogra_> i explicitly didnt build them when i maintained it
[12:41] <ogra_> but jani moved to git and all ... using the ubuntu sauce etc
[12:42] <infinity> Well, sort of.
[12:42] <ogra_> so i guess we inherit udeb building
[12:42] <infinity> It's more linaroish than ubuntuish.
[12:42] <ogra_> yeah
[12:42] <apw> ick :)
[12:42] <ogra_> i originally based on n900 ... he moved to some generic linaro ways from that
[12:43] <ogra_> but added the sauce
[12:43] <apw> ogra_, i have often felt the right thing is to take linaro tip and merge our master into it each time to make the new version
[12:44] <infinity> I miss being a lot less confused by kernels.  When that all built from the same source package, and x86-centric people whined that merging patches with Sparc was "too hard", so they just didn't, and then they whined when it would FTBFS.
[12:44] <infinity> Good times.
[12:44] <ogra_> apw, well the prob is that linaro refuses to maintain tehir kernels after a release ... and they release monthly
[12:44] <apw> infinity, its cirtainly different now, i think i've lived through it all, quite a ride
[12:45] <apw> ogra_, oh i know, you'd be merging their original tip into our tip with cves and hoping that the result worked
[12:45] <ogra_> we could go from snapshot to snapshot ... but as soon as *we* release there isnt a way to get SRUs or security fixes
[12:45] <apw> ogra_, the one thing i am fully aware of is the amount of work their cause me and my arm peeps
[12:45] <ogra_> yep
[12:46] <apw> we essentially maintain > 2x the kernel revisions we want to cause of this crap
[12:46] <infinity> apw: I think we still need some clever way to keep the packaging more centralised and sane than it currently is.  And the secret sauce.  And all that jazz.  Even if we don't want one massive source package that takes forever to build and has (potentially) conflicting patches.
[12:46] <infinity> apw: Like, some shiny tool that will essentially roll a proper source package from git, with grafted branches as needed.
[12:46] <apw> infinity, care to be part of a discussion at rally about ideas on how we can improve things
[12:46] <infinity> apw: So they all look and act the same.
[12:47] <infinity> apw: Yeah, perhaps.
[12:47] <apw> that has been suggested and the AAs went mad that the source should be the source
[12:47] <ogra_> hard to do if you have as many different versions as linaro has though
[12:47] <ogra_> (read: BSP kernels)
[12:47] <apw> and we arn't allowed to backport the packaging changes to older releases
[12:47] <ogra_> iirc there are still boards they run with .35
[12:47] <apw> and .. 200 other complaints against anything we have suggested
[12:47] <infinity> apw: I mean, for Linaro-maintained kernels, we can't do as much, and that's fine, but anything that's theoretically maintained by the Ubuntu kernel team should all match with packaging, enforce, etc.
[12:48] <apw> infinity, and we'd do that in an instant if the sru team would take the harmonised packaging
[12:48] <infinity> apw: The source is never the source.  I wonder if maybe some wires got crossed in describing how to do such a thing.
[12:48] <apw> but we did try and they said flat no
[12:48] <infinity> apw: I mean, heck, nothing that uses autoconf is "pristine source", upstream always generates configure, etc.
[12:49] <apw> infinity, yeah, its the debian packaging changing in old releases they won't let us do
[12:49] <infinity> apw: I don't see how SRUs relate.  That's just different (and stagnant) branches.  You always have to branch at a stable release.
[12:49] <infinity> apw: Anything "auto-generating" packaging in a stable release should be deterministic anyway.
[12:49] <ogra_> the past is whats creating the workload ...
[12:49] <apw> well if we commonise, we want to commonise everywhere no?
[12:50] <apw> else the old stuff is different and the world is more of a pain than now
[12:50] <ogra_> while we can change it for the future, kernel team is stuck with the past stuff
[12:50] <infinity> apw: (ie: if I rerun autotools across a source package with the same versions of autoconf, libtool, etc, it won't change the output)
[12:50] <apw> right
[12:50] <infinity> apw: No, changing the past is a no-go.  But that doesn't perclude improving the future. ;)
[12:50] <apw> a ripe discussion for rally
[12:51] <apw> infinity, well except where the new differs from the old in semantics as that creates mantenance burden
[12:51] <infinity> apw: But let's have an informal beer on Sunday night at the Rally and see if it comes to fisticuffs and/or agreement before you care about my opinions on the matter. :)
[12:51] <apw> and right now most of the burden is on people making new branches
[12:51] <apw> infinity, sounds good to me
[12:52] <infinity> I'll go work out.
[13:08] <abogani> BenC: About "Reviving Ubuntu PowerPC"...
[13:08] <abogani> BenC: What systems will be used as reference in this effort?
[13:21] <infinity> abogani: My PowerStation, for one. ;)
[13:27] <smb> herton, I discovered this morning that I had missed one change in the upstream patches which has a related bug in the ec2 deviated files (had been missing two files in the deviations file). I suppose the correct way forward is a completely new tracking bug and to invalidate/mark duplicate the old one. Or is there another option?
[13:27]  * cking grabs some food
[13:28] <herton> smb, yes, doing a new tracking bug, duplicating the old against the new is ok, no other way
[13:29] <smb> herton, ok, will follow-up with that then. thanks
[13:46] <bullgard6> How is a »kernel update« defined? Is the term »kernel update« a technical term meaning something else than just any change in the kernel code to reflect a newer development?  So far I did not find a definition when googling. How can one write: "The package linux-generic is a kernel update"?
[13:47] <apw> generally when we talke about a 'kernel update' we are talking about an updated package containing the kernel
[13:47] <apw> i don't think i would ever write "the package linux-generic is a kernel update"
[13:47] <bullgard6> Ah!
[13:47] <apw> the package linux-generic trigers your kernel to be updated
[13:47] <apw> by always depending on the latest kernel package available
[13:49] <bullgard6> apw: Thank you very much for explaining.
[13:50] <apw> np
[13:52] <apw> ppisati, did you get an email in response to my upload
[13:54] <ppisati> apw: i got the "applied" email
[13:55] <apw> ppisati, did you get anything from launchpad about it
[13:55] <ppisati> nope
[13:55] <apw> bloody lp
[14:08] <infinity> apw: The librarian's down.
[14:08] <apw> infinity, does that break uploads?  presume so
[14:09] <infinity> apw: Since they have to be stored in the librarian, yeah.
[14:09] <infinity> apw: They should be tucked away in queues, waiting to flush when it's fixed, though.  In theory.
[14:10] <apw> infinity, yeah heres hoping ...
[15:05] <tgardner> jsalisbury, do you have a way to search for bugs against linux-meta ? In almost all cases they should be changed to linux (unless they really are meta package bugs)
[15:05] <ppisati> apw: P/omap4 is in and it's building
[15:05] <jsalisbury> tgardner, yes, I can do a search on them.  I'll do that and move them over linux
[15:05] <ppisati> apw: but the armhf version says "need building"
[15:06] <ppisati> seems it's queued
[15:06] <ppisati> gut
[15:07] <apw> ppisati, yep all good, given the state of the librarian its amazing its building at all
[15:07] <ppisati> apw: but since we don't have any armhf builder, how does it build?
[15:08] <jsalisbury> herton, bjf, Request for a patch backport to oneiric:  bug 899598
[15:08] <ubot2> Launchpad bug 899598 in linux "[Patch] The resolution of Display Port for intel cards is limited" [Medium,Triaged] https://launchpad.net/bugs/899598
[15:08] <herton> jsalisbury, we will take a look
[15:08]  * herton -> lunch
[15:09] <apw> ppisati, yep we do, we have about 10
[15:10] <ppisati> ah cool
[15:10] <apw> ppisati, we actually have more than we have armel right now, but then we have 1000s of packages to build
[15:10] <ppisati> i see
[15:10] <jsalisbury> herton, thanks
[15:18] <ogra_> ppisati, apw, infinity can raise the priority for the armhf build
[15:18] <ogra_> (or any other archive admin)
[15:19] <apw> ogra_, yep, its already started building too
[15:19] <ogra_> ah, k
[15:51] <jsalisbury> **
[15:51] <jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[15:51] <jsalisbury> **
[15:53]  * apw wimpers
[15:57]  * ogasawara back in 20
[16:13] <GrueMaster> ogra_, apw: My issue on kernel SRU yesterday was that a much needed feature that was tested in various kernels a couple of weeks ago didn't get included with this SRU cycle, meaning that people that need these fixes need to wait until almost EOY for them.  Or they run with a test kernel and not get any of the SRU updates in this release.
[16:13] <GrueMaster> Just to clarify.
[16:13] <ogra_> yeah, i think i got that across to apw and he even apologized
[16:14] <apw> yep and i suspect that is because the submitter was on holiday when he results came in, and appoligies for the testing effort that is wasted as a result
[16:14] <apw> separate to the inconvienience, it sounds like we need some updated test kerenls as well
[16:15] <apw> i am assured the fix is applied now though i can't say i have checked
[16:15] <ogra_> well, the important part (buildds) is fixed anyway already ... essentially getting it into the archive is rather the formal afterwork :)
[16:15] <GrueMaster> For the record, I'm not trying to stir up that argument again, just clarifying where I stood.
[16:15] <apw> GrueMaster, nope and i am not seeing it as a moan either
[16:15] <GrueMaster> Good.  :)
[16:15] <apw> and had i realised that it was a 2 day effort to test it i'd have been more careful to shepherd the fix
[16:16] <apw> i tend to assume its boot and run for a couple of minutes and know, whcih isn't at all the case for this puppy
[16:16] <GrueMaster> I do have some qrt tests that magically work with that fix, but since i have had to manually run them anyways until now, it isn't too much effort to monitor them again.
[16:17] <ogra_> well, we could just ask lamont to set the verification-done tag on the bug
[16:17] <apw> topdown mmap support
[16:17] <ogra_> gievn he already runs the fix on the buildds
[16:17] <apw> its that set isn't it we are talking about
[16:17] <ogra_> without having GrueMaster to runn a full test ...
[16:17] <GrueMaster> Part of the test process is that I am struggling to automate SRU testing.  Largely due to script issues and the lack of any automated installation capabilities prior to Oneiric on omap4.
[16:18] <GrueMaster> But those are almost resolved.
[16:18] <apw> ppisati, where do i expect to find 'topdown mmap support' applied?
[16:18] <apw> ppisati, fsl-imx51 and natty and oneiric ti-omap4 right?  (which it is)
[16:18] <ppisati> apw: M/N/O/P/omap4 and L/imx51
[16:19] <apw> so it looks like it is applied everywhere i am expecting it to be, so i assume it'll be in teh next roll up
[16:19] <apw> ppisati, ok cool, just checking they got applied right
[16:20] <ppisati> i posted the testing kernels the day X, but i got the ack about all of them the day _after_ the SRU process started
[16:20] <GrueMaster> ppisati: In the future, when you go on vacation to get away from it all, make sure to take your laptop so you can still work.  :P
[16:20] <ppisati> so i couldn't pull
[16:20] <ppisati> i did it before my internet disconnection
[16:20] <ogra_> lol
[16:20] <ogra_> ppisati, dont listen to him !
[16:20] <apw> ppisati, yep that is likely our fault
[16:20] <cking> hrm, still more workitems to plough through...
[16:21] <ppisati> IMO it was just an unfortunate timing
[16:21] <ppisati> the problerm is that i can't pull in fixes if they aren't tested
[16:21] <GrueMaster> Agreed.  Actually, I was on a national holiday that week as well.
[16:22] <infinity> ogra_: Err, reading backscroll, I don't think the buildds are fixed.
[16:22] <infinity> ogra_: lamont tested a kernel on a machine, he didn't do any sort of mass roll-out.
[16:22] <ogra_> infinity, i thought lamont was using the fixed kernels since a while
[16:22] <ogra_> oh
[16:22] <ogra_> ok
[16:23] <ogra_> but after all he did the testing and could just comment on the bug ... leaving tobin off the hook
[16:23] <GrueMaster> I tested it too.  Thought I had commented on the bug.
[16:23]  * GrueMaster goes to check.
[16:23]  * ogra_ hasnt looked at the bug
[16:24] <infinity> ogra_: He tested one kernel on one machine type.  That's not quite the scope of tobin's testing.
[16:24] <ogra_> oh
[16:25]  * ogra_ leaves that topic alone then
[16:25]  * ppisati goes back to 3.2/omap4...
[16:25] <ogra_> i somewhat had a different impression
[16:27] <GrueMaster> I tested it on babbage3 (Lucid) and panda (natty & oneiric).  Not sure if we had a test kernel for maverick.
[16:28] <GrueMaster> Does the patch need to be retested on top of this new SRU kernel or can it just float into the next SRU cycle and get tested there?
[16:29] <GrueMaster> (I may have missed this answer due to lack of caffeine).
[16:30] <apw> GrueMaster, for me, just when it gets applied to teh next SRU, i am not expecting it to break
[16:30] <ogra_> ++
[16:30] <GrueMaster> Ok, great.  Means I can focus on other things until next SRU cycle without a special testcase getting thrown into the mix.
[16:38] <infinity> apw: Looks like I win, my kernel will get built first.
[16:38] <apw> heh
[16:38] <infinity> (not that it matters, cause neither one can be published to the archive for a few hours)
[16:46] <amb__> We have a bug (LP #886521) which is marked "Fix Committed" in Oneiric. What is the process / timescale that a new kernel gets released to incorporate such fixes (and presumably changes it to "Fix Released")?
[16:46] <ubot2> Launchpad bug 886521 in linux "CONFIG_XEN_PLATFORM_PCI should be "y" when building 3.1 kernel" [Medium,Fix committed] https://launchpad.net/bugs/886521
[16:46] <apw> amb__, it is likely the fix if already rolled up in the -proposed kernel for testing
[16:47] <smb> Could be in the pending round of getting into proposed
[16:47] <amb__> apw, so is that an automatic process?
[16:47] <smb> But normally you find an update in the bug that is automatically generated which tells you to test the proposed kernel
[16:48] <amb__> (and/or how do we get at the .debs to test such kernels)
[16:48] <amb__> ah, it's not there yet
[16:48] <amb__> then
[16:48] <apw> amb__, ok its only just been commited, so it missed the current sru round, so i'd say you'll see it in a kernel in about 3 weeks
[16:48] <smb> No, I think its is on the way. The auto entry has some instructions about enabling proposed
[16:49] <smb> but one also can get the debs from launchpad history of the linux package
[16:49] <smb> https://launchpad.net/ubuntu/+source/linux/+publishinghistory
[16:49] <smb> ^ if lp is willing
[16:49] <bjf> amb__: we will be building the next oneiric kernel next week, as apw said it will hit -updates three weeks after that, it will be available via -proposed earlier
[16:49] <apw> amb__, and expect testing requests for it around then
[16:50] <smb> gah! lp timeout
[16:51] <amb__> bjf, thanks
[16:51] <bjf> amb__: np
[16:52] <ppisati> don't we have the meeting in 1 hour?
[16:52] <ppisati> sorry
[16:52] <ppisati> 8mins
[16:53] <jsalisbury> ppisati, yes
[16:54] <tgardner> jsalisbury, we've been screwed by going off of daylight savings time. there are 2 entries in the calendar
[16:55] <jsalisbury> tgardner, ahh, ok.  Should one of the entries be removed?
[16:56] <tgardner> jsalisbury, yeah, but which one ?
[16:56] <tgardner> I'll nuke the later one
[16:57] <apw> the meeting is at 17:00 UTC right
[16:57] <bjf> apw, yes, the meeting is now
[16:57] <jsalisbury> apw, yes, in about 3 minutes
[16:58] <tgardner> hmm, I can't delete the bogus entry. I'll send a note to Pete
[16:58] <apw> stupid google
[17:23] <ppisati> brb
[17:31] <lamont> ogra_: I was given to understand that some post-my-testing kernel had the fix, which was great, since that was what I was waiting for - the rollout of a fixed SRU is semi-automatic, manually rolling out a non-standard kernel is a royal pain
[17:31] <ogra_> aha
[17:31] <ogra_> thanks for clearifying :)
[18:36]  * tgardner -> lunch
[19:53] <bjf> jsalisbury: i believe bug 793367 can be "Fix Released"
[19:53] <ubot2> Launchpad bug 793367 in linux "ecryptfs corruption during make -j" [Medium,Fix committed] https://launchpad.net/bugs/793367
[19:53] <jsalisbury> bjf, Ok, thanks.  I'll update it.
[20:02] <jsalisbury> bjf, I'll keep an eye on and to ensure it falls off the hot list automatically as expected.
[21:39] <jsalisbury> bjf
[21:39] <jsalisbury> bjf, herton, possible Lucid update regression: bug 900943
[21:39] <ubot2> Launchpad bug 900943 in linux "System clock runs fast in kernel 2.6.32-36" [Medium,Confirmed] https://launchpad.net/bugs/900943
[21:40]  * tgardner -> EOD for now
[21:59] <bjf> jsalisbury: thanks for the pointer, have added comment, am monitoring it
[21:59] <jsalisbury> bjf, great, thanks.


[00:22] <tz_> further tinkering tells me that $cloud-config-url is pulled from DEFAULT_MAAS_URL in maas_local_settings.py .. How do I set that variable for different networks/interfaces in a cluster?
[00:32] <bigjools> DEFAULT_MAAS_URL is the address of the region and needs to be reachable from anywhere
[00:36] <tz_> so you're saying the cloud-config-url can only be one IP per cluster?
[00:47] <bigjools> it's the address of the app server
[00:48] <bigjools> it's one IP globally
[00:48] <bigjools> well not IP, a host
[00:48] <bigjools> URL to a host
[00:48] <bigjools> all maas networks need a routing to the region appserver
[00:49] <tz_> so say that host has multiple interfaces setup, how do I set default_maas_url to <IP_ADDRESS> or some sort of dynamic IP? is it possible at all?
[00:51] <bigjools> you need to set it to the IP of the interface that can route to and from the cluster networks
[00:51] <bigjools> s/interface/region's interface/
[00:52] <tz_> which can only be one at a time?
[00:52] <bigjools> the URL you set is handed to the nodes when they're deploying so they know how to contact the region
[00:52] <bigjools> yes, one
[00:52] <bigjools> on big deployments with many appservers it is likely to be a load balancer
[00:53] <tz_> this is just one server, that's why it has multiple interfaces/vlans
[00:54] <tz_> its would be a waste to start throwing in extra cluster controllers and load balancers, hence why I want that one variable to work for the networks setup on the one cluster
[00:55] <bigjools> you just need a route from the cluster interfaces to the relevant region interface
[00:55] <bigjools> then it will work
[00:57] <tz_> yeah i get that, trying to keep the networks segregated without adding a bunch of static routes and cross-vlans
[00:58] <tz_> in the config file it has a comment "
[00:59] <tz_> "configuration can, and probably should, override this."  .. do you know what config it's referring to?
[01:01] <bigjools> maas_local_settings
[01:02] <bigjools> it's set from dpkg-reconfigure


[00:50] <noarb> my motivation was to get 22.04 on a fully encrypted system booting with UEFI. My understanding is that the EFI partition will always be unencrypted, but the payloads will be signed. In order to use dropbear ssh so the drive can be unlocked remotely, is it required to have an unencrypted /boot as well as /boot/efi?
[00:51] <noarb> I think it will require an unencrypted /boot, so I was trying to make sure secure boot was enabled
[00:53] <noarb> Now shimx64.efi invokes grubx64.efi on the EFI stub. Unencrypted but signed, this grub could unlock the drive (I think it can handle luks2 now) but not with networking
[00:57] <causasui> hi, trying to gather a bit of history here. does anyone know about which version of ubuntu was the first to ship with python 3 instead of (just) 2?
[00:59] <sarnold> causasui: I think the first python3 in ubuntu was named python3.0, but I'm not 100% positive on that https://launchpad.net/ubuntu/+source/python3.0/+publishinghistory
[00:59] <causasui> nice... alternative question that might get me where I need: when did /usr/bin/python become python3?
[01:00] <sarnold> causasui: if you've chosen to install python-is-python3 package, which I think was introduced for focal https://launchpad.net/ubuntu/+source/what-is-python/+publishinghistory
[01:01] <causasui> okay, not being an ubuntu main-liner myself I don't know a lot of this offhand, e.g. if I install 22.04 and run `python` do I get 2 or 3?
[01:01] <causasui> sounds like I still need python-is-python3 to get 3 there?
[01:04] <sarnold> causasui: here's what my focal system shows when I remove the package and then try to run python https://termbin.com/7bhq
[01:05] <causasui> fascinating, okay, so python2 is actually gone
[01:05] <causasui> that's good :D
[01:05] <sarnold> well, it's there, if you install the python-is-python2 package :)
[01:06] <sarnold> it all depends on which set of scripts you want to break, hehehe
[01:06] <causasui> right
[01:34] <causasui> sarnold: if I want to know (just picking one arbitrarily here) if I can get python 3.xx by _installing_ it on xx.04, can I? how would you find out? same publishing history site on launchpad ?
[01:35] <oerheks> python3 is standard for some time now.
[01:36] <Bashing-om> !info python3 focal | causasui
[01:37] <sarnold> causasui: that's actually a bit difficult :( the packages.ubuntu.com webpage lets you do a search for eg python3 in source package names, that narrows it down a bit: https://packages.ubuntu.com/search?keywords=python3&searchon=sourcenames&suite=all&section=all
[01:38] <noarb> in this scenario: https://askubuntu.com/q/66785 is the initramfs on an unencrypted partition?
[01:40] <causasui> sarnold: fair enough, thanks :)
[02:13] <lantech19446> has anyone experienced an issue with gnome-tweaks being completely ignored by ubuntu 22.04?
[02:13] <sarnold> I think it just sets the moral equivalent of registry keys, and perhaps the keys it sets aren't read by programs any more
[02:14] <sarnold> what specific settings are you changing? what happens when you change them?
[02:14] <lantech19446> i set it to disable my touchpad while i'm typing and when that didn't work i told it to disable touchpad emulation and that didn't work either
[02:15] <lantech19446> I may have to go back to an older version
[02:17] <zxiion> hey guys how do i nickserve register ?
[02:19] <oerheks> !register
[03:23] <hqyj> ??
[03:40] <zxiion> hello room, I have an audio question (using ubuntu all works out of box trying to get this to work in other distros)
[03:40] <zxiion> pci:8086-a0c8-103c-87fe;04-01;detected;sound;snd_hda_intel, snd_sof_pci_intel_tgl;Intel Corporation;Tiger Lake-LP Smart Sound Technology Audio Controller;Hewlett-Packard Company;Tiger Lake-LP Smart Sound Technology Audio Controller
[03:56] <Bashing-om> !sound | zxiion
[03:57] <zxiion> ubuntu isnt giving me an issue its other distros (not sure what "magic" ubuntu is doing) ... figured the right modprobe -a on a driver would work
[04:05] <Crucifyy> should prolly ask in the official support chan for whatever distro you are using
[04:28] <maccam94[m]> somehow my laptop (running 22.04) has switched back to using X11 instead of wayland, and I have intel graphics (no nvidia). how can I switch back? I don't see a promising options in the GDM session list
[04:29] <matsaman> no mysterious icon?
[04:30] <maccam94[m]> I can't look at it while I'm logged in, but iirc there are only 3 options, none of them say X11/xorg, i'm just in GNOME
[04:31] <matsaman> yeah but if they say things they aren't mysterious =)
[08:07] <shawn> sdf
[08:09] <SugarElvis> suddenly have something using 25% of my CPU, (Jellyfish)  bashtop shows it as   /usr/bin/ssh -oForwardX11 no -oForwardAgent no -oPermitLocal      -is that anything to be worried about?
[08:10] <SugarElvis> i've run rkhunter chkrootkit and currently scanning with clamav so far it's ok
[08:12] <oxfuxxx> 25% is too high especially for today's CPU. My guess is that a gremlins is wanking off your ssh keys.
[08:12] <oxfuxxx> ;]
[08:12] <oxfuxxx> You must have some process working, i don't know.
[08:31] <weedmic> i have some remote machines and two databases that record when they were last seen.  our database person is on vacation.  i know the machines are online and can reach them via ssh and issue commands.  one database reports when they were last seen, the other (on some machines) reports last seen months ago.  I am trying to determine, do the remote machines "report" they are online - or - is the database server polling them to see if they are online.  so, my
[08:31] <weedmic> question is... what software would be on ubuntu machines to "report" they are online.  I'll search for those to see if any exist and are active.
[09:16] <weedmic> is this an example of the host communicating with itself?  olimex    4491  0.0  0.3  11936  3816 ?        S    03:13   0:00 sshd: olimex@pts/0
[09:23] <otisolsen70> I have a disk attached to a virtual machine that is not visible with 'lsblk'. Is there any way to "refresh" what is shown by lsblk so as to have the VM/Linux discover the disk/volume?
[09:37] <A_Dragon> .g 164
[09:37] <A_Dragon> whoops
[09:37] <A_Dragon> hi
[09:44] <wez> hi A_Dragon!
[09:44] <A_Dragon> o/
[09:54] <scortal> o hi
[10:02] <weedmic> time was wrong on the remote machine, everything else was correct - fyi
[10:02] <weedmic> g2g
[10:10] <BluesKaj> Hi all
[10:10] <wez> .o/
[10:38] <ketiv> I woke up, done some baking and to test if everything is working fine after upgrading wrote in a Pycharm that code: hi("print")  :-)
[10:50] <student> se
[10:50] <student> ess
[10:50] <student> Witam bardzo serdecznie '
[12:02] <circ-user-QTzQq> the monitor goes into power saving or off mode when my mouse moves to the lower right corner and lower part of the screen. no screen saver, only power saving mode or shut down. after upgrading to the latest LTS, 22.04 LTS. I have a desktop computer, Dell Desktop. i did google to solve for several days, i changed a lot of settings to solve.
[12:02] <circ-user-QTzQq> *turn off not shut down
[12:28] <guiverc> otisolsen70, you can use `watch` to monitor output from commands & highlight differences (options allow you to set interval etc(
[12:31] <scortal> ubuntu
[12:31] <scortal> o hi
[12:37] <dreamon> since update to 22.04 my default printer is always not default one. I have to set it everytime on printerdialog.
[12:46] <otisolsen70> guipan, how to have 'watch' highlight differences?
[12:50] <ioria> otisolsen70, watch -d <cmd>
[12:50] <ioria> dreamon, there was on old bug; see if you have somewhere an 'lpoptions' file
[12:51] <otisolsen70> ioria, thanks!
[12:51] <ioria> ok
[12:51] <Maik> scortal: please stop posting random stuff in the support channel
[12:52] <Maik> scortal: if you're bored just ahng out in the offtopic channel
[13:00] <scortal> nou
[13:22] <dreamon> ioria, /snap/okular/109/usr/bin/lpoptions , /usr/bin/lpoptions and /home/dreamon/.cups/lpoptions
[13:31] <mort> afaik 22.04 is released properly now, right? `do-release-upgrade` still tells me "There is no development version of an LTS available" even though I'm on 20.04
[13:32] <mort> is the best solution to set Prompt=normal, upgrade to 22.04, then set Prompt=lts again? I assume 22.04 is held back for LTS people to let non-LTS people sort out any issues first
[13:32] <dreamon> mort, afaik do-release-upgrade runs at 22.04.1
[13:33] <dreamon> "update-manager -d" sould do it
[13:33] <mort> what do you mean by "runs at 22.04.1"
[13:34] <dreamon> by release 22.04.1 its possilbe to upgrade, using do-release-upgrade..
[13:34] <mort> ah
[13:34] <lotuspsychje> !ltsupgrade | mort
[13:34] <mort> makes sense
[13:34] <dreamon> (o)
[13:35] <mort> the do-release-upgrade help output makes it sound like you'll end up running a development release if you use `-d`
[13:54] <jkaye> Good morning all! Does anyone know if it's possible to disable the behavior of switching workspaces with the mouse wheel? This triggers on me 10+ times a day by mistake and I can't seem to find any way to turn it off
[14:24] <theteju> good Morning Everyone, I am on kubuntu 20.04
[14:24] <theteju> Linux Kubuntu2020 5.4.0-109-generic #123-Ubuntu SMP Fri Apr 8 09:10:54 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
[14:24] <theteju> I need kernel 5.14 or above for one of my audio interface device to work
[14:25] <theteju> can someone please guide me how can I safely upgrade the kernel? Or else.
[14:25] <lotuspsychje> jkaye: for tweaks in your system try dconf-editor, if the value exist you can find it there
[14:25] <theteju> This is the module I need to get the device working. https://github.com/Focusrite-Scarlett-on-Linux/sound-usb-kernel-module/blob/v5.12-scarlett-gen3/README.md
[14:29] <oscar> hi!
[14:32] <oscar> Hi guillermo!
[14:33] <guillermo> hola buenas
[14:33] <guillermo> me gusta el esparrago
[14:34] <guillermo> Hello oscar i love ubuntu i hate windows
[14:35] <oscar> hello
[14:36] <BluesKaj> running linux doesn't mean you have to hate windows :-)
[14:37] <guillermo> dont worry because i was making some homework
[14:37] <guillermo> and what i said it was because i was sending a message here with my partner
[14:37] <ketiv> Hello Everybody, Stay Happy & Keep Rolling ;-)
[14:38] <BluesKaj> hi ketiv
[14:38] <ketiv> o/
[14:38] <ketiv> What's up BluesKaj ?
[14:39] <BluesKaj> just mucking about with pavutcontrol settings, ketiv
[14:39] <BluesKaj> err pavucontrol
[14:39] <ketiv> ok, how's it going?
[14:40] <BluesKaj> ok, got it setup to decode the audio properly
[14:43] <BluesKaj> this pc is a HTPC plus Linux pc, integrated with my cable box, tv and audio system
[15:09] <Minvera> Does Ubuntu have xinit already? If I put a .xinitrc in my ~ will it actually run?
[15:43] <jpmh> I have a MINIMAL pythn script that is monitoring gpio 26 - Weirdly, at least to me, when I change the state of pins 4 and 17 it triggers the event handler for pin 26.  The code is VERY short and is at: https://paste.ubuntu.com/p/bw9whNYMVy/
[15:44] <jpmh> any suggestions?
[15:45] <leftyfb> jpmh: maybe try #python or #raspberrypi?
[15:46] <jpmh> leftyfb: TY - did post in the raspberrypu too - it is NOT a python issue  - the same or at least similar perl script shows exactly the same
[15:47] <leftyfb> jpmh: it's not an ubuntu issue either
[15:48] <leftyfb> you are more than likely addressing your GPIO ID's incorrectly
[15:48] <jpmh> leftyfb: true - but I am seeing it on ubuntu on the pi - so I wondered if maybe it is in the interupt overlat
[15:50] <leftyfb> jpmh: https://pinout.xyz/
[15:50] <jpmh> leftyfb: I like your idea - but realistically the changes are with raspi-gpio which is VERY standard and VERY well documented and the python code is the sort of reference.  And, other than triggering the event it does all work correctly.  In fact, as a band-aid I am just ignoring the event if the state has not changed
[15:51] <leftyfb> jpmh: a good test would be to throw raspiOS onto an SD card and try your script there
[15:52] <jpmh> lefty - I like that idea - simple enough to try -  of course if the underlying issue is debian then both ubuntu and piOS come from that same root - but a GREAT suggestion.  I'll try that
[15:53] <waveform> jpmh, I would second the suggestion to try it on raspios too but from a quick look at your script I don't see any obvious issues. Is the wire to GPIO26 particularly long? (wondering if it's acting as an aerial to whatever's going on on other GPIOs)
[15:53] <jpmh> waveform: the wire is maybe haf a meter and I would point out that I do have the Pull Up specified
[15:54] <jpmh> haf -> half
[15:54] <waveform> jpmh, yes -- that was the first thing I checked :)
[15:54] <waveform> (the pull-up)
[15:54] <jpmh> waveform: what?
[15:55] <waveform> the first thing I checked was that it wasn't a floating input (that you had the pull-up set)
[15:55] <jpmh> but actually - I have plenty of Pi's so I'll stick it on another machine where there is nothing attached.  I love the idea of interference.  In fact the outputs both have relays on them too.  SO, I'll move the code to a machine with NOTHING connected to the pins
[15:56] <waveform> hmm, relays can be fairly noisy interference-wise and the built-in pulls aren't the strongest (50K IIRC?) so it's worth considering at least
[15:59] <waveform> one thing I would caution (although I'm fairly confident it's not the cause here) is that the method of accessing GPIOs is in the process of changing; full details here: https://waldorf.waveform.org.uk/2021/the-pins-they-are-a-changin.html
[15:59] <jpmh> waveform: and leftyfb TY SO MUCH - indeed it is the relays -
[15:59] <jpmh> just chatting with smart people is so helpful - I really appreciate the input
[15:59] <waveform> no prob :)
[16:26] <scortal> hi
[16:48] <jpmh> when I log in the system creates /run/user/1000 - but when I start jobs using @reboot in crontab it does not - is there some way to cause that to happen
[16:49] <scortal> brb
[16:57] <leftyfb> jpmh: use systemd as opposed to crontab and make sure you're running it as a user and not root
[16:57] <i-garrison> jpmh: why do you need that?
[18:20] <GrayGhost> after updating to 22.04 several app don't run or give errors .. related to gtk
[18:21] <GrayGhost> might there be a fix for this ?
[18:22] <GrayGhost> Gtk-Message: 13:21:54.552: Failed to load module "canberra-gtk-module"
[18:22] <GrayGhost> Segmentation fault (core dumped)
[18:23] <GrayGhost> I am using Gnome
[18:24] <mrkubax10> error message don't tell much, it's related to theme which shouldn't make app segfault
[18:26] <mrkubax10> but you can try: apt install libcanberra-gtk-module libcanberra-gtk3-module
[18:26] <GrayGhost> I did that ... latest one is installed
[18:27] <mrkubax10> what app is segfaulting?
[18:27] <GrayGhost> canon scanner software
[18:29] <GrayGhost> also getting simular errors with Gambas3 software
[18:31] <mrkubax10> you can run it with gdb and send backtrace, I don't have any other ideas...
[18:31] <mrkubax10> use paste service for that
[18:35] <GrayGhost> it says "no stack"
[18:36] <mrkubax10> I don't think that it will be possible with canon software as it is probably proprietary
[19:02] <rabbitnightmare> good lord this LTS release is incredibly unstable
[19:02] <rabbitnightmare> trying to wipe a thumb drive and everything crashes
[19:04] <rabbitnightmare> applications refuse to run properly, deluge for example runs only in "thin client mode"
[19:04] <rabbitnightmare> how did this release get messed up SO badly?
[19:04] <rabbitnightmare> how am I suppose to roll this out
[20:06] <makechanges> is there a way to find out when a build with be incorporated into the ubuntu distribution, and/or a location that lists upcoming builds that will be released or what the current builds are that are distributed?
[20:08] <jhutchins> makechanges: Not generically, no.  When will your taxes be ready to file for 2022?
[20:09] <jhutchins> makechanges: If there's a specific update that you're looking for we might be able to direct you.
[20:09] <makechanges> jhutchins: usually the day before they are due
[20:09] <jhutchins> makechanges: If you just want to be sure you're always running the very latest version of all of your software, Ubuntu is probably not for you.
[20:10] <jhutchins> makechanges: See also "how long is a piece of string?".
[20:11] <makechanges> jhutchins: i'm learning how this works, so please pardon me for lack of proper terms, etc. i've been using ubuntu for 10 years, but i'm not really a tech-oriented person. i've been having problems with how thunderbird has been dealing with pgp keys, and have a hacky (from my perspective) way of working with it.
[20:13] <makechanges> jhutchins: so, while i'm dealing with my issues related to thunderbird, i'm trying to figure out how the distribution, etc works so that if i have a question in the future related to builds/etc and when they will be incorporated into the ubuntu distribution i can better understand it.
[20:21] <oerheks> launchpad would be a good start https://launchpad.net/ubuntu/+source/thunderbird
[20:21] <oerheks> https://launchpad.net/ubuntu/+source/thunderbird/+changelog
[20:26] <makechanges> oerheks: thank you!
[20:29] <makechanges> oerheks: do you know if there is a page that lists all of the packages that are included in the ubuntu distributions. i tried https://launchpad.net/ubuntu/+source, but that just reverts to https://launchpad.net/ubuntu/. it appears that if i know a package's name i can tack it onto the end, like this... https://launchpad.net/ubuntu/+source/TACK_PACKAGE_NAME_HERE
[20:32] <makechanges> oerheks: and i think i understand correctly that, according to https://launchpad.net/ubuntu/+source/thunderbird, thunderbird 1:91.9.0 is proposed, and will eventually be released to Kinetic Kudu (and presumably trickle down to jellyfish/indri/fossa/etc...)?
[21:03] <mattf> Im trying to create a dummy sound card on a ubuntu vps but aplay -l doesn't show it
[21:04] <mattf> devices are mounted on /dev/snd http://ix.io/3Xta
[21:04] <mattf> I ran "modprobe snd-dummy" and it was sucessfull
[21:05] <mattf> I created this basic config: http://ix.io/3Xtc then ran "alsactl init" and "alsactl restore"
[21:06] <mattf> http://ix.io/3Xtd
[21:07] <mattf> what is wrong here?
[21:12] <jhutchins> makechanges: There's no schedule, and there's no one team that handles ALL of the packages.  The final packaging and distribution to the repos is mostly handled by the same group of volunteers as they have the time and resources to do it.
[21:13] <Aison0> I'm pretty much overwhelmed with this apt-key deprecation...
[21:14] <Aison0> e.g. I would like to add this key: apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 871920D1991BC93C
[21:14] <jhutchins> makechanges: For Ubuntu, like most distros, the major version of a project is mostly frozen at the distro version release.  Bug and security fixes usually get updates, but new features and designs only get updated if someone volunteers to create a backport.
[21:14] <Aison0> but that's deprecated now
[21:15] <jhutchins> makechanges: Packages like Firefox are sort-of an exception, some teams maintain them in external repositories, and there are snaps that are uusally ahead of the official .deb packages in the repos.
[21:15] <jhutchins> makechanges: You can also go directly to mozilla.org.  I believe they have very current .deb packages available.
[21:16] <jhutchins> makechanges: You can also, of course, download the source code and build the very latest version yourself.
[21:16] <jhutchins> makechanges: You might also want to check out some of the other browsers that are available.
[21:17] <vimart> Hi
[21:20] <sarnold> hi vimart
[21:21] <vimart> oi sarnold how are you?
[21:23] <makechanges> jhutchins: thanks for the explanation. i used the thunderbird tar.bz2 file to update to thunderbird's 'more current verison' of 91.9. that doesn't have the same problem as 91.8. i'll just keep an eye out for when a more recent thunderbird build gets distributed as a ubuntu package and move back to the build in the ubuntu repository then.
[21:25] <jhutchins> makechanges: Glad you solved it!  Remember though, the "upstream" packages aren't as well tested - you become one of the testers!
[21:25] <jhutchins> makechanges: New releases can mean new bugs.
[21:26] <jhutchins> (Backup snapshots are a great idea.)
[21:26] <makechanges> jhutchins: guess i will double down on my backups :)
[21:35] <Sbur3> Using ubuntu.  Trying to resize 2 oartitions on a 4tb sata drive. I "lost" it.  Doesn't get detected during boot or when connected. Can someone walk me through how to recover access to it?
[21:35] <jhutchins> Sbur3: SSD?
[21:35] <Sbur3> It would be /sdb
[21:36] <Sbur3> jhutchins no
[21:36] <jhutchins> Sbur3: Can you attach it to a sifferent SATA port?
[21:36] <jhutchins> different
[21:37] <jhutchins> Is it detected in the BIOS/UFI menus?
[21:37] <Sbur3> It workesd.  I had resized one partition from 3.81tb to 2.96. Was able to create another partition of 696gb
[21:39] <Sbur3> jhutchins I had it almost where I wanted it to be.  I wanted to resize down the 2.96tn to2.86 to give more room to the 696gb. I think that I clicked "sqafely remove" for the 696gb and it lost the 2.96
[21:42] <Sbur3> is there a command line to toggle siomething?
[21:47] <Sbur3> jhutchins In "system settings", it lists "automount devices" (on login" and "on attach. Both columns have the partitions in the "disconnected devices" and each column as not checked
[21:48] <jhutchins> I'm not familiar with the Gnome interface, but I would expect that you could mount them by selecting them either there or in the file manager.
[21:49] <jhutchins> The disk utility that you're managing the partitions with should be able to see and deal with un-mounted partitions.
[21:49] <Sbur3> both gpart and kde partition manager seems to have "lost" the partitions and the hard drive
[21:52] <Sbur3> jhutchins I think I'll try a reboot and see if that changes something
[21:52] <Sbur3> jhutchins thanks for the help
[22:03] <Urk> How do I get development folks to adapt xsct as a package?  Its needed because sct is no longer actively being developed, and the current iteration has problems.
[22:05] <sarnold> Urk: the best way is to get the package into debian; that's not exactly the easiest thing, but it'll show up in the next ubuntu release after it's in debian
[22:05] <sarnold> Urk: you could also put together a snap package if one doesn't already exist, that'd give you results today :)
[22:06] <makechanges> oerheks: thanks for your help today!
[22:06] <makechanges> jhutchins: thanks for your help today!
[22:06] <GrayGhost> since the upgrade to 22.04 I can not run my canon scaner software, does this tell you anything that I can fix : https://pastebin.com/rLsbQudF
[22:06] <makechanges> thanks to everyone else for making ubuntu happen - much appreciated!
[22:07] <sarnold> GrayGhost: I think that all looks fine
[22:10] <GrayGhost> what about this :  https://pastebin.com/1hVk4bjV
[22:11] <sarnold> ouch
[22:11] <sarnold> that looks unhappy
[22:11] <GrayGhost> lol ... thanks
[22:12] <GrayGhost> what do I do about it ?
[22:12] <sarnold> GrayGhost: https://askubuntu.com/a/66361/33812  suggests trying "sudo apt-get install gtk2-engines-pixbuf:i386"
[22:12] <GrayGhost> I have tried all the fixes I could find on google
[22:13] <sarnold> yeah, needing something from gtk2 era isn't going to go great..
[22:13] <sarnold> needing something from 32-bit era isn't going to go great :(
[22:14] <jhutchins> GrayGhost: Do you have xsane installed?  It has a scan-for-devices option that might tell you something.
[22:14] <GrayGhost> that did not help
[22:15] <GrayGhost> it worked before the upgrade to 2204
[22:15] <jhutchins> sarnold: Yeah, the only version of the "wrapper" for my Brother printer is 32b and doesn't want to work with a 64b system.
[22:16] <GrayGhost> I installed the 64 bit from canon
[22:17] <sarnold> GrayGhost: hmmmm... it kinda looks like it should be available for 22.04 too, https://launchpad.net/ubuntu/jammy/+package/gtk2-engines-pixbuf
[22:20] <GrayGhost> sarnold, which means I should have it ... or need to install it .
[22:21] <sarnold> GrayGhost: yeah, installing it at least ought to be easy enough
[22:24] <GrayGhost> No joy  : Gtk-Message: 17:24:14.631: Failed to load module "atk-bridge"
[22:25] <sarnold> GrayGhost: is it just that one message, though?
[22:25] <Urk> sarnold:  The problem with getting a package in Debian is that you have to find a developer who wants to work on it.  I previously made a recommendation for gammy, and even though it was introduced as a candidate, no one signed up to work on it.  Yet color correction, and eye protection has become a big thing.
[22:26] <GrayGhost> is there any way I can go back to 21.XX  ?
[22:26] <Sbur3> jhutchins I'm back. my sdb2 (2.96tb)has a watning about it needing e2fsprogs v1.41+
[22:26] <sarnold> GrayGhost: that package looks like it exists for 32 bit x86 as well https://launchpad.net/ubuntu/+source/at-spi2-atk/2.38.0-3/+build/23106559
[22:27] <sarnold> GrayGhost: try sudo apt install libatk-bridge2.0:i386  and see if that helps?
[22:27] <Urk> sarnold:  Thats a different package.  I was referring to gammy, and not jammy.  I don't know what jammy is, but gammy is a color correction tool.
[22:27] <jhutchins> Sbur3: Interesting.
[22:28] <sarnold> Urk: please note, I was talking with GrayGhost
[22:28] <jhutchins> Sbur3: What steps get you to that message?
[22:28] <Urk> gammy was ported from windows, and has already been adapted by Fedora, and Arch.
[22:28] <Urk> sarnold:  sorry about that.  I got confused.
[22:28] <jhutchins> Urk: So yours was a request for packaging?
[22:28] <sarnold> Urk: easy enough :)
[22:28] <jhutchins> Urk: Have you tried building it yourself?
[22:28] <sarnold> Urk: it's definitely a lot of work to get things into debian :(
[22:29] <GrayGhost> sarnold,   Unable to locate package libatk-bridge2.0:i386
[22:29] <Urk> jhutchins:  I'm having a bit of trouble managing the things I am already working on so have elected to hold off for now.
[22:29] <sarnold> GrayGhost: hrm :(
[22:29] <sarnold> GrayGhost: maybe download it from the launchpad page and install it manually?
[22:30] <Sbur3> jhutchins gparted. list of paertitions. exclamation mark next to sdb2.  Rught click on sdb2. Option "information"
[22:31] <jhutchins> Sbur3: I can't seem to raise the bot, do you have e2rsprogs installed?
[22:31] <jhutchins> That should operate at a filesystem level, not at the partition table level.
[22:32] <Sbur3> jhutchins it says that it can't read the file system and that the ext4 needs e2fsprogs v1.41+
[22:34] <Sbur3> If I could screenshot the thing, I would


[00:00] <huwshimi> hatch: Any idea what is going on here? http://ci.jujugui.org:8080/job/juju-gui-merge/575/console
[00:01] <hatch> just re-run it
[00:01] <huwshimi> ok
[00:01] <hatch> assuming you have the conflicts fixed
[00:01] <huwshimi> yeah
[03:14] <hatch> huwshimi looks like thse 2 landed well
[03:18] <huwshimi> hatch: Yeah, I had to fix the tests and merge conflicts for both. I was prepared for that as all my branches are touching the same code
[03:18] <hatch> ahh - well this mv is coming together quite nicely
[03:19] <hatch> I found a really simple way to do the new inspector tests heh
[03:19] <hatch> well a simple way to conver it
[03:19] <huwshimi> Ah nice!
[03:20] <hatch> yeah I'll put it up tomorrow
[03:20] <huwshimi> Great
[03:20] <hatch> now the card I've been working on is going to be quite interesting...
[03:21] <hatch> the one where we delete the machine token before the delta comes in
[03:26] <huwshimi> hatch: oh yeah, it'll be a nice change, but tricky to handle
[03:29] <huwshimi> hatch: Any ideas how you'll do it?
[03:31] <hatch> heh still investigating....it's probably going to be a multi step process, the model will be updated with the appropriate data when juju sends it's ACK but then when the detla comes in, it swaps it then...
[03:36] <hatch> well I'm out, have a good day
[10:39] <rick_h__> morning party people
[10:42] <urulama> rick_h__: morning
[10:55] <frankban> rick_h__: morning
[10:55]  * frankban lunches
[11:46]  * urulama lunches
[12:16] <bac> ahoy
[12:18] <rick_h__> welcome back bac
[12:19] <bac> you too, though a day late
[12:23] <rick_h__> bac: spent 3hrs watching youtube videos on landscape photography for my yosemite trip
[12:24] <rick_h__> bac: watch out, here comes hdr I think, I don't have all the ND filter extra 10lbs of stuff on my lens gear :/
[12:24] <bac> fun
[12:24] <bac> we took a day trip on friday and i took some crap fotos, but it was fun
[12:27] <rick_h__> party
[12:29]  * urulama checks bac.photo ... no Yosemite :(
[12:57] <bac> jujugui: just had failures bootstrapping to ec2:us-west-2.  changed to us-east-1 and all was good.  ymmv.
[12:58] <bac> urulama: never been to yosemite.  :(
[14:20] <frankban> urulama, guihelp: I need two reviews for https://github.com/juju/charmstore/pull/75 (charmstore/golang). anyone available? thanks!
[14:21] <urulama> frankban: be on it in 5min
[14:21] <frankban> urulama: thanks
[14:35] <hatch> jujugui need one more review on huws branch https://github.com/juju/juju-gui/pull/500
[14:37] <urulama_> hatch: internal server error ...
[14:37] <hatch> hah hah haaaaaa
[14:37] <rick_h__> hatch: looking
[14:42] <hatch> thx
[14:50] <hatch> jujugui call in 10
[14:57] <hatch> jujugui call in 2
[15:01] <rick_h__> jujugui call time antdillon urulama_ ^
[15:01]  * bac trying...
[15:02]  * bac reboots
[15:11] <hatch> Makyo:  https://github.com/juju/juju-gui/pull/501
[15:11] <Makyo> Thanks
[15:11] <hatch> really trivial, heh
[15:14] <hatch> jrwren: so they don't have overnight camp there?
[15:15] <hatch> or do I have a different idea of camp :)
[15:15] <jrwren> hatch: she is a little young for that. She would probably be fine.
[15:15] <jrwren> hatch: no kids eh?
[15:15] <jrwren> hatch: once kids get to elementary school, instead of going to day care all day in the summer, they go to day camps.
[15:15] <jrwren> hatch: a lot of our kids friends are at day camp all day every day of all of summer vacation.
[15:16] <rick_h__> luca: ! the guys brought up something important
[15:16] <jrwren> hatch: it makes for a very different childhood than I had.
[15:16] <rick_h__> luca: how does one delete a unit on a machine/container?
[15:16] <hatch> jrwren:  nope no kids, one big d.i.n.k, here
[15:16] <hatch> ahh yeah we don't have day camps, just day care for summer
[15:16] <jrwren> hatch: stop, you'll make me jealous.
[15:16] <hatch> although I was different because I went to the lake for most of the summer
[15:16] <hatch> lol
[15:17] <luca> rick_h__: each unit has a destroy button found in a more menu
[15:17] <rick_h__> luca: ok, /me goes to look for that screenshot
[15:17] <rick_h__> luca: and anything on the inspector list for the units?
[15:17] <hatch> day camps actually sounds like a really great idea
[15:17] <luca> rick_h__: https://drive.google.com/file/d/0B7XG_QBXNwY1RXozODVyeU5QMUU/edit?usp=sharing
[15:18] <luca> rick_h__: thats right, at the moment scaling down can only be done manually
[15:19] <rick_h__> luca: that's destroy machine, but what about a single unit on that machine?
[15:19] <luca> rick_h__: it’s the same
[15:20] <luca> rick_h__: there should be a more menu associated with every unit available on hover
[15:20] <luca> rick_h__: inside that more menu you can find destrou
[15:20] <luca> rick_h__: destroy^
[15:20] <rick_h__> luca: oh? there's a more menu for every unit in a machine/container?
[15:20]  * rick_h__ missed that
[15:21] <luca> rick_h__: I just check the states file and it’s missing from that…
[15:21] <luca> rick_h__: somewhere down the MV iterations Spencer and I have forgotten to include it in the states file
[15:22] <rick_h__> luca: ok, so we're not completely nuts to not have it
[15:22] <luca> rick_h__: but we’ve had a destroy button on units since the button
[15:22] <rick_h__> luca: thanks
[15:22] <luca> rick_h__: no worries
[15:22] <luca> rick_h__: I don’t have Spencer available to make a new mock-up though
[15:22] <luca> rick_h__: https://docs.google.com/a/canonical.com/file/d/0B7XG_QBXNwY1YjNQajhsMUNHOFE/edit
[15:22] <rick_h__> luca: all good
[15:22] <rick_h__> we can work it out
[15:23] <luca> rick_h__: ok, thanks
[15:23] <rick_h__> anything else in there besides the destroy?
[15:23] <rick_h__> luca: maybe we'd put the web view stuff in there if we get that feature in
[15:23] <luca> rick_h__: I was thinking of “View on the web”
[15:23] <rick_h__> right
[15:23] <luca> rick_h__: yeah
[15:23] <rick_h__> ok cool
[15:23] <luca> rick_h__: we’re in sync :P
[15:23]  * rick_h__ is scared now
[15:23] <luca> rick_h__: lol
[15:42] <kadams54> jujugui: Sorry about missing standup. Lost my internet connection and then my phone tethering failed me, so ended up relocating.
[15:42] <rick_h__> kadams54: all good
[15:42] <rick_h__> kadams54: any notes on your current card?
[15:42] <rick_h__> kadams54: I wasn't sure what 'all classes' meant
[15:43] <kadams54> rick_h__: we need autodeploy functionality now in both the MachineViewPanelView and DeployerBar classes.
[15:43] <rick_h__> kadams54: right, and it's in the MV panel currently?
[15:43] <rick_h__> kadams54: at least the UX is there, /me hasn't tried it out
[15:44] <kadams54> rick_h__: Yup. Got that refactored into a class extension and all tests are passing, but there aren't any unit tests touching those methods specificially.
[15:44] <hatch> frankban:  rick_h__ Makyo was there a reason why we originally went with removing ghost models of machines/containers/units instead of updating them on the delta to begin with?
[15:44] <kadams54> rick_h__: So I'm writing up some new tests before landing it.
[15:45] <rick_h__> hatch: I can't recall any reason. Just easy? Maybe some connection point issue between the delta coming back?
[15:45] <rick_h__> kadams54: ok awesome thanks
[15:45] <frankban> hatch: I don't remember: does the ghost model share the same id as the real one that will come?
[15:45] <hatch> frankban:  no their id's will be different, but that doesn't necessarily mean we can't update it
[15:46] <hatch> I am just devising a plan and wasn't sure if there was some reason why we didn't do that originally
[15:46] <urulama_> frankban: been on a call, continue your PR
[15:46] <frankban> hatch: so are you planning to update the models in handlers.js?
[15:46] <rick_h__> hatch: I think the main thing is to make sure we don't couple too much stuff together doing that
[15:47] <hatch> so my plan (still to be determined if this will work) when juju responds with ACK we update the ghost model with the 'real' ids - then when the delta comes in, we search for the id supplied in the detla and update the model accordingly
[15:47] <hatch> right now the issue is that when juju sends the ACK we destroy the ghost model
[15:48] <hatch> so we don't have any UI until the delta comes in
[15:48] <rick_h__> right
[15:48] <kadams54> hatch: what card are you working on?
[15:48] <rick_h__> I think your plan seems sane
[15:49] <hatch> kadams54:  in Project 1
[15:49] <kadams54> hatch: yeah, this is the uncommitted state not being removed until we get the ACK, right?
[15:49] <frankban> hatch: that would work fine, assuming we have the real id for each call at juju ACK time
[15:49] <hatch> frankban:  right, do you know if that's the case?
[15:49] <hatch> I am assuming so, but have no data to back that up yet
[15:50] <frankban> hatch: no, we need to check, and it can be done easily by looking at go.js
[15:50] <frankban> hatch: if that's the case, then +1 on your plan
[15:50] <hatch> great thanks all, I'll dig deeper
[15:53] <kadams54> hatch: just a heads up: this may impact the stuff I just landed in the onParentResults handler specified in lazyAddUnits.
[15:55] <hatch> kadams54: it shouldn't, this is all happening in the callback after the juju ACK so it's all one layer up from where that's happening
[15:55] <hatch> onParentResults is called well before this stuff
[15:55] <kadams54> hatch: cool
[15:55]  * rick_h__ runs to get food stuffs
[15:56] <hatch> kadams54:  with that said, your changes makes this work properly though :)
[15:56] <kadams54> yay
[16:06] <hatch> jujugui does anyone have any tricks to working on the gui in a real env?
[16:07] <frankban> hatch: you know mine, mostly for hacking. if you mean being able to have a branch in the lxc, then no, but I always wanted to investigate something like that
[16:08] <frankban> hatch: anyway, mine is: juju set juju-gui juju-gui-debug=true juju-gui-console-enabled=true juju-gui-source="https://github.com/frankban/juju-gui.git BRANCHNAME"
[16:08] <hatch> frankban:  well I want to work on the gui in the local env without having to push it up all the time
[16:08] <hatch> frankban:  using juju-gui-debug=true does that allow me to modify the source in the charm and have it reflected in the real env?
[16:09] <frankban> hatch: and then hack on /var/lib/juju-gui/juju-gui/build-debug (or something like that)
[16:09] <hatch> ok I'll try that thanks
[16:16] <hatch> huh it appears that local isnt' working for me, it's not spinning up an lxc instance
[16:16] <hatch> 1.20.1
[16:17] <hatch> hmmmmmmmmm
[16:29] <rick_h__> hatch: any luck?
[16:30] <hatch> rick_h__:  yeah got it deployed, changes in the dir frankban mentioned don't appear to show up though
[16:32] <frankban> hatch: did config-changed complete its execution? are you in the build-debug directory? are you refreshing your browser hard?
[16:35] <hatch> frankban:  yeah I'm on the develop branch, and modifying in the same dir you mentioned
[16:35] <hatch> no amount of refreshes seem to help
[16:36] <frankban> hatch: what's the content of /etc/init/guiserver.conf?
[16:37] <hatch> --guiroot="/var/lib/juju-gui/juju-gui/build-debug" \
[16:37] <hatch> assuming that's the line you're interested
[16:37] <hatch> that's where I'm modifying but nothings changing in the browser....
[16:37] <frankban> hatch: yes, so those are the file served
[16:37] <frankban> being served
[16:39] <frankban> hatch: in var/log/upstart/guiserver.log you should see what files are served for each request
[16:40] <hatch> frankban:  yeah so it turns out it was a really bad cache
[16:41] <hatch> :/ sorry
[16:41] <frankban> hatch: np
[16:41] <hatch> the good news is that the machine view actually creates machines
[16:41] <hatch> :)
[16:42] <frankban> hatch: :-) I supposed that, shouldn't I ?
[16:42] <hatch> haha - you never know :)
[16:42] <hatch> looks like the callbacks are passed the new 'real' ids
[16:42] <hatch> so this will work
[16:43] <hatch> it's only passed the new id though
[16:43] <hatch> but that's enough
[16:46] <hatch> *sigh* one of my thunderbolt ports is loose...apple quality....
[17:52] <marcoceppi> who owns charmworld? is it you guys or is it still sinzui & co>
[17:53] <rick_h__> marcoceppi: it's us still
[17:53] <rick_h__> marcoceppi: what's up?
[17:53] <marcoceppi> rick_h__: nm, just been building a new review queue, doesn't affect you guys much but I'll cc your list as a heads up
[17:53] <rick_h__> marcoceppi: cool thanks.
[17:54] <rick_h__> marcoceppi: also, we'd love to chat. I'm not sure how much jcastro/arosales told you about our upcoming plans to deprecate charmworld
[17:54] <marcoceppi> I got the low down from you guys last sprint
[17:54] <marcoceppi> which is why I started the new review queue
[17:54] <rick_h__> marcoceppi: so would like to chat with you and tvansteenburgh around a migration path from charmworldlib in the nearish future
[17:54] <rick_h__> marcoceppi: cool
[17:54] <marcoceppi> rick_h__: yeah, that too
[17:55] <rick_h__> marcoceppi: and curious how the review queue stuff is to work in a 'juju publish' world (sans LP)
[17:55] <hatch> oo new review queue nice
[17:56] <marcoceppi> rick_h__: I'm building a login system using Ubuntu/Launchpad SSO, when taht happens you'll just submit a new request for review there and we'll build plugins to map wherethe soruce for that charm is held to monitor merge req
[17:56] <marcoceppi> but it's going to need some thinking/work
[17:56] <marcoceppi> already building in gh support to monitor the mirrors
[17:56] <rick_h__> marcoceppi: yea, that's what we need to sync up on. In a publish world there's no promise of vcs info there
[17:57] <marcoceppi> yeah, now that it's sinking in, I can already see a glaring hole-in-the-head for how we maintain promulgated charms :)
[17:58] <rick_h__> marcoceppi: yea, we want to sync up and solve those issues ahead of the game if possible
[17:59]  * marcoceppi nods
[17:59] <marcoceppi> want to do that sometime this week?
[17:59] <rick_h__> marcoceppi: sounds good, /me checks calendar
[17:59] <rick_h__> marcoceppi: pretty open Tues/Wed or Friday here
[17:59] <marcoceppi> Tues work well for me
[18:00] <rick_h__> marcoceppi: k, added a meeting with you and tim
[18:19] <hatch> rick_h__:  I sent an email to luca and peeps, I forgot to add that I think it should be pre-MV 1.0, thoughts?
[18:20] <rick_h__> hatch: looking
[18:21] <rick_h__> hatch: yea, there's some thoughts on onboarding from back when MV was designed.
[18:21] <rick_h__> hatch: and it's a known thing they're looking at as the notifications are too transient and we talked about them during the sprint
[18:22] <rick_h__> hatch: so I don't think your email is a surprise or anything.
[18:22] <hatch> ahh ok good - I was just sitting there, going "umm this change should be instant" heh
[18:22] <rick_h__> hatch: and it's something to get right before launch for sure
[18:22] <hatch> then "oh duh"
[18:38] <hatch> TIL getById uses an internal id map which doesn't get updated in lazy model lists when you update the id in the model and there are no util methods to do so
[18:38] <rick_h__> heh, good lesson to know :)
[18:39] <hatch> looks like I'll have to write a util method to fix that
[18:39] <hatch> time to patch YUI
[18:40] <hatch> I was stepping through the delta stuff going ....umm why is this id not being picked up by getById.... heh
[18:40] <hatch> ok taking lunch bbl
[19:08] <urulama> good night, jujugui, have a great rest of the day
[19:08] <bac> see ya urulama-afk
[19:30] <kadams54> guihelp: need a code review only (no QA) for: https://github.com/juju/juju-gui/pull/503
[19:32] <Makyo> On it.
[19:32] <kadams54> Makyo: thanks!
[19:32] <Makyo> kadams54, mind taking a look at PR 502 in exchange?  It's tiny.
[19:33] <kadams54> Makyo: yeah, will do.
[19:41] <kadams54> Makyo: comment added.
[19:41] <rick_h__> kadams54: looking
[19:44] <Makyo> kadams54, thanks.  We don't have direction on what to do with the add container link, since that will be moving to the more menu soon; once there, we'll have direction on whether to remove or show as disabled.
[19:44] <kadams54> Makyo: yeah, in reviewing the bug, it seemed ambiguous. rick_h__: do you know if the "more" menu is pre- or post-1.0?
[19:45] <Makyo> kadams54, yeah, sorry, forgot to link the bug.
[19:45] <kadams54> If it's post-1.0, it seems like we ought to get clarification.
[19:45] <rick_h__> kadams54: pre
[19:45] <kadams54> Ah good.
[19:45] <rick_h__> kadams54: it's what we got the delay points for
[19:45] <rick_h__> kadams54: the more menu and some other UX enhancements
[19:46] <kadams54> rick_h__: basically the revamped MV design they showed us in London, right?
[19:46] <rick_h__> kadams54: yep
[19:46] <rick_h__> we want to release with the cleaner better UX out of the gate vs waiting to update it
[19:46] <kadams54> Makyo: I'm fine with landing PR#502 then.
[19:47] <kadams54> I'll add a comment to that effect in the PR.
[19:48] <kadams54> Looks like huw's all over the more menus :-)
[19:48] <rick_h__> yea, need to check on their status tonight
[20:08] <hatch> bac:  so I just chatted with the local apple store (not a real apple store) and he said after they run a diagnostic on it, about 2 days to order the new logic board then 2-3h install - so not horrible, maybe you should look into it as well if you're having the same problem
[20:08] <hatch> assuming of course you have a local apple repair shop heh
[20:09] <bac> hatch: did they mention if there was a design change?
[20:09] <hatch> there are reports of people with new machines with the same problem (he wasn't even surprised that this happened) so my guess is no
[20:10] <hatch> guess logic boards are cheap for apple lol
[20:11] <bac> seems like a pita if there is no reason to think it'll really fix the problem
[20:11] <bac> i think your eraser solution is pretty elegant...
[20:12] <hatch> lol - my warranty is up in December so I want to make sure it's fixed before that :)
[20:13] <bac> yeah, mine is long gone
[20:13] <hatch> applecare is really expensive, I wonder how much a logic board costs
[20:16] <hatch> $379 for 3 years....maybe it's worth it if it costs a lot to fix heh
[20:20] <hatch> logic board from ifixit is almost $1k lol ouch
[20:20] <hatch> I hope that's not the regular price haha
[20:21] <hatch> ohh it's 3 years total, so only an additional 2 years for the extra $379.... almost $200/yr
[20:47] <hatch> jujugui when trying to update an id of a lazy model object and the id already exists, would you expect it to throw? return false? return the object at that id?
[20:47] <hatch> I'm thinking throw....but we don't really throw anywhere else...
[20:47] <hatch> I'm thinking return false or return the new id if it was successful
[20:48] <rick_h__> undefined vs false?
[20:49] <hatch> does undefined signify that it didn't work? I'm thinking no because js fn's return undefined by default
[20:50] <rick_h__> hatch: hmm, true
[20:50] <rick_h__> I guess I like throw then tbh. You asked for something it cannot/will not do
[20:50] <rick_h__> right?
[20:50] <hatch> right, but I don't think YUI throws anywhere
[20:50] <hatch> it just returns some value
[20:50] <hatch> so you don't have to try/catch everywhere
[20:51] <hatch> I'd prefer throwing also :)
[20:51] <hatch> but doesn't really follow a convention
[20:51] <rick_h__> meh, it's clear as day, error in the console, I'm +1 on throw if it's for our use anyway
[20:51] <hatch> ok throw it is
[20:51] <rick_h__> and if we want to upstream it I'd suggest we get feedback on upstream
[20:51] <rick_h__>  /on/from
[20:51] <hatch> nah - they will want tests and everything
[20:51] <hatch> too much work to upstream it lol
[20:52]  * rick_h__ leaves for the day before he starts anything :P
[20:52] <hatch> (ok maybe that's just lazy) :P
[20:52] <rick_h__> have a good night all
[20:52] <hatch> hahaha
[20:52] <hatch> cya, enjoy your night
[20:52] <hatch> I'll ask huw about the widget
[20:52] <rick_h__> yea, I'll be online sometime tnoight to bug him on that and his expenses
[20:52] <hatch> oh ok cool
[20:52] <rick_h__> thanks for the help
[21:00] <Makyo> jujugui can I get another quick review on https://github.com/juju/juju-gui/pull/502 ?
[21:01] <hatch> done
[21:01] <hatch> ^ Makyo
[21:04] <Makyo> Thanks hatch
[21:04] <Makyo> hatch,  do you have Privacy Badger installed?
[21:05] <Makyo> It's blocking some github avatar URLs for me.
[21:22] <bac> Makyo: i use ghostery.  is the badger newer, shinier, better?
[21:24] <hatch> Makyo:  I don't
[21:26] <hatch> oo boy do I hate errors from within YUI
[21:35] <hatch> wow....ok do not use Object.create(null) if you're going to ever use that object in YUI
[21:35] <hatch> heh
[22:07] <Makyo> jujugui anyone have the latest MV design handy?  I lost my tab :(
[22:08] <hatch> sorry not here - I can't keep all their designs straight lol
[22:11] <Makyo> It's a real problem
[22:11] <Makyo> I'll do a temporary version, then fix it up tomorrow.
[22:42] <hatch> I don't think the setCommitted and setUnCommitted methods are used in the tokens any longer
[22:45] <rick_h__> Makyo: it's in the "Juju Gui" folder I think. THey keep the latest designs in the drive folder
[22:46] <rick_h__> Makyo: https://drive.google.com/drive/u/1/#folders/0Bzj8yHKHrx6pNkVUTkNPd3RWNTQ/0BwDPGKe0SiMbU0RfOXZIXzJlODg/0B7XG_QBXNwY1V3B3dDNvYXJGRE0/0B7XG_QBXNwY1NEtGaHJYZGM4enM
[23:03] <hatch> awww yeah got this working
[23:04] <hatch> oh and look at that, just at EOD
[23:07] <huwshimi> Morning
[23:08] <hatch> ohhh look who decided to show up!
[23:08] <hatch> :P morning
[23:08] <huwshimi> :)
[23:10] <huwshimi> hatch: How's the delta stuff coming along?
[23:10] <hatch> good I just finished it - functionally complete anyways
[23:10] <hatch> needs cleanup and tests now
[23:11] <hatch> how we set the committed and uncommitted stuff needs to change into the models....not sure why it's a token level property
[23:11] <huwshimi> Nice!
[23:14] <hatch> yeah but now tokens stay uncommitted for a while while we wait for juju to ack the changeover haha
[23:14] <hatch> so will need another ui state
[23:16] <huwshimi> hatch: I guess that might be helped somewhat if there is a progress bar at the bottom, so you know things are happening
[23:17] <hatch> yeah there are a few different approaches for sure
[23:17] <hatch> I sent off an email to peeps about it
[23:19] <hatch> well I'm stepping away for a bit
[23:19] <hatch> huwshimi:  rick_h__ wanted to talk to you about where you were at with the widget
[23:19] <hatch> just a heads up he'll be popping back in sometime tonight
[23:20] <hatch> bbl
[23:20] <huwshimi> hatch: I'm trying to figure out how to render the dummy element before it gets render for real
[23:21] <hatch> not sure I understand?
[23:21] <hatch> wana have a quick call?
[23:21] <huwshimi> hatch: Well, I have to display a button, that turns into the real menu on hover, so I have to have some dummy elements that exist outside the widget
[23:22] <hatch> that's not what I was suggesting
[23:22] <hatch> I was suggesting that each token had a ... which was visible when hovered
[23:22] <hatch> when the user clicked the ... it would render the widget for the menu
[23:24] <huwshimi> hatch: I know but rick said to do the init first, so I'm trying to get it to replace the elements rather than appending a new bouding box container
[23:24] <huwshimi> Also, the ... menu is visible before hover
[23:25] <hatch> ohh noo the ... is just a dumb dom element
[23:25] <hatch> you don't need to render the widget
[23:25] <hatch> you can instantiate it without rendering it
[23:26] <hatch> then when someone clicks the .. it renders the widge
[23:26] <hatch> t
[23:26] <huwshimi> I know, but, I have to then get the inited widget to listen for the clikc on the dummy elemnt, but I can't because it creates it's own bounding box
[23:26] <huwshimi> it's ok, I have it under control, it's just a pain :)
[23:27] <huwshimi> Actually, you're correct, the more menu does appear on hover (despite what the mockups show)
[23:27] <hatch> nooooooooo you put a delegate handler on the machine view container which then calls the tokens 'rendermenuwidget' method
[23:27] <hatch> then you only have one event handler for infinite tokens
[23:28] <huwshimi> Ah sure, that's a good idea
[23:28] <hatch> :)
[23:29] <hatch> ok I'm really leaving for a bit now
[23:29] <hatch> :) be back in like 45mins
[23:30] <huwshimi> bye


[05:27] <Endler> Is anyone working on backporting the patch for kernel bug #8791 fixed in 2.6.23 to 2.6.22.  I'd like to try test gutsy, but all drives are on a HPT374 controller, so I'm out of luck until this patch is applied.
[05:29] <Endler> Seems like it going to be rough going for Gutsy using the .22 kernel with bugs fixed in .23
[07:18] <arno-t> Hi. I used git to get the feisty source, and did a make clean, make xconfig and "make-kpkg -rootcmd fakeroot --initrd linux_image". It did a lot of compiling and ended up with: "cannot change ownership of debian/linux-headers-2.6.20.arno1/usr/share" "Error 1". Suggestions? Are there better ways of compiling?
[08:49] <kraut> moinm
[06:18] <mjg59> BenC: My patch to add GTM and STM support to libata seems to have fallen out of gutsy
[06:19] <BenC> mjg59: Ok, we'll get it back in. Initially I had left it out because it didn't apply, and I was hoping it would get upstream
[06:19] <mjg59> BenC: Ok. It's kind of critical.
[06:20] <mjg59> I can't remember what the upstream situation was. I'll track that down and repush.
[06:22] <mjg59> BenC: Do you have a list of *all* the patches that were in feisty but haven't been applied to gutsy? I've asked this before and you gave me some, but that wasn't one of them. I'm uncomfortable not knowing what else has been dropped.
[06:23] <BenC> everyrthing from libata was dropped
[06:23] <BenC> all the acpi stuff got in
[06:23] <BenC> pretty much libata was left alone
[06:23] <mjg59> That's not the entire set of the kernel I touched
[06:23] <BenC> I did re-integrate the HPA patch though
[06:24] <BenC> mjg59: everything else is in there
[06:24] <mjg59> BenC: It's just that you previously told me that everything else was in there, which is why I've been scratching my head over this regression on HPs for a couple of months
[06:24] <BenC> libata was such an ugly delta it was near impossible to strip things out
[06:24] <mjg59> I'm happy to regenerate patches, but that's kind of hard if I don't know that they've been dropped :)
[06:25] <BenC> mjg59: unfortunately I deleted all the data I had from doing the feisty to gutsy merge :/
[06:25] <BenC> that whole deal isn't going to happen after gutsy because of the way we've been able to rebase the tree and keep it cleaner
[06:26] <mjg59> BenC: That makes life... awkward.
[06:26] <BenC> mjg59: I can take some time this weekend to go over the feisty patches and check against gutsy
[06:26] <mjg59> Ok, that would be helpful
[06:26] <BenC> but I'm pretty sure that libata was the only thing that got screwed on the merge for gutsy
[06:28] <mjg59> The GTM stuff /seems/ to be upstream now
[06:28] <mjg59> But not in 22
[06:31] <rtg> BenC: when are you planning to merge <IP_ADDRESS>?
[06:32] <BenC> mjg59: ah, wonder if we can just cherry pick
[06:32] <BenC> will make gutsy+1 merge easier
[06:32] <BenC> rtg: should do it now while we still can
[06:32] <rtg> BenC: my thought exactly.
[06:32] <mjg59> BenC: It's in linus's tree, by the looks of it
[06:33] <BenC> mjg59: if you can give a SHA(s), we can pull it in
[06:33] <BenC> brb
[06:38] <zul_> BenC: got a sec?
[06:38] <BenC> yeah
[06:39] <zul_> for 84965 the microsoft keyboard bug there is a driver out there for 2.6.22 but it depends on a usb-hid input system that is not accepted upstream yet, not sure what to do
[06:40] <zul_> the hid simple driver interface is what its called
[06:41] <BenC> zul_: we can't fix the bug in current code?
[06:41] <zul_> nope doesnt look like it, its intertwinned with the interface
[06:41] <BenC> then we can't fix it :/
[06:42] <zul_> thats what I thought
[06:42] <zul_> oh well :)
[06:47] <zul_> ill give an explanation and place it as wont fix
[06:50] <zul_> done
[06:50] <zul_> back to oops training
[07:02] <mjg59> BenC: Ok, I have a patch
[07:03] <BenC> mjg59:
[07:03] <BenC> err, cool
[07:03] <mjg59> BenC: Sent to kernel-team
[07:03] <BenC> I'm off to lunch in a bit
[07:03] <BenC> mjg59: thanks
[07:05] <BenC> \
[07:06] <rtg> mjg59: How come you don't use your kernel.ubuntu.com account to produce a git commit?
[07:07] <mjg59> Because I haven't got round to setting stuff up there yet
[07:12] <rtg> mjg59: cherry picking is a lot less work for me.
[07:13] <mjg59> rtg: I couldn't just pull this from upstream, because that would have introduced dependencies on various changes to libata-core that we don't want
[07:14] <rtg> mjg59: I know that. But cherry picking the final commit from your Gutsy tree is trivial.
[07:15] <rtg> trivial for me, that is.
[07:16] <mjg59> rtg: Just pipe the mail to git-applypatch?
[07:17] <mjg59> (git-am, rather)
[07:18] <rtg> mjg59: hmm, I've not used that one. Lemme give it a whirl.
[07:26] <rtg> mjg59: I think BenC and kylem need to look at it. Thats a big honking patch meddling in stuff I have no experience with.
[07:27] <mjg59> rtg: Probably a good thing you couldn't just pull it into the tree, then :)
[07:27] <rtg> mjg59: well, I always look first anyways.
[08:11] <mjg59> BenC: While the HPA code is in gutsy, it seems to be disabled by default
[08:11] <mjg59> (ata_ignore_hpa is 0)
[08:14] <elmo> maybe this is a stupid question, but wouldn't ignore_hpa being false, mean don't ignore it?
[08:15] <elmo> tho that might explain the problem I had on the Equium the other day
[08:15] <mjg59> elmo: If it doesn't ignore the HPA, the HPA is still in effect. Therefore your disk is smaller.
[08:16] <mjg59> So ata_ignore_hpa has to be true
[08:16] <elmo> oh, right
[08:16] <elmo> mjg59: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/134950 <- could that be due to HPA?
[08:17] <mjg59> elmo: Don't /think/ so
[08:17] <mjg59> I just saw exactly the same thing on this device
[08:18] <mjg59> Vista 32-bit or 64-bit?
[08:20] <elmo> mjg59: 32
[08:32] <mjg59> Ok, so it turns out that I've screwed that patch up
[08:32] <mjg59> Just working on it
[08:33] <mjg59> Right, much better
[08:33] <mjg59> Just need to figure out why atapi is unhappy
[08:41] <rtg> BenC: just pushed gutsy-lum for Dell 1420 sound fix. Try it on your XPS 1330.
[08:45] <mjg59> Ngh. Actually, these commands are failing on both devices
[09:30] <sparrw> when compiling a module, gcc is complaining "expected ')' before string constant" about MODULE_PARM(debug,"i");, there may be gcc/kernel version compatibilty issues.  any ideas?
[09:35] <IntuitiveNipple> sparrw: what are the lines leading up to that line? usually there's a syntax error, missing ; or something
[09:35] <infinity> s/MODULE_PARM(debug,"i")/module_param(debug, ulong, 0)/
[09:35] <sparrw> MODULE_AUTHOR("..."); MODULE_DESCRIPTION("..."); MODULE_LICENSE("...");
[09:35] <sparrw> infinity: ill try that
[09:36] <infinity> (or bool, or whatever)
[09:36] <infinity> Probably a bool, in your case, since debug's kinda an on or off thing.
[09:37] <sparrw> warning, return from incompatible pointer type...  probably bool then?
[09:37] <infinity> Well, I don't know, not having seen the rest of your code. :P
[09:37] <sparrw> yeah, ill just try it
[09:38] <infinity> I'd tend to want a debug flag to be bool, but that's just me.
[09:38] <IntuitiveNipple> what's the type of debug?
[09:38] <infinity> If I had to guess, based on "random C coder laziness", I'd guess it's an int currently.
[09:39] <infinity> Because, y'know, everything is an int.
[09:39] <infinity> Or a char.. *shudder*
[09:39] <sparrw> could be worse...  could be an assumed-32-bit-int  :)
[10:18] <sparrw> i have a problem with -dev packages...  /usr/include/unistd.h and /usr/include/xorg/xf86_ansic.h disagree wbout the definition of xf86usleep (and there are other conflicts)...  help
[10:18] <sparrw> ?


[06:06] <tite12345> Hi!
[06:06] <tite12345> Anyone here?
[06:06] <tite12345> Merry Christmas by the way! :D


[23:25] <Aaron> hey question
[23:25] <Aaron> I'm getting some emails. from my own email which is<EMAIL_ADDRESS>[23:25] <wxl> probably better to ask at #canonical-sysadmin
[23:26] <wxl> however, i think you'll find they don't originate from canonical servers
[23:26] <wxl> they're just spoofing the from
[23:26] <wxl> which is trivial to do
[23:26] <Aaron> that's weird.
[23:26] <wxl> typical spam/phishing behavior


[02:06] <hapibeli> as I'm used to Mint, how do I check my RAM's capabilities?
[02:06] <hapibeli> sorry, on my kubuntu machine?
[02:19] <oerheks> Mint?
[02:19] <oerheks> interesting, they have their own channel..
[03:47] <glo> miquerencia!
[03:47] <glo> nnmmmmmm
[13:28] <kattyb> Hello, good afternoon
[21:30] <SignorGranchio> ciao