[00:18] <bryce> http://bryceharrington.org/drupal/zap
[06:00] <tjaalton> bryce: hope it does it's job to silence the minority
[06:55] <bryce> thanks for mentioning the alt-sysrq-k on the merge thread; I'm not sure how to add replies to that other than replying to emails
[07:11] <tjaalton> yep, me neither
[07:49] <bryce> heya mvo
[07:49] <mvo> hey bryce
[07:50]  * mvo yawns
[07:53] <mvo> is there a consensus now on the discussion about the dontzap option?
[07:54]  * mvo reads the mails about it
[07:56] <bryce> mvo: see my blog as well
[07:56] <pwnguin> i cant believe it went this long without noticing
[07:56] <bryce> mvo: I don't know that we necessarily have consensus, but we do have definitive sabdfl direction on it
[07:58] <bryce> I don't think we really need the checkbox anyway; we still have alt-sysrq-k which seems to work just as well for me
[07:59] <mvo> ok, I will revert the merge again
[08:00] <bryce> thanks mvo
[08:05] <tjaalton> i was surprised to see the merge request, since there had not been any discussion about adding it to the capplet
[08:07] <bryce> tseliot had emailed me and rick privately with the idea.
[08:07] <bryce> in hindsight probably should have been discussed more widely first
[08:07] <mvo> I had the impression this was part of the uds discussion already
[08:08] <mvo> a bit unfortunate that alberto did the work on it and now its not being used :/
[08:10] <bryce> yeah, for kubuntu we decided at the uds session to have a checkbox for it.  For ubuntu we actually decided to make it available in the xorg.conf options editor
[08:10] <bryce> however tseliot is thinking he may not get that sufficiently done in time, so suggested doing a checkbox for gnome as well, for the time being
[08:12]  * mvo nods
[08:12] <mvo> about the transition for fglrx->ati, I think that is straightforward, I will answer in detail today
[08:15] <bryce> thanks.  Yeah it will be good to have that in our back pocket
[08:16] <bryce> after my last confcall with them I think we may need that in the future
[08:35] <bryce> new troubleshooting guide --  https://wiki.ubuntu.com/X/Troubleshooting/HugeFonts
[09:59] <marijus1> what are the prerequisites to get kms working on jaunty with intel?
[10:00] <jcristau> marijus1: a new kernel, and possibly rebuilding the driver against that
[10:01] <jcristau> not sure about the latter
[10:01] <marijus1> i got .29-rc3
[10:01] <RAOF> Depends on how much you want X to work, I think.
[10:01] <marijus1> :D
[10:02] <marijus1> well... i tried... and gdm was kind of not messed up
[10:02] <jcristau> if you want things to work somewhat better, you probably want master of the driver and libdrm, instead of the releases
[10:02] <RAOF> And probably building the kernel modules from master wouldn't hurt.
[10:03] <jcristau> RAOF: .29-rc3 is fine
[10:03] <jcristau> results will depends on the chipset, too. and you need to use uxa iirc
[10:03] <marijus1> so jaunty libdrm is not suited for that?
[10:03] <RAOF> Cool.  Ish.  More cool would be if nouveau did it :)
[10:06] <marijus1> i got an 855GM :)
[10:06] <jcristau> ah. that's probably not going to work
[10:06] <marijus1> not yet... or never ever?
[10:07] <jcristau> not yet
[10:07] <marijus1> well i guess ill try anyway...
[10:10] <marijus1> does it also have anything to do with mesa?
[10:11] <bryce> marijus1: 855 is just such an old chip...
[10:11] <marijus1> i know :)
[11:20] <dholbach> hello my friends - how are you doing?
[11:21] <dholbach> I was wondering if somebody knew the magic silver bullet to make my compose key and the "usual accents" and stuff work on my intrepid and jaunty again
[11:21] <dholbach> ~n  'e  `e  ^e  ,c  "i  is the stuff that I get right now
[11:21] <dholbach> with German Eliminate Dead keys
[11:21] <dholbach> and a compose key set
[11:23] <dholbach> the might seb128 says it might be xkeyboardconfig
[11:27] <dholbach> œ ñ é è ê ç ï - seems like I have to use the right strg key
[11:27] <dholbach> everything else either blocks other key combinations or does not work
[11:28] <dholbach> the behaviour definitely changed
[11:28] <dholbach> s/strg/ctrl
[11:34] <Ng> mmm, compose. I probably can't help, I just told gnome to use Alt-Gr as compose and it kinda just worked with the UK layour ;)
[11:46] <dholbach> thanks Ng - I fixed it now
[11:46] <dholbach> using "Germany" instead of "Germany Eliminate Dead Keys"
[11:46] <Ng> huh
[11:47] <dholbach> and the right win key or is it a menu key(?) does not work for me
[11:47] <dholbach> Germany with Ctrl as compose works
[11:47] <dholbach> very weird
[11:47] <dholbach> I hope I get it working on jaunty on the other machine now too
[11:47] <dholbach> I felt stupid and illiterate for not writing names properly :)
[11:51] <dholbach> works in jaunty now too
[11:51]  * dholbach is happy
[11:51] <dholbach> thanks again my X friends
[13:08] <ogra> hmm, did Xorg drop support for ~/.xsession ?
[13:08] <jcristau> no
[13:08] <ogra> creating a .xsession in my homedir that just contains xterm makes startx fail
[13:09] <ogra> removing that file gets me to a desktop proper
[13:09] <jcristau> define fail
[13:12] <ogra> its in qemu ... so it uses fb0 ... i see (==) using config file: "/etc/X11/xorg.conf" which is a completely empty file apparently
[13:12] <ogra> next line says "Primary device is not PCI" (how did it know that ! :) )
[13:13] <ogra> then an xkbcomp warning
[13:13] <ogra> and then: waiting for X server to shut down ddxSigGiveUP: closing log
[13:13] <ogra> thats all
[13:14] <ogra> removing .xsession just works
[13:15] <ogra> its an armel install done with d-i with yesterdays iso
[13:16] <ogra> gdm works as well btw ... but both, gnome and gdm are just to heavy since the arm qemu has a restriction to 256M
[13:16] <ogra> so i wanted to use an xterm to be at least able to test single apps
[13:17] <ogra> nothing in the log either, no errors or anything
[13:19] <ogra> looks like X itself comes up fine but doesnt go to the .xsession file
[13:21] <ogra> same if i put gnome-terminal instead f xterm in there
[13:22] <ogra> hmm, works with metacity (which indeed doesnt get me anywhere)
[13:22] <ogra> argh and no zapping ...
[13:22]  * ogra reboots the VM and grumbles
[13:25] <ogra> hmm
[13:25] <ogra> metacity &
[13:25] <ogra> xterm
[13:25] <ogra> doesnt work either
[13:26] <ogra> the other way round metacity starts but i dont get an xterm ...
[13:27]  * ogra doesnt get it
[13:28] <ogra> aha !
[13:29] <ogra> .xsession-errors: xterm Xt error: Unresolved inheritance operation
[13:29] <ogra> whatever that means ... it prevents treminals from starting apparently
[14:20] <tjaalton> bryce: heh, not a single comment on your blog, or maybe they are on the moderation queue?
[17:59] <bryce> tjaalton, oh yeah probably in the moderation queue
[19:00] <Rocket2DMn> hey bryce , got a few minutes?
[19:02] <bryce> Rocket2DMn: sure
[19:02] <Rocket2DMn> cool, ive been working on bug 322610 triage for a friend
[19:03] <Rocket2DMn> ive been having trouble deciding on the package to file under, im thinking it might be the intel driver though, which is why im asking you
[19:03] <Rocket2DMn> since in Xorg.0.log intel is talking about the backlight
[19:03] <bryce> mmm
[19:04] <bryce> gnome-power-manager would be my first guess
[19:04] <bryce> often problems with backlights are ACPI issues rather than X.
[19:04] <Rocket2DMn> yeah the bug was originally filed under gpm
[19:05] <bryce> that said, there have been some cases where it is the video driver that's at fault.
[19:05] <Rocket2DMn> but the problem kicked in only after a kernel upgrade, so i filed it under linux as a hardware regression
[19:05] <Rocket2DMn> the kernel upgrade came in the other day, the intel driver update a few days before
[19:05] <bryce> yep that's also possible
[19:05] <kees> Rocket2DMn: you can booting an earlier kernel, or downgrading the intel driver?
[19:06] <Rocket2DMn> kees, i had him reboot into an older kernel and the problem goes away
[19:06] <Rocket2DMn> there are attachments on the bug from both kernels, but the logs basically line up
[19:06] <Rocket2DMn> there was a quirk in hal, the older kernel picked up 2 compter_backlight entries, whereas the new kernel only saw one
[19:08] <Rocket2DMn> thinkpad_acpi has some stuff in kern.log but its the same in both, it looks like its surrendering control
[19:08] <Rocket2DMn> which seems normal in this case
[19:09] <bryce> yeah, sounding a lot like an acpi kernel issue
[19:09] <bryce> Rocket2DMn: speak with ogasawara who is the kernel bug triage person, to help get attention on your bug
[19:10] <Rocket2DMn> alright, its not my bug, its a friend's
[19:10] <Rocket2DMn> ill ping her about that
[19:10] <Rocket2DMn> do you think its ok under linux or should it be under acpi-support?
[19:10] <pwnguin> its kind of unfortunate that one person determines what kernel devs do and don't see
[19:11] <pwnguin> if you follow all the triage rules, it still won't make it onto her "suggested bugs of the week" list
[19:11] <Rocket2DMn> i think sometimes she is a little slow to look at some bugs, but im sure the kernel team is very busy
[19:12] <pwnguin> rocket2dmn: well, its also easy to fall off her radar
[19:12] <Rocket2DMn> yeah, i dont doubt that
[19:12] <bryce> at least there is a process; it was worse before
[19:13] <Rocket2DMn> hehe, yeah, i guess they decided at the last UDS to not have triagers assign bugs to the kernel team either
[19:14] <Rocket2DMn> i think that's unfortunate, but i hope it helps their process
[19:16] <bryce> tjaalton, ok comments are up at http://www2.bryceharrington.org:8080/drupal/zap
[19:19] <tjaalton> bryce: cool :)
[19:20] <bryce> heh, most common message is that yet again macbook is missing keys
[19:21] <bryce> it baffles me why people buy macbooks when they are missing so much functionality
[19:21] <jcristau> tell them to get a real computer :)
[19:21] <bryce> anyway, presumably they still have a power button at least
[19:22] <tjaalton> hehe
[19:45] <tjaalton> bryce: hmm, still can't see the comments there
[19:57] <bryce> really? hm
[19:58] <bryce> tjaalton, try reloading?  they should all be there
[20:00] <tjaalton> still nothing.. bad firefox
[20:00] <tjaalton> oh well, maybe I don't want to read them anyway
[20:01] <tjaalton> s/want to/*shouldn't*/
[20:01] <tjaalton> uh, s/don't//
[20:02] <tseliot> tjaalton: firefox knows what's better for you :-P
[20:02] <tjaalton> tseliot: seems to be the trend ;)
[20:02] <tseliot> hehe
[20:02]  * tseliot -> away
[20:03] <bryce> I really need to upgrade drupal...
[20:05] <bryce> tjaalton, could you try again?  I tried a different method for publishing the comments this time
[20:06] <tjaalton> bryce: shiny.. works this time
[20:07] <bryce> awesome
[20:29] <tjaalton> nothing too alarming there. on my thinkpad I don't need to use Fn, but altgr instead of alt
[20:30] <tjaalton> so maybe documenting "the new behaviour" isn't that straightforward as would be ideal
[20:32] <bryce> yeah
[20:33] <bryce> tjaalton oh btw, what do you think of that patch for kees' bug to change the max client limit?
[20:48] <jcristau> hrm. the vmmouse_detect(1) manpage upstream says 'report bugs to launchpad'.
[20:48] <jcristau> should that be changed to fd.o bugzilla?
[20:50] <bryce> jcristau: interesting; yes that should be changed
[20:51] <jcristau> the manpage has your copyright so it's not too surprising, just noticed it while looking at getting the latest version in experimental
[21:08] <jcristau> http://people.debian.org/~jcristau/0001-Point-to-freedesktop.org-bugzilla-instead-of-launchp.patch
[21:36] <bryce> jcristau: wow nice.  I didn't know about @PACKAGE_BUGREPORT@ before
[21:37] <jcristau> yeah it's the third argument to AC_INIT
[22:14] <tjaalton> bryce: yeah, I do agree
[22:14] <bryce> working on the 'High CPU' bugs this afternoon
[22:15] <tjaalton> the gnome-madness bug you say?
[22:15] <bryce> it feels very nice to be able to drop bugs as "looks like a client-side application problem to me"
[22:15] <bryce> oh all over the place.  one was an xfce-theme problem (just two themes triggered it)
[22:15] <tjaalton> hehe
[22:16] <bryce> "I notice these two themes do some really intense gradient animation... no idea if that's related..."
[22:16] <bryce> also appears kde was doing monitor polling with xrandr calls every 10 sec at some point too
[22:17] <bryce> http://jakob.petsovits.at/projector-fun
[22:18] <bryce> it drives me crazy that even after people realize the problem was caused by something other than X, they still blame X for their problems ;-)
[22:18] <bryce> silly people
[22:21] <tjaalton> yeah, more work for the cluebat
[22:29] <bryce> tjaalton, btw I pushed out the xorg changes that were sitting in git.  Figured we should get them out for alpha-4 next week
[22:33] <bryce> making bug 294972 master for cpu load issues
[23:01] <tjaalton> bryce: ok, did you push the release commit?-)
[23:01] <bryce> oh yeah
[23:02] <tjaalton> k, our spamfilter must've eaten it
[23:02] <bryce> no I mean, "Oh yeah, <mumble> git <mumble> needs to be committed still..."
[23:02] <tjaalton> hehe
[23:02] <bryce> pushed
[23:03] <tjaalton> thanks
[23:04] <bryce> oh btw, seb128 is thinking about dropping the forced 96 dpi in gnome next week at the sprint
[23:04] <bryce> so we might get more of those "HUGE font" bugs
[23:05] <tjaalton> figures
[23:05] <tjaalton> did I already ask about 'gdm on vt1'?-)
[23:06] <tjaalton> I guess we need a flamewar for jaunty+1 too
[23:06] <bryce> hehe
[23:07] <bryce> we need a section in the release notes titled, "How X will piss you off to no end in this release of Ubuntu"
[23:08] <tjaalton> I've been running X on vt1 since UDS. very few changes needed, gdm and system-services (drop /etc/event.d/tty1)
[23:08] <bryce> we can end it with a link to the Wayland home page
[23:08] <tjaalton> bwaha
[23:09] <tjaalton> "a teaser of what we'll see... in 2017!"
[23:32] <bryce> ok, high cpu bugs done.  I was able to drop x from almost all of them, except a couple that actually were xserver lockups
[23:32] <bryce> ok, lunchtime
[23:35] <tjaalton> whoa, first real nouveau bug
[23:35] <tjaalton> bug 323377
[23:38] <bryce> sweet
[23:46] <bryce> I'll close it
[23:47] <tjaalton> well, even though it's not really supported, it might be nice to see how the driver progresses
[23:48] <bryce> hank you for testing the new -nouveau driver and reporting your finding of a problem.
[23:48] <bryce> However, while we are providing -nouveau for testers to experiment with, we are not yet supporting -nouveau in Ubuntu and will not be following up on this bug at this time.
[23:48] <bryce> It sounds like you have a good lead on finding a solution to this problem associated with lvds detection though, and I would strongly encourage you to contact the upstream developers directly and work with them on finding a solution.
[23:48] <bryce> +T
[23:59] <tjaalton> getting late.. night!


