 That's scary
 People are so crazy
 So someone suggested to me javascript front end dev was easy, paid well, and had a lot of free time
 Is this all true
 No.
 It depends where you work.
 The bottom of glass prints comes out like glass! :D
 Damn the Google Home sound is awesome
 you just got one?
 No the one you guys got me
 oh!  Yeah!
 Got internet last Wednesday
 it's great!
 But they gave me tv and phone for some reaon in a bundle


[07:31] <flaccid> has nixternal been around?
[07:34] <flaccid> i guess he'll be on later
[07:36] <Burgundavia> flaccid: is early morning eastern US time
[07:37] <flaccid> np
[07:37] <flaccid> i just noticed http://www.kubuntu.org/doc/index.php is broken
[07:37] <flaccid> looks like php is not parsing and wrong mime type being outputted
[15:45] <BindO> hi sorry bugging, where should I go for help with kdm on kubuntu hardy ?
[17:07] <wallan> does anyone have any advice on linking to the official docs from the community wiki? i don't want the link to break when the version changes.
[17:17] <seisen> what exactly are you linking from th official docs?
[17:19] <wallan> i was thinking about linking from https://help.ubuntu.com/community/InternetApplications to https://help.ubuntu.com/8.04/internet/C/web-apps.html
[17:32] <seisen> I not really sure how exactly do to that wallen
[17:33] <wallan> fair enough! i'll just add a link to https://help.ubuntu.com/, with instructions to navigate to the relevant section
[20:34] <wallan> can someone revert https://help.ubuntu.com/community/Applications to revision 73, please?
[20:45] <wallan> anyone?
[22:18] <wallan> anyone there who can revert a community wiki page?
[22:25] <Flannel> wallan: Whats up with it?
[22:25]  * Flannel is looking
[22:26] <wallan> this page here: https://help.ubuntu.com/community/Applications
[22:28] <Flannel> wallan: You can revert you know.
[22:29] <wallan> i keep getting this: 'You are not allowed to revert this page!'
[22:29] <wallan> as for my reasons for wanting to revert the page: the content from the page has been moved somewhere else, and has been revised substantially. i think there are some major problems with the way this material is being developed. i've spoken with the person who's making the changes, and he's consented to my suggestion that i should continue the old page in a parallel for the time being.
[22:30] <Flannel> wallan: Hmm, interesting. Well, you can do it the old fashioned way:  Raw view of rev 73, and copy/paste into a new rev
[22:30] <wallan> ah, hadn't seen the raw text option. great stuff. will do it that way. thanks Flannel!
[22:31] <Flannel> wallan: just make sure in the comment you write "reverting to 73" or whatever, or people will scratch their heads.
[22:32] <wallan> yeah, sure. :)
[23:02] <leviwine> hi, my garbage and the wheater-information is not available. and I can't add it by the panel-menu. can you helf me?


[12:51] <CodePulsar> What is the password for joining the IRC channels?
[12:51] <CodePulsar> I've registered at LaunchPad
[12:51] <CodePulsar> How can I join the sessions?
[13:04] <tsimpson-uds> CodePulsar: there is no password
[13:08] <CodePulsar> tsimpson-uds: so is the channel #ubuntu-uos-platform1 or #unbuntu-uds-platform1 ?
[13:08] <CodePulsar> I can't join the former
[13:09] <tsimpson-uds> CodePulsar: just replace -uos- with -uds- for now
[14:54] <d_ed> good afternoon all.
[14:54] <d_ed> I'm the host of the first session in 5 minutes
[14:54] <d_ed> please let me know if there are any problems with the audio/video etc.
[14:57] <CodePulsar> I hear
[14:58] <d_ed> brb, technical difficultied
[14:59] <Trevinho> d_ed: it was working actually...
[15:00] <d_ed> yeah...
[15:00] <d_ed> I realised that afterwards
[15:00] <theretard> Hey guys!
[15:00] <Trevinho> d_ed: you probably need mhall119 to create a new one
[15:01] <d_ed> done
[15:01] <d_ed> ok, please refresh
[15:02] <d_ed> ok, starting
[15:15] <d_ed> Ask me questions here: https://plus.google.com/hangouts/_/gwkgcskau3hdgbwzseyhezgew4a
[15:17] <kdeuser56> d_ed: anyway to relink it on http://summit.ubuntu.com/uos-1406/meeting/22262/kde-frameworks-libraries-for-all-qt-users/?
[15:17] <d_ed> I put it in the notes
[15:18] <CodePulsar> QUESTION: Is there a roadmap for the KDE Frameworks modularization process? What has been done, what's being worked on now, who is working on what, what needs to be done in the future, etc.
[15:18] <d_ed> CodePulsar: good question
[15:18] <d_ed> CodePulsar: mostly it's all done
[15:19] <d_ed> we're in our 3rd beta
[15:19] <d_ed> everything is already split
[15:19] <d_ed> and about to be released.
[15:20] <kdeuser56> d_ed: is it planned to merge trier 1 frameworks in Qt in the future? what about the whole k-naming in the classes?
[15:20] <d_ed> we tried where possible to merge
[15:20] <d_ed> we merged a lot
[15:21] <kdeuser56> d_ed: so after all a lot of the k-names remain, which wont change due to the api stability ... wont that cause problems?
[15:22] <CodePulsar> d_ed: awesome, I've found this page: https://community.kde.org/Frameworks/Epics/Splitting_kdelibs which also says "DONE" according to the definition mentioned there.
[15:22] <d_ed> kdeuser56: so anything still in KDE Frameworks still has a K prefix
[15:22] <d_ed> just like Qt stuff has a Q prefix
[15:23] <d_ed> we have a layer for people porting Qt4->Qt5 called KDE4LibsSupport
[15:23] <d_ed> which still has the K* class
[15:24] <d_ed> I can see some more stuff moving into Qt eventually
[15:24] <d_ed> but Qt will never contain everything, Qt would just become too big and clunky.
[15:25] <CodePulsar> From what I understand the definition of Tier1 modules is that they depend only on Qt modules, what is the definition of Tier 2/3/4 modules?
[15:25] <mgraesslin> Tier 2 may only depend on Tier 1
[15:26] <mgraesslin> + Tier 1 deps
[15:26] <mgraesslin> Tier 3 on Tier 2 and Tier 3 frameworks
[15:26] <d_ed> so KTextWidgets which contains a QTextEdit with spellchecking cannot be tier1 because it depends on Sonnet in tier 1
[15:27] <kdeuser56> d_ed: what about high resolution support in the gui related libraries?
[15:27] <d_ed> When Qt patches land that provide the devicePixelRatio then we should "just work"
[15:28] <d_ed> as most the changes happen in QStyle
[15:28] <d_ed> If anything is broken, we'll fix it there and then.
[15:30] <d_ed> CodePulsar: does that answer your question?
[15:31] <CodePulsar> d_ed: yes, thanks
[15:31] <kdeuser56> d_ed:  how do you see the relation of stuff ubuntusdk introduced like conditional layouts and kde frameworks related stuff in the future? will stuff play together well, so that one can use the best of both worlds, without being limited to one platform?
[15:32] <d_ed> kdeuser56: with 95% of stuff, they're completely unrelated.
[15:32] <d_ed> kdeuser56: in the case of plasma-framework, they might clash a bit, but I can't imagine anyone using those two together
[15:33] <d_ed> the whole point of frameworks isn't that you'd want to use all of them, it's to select the bits you do want
[15:37] <d_ed> ok, any more questions?
[15:41] <CodePulsar> d_ed: Where can we find the notes for the talk?
[15:41] <d_ed> it's on the right on http://summit.ubuntu.com/uos-1406/meeting/22262/kde-frameworks-libraries-for-all-qt-users/
[15:41] <d_ed> the link to the API is the super useful one
[15:44] <mgraesslin> the apidocs work great - I work with them every day
[15:44] <mgraesslin> (even for the API I maintain)
[15:44] <CodePulsar> OpenID Authentication Required loop
[15:47] <d_ed> CodePulsar: on the summit page?
[15:47] <d_ed> I'll post a direct link here
[15:47] <CodePulsar> yes, when trying to access the pad
[15:48] <d_ed> API docs: http://api.kde.org/frameworks-api/frameworks5-apidocs/
[15:48] <d_ed> lists what tier everything is in
[15:48] <d_ed> and the cross-platformability of it
[15:48] <d_ed> Article about Frameworks in general: http://dot.kde.org/2013/09/25/frameworks-5
[15:50] <CodePulsar> great
[15:50] <d_ed> CodePulsar: mind if I ask what you work on?
[15:55] <CodePulsar> d_ed: I haven't worked on the development of KDE as of yet, but I'm a financial contributor. I've used and use Qt at work extensively and I'm interested in contributing back to KDE, development wise.
[15:56] <d_ed> we should take this discussion outside of this channel now
[16:02] <rickspencer3> o/
[16:04] <bregma> sorry folks, looks like some technical issues are happeining....
[16:05] <FunnyLookinHat> Has the hangout video started for anyone else?
[16:05]  * lool switches to looking at some container demo  :-)
[16:05] <lool> FunnyLookinHat: 18:04 < bregma> sorry folks, looks like some technical issues are happeining....
[16:06] <FunnyLookinHat> lool, ty
[16:06] <lool> FunnyLookinHat: will certaily start in a couple of minutes
[16:07] <seb128> if we find somebody able to host a live hangout
[16:07] <seb128> seems like most of us got kicked out by google
[16:08] <dholbach> sorry for the delay - hangout should be up in a bit
[16:09] <Laney> could we do it from a personal account?
[16:09] <seb128> shrug
[16:09] <seb128> I can't even join one!
[16:09] <seb128> it's not only hosting
[16:10] <dholbach> seb128, can you use your normal @gmail.com account?
[16:10] <dholbach> everyone: ^ :)
[16:10] <bregma> have you tried turning it off and then back on?
[16:10] <bschaefer> bregma, that should work
[16:10] <seb128> let me try
[16:11] <seb128> bregma, turn what off and on?
[16:11] <Laney> haha
[16:11] <dshimer> live
[16:11] <Laney> I think that was a troll
[16:11] <seb128> oh, it works after a "clear recent activity" and log in again
[16:11] <Laney> link?
[16:12] <seb128> Laney, see query
[16:12] <Laney> thanks
[16:12] <Laney> twice even!
[16:12] <seb128> hum, I'm alone in there
[16:12] <seb128> that looks wrong
[16:12] <robruos> seb128: I see dholbach and mterry and bregma but not you
[16:13] <dholbach> finally!
[16:13] <dholbach> it just took 13 minutes to get us going!
[16:14] <dholbach> is mterry breaking up for anyone else as well?
[16:14] <bschaefer> mterry, you're going down
[16:14] <Laney> yep
[16:15] <rickspencer3> o/
[16:15] <mterry> seb128, can you hear me?
[16:15] <seb128> indeed
[16:15] <rickspencer3> maybe seb128 can take over?
[16:16] <seb128> http://cdimage.ubuntu.com/ubuntu-desktop-next/daily-live/
[16:16] <seb128> blueprint https://blueprints.launchpad.net/ubuntu/+spec/client-1410-unity8-desktop-iso
[16:17]  * Laney DONEs some items ;-)
[16:17] <rickspencer3> rats, I was looking forward to trying it out soon :)
[16:17] <Laney> it got blocked in the train by some other things
[16:17] <Laney> I think those other items are going to be flushed through quite soon
[16:19] <mterry> :(
[16:19] <mterry> :(  I keep losing connection
[16:20] <lool> seb128: FYI there's another system-image for servers session later today
[16:21] <seb128> lool, thanks
[16:23] <hanswurst> where will I be able to download the new iso? Will I be able to run it in Virtualbox in order to test it and report bugs?
[16:24] <dholbach> notes: http://pad.ubuntu.com/ep/pad/view/uos-1406-unity8-desktop-preview-image/latest
[16:24] <mterry> I'm back!
[16:24] <dholbach> sorry, http://pad.ubuntu.com/uos-1406-unity8-desktop-preview-image
[16:24] <Laney> http://cdimage.ubuntu.com/ubuntu-desktop-next/daily-live/
[16:25] <Laney> still bad
[16:25] <dholbach> mterry, you're still breaking up
[16:25] <seb128> mterry, no luck :/
[16:26] <mterry> You can't hear me?
[16:26] <mterry> I can hear you, weird
[16:26] <mterry> Well, give me the greeter work items anyway  :)
[16:26] <dholbach> mterry, I believe that's what's happening in the pad already :-P
[16:27] <xnox> hello?
[16:27] <rickspencer3> seems that mterry is not having good luck with hanging out today :)
[16:27] <xnox> is this thing on?!
[16:27] <rickspencer3> xnox, you forgot to tap it first
[16:27]  * rickspencer3 tap tap tap
[16:27] <dshimer> QUESTION: When will this be at a point where a casual but interested user could download install (or run from a live ISO) and report experiences on varying hardware?
[16:27]  * xnox I LOVE ROCK&ROLL
[16:27] <mterry> Guh, there goes my video
[16:28] <Guest22379> Am I understanding correctly, that there will be 2 Ubuntu "Desktop" Versions for 14.10, one running Unity7 and one running Unity8 (Ubuntu Desktop Next)?
[16:28] <dholbach> xnox, want to join the hangout too?
[16:28]  * mterry gives up
[16:28] <bregma> dshimer, "soon" but with the caveat that Mir is still not yet supported on proprietary binary video drivers
[16:29] <xnox> Laney: installer tests would be easy to test -> cause it would be ubiquity preseeding and AP tests
[16:29] <Laney> xnox: what does the pending stuff?
[16:29] <dholbach> Guest22379, unity8 currently just works on the phone and tablet, the discussion is about offering an optional desktop session image for the release, so we can test and play around with this more easily, etc
[16:29] <Laney> or, what tests does it run?
[16:29] <xnox> Laney: desktop live-session is never tested, but rather a system is installed, booted and then after the reboot the "typical user account" is tested for basic functionality
[16:29] <xnox> Laney: yes, some of these tests block pending -> current migration
[16:29] <Laney> no testing of live?
[16:30] <xnox> Laney: all automated preseeding must pass
[16:30] <xnox> Laney: plus desktop tests post install must also pass
[16:30] <xnox> (which also includes e.g. OEM)
[16:30] <xnox> Laney: there is no way to test live-session (try-ubuntu) at the moment.
[16:30] <xnox> bregma: correct
[16:30] <Laney> okay
[16:30] <Laney> I think installing should work
[16:30] <Laney> so it's probably alright to re-use some of this
[16:31] <xnox> bregma: i can work on the installer
[16:31] <dholbach> xnox, want to join the session?
[16:31] <xnox> bregma: Laney: .... if gtk3-mir support is built into that image, e.g. via a ppa?!
[16:31] <xnox> dholbach: nah, i have bad hair day
[16:31] <Guest22379> will there be a session dedicated to the visual design of unity8 on the desktop. I take it there will be some changes compared to unity7
[16:31] <Laney> installing in only-ubiquity by now
[16:31] <dholbach> oh well, I tried
[16:32] <Laney> s/by/for/
[16:32] <xnox> seb128: feel free to give some of them to me (e.g. installer / testing etc....)
[16:32] <seb128> xnox, thanks
[16:32] <Laney> I don't know when gtk3 will be ready, but I don't expect installnig from the live session to be a priority at the start
[16:33] <xnox> Guest22379: this is pure engineering session, rather than design/ux/etc
[16:33] <seb128> mterry, do you plan to look at making the phone greeter work on desktop?
[16:34] <seb128> the few bugs we talked about in Malta that need to be fixed at least
[16:34] <mterry> seb128, I added a work item to the BP for it
[16:34] <seb128> mterry, ok, I'm taking notes on http://pad.ubuntu.com/uos-1406-unity8-desktop-preview-image
[16:34] <seb128> workitems as well
[16:34] <mterry> seb128, priority is phone, but I want to fix this for desktop too obvi
[16:34] <mterry> seb128, oh ok
[16:34] <seb128> k
[16:35] <seb128> that didn't seem to be too much work, we just tweaked the qpa and some other minor things
[16:35] <xnox> Laney: does desktop-next image auto-logins now? (as in did your patches land?!)
[16:35] <Laney> not yet
[16:35] <Laney> train delays
[16:35] <Laney> leaves on the line or something like that
[16:35] <xnox> Laney: ack, but i guess it can't boot into "only-ubiquity" can it?
[16:36] <Laney> can't?
[16:36] <Guest22379> how can I help with testing?
[16:36] <Laney> it probably can, you select that before booting
[16:36] <Laney> but I haven't tried it I'm afraid
[16:36] <xnox> Laney: because there is no X & ubiquity doesn't have X dependency
[16:36] <Laney> no X ?http://cdimage.ubuntu.com/ubuntu-desktop-next/daily-live/pending/utopic-desktop-amd64.manifest
[16:36] <xnox> Laney: (even if that would be on the image only and not actually installed to disk, nor runable in the live-session)
[16:37] <xnox> Laney: ok.
[16:37] <xnox> Laney: so i should get cracking on the installation front.
[16:37] <Guest22379> is there a version of apport or similiar for this image?
[16:37] <xnox> bregma: $ ubuntu-bug ubiquity
[16:37] <xnox> bregma: if the iso doesn't boot, doesn't install, crashes live session ^
[16:37] <leftyfb> I'm just jumping into the session now ....  will MIR be able to do X forwarding? As in over ssh? That's a feature I use very often.
[16:37] <xnox> bregma: all should go to ubiquity, and then redirect =)
[16:39] <seb128> dholbach, thanks for hosting
[16:39] <dholbach> leftyfb, not sure if people know, but you could try asking on #ubuntu-mir as well
[16:39] <seb128> mterry, way to sneak out!
[16:39] <dholbach> seb128, anytime
[16:39] <mterry> :)
[16:39] <mterry> seb128, dholbach: sorry about that!  Thanks for saving me
[16:41]  * mterry goes to a coffee shop for better internet  :(
[16:41] <rtwert> is there a login and pw for the new image
[16:42] <rtwert> i just installed it and can't get past the greeter
[18:59] <stgraber> https://plus.google.com/hangouts/_/hoaevent/AP36tYdKGQui2ypMnKFITIpq_WXCp2VL6hBywLvxBs38a4xtIRLfVw?authuser=0&hl=en
[19:00] <jamespage> o/
[19:00] <stgraber> hangout url is https://plus.google.com/hangouts/_/hoaevent/AP36tYdKGQui2ypMnKFITIpq_WXCp2VL6hBywLvxBs38a4xtIRLfVw?authuser=0&hl=en
[19:01] <cjwatson> Do we have a G+ link?
[19:01] <stgraber> https://plus.google.com/hangouts/_/hoaevent/AP36tYdKGQui2ypMnKFITIpq_WXCp2VL6hBywLvxBs38a4xtIRLfVw?authuser=0&hl=en
[19:01] <barry> stgraber: i got an error with that one
[19:02] <cjwatson> wfm
[19:03] <barry> dang
[19:03] <asac> o/
[19:03] <stgraber> https://plus.google.com/hangouts/_/hoaevent/AP36tYdKGQui2ypMnKFITIpq_WXCp2VL6hBywLvxBs38a4xtIRLfVw?authuser=0&hl=en
[19:04] <dholbach> you are live! :)
[19:04] <barry> yeah, it keeps erroring on me.  guess i'll just particpate this way
[19:04] <lool> I also have bandwidth issue
[19:05] <lool> cant open the ho, but will see the yt stream
[19:11] <lool> cant we handle everything from a specific initrd rather than relying on bootloader?
[19:11] <lool> like, checking system files to decide between recovery and regular boor
[19:11] <lool> *boot
[19:15] <lool> stgraber: is it worth discussing the UID changes issue? this happened again in recent images
[19:16] <stgraber> lool: I don't think so, this isn't really server specific but a generic issue we need to resolve
[19:19] <gQuigs> I don't quite understand the benefit of this for the server...  we want servers to go towards no reboots as opposed to more...
[19:19] <lool> gQuigs: the point is avoiding the random combinations of packages breaking the upgrade
[19:19] <lool> a single wholesale upgrade from v1 of the OS to v2
[19:20] <gQuigs> lool: oh
[19:20] <gQuigs> can we do kexec to the next image then?
[19:20] <lool> also, more efficient as you're not running all the upgrade scripts, just applying a big OS delta
[19:20] <lool> gQuigs: linux is just one thing, most of the system image bits are to update all OS files
[19:20] <gQuigs> lool: this only works if people are upgrading in about the same timeframe?
[19:21] <lool> gQuigs: we keep a set of deltas; this is flexible to any base version scheme we want to support; worst case you download a full image
[19:21] <lool> that is, you download the whole v2 files
[19:21] <gQuigs> lool: cool :)
[19:21] <cjwatson> I think in general FWIW this is mainly aimed at some very limited use cases, certainly for now
[19:21] <cjwatson> more like the kind of embedded server arena
[19:22] <gQuigs> cjwatson: ah, ok
[19:22] <barry> the question then is whether the embedded server target market will have that slow bios step
[19:22] <cjwatson> not that I want to limit people's creativity but it might help to keep the scope fairly narrow so that it's achieveable ...
[19:22] <barry> not that embeddeds are super fast rebooters
[19:22] <lool> barry: server BIOSes are not super fast
[19:23] <barry> lool: right
[19:23] <cjwatson> understatement
[19:23] <barry> but e.g. your fridge might not have a bios :)
[19:23] <lool> perhaps I'm unlucky, but it seems to me server boot is designed to be debuggable and reliable and hence is slow
[19:24] <gQuigs> +1 on the LXC juju idea
[19:24] <lool> I wonder whether we ought to design something more along the lines of super minimal linux + initrd that is only rarely rebooted, and system-image updates of containers started by this minimal linux + initrd; linux+initrd only updated/restarted less frequently
[19:24] <lool> ah well, I'm lagging I guess :)
[19:25] <gQuigs> would one of the goals be to make it easy for an end user to customize an image to their need?
[19:26] <gQuigs> (aka for a deployment to 1000 embeded nodes)
[19:26] <barry> gQuigs: not a goal per se, but doable
[19:27] <barry> we already have people experimenting with custom images for touch
[19:27] <gQuigs> barry: awesome :)
[19:30] <lool> do we have the list of clicks we want to demo this way?
[19:31] <jdstrand> that is what we do with apparmor
[19:31] <jdstrand> (use an intermediate format for something on the system)
[19:32] <cjwatson> right
[19:32] <cjwatson> lool: well, I doubt any existing click packages would be appropriate
[19:34] <lool> cjwatson: sorry, I was asking which services we would want to clickify (see pad)
[19:34] <jdstrand> currently, apps must do upgrades themselves
[19:35] <jdstrand> (eg, if an app changes frameworks, it is expected to handle that upgrade itself)
[19:35] <jdstrand> (eg, db formot change)
[19:36] <jdstrand> s/formot/format/
[19:36] <asac> jdstrand: iirc we said click might grow hooks for this stuff, yes
[19:36] <jdstrand> sure, just saying what the state is now
[19:36] <asac> for restart, data migration etc.
[19:36] <lool> hmm
[19:37] <asac> right, for daemons we surely need to do something
[19:37] <jdstrand> yeah
[19:37] <asac> lool: you disagree?
[19:37] <cjwatson> right, though I want to steer away from the maintainer script path
[19:37] <asac> :)
[19:37] <asac> yes!!
[19:37] <asac> please no free form scripts :)
[19:37] <jdstrand> indeed
[19:37] <cjwatson> but we need something for data migration
[19:37] <asac> just export: i am a daemon that needs restart :)
[19:37] <cjwatson> no there definitely has to be some capability for free-form
[19:37] <cjwatson> but just not in the same way
[19:37] <asac> yeah, data migration for sure
[19:38] <cjwatson> I don't think we can do fully declarative data migration :)
[19:39] <cjwatson> restart of course can be declarative and in fact shouldn't even need declaring
[19:39] <cjwatson> if your package ships a service and it's upgraded, it fairly obviously wants to be restarted IMO
[19:40] <cjwatson> and we just delegate the hard work of that to systemd
[19:40] <barry> cjwatson: it's possible you want to apply update now but reboot at a more convenient time
[19:40] <barry> *restart
[19:40] <cjwatson> reboot yes, restart individual service I don't really think so
[19:40] <cjwatson> we restart services on dpkg upgrades today
[19:41] <barry> true.  yeah possibly so
[19:41] <cjwatson> and it's generally a lot less confusing than not doing so :)
[19:41] <asac> cjwatson: right, but arent there services that need to be stopped before the unpack (preinst) and other services that just get restarted after?
[19:42] <cjwatson> it's more a question of services that need to stay down for only short periods of time if at all, and ones where it doesn't matter
[19:42] <lool> hmm should be different dirs anyway
[19:42] <cjwatson> I think in the system-image/click model, just restarting everything after upgrade would be fine
[19:42] <cjwatson> bearing in mind that the library linkage graph is much simpler
[19:43] <cjwatson> any libraries you need are either in the click package, or they're applied en masse by the system-image upgrade
[19:45] <asac> just note down what needs doing and who would be best, we figure out priority etc. later :)
[19:45] <lool> happy to help there
[19:48] <rsalveti> yup, would be fine to do some clean up
[19:49] <rsalveti> but it'll change a bit as well once we start supporting the device with a proper partitioning scheme
[19:56] <asac> yeah, idea was to get a fully usable system on usb key (including upgrades)
[20:01] <asac> thanks!
[20:01] <rsalveti> thanks
[20:01] <asac> stgraber: slangasek: mvo: jamespage: cjwatson: ^ thanks ^
[20:01] <asac> have to review notes if something big was missing :)