[00:30] <Alcool9000> Hi
[00:30] <Alcool9000> bye
[08:05] <elacheche> Hello akaisora
[08:06] <elacheche> Mornign folks
[08:06] <elacheche> Na3iL marwen_ : o/
[08:09] <akaisora> elacheche: good day!
[08:10] <akaisora> How is it going?
[08:10] <elacheche> Hope it'll be good :)
[08:11] <akaisora> yeah :) good to be positive
[08:26] <Na3iL> Morning guys
[08:34] <elacheche> Hello Na3iL :)
[08:34] <Na3iL> elacheche, how are you today?
[08:38] <elacheche> I need a 3rd coffee Na3iL
[08:40] <akaisora> Na3iL: morning!
[08:41] <akaisora> elacheche: you need a coffee machine next to your laptop xD
[08:46] <elacheche> akaisora: :)
[08:47] <Na3iL> elacheche, I have a mug of coffee next to me, I will send it to you :D
[08:47] <Na3iL> akaisora, good morning, glad to see new faces here :D
[08:47] <Na3iL> You are from Tunis, right?
[08:48] <akaisora> nah Sousse but I work in sousse :-)
[08:48] <akaisora> I work in Tunis *
[08:48] <Na3iL> Ah, good. You will be present during the SFD this year, right?
[08:50] <elacheche> Oh! I see why you asked about my company akaisora :)
[08:50] <elacheche> the company I work for name*
[08:50] <akaisora> elacheche: do you know Marwen Chouri?
[08:50] <akaisora> he had an internship in your company
[08:50]  * elacheche needs and other coffee, so it's up to you to decode his weird sentences..
[08:51]  * akaisora can handle it :D
[08:52] <elacheche> I gogoled the name, I remember the face..
[08:52] <akaisora> anyway xD i'm his cousin
[08:52] <akaisora> the name is Soulaymen Chouri
[08:52] <elacheche> Nice to meet you :)
[08:53] <akaisora> nice to meet you too ^^
[08:54] <elacheche> I didn't had direct cotnact, with my poor memory I can really remember people only after the 10th direct contact at least x(
[08:54] <elacheche> didnt had direct contact with him
[09:20] <akaisora> elacheche: I see ^^
[09:21] <akaisora> I just recalled that we are friends on linkedin as well :D
[09:24] <elacheche> Oh! Yes we are x)
[09:25] <elacheche> I like when associate niknames with real names and faces.. that helps my memory
[09:30] <akaisora> Yeah xD
[09:30] <akaisora> add more coffee and it willhelp even more
[09:30] <akaisora> xD
[09:48] <elacheche> a:)
[10:17] <akaisora> Na3iL: when is the SFD?
[10:19] <elacheche> Next month akaisora
[10:19] <elacheche> @IssatSo
[10:19] <Na3iL> 18 october if I am not mistaken
[10:19] <Na3iL> right elacheche ?
[10:19] <akaisora> my university? XDDDD
[10:20] <elacheche> Don't know Na3iL.. That Clibre's meeting is holding too much actions and news :/
[10:21] <Na3iL> okay
[10:24] <elacheche> Let's ping them on that thread on the ML? :D
[10:31] <Na3iL> Yep