[08:15] -queuebot:#ubuntu-ci-eng- mitya57, https://bileto.ubuntu.com/#/ticket/3330 Preparing packages
[09:15] -queuebot:#ubuntu-ci-eng- mitya57, https://bileto.ubuntu.com/#/ticket/3330 Successfully built


[00:45] <ovnicraft> hi folks, in translation process project i get full access but i am not the owner, i uploaded a translation, the owner must be approve?
[04:39] <cjohnston> IS there someone who could remove my eMail address from a question in launchpad please?
[05:16] <wgrant> cjohnston: You're not likely to find an admin around here at the moment. It's both a weekend and the end of year break.
[05:16] <wgrant> cjohnston: Ask at https://answers.launchpad.net/launchpad/+addquestion
[07:24] <TheUni> is there any way (email/rss/xmlrpc) to be notified when a new build succeeds? can't find anything at the moment
[07:30] <wgrant> TheUni: Not at the moment, no.
[07:30] <wgrant> TheUni: But you could poll easily using the API.
[07:32] <TheUni> hmm
[07:32] <TheUni> seems an rss would be a rather basic feature these days
[07:32] <TheUni> though i suppose i could write a basic poller
[07:32] <wgrant> LP has lots of RSS feeds. But not for builds.
[07:33] <wgrant> (yet)
[07:33] <TheUni> k
[11:40] <pkern> Hi, is it possible to drop a dists/<suite> dir from a PPA or will that happen automatically after some time?  We won't be publishing binaries for that suite anymore and want to "notify" our users about that.
[11:52] <wgrant> pkern: It will not happen automatically. It could only be done by a sysadmin.
[12:00] <pkern> wgrant: Thanks, I'll open a question then.


[00:40] <davecheney> thumper: http://paste.ubuntu.com/11759872/
[00:40] <davecheney> this morning's results
[00:40] <davecheney> there are three packages with races remaining
[00:40] <davecheney> 2 of them are going to be involved fixes
[00:54] <mup> Bug #1467712 opened: cmd/jujud/agent: data race in test <juju-core:New> <https://launchpad.net/bugs/1467712>
[01:04] <thumper> hmm
[01:12] <mup> Bug #1467715 opened: worker/peergrouper: data race in package <juju-core:New> <https://launchpad.net/bugs/1467715>
[01:13] <davecheney> thumper: this one is worse https://bugs.launchpad.net/juju-core/+bug/1467715
[01:13] <mup> Bug #1467715: worker/peergrouper: data race in package <juju-core:New> <https://launchpad.net/bugs/1467715>
[01:13] <thumper> davecheney: what's it doing?
[01:18] <davecheney> there are lots of races here
[01:18] <davecheney> it looks like an internal slice has been leaked to the caller
[01:18] <davecheney> and the caller is sorting it
[01:19] <natefinch> ouch
[01:19] <davecheney> _but_ the race only happens when the test fails
[01:20] <davecheney> and these are failures we've seen in ci
[01:20] <davecheney> if the test passes, there is no race
[01:20] <davecheney> \o/
[01:20] <thumper> natefinch: happy birthday from the future
[01:21] <natefinch> thumper: thanks! :)
[01:21] <natefinch> davecheney: lol
[01:22] <davecheney> \o/ yes, stop working, go and have a birthday
[01:26] <natefinch> Any time I don't have any kids in the same room with me, it's a party ;)
[01:26] <anastasiamac> \o/
[01:42] <perrito666> natefinch: aw, I am too lazy to wait until midnight to tell you hb, can I leverage the fact that most of my team is in tomorrowland and wish you a hb now?
[01:43] <natefinch> perrito666: haha, sure :)  Thanks :)
[02:09] <davecheney> thumper: menn0 https://github.com/juju/juju/pull/2624
[02:09] <davecheney> just a small one
[02:11] <wallyworld> thumper: want a bug to fix as part of your bug squad fun and games?
[02:45] <menn0> davecheney: looking now... was having lunch
[02:47] <menn0> davecheney: Ship It (although I see you were merging anyway)
[02:52] <thumper> wallyworld: what is it?
[02:53] <wallyworld> thumper: bug 1467690
[02:53] <mup> Bug #1467690: inconsistent juju status from cli vs api <canonical-bootstack> <juju-core:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1467690>
[02:53] <thumper> ha...
[02:54] <thumper> I'm addressing ci blockers first
[02:54] <wallyworld> i did some diagnostics, should be easy to demo using a test and then fi
[02:54] <wallyworld> ok
[02:54] <thumper> I"ll make sure it is on the list...
[02:54] <wallyworld> i might get time today
[02:55] <wallyworld> if not, tonight
[03:08] <thumper> ...
[03:08] <thumper> [LOG] 0:00.122 ERROR juju.service.systemd invalid conf for service "jujud-machine-99": relative path in ExecStart (C:/Juju/lib/juju/init/jujud-machine-99/exec-start.sh) not valid
[03:08] <thumper> this error message is all sorts of wrong
[03:09] <thumper> log says vivid machine, tests running on windows
[03:09] <thumper> pretty sure ExecStart shouldn't be C:/ ...
[03:10] <thumper> WTF...
[03:11] <thumper> test is weird
[03:11] <thumper> says "Series": "quantal"
[03:11] <thumper> but tools "1.2.3-vivid-amd64"
[03:11] <thumper> talk about confused
[03:16] <davecheney> thumper: i can xplain that
[03:16] <davecheney> we fake the series most of the time
[03:16] <davecheney> and i know that those faked fixtures are reused many times
[03:16] <davecheney> this is why I get so cross about version.Version being reused
[03:16] <davecheney> this is the same problem
[03:17] <thumper> ugh
[03:17]  * thumper looks for the code that is obviously screwing up
[03:24]  * thumper sighs
[03:29] <davecheney> thumper: is the build blocked ?
[03:30] <thumper> davecheney: yeah, looking at the blocker now
[03:30] <davecheney> someone just marked it invalid
[03:30] <thumper> I actually have a useful stack trace from the failure
[03:31] <thumper> davecheney: someone did for trunk, it really shouldn't be invalid
[03:31] <thumper> I'm looking at 1.24 first
[03:32] <thumper>  (╯°□°）╯︵ ┻━┻)
[03:32] <thumper> FAARRRRKKK!!!!!!!!!!!!!!!!!!
[03:32] <thumper> davecheney: EXACTLY what you said before
[03:32] <thumper> version.Current used for the wrong thing
[03:32]  * thumper wants to stab someone
[03:33] <thumper> systemd support
[03:34]  * davecheney pats thumper on the back
[03:34]  * davecheney leaves a little post it "i told u so"
[03:35] <davecheney> thumper: the mess may be partly my fault
[03:35] <davecheney> or at least
[03:35] <davecheney> i was the last person to try to patch over the horror
[03:36] <davecheney> if you find a bit of code that snifs aroud the version string, then astudiously overwrites parts of it
[03:36] <davecheney> that was my fault
[03:36] <davecheney> that was what we needed to do to get ppc64 working for T
[03:40] <thumper> no...
[03:40] <thumper> this is just blatently using version.Current.Series to work out the datadir for the systemd data directory
[03:40] <thumper> which is wrong in so many ways
[03:41] <thumper> works by accident for all juju devs using ubuntu
[03:45] <thumper> trying to find the point to insert the right info
[03:47] <menn0> thumper: the existing debuglog API handler doesn't stop if the API server stops... i've fixed that but am now wondering if that was intentional
[03:47] <menn0> thumper: do you happen to remember?
[03:47] <thumper> oversight
[03:47] <thumper> it should
[03:47] <menn0> good :)
[03:55] <menn0> thumper: the final signficant db-log PR is ready... just doing some manual testing
[03:55] <thumper> kk
[03:55]  * thumper headdesks
[03:56]  * thumper raises head high
[03:56] <thumper> WWWHHHYYY!!!!!
[03:57]  * thumper wonders how much of a hatchet to wield
[03:58] <menn0> thumper: what's broken?
[03:59] <thumper> service detection code
[03:59] <thumper> inappropriate structures passed around because it happens to have a few useful fields
[04:01] <davecheney> when the only field you have is a hammer, everything looks like a hammer
[04:01] <davecheney> 13:40 < thumper> this is just blatently using version.Current.Series to work out the datadir for the systemd data directory
[04:01] <davecheney> ^ this, now you feel my rage
[04:01]  * thumper nods
[04:04] <davecheney> thumper: how can I help ?
[04:04] <davecheney> can i fetch you a refreshing clue bat ?
[04:05] <thumper> find whoever added Version.OS and use the clue bat on them
[04:05] <thumper> there is NO compelling reason to have it AFAICS
[04:06]  * thumper sharpens the hatchet and wades into the code
[04:06]  * thumper starts with service...
[04:06] <davecheney> thumper: I'm sensing a theme for next weeks bug fixing
[04:07]  * thumper sobs while hacking
[04:11] <menn0> Achievement unlocked! Menno Smits got review request #2000!
[04:11] <menn0> thumper: http://reviews.vapour.ws/r/2000/
[04:16] <anastasiamac> menn0: well done! today is the day to get lotto, i guess :D
[04:28] <mup> Bug #1404946 changed: charm-upgrade hangs forever <canonical-bootstack> <upgrade-charm> <juju-core:Expired> <https://launchpad.net/bugs/1404946>
[05:07] <thumper>  (╯°□°）╯︵ ┻━┻
[05:10] <mup> Bug #1467753 opened: cmd/jujud/agent: multiple data races detected <juju-core:New> <https://launchpad.net/bugs/1467753>
[05:17] <thumper> davecheney: the map ordering problem is in the coreos/systemd repo
[05:17] <davecheney> oh
[05:17] <davecheney> dear
[05:17] <thumper> hazaah
[05:18] <davecheney> github.com/coreos/systemd ?
[05:18] <thumper> aye
[05:18] <thumper> go-systemd
[05:18]  * thumper hacks and slaches
[05:18]  * thumper grabs a copy of the serialization code
[05:21] <menn0> thumper: another one: http://reviews.vapour.ws/r/2001/
[05:22] <thumper> menn0: sorry, been stuck on the ci blocker
[05:22] <menn0> thumper: no worries
[05:22]  * thumper copies code from the go-systemd package for now
[05:22] <menn0> these can wait
[05:28] <thumper> pfft...
[05:29] <thumper> the tests inside coreos/go-systemd/unit don't actually pass
[05:29] <thumper> and can't pass if you look at the fucking code
[05:29]  * thumper rages
[05:42] <thumper> anyone http://reviews.vapour.ws/r/2002/
[05:42] <thumper> this fixes the current ci blocker, which fails on windows and ppc
[05:42]  * thumper has to go help with dinner now.
[07:30] <davecheney> ping, who's on call reviewer tonight ? http://reviews.vapour.ws/r/2003/
[07:37] <wallyworld> fwereade: are you happy with horatio's latest uniter related PR? it looks ok at first read but i'm sure i won't pick up any subtle issues http://reviews.vapour.ws/r/1979
[07:38] <wallyworld> fwereade: also, i need to talk to you later about idle time - i really want to leave it at 2 seconds otherwise status will be wrong a lot more often that it is right and so far it seems to be working fine in practice
[07:38] <fwereade> wallyworld, thanks for the reminder, looking now
[07:38] <dimitern> davecheney, me; looking
[07:40] <dimitern> davecheney, ship it
[07:41] <fwereade> wallyworld, so what I am mainly concerned about is that having an idleness timer that is higher-resolution than the event timer is going to lead to pathological flickering back and forth in certain circumstances
[07:41] <fwereade> wallyworld, nothing-to-do-ohwait-look-nothing-to-do-oh-wait-look
[07:42] <fwereade> wallyworld, and while the ideal is swift convergence to reliable values
[07:42] <fwereade> wallyworld, I would prioritise the reliability over the swiftness
[07:44] <fwereade> wallyworld, and as it stands even the best possible timings for relation chatter mean we can't reasonably infer that relation chatter has finished until at *least* 10s have elapsed, if not 15s
[07:50] <rogpeppe1> fwereade: do you by any chance know how to turn on juju feature flags within tests?
[07:52] <davecheney> dimitern: thanks
[07:53] <davecheney> select {} is more like time.Sleep(some massive int)
[07:53] <davecheney> but you don't need to import the time package
[07:53] <dimitern> davecheney, I see - interesting trick though :)
[07:53] <davecheney> maybe it could be written as
[07:53] <davecheney> for { runtime.Sched() }
[07:53] <davecheney> maybe
[07:54] <davecheney> which might have the same result
[07:54] <davecheney> but probably not
[07:55] <dimitern> so a goroutine using select{} is just not running and it's not scheduled
[07:55]  * fwereade scratches head at rogpeppe1, I did it once, possibly via SetFlagsFromEnvironment?
[07:55] <davecheney> yeah
[07:55] <fwereade> rogpeppe1, it seemed a bit janky but doable
[07:55] <rogpeppe1> fwereade: finally found it, yes
[07:55] <rogpeppe1> fwereade: seems like there should be a SetFlags call really
[07:56] <rogpeppe1> davecheney: out of interest, how was the deepCopy function failing?
[07:59] <rogpeppe1> davecheney: (i think it was me that suggested that solution and I'm interested to know why it went wrong, and particularly so if it triggered some kind of race condition)
[08:01] <davecheney> it didn't appear to be duplicating slices properly
[08:01] <davecheney> http://paste.ubuntu.com/11759941/
[08:02] <davecheney> here is the race failure
[08:02] <rogpeppe1> davecheney: how is that possible?
[08:03] <rogpeppe> davecheney: there's no connection between old and new values
[08:03] <rogpeppe> davecheney: as the entire thing gets marshaled and unmarshaled to a byte slice
[08:03] <davecheney> i dunno
[08:03] <davecheney> but taking it out and doing it by hand fixed the issue
[08:03] <rogpeppe> davecheney: there's much more likelihood of getting it wrong by doing it manually
[08:04] <rogpeppe> davecheney: your manual copy doesn't actually copy as much
[08:04] <davecheney> once we have the race's fixed
[08:04] <davecheney> we
[08:04] <davecheney> we'll have a voting race build which will double check our work
[08:04] <rogpeppe> davecheney: please try to take the time to understand *why* a race is happening rather than papering over the cracks
[08:07] <rogpeppe> davecheney: i don't believe that deepCopy routine was at fault here, and by *not* deep copying, i'm concerned that there might be more potential for race conditions
[08:08] <rogpeppe> davecheney: for example, there are quite a few Member fields which are pointers and are not now being appropriately copied
[08:10] <wallyworld> fwereade: i have to go to soccer, i'll ping you later, i think we need to talk through the issue
[08:10] <fwereade> wallyworld, sgtm, enjoy
[08:11] <rogpeppe> davecheney: it's quite possible that changing the copy changed the timings so the race detector doesn't trigger (that does happen)
[08:15] <rogpeppe> davecheney: i have a feeling that the change that actually fixed the issue was probably your changes on lines 111, 397 and 398
[08:15] <rogpeppe> davecheney: as that means that the watcher won't trigger initially
[08:16] <rogpeppe> davecheney: which actually breaks the expected watcher semantics, i think
[08:31] <fwereade> rogpeppe, I think you're right there, not having looked at the actual CL
[08:32] <rogpeppe> fwereade: i'm just looking at the race, trying to see what's actually going on
[08:36] <rogpeppe> fwereade: ah, i think i understand the issue
[09:05] <jam> fwereade: standup?
[09:05] <fwereade> jam, oops, where does the time go, just a sec
[09:23] <rogpeppe> fwereade, dimitern: an alternative fix for the peergrouper race: https://github.com/juju/juju/pull/2631
[09:25] <fwereade> rogpeppe, assertMembers change LGTM, I trust that the rest is just reverts :)
[09:25] <rogpeppe> fwereade: thanks. yes, that's the case.
[09:25] <rogpeppe> fwereade: the peergrouper package is full of intermittent failures though. i don't remember it being like that before :)
[09:26] <rogpeppe> fwereade: but probably it was all my fault
[09:26] <fwereade> rogpeppe, I sort of doubt it actually
[09:26] <fwereade> rogpeppe, races and suchlike do seem to get inserted quite a lot during "maintenance" :/
[09:27] <rogpeppe> fwereade: yes, it's easy to do when the invariants aren't spelled out, which they probably should be better done in this package
[09:28] <TheMue> fwereade: did I get you right? create a type in ipaddress.go which implements the three according methods (code moving) and embed it into State?
[09:28] <rogpeppe> fwereade: and to be fair the testing style in worker/peergrouper is quite experimental
[09:29] <rogpeppe> dimitern: i'd appreciate your take on this, as you signed off on the original PR http://reviews.vapour.ws/r/2003/
[09:29] <rogpeppe> dimitern: oops, http://reviews.vapour.ws/r/2005/ of course
[09:30]  * rogpeppe tries to avoid getting sucked into Fixing All The Things.
[09:41] <fwereade> TheMue, I'd prefer explicit access over embedding, but, yeah
[09:41]  * fwereade feels rogpeppe's pain
[09:45] <dimitern> rogpeppe, looking
[09:45] <rogpeppe> dimitern: thanks
[09:50] <perrito666> Fwereade tx for the review I will look at it in depth when I get to something bigger than my phone
[09:55] <TheMue> fwereade: ah, ok, I prefer explicit too. better to maintain and no available methods where don't directly can see where they are implemented
[10:11] <natefinch> rogpeppe: if you have time today, I'd love a review of deputy, since it's in a relatively final state.  Here's a PR that has the full code for review: https://github.com/juju/deputy/pull/1
[10:14] <evilnick> natefinch, the internet tells me it is your birthday today. If true, Happy Birthday :)
[10:15] <natefinch> evilnick: the internet is correct, as it always is ;)  Thanks! :)
[10:16]  * natefinch is having leftover cake from father's day for breakfast :D
[10:23] <mup> Bug #1467873 opened: leadership lost during service teardown <juju-core:New> <https://launchpad.net/bugs/1467873>
[10:38] <davecheney> rogpeppe: thanks for revertin that
[10:38] <davecheney> i was just about to do that
[10:39] <rogpeppe> davecheney: np
[10:39] <rogpeppe> davecheney: there are a few other intermittent failures in peergrouper that would be nice to get to the bottom of
[10:40] <rogpeppe> davecheney: i'm also seeing something that looks like a go bug, but i think that's probably a feature of tip only
[10:41] <davecheney> ok, i'll try again tomorrow once the revert lands
[10:54] <rogpeppe> natefinch: reviewed
[10:57] <natefinch> rogpeppe: awesome, thanks!
[11:04]  * natefinch just realized that he mocked out os.Exit, and his code is relying on it to terminate the function it's in.
[12:11] <rogpeppe1> does anyone know what should be the restrictions on the format of environment names?
[12:13] <rogpeppe1> looks like it can't contain / or \, but other than that, i guess anything should be ok
[12:37] <rogpeppe1> another random question without much hope of answer: anyone know what proxy.Settings.NoProxy is for?
[12:45] <axw> rogpeppe1: pretty sure it's used for "no_proxy", as in wget and friends
[12:45] <rogpeppe1> axw: ah, i didn't know about that - guess i should've google it :)
[12:45] <rogpeppe1> googled
[12:46] <axw> rogpeppe1: env name shouldn't contain "-
[12:47] <axw> " either I think
[12:47] <axw> otherwise tags would be broken?
[12:47] <rogpeppe1> axw: ah
[12:47] <rogpeppe1> axw: maybe that should be enforced in environs/config then?
[12:47] <rogpeppe1> axw: (currently it just checks for / and \)
[12:47] <axw> rogpeppe1: sorry, thinking of the IDs
[12:47] <axw> rogpeppe1: which are just UUIDs... never mind
[12:47] <rogpeppe1> axw: yeah, not id
[12:48] <rogpeppe1> axw: it's just that kind of thing i'm wondering about though
[12:48] <rogpeppe1> axw: as i'm just about to automatically generate an environment name, and i don't want to break things
[12:53] <rogpeppe1> axw: i'm also trying to see a way forward to being able to call Provider.PrepareForCreateEnvironment on the server side not the client side
[12:55] <axw> rogpeppe1: what's preventing that?
[12:55] <rogpeppe1> axw: logic that gets env vars
[12:56] <axw> ah
[12:57] <rogpeppe1> axw: the real bad apple here is the local provider which does all kinds of shenanigans, running commands etc
[12:58] <rogpeppe1> axw: which in a way doesn't matter (who wants to run multi environments locally anyway) but it would be nice to have it working for tests
[12:58] <rogpeppe1> s/anyway/anyway?/
[13:02] <rogpeppe1> axw: BTW do you think it's reasonable for someone to be able to specify a specific agent-version setting when creating a new environment in a JES?
[13:03] <axw> rogpeppe1: I don't see why anyone would want to, but does allowing it (within reason) make something difficult?
[13:03] <rogpeppe1> axw: just wondering - it could potentially be awkward i guess, if someone uses an incompatible agent version
[13:05] <axw> rogpeppe1: ok. I'm not sure, sorry, better to ask thumper
[13:05] <rogpeppe1> axw: you don't by any chance know off-hand what OS context the local provider's jujud runs in, do you?
[13:05] <axw> rogpeppe1: what OS context? not sure what you mean by that
[13:06] <rogpeppe1> axw: will it see the same environment variables that the user had when they bootstrapped?
[13:06] <axw> rogpeppe1: ah. I don't think so - pretty sure we just write an upstart/systemd conf, and env vars won't generally be preserved
[13:07] <rogpeppe1> axw: ah, ok so we really do need to do all that stuff locally
[13:08] <axw> rogpeppe1: what exactly do you want to do server-side? generate the complete env config?
[13:09] <rogpeppe1> axw: yes, to the greatest extent possible
[13:09] <axw> rogpeppe1: and then something could, say, fetch the config into a .jenv file to run?
[13:29] <mup> Bug #1467374 changed: worker/uniter/filter: ci test failure <juju-core:Triaged> <https://launchpad.net/bugs/1467374>
[13:29] <mup> Bug #1456763 opened: TestUnitRemoval fails <ci> <intermittent-failure> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1456763>
[13:47] <wallyworld> dimitern: can i have a small review to fix a 1.24.1 ritical? http://reviews.vapour.ws/r/2007/
[13:49] <wallyworld> or perrito666 ^^^^
[13:52] <perrito666> wallyworld: reviewed
[13:52] <wallyworld> perrito666: tyvm
[13:53] <wallyworld> oh, anastasiamac also did it
[13:54] <anastasiamac> wallyworld: perrito666: I just perused :D it does not really count :))
[13:54] <natefinch> rogpeppe1, axw: we should really document the format of environment names
[13:54] <perrito666> wallyworld: I am familiar with the code so mine does count :p
[13:55] <wallyworld> perrito666: it is a bad bug - affecting a paying customer site
[13:55] <wallyworld> so it seems, there were upgraded from 1.20.14
[14:02] <katco> natefinch: standup
[14:49] <rogpeppe1> natefinch: true, but environment names are getting increasingly redundant
[14:52] <natefinch> rogpeppe1: not sure I agree with that.  you still need to know what environment Juju is talking about, and if you and juju disagree on what it's called, it'll be confusing
[14:53] <rogpeppe1> natefinch: an environment can have many names
[14:54] <rogpeppe1> natefinch: it's used to tag provider machines, but now we've got ResourceTags for that
[15:00] <natefinch> rogpeppe: just thinking of reading logs etc.
[15:00] <natefinch> rogpeppe: I guess if you never have mixed logs, it's not a problem
[15:01] <rogpeppe> natefinch: the UUID is the thing that matters, not the name
[15:02] <natefinch> rogpeppe: right, but uuids are not human-friendly
[15:02] <natefinch> "wait am I supposed to be looking at environment de305d54-75b4-431b-adb2-eb6b9e546014 or 123e4567-e89b-12d3-a456-426655440000?"
[15:03] <rogpeppe> natefinch: that can easily be dealt with with a tiny amount of tooling
[15:03] <mup> Bug #1467964 opened: state still serializes external types <tech-debt> <juju-core:Triaged> <https://launchpad.net/bugs/1467964>
[15:03] <rogpeppe> natefinch: sed "s/$UUID/my-environment/g"
[15:05] <natefinch> rogpeppe: exactly the usability issue I was talking about
[15:06] <rogpeppe> natefinch: how is that a usability issue? i don't believe that all logs should be directly human readable necessarily.
[15:06] <rogpeppe> natefinch: and as i said, there is no one global name for an environment except the UUID
[15:06] <natefinch> rogpeppe: I bet our users would disagree
[15:07] <rogpeppe> natefinch: with the last fact?
[15:07] <natefinch> rogpeppe: with the fact about logs not needing to be directly human readable
[15:08] <rogpeppe> natefinch: lots of logs are in JSON format. that's not very human readable, but it's very useful and eminently toolable
[15:09] <natefinch> rogpeppe: and if we don't give an environment a human-readable when it is created, that's our own fault.  I'm not saying that name has to be globally unique.  Or even unique at all. Just human readable.
[15:09] <rogpeppe> natefinch: i'm not objecting to having a label that can be attached to an environment
[15:09] <rogpeppe> natefinch: but that's quite a different role than the environment name has traditionally played in juju
[15:10] <rogpeppe> natefinch: for example, if it's just a label, you might consider being able to change it
[15:10] <natefinch> rogpeppe: yes.  And don't get me wrong, I definitely think we need a UUID on every environment to identify it to our code.
[15:10] <natefinch> rogpeppe: just saying we should also have some kind of label for the poor sucker reading the logs at 3am
[15:12] <rogpeppe> natefinch: log size is a real problem for us. i'm not sure i'd want us to put the env name *and* the UUID in every log message
[15:13] <rogpeppe> natefinch: mostly you won't want to mix log files between environments anyway
[15:14] <natefinch> rogpeppe: yeah, that was my second thought - hopefully they never end up in the same place anyway.
[15:15] <rogpeppe> natefinch: if you *do* mix 'em, just prefix each line with the UUID and provide a trivial tool to relabel according to whatever labels you deem appropriate or just grep.
[15:29] <katco> ericsnow: you have a review (http://reviews.vapour.ws/r/1963/). nothing really wrong with the patch, but a few suggestions i think are good.
[15:29] <ericsnow> katco: thanks
[15:31] <katco> ericsnow: also, do you think bug 1466565 is related to the lxc collision issue? please don't dig into it too much if you don't know.
[15:31] <mup> Bug #1466565: Upgraded juju to 1.24 dies shortly after starting <cts> <landscape> <sts> <upgrade-juju> <juju-core:Triaged> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1466565>
[15:32] <katco> ericsnow: gah... why did rb screw up my code formatting?
[15:32] <ericsnow> katco: I was just wondering that :)
[15:32] <ericsnow> katco: did you indent the block 4 spaces?
[15:32] <katco> ericsnow: i put it between `'s with newlines
[15:32] <katco> ericsnow: i did not. is there a way to edit?
[15:32] <ericsnow> katco: no need to quote; just indent 4 spaces
[15:33] <ericsnow> katco: I don't think you can edit
[15:33] <katco> boo
[15:33] <katco> well, copy/paste to vim i suppose
[15:33] <mup> Bug #1467973 opened: uploadSuite.TearDownTest Fails <ci> <intermittent-failure> <unit-tests> <juju-core:Incomplete> <juju-core 1.24:Triaged> <https://launchpad.net/bugs/1467973>
[15:33] <ericsnow> katco: just try replying to the comment
[15:33] <natefinch> for multiline code formatting, you can do ``` before and after
[15:34] <ericsnow> katco: sorry, not sure about that bug
[15:34] <katco> ericsnow: no worries at all
[15:35] <katco> ericsnow: just thought it might spark something
[15:35] <katco> natefinch: ty
[15:35] <katco> ericsnow: updated
[15:36] <ericsnow> katco: thanks
[15:44] <katco> ericsnow: it looks like go's code relies solely on pid to get current user. good call
[15:44] <katco> ericsnow: sorry, meant uid
[15:44] <ericsnow> katco: np :)
[15:45] <natefinch> rogpeppe: about your comment on deputy for StderrLog and StdoutLog being the same... that would require a change to the API, since right now those are functions, which can't be compared, so we'd have to make them interfaces instead... which kind of complicates the package's API.
[15:46] <katco> natefinch: how's that work for the demo coming? :)
[15:47] <natefinch> katco: crap, is that this iteration? ;)
[15:48] <katco> natefinch: haha :p just a gentle nudge on priorities given we are way over capacity
[15:48] <natefinch> katco: yep
[16:10] <rogpeppe> natefinch: no, you wouldn't need to change the API
[16:11] <rogpeppe> natefinch: oh yes, you would... hmm
[16:12] <rogpeppe> natefinch: yeah, i dunno. seems a pity but no obvious solution
[16:12] <natefinch> rogpeppe: ok, sort of what I though too, just hoping you'd see something I missed.
[16:29] <katco> ericsnow: passing thought. what do you think of creating a "proccmd" package under process/context? this way, instead of "NewFooCmd(...)", it is "proccmd.Foo(...)"
[16:30] <ericsnow> katco: I had considered that before but tabled it
[16:30] <ericsnow> katco: +0
[16:30] <katco> ericsnow: lol
[16:31] <katco> ericsnow: fair enough
[16:31] <ericsnow> katco: we won't have a lot of commands, but it might still be a good idea
[16:31] <katco> ericsnow: we'll pain the bike shed at some point.
[16:31] <katco> paint
[16:31] <ericsnow> katco: k
[17:37] <katco> ericsnow: it's unclear to me how the arguments in the spec translate to the arguments passed into Init(...) for commands
[17:38] <ericsnow> katco: take a look at the register command (and registeringCommand)
[17:39] <ericsnow> katco: RegisterCommand maps onto the register command in the spec
[17:39] <katco> ericsnow: yes, i'm looking at that. however, in the spec there are options that it looks like we're not accounting for?
[17:39] <ericsnow> katco: like what?
[17:40] <katco> ericsnow: i.e. spec takes some flags, Init(...) on register only takes name, and info
[17:40] <katco> ericsnow: --definition, --extend, --override
[17:40] <ericsnow> katco: those are defined on registeringCommand
[17:40] <ericsnow> katco: which RegisterCommand embeds
[17:40] <katco> ericsnow: ah ok
[17:41] <ericsnow> katco: we did it that way expressly for the furture work on the launch command :)
[17:41] <katco> ericsnow: :) sorry i didn't see it
[17:41] <ericsnow> katco: np
[17:50] <natefinch> gah, I hate using godeps
[17:55] <fwereade> http://reviews.vapour.ws/r/2008/ if anyone's of a mind to
[19:00] <katco> ericsnow: is there a way we could have factored the use of cmd.Context out so the interface for our commands is simpler?
[19:01] <ericsnow> katco: hadn't thought about it
[19:01] <katco> ericsnow: i really dislike the chaining of suites
[19:01] <katco> ericsnow: and it's more difficult to write unit tests when we're relying on the suite chain
[19:02] <natefinch> +1 for less chaining
[19:03] <katco> ericsnow: well anyway, i'm just going to write the tests as register has, but it is causing me some discomfort ;)
[19:04] <ericsnow> katco: how so?
[19:04] <katco> ericsnow: there's too much stuffed into parent structs
[19:05] <ericsnow> katco: that's making it hard to write new tests?
[19:05] <katco> ericsnow: it's making it very easy for me to write new tests that i don't fully understand
[19:05] <ericsnow> katco: k
[19:09] <katco> ericsnow: this is the style of unit test i prefer: https://github.com/juju/juju/blob/master/leadership/leadership_test.go#L95-L108
[19:09] <katco> ericsnow: it's very easy to tell where your stubs are coming from and what they're doing
[19:11] <ericsnow> katco: so you prefer creating a new stub in each test?
[19:12] <katco> ericsnow: i like defining the functionality i'm stubbing out within the test
[19:12] <katco> ericsnow: which does require a new instance of a stub in each test
[19:14] <ericsnow> katco: while I think the discussion of what test methods should look like will be valuable, perhaps we should table it for now
[19:14] <katco> ericsnow: sure, i'm continuing with the style as it is defined, just thought you'd be interested
[19:14] <katco> ericsnow: https://plus.google.com/+KatherineCoxBuday/posts/7odKtVXgRB1
[19:15] <ericsnow> katco: I think we different opinions here but I'd like to get on the same page
[19:15] <natefinch> haha, I was going to say I agree with katco, but evidently already did back in August ;)
[19:15] <ericsnow> katco: so I'm glad you've brought it up :)
[19:16] <katco> natefinch: lol
[19:16] <katco> ericsnow: it's the perks of being on an awesome team. good discussion :)
[19:16] <ericsnow> katco: :)
[19:19] <natefinch> I don't like setuptest and setupsuite because they're not obvious enough.  It's easy to be reading a test and not understand how it works, only to find out it relies on stuff 500 lines up the file in SetupTest, but it's magic, so you can't tell from the test.
[19:19]  * natefinch looks at the setuptest and setupsuite he just wrote and winces.
[19:22] <natefinch> ericsnow: I think we made a mistake in putting ProcDetails in the plugin package.  I think it should go in juju/charm ...that way it stays in lockstep with charm.Process
[19:23] <natefinch> ericsnow: as the input and output of the plugin
[19:23] <ericsnow> natefinch: but charms have nothing to do with ProcDetails
[19:24] <natefinch> ericsnow: hrmph.... yeah.
[19:25] <natefinch> ericsnow: I was trying to avoid copying and pasting the code for serialization of ProcDetails
[19:25] <katco> ericsnow: natefinch: perhaps the notion of logical vs. physical boundaries is applicable here
[19:26] <ericsnow> natefinch: why do you have to copy-and-paste?
[19:26] <natefinch> ericsnow: I have to convert the json into a struct that the plugin code can rationalize about
[19:26] <ericsnow> natefinch: worst-case you have to import github.com/juju/juju/process/plugin
[19:26] <natefinch> ericsnow: I can't. That's not version controlled.
[19:27] <natefinch> ericsnow: anything under github.com/juju/juju can change at any time
[19:27] <ericsnow> natefinch: hmm
[19:27] <natefinch> ericsnow: that's why charm.v5 would have worked, because it *is* version controlled
[19:28] <ericsnow> natefinch: maybe *for now* it would make sense to just keep the plugin in github.com/juju/juju/process/plugin/docker
[19:29] <ericsnow> natefinch: that would buy use time to sort out the issue
[19:29] <natefinch> ericsnow: or like katco said, instead of purely logical boundaries, we use a physical boundary for this code
[19:30] <natefinch> ericsnow: the plugin code already imports charm.v5 for the Process struct, it's not unreasonable to put the ProcDetails struct there... even if it's not strictly part of charm code (it does certainly relate to charms)
[19:31] <ericsnow> natefinch: also, it's not like there's a lot of structure to what the plugin must serialize, right?
[19:31] <natefinch> ericsnow: for now, sure :)
[19:31] <natefinch> ericsnow: we can punt on it for now and I can copy pasta
[19:32] <ericsnow> natefinch: I mean there shouldn't be much copying
[19:32] <natefinch> ericsnow: there's not :)
[19:32] <natefinch> ericsnow, katco: gotta run, birthday time
[19:32] <ericsnow> natefinch: this does bring up the question of perhaps versioning the plugin serialization format
[19:32] <katco> natefinch: have fun dude
[19:33] <katco> natefinch: happy birthday to you and your wife
[19:33] <ericsnow> natefinch: happy birthday!
[19:33] <natefinch> ericsnow: we can talk later.  I do think versioning the format is a good idea. WE'll have to figure out how to do that
[19:33] <natefinch> thanks!
[19:33] <ericsnow> natefinch: I'll add a card
[19:33] <katco> ericsnow: keep in mind, versioning may be ok to fudge for the demo
[19:40] <ericsnow> katco: agreed
[20:58] <katco> ericsnow: a bit confused. is registeringCommand intended to be the base command for all commands? it seems geared towards register specifically?
[20:59] <ericsnow> katco: it's for register and launch
[20:59] <katco> ericsnow: // registeringCommand is the base for commands that register a process
[20:59] <katco> // that has been launched.
[21:00] <katco> ericsnow: maybe we should update that? it makes it seem like the process has already been launched?
[21:00] <ericsnow> katco: that's correct
[21:00] <ericsnow> katco: the launch command launches the proc via the plugin and then registers it
[21:02] <katco> ericsnow: ah i think i see now. that is intended to be called after launch does it's thing
[21:03] <ericsnow> katco: for the launch command the Run method will make the call the plugin and then call the register method with the result
[21:03] <katco> ericsnow: gotcha
[21:16] <katco> ericsnow: i'm assuming i want to convert from plugin.ProcStatus -> process.Status. is there a method defined for that already?
[21:16] <ericsnow> katco: actually you don't
[21:16] <ericsnow> katco: they are two different statuses
[21:16] <ericsnow> katco: ProcStatus is sent as-is
[21:17] <katco> ericsnow: plugin.Launch returns a plugin.ProcStatus, register wants a process.Status
[21:17] <ericsnow> katco: Status is always set to Active
[21:17] <katco> ericsnow: oh, surprising...
[21:17] <katco> ericsnow: so we just ignore the actual status from launching the plugin?
[21:17] <ericsnow> katco: Launch returns a process.Details
[21:18] <ericsnow> katco: pretty much...it's just informational (we will display it in juju status)
[21:18] <katco> ericsnow: so if plugin.Launch returns "error, this is absolutely not running", we still pass "StatusActive" to register?
[21:19] <ericsnow> katco: in that case the command should fail
[21:19] <ericsnow> katco: but that should be handled via the error return from the plugin
[21:19] <ericsnow> katco: not the status
[21:20] <katco> ericsnow: ah gotcha. so if no error is returned, we assume the plugin has done the right thing, and whatever status is displayed is representing some good state?
[21:20] <ericsnow> katco: yep
[21:20] <katco> ericsnow: k makes sense now
[21:20] <ericsnow> katco: oh good
[21:21] <katco> ericsnow: and i will comment to that effect ;)
[21:31] <alexisb> thumper, ping
[21:32] <alexisb> can you join us please
[21:32] <thumper> coming
[22:04] <katco> ericsnow: is baseCommand::getInfo().Process the correct place to get the charm.Process? it looks like that may be circular reasoning
[22:06] <ericsnow> katco: when one of our hook context commands is run the user provides the name of the process
[22:06] <wallyworld> thumper: menn0: for 1.24.2, just a reminder, don't forget to land the mgo v2 dep change once 1.24 is unlocked
[22:07] <ericsnow> katco: the base command uses that name to extract that appropriate info from the hook context
[22:07] <menn0> wallyworld: will do. thanks.
[22:07] <ericsnow> katco: after that the info is available through the info field of the base command
[22:08] <ericsnow> katco: thus you can then get the charm.Process via info.Process
[22:10] <jw4> what is required for a change to get into 1.24 at this point?
[22:10] <jw4> wallyworld, alexisb ^^ ?
[22:11] <wallyworld> jw4: what change?
[22:11] <alexisb> jw4 it needs to be a regression, critical impact
[22:11] <alexisb> jw4, why?
[22:12] <jw4> #eco is saying that bug 1457205 is blocking some critical features in CABS
[22:12] <mup> Bug #1457205: Subordinate charm Action data not reported by API <actions> <charmers> <subordinate> <juju-core:Triaged by johnweldon4> <https://launchpad.net/bugs/1457205>
[22:12] <katco> ericsnow: ok, looks like that's done through basecommand::init(...)?
[22:12] <jw4> mind you they did not ask me to escalate
[22:12] <ericsnow> katco: yep
[22:13] <wallyworld> jw4: alexisb: marco seems to be happy for it to be fixed for 1.25, what's the reason for asking about 1.24?
[22:14] <alexisb> wallyworld, it is coming up again in actions discussions
[22:14] <jw4> wallyworld: arosales just discovered that it's impacting some critical functionality with CABS
[22:14] <wallyworld> so we could target to 1.24.2
[22:14] <jw4> is there a freeze/cut-off date?
[22:14] <katco> ericsnow: am i free to make the ProcLaunchCommand ctor signature whatever, or does that conform to some function sig?
[22:15] <alexisb> jw4, is this a bug you are willing to take?
[22:15] <wallyworld> jw4: there's some upgrade issues to fix on 1.24.2 so it will be a few days i expect
[22:15] <jw4> alexisb: it's assigned to me right now - I was just expecting a more sedentary approach
[22:15] <jw4> :)
[22:15] <wallyworld> by EOW would be good
[22:16] <alexisb> wallyworld, based our discussion today in the release call I would think the release target date to be 7/3 with a freeze date a earlier in the week
[22:16] <wallyworld> for 1.24.2? that seems a way off
[22:16] <jw4> ... it's closer than it appears in the mirror
[22:17] <alexisb> well given 1,24,1 is going out tomorrow that seems very reasonable
[22:17] <alexisb> that is less then 2 weeks
[22:17] <ericsnow> katco: it has to conform to the signature expected by the registration func; so it keep it the same as NewProcRegistrationCommand
[22:17] <wallyworld> ok
[22:18] <katco> ericsnow: i.e. func(HookContext) (*ProcLaunchCommand, error)?
[22:18] <wallyworld> my hope is we get stuff fixed sooner if possible so we are not under release pressure
[22:18] <arosales> wallyworld, an issue for anyone wanting to do benchmarking with Juju and use subordinates.  We would like to make benchmarking with juju generally available next week
[22:18] <ericsnow> katco: yep
[22:18] <jw4> wallyworld: +1
[22:18] <alexisb> wallyworld, agreed
[22:18] <alexisb> arosales, that could be an issue
[22:19] <alexisb> depending on how the fix can come about
[22:19] <alexisb> ie I dont see us really 1.24.2 + fix for 1457205 before eow next week (at the earliest)
[22:19] <arosales> alexisb, Understood if it can't make next week, but we don't want benchmarking to be crippled for too long after release
[22:20] <alexisb> ok arosales noted
[22:20] <arosales> we could cavet in the release notes until 1.25, but the sooner the better so we could remove that cavet
[22:20] <wallyworld> alexisb: if we aim for EOW this week for 1.24.2 fixes, then we can try for EOW next week for a release as a goal
[22:20] <arosales> its something we (eco eng) tracking daily on our dev board
[22:20] <alexisb> wallyworld, yep
[22:21] <arosales> wallyworld, jw4, alexisb: thanks. Let us know if you need us to test anything
[22:21] <katco> ericsnow: is that sig defined somewhere?
[22:21] <wallyworld> arosales: will do. the benchmarking stuff is freaking awesoe
[22:21] <alexisb> arosales, in the bug we had an agreement for 1.25, so we will do the best we can to get it out in 1.24.2
[22:21] <jw4> arosales: will do
[22:21] <ericsnow> katco: worker/uniter/runner/factory.go?
[22:21] <marcoceppi> wallyworld: just wait until next weeks announcment ;)
[22:21] <arosales> wallyworld, ya the devX team has done some good work there
[22:22] <alexisb> and yes the benchmarking stuff is freak'n awesome
[22:22] <wallyworld> marcoceppi: yes, looking forward to it :-)
[22:22] <ericsnow> katco: look in component/all/processes.go to see how the commands get registered
[22:22] <arosales> alexisb, understood and thanks for trying to get it in earlier
[22:22] <alexisb> and marcoceppi I tweeted that "stuff" just for you ;)
[22:22] <alexisb> and because it is freak'n awesome
[22:23] <wallyworld> arosales: marcoceppi: in your announcement will you note the limitation with subordinates to folks don't get the breakage when jumping in to try it out?
[22:24] <marcoceppi> wallyworld: yes, we have a page on the juju docs we're putting up, I'll highlight that limitation there
[22:24] <katco> ericsnow: this is a little strange to me. i thought component was supposed to be the way features registered themselves? it looks like they're hard coded?
[22:25] <arosales> marcoceppi, thanks and hopefully we don't have to note it for too long.
[22:25] <arosales> keep rockin' it juju-core
[22:25] <wallyworld> +1 :-)
[22:25] <arosales> and thanks for working on https://bugs.launchpad.net/juju-core/+bug/1466629
[22:26] <mup> Bug #1466629: Containers fail to get ip when non-maas dhcp/dns is used <dhcp> <dns> <lxc> <maas> <openstack-installer> <openstack-provider> <ubuntu-engineering> <ubuntu-openstack> <juju-core:Triaged> <https://launchpad.net/bugs/1466629>
[22:26] <ericsnow> katco: they key phrase there is "register themselves"
[22:26] <ericsnow> katco: code somewhere has to make the call
[22:26] <ericsnow> katco: ergo "hard-coded"
[22:26] <katco> ericsnow: i just pictured it inverted
[22:26] <katco> ericsnow: features calling into this package to say "here i am"
[22:26] <ericsnow> katco: component/all is the intersection point
[22:27] <alexisb> arosales, I will follow-up with dimiter in the morning on https://bugs.launchpad.net/juju-core/+bug/1466629
[22:27] <mup> Bug #1466629: Containers fail to get ip when non-maas dhcp/dns is used <dhcp> <dns> <lxc> <maas> <openstack-installer> <openstack-provider> <ubuntu-engineering> <ubuntu-openstack> <juju-core:Triaged> <https://launchpad.net/bugs/1466629>
[22:27] <katco> ericsnow: this way, we have 1 package that imports the world
[22:27] <ericsnow> katco: but they have to be imported to trigger that
[22:27] <alexisb> arosales, but if logs can be provided tha twould be most helpful
[22:27] <ericsnow> katco: I went way from such import side-effects
[22:27] <katco> ericsnow: we want it inverted; every feature imports all and says "here i am"
[22:28] <ericsnow> katco: but something has to import all the components we want
[22:28] <katco> ericsnow: not if you use the registration pattern
[22:28] <ericsnow> katco: that's the way we had it before
[22:29] <ericsnow> katco: mind hopping into moonstone?
[22:29] <katco> ericsnow: sure
[22:29] <arosales> alexisb, I'll see if jcastro can reach out to the bug submitter and see if we can get a reproduction
[22:30] <alexisb> thanks arosales !
[22:43] <mup> Bug #1466660 changed: Unable to create hosted environments on EC2 <config> <ec2-provider> <juju-core:Invalid by cherylj> <https://launchpad.net/bugs/1466660>
[22:47] <mwhudson> davecheney: say um, how heavily do you think cgo on arm64 has been tested?
[22:56] <wallyworld> anastasiamac: perrito666: axw: i'll be 15 minutes late for standup as i have a clash
[22:57] <perrito666> wallyworld: ah, I hate when I have punk rock bands too
[22:57] <perrito666> :p
[22:57] <wallyworld> gawd, dad joke
[22:57] <perrito666> that was a terrible joke
[22:57] <perrito666> sorry
[22:57] <wallyworld> so you should be
[22:59] <perrito666> axw: ping me when you arrive pls
[23:00] <alexisb> cherylj, thumper ping
[23:01] <thumper> coming
[23:02]  * menn0 likes perrito666's joke #dad
[23:04] <axw> perrito666: I have arrived
[23:07] <perrito666> axw: that sounded batmanish
[23:09] <davecheney> thumper: sorry i missed the standup
[23:09] <davecheney> it's so coldhere, it's hard to get out of bed that early
[23:09] <thumper> what? down below 15°C?
[23:22] <davecheney> mwhudson: the heviest tests have probably been the ones that come with the std lib
[23:22] <davecheney> juju might exercise the glibc bindings a bit
[23:22] <mwhudson> yeah
[23:22] <davecheney> but the more escoteric stuff, nope
[23:22] <mwhudson> looking at the code, i'm a little concerned that the thread local storage used to save g over a cgo call is not, in fact, thread local
[23:22] <wallyworld> axw: here now
[23:23] <mwhudson> but i'm not sure how to check
[23:23] <axw> wallyworld: joining
[23:23] <mwhudson> davecheney: runtime·clone has the wonderful comment "// TODO: setup TLS."
[23:23] <axw> perrito666: ^^
[23:24] <alexisb> thumper, that video is awesome!
[23:24] <thumper> :-)
[23:25]  * axw is intrigued
[23:25] <alexisb> o juju core developers are so getting chairs in october
[23:25] <alexisb> https://www.youtube.com/watch?v=Y9ttBt-4vWo
[23:34] <menn0> wallyworld: reviewed your ResourceManager facade branch
[23:34] <wallyworld> menn0: ty, will look after standup
[23:35] <menn0> wallyworld: tl;dr is "ship it" :)
[23:35] <wallyworld> menn0: \o/ ty