[05:24] <pitti> Good morning everyone
[06:38] <DanChapman> Good Morning
[06:38] <elfy> morning DanChapman
[06:43] <pitti> hey DanChapman, hey elfy
[06:43] <elfy> hi pitti - and congrats on the Tech Board thing
[06:43] <pitti> hey elfy; thanks (have been doing TB for quite a while :) )
[06:44] <elfy> yep - I know that too :)
[06:44] <elfy> I might hide away - but after 7 years of it I sort of have a good idea of what's going on lol
[06:45] <elfy> though I did venture out of the shadow of the forums to the community council
[06:49] <DanChapman> Hey elfy and pitti o/
[06:53] <DanChapman> pitti while i remember bug 1261685 I managed to break it down into a small test case which I attached to a comment do you need a new bug for it as that one is fix released?, I didn't have very much success in tracing it any further
[06:54] <pitti> DanChapman: indeed, thanks for working on a reproducer; I'm catching up with bug mail, I just opened that one :)
[06:54] <pitti> DanChapman: new bug report would be nice
[06:54] <pitti> DanChapman: I'll try your reproducer
[06:55] <DanChapman> pitti, excellent thanks, i'll get a new bug report done for it
[09:43] <rvr> Happy new year to everyone!
[09:51] <pitti> DanChapman: I indeed get a crash with just http://paste.ubuntu.com/6708207/, always at iteration 57
[09:51] <pitti> DanChapman: but it's not quite exactly the same crash as in bug 1261685 as that part of the code was changed
[09:57] <DanChapman> pitti, thats strange how it's always iteration 57. Your right, sorry about that, I will update the bug report
[09:58] <pitti> DanChapman: thanks for the new bug report, I updated/assigned it
[09:58] <pitti> DanChapman: I'll figure out how to debug it from here, many thanks for the reproducer!
[10:06] <DanChapman> pitti no problem :-)
[10:17] <pitti> DanChapman: meh, I can't actually get it to crash (no core file, nothing in dmesg, etc.); tough..
[10:17] <pitti> I clearly get the graying out/org.freedesktop.DBus.Error.NoReply though
[10:27] <pitti> DanChapman: are you sure it crashes with the reproducer? i. e. do you get an apport .crash file or something? if so, would you mind putting that somewhere?
[10:31] <pitti> DanChapman: err, WTF -- with teh g_warning -> g_debug fix for bug 1250452 it suddenly works
[10:33] <DanChapman> pitti, yeah I hit a brick wall trying to find it. It's a really tricky one, I couldn't get a crash file either from it
[10:33] <DanChapman> pitti lol really??? o-O
[10:33] <pitti> DanChapman: running with your script now
[10:34] <pitti> it's like the spewage overflows some of autopilot's stdout/err capturing buffers, and that might need some time to catch up during which the d-bus time out happens
[10:38] <pitti> DanChapman: so you didn't actually see it crash, but you saw ubiuity (or whatever) gray out and hang, and the DBus.NoReply error?
[10:38] <pitti> $ (D=`pwd`; cd tests/autopilot; GTK_PATH=$D/lib autopilot run -v tests.test_force_segfault)
[10:38] <pitti> Ran 4 tests in 186.526s
[10:38] <pitti> OK
[10:38] <pitti> DanChapman: ^ that's your script
[10:38] <pitti> (with trunk)
[10:42] <pitti> DanChapman: bug updated, would appreciate a confirmation/difference to what you see
[10:44] <DanChapman> pitti I haven't got it to crash locally but yes ubiquity was doing the same with greying out in exactly the same way polling on the progressbar then getting the dbus, I pushed up patch to the tests to see on jenkins  with the 0.3 second sleep, it's been somewhat better but the odd test  1 or 2 a day are still failing with it but in general it helped
[10:45] <DanChapman> pitti sure i'll give it a run now :-)
[10:45] <pitti> DanChapman: want an amd64 libautopilot.so to test? (with the g_debug change)
[10:45] <pitti> or a .deb?
[10:46] <DanChapman> pitti, a .so would be handy :-)
[10:47] <pitti> DanChapman: http://people.canonical.com/~pitti/tmp/libautopilot.so
[10:47] <pitti> DanChapman: or http://people.canonical.com/~pitti/tmp/libautopilot-gtk_1.4+14.04.20131218-0ubuntu1_amd64.deb if that's more convenient
[10:47] <pitti> (just a straight bzr bd -- -b from trunk)
[10:47] <DanChapman> thanks :-)
[10:51] <pitti> DanChapman: I committed the new test to a branch; I'll wait for your testing results for submitting, though
[11:01] <davmor2> Morning all
[11:16] <DanChapman> pitti all seems to be good from this end. +1 from me :-)
[11:16] <pitti> DanChapman: nice!
[11:20] <pitti> DanChapman: great, I'll land the new test case and then ask for getting trunk into trusty
[11:20] <pitti> DanChapman: many thanks for confirming!
[11:21] <DanChapman> pitti, No problem, thanks for the efficient fix :-)
[12:05] <pitti> jibel: does run-adt-test currently work for you? first time I try it since the holidays (with -sUl), it hangs here
[12:08] <pitti> it waits for /dev/vdc (the pristine VM image) which apparently never comes up
[12:21] <jibel> pitti, it is not the first thing I tried this morning, but I'll check.
[12:35] <jibel> pitti, (qemu) pci_add: command not found
[12:35] <jibel> (qemu) pci_add auto storage file=/dev/shm/adt/trusty-amd64-tabix-20140107_133008.FoLnAX.img,if=virtio,index=2,readonly
[12:35] <jibel> unknown command: 'pci_add'
[12:36] <jibel> ^
[12:48] <jibel> pitti, in 1.7.0+dfsg-2ubuntu5   * Drop d/p/fix-pci-add: upstream does not intend for pci_add to be
[12:49] <jibel>     supported any longer.
[12:49] <jibel> replaced by device_add
[12:49] <jibel> https://bugzilla.redhat.com/show_bug.cgi?id=602590
[12:55] <pitti> jibel: ah, many thanks; I'll adjust
[13:11] <pitti> jibel: meh; there's very little documentation about that, will take me a while; if this blocks the CI ADT tests, I can also just comment it out for now
[13:12] <jibel> pitti, I cannot find much documentation either and syntax is non-obvious. I don't think it block adt tests, the change is only in trusty.
[13:13] <pitti> jibel: ah, in CI we run this from precise/raring, right?
[13:13] <jibel> pitti, yes, precise and saucy
[13:15] <jibel> and errors are not better than documentation: Can't hot-add drive to type 7
[13:41] <jibel> pitti, I can hot plug an scsi disk and get a /dev/sda but no luck with virtio
[13:41] <pitti> jibel: I pinged hallyn in #u-devel about it, maybe he knows
[13:42] <jibel> pitti, good, thanks
[14:00] <jibel> pitti, just FTR, here are the commands to hotplug an scsi disk. but if I replace if=none with virtio it fails with "can't hot-add drive to type 7"
[14:00] <jibel> I hope there is something simpler
[14:02] <jibel> pitti, with the link http://paste.ubuntu.com/6709139/ :)
[14:02] <pitti> jibel: merci
[14:11] <rbasak> pitti: "Drop --override-control option". Hey, I used that!
[14:16] <pitti> rbasak: oha; OOI, what's the use case?
[14:17] <pitti> rbasak: we can certainly bring it back, but I didn't know anyone who used it, and it seems rather strange (and adds unnecessary complexity)
[14:17] <rbasak> Right now, I wanted to enable some tests that were disabled in the archive due to breaks-testbed not implemented. I think I have used it in the past for other things, though.
[14:17] <rbasak> I'm trying to work around, but I can't seem to get --unbuilt-tree to work.
[14:18] <pitti> rbasak: how does it fail? (it even has test coverage now)
[14:19] <rbasak> cp: cannot open ‘/tmp/adt-downtmp/ubtree0-ubtree/./debian/changelog’ for reading: Permission denied
[14:19] <rbasak> I'm not sure if that's an issue with adt-virt-lxc or something I'm doing wrong.
[14:19] <rbasak> I'm still looking at it.
[14:28] <rbasak> pitti: I think it's a regression, though haven't spent time trying to confirm it.+
[14:28] <rbasak> pitti: adt-virt-lxc defaults to suggested-user=ubuntu, and you have to say --gain-root=sudo to adt-run, so that it does "debian/rules binary" with sudo.
[14:29] <rbasak> pitti: adt-run picks up on that and does, effectively, --user=ubuntu as default in that case.
[14:30] <pitti> rbasak: right; that's similar how schroot behaves now (since the last release)
[14:30] <rbasak> pitti: http://paste.ubuntu.com/6709295/
[14:30] <rbasak> pitti: I think it then can't copy from $origpwd because that isn't readable by the ubuntu user.
[14:31] <pitti> rbasak: ah, I only tried it with schroot, where the suggested user is the same as the calling one (which is different with lxc)
[14:32] <rbasak> pitti: btw, I also needed a workaround for adt-virt-lxc and the latest lxc in trusty. The wait implementation inside adt-virt-lxc assumes that it can see inside the guest tree from the host as a normal user, but latest lxc sets /var/lib/lxc o-a. So I set it to 755 as a quick workaround.
[14:35] <pitti> rbasak: indeed, "lxc-ls" is now also broken due to that
[14:35] <pitti> was that a deliberate change, or a bug?
[14:35] <rbasak> I'm not sure, but I presume "sudo lxc-ls" is required.
[14:35] <pitti> it wasn't until a few weeks ago
[14:36] <rbasak> OK, so I mean is *now* required :)
[14:36] <pitti> did someone complain that they have super-s3kr1t container names which are never running? (because you can see their names in ps when they are..)
[14:36] <pitti> stgraber: ^
[14:39] <stgraber> pitti: it's a deliberate security change
[14:40] <stgraber> without that, any user would be able to execute a setuid binary from any of the container's rootfs or cache
[14:40] <pitti> stgraber: how so?
[14:40] <pitti> stgraber: I understand making /var/lib/lxc/<container> 0700
[14:40] <pitti> but /var/lib/lxc itself?
[14:42] <stgraber> we indeed could have done it on /var/cache/lxc and /var/lib/lxc/*, changing LXC so that containers dirs are always created 0700 instead of respecting the umask, but /var/lib/lxc + /var/cache/lxc was just easier
[14:42] <stgraber> the obvious downside is that you can't list containers as non-root now
[14:42] <stgraber> but at the same time, lxc-ls as non-root won't be listing /var/lib/lxc in 1.0 anyway
[14:42] <stgraber> (as we have unprivileged containers and lxc-ls lists ~/.local/share/lxc/ now)
[15:40] <senan> DanChapman,balloons, Hello Good Eve!!!
[15:40] <balloons> good eve senan
[15:46] <DanChapman> senan hey there, sorry i missed your messages over the holidays
[15:51] <senan> DanChapman, Its ok dan
[15:57] <senan> DanChapman, can you check the issue I mentioned
[16:11] <DanChapman> senan, I have looked into testing the file chooser dialog in general, what you need to do is select_single('GtkTreeView', BuilderName=u'') this gives you the 'Places' treeview then you need to select_single the GtkTreeViewAccessible with the same globalRect as your current selected treeview, from the treeview accessible object you will be able to select any of the treeview items  with .select_single('GtkCellTextAccessible', accessible_name='
[16:11] <DanChapman> item label value')
[16:13] <DanChapman> senan, do you need an example?
[16:16] <senan> DanChapman, Yes
[16:31] <senan> DanChapman, Did you mean the browse_files_tree_view ?
[16:39] <senan> DanChapman, Can you please give me an example
[16:39] <DanChapman> senan just sorting it now :-)
[16:40] <senan> ok dan
[16:42] <xnox> mhall119: balloons: can you please approve me to https://launchpad.net/~ubuntu-touch-coreapps-test-writers/+members I'm helping out on enabling all core apps tests pass in the emulator?
[16:42] <xnox> into that is.
[16:42] <balloons> xnox, sure thing
[16:43] <balloons> done
[16:44] <DanChapman> senan http://paste.ubuntu.com/6709963/ use this all you have to do is pass the treeview object and the treeitem label name
[16:45] <DanChapman> senan you want the other treeview and not browse_files_tree_view. The one with no name
[16:46] <senan> DanChapman, under PlacesSidebar right ?
[16:51] <xnox> balloons: thanks!~
[16:56] <senan> DanChapman, Is it possible to directly access GtkTextCellAccessible ?
[16:58] <DanChapman> senan it is but you have to be sure its coming from the treeview you want, hence you need to match the GtkTreeViewAccessible.globalRect with the treeview then select it from there to be sure your in the correct treeview
[16:59] <senan> DanChapman, So first I need to get the TreeView object under PlacesSidebar and pass it to the function  you just created
[17:08] <DanChapman> senan yes so with the treeview object do self.get_tree_item(treeview, 'Computer') and you will get the 'Computer' tree item which you can then click
[17:16] <balloons> xnox, I need to try out your autopilot testing with the emulator :-)
[17:16] <xnox> balloons: well instructions on the bug reports and on ubuntu-phone mailing list
[17:16] <DanChapman> balloons, howdy can you just confirm a bug for me if you right click the text area of gnome-calculator is the menu over sized?
[17:17] <balloons> DanChapman, yes it is.. wild
[17:17] <balloons> DanChapman, if you right click the numberpad first, then the textarea, it works fine
[17:19] <DanChapman> balloons, thanks. Your right it does!, it seems it's only when the text cursor is visible
[17:25] <senan> DanChapman, It worked!!! Thanks
[17:25] <DanChapman> senan YAY!! your welcome :-)
[17:28] <senan> DanChapman, One more issue...when launching Scan Remote Folder
[17:29] <senan> DanChapman, its launching NautilusConnectServer Dialog
[17:29] <senan> DanChapman, I believe its a separate process
[17:38] <senan> DanChapman, NautilusConnectServerDialog, I am not able to catch it
[17:43] <senan> Good Night All!!!
[17:46] <DanChapman> senan i wouldn't worry about scanning remote repositories as it's generally not recommended to depend on external connections
[17:46] <DanChapman> good night senan


[04:11] <KDESupporter> Hello! ~ Please, I have a question: In terms of software updates, what the difference between Kubuntu (with the backports enabled) and "KDE Neon". Logically speaking, Kubuntu with the backports enabled should mean that we are getting the latest KDE software. What's your opinion?
[10:39] <BluesKaj> 'Morning all
[10:42] <jubo2_> Hello.
[10:42] <jubo2_> Seems fi.archive.ubuntu.com is not quite up
[10:43] <jubo2_> Is there a simple way to change what mirror the machine is connecting to
[10:43] <lordievader> jubo2_: Change /etc/apt/sources.list
[10:44] <jubo2_> lordievader: so like change fi to sv ?
[10:45] <lordievader> Or just `archive.u.c` which is the default, I think, let the load balancer decide.
[10:47] <jubo2_> I switched to Sweden
[10:48] <jubo2_> seems to run fine now
[10:48] <BluesKaj> I use muon and change the mirrors there, it's eaier
[10:48] <BluesKaj> easier
[13:46] <Pascal_> y[]
[16:29] <p4t> Hello everybody
[16:29] <p4t> I've a problem with suspension, could someone help me?
[16:34] <p4t> Nobody can?
[16:37] <Aison0> maybe you ask your question as understandable as possible and then you may get some answer now or later.
[16:38] <Aison0> meta-questions do not help that much ;)
[16:38] <p4t> I've not changed powersaving settings.
[16:40] <p4t> Powersave settings are default one. I have suspension (save on ram) afer 10 min of no user interaction. When it suspends, after a bit, it wakes up alone (like if someone has touched mouse or keyboard), then it goes to sleep, then it get up again, and on and on. When I close the lid everything works perfect, it's just when the lid is open (i've also heard notification sound when it should be in suspension)
[19:01] <EvilRoey> bash question, forgot, how do I check to see if an environment label exists and is currently set to nothing ?
[19:28] <BluesKaj> EvilRoey, why not ask in #bash ?
[19:29] <EvilRoey> pretentiasaurs
[19:29] <EvilRoey> nah I was too embarrassed ;)
[19:29] <EvilRoey> because I'm a regular in there anyway
[19:29] <EvilRoey> heh
[19:43] <BluesKaj> we all forget stuff, don't be afraito ask when something slips your mind
[19:47] <BluesKaj> guess the bash chat is full of geks and nerds with attitude
[19:47] <BluesKaj> geeks even
[21:35] <mgolden_> EvilRoey: printenv
[21:52] <dunocz> hi


[04:36] <jam> morning all
[08:14] <mup> PR operator#319 opened: ops: get version from git <Created by chipaca> <https://github.com/canonical/operator/pull/319>
[08:17] <mup> Issue operator#313 closed: If ops is installed, the test run picks up the wrong one <Created by chipaca> <Closed by chipaca> <https://github.com/canonical/operator/issues/313>
[08:17] <mup> PR operator#314 closed: test_main: set up PYTHONPATH so the sub-process picks up this ops <Created by chipaca> <Merged by chipaca> <https://github.com/canonical/operator/pull/314>
[08:18] <jam> morning Chipaca
[08:18] <Chipaca> jam: moin moin :)
[08:22] <jam> Chipaca, I'd like to chat a bit about serialization of StoredState, we can start on IRC and move from there if you feel it is too involved
[08:22] <Chipaca> jam: sure
[08:23] <jam> Chipaca, so I'm pretty sure you're aware that we currently use a pickle into a sqlite database for all StoredState content
[08:23] <Chipaca> yep
[08:24] <jam> Juju will accept key=value pairs for 'state-set/get' and can take that 'state-set' as 'key=value' on the CLI or as YAML key:value from --file  (which can be '-' for stdin)
[08:24] <jam> The current spike was done by putting the pickle bytes into base64 and then writing that as the value
[08:24] <Chipaca> mhmm
[08:25] <jam> it is a pretty obtuse way to understand what your state is, if you ever wanted to do "juju run --unit u/0 state-get"
[08:25] <jam> foo: gANLCi4=
[08:26] <jam> I have some concerns about pickle support, though AIUI since we force it to be simple types with a pass by Marshal
[08:26] <jam> there shouldn't be too much trouble if you wrote a pickle with python 3.7 and read it with python 3.8
[08:26] <jam> (say you did a do-release-upgrade on the machine that was running the charm, and it is now running a different version of python)
[08:27] <Chipaca> pickle's fine with that, yes
[08:27] <jam> Chipaca, it doesn't *feel* like a 'stable format to keep your state in over time"
[08:27] <Chipaca> eh, it's stable enough (you can use 3.8 to load a pickle from 2.2 for example)
[08:27] <Chipaca> but
[08:27] <Chipaca> it's not very approachable
[08:27] <Chipaca> and that might be a bigger issue :)
[08:28] <Chipaca> jam: given that they're simple types, wouldn't yaml also work for us?
[08:28] <jam> Chipaca, so the one caveat is that yaml or json as the actual payload loses the type for set vs list
[08:29] <jam> Also, JSON keys are strictly strings IIRC, so you can't have {0: 'foo'}
[08:29] <jam> I think YAML supports non-string keys
[08:29] <Chipaca> are yaml keys also -- ah
[08:29] <Chipaca> hmm
[08:30] <Chipaca> jam: and python?
[08:30] <jam> Python has the nice behavior that json.dumps({0: 'foo'}) => '{"0": "foo"}'
[08:30] <jam> iow, it silently casts your numeric keys into string keys
[08:30] <Chipaca> no i mean, make it a python literal
[08:31] <Chipaca> and use ast.literal_eval to bring it back
[08:31] <jam> $ python3 -c "import json; print(json.dumps({'0': 'foo', 0: 'bar'}))"
[08:31] <jam> {"0": "foo", "0": "bar"}
[08:32] <jam> Chipaca, what is the cleanest way to turn a nested dict into a literal? just repr() ?
[08:32] <Chipaca> yep
[08:32] <Chipaca> bah, dicts you can str because repr is str there :) but yes, repr
[08:32] <jam> Chipaca, and... there isn't much in the way of versioning, so we have a way to change our mind about how we want to store the content.
[08:33] <Chipaca> s/have/don't have/ ?
[08:33] <Chipaca> we could add that ourselves, make the first byte of the value be the version?
[08:34] <Chipaca> does juju care at all what we dump in there? what further processing does it do on it?
[08:34] <jam> >>> repr({'0': [1,2,3], 0: set(['a', 'b', 'c'])})
[08:34] <jam> "{'0': [1, 2, 3], 0: {'b', 'c', 'a'}}"
[08:34] <jam> >>> ast.literal_eval("{'0': [1, 2, 3], 0: {'b', 'c', 'a'}}")
[08:34] <jam> {'0': [1, 2, 3], 0: {'b', 'c', 'a'}}
[08:34] <jam> Chipaca, so Juju *should* just round trip the content we give it.
[08:34] <Chipaca> yeah, sets have literals too ;)
[08:35] <jam> Chipaca, yeah, I always use set() because the empty set doesn't have another literal
[08:35] <Chipaca> ah, yeah
[08:36] <jam> since {} would be ambiguous. I'm also not a huge fan of "did you notice there were no :"
[08:36] <Chipaca> and it might fail here :-/
[08:36] <Chipaca> because 'set()' isn't a literal
[08:36] <jam> >>> ast.literal_eval(repr({'0': [1,2,3], 0: set()}))
[08:36] <jam> Traceback (most recent call last):
[08:36] <jam>   File "<stdin>", line 1, in <module>
[08:36] <jam>   File "/usr/lib/python3.6/ast.py", line 85, in literal_eval
[08:36] <jam>     return _convert(node_or_string)
[08:36] <jam>   File "/usr/lib/python3.6/ast.py", line 66, in _convert
[08:36] <jam>     in zip(node.keys, node.values))
[08:36] <jam>   File "/usr/lib/python3.6/ast.py", line 65, in <genexpr>
[08:36] <jam>     return dict((_convert(k), _convert(v)) for k, v
[08:36] <jam>   File "/usr/lib/python3.6/ast.py", line 84, in _convert
[08:36] <jam>     raise ValueError('malformed node or string: ' + repr(node))
[08:36] <jam> ValueError: malformed node or string: <_ast.Call object at 0x7f2b34d35160>
[08:36] <jam> Chipaca, indeed, it does fail :9
[08:36] <jam> :(
[08:37] <Chipaca> so close
[08:37] <jam> it is also true that we are running pickle.loads() on unknown data
[08:38] <jam> yes we write it from things that are 'safe', but we are still running the engine on data that we're reading back from 'outside'
[08:38] <jam> Chipaca, code layering wise, it is also quite hard to not use pickle, because Framework is the part that decides pickle, while Storage decides to write it to the DB
[08:39] <Chipaca> yeah
[08:39] <jam> (Framework.save_snapshot is where the marshal.dumps check and pickle.dumps is done)
[08:39] <Chipaca> i think that could use a refactor, but separately
[08:39] <jam> Chipaca, though again, we can just move that down into the SQLiteSnapshot layer
[08:39] <jam> SQLiteStorage
[08:40] <jam> Chipaca, indeed. snapshot() from the actual objects that people implement is still defined as a dict so we're ok there
[08:40] <Chipaca> jam: do we care about the spike being forwards-compatible?
[08:40] <Chipaca> i guess we do but just checking :)
[08:40] <jam> Chipaca, as in that the current version of the code can read the content written by future versions?
[08:41] <Chipaca> as in the state written by the spike be readable by future versions
[08:41] <jam> or if it can't read it, fail gracefully
[08:41] <jam> Chipaca, we don't care about the current spike, because it was just to show proof-of-concept. no charms that I'm aware of are using it.
[08:41] <Chipaca> jam: ah so the spike isn't what we'd put in 0.7
[08:42] <jam> Chipaca, correct. I'm using it as a starting point, but taking the time to carefully structure things and make sure it is the serialization that we're happy with.
[08:42] <Chipaca> ok
[08:42] <jam> I'd really rather use something like json/yaml and have it be inspectable by humans.
[08:42] <Chipaca> so for the initial spike, pickle is fine then :)
[08:42] <jam> I think you missed a comment by Stub that people are writing sqlite3 hacks to unpickle the snapshot fields to try to figure out what is going on.
[08:43] <Chipaca> i've seen that in bugs and etc, yes
[08:43] <Chipaca> which seems obvious to me -- if i were trying to figure out what was going wrong, i'd want to look at anything i could too
[08:43] <jam> Chipaca, and we can write a common helper to make it easier to inspect that state
[08:44] <jam> Chipaca, but ideally it would be less opaque to start with.
[08:44] <jam> Could we make the statement "sets aren't allowed" and just go with JSON ?
[08:44] <Chipaca> json also mangles numbers
[08:44] <jam> ah right
[08:44] <jam> yeah, I hate that part.
[08:44] <Chipaca> so it's my least favourite for this :)
[08:44] <jam> if it *failed* I might be ok with it.
[08:44] <jam> the fact that it silently corrupts makes it out
[08:45] <jam> see my above comment where you can json.dumps() and get the integer and string keys colliding with no error.
[08:45] <Chipaca> we can come up with special handling for empty sets and work with that, also
[08:45] <stub> I'd actually assumed sets were not allowed by 'simple types only', like json and yaml and toml and everything else people are used to now days.
[08:45] <davigar15> Hello!
[08:45] <davigar15> ERROR juju.worker.uniter.operation hook "start" (via explicit, bespoke hook script) failed: exit status 1
[08:45] <stub> Recommend feeding the CLI tool using the --yaml argument to avoid CLI command length limitations and encoding and locale issues
[08:45] <davigar15> I'm getting that error in k8s charms in 2.8.1
[08:46] <davigar15> Chipaca: any ideas?
[08:46] <Chipaca> davigar15: what operator version?
[08:46] <davigar15> latest
[08:46] <Chipaca> davigar15: can we see the debug logs?
[08:46] <davigar15> yes
[08:46] <jam> stub, yeah, --file is currently the way that I'm interacting with state-set.
[08:46] <jam> davi
[08:47] <jam> davigar15, I'd start with "juju model-config logging-config=DEBUG" and "juju debug-log" to get more information about what is going wrong.
[08:47] <stub> jam: Maybe this time we can use = and . in our keys :)
[08:47] <Chipaca> we _could_ restrict what you can put in state even further, for this feature
[08:47] <Chipaca> or, we could special-handle empty sets :)
[08:48] <Chipaca> (or sets in general!)
[08:48] <davigar15> oooh, good trick. Need to debug it :-)
[08:49] <Chipaca> jam: yaml.safe_load(yaml.dump(set()))
[08:49] <Chipaca> jam: → set()
[08:50] <Chipaca> yaml.safe_load(yaml.dump({'0': [1,2,3], 0: set(['a', 'b', 'c'])})) → {0: {'a', 'b', 'c'}, '0': [1, 2, 3]}
[08:51] <Chipaca> we'd have to check if the !!set annotations require a particular pyyaml version
[08:52] <davigar15> application-zookeeper-k8s: 10:52:25 DEBUG unit.zookeeper-k8s/2.start     raise TypeError(
[08:52] <davigar15> application-zookeeper-k8s: 10:52:25 DEBUG unit.zookeeper-k8s/2.start TypeError: observer methods must now be explicitly provided; please replace observe(self.on.config_changed, self) with e.g. observe(self.on.config_changed, self._on_config_changed)
[08:52] <davigar15> There is it
[08:53] <davigar15> It has to be explicit. I have self instead
[08:53] <davigar15> :-)
[08:53] <davigar15> thanks
[08:53] <Chipaca> jam: but it works in 3.11 (xenial) and 3.12 (bionic) at least
[08:53] <jam> Chipaca, ^^ that looks like the "catch exceptions and log at higher than DEBUG" :)
[08:53] <Chipaca> davigar15: :) sorry we broke your charm, glad we were trying to tell you about it at least :)
[08:54] <Chipaca> jam: yep
[08:54] <Chipaca> did we have an issue for that? i should do that one next
[08:54] <jam> we do
[08:54] <davigar15> It's okay! nothing in production yet hahaha
[08:54] <jam> Chipaca, #289
[08:54] <mup> Issue #289: hook exception logged at DEBUG <Created by jetpackdanger> <https://github.com/canonical/operator/issues/289>
[08:54] <Chipaca> perfect
[08:54] <Chipaca> jam: any reason not to go the yaml route (after the refactor to move sqlite decision out of framework) ?
[08:55] <jam> Chipaca, so I've been told historically that YAML is good if a human is going to edit it, but it has enough edge cases it doesn't make a great machine<=>machine format.
[08:55] <stub> I think you will need to keep sqlite if you want Juju 2.7 compatibility
[08:55] <jam> (things like base 60 numbers)
[08:55] <jam> stub, yes, it isn't removing sqlite
[08:56] <jam> it is adding an alternative when it is available
[08:56] <Chipaca> yeah i bungled and meant 'pickle' there
[08:56] <jam> but what do we want *that* to look like
[08:56] <Chipaca> framework is pickoing, storage is sqliting
[08:56] <Chipaca> pickling
[08:56]  * Chipaca used to be able to type
[08:56] <jam> Chipaca, I think I'll want to keep the marshal() check, but move the pickling into Storage and out of JujuStorage and try using YAML there.
[08:57] <jam> Chipaca, it kind of has to happen at the same time, since the interface to the Storage changes from taking a bytes to taking a dict
[08:57] <jam> but it shouldn't be very invasive.
[08:58] <Chipaca> jam: so what _is_ a good machine ⇔ machine format?
[08:58] <stub> With the marshal check, the yaml should always be bog simple except for sets (and maybe other builtin Python types I can't think of right now), and seems fine to me as machine <-> machine
[08:58] <jam> well, the recommendation was JSON, but for obvious reasons that is out. I don't think pickle/python ast fall into that category. XML is overbroad
[08:59] <jam> stub, Chipaca certainly YAML is my top pick right now
[08:59] <Chipaca> base64 of a pickled xml ast dump \o/
[08:59]  * Chipaca hides
[08:59] <stub> eval(repr(blob))
[08:59] <Chipaca> exec*
[08:59] <Chipaca> ]:-)
[08:59] <Chipaca> wait is exec eval now
[09:00]  * Chipaca checks
[09:00] <Chipaca> nope exec is still the right one for maximum pawnage
[09:01] <Chipaca> anyway, sorry for the silliness :)
[09:01]  * Chipaca is only a little bit sorry
[09:01] <Chipaca> hush you
[09:01] <jam> Chipaca, if only there was some way to get "sudo" in there
[09:02] <Chipaca> jam: charms run as root ¯\_(ツ)_/¯
[09:06] <jam> Chipaca, so one nice property is that refactoring is actually quite localized
[09:07] <jam> Chipaca, what is the type annotation for "snapshot". Currently we only really ever use 'dict' or None, but it has so far been anything that python can pickle
[09:08] <jam> is that just "object" ?
[09:09] <Chipaca> jam: Any ?
[09:09] <Chipaca> it's not strictly Any, but I don't think there's something better
[09:10] <Chipaca> OTOH maybe we should enforce it being dict-or-None
[09:10] <Chipaca> anything else isn't going to be extensible enough for long-term
[09:10] <davigar15> Chipaca: Why could my charm be in wating for container, without giving any errors?
[09:11] <Chipaca> 'waiting for container' sounds like a juju thing to me :)
[09:11] <Chipaca> ie not yet the charm
[09:13] <Chipaca> jam: OTOH you *could* spell it all out
[09:14] <Chipaca> as in, Union[int, float, … ]
[09:15] <jam> Chipaca, so we do have tests that snapshot() -> str and 'def snapshot(self): return self.value' where value was passed in to .emit(value)
[09:15] <jam> (where in the test value is only ever a string)
[09:18] <Chipaca> and it's probably overly opinionated for a framework :)
[09:18] <Chipaca> i mean the 'always use a dict' thing
[09:21] <jam> Chipaca, well, dict or None would be acceptable IMO, and we are little if not opinionated :)
[09:21] <jam> Chipaca, if our review of people's code would always be "you really should use a dict" then we should push that a bit harder, I think.
[09:22] <mup> PR operator#320 opened: ops/framework.py: Move pickle into Storage <Created by jameinel> <https://github.com/canonical/operator/pull/320>
[09:24] <davigar15> Chipaca: happening with juju stable version... I'm going to check my charm.
[09:26] <davigar15> Can't see anything wrong... https://pastebin.canonical.com/p/BMqcdkT6fN/
[09:29] <Chipaca> davigar15: what does the debug log say
[09:29] <davigar15> juju model-config logging-config=DEBUG
[09:29] <davigar15> ERROR config value expected '=', found "DEBUG"
[09:29] <davigar15> haha
[09:30] <jam> that exact line worked here
[09:31] <jam> you could also do: juju model-config "logging-config=<root>=DEBUG"
[09:31] <jam> which is the more explicit version
[09:31] <jam> (that allows you to specify each module separately)
[09:31] <jam> davigar15, though your particular statement "waiting for container", I believe, is created by Juju
[09:32] <jam> (if a charm sets a pod spec, and otherwise goes into Active, Juju sets the state to 'waiting for container' until the pod has started)
[09:32] <jam> davigar15, https://discourse.juju.is/t/how-to-avoid-the-waiting-for-container-message/1369/3 might help?
[09:34] <jam> specifically https://discourse.juju.is/t/how-to-avoid-the-waiting-for-container-message/1369/6
[09:35] <davigar15> https://pastebin.canonical.com/p/CxPhPygZb4/
[09:35] <davigar15> $ microk8s.kubectl -n zk get pods
[09:35] <davigar15> NAME                             READY   STATUS    RESTARTS   AGE
[09:35] <davigar15> modeloperator-658686f765-cfsr6   1/1     Running   0          2m59s
[09:35] <davigar15> zookeeper-k8s-operator-0         1/1     Running   0          2m11s
[09:35] <davigar15> But the application pods are not even created
[09:37] <jam> davigar15, so offhand your charm seems to be missing a self.state.set_default(spec=None) as on_config_changed introspects self.state.spec directly
[09:38] <davigar15> create Pod zookeeper-k8s-0 in StatefulSet zookeeper-k8s failed error: Pod "zookeeper-k8s-0" is invalid: spec.containers[0].ports[2].name: Invalid value: "leader-election-port": must be no more than 15 characters
[09:38] <davigar15> found
[09:38] <davigar15> haha
[09:38] <jam> (I don't think this the problem here, as it means hitting config_changed without start, which will happen with 2.8)
[09:39] <jam> davigar15, where did you find that? I don't see it in your pastebin
[09:55] <Chipaca> it's one of those no-rest-for-the-wicked days
[09:56] <Chipaca> taking a breka now and getting the lunch sorted because then i'll be eating in meetings
[11:01] <facubatista> Muy buenos días a todos!
[11:04] <davigar15> Chipaca: how can I get the number of ensured units with the op framework
[11:08] <jam> davigar15, is that len(self.get_relation(PEER_RELATION).units)
[11:08] <jam> or do you need the count before they are actually started?
[11:09] <davigar15> good question
[11:09] <davigar15> I think I need it before
[11:16] <jam> https://github.com/canonical/operator/issues/165 is about possibly having the framework expose the count (reading it from goal-state), but that hasn't been implemented, so understanding your use case/adding it to that issue is useful
[11:16] <jam> davigar15, ^^
[12:05] <Chipaca> facubatista: https://github.com/canonical/operator/releases/tag/0.6.0
[12:05] <facubatista> Chipaca, wonderful
[13:12] <Chipaca> facundo__: note #294 is gtg
[13:12] <mup> PR #294: Log when a served breakpoint is not really activated because of name mismatch <Created by facundobatista> <https://github.com/canonical/operator/pull/294>
[13:12] <facundo__> Chipaca, ack
[13:13]  * facundo__ will restart the router to see if all these disconnections stop
[13:13] <jam> Chipaca, and for issue #21, if it is a script, and we set JUJU_DISPATCH_PATH it will try to reinvoke hooks/install but that will notice the OPERATOR_DISPATCH env and exit early, right?
[13:13] <mup> PR #21: Persist stored state before framework commit <Created by dshcherb> <Merged by niemeyer> <https://github.com/canonical/operator/pull/21>
[13:14] <Chipaca> jam: indeed
[13:14] <Chipaca> charmcraft#21, mup m'dear
[13:14] <mup> Issue charmcraft#21: Event charm.py not defined <Created by knkski> <https://github.com/canonical/charmcraft/issues/21>
[13:14] <Chipaca> facundo__: want me to fix this ^? i can do that right now
[13:15] <facundo__> Chipaca, be my guest
[13:19] <jam> Chipaca, btw, if you want easier ways to get to source code from a git submodule you can open the '.gitmodules' file which contains the URL that git will use to find the revision
[13:19] <jam> https://git.launchpad.net/charm-k8s-mattermost/tree/.gitmodules
[13:19] <Chipaca> jam: 👍
[13:20] <jam> github does that for you, eg if you look at this: https://github.com/jameinel/ubuntu-lite/pull/2/files#diff-b1d90847e9ac9d08a6205ad8f09fd5a9L14 it has a direct link to the Operator code
[13:20] <mup> PR jameinel/ubuntu-lite#2: Operator <Created by jameinel> <https://github.com/jameinel/ubuntu-lite/pull/2>
[13:21] <jam> or https://github.com/jameinel/ubuntu-lite/tree/operator/mod if you are browsing the Tree rather than the PR
[13:23] <jam> Chipaca, while sending the mattermost email, I realized we also really need to review https://github.com/johnsca/resource-oci-image/blob/master/oci_image.py
[13:23] <jam> since that is as common to be reused as k8s.py
[13:24] <Chipaca> ah
[13:24] <Chipaca> jam: ok
[14:32] <Chipaca> closed charmcraft#18, charmcraft#19 and charmcraft#20. I hope I was able to explain why clearly enough for the reporter not to hate us too much :-|
[14:32] <mup> Issue charmcraft#18: Poetry integration <Created by knkski> <Closed by chipaca> <https://github.com/canonical/charmcraft/issues/18>
[14:32] <mup> Issue charmcraft#19: Pep 518 support for charm metadata <Created by knkski> <Closed by chipaca> <https://github.com/canonical/charmcraft/issues/19>
[14:32] <mup> Issue charmcraft#20: Support pep 517 for building charms <Created by knkski> <Closed by chipaca> <https://github.com/canonical/charmcraft/issues/20>
[14:51] <mup> PR operator#321 opened: have a Code of Conduct <Created by chipaca> <https://github.com/canonical/operator/pull/321>
[14:54] <Chipaca> facubatista, jam, reviews on #23 would mean we could ship it today
[14:55] <mup> PR #23: Add leadership to model <Created by johnsca> <Closed by johnsca> <https://github.com/canonical/operator/pull/23>
[14:55] <Chipaca> charmcraft#23
[14:55] <mup> PR charmcraft#23: build: set JUJU_DISPATCH_PATH so we get the right hook <Created by chipaca> <https://github.com/canonical/charmcraft/pull/23>
[14:55] <facubatista> Chipaca, ack
[14:56] <mup> Issue operator#220 closed: Log in WARNING when a breakpoint is not served in debug mode <Created by facundobatista> <Closed by chipaca> <https://github.com/canonical/operator/issues/220>
[14:56] <mup> PR operator#294 closed: Log when a served breakpoint is not really activated because of name mismatch <Created by facundobatista> <Merged by chipaca> <https://github.com/canonical/operator/pull/294>
[14:58] <mup> Issue operator#262 closed: Harness should support resource-get <Created by jameinel> <Closed by chipaca> <https://github.com/canonical/operator/issues/262>
[14:58] <mup> PR operator#296 closed: Oci resources <Created by chris-sanders> <Merged by chipaca> <https://github.com/canonical/operator/pull/296>
[15:08] <facubatista> Chipaca, would you mind to explain what magic are you doing in charmcraft#23?
[15:08] <mup> PR charmcraft#23: build: set JUJU_DISPATCH_PATH so we get the right hook <Created by chipaca> <https://github.com/canonical/charmcraft/pull/23>
[15:09] <Chipaca> facubatista: i see no magic :-/
[15:09] <Chipaca> facubatista: the {{}} is because I need actual {s in the output
[15:10] <Chipaca> facubatista: WRT ${parameter:-word}    Use Default Values.  If parameter is unset or null, the expansion of word is substituted; otherwise, the value of parameter is substituted.
[15:11] <Chipaca> so ${JUJU_DISPATCH_PATH:-$0} is "either JUJU_DISPATCH_PATH or, if that is unset or null, $0"
[15:13] <facubatista> Chipaca, fantastic, thanks!!!
[15:14] <facubatista> Chipaca, mind to put a comment saying something like "if Juju don't support the dispatch mechanism, it will execute the hook, and we need sys.argv[0] to be the name of the hook, so we fake JUJU_DISPATCH_PATH to be that value"?
[15:14] <facubatista> Chipaca, thanks!
[15:15] <Chipaca> will do
[15:16] <facubatista> Chipaca, approved
[15:16]  * facubatista -> lunch
[15:58] <Chipaca> hmmmmmm
[15:58]  * facubatista is back
[15:58]  * Chipaca hmms
[16:01] <Chipaca> dunno if my lxd is stuck, or just my juju
[16:01] <Chipaca> facubatista: do you have a working thing you could juju ssh into to try something with juju-log?
[16:02] <facubatista> Chipaca, yes, but on a meeting right now
[16:02] <Chipaca> ah
[16:02] <Chipaca> k
[16:18]  * facubatista brb
[17:02] <Chipaca> ok i think i'm off
[17:02]  * Chipaca EODs
[17:03]  * facubatista is back
[19:44]  * facubatista eods


[09:45] <LocutusOfBorg> smb, hello, xen merge please? the Debian release fixes CVEs...
[10:01] <smb> LocutusOfBorg, I gladly will allow anyone who wants to have that erm... joy. More seriously, maybe in the next weeks but I more and more lack time to do those other things.
[12:48] <ahasenack> sil2100: hi, did you see my message from yesterday about bileto and it complaining about the "all" architecture?
[12:49] <ahasenack> sil2100: Laney suggested this: https://code.launchpad.net/~ahasenack/bileto/+git/bileto/+merge/388324
[12:55] <sil2100> ahasenack: oh, looking! But from the first glance it looks good
[12:55] <sil2100> ah this new britney
[13:27] <Laney> might be worth doing a diff of the whole config ...
[13:28] <doko> LocutusOfBorg: are you going to extract the ICE information for the llvm-11 build?
[13:38] <LocutusOfBorg> why should we do it right now?
[13:38] <LocutusOfBorg> I don't want to use llvm-11 as default in groovy
[13:39] <LocutusOfBorg> its completely unstable, just an rc
[13:40] <LocutusOfBorg> interestingly it didn't happen in Debian, meh
[13:54] <LocutusOfBorg> doko, https://launchpadlibrarian.net/490817056/buildlog_ubuntu-groovy-armhf.ns3_3.31+dfsg-2_BUILDING.txt.gz
[13:54] <LocutusOfBorg> mmmm lots of ices... looks suspicius?
[16:24] <xnox> "I don't want to use llvm-11 as default in groovy" -> right now, or at all? cause i hoped that groovy final will have llvm-11 because of all the CET goodness on amd64
[16:38] <tjaalton> yeah I'd expect mesa to migrate to it
[19:51] <mwhudson> releasing subiquity to stable


[02:02] <slangasek> apw, bjf: a lot of autopkgtest failures recently for linux/ppc64el in zesty; are we going to be getting back to green sometime soon?
[02:48] <bjf> slangasek, please bring that up tomorrow with sforshee and rtg
[02:57] <bjf> slangasek, actually, the tests look pretty good to me. the one real failure i'm seeing is with the kernel selftests. it looks like upstream hasn't built it on that platform
[04:49] <slangasek> bjf: so could the testsuite itself detect that, so that we don't have to dig into the logs each time to know whether the failure is ignorable?
[12:11] <sforshee> slangasek, bjf: the ppc selftests failure on ppc64el is because some of the tests don't build with pie enabled. We have a fix comitted, but since the tests run based on the zesty master branch it won't pass until the current kernel is released and master gets updated.
[12:45] <apw> sforshee, is that zesty master ?
[12:46] <apw> sforshee, if so you could probabally just shove it out as we care a lot less that that one rebases (which it likely won't anyhow) before release day
[12:50] <sforshee> apw: yeah I suppose. I was wondering though if the tests shouldn't be checking out the tag for the kernel under test.
[12:51] <apw> sforshee, these are the kernel self-tests right ?
[12:51] <sforshee> apw: yes
[12:52] <elmo> hey, I just rolled to 4.10! \o/
[12:52] <apw> heh
[12:53] <apw> elmo, and you are able to login to tell me so, so something must work
[13:16] <rtg> apw, sforshee - will defaulting to consoleblank=0 in Zesty have any deleterious side effects that you can think of ? See https://bugs.launchpad.net/ubuntu/+source/kbd/+bug/869017/comments/14
[13:24] <sforshee> rtg: nothing comes to mind. My guess is that comment is right, that it was probably set up that way to avoid burn-in on CRTs which isn't as much of a concern nowadays
[13:25] <rtg> sforshee, I'm sure it'll piss off someone though :)
[13:25] <sforshee> rtg: no doubt
[14:37] <snoerd> hey, since #ubuntu-boot seems to be abandoned, I'll try my luck here. Does anybody here have any experience with nfs-boot and overlayroot?
[14:47] <apw> snoerd, i personally do not but there are people who who likely have played with that kind of thing
[14:47] <apw> snoerd, but i would also suggest as people are on wildly different timezones, that
[14:47] <apw> snoerd, you ask your question so people don't tell you they know and leave
[14:52] <snoerd> apw: thanks, good point. My issue is plain and simple: booting over nfs works ( root dir passed as kernel parameter), as soon as I enable overlayroot, it hangs after successfully enabling overlayroot. It just prints "done" and that's been it
[14:53] <snoerd> here's a screenshot: https://postimg.org/image/x14ljvolr/
[14:54] <apw> snoerd, have you tried a "break=bottom" to get a shell at that point and have a look around ?
[14:55] <apw> snoerd, look at dmesg that kind of thing
[14:55] <snoerd> ahh, didn't know that parameter yet, thx. normally I'm poking around in userspace. gimme a sec
[14:56] <apw> it actually is a userspace implemented thing, by initramfs-tools, but goes on the kernel command line for giggles
[15:06] <snoerd> apw, sorry, was on the phone. If I use that parameter, I do in fact get a busybox shell at the end. however I cannot see something suspicous. only strange thing is that my nfs share is mounted in /root
[15:06] <apw> snoerd, and is the overlay mounted yet ?
[15:07]  * apw though bottom was after root was mounted
[15:07] <apw> ie literally the next thing was chroot into it
[15:08] <snoerd> doesn't look like it
[15:11] <snoerd> i can actually chroot into /root, but I get an "inappropriate ioctl for device" error from bash
[15:11] <snoerd> but it still works
[15:11] <snoerd> hm
[15:11] <snoerd> but no overlay
[15:12] <snoerd> ls
[15:12] <snoerd> damn :)
[15:13] <apw> snoerd, oh that is before bottom, breaks=init instead
[15:13] <apw> break=init
[15:18] <snoerd> ahh, thanks. I'll try that
[15:19] <snoerd> yeah, now I get the overlayroot.
[15:19] <apw> now at least you can see if it is working at all
[15:20] <snoerd> ahh, i guess there is something severly broken. I just get a scrambled stack trace when I try to chroot into it
[15:21] <snoerd> also, i can read in the overlay, but not write
[15:28] <snoerd> after a bit of trying a got a readable version of the stacktrace. it happend when I tried to chroot into the overlay. maybe it is of help https://postimg.org/image/kjr8gav3r/
[15:47] <snored> if somebody has a followup on the bug i've posted: I've joined this channel with my regular nick 'jules'
[15:48] <apw> jules, hey ... did you put a simple how to reproduce this in your bug ?  i assume it is pretty easy
[15:48] <apw> jules, if so then i recon that that one can be bisected in a VM or something
[15:49] <apw> jules, also what was the bug # ??
[15:53] <jules> apw: I haven't reported it yet. reproducing it should be fairly straight forward, but you have to have a working PXE environment, which is a bit of a hazzle to set up.
[15:54] <apw> jules, well if you are able to test kernels for it, we likely can supply them
[15:55] <jules> apw: that should be no big deal. I'm writing the bug report now
[16:29] <jules> apw: filed as bug #1675086


[00:09] <Proz0id> how do i install the libxml-2.0 and libxslt in ubunbtu server 10.04 lTS?
[00:13] <Proz0id> development libraries
[00:14] <Proz0id> that is
[00:51] <elks294> the router reset has solved my ubuntu network issue too, im online in ubuntu
[00:54] <elks294> help, text in the chat room is highlighted, my mouse wont click off it, and a user is highlighted
[00:55] <elks294> ok that worked
[00:59] <holstein> Proz0id: could be simply the package names
[01:00] <holstein> when i run apt-cache search, looks like its libxml2 - GNOME XML library
[01:00] <elks294> what is a good firewall to use on ubuntu 11.04
[01:01] <holstein> libxslt1-dev - XSLT processing library - development kit
[01:01] <holstein> Proz0id: ^
[01:01] <holstein> elks294: https://help.ubuntu.com/community/UFW
[01:02] <holstein> shorewall is popular as well
[01:04] <Proz0id> i found it ... "sudo apt-get install libxslt-dev libxml2-dev"
[01:09] <elks294> ufw looks complicated to setup
[01:10] <elks294> is there a easier version
[01:16] <elks294> someone help me setup ufw please
[01:19] <elks294> can i run a good vmware firewall
[01:35] <holstein> elks294: are you behind a router?
[01:35] <holstein> the router is going to have a firewall
[01:35] <holstein> the 'U' in UFW stands for uncompicated :)
[01:35] <elks294> yes im behind a router, router is running dd-wrt
[01:36] <holstein> so, you have a firewall there
[01:36] <elks294> is this enough?
[01:37] <elks294> on my windows box, i noticed some unsolicited tcp connections in netstat
[01:37] <elks294> which is one reason im on ubuntu now
[01:37] <holstein> elks294: do what makes you feel comfortable
[01:38] <zkriesse> If you're router is firewalled you should be fine, especially with 'buntu
[01:38] <holstein> i dont have additional firewalls per machine
[01:39] <holstein> but, go for it, if you feel safer
[01:39] <elks294> also using terminal in ubuntu, netstat is outputing a bunch of stuff maybe too much
[01:40] <elks294> i can't view it all the screen is cut off
[02:06] <elks294> how do you install a .bundle
[02:06] <holstein> elks294: what are you trying to do?
[02:06] <elks294> im trying to install vmware
[02:08] <holstein> elks294: check out https://help.ubuntu.com/community/VMware/Player
[02:08] <holstein> i use virtualbox*
[02:10] <elks294> thanks this got me installing
[02:10] <holstein> :)
[02:10] <elks294> as long as VMware is free its ok with me
[02:12] <holstein> i use the opensource virtualbox edition
[02:12] <holstein> its just what i started using
[02:28] <elks294> ubuntu seems to be hanging up slightly
[02:36] <elks294> is there a virus scanner for ubuntu, to scan files for windows
[02:38] <holstein> check out https://help.ubuntu.com/community/Antivirus elks294
[05:31] <elks294> im trying to install ubuntu restricted extras but its asking me to uninstall libav codec and utility how is this done or is it neccasary
[05:35] <braiam> elks294: use synaptic to examine the situation
[05:42] <elks294> ok i marked them in synaptic
[06:07] <elks294> looks like its stuck on Unpacking ttf-mscorefonts-installer (from .../ttf-mscorefonts-installer_3.3ubuntu3_all.deb) ...
[06:08] <elks294> nvm there was a user agreement screen in the back waiting on me
[06:10] <wastrel> hi
[06:49] <Ambrose83`> I just installed the xserver-xorg-video-radeonhd driver.  I would like to enable the audio option for this driver to allow audio to pass through the HDMI cable.
[06:49] <Ambrose83`> The following website: http://manpages.ubuntu.com/manpages/lucid/man4/radeonhd.4.html
[06:50] <Ambrose83`> Says that I should be able to enable the "audio" option, but I am not sure exactly what command to issue in order to do this.
[06:50] <Ambrose83`> Could someone please let me know.
[08:27] <LigH> Good morning.
[08:29] <LigH> I wanted to switch from the Unity desktop to the Classic one. Several websites report that I can switch this in the login screen. But I don't see any combobox in the bottom bar, neiter with the 32b nor with the 64b installation of 11.04.
[08:30] <LigH> I got a suggestion to check the gdm bugs in the Launchpad bugtracker, but I did not find something matching, maybe because I don't know the best matching terms to search for.
[08:35] <bioterror> LigH, http://ihaveapc.com/wp-content/uploads/2011/04/Ubuntu-11.04-Classic-Gnome-Session-001.png
[08:38] <LigH> From the right bottom corner, I have: The off switch, the clock, the handicap menu. Nothing else.
[08:39] <LigH> This Ubuntu install DVD was shipped with the german c't magazine.
[08:39] <bioterror> you should have those in your default installation
[08:39] <bioterror> otherwise something is broken ;)
[08:40]  * bioterror is no GDM master
[08:40] <LigH> Guessed so. And now ... ?!? - Make a bug report in launchpad - gdm?
[08:41] <LigH> BTW, my boot sequence often hangs after switching the keyboard and mouse off, untik I hit e.g. the Ctrl key.
[08:41] <LigH> There I found a similar report.
[10:44] <zkriesse> hallo all
[10:54] <raju> every time while i am login to ubuntu , i am getting a message that " cannot find /tmp , press F to fix or I ignore blah blah blha...." how can i solve this problem
[16:07] <Sage> anyone using avlinux?
[16:10] <coalwater> i dont even know what that is lol
[16:37] <Sage> anyone made a live usb install?
[16:39] <bodhizazen> I have =)
[16:40] <Sage> which flavor?
[16:40] <bodhizazen> Zenix =)
[16:40] <bodhizazen> what problem are you haveing
[16:41] <bodhizazen> http://zenix-os.net/
[16:42] <Sage> I used linux years ago, now I'm brand new again... used avlinux live cd and cant see my windows c: drive, can see my usb HD
[16:43] <bodhizazen> Well, should be rather trivial
[16:43] <bodhizazen> Open a terminal and switch to root
[16:43] <Sage> just when to the link, haha nice, a Buddhist Linux!
[16:43] <bodhizazen> sudo -i or su -
[16:43] <bodhizazen> then fdisk -l
[16:43] <bodhizazen> to list your partitions
[16:44] <bodhizazen> then mount /dev/sda1 /mnt
[16:44] <bodhizazen> you will need to change sda1 to your windows partition
[16:44] <bodhizazen> and thanks for looking at Zenix, it is a nice little distro =)
[16:45] <Sage> does it have a live version?
[16:46] <Sage> I'll take note, but sadly, most of that was over my head for now... Thanks!
[16:46] <bodhizazen> Zenix runs live yes
[16:46] <bodhizazen> burn it to cd
[16:46] <bodhizazen> http://zenix-os.net/live.html
[16:48] <Sage> I just downlded the linux live tool for windows and will try to make a usb install later... would like to use avlinux since it is designed for what I am interested in trying
[16:50] <Sage> do you know the diff between unetbootin and lili?


[16:00] <mvo> hello
[16:01] <doko> hi
[16:01] <robbiew> #startmeeting
[16:01] <MootBot> Meeting started at 10:01. The chair is robbiew.
[16:01] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[16:01] <robbiew> o/
[16:01] <psurbhi> o/
[16:01] <ev> \o/
[16:02] <jhunt_> o/
[16:02] <robbiew> [TOPIC] Lightning Round
[16:02] <cjwatson> hi
[16:02] <MootBot> New Topic:  Lightning Round
[16:02] <robbiew> any volunteers?
[16:02] <ev> o/
[16:03] <ev> trying to sort out how to properly draw on the root window in a compiz world in support of moving the installer session to it. Finishing up the usb-creator specification.
[16:03] <ev> Documenting the state of the partitioning UI in preparation for a meeting with ivanka on the home preservation and package retention stuff on Friday. Sorted the oem-config slideshow stuff.
[16:03] <ev> (done)
[16:04] <cjwatson> o/
[16:04] <cjwatson> I've spent almost all of this week on the bootstrap project, with a bit of 10.04.2 archive/CD-building work on the side.  No other progress to report.
[16:04] <robbiew> thxn ev and cjwatson
[16:04] <cjwatson> Unfortunately I think I'll have to defer GRUB-on-the-CDs for another cycle.  Sorry. :-(
[16:04] <cjwatson> --
[16:04] <barry> o/
[16:05] <barry> bug 686257 (python-keyring), bug 664276 (python-numpy), bug 710711 (network manager crashes - not fix), bug 693671 (wubi - not fixed), bug 711225 (subprocess.Popen() crash), bug 697792 (fuse verified for lucid-proposed), bug 702375 (launchpadlib), bug 715707 bug 601585 bug 591433 (computer-janitor).  also: several udd discussions, python archive analysis, python3 porting c/c, c-j bug triage.  done.
[16:05] <barry> ev: i think i'm going to need some help on the wubi issue.  i can't even get as far as the original bug reporter
[16:06] <robbiew> sweet...thnx for working the bugs barry
[16:06] <psurbhi> o/
[16:06] <psurbhi> 1) still debugging mountall - upstart communication in initramfs. Analaysed that "a read on a socket is occuring for 0 bytes" , so connection between mountall and upstart is getting disconnected. Just have analyse what is happening :( but not the why part! (need to discuss this) hopefully by next week shall have a better status. not much PROGRESS in this week- sorry!
[16:06] <psurbhi> 2) spent some time today on samba 526464 and 496160 (looked at the patch back portability and code trace), traced some nfs code last week.
[16:06] <psurbhi> (done)
[16:06] <ev> barry: sure
[16:07] <robbiew> doko:?
[16:07] <doko> short week, starting on Mon. still catching up, long call with bjoern for LO, more mentoring, gcc linaro merges, gcc-4.4 and gcc-4.5 updates, binutils update, started eglibc-2.13 merge/packaging
[16:07] <doko> done
[16:07] <robbiew> mvo?
[16:07] <cjwatson> mountall/initramfs> if you can get strace into your initramfs and run mountall under it, that would probably be helpful
[16:07] <mvo> apt: merges from debian
[16:07] <mvo> aptdaemon: fixes, merges, upload new version
[16:07] <mvo> auto-upgrade-tester: add python-all test profile, run test, fix #715075, fix main-all bootstraping (always a bit of a pain)
[16:07] <mvo> mago: modernize packaging, upload new bzr snapshot (needed for s-c)
[16:07] <mvo> Review lp:~csurbhi/+junk/mdadm.fixes (looks good, but needs changelog updates to refer to the individual bugs for the SRU)
[16:07] <cjwatson> oh, unless you've already done that
[16:07] <mvo> rnr-server: debug/fix encoding issues (#714582), expose usefulness via API, add offline mode to piston-mini-client
[16:07] <mvo> Softwae-center: branch review/merges, cleanup, debug oneconf issues, upload 3.0-sru, work on "was-this-review-useful" feature,
[16:07] <mvo> Update-manager: look at native python-patch impleentation (for applying emergency hot-fixes during the upgrade as some minimal systems do not even have "ed" installed). not much luck yet
[16:07] <mvo> (done)
[16:07] <robbiew> psurbhi: did you see cjwatson's suggestion?
[16:08] <psurbhi> cjwatson, thanks..! i will try that too
[16:08] <robbiew> mvo: so are there plans to allow people to sort applications by reviews?
[16:08] <psurbhi> currently i am redirecting all the output to a serial port in kvm (and that goes to a file)
[16:08] <psurbhi> and i have put a trillion printfs in libdbus.. and mountall
[16:08]  * robbiew is too lazy to read the novel/spec
[16:09] <mvo> robbiew: not currently, but maybe a top rated section
[16:09] <mvo> robbiew: but FF is close :/
[16:09] <robbiew> mvo: heh...sure...not meaning for 11.04
[16:09] <robbiew> just in general
[16:09] <psurbhi> cjwatson, i will try the strace today and hopefully find something more, thanks!
[16:09] <robbiew> top rated is probably good enough
[16:09] <mvo> in the long term I think it would be really useful
[16:09] <mvo> we plan to have search results ranged by it too
[16:09] <robbiew> cool
[16:10] <robbiew> jhunt_:?
[16:10] <jhunt_> Finished Upstart visualisation tests and pushed branch. Then found a bug in the Graphviz script which has led to a rework. Ironically, that rework ended up showing up a bug in autofs (bug 718664 which I fixed), and a minor bug in the Upstart visualization parser. A side-effect of the tests for the visualisation means that I have been able to write a script for users to syntax check their .conf job files prior to installing them into /etc/init/. Currently
[16:10] <jhunt_> EOT
[16:10] <mvo> nice
[16:10] <cjwatson> cut off at "Currently"
[16:11] <robbiew> jhunt_:  ^^
[16:12] <robbiew> hmm...maybe lost connection
[16:13] <robbiew> [TOPIC] Natty
[16:13] <MootBot> New Topic:  Natty
[16:13] <robbiew> Feature freeze next week!!!!
[16:13] <mvo> *urgh*
[16:13] <ev> !!!!!1
[16:14] <highvoltage> *panics*
[16:14] <robbiew> we do have the option of submitting feature freeze exceptions...but I think skaet and the release team plan to hand those out sparingly ;)
[16:15] <robbiew> http://reports.qa.ubuntu.com/reports/team-assigned/canonical-foundations-assigned-bug-tasks.html
[16:15] <MootBot> LINK received:  http://reports.qa.ubuntu.com/reports/team-assigned/canonical-foundations-assigned-bug-tasks.html
[16:15] <robbiew> A total of 252 bug tasks are assigned to the canonical-foundations team!
[16:15] <robbiew> Michael Vogt has 107 tasks assigned
[16:15] <robbiew> Colin Watson has 54 tasks assigned
[16:15] <robbiew> Canonical Foundations Team has 28 tasks assigned
[16:15] <robbiew> Barry Warsaw has 17 tasks assigned
[16:15] <robbiew> Surbhi Palande has 17 tasks assigned
[16:15] <robbiew> Evan Dandrea has 14 tasks assigned
[16:15] <robbiew> Matthias Klose has 10 tasks assigned
[16:15] <robbiew> James Hunt has 5 tasks assigned
[16:16] <jhunt__> sorry - slight case of kernel barfage...!
[16:16] <robbiew> (10:10:20 AM) jhunt_: Finished Upstart visualisation tests and pushed branch. Then found a bug in the Graphviz script which has led to a rework. Ironically, that rework ended up showing up a bug in autofs (bug 718664 which I fixed), and a minor bug in the Upstart visualization parser. A side-effect of the tests for the visualisation means that I have been able to write a script for users to syntax check their .conf j
[16:16] <robbiew> (10:10:23 AM) ubottu: Launchpad bug 718664 in autofs5 (Ubuntu) "upstart config fo file autofs5 requires space" [Undecided,Fix released] https://launchpad.net/bugs/718664
[16:16] <robbiew> (10:10:27 AM) jhunt_: EOT
[16:16] <robbiew> (10:10:41 AM) mvo: nice
[16:16] <robbiew> (10:10:50 AM) cjwatson: cut off at "Currently"
[16:17] <robbiew> okay....
[16:17]  * cjwatson unassigns another handful from himself
[16:17] <robbiew> so the bug numbers for the team are not bad...unless you are mvo, who apparently loves to work bugs
[16:18] <cjwatson> might eventually get down to a comfortable level
[16:18] <mvo> *cough* I guess I love to collect them
[16:18]  * mvo will agressively fix/unassign
[16:18]  * robbiew vows to get mvo under 100
[16:18] <robbiew> I probably can't fix any of them....but I can unassign/invalidate the REALLY old ones
[16:18] <robbiew> ;)
[16:19] <psurbhi> :D
[16:19] <jhunt__> robbiew: shall I re-paste?
[16:19] <robbiew> jhunt__: would be nice :)
[16:19] <jhunt__> hold onto your pants, here we go...
[16:19] <jhunt__> Finished Upstart visualisation tests and pushed branch. Then found a bug in the Graphviz script which has led to a rework. Ironically, that rework ended up showing up a bug in autofs (bug 718664 which I fixed), and a minor bug in the Upstart visualization parser. A side-effect of the tests for the visualisation means that I have been able to write a script for users to syntax check their .conf job files prior to installing them into /etc/init/. Currentl
[16:19] <jhunt__> EOT
[16:20] <psurbhi> jhunt_, the message is cut off at Currentl :P
[16:20] <cjwatson> IRC has a line length limit - you need to split
[16:20] <jhunt__> take 2, part 2...
[16:20] <jhunt__> Currently finishing off graphviz script and a "check mode" for initctl to detect invalid configuration combinations (useful for dpkg) and will then concentrate on looking at Keybuks branches in earnest along with packaging up my code for natty. I think we're running out of runway for my "interactive boot" work for this cycle (it wasn't actually scoped), but we'll see...
[16:21] <jhunt__> I think I'll revert to my old style of pasting next time :)
[16:21] <robbiew> heh...well, there's no shame in postponing work to the next release
[16:21] <cjwatson> FWIW I'll be more than happy if we get the scoped work done, aside from future work ;-)
[16:21] <robbiew> as long as we do it
[16:22] <robbiew> http://people.canonical.com/~pitti/workitems/natty/canonical-foundations-natty-alpha-3.html
[16:22] <MootBot> LINK received:  http://people.canonical.com/~pitti/workitems/natty/canonical-foundations-natty-alpha-3.html
[16:22] <robbiew> speaking of scoped work :P
[16:23] <robbiew> not that many work items really listed, so assuming they aren't SUPER generalized ones, like "fix bugs"....I'm fine with it
[16:23] <robbiew> http://people.canonical.com/~pitti/workitems/natty/canonical-foundations.html
[16:23] <MootBot> LINK received:  http://people.canonical.com/~pitti/workitems/natty/canonical-foundations.html
[16:23] <robbiew> that looks even better :)
[16:24] <robbiew> [TOPIC]AOB/GoodNews
[16:24] <MootBot> New Topic: AOB/GoodNews
[16:24] <mvo> I ran a python-all upgrade test (including python packages from universe) from maverick->natty and it looks very good
[16:24] <robbiew> \o/
[16:25] <mvo> (filed some bugs, did some fixes, but overall very good, tag python27 for the remaining ones)
[16:25] <mvo> and I just uploaded apt-btrfs-snapshot to natty
[16:25] <psurbhi> yey
[16:25]  * mvo is very excited about this one
[16:25] <psurbhi> :)
[16:25] <barry> mvo: thanks!
[16:25] <cjwatson> that went fast after the infrastructure was done :)
[16:25] <mvo> thanks psurbhi for the work to make this happen (in the installer)
[16:26] <psurbhi> mvo, thanks to you too for the wonderful feature
[16:26] <mvo> cjwatson: yeah, its not hard, the tricky part was what you and psurbhi did (and the initial thinking)
[16:26] <robbiew> what does apt-btrfs-snapshot do?
[16:27] <mvo> it will create btrfs snapshots
[16:27] <mvo> ;)
[16:27] <cjwatson> there are still some issues in grub2 that make it tricky to use by default (aside from any problems with btrfs itself)
[16:27] <mvo> on each apt-get install/remove/upgrade run
[16:27] <cjwatson> in particular we don't have anywhere to put the environment block yet, so a few features won't work
[16:27] <mvo> plus it provides the needed hooks so that the release upgrade can use it
[16:27] <cjwatson> we have a design for a solution to that, but no code for it yet
[16:28] <mvo> cjwatson: I also noticed that btrfs and dpkg do not play that well, everything feels slow because of the fsync() calls I assume
[16:28] <mvo> this needs fixing IMO as well before we can consider it as default
[16:29] <mvo> but its still a really nice step forward
[16:29] <robbiew> mvo: ah...cool
[16:29] <robbiew> thnx
[16:30] <mvo> robbiew: I should add that it works seamlessly, you install apt-btrfs-snapshot and you get snapshots plus a cli to manually create/list/delete
[16:30] <mvo> (well, on my test machine anyway ;)
[16:30] <robbiew> sweet
[16:30] <robbiew> heh
[16:30] <barry> nice
[16:30] <robbiew> ubuntu timemachine
[16:30] <mvo> indeed, a bit like it
[16:31] <robbiew> anything else?
[16:31] <robbiew> going once......
[16:32] <robbiew> twice.....
[16:32] <robbiew> #endmeeting
[16:32] <MootBot> Meeting finished at 10:32.
[16:32] <psurbhi> thanks!
[16:32] <robbiew> thnx all!
[16:32] <mvo> thanks
[16:32] <jhunt__> thx
[16:32] <barry> thanks!
[16:32] <ev> thanks
[19:00] <highvoltage> Anyone present for an Edubuntu meeting? :)
[19:01]  * alkisg waves
[19:01]  * mgariepy waves
[19:02]  * highvoltage rolls
[19:02] <highvoltage> http://www.uct.ac.za/images/uct.ac.za/contact/campusmaps/big/upper.jpg
[19:02] <highvoltage> oope, not that one
[19:02] <highvoltage> https://wiki.ubuntu.com/Edubuntu/Meetings/Agenda
[19:02] <highvoltage> should we make Edubuntu meetings monthly instead and just plan more if we need them?
[19:03] <mgariepy> Would work for me.
[19:03] <highvoltage> we don't usually have many people attending, and most of us that do usually follow #edubuntu
[19:03] <alkisg> Sounds good
[19:04] <alkisg> Or we could have shorter meetings :)
[19:04] <alkisg> :P
[19:04] <highvoltage> we've been doing that too :)
[19:04] <highvoltage> https://wiki.ubuntu.com/Edubuntu/Devel/RoadMap
[19:05] <highvoltage> Feature Freeze is next week
[19:05] <highvoltage> so I'll work on getting acire/python-snippits in
[19:05] <highvoltage> librecad is uploaded, so we'll change the seeds to switch qcad for librecad
[19:06] <highvoltage> stgraber said that he should be ok working on the ubiquity stuff before then
[19:06] <highvoltage> not sure if mhall119 made progress for the qimo gnome session yet, but as I know him he'll probably pop in any moment to give an update
[19:07] <highvoltage> I emailed the artwork team to let them know about our intentions working with doctormo, hopefully that turns out ok
[19:08] <highvoltage> and that's it I can think of now. anyone else have any news of what's been happening in Edubuntu recently?
[19:09] <alkisg> The italc problem didn't cause much noise after all...
[19:09] <alkisg> Nope, nothing from me
[19:09] <mgariepy> nothing for me
[19:10] <highvoltage> alkisg: yeah, I was (pleasantly) surprised
[19:11] <highvoltage> ok, let's call it a meeting then, thanks alkisg and mgariepy
[19:11] <alkisg> Ty highvoltage
[19:11] <mgariepy> thank you guys
[19:13]  * mhall119 pops in
[19:13] <mhall119> no qimo progress at all to report ;9
[19:13] <mhall119> :(
[19:13] <mhall119> debmower still doesn't work, and I haven't gotten around to ripping apart an xubuntu iso yet
[19:13] <mhall119> highvoltage: if push comes to shove, is there room on the DVD for Xfce?
[19:14] <highvoltage> mhall119: hmm, room yes, I think the bigger issue is shipping another desktop environment.
[19:15] <highvoltage> mhall119: I have some time allocated to work on debmower, I'm also going to look at Offspring and see if it's worth while, it's CA'd though and I'm not sure if I'd be comfortable with the future of that
[19:16] <mhall119> CA'd?
[19:16] <highvoltage> copyright assigned
[19:17] <mhall119> ah
[19:17] <highvoltage> I'm not too confortable of having the possibility of having a free software project that might have to compete with an exact non-free version, but that possibly has more features added for show or something
[19:17] <mhall119> we can fork it though, if we wanted to
[19:17] <mhall119> it's OSI licensed?
[19:18] <highvoltage> yep
[19:18] <highvoltage> cody-somerville: will it support building debian CDs too?
[19:21] <cody-somerville> highvoltage, Offspring isn't a build tool its self. If the build tool you use for a project supports it, then yes. Offspring ships with support for using live-build out of the box which is actually a Debian project. It supports building theoretically any Debian-based system.
[19:21] <highvoltage> cody-somerville: ok, that's pretty cool then
[19:24]  * stgraber waves


[06:41] <lordievader> Good morning
[12:56] <Tireg> I just found out CANONICAL-AS on the RIPE database, with all its subnets (https://apps.db.ripe.net/db-web-ui/query?bflag=true&dflag=false&inverse=mnt-by&rflag=false&searchtext=CANONICAL-MNT&source=RIPE&types=route), and noticed that every Ubuntu/Canonical services are hosted on those networks (keyserver, launchpad, repositories except mirrors,
[12:56] <Tireg> snapcraft/snapstore, ...)
[12:56] <Tireg> Does Canonical host third-party services on those ranges ?
[12:57] <xnox> Tireg:  what do you mean by "third-party services"?
[12:58] <Tireg> Services not managed by Canonical themself, such as if they would host VMs/Containers/Services on those ranges, but for third party people/enterprises
[12:59] <Tireg> Just like AWS would host files for their customers
[13:02] <Tireg> (or said in another way, if I would insert firewall rules to allow outbound traffic to those Canonical subnets, would this allow only traffic to Canonical-managed services, or also to services not managed by Canonical/Ubuntu community)


[15:00] <falktx> hi abogani
[15:00] <falktx> abogani: you there?
[15:00] <abogani> falktx: yes
[15:01] <falktx> abogani: i have a favour to ask you
[15:01] <falktx> abogani: can you update the lucid lowlatency kernel on your ppa?
[15:01] <falktx> it's the default kernel on my kxstudio distro
[15:02] <abogani> falktx: As reported to all our Studio mailing-list lowlatency lucid is dropped.
[15:02] <falktx> abogani: maybe just a last update?
[15:02] <falktx> please..?
[15:04] <abogani> falktx: No I can't. I have already delete all files. I would happy to help you but there is no way. Sorry
[15:04] <falktx> ah, ok
[15:04] <falktx> i'm not sure about using the realtime kernel as default
[15:04] <abogani> falktx: Could you inform me when you use my package? So I avoid to delete these without alert you.
[15:05] <abogani> falktx: .33 seems a lot stable, at me at least
[15:06] <falktx> abogani: usually I copy your packages into my PPA, the version I now have is 2.6.32-24.42
[15:06] <falktx> I guess I'll be back to generic
[15:07] <abogani> falktx: Yes an other good choise.
[15:07] <abogani> choice
[15:10] <falktx> abogani: so the lowlatency kernel will be dropped for good?
[15:13] <falktx> abogani: what about natty? will you make lowlatency for it or it's not decided yet?
[15:18] <astraljava> falktx: More information regarding kernels can be found on: https://wiki.ubuntu.com/RealTime
[15:19]  * falktx reads
[15:22] <falktx> ok
[15:48] <falktx> hey I just found AutoStatic in IRC
[15:48] <falktx> he's coming here
[15:49] <falktx> hey AutoStatic
[15:49] <AutoStatic> Hi
[15:50] <falktx> me and AutoStatic were discussing about the PPA
[15:52] <falktx> from what I understand, this is the official us dev team: https://launchpad.net/~ubuntustudio-dev
[15:52] <falktx> and this is the PPA for it - https://launchpad.net/~ubuntustudio-dev/+archive/ppa
[15:54] <falktx> to all devs here: What is the best choice for a new studio PPA:
[15:54] <falktx> 1 - the official ubuntustudio-dev
[15:54] <falktx> 2 - a new team
[15:54] <falktx> ?
[15:55] <abogani> What type of packages should go into that new PPA?
[15:55] <astraljava> A new studio PPA? What for?
[15:55] <AutoStatic> For Ubuntu Studio
[15:56] <AutoStatic> atm there are multiple multimedia PPA's
[15:56] <astraljava> I mean, what apps should go there, and why couldn't they go into the official repos?
[15:56] <AutoStatic> philip5, falktx, tangostudio etc
[15:57] <falktx> astraljava: for example wineasio and VSTs
[15:57] <falktx> astraljava: also svn builds of ardour3.0, hydrogen, etc
[15:57] <AutoStatic> Apps that are not in Debian testing or the official repo's
[15:57] <falktx> AutoStatic: maybe we should split into 2 ppas, 1 stable and 1 testing
[15:57] <AutoStatic> So not even necessarily svn builds
[15:58] <AutoStatic> Yes, good idea
[15:58] <astraljava> falktx: Okay. If Ubuntu Studio devs are supposed to offer support for them, it would make sense for them to be in ubuntustudio-dev PPA. And one PPA can offer several repositories.
[16:00] <abogani> The best thing should be: Create a PPA into ubuntustudio. Place there all stable packages. Use the ubuntustudio-dev's PPA for development packages (like svn builds).
[16:00] <abogani> IMHO obviously :-)
[16:00] <falktx> seems good to me
[16:01] <falktx> but afaik, everyone is allowed to be part of the ubuntustudio team
[16:02] <astraljava> Yeah, the idea of providing support for such packages make me cringe a bit. :)
[16:02] <astraljava> +s
[16:02] <falktx> so maybe it could be better if the team is kinda not official
[16:03] <AutoStatic> now orries I think astraljava
[16:03] <AutoStatic> no worries I mean
[16:04] <astraljava> Are there licensing issues why some of the packages couldn't go to official repos?
[16:04] <falktx> AutoStatic: the way I currently build svn packages, they dont conflict with the stable ones
[16:04] <falktx> AutoStatic: maybe they should go too into the stable ppa too, and leave the test ppa just for testing of new packages
[16:05] <AutoStatic> I haven't build that much of those kind of packages
[16:05] <falktx> astraljava: most packages are ok
[16:05] <AutoStatic> I second that, i don't foresee any big support issues
[16:05] <falktx> astraljava: but VSTs require non-free headers to compile
[16:05] <astraljava> falktx: Gotcha.
[16:05] <falktx> astraljava: my way of doing it is to compile them myself and only include the source in the package
[16:06] <falktx> astraljava: I never touch the non-free headers at anytime in the PPA
[16:06] <astraljava> Ok.
[16:08] <falktx> astraljava: here's an example of restricted package - https://launchpad.net/~falk-t-j/+archive/lucid/+sourcepub/1343380/+listing-archive-extra
[16:08] <AutoStatic> falktx: with a good set-up on your won machine one doesn't really need a test PPA I think
[16:09] <falktx> astraljava: all source is included, but not the non-free header
[16:09] <falktx> astraljava: the folder 'build' contains the binary I compiled
[16:09] <falktx> astraljava: please check it and tell me if this should be ok
[16:09] <falktx> AutoStatic: you too please
[16:10] <falktx> AutoStatic: for testing I guess I could just use my own testing PPA
[16:11] <AutoStatic> just a sec
[16:14] <AutoStatic> Looks good to me
[16:15] <falktx> this is the method I use for VSTs too
[16:15] <falktx> I spoke to the launchpad guys about this too, they said it was ok
[16:16] <AutoStatic> But isn't wieasio a lib?
[16:16] <AutoStatic> wineasio
[16:17] <astraljava> falktx: I'm not an expert on these matters, but IMO that's fine.
[16:17] <falktx> AutoStatic: yes, it goes to /usr/lib/wine
[16:18] <falktx> AutoStatic: but it uses ASIO, non-free stuff from the Windows world...
[16:18] <falktx> astraljava: thanks
[16:19] <AutoStatic> Yes I know falktx, but I was hinting at the fact that it seems to be packaged as a single binary while it is actually a library
[16:19] <AutoStatic> But then I'm not a packaging expert
[16:20] <falktx> AutoStatic: ah, that
[16:20] <AutoStatic> That will come when we start packaging for Natty
[16:20] <AutoStatic> ;)
[16:20] <falktx> AutoStatic: everyone was using the name 'wineasio' for the package, so I just continue the tradition
[16:20] <falktx> btw, I also have an external repo for really non-free stuff (closed source apps), these I know can't be on launchpad
[16:22] <AutoStatic> I don't mean the package name but apparently it's created with dh_make -s instead of dh_make -l
[16:22] <AutoStatic> Nah, letś not go into details
[16:22] <AutoStatic> It works :)
[16:23] <falktx> AutoStatic: what is the diff between '-s' and '-l' ?
[16:24] <AutoStatic> -s = single binary and -l = library
[16:24] <AutoStatic> I think package managers rely on this too
[16:25] <AutoStatic> Synaptic - Sections
[16:25] <AutoStatic> wineasio is now in sound while it shoudl be in libraries
[16:25] <AutoStatic> I think
[16:26] <falktx> hm... not sure
[16:26] <falktx> anyway, it's not a big issue
[16:26] <AutoStatic> Nope
[16:26] <AutoStatic> That kind of stuff is debatable
[16:26] <falktx> AutoStatic: when we make a PPA, you can easily fix it if you want
[16:28] <AutoStatic> Yes, but we'll see
[16:28] <falktx> so how should we name the team?
[16:28] <AutoStatic> It's still all a bit vague
[16:30] <AutoStatic> Ok, gotta go
[18:48] <scott-work> i realize that autostatic and falktx are not here but i wanted to add my opinion to this as well
[18:49] <scott-work> i would like to try to avoid implying that the ubuntu studio developer team would be responsible for maintaining or responsible for any packages in falktx/autostatic's group PPA
[18:50] <scott-work> perhaps calling the team "Ubuntu Studio Packaging Team" with a clear explanation that this is not part of the official Ubuntu Studio Dev team
[18:51] <scott-work> also mentioning that the purpose of the team is to package applications that cannot be in the official repositories due to licensing or too experimental as well
[18:52] <scott-work> hopefully falktx and autostatic can also focus on getting packages into the repos when possible, rather than take the quick satisfaction of putting everything into a PPA
[18:53] <scott-work> we will get much longer benefits if packages that *can* go into the repos actually see the work to *get* them into the repos
[18:53] <scott-work> preferrably into debian first though ;)
[19:04] <astraljava>                  modules see ya
[19:04] <astraljava> [20:33] < clave> hello?
[19:05] <astraljava> sorry


[21:06] <darkxst> ricotz, can you rebuild js188 with e4x enabled
[21:32] <ricotz> darkxst, e4x (xml support) is enabled by default
[21:36] <darkxst> ricotz, hmm ok, well its not working for some reason
[21:39] <ricotz> darkxst, are you forced to replace the current handling to port it?
[21:40] <ricotz> (if this is gjs related)
[21:40] <darkxst> yes gjs related
[21:41] <darkxst> it was removed in 18, so should work in 17
[21:41] <darkxst> Gio overrides make use of it though
[21:44] <ricotz> ah i see
[21:44] <ricotz> so an alternative is needed (soon) then
[21:44] <darkxst> yes
[21:46] <ricotz> ok, anyway, it is enabled in the 188 build and is suppose to work then


[11:36] <pascal3> bonjour
[15:15] <little> Hey there. (:
[15:15] <jjesse> hello little
[15:15] <little> I'm a big fan of Kubuntu and have written several HOWTO pages, and would just love to contribute. Time on my hands and all that. (:
[15:16] <little> You guys can feel free to check out my work at http://littlergirl.googlepages.com
[15:16] <little> I try to write idiot-proof documentation that anybody can follow. (:
[15:17] <jjesse> cool that's what wwe need, idiot proof documentation
[15:17] <little> LOL!
[15:20] <little> Some of my stuff would be a bit complicated to put onto the wiki, but I'm up for it. (:
[15:21] <jjesse> if you find anything that needs to change in the current hardy documentation you can always file bugs against kubuntu-docs
[15:21] <jjesse> and then start working on fixing them :)
[15:22] <jjesse> the docbook branch is located at https://code.edge.launchpad.net/~ubuntu-core-doc/ubuntu-doc/kubuntu-intrepid
[15:24] <little> Is this one already useless: https://code.edge.launchpad.net/~ubuntu-core-doc/ubuntu-doc/kubuntu-hardy ? I use Hardy Heron LTS.
[15:26] <jjesse> well if there are bugs in the hardy branch we will be updating them in the intrepid release
[15:26] <jjesse> the bug might be fixed in intrepid already
[15:26] <little> Then I think I'd be better at doing the wiki documentation, since my interest is in how to make the software do things. (:
[15:31] <jjesse> make what software work?
[15:45] <little> Ah, sorry, I was editing the Documentation page. Whatever software interests me at any given time. I document how to use it.
[21:17] <mdke> kirkland: just to followup on something you mentioned in your recent email to the list: wiki.ubuntu.com isn't a documentation site. Unofficial ubuntu documentation is on help.ubuntu.com/community
[21:18] <kirkland> mdke: whoops, my bad :-/
[21:18] <mdke> kirkland: no worries, I just wanted to clarify
[21:18] <kirkland> mdke: thanks for doing so
[21:18] <mdke> kirkland: it's not the most obvious distinction
[21:18] <kirkland> mdke: i was honing in on that guy's PPC angle, probably something we're lacking around here
[21:18] <mdke> but if you see *user* documentation on wiki.u.c (as opposed to developer documentation), then it can be tagged for moving with "CategoryDocumentation"
[21:19] <mdke> kirkland: yeah, I think that's a good idea
[21:19] <kirkland> mdke: good point, will take note
[21:19] <mdke> kirkland: by the way, awesome post on your trip to Scotland, really enjoyed reading it
[21:20] <kirkland> mdke: thanks ;-)  it was a helluva trip
[21:20] <mdke> :)
[21:20] <kirkland> mdke: you been to the north country before?
[21:20] <mdke> kirkland: briefly only, and i didn't see much unfortunately
[21:21] <mdke> I've wanted to go back, driving through it alone was pretty beautiful
[21:21] <kirkland> mdke: yeah, i can't wait to see more of it
[21:21] <kirkland> i'm ready to go back already
[21:22] <mdke> heh