[10:13] <tjaalton> alkisg: hwe server update pushed to ppa:canonical-x/x-staging
[10:13] <alkisg> Thank you tjaalton! I didn't have a chance to test with the live cd yet, I was trying to fix a school broken internet connection all morning :)
[10:18] <tjaalton> np, had to update it anyway


[11:59] <Angelfish> LjL yea, sorry
[11:59] <gnomefreak> anyone have any issue with new kernel? i wanna know what to look for when i reboot
[11:59] <Angelfish> LjL, http://www.kde-look.org/content/show.php?content=13969
[11:59] <lorenzo> running breezy, with apache, php5 and mysql. I installed a portal and on some of the pages (registration, feedback) there is a form with which users should be able to contact me.


[04:43] <ScottK> mamarley: Thanks.  Since debfx  tested it before, I'll let him have first crack at it.
[04:43] <ScottK> shadeslayer: Pretty sure it's OK.
[07:08] <soee> good morning
[07:32] <lordievader> Good morning.
[09:52] <yofel> can someone try to run the nepomuk kcm in 4.11.3? Here running 'kcmshell4 nepomuk' gives me a frozen window
[10:02] <soee> yofel, if you tell me that i can upgrade my machine @ work :D
[10:02] <soee> 4.11.3 officially released ?
[10:03] <vHanda> Nothing has changed in the nepomuk kcm for 4.11.3
[10:10] <valorie> released by KDE
[10:10] <valorie> ....
[10:14] <yofel> vHanda: probably, but then I wonder why it's hanging. (I was trying to stop it in an attempt to kill virtuoso)
[10:15] <yofel> if only I could tell virtuoso to not run while on battery :S
[10:15] <vHanda> Indexing doesn't run when on battery
[10:15] <vHanda> queries and all, yes. Anyway, we're working on a replacement so this should get a lot better.
[10:16] <yofel> yeah, but nepomuk isn't doing anything as far as I can tell. It's just virtuoso-t using 100% cpu
[10:16] <vHanda> then that's virtuoso going mad, just kill it
[10:16] <vHanda> It has a nack for doing that at times :/
[10:17] <yofel> yeah, SIGKILL helped :/
[10:18] <yofel> now the kcm works again ^^
[10:18] <vHanda> urgh, virtuoso
[12:59] <BluesKaj> 'Morning folks
[14:15] <Mamarok> claydoh: /me grrrmls at Basil Chupin on the ML, should we drop him a note? That guy is not even using Kubuntu
[14:21] <apachelogger> uhhh, drama?
[14:22] <apachelogger> "Your signature line tells me that you are from Holland - Utrecht, the
[14:22] <apachelogger> place where my wife's god-daughter (and our 'unofficial niece') was
[14:22] <apachelogger> married to Jarno [but both who now live in Melbourne, Australia]."
[14:22] <apachelogger> Oo
[14:24] <apachelogger> claydoh: Mamarok: ask him to refrain from posting until such time that he actually uses kubuntu maybye?
[14:24] <apachelogger> and inform him that his life story aint not belonging on no mailing list
[14:26] <BluesKaj> but he has such an interesting life , he just wants to share it with everyone :)
[14:26] <apachelogger> he can gladly share it on the facebookz or something
[14:29] <BluesKaj> I'm sure he already does , but he's more special than the rest of us so we deserve to hear all about it, don't you understand ? :)_
[14:40] <apachelogger> "Ask release team about possibility of a .10.1 ISO for kubuntu and ubuntustudio" <- ScottK shadeslayer_ Riddell did anything come out of that?
[14:41] <shadeslayer_> apachelogger: IIRC you said that updating via installer works
[14:41] <shadeslayer_> so I did not pursue that
[14:42] <apachelogger> mh, k
[14:46] <benvantende> hey kubuntu devs
[14:47] <benvantende> since a few months i get this purple background with video's. a bit randomly. i could not find that as an issue somewhere. does that sound familiar?
[14:48] <soee> graphic card issue benvantende  ?
[14:48] <apachelogger> define purple background please
[14:49] <shadeslayer_> the ubuntu wallpaper xD
[14:49] <benvantende> lol
[14:49] <soee> also what videos ?
[14:49] <apachelogger> shadeslayer_: prepping a mail to -devel and -users on UEFI
[14:49] <apachelogger> "Create a comprehensive guide on how to install despite broken UEFI"
[14:49] <soee> maybe they are just encoded wrong
[14:49] <shadeslayer_> apachelogger: ack
[14:49] <apachelogger> shadeslayer_: I wonder where to put such a guide
[14:49] <apachelogger> or whether it would suffice to detail that in the mail
[14:49] <shadeslayer_> apachelogger: maybe a announcement on kubuntu.org as well
[14:49] <shadeslayer_> apachelogger: wiki?
[14:49] <apachelogger> wiki aint for users :P
[14:49] <apachelogger> question is
[14:50]  * shadeslayer_ is feeling poorly today, not going to be online for long
[14:50] <apachelogger> how detailed should we go there anyway
[14:50] <Mamarok> claydoh: sent a mail, you should see it in -owner
[14:50] <benvantende> no, it comes as a layer behind the video and also disappears again. in full screen i can see the video darkens. so with all youtube (html 5) and vimeo
[14:50] <apachelogger> shadeslayer_: because if we assume: must install with updates or you are screwed, then that can just be outlined in the mail really
[14:50] <apachelogger> manual repair is somewhat tricky anyway
[14:50] <shadeslayer_> "No one tested stuff on EFI, some details about post install issue, fix pushed, two ways to fix, document both fixes"
[14:51] <shadeslayer_> fine, the less technical people will just reinstall, the more technically able people with try recovery
[14:51] <apachelogger> *shrug*
[14:51] <apachelogger> we could also write a scripty to attempt fixing that
[14:52] <apachelogger> but chances are that goes wrong and then it's even more screwed :P
[14:52] <shadeslayer_> ^^
[14:52] <apachelogger> benvantende: how do you see it if it is behind the video?
[14:54] <benvantende> apachelogger: ahaaa well it extends a little bit beyond the border of the video. taking a screenshot does not work, because that seems to redraw the screen
[14:56] <benvantende> apachelogger: so ok. it is hard to say if it as a layer behind. could be on top too.
[14:57] <apachelogger> sounds like a driver bug if a screen redraw fixes it
[14:58] <apachelogger> `ubuntu-bug video` should bring up an appropriate bug report screen
[14:58] <benvantende> ok
[14:58] <benvantende> but does not sound familiar?
[15:00] <benvantende> Package video does not exist.
[15:00] <apachelogger> shadeslayer: http://paste.ubuntu.com/6370898/
[15:00] <apachelogger> benvantende: nope
[15:03] <apachelogger> benvantende: maybe it was ubuntu-bug display
[15:03] <apachelogger> well, if all else fails, try to find out what graphics driver you have and report a bug against that ;)
[15:03] <apachelogger> -> afk
[15:03] <benvantende> ok tHNx
[15:24] <apachelogger> ScottK, shadeslayer, Riddell: http://paste.ubuntu.com/6371017/ announcement mail
[16:26] <Riddell> apachelogger: I'd get rid of "the final version of" as that sounds like there might be other versions
[16:27] <Riddell> apachelogger: where do you expect to put that?
[16:28] <apachelogger> Riddell: -devel -users
[16:28] <Riddell> apachelogger: and kubuntu.org?
[16:28] <Riddell> maybe update the release page too
[16:29] <apachelogger> did that aready
[16:29] <Riddell> ovidiu-florin: travel funds approved!
[16:34] <ovidiu-florin> Riddell: by Canonical?
[16:34] <Riddell> yep
[16:35] <ovidiu-florin> yeeey
[16:35] <ovidiu-florin> Riddell: thanks for the news
[16:35] <ovidiu-florin> KDE 4.11.3 was released. Is it available in backports already?
[16:39] <Riddell> I've not looked at it at all, been working on kde frameworks coinstallability
[16:40] <soee> its i ninjas ppa :)
[16:40] <soee> im using it since 2 days on saucy. works perfect
[16:42] <yofel> saucy is done and needs to be copied, raring needs testing, precise needs fixing
[16:57]  * Riddell high fives yofel
[17:00] <genii> Hm. Maybe the #kubuntu !contribute factoid needs updating. It's pretty Ubuntu-centric.
[17:22] <Riddell> hi bukai :)
[17:23] <bukai> Riddell:  hi
[17:24] <Riddell> bukai: are you going to become an elite kubuntu contributor?
[17:25] <bukai> Riddell: yes , but i need some help regarding how to proceed.
[17:27] <bukai> Riddell: i am really eager to contribute and become an elite contributor.
[17:28] <Riddell> sweet
[17:29] <Riddell> I need to run off now but there's others about or I'll be back later this evening
[17:30] <bukai> Riddell: ok :)
[17:32] <debfx> mamarley: sorry, forgot about your upstart script. the problem was that I've tested it with precise. newer upstart version call initgroups() so that should be fine.
[17:32] <debfx> still need to test it though
[18:20] <debfx> ScottK: do you have an unpushed quassel bzr branch or should I just import the latest version?
[19:00] <mamarley> debfx: Using start-stop-daemon doesn't seem to cause any problems, so should I just stick with that?
[20:22] <genii> "Begin 64-Bit Download" at http://www.kubuntu.org/getkubuntu/download#download-block is broken. Url has raring in the path but saucy iso file
[20:23] <eagles0513875> genii: you beat me to it lol
[20:23] <eagles0513875> genii: according to launchpad Riddell seems to be in charge of the site not sure who else has access to it
[20:24] <eagles0513875> genii: bug already reported https://bugs.launchpad.net/kubuntu-website/+bug/1248656
[22:47] <apachelogger> yofel: https://trello.com/c/6YqRWWdd
[22:48] <eagles0513875> apachelogger: are you able to fix something on the kubuntu website?
[22:49] <Riddell> eagles0513875: what's up?
[22:49] <eagles0513875> Riddell: its a rather urgent bug the 64bit iso on the download page the button is pointing to raring with nothign there
[22:49] <eagles0513875> bug 1248656
[22:50] <Riddell> eagles0513875: how's it now?
[22:50] <eagles0513875> thanks :) Riddell its working now
[22:51] <eagles0513875> whats the normal procedure for website bugs? just to file a bug on launchpad?
[22:51] <Riddell> eagles0513875: and ping someone here
[22:52] <Riddell> so you did good :)
[22:52] <eagles0513875> :) I am wondering if that should be added on the website somewhere. especially now that a 3rd party has taken over maintaining kubuntu etc instead of canonical
[22:53] <valorie> I got hit with the muon updating bug -- 5 mins and it's still grayed out and working away with no progress
[22:53] <valorie> also grayed out: the cancel button
[22:56] <Riddell> valorie: fix may well be in 2.1 branch if you want to test a git compile
[22:56] <Riddell> eagles0513875: no third party, kubuntu is still incharge of kubuntu
[22:57] <valorie> hmm, so that means uninstall muon, and then compile muon from git?
[22:57] <Riddell> just compile muon from git and install that over the package
[22:57] <valorie> ah, ok
[22:58] <valorie> I'll check the muon techbase for details
[22:58] <eagles0513875> Riddell: hopefully with ikonia mentoring me ill be able to package stuff for the community :)
[22:58] <Riddell> that would be awesome
[22:58] <Riddell> calligra needs done :)
[22:58] <Riddell> (it's a beast)
[22:59] <eagles0513875> :) also mysql workbench
[22:59] <eagles0513875> we have 5.2.47 latest is 6.0.7
[22:59] <eagles0513875> probably be best to get that pushed upstream?
[23:02] <Riddell> that's up to the server team, I assume they have their reasons
[23:02] <eagles0513875> Riddell: workbench is a GUI front end though not server side
[23:03] <yofel> apachelogger: I know - what should we do about merging? AFAIK nothing got done and I was busy with 4.11.3
[23:14] <apachelogger> yofel: I think the conclusion was to not merge at all
[23:15] <yofel> if we had a conclusion then I missed it - though I guess nobody doing anything would be a conclusion of some sort
[23:16] <valorie> I asked for a conclusion on the list and got no reply
[23:16] <apachelogger> which is the conclusion :P
[23:16] <valorie> and yet the consensus seemed to be 'merge when it seems a good idea'
[23:16] <valorie> which is why I asked
[23:17] <apachelogger> FWIW considering the amount of weird regressions we get out of merging it doesn't seem like the worst of ideas for 14.04
[23:17] <yofel> well, we could still do a comparison with debian later on to cherry pick some fixes
[23:18] <yofel> full merging is generally full of regressions :S
[23:18] <apachelogger> yah
[23:36] <valorie> i'm in the build folder of muon after cloning, but I've forgotten how to change to 2.1 branch
[23:36] <valorie> and then:
[23:36] <valorie> cmake -DCMAKE_BUILD_TYPE=DebugFull ..
[23:36] <valorie> make && sudo make install
[23:36] <valorie> ?
[23:42] <valorie> muon isn't ON techbase, btw
[23:42] <valorie> which is a bit weak


[00:56] <thethomaseffect> OSSbarcamp site has been compromised by the looks of things, just got a ton of nonsense in my RSS reader
[00:57] <czajkowski> domain is gone


[11:58] <pavlushka> Who will review the translations?
[16:43] <askhl> pavlushka: if the language has an active translation team, someone from the team might.  But you should get in contact with them and ask them how you can best contribute
[16:43] <askhl> pavlushka: in the end, the coordinator of your language should know how you can must productively contribute
[16:43] <pavlushka> I kept sending mail to the team admins with no result.
[16:44] <askhl> pavlushka: Maybe the team is inactive.  Which language?
[16:44] <pavlushka> bengali
[16:46] <pavlushka> the teams link is https://launchpad.net/~ubuntu-l10n-bn
[16:47] <askhl> Hmmm.  Maybe you can get in contact on the team mailing list?  But yes, it's a bit strange.
[16:48] <pavlushka> sent that too, to the mailing list.
[16:49] <pavlushka> I can forward you the mails.
[17:07] <askhl> Hmm, are the other translators active?
[17:07] <askhl> Do they produce translations?  Do they have a web page or anything?
[17:08] <askhl> The ubuntu group is a subgroup of the launchpad translation group: https://launchpad.net/~lp-l10n-ben
[17:08] <askhl> That means really lp-l10n-ben are in charge.  Maybe you should try to contact those, if they are different from the other group.
[17:09] <askhl> However it is a bit strange.
[17:12] <pavlushka> askhl: no, they dont have any websites
[17:22] <pavlushka> askhl: ok, I will ask them, thanks for the suggestion and time.


[10:02] <Quantos> This is something that I'd expect from Winblows
[10:02] <Quantos> I just had a popup on my desktop it says 'System program problem detected'
[10:03] <Quantos> And asks if I want to report it
[10:03] <Quantos> But that's all the information it gives me
[10:03] <hateball> There should be an arrow or some such to show additional info
[10:06] <Quantos> Just the arrow on the menu bar and the other one that rolls it up
[10:06] <Quantos> Hi there hateball, thanks again for that help before
[10:07] <Quantos> It just dawned on me I could disrupt the internet and click continue just to see what happens
[10:07] <Quantos> I'd rather find out what it is though
[10:08] <Quantos> Everything in System Manager looks good
[10:08] <Quantos> Doesn't indicate any software that's not working
[10:10] <Quantos> Would a screen shot help?
[10:11] <hateball> not really, no
[10:11] <hateball> usually not something to concerned with
[10:11] <hateball> if it's a system service it tends to restart on crash
[10:12] <hateball> you just get notified it shouldnt be crashing
[10:12] <Quantos> It would be nice if they could possibly identify what it is
[10:13] <Quantos> It's almost windows like
[10:13] <hateball> the crash is dumped somewhere, I cant remember where tho
[10:13] <Quantos> Somehing happened, we don't know what, but it's likely bad for you
[10:14] <Quantos> So a reboot wouldn't be necessary for it then
[10:14] <Quantos> The service will start again when called?
[10:15] <Quantos> Apparently if you click to report the problem it tells you what it is
[10:15] <Quantos> It was VBox
[10:16] <Quantos> Which is odd, it didn't even hickup on me
[12:00] <cosec_> guys
[12:01] <cosec_> i want to install lubuntu
[12:01] <cosec_> along side my existing kubuntu
[12:01] <cosec_> does the installer provide me options to do so ?
[12:02] <damascene> cosec_, do you know how to partition Linux drives correctly?
[12:03] <hateball> cosec_: why do you want to dualboot instead of simply installing lubuntu-desktop and choosing at login?
[12:03] <cosec_> i am not so good at making linux partitions
[12:03] <cosec_> problem is
[12:04] <cosec_> i am using the fglrx drivers
[12:04] <cosec_> its eating my battery
[12:04] <cosec_> and i have to set my lappy on discrete
[12:04] <cosec_> to use my current os
[12:04] <cosec_> :(
[12:05] <cosec_> so i was thinking
[12:05] <cosec_> install lubuntu, set graphics to switchable
[12:05] <cosec_> enjoy happy hours travelling
[12:06] <cosec_> and switch to kubuntu, switch to discrete
[12:06] <cosec_> and enjoy graphics
[12:07] <cosec_> its complicated
[12:07] <cosec_> :(
[12:09] <damascene> I see
[12:10] <cosec_> right now i am on kubuntu
[12:10] <cosec_> i have allotted the entire hdd to kubuntu
[12:10] <cosec_> :/
[12:11] <damascene> what I suggest is to backup all your important data to a backup medium then shrink one of your partition and install lubuntu there.
[12:11] <cosec_> so just, using a lubuntu-desktop doesn;t change anything except the interface
[12:12] <damascene> it's not too hard, you just have to set the the empty partion mount point to /
[12:13] <cosec_>  /dev/sda ?
[12:13] <cosec_> i see
[12:14] <cosec_> i have to go for now
[12:14] <cosec_> i will comeback
[12:14] <cosec_> ty for you help
[12:14] <damascene> not /dev/sda but it should be something with number at the end like /dev/sda10
[12:15] <damascene> if you can login to this channel through the installation we can support you
[12:15] <damascene> hopefully
[12:50] <cosec_> ok ty
[12:50] <cosec_> :)