[19:10] <kwwii> hi hellraiser_rob
[19:19] <hellraiser_rob> kwwii, so are you all done for the release tomorrow now?
[19:28] <kwwii> hellraiser_rob: yepp, looks like it
[19:28] <kwwii> responding to a few community emails atm
[19:28] <kwwii> can't wait to start work on hardy
[19:29] <hellraiser_rob> haha, i can't tell if you are serious or not?
[19:29] <kwwii> well, a nice little vacation somewhere tropical would be pretty nice too :p
[19:29] <kwwii> actually, I was trying to be serious
[19:29] <hellraiser_rob> thats good
[19:29] <kwwii> but maybe my tiredness is showing through
[19:30] <hellraiser_rob> i have been very impressed with gutsy
[19:30] <kwwii> I liked what came out of it too but I think we still have a long way to go
[19:31] <hellraiser_rob> i think after a long project everyone feels that way slightly
[19:31] <hellraiser_rob> and maybe miss just how well it's turned out
[19:32] <kwwii> yeah, it is easy to get really sick of looking at it :-)
[19:32] <hellraiser_rob> everyones done a great job
[19:32] <kwwii> I should count all the releases I have done in my life
[19:33] <kwwii> and probably take a week off of my life for each one
[19:33] <hellraiser_rob> haha
[19:33] <hellraiser_rob> what other distros have you been involved with?
[19:35] <kwwii> I worked for SUSE for 7 years
[19:35] <kwwii> I bet I have done somewhere around 20 linux releases
[19:36] <kwwii> well more around 25+
[19:37] <hellraiser_rob> and you still flood the kitchen :D
[19:38] <kwwii> lol, no doubt
[19:38] <kwwii> that is probably one of the stupidest things I ever did in my life
[19:38] <hellraiser_rob> i did think to myself, who checks their emails for that long!
[19:44] <kwwii> let me tell you...the artist list alone (which I admin) gets like 20-30 spam emails a day
[19:45] <hellraiser_rob> :D
[19:45] <kwwii> I bet that on a good day I receive a few hundred emails
[20:56] <kwwii> lol, we have a "mailing list" section on the GetInvolved page but no specific info on how to join it!
[20:59] <kwwii> hehe, nor does the link to the meetings page work


[13:59] <didrocks> who is participating to the Qt5 session? :)
[14:02] <Mirv> welcome anyone to the hangout :) https://plus.google.com/hangouts/_/7ecpjhcv91f5e2g6cvefjmia44
[14:04] <Mirv> https://plus.google.com/+TimoJyrinki/posts/NeUt19z1V3p
[14:08] <Riddell> hi
[14:08] <tsdgeos> hi
[14:11] <didrocks> hey Riddell
[14:11] <didrocks> Riddell: wants to join the hangout?
[14:14] <lool> didrocks: I think I'll drop to another session about cross-compilation now that I raised the main things I wanted to make sure was taken care of; I trust others know better than me about 5.2 issues/bugs to solve etc.
[14:14] <didrocks> Riddell: nice to see you, welcome! :)
[14:14] <didrocks> lool: agreed
[14:14] <didrocks> lool: see you!
[14:35] <Mirv> thanks everyone, adding some notes still to the pad from discussion
[14:36] <rsalveti> seems we're done already
[14:39] <Mirv> rsalveti: yeah, we finished as no new questions or topics were raised.
[14:39] <Mirv> notes in the pad
[14:48] <rsalveti> Mirv: thanks
[15:01] <didrocks> who is going to lead the mediascanner roadmap?
[15:02] <satoris> didrocks: that would be me.
[15:04] <didrocks> satoris: are you joining?
[15:05] <didrocks> https://plus.google.com/hangouts/_/72cpigmmgnfvmfg8d0qugft72c?authuser=0
[15:05] <satoris> Feel free to join.
[15:09] <jdstrand> mediascanner directly usable by apps is useful for application confinement
[15:09] <jdstrand> since it is out of process, 3rd party music players could just use it
[15:10] <jdstrand> yes, please do not allow direct access to the sql db. that will limit what 3rd party apps in the app store can do (due to application confinement)
[15:10] <jamesh> http://bazaar.launchpad.net/~mediascanner-team/mediascanner/v2/view/head:/src/mediascanner/MediaStore.hh
[15:10] <jdstrand> right now, music-app is unconfined. the apis should support it being confined
[15:13] <ahayzen> vthompson, we'll still have to store playlists in our db? but could we reduce it just to the file/uri and query the mediascanner for the metadata?
[15:14] <mhr3> QUESTION: with the new mediascanner, apps open the db themselves, right? how is that going to play with confined apps?
[15:16] <vthompson> ahayzen,  I believe we'll still need to keep track of playlists. But keeping just the URI might be a way forward. I believe we could do that with grilo as well
[15:16] <jdstrand> mhr3: it won't (see above comments). we should provide an api so confined apps don't have to do that
[15:17] <jdstrand> we special cased music-app for 13.10, but it should be confined like everything else
[15:17] <jdstrand> (unfortunately, I got called to another session)
[15:17] <ahayzen> vthompson, I would be happy working on reworking our side of things to do tht
[15:18] <bfiller> QUESTION: is their a library available to do thumbnail generation? we want the mediaplayer-app and gallery-app to use this if so
[15:20]  * jdstrand is still here if you need me
[15:21] <bfiller> cool!
[15:21] <mhr3> bfiller, i think part of it is already in the SDK
[15:22] <bfiller> does it require any special codeces?
[15:22] <bfiller> codecs
[15:22] <bfiller> i.e. ffmpeg or any -ugly stuff?
[15:22] <jdstrand> jamesh: I'm back a few minutes in the feed (cause I got pulled out). we *could* allow readonly access to the db in apparmor policy. the sqlite db has to be opened in a very specific way to do that. I kind of hoped the mediascanner library would call out to the mediascanner process and the mediascanner process could give the info rather than direct access to the db
[15:23] <jdstrand> jamesh: that could be over dbus
[15:24] <mhr3> bfiller, depends on what you want to thumbnail :)
[15:24] <mhr3> bfiller, ultimately it just pokes gstreamer
[15:24] <jamesh> jdstrand: the client library lets you open the database in SQLITE_OPEN_READONLY mode, which should be fine with read only confinement right?
[15:24] <bfiller> mhr3: thanks makes sense
[15:25] <jdstrand> jamesh: the confinement could be made to allow that. right now we don't have policy groups for that, but it could be added
[15:26] <mhr3> jhodapp, shouldn't such test be somewhere in the media stack? thumbnailer just uses gstreamer to get it
[15:26] <jdstrand> jamesh: we have a similar issues with thumbnails btw
[15:26] <jhodapp> mhr3, yes, but I'd also like to test it at this level...i think the more tests in different use-cases the better
[15:27] <mhr3> jhodapp, well it means that thumbnailer will fail only because the media stack will go through a transition
[15:28] <jdstrand> jamesh, satoris: sorry if I missed this-- will the mediascanner do the thumbnailing and then apps use these thumbnails?
[15:28] <jhodapp> mhr3, not sure I'm following
[15:28] <mhr3> jhodapp, if something breaks in media stack, it automatically breaks thumbnailer
[15:28] <jhodapp> mhr3, yes, that's what I want to catch
[15:28] <ahayzen> vthompson, is there any other info we need from the mediascanner?
[15:28] <mhr3> jhodapp, yet thumbnailer is not able to do anything about it
[15:29] <jhodapp> mhr3, right
[15:29] <mhr3> jhodapp, that's why i think the test shouldn't be there
[15:29] <jhodapp> mhr3, I guess that's up to the media scanner team then as I still think it's useful
[15:30] <jdstrand> QUESTION: what is the hangout url?
[15:30] <vthompson> ahayzen, so I think we'll need to maintain a 14.04 specific branch for this capability and possible U1 streaming if we tackle that
[15:30] <jhodapp> https://plus.google.com/hangouts/_/72cpigmmgnfvmfg8d0qugft72c?authuser=0
[15:31] <ahayzen> vthompson, ok, when is the new mediascanner expected to land?
[15:32] <vthompson> ahayzen, sounds like we'll have a PPA to access in some soon-ish timeframe
[15:32] <pstolowski_> QUESTION: is QML bindings something you would consider community could help with, or even drive?
[15:32] <ahayzen> vthompson, cool, guess we can start doing some things and still use Grilo for the moment?
[15:33] <vthompson> ahayzen, I believe we'll have to maintain grilo in Saucy.
[15:40] <jdstrand> jhodapp: thanks for the link btw :)
[15:40] <pstolowski_> QUESTION ^^ :)
[15:40] <jhodapp> jdstrand, np
[15:45] <jdstrand> vthompson: as an aside-- thanks for all the bug fixes for music-app of late :)
[15:45] <jdstrand> I can't wait to get the new player :)
[15:45] <vthompson> jdstrand, :) my pleasure
[15:46] <ahayzen> vthompson, i'm gonna go back home anything u need from me?
[15:50] <vthompson> ahayzen, nope! Safe travels!
[15:50] <ahayzen> vthompson, probably speak in ~1hr :)
[16:01] <dbarth> hiya
[16:02] <didrocks> hey dbarth!
[16:03] <alex-abreu> oa it is then
[16:05] <dbarth> who wants to hop on the hangout?
[16:05] <didrocks> kenvandine: interested?
[16:05] <dbarth> jdstrand: ?
[16:05] <dbarth> kenvandine: ?
[16:05] <kenvandine> yes
[16:06] <jdstrand> dbarth: I will be in irc. mdeslaur could join the hang out since he is leading this discussion on my team
[16:07] <dbarth> ah cool
[16:09] <mmcc> Hi folks :)
[16:09] <jdstrand> dbarth: if you need me to join, I'm here
[16:12] <dbarth> ok
[16:15] <robruds> mardy: friends uses flickr
[16:16] <ssweeny-uds> is the friends flickr plugin installed on the phone?
[16:16] <robruds> ssweeny-uds: nope ;-)
[16:17] <robruds> ssweeny-uds: only twitter and facebook by default.
[16:17] <ssweeny-uds> robruds: that's what i thought
[16:18] <robruds> ssweeny-uds: so I'm just realizing right now for the first time that friends-{flickr,instagram,linkedin} are broken on the phone because they're not installable on a readonly image.
[16:18] <ssweeny-uds> robruds: as a user of third-tier open social networks I've felt pretty marginalized on the phone with no easy way to write friends plugins :)
[16:18] <ssweeny-uds> robruds: yeah that might be a problem...
[16:19] <dbarth> ssweeny-uds: that's why we need click hooks
[16:19] <dbarth> for OA plugins / auth. providers
[16:19] <ssweeny-uds> dbarth: yeah, OA and friends both need them
[16:19] <robruds> ssweeny-uds: yeah, there was a session yesterday about the idea of installing plugins with click, so friends will have to be part of that.
[16:19] <dbarth> ssweeny-uds: but which is currently planned to be a manual process, for partners we can have an audit or agreement with
[16:20] <ssweeny-uds> robruds: we talked about this a few months ago. you said i think that friends plugins would need to be split up into their own processes to allow confinement
[16:20] <robruds> ssweeny-uds: well that was based on my understanding of confinement, more than my understanding of friends plugins.
[16:20] <ssweeny-uds> ah
[16:20] <robruds> ssweeny-uds: so i could be wrong
[16:21] <ssweeny-uds> my thinking is if a friends plugin can only access data associated with the account it's "called" with then the security issues aren't so bad
[16:21] <robruds> ssweeny-uds: the friends plugins are so simple, don't take up any space. i'd like to just have them all installed by default (I was opposed to the original work of splitting them all up into different packages)
[16:21] <ssweeny-uds> like, as long as the twitter plugin can't access your facebook profile the risk is low
[16:21] <ssweeny-uds> robruds: that makes sense
[16:22] <ssweeny-uds> robruds: i'm mostly worried about pushback against click plugins for friends
[16:22] <robruds> ssweeny-uds: haha, no. the friends plugins are python modules, they have total access to the entire friends infrastructure, they can do anything.
[16:22] <ssweeny-uds> yeah, that's what i was afraid of
[16:23] <ssweeny-uds> so there will be security concerns with third-party friends plugins
[16:24] <robruds> ssweeny-uds: hmmm, yeah, this is a tricky issue i hadn't previously considered.
[16:24] <ssweeny-uds> there was talk yesterday of manual review for certain types of packages
[16:24] <ssweeny-uds> this might have to fall under that
[16:25]  * cwayne and ssweeny-uds started work on a click-hooks for o-a
[16:25] <cwayne> ~/.local/share
[16:25] <cwayne> u-s-s-o-a needs to be modified to look for qml-plugins in ~
[16:27] <didrocks> cwayne: ssweeny-uds: robruds: one of you wanting to join the hangout?
[16:28] <dbarth> cwayne, ssweeny-uds: do you want to continue the work on that?
[16:28] <dbarth> the click hook
[16:28] <robruds> dbarth: mardy: sorry I think ssweeny-uds and i are bit offtopic here
[16:28] <dbarth> ie, to get that task done in the plan
[16:28] <ssweeny-uds> dbarth: yes please
[16:28] <cwayne> dbarth, the click hooks should probably be part of the online-accounts system settings package
[16:28] <kenvandine> cwayne has been looking at click packages for account plugins
[16:28] <dbarth> right
[16:29] <ssweeny-uds> dbarth: i'm about 70% done with the patch to the system-settings part
[16:29] <dbarth> but mardy welcomes patches, you see ;)
[16:29] <dbarth> ssweeny-uds: cool!
[16:29] <dbarth> ssweeny-uds: did that get a cjwatson review yet?
[16:29]  * cwayne also volunteers to make an sdk template for new online-accounts once we have them as clicks
[16:29] <dbarth> awesome!
[16:30] <mardy> http://developer.ubuntu.com/api/qml/sdk-1.0/
[16:30] <cwayne> i think all we're waiting on re: click hooks is getting this fixed: https://bugs.launchpad.net/ubuntu/+source/click/+bug/1245826
[16:30] <udsbotu> Launchpad bug 1245826 in click (Ubuntu) "Allow applying a hook to multiple files" [Wishlist,Triaged]
[16:30] <mmcc> QUESTION: Is there anything currently using signon-ui on ubuntu touch? Our UbuntuOne provider plugin has custom QML UI for login, and needs signon-ui to support QML so we can handle requesting re-authentication for invalidated tokens.
[16:30] <mardy> http://developer.ubuntu.com/api/qml/sdk-1.0/Ubuntu.OnlineAccounts/
[16:31] <ssweeny-uds> dbarth: the patch i'm working on now is just to get the settings UI to load stuff from ~/.local/share/
[16:33] <mmcc> mardy: this is re your comment on bug 1248326
[16:33] <udsbotu> Ubuntu bug 1248326 in Unity Click Scope "Handle invalidated token in a more user-friendly way" [Undecided,New] https://launchpad.net/bugs/1248326
[16:38] <ssweeny-uds> this (multiple possible domains) discussion is also useful for things like owncloud or statusnet which don't have a central server
[16:38] <dbarth> ssweeny-uds: do you have a working model for that?
[16:38] <dbarth> are you constraining urlpatterns?
[16:39] <ssweeny-uds> dbarth: i don't know if you can do that. the domain could be anything
[16:39] <dbarth> ssweeny-uds: oh, meaning, any server where you would host the service?
[16:39] <ssweeny-uds> yeah
[16:40] <dbarth> i see
[16:40] <dbarth> but are you using a webapp container for this one?
[16:40] <dbarth> or would like to do so
[16:40] <ssweeny-uds> dbarth: for instance i have statusnet and owncloud services running on my own domain
[16:40] <dbarth> want to hop on the hangout?
[16:40] <ssweeny-uds> dbarth: i'm not actually looking to use webapps. i'm talking more generally that i'd like OA to be able to handle decentralized services
[17:00] <dbarth> thanks everyone for your feedback on the topic
[17:01] <dbarth> and for the upcoming contributions more importantly!
[17:01] <dbarth> really appreciated
[17:59] <olli> who is running this track?
[18:00] <olli> got a link to the URL
[18:00] <olli> lol
[18:00] <olli> link to the HO
[18:03] <tvoss_> didrocks, r u running the hangout?
[18:03] <didrocks> tvoss_: yeah, want to come?
[18:03] <didrocks> thostr: is going to lead it
[18:04] <doko> what's the hangout URL?
[18:05] <didrocks> doko: it's about unity8 scopes
[18:05] <didrocks> doko: are you sure you are in the right room?
[18:05] <tvoss_> didrocks, listening in :)
[18:19] <Saviq> QUESTION: is JavaScript considered less resource hungry than Python/
[18:19] <Saviq> ?
[18:20] <olli> QUESTION: what's the situation re security & JS?
[18:20] <satoris> The basic memory footprint of Python interpreter is 5MB or so.
[18:21] <mhr3> didrocks, can you mute yourself?
[18:21] <didrocks> mhr3: sorry, done
[18:21] <mhr3> thx
[18:21] <davidcalle> Also, for the record, the memory footprint of a basic running scope is around 9MB.
[18:21] <davidcalle> Python ^
[18:22] <facundobatista> davidcalle, that have imported all the gio crazyness, right?
[18:22] <davidcalle> facundobatista, right
[18:23] <facundobatista> davidcalle, that's not fair ;)
[18:23] <jdstrand> fyi, https://wiki.ubuntu.com/SecurityTeam/Specifications/ScopesConfinement
[18:25] <jdstrand> (I also added ^ to the pad)
[18:27] <jdstrand> QUESTION: can you comment (for the wider community) on how you've addressed privacy wrt to scopes? (ie, briefly detail the work you've done on disabling internet scopes globally and on a per scope basis, etc)
[18:27] <jdstrand> (of course the security design feeds in to that too)
[18:28] <jdstrand> (but you already mentioned that :)
[18:29] <jdstrand> I know the answer-- but thought others might be interested in it :)
[18:33] <alecu> regarding the online switch for scopes: the click scope listens to that setting too, and disables getting "suggested apps" from the click webservice when online searches are off. It
[18:33] <alecu> it still does the search of locally installed apps
[18:42] <pedronis2> we are also proxying images, so those don't get to the original server either
[18:52] <fugue88> What's the name of that "global search" ?
[18:52] <fugue88> David mentioned it.
[18:52] <Saviq> davidcalle, ↑
[18:52] <davidcalle> fugue88, Blippex
[18:52] <fugue88> Thanks!
[18:53] <davidcalle> fugue88, np. Here is a few screenshots : https://plus.google.com/+davidcalle/posts/7E1SDPZie9p
[18:53] <pedronis2> thanks
[18:54] <fugue88> davidcalle: Cool.  Interesting that they allow you to set "dwell time" and other things.
[18:54] <davidcalle> fugue88, yes, this is a very interesting search engine.
[19:01] <tvoss_> didrocks, ping
[19:01] <tvoss_> niemeyer, hey there :) wanna join us on the hangout?
[19:01] <didrocks> tvoss_: pong
[19:01] <niemeyer> tvoss_: Sure, link?
[19:01] <tvoss_> didrocks, got the ho link for me?
[19:01] <didrocks> tvoss_: I sent you the links 5 minutes ago :p
[19:01]  * didrocks does again
[19:01] <tvoss_> didrocks, don't have it :/
[19:02] <tvoss_> didrocks, this time it worked
[19:02] <tvoss_> niemeyer, https://plus.google.com/hangouts/_/72cpi68tob23aag0bfji9amh30?authuser=0
[19:02] <didrocks> tvoss_: I sent it to him already FYI ;)
[19:02] <tvoss_> jdstrand, wanna join the hangout, too?
[19:03] <tvoss_> jdstrand, https://plus.google.com/hangouts/_/72cpi68tob23aag0bfji9amh30?authuser=0
[19:03] <jdstrand> tvoss_: actually, I was going to attend a different session and have two people here if you need comments from the security team
[19:03] <tvoss_> jdstrand, would like to have someone on the hangout, yes
[19:03] <jdstrand> tvoss_: if you feel my input is required, I'll attend
[19:03] <tvoss_> jdstrand, not necessary, as long as someone from security is here
[19:08] <zyga> hi
[19:09] <lool> tvoss_: do we have someone representing SDK team?
[19:09] <tvoss_> lool, nope, can you pull zoltan over?
[19:10] <lool> tvoss_: poked him
[19:10] <pmcgowan> lool, I will join for now
[19:10] <fugue88> QUESTION: By client side, do you mean GUI, or more generic than just GUI?
[19:11] <tvoss_> fugue88, more generic than just UI
[19:15] <fugue88> On the other hand, with gcc *maybe* making gccgo a default, it might get some more popularity.
[19:16] <fugue88> Of course, we don't have a crystal ball.
[19:16] <cjwatson> can I have the hangout url?
[19:16] <tvoss_> fugue88, look at https://launchpad.net/usensord for example
[19:16] <tvoss_> cjwatson, https://plus.google.com/hangouts/_/72cpi68tob23aag0bfji9amh30?authuser=0
[19:16] <Saviq> cjwatson, https://plus.google.com/hangouts/_/72cpi68tob23aag0bfji9amh30?authuser=0
[19:16] <cjwatson> ta
[19:16] <zyga> IIRC linaro was doing some work on porting go to aarch64
[19:16] <zyga> https://groups.google.com/forum/#!topic/golang-dev/MLaz62sHUc0
[19:17] <zyga> one of the people there is actually working for canonical
[19:19] <tedg> jdstrand, Why is compiling every application an issue?  Tooling?
[19:19] <zyga> tedg: upgrades probably
[19:19] <Saviq> tedg, no, we don't have the sources
[19:19] <zyga> tedg: imagine if everything is in go :-(
[19:20] <Saviq> tedg, think of all the apps in the store - all would need to be recompiled
[19:20] <zyga> tedg: 10GB upgrade for each security issue?
[19:20] <zyga> ah, store argument is important too
[19:20] <tedg> Well, the store is different.
[19:20] <zyga> I don't think go is designed to work well there
[19:20] <tedg> We can't apply security updates to store things mostly.
[19:20] <tedg> It's all BYOD (Bring your own deps)
[19:20] <Saviq> tedg, that's why we're talking about "go's stdlib"
[19:21] <Saviq> tedg, which would be provided by us
[19:21] <zyga> tedg: but we can ship fixed libraries (ssl, etc)
[19:21] <tedg> Plus things in click packages are confined.  We don't care about security anymore ;-)
[19:21] <fugue88> If an app dev has bundled their own crypto library in the click-package, the distro couldn't handle that anyway, right?
[19:21] <zyga> tedg: mmaaybe
[19:21] <Saviq> tedg, see, Jamie is responding right now ;0
[19:21] <Saviq> damn shift...
[19:22] <cjwatson> fugue88: their own, sure, but they should be able to use the crypto library in the stdlib without having to update their app every time there's a security vulnerability found in it
[19:22] <fugue88> cjwatson: Well, I certainly agree about that, but some things will be bundled and have security concerns nonetheless.
[19:23] <fugue88> But the burden on app devs to recompile every time the platform shifts is a big one.
[19:23] <cjwatson> the perfect must not be the enemy of the good
[19:23] <cjwatson> just because some things will end up being bundled doesn't mean we shouldn't make efforts to avoid bundling the stdlib with everything
[19:24] <fugue88> No no, I agree.
[19:24] <cjwatson> tedg: that only means the application can't compromise the rest of the system, not that it cannot be compromised itself
[19:25] <tedg> cjwatson, Sure, but that means that the attack surface is much smaller.
[19:25] <tedg> cjwatson, And the consequences of the attack.
[19:25] <cjwatson> yes, but not that it should be ignored
[19:25] <cjwatson> I don't think it would be responsible for us to ignore it
[19:25] <tedg> I'm not saying it should be ignored, but I am saying that it may not be a blocker considering its size.
[19:26] <Saviq> QUESTION: when talking Go/QML, QML in itself is very modular, allows for easy reusability between projects, would a Go QML extension/module be usable outside of a Go application?
[19:30] <kardianos> Go support hard float
[19:30] <kardianos> (It works on rpi)
[19:30] <lool> thanks for the confirmation
[19:30] <tvoss_> thx
[19:32] <jdstrand> weird, I dropped out (connection was lost)
[19:32] <lool> that's why you looked so static
[19:33] <Saviq> niemeyer, thanks, I'm game :)
[19:33] <kardianos> Go gc I'm fairly sure now generates PIC as a precursor for generating so objects. They are still attempting to fill the whole shared object story, no timeline yet, but the story is being developed.
[19:33] <cjwatson> Would this be easier if using gccgo?
[19:33] <niemeyer> kardianos: Right, and that's not even about Go 1.2..
[19:33] <kardianos> Correct
[19:34] <kardianos> I don't think it will be easier then gccgo, but I could be mistaken. Just the runtime story just haven't  been finished.
[19:35] <cjwatson> Well, I ask because I understand (at second hand) that one can already build Go shared objects with gccgo
[19:35] <Saviq> lool, no, reusable - and yes - IIUC niemeyer said it's possible - not yet, though
[19:35] <kardianos> You could be correct there.
[19:38] <kardianos> Not anymore
[19:38] <kardianos> There is no longer any runtime code generation.
[19:42] <Saviq> tvoss_, also, the main() for QML apps is usually minimal (if any), and porting that to Go wouldn't be a substantial task, if needed
[19:42] <tvoss_> Saviq, yup, +1
[19:42] <Saviq> so, yeah, goqmlscene would be enough in most cases
[19:42] <Saviq> as qmlscene is enough in most cases now
[19:43] <Saviq> QUESTION: any estimate on what could the overhead of a .so with the Go runtime be when used from a C++ application? I assume there would have to be a runtime-per-extension?
[19:44]  * Saviq poking holes, sorry
[19:44] <niemeyer> Saviq: A bit early to tell
[19:44] <Saviq> niemeyer, right, thanks
[19:58] <sergiusens> lool, Mike is using https://code.launchpad.net/~jamesh/go-dbus/trunk
[19:59] <lool> thanks
[19:59] <lool> it's listed in the bp already
[19:59] <lool> actually the topic I wanted to open were which go library bindings we missed
[19:59] <lool> but it seems dbus is not a problem anymore
[19:59] <sergiusens> lool, I'm also trying to get these into debian (as well as niemeyer's gocheck)
[20:00] <sergiusens> lool, I jsut noticed I'm not 'live' :-/
[20:00] <sergiusens> sorry :-)
[20:00] <lool> np
[20:00] <Saviq> session has ended → tvoss_ beer
[20:00] <tvoss_> Saviq, yup :)
[20:01] <didrocks> yeah, but jdstrand had a disruptive not intending to be disruptive but which can be seen as disruptive question :p
[20:01] <pmcgowan> out of battery
[20:02] <didrocks> oh, the excuse from Pat to drink beers :)
[20:03] <lool> well it's Pat's battery
[20:03] <lool> it needs beer to recharge
[20:03] <didrocks> heh
[20:04] <lool> he didn't say his *laptop* ran out  ;-)
[20:04] <ogra_> thats was a fast beer
[20:04] <lool> :-)
[20:04] <Azendale> I'm interested in learning about any bindings from Qt to Go. (Last time I looked, it didn't seem like there really was anything). Can anyone point me in a direction?
[20:04] <ogra_> beer injection :)
[20:06] <Saviq> Azendale, here's what niemeyer is working on https://github.com/niemeyer/qml
[20:07] <Azendale> Saviq: Thanks!
[20:07] <Saviq> o/


[03:21]  * bitmonk wonders if anyone can point at RPMs for bzr that work on RHEL4
[03:22] <bitmonk> the fc7/8/9 stuff all wants python 2.5 and glibc 2.4 or newer
[11:17] <minghua> Hi, is it normal that I can't branch a bzr-svn repo (rich-root format) to a branch in a shared repo with pack-0.92 format?
[11:18] <dato> minghua: yes
[11:18] <luks> yes
[11:18] <luks> use --rich-root-pack
[11:18] <minghua> luks: Not --rich-root?
[11:18] <luks> depends if you want to use packs or not
[11:19] <luks> but you said pack-0.92, so the equivalent is rich-root-pack
[11:19] <minghua> Or you mean "bzr branch --rich-root-pack ..."?  Let me read the man page...
[11:19] <luks> no, the repository must be in the rich-root-pack format
[11:19] <luks> you can upgrade it
[11:19] <luks> but it will break backward compatiblity with <1.0 clients
[11:20] <minghua> Oh, I see.  So a repository initiated with --rich-root will also work?
[11:20] <luks> yes
[11:20] <minghua> I don't mind re-creating the repository.
[11:23] <minghua> luks: Thanks a lot for the help.
[11:23] <tumbleweed> can anyone help me with some config-manager difficulty? I'd like to cherry-pick dirs from CVS repos, but cm doesn't seem to be able to do that: https://bugs.edge.launchpad.net/bugs/178073
[11:24] <ubotu> Launchpad bug 178073 in config-manager "Support cherry-picking subtrees from a CVS repo" [Undecided,New]
[13:27] <dennda> http://pastebin.ca/828424 <--- what went wrong?
[13:29] <luks> missing ssl certificates probably, I think it's fixed in newer versions
[13:29] <luks> you can try urllib+https://... to workaround it
[13:29] <luks> actually, https+urllib://...
[13:30] <dennda> oops, link was wrong
[13:30] <dennda> stupid me
[13:38] <Stavros> what's the fastest way to push a new repo to a remote server?
[13:38] <Stavros> actually, the way that uses the least bandwidth
[13:49] <Stavros> anyone?
[13:49] <mwhudson> make a tarball, scp it?
[13:50] <mwhudson> well, .tar.bz2
[13:52] <Stavros> hmm
[13:53] <Stavros> isn't bzr+ssh faster?
[14:00] <aadis> Stavros: i can't see how it can be faster than bzr+ssh for a new repo
[14:06] <Stavros> aadis: i don't really know what bzr+ssh does, i assume it sends the (compressed) changesets?
[14:06] <aadis> for a new repo, i don't see how that's going to be more efficient than just bzipping the repo
[14:07] <aadis> makes sense for an ongoing transfer. prolly tar+bz2 can extract better compression even
[14:07] <LarstiQ> the main thing there is roundtrips, really
[14:08] <AfC> scp'ing a tar.bz2 is pretty much the definition of "wire speed" used around here. Robert usually compares against it.
[14:09] <luks> .tar would be "wire speed"
[14:09] <AfC> Stavros: I have used rsync very successfully in the past for this sort of thing, but now I just rely on bzr to do the right thing.
[14:09] <AfC> I said "around here"
[14:09] <luks> bzr repository has a lot of compressible data that are not compressed
[14:09] <luks> so bzip2 -9 could help a bit
[14:10] <AfC> luks: that's not correct. Bazaar employs compression quite heavily.
[14:10] <AfC> (at least, Robert's new code does)
[14:11] <luks> AfC: indexes are not compressed
[14:11] <AfC> Oh, sure
[14:11] <AfC> But one doesn't ship indexes when shipping revisions, does one?
[14:11] <AfC> My understanding was that they were a branch-by-branch artifact
[14:12] <AfC> (Huh. But, of course, if you rsync / scp a branch across raw, then you will drag all that crap with you)
[14:13] <AfC> (So you could just send the revisions directory... but then, well, you're more or less using packs :))
[14:13]  * AfC looks at the time and realizes he should be asleep
[14:14] <luks> AfC: one does
[14:14] <luks> knits nor packs are not standalone
[14:18] <tumbleweed> can someone help me lay out a repo? I'm trying to use a centralised bzr repo for managing and updating drupal sites
[14:18] <tumbleweed> but each site will have a different collection of modules
[14:18] <Stavros> does anyone remember how i can copy all *.py files recursively from a directory to another?
[14:19] <tumbleweed> if drupal was available by svn, I'd check it out with svn and use svn:externals, but that's obviously not an option
[14:19] <aadis> Stavros: same dir structure? or in the same dir?
[14:19] <Stavros> aadis: i'm copying my working copy files to the directory with the bzr repo, so exact same structure
[14:19] <Stavros> i.e. copy workingcopy/*.py workingcopy_bzr/
[14:19] <aadis> Stavros: no clean way comes to find, except perhaps using tar!
[14:20] <Stavros> hmm, interesting
[14:20] <tumbleweed> Stavros: hang on, I'm sure I can think of something
[14:20] <aadis> tar can do anything!
[14:20] <Stavros> tar should work
[14:20] <tumbleweed> Stavros: you could use rsync
[14:20] <Stavros> aha, yes
[14:20] <Stavros> even better
[14:21] <tumbleweed> rsync -av source/ dest/ --include '*.py' --exclude '*.pyc'
[14:22] <tumbleweed> or cp -a source/ dest; find -type f -a ! -name '*.py' -exec rm {} \;
[14:22] <tumbleweed> ^ lazy method
[14:22] <Stavros> aw man
[14:22] <Stavros> that rsync line copied everything :/
[14:22]  * tumbleweed was excluiding pyc
[14:22] <tumbleweed> you'd have to exclude every extension you don't want, individually
[14:23] <Stavros> oh
[14:23] <Stavros> hmm
[14:23] <tumbleweed> which sucks, but rsync doesn't have an option to include directories
[14:23] <Stavros> i'd think "include py" would exclude everything else
[14:23] <Stavros> it's ok, i'll just have bzr clean it up
[14:23] <tumbleweed> no, it doesn't
[14:23] <Stavros> thanks a lot!
[14:23] <tumbleweed> Stavros: use find to clean it up
[14:24] <tumbleweed> anyway, I was asking about lay outs, would this make sense?:
[14:24] <tumbleweed> repo/drupal (drupal tree)
[14:24] <tumbleweed> repo/modules/foo (each module)
[14:25] <Stavros> any idea how to delete all .svn folders under my tree? :/
[14:26] <tumbleweed> Stavros: find . -name '*.svn' -print0 | xargs -0 rm -rf
[14:26] <Stavros> thanks
[14:26] <tumbleweed> Stavros: find . -name '.svn' -print0 | xargs -0 rm -rf
[14:26] <tumbleweed> whoops
[14:26] <tumbleweed> not *.svn
[14:26] <Stavros> indeed, thanks
[14:28]  * tumbleweed can't think straight in this heat
[14:31] <tumbleweed> Stavros: re your copying problem
[14:31] <tumbleweed> you could do rsync -av source/ dest/ --include '*.py' --exclude '*.*'
[14:31] <tumbleweed> assuming all files have extensions
[14:34] <bob2> not --exclude '*'?
[14:38] <Stavros> tumbleweed: ah, that worked, thanks
[14:48] <tumbleweed> bob2: exclude * would exclude everything
[14:48] <tumbleweed> bob2: including directories that form part of the parent tree to your .py files
[14:48] <tumbleweed> it's a yucky solution, but it works
[14:51] <tumbleweed> now that my head is working on this, here is a good, and correct solution: find . -name '*.py' -exec cp --parents {} ../destination/ \;
[15:00] <Stavros> ah, thanks
[15:00] <Stavros> trying to migrate to bzr :/
[15:01] <LarstiQ> Stavros: how big is your repo that you don't want to just `bzr push` all your branches?
[15:03] <bob2> tumbleweed: afaict include is applied after exclude, so it does work
[15:03] <Stavros> LarstiQ: it's not large, but the production server has a few lines different from dev
[15:04] <Stavros> and i'm trying to reconcile things
[15:04] <Stavros> so i have to get that working copy, diff it, etc etc
[15:04] <tumbleweed> bob2: includes and excludes are applied in the order specified
[15:05] <tumbleweed> bob2: but rsync won't copy a file unless it copies it's parent directories, too (not necessarily contents of them, though)
[15:05] <LarstiQ> Stavros: aah
[15:06] <Stavros> LarstiQ: yes, it's proving rather hard :/
[15:06] <Stavros> oh wait
[15:06] <Stavros> i'm just stupid
[15:06] <Stavros> gah, i should just delete the .bzr dir and copy everything else
[15:13] <Stavros> anyone know how to cause an external HDD to spin down in linux, like windows' unmount does?
[15:13] <Stavros> (i'm way off topic now)
[15:14] <tumbleweed> hdparm -y /dev/foo
[15:15] <Stavros> ah, thanks
[15:15] <Stavros> y or Y?
[15:15] <tumbleweed> I think Y is a deeper sleep than y
[15:15] <tumbleweed> but why do you want to do this?
[15:16] <tumbleweed> oh, external
[15:16] <Stavros> yes, i'm not sure if it parks the head otherwise
[15:16] <tumbleweed> I'd assume it does, but don't know
[15:16] <tumbleweed> I think drives park their heads as the power is lost
[15:17] <Stavros> that sounds reasonable... i wouldn't want to risk it, though
[15:31] <Stavros> i have two working copies that diverged from the same revision, how can i merge them?
[15:32] <Stavros> i committed one and am trying to merge the other, but merge says there's nothing to do
[15:33] <fullermd> Stavros: You generally merge branches, not working copies.  Merge only works on commits, unless you use --uncommitted to try and bring over working copy changes.
[15:33] <fullermd> But you probably want to commit, then merge.
[15:34] <Stavros> hmm, it's a bit messed up now, because i'm trying to migrate, so they're both in the same directory
[15:34] <Stavros> i.e. i took the original revision, made some changes, committed
[15:34] <Stavros> then i took the other working copy and i want to merge the changes i had done
[15:35] <Stavros> i don't know if i'm making sense
[15:35] <Stavros> if i commit now, i'll revert all the changes i last committed
[15:35] <Stavros> i want to merge the last commit with the working copy (it has a bug fix)
[15:36] <fullermd> Oh, yeah, that doesn't make sense.
[15:36] <Stavros> hmm
[15:36] <fullermd> What you want to do is branch the rev before that, that both were based on, commit in that's tree, then merge them.
[15:36] <Stavros> aha
[15:36] <Stavros> that makes sense then, yes
[15:36] <Stavros> thanks
[15:38] <Stavros> how do i push some changes to another local branch without changing the working copy?
[15:43] <fullermd> Mmm.  Not sure that makes much sense either.
[15:43] <fullermd> I guess you could act remote (use sftp:// localhost or something) and update the branch without touching the tree.
[15:43] <Stavros> ah, never mind, it doesn't do it if they've diverged
[15:43] <Stavros> if they haven't, one could just revert to the committed revision
[15:44] <fullermd> Yeah, that'd stop it there.
[15:44] <fullermd> A branch can only have one head rev, so you'd have to merge them to get them together again.
[15:50] <Leonidas> hi
[15:51] <Leonidas> is there some equivalent of mercurials mq or gits stgit for Bazaar available?
[15:56] <Leonidas> or what is the preferred way in bazaar to track patches which are supposed to be send via mail when they are done?
[15:56] <Stavros> i did a "bind" and a "push" but the push is not pushing where i bound,what do i do?
[16:00] <radix> Stavros: if you bind, you don't need to push
[16:00] <radix> Stavros: commits will automatically be pushed
[16:00] <fullermd> push defaults to its own location, different from bind.
[16:01] <mgedmin> I cannot use bzr diff while writing a commit message :(
[16:01] <mgedmin> bad usability, imho
[16:01] <radix> Leonidas: with a branch?
[16:01] <fullermd> mgedmin: It's generally considered a bug.
[16:01] <radix> mgedmin: I've found that annoying too
[16:02] <Leonidas> radix: imagine the following setup: there is an remote repository to which I have no access. Now, I cloned it and want to make some improvements to the code. So, what would be "the Bazaar way" of doing this?
[16:04] <fullermd> Leonidas: The normal way would just be to go ahead and work on it and commit in your branch.
[16:04] <fullermd> I thought I heard of somebody some months ago looking at making mq work with bzr, but I may be imagining it.  I don't think anybody's come out and declared success with it.
[16:06] <Leonidas_> sorry, connection problem.
[16:06] <Leonidas> fullermd: ok, but what would happen on merges?
[16:07] <Leonidas> hmm, I think I really should try it out myself, instead of aksing stupid questions
[16:08] <Leonidas> But at least I know how to handle it with bzr
[16:10] <fullermd> Well, merges would just be merges.
[16:13] <radix> Leonidas: so, you might have many local branches
[16:13] <radix> Leonidas: you might branch the upstream to "upstream", then branch *that* to "fix-for-my-bug"
[16:13] <radix> Leonidas: in other words, you should represent distinct change sets as distinct branches
[16:14] <radix> (I use the word "change sets" loosely -- a fix for a bug or a new feature)
[16:14] <Leonidas> radix: but when I update the upstream branch I would need to update every single branch, right?
[16:14] <radix> Leonidas: well, hopefully you'll get those other branches merged quickly.
[16:15] <radix> Leonidas: And it's ok if it gets a little bit out of date; as long as no conflicting changes are made, it'll still be mergable.
[16:15] <radix> well, of course it'll be mergeable in any case, but the conflicts will need to be resolved after the merge.
[16:16] <Leonidas> fine :)
[17:10] <jrydberg_> odd question: but do anyone know of there's a package out there that provides more or less "bzr shelve" but for subversion?
[17:11] <LarstiQ> jrydberg_: not directly, but I'd try quilt
[17:12]  * mgedmin always used svn diff > my.diff; less my.diff; svn revert -R
[17:13] <jrydberg_> mgedmin: that is an option :)
[17:18] <jrydberg_> darn, so i have to port shelve to subversion. hehe
[17:21] <Stavros> does "pull" update the working copy if it hasn't diverged?
[17:22] <fullermd> Actually, pull tries to update the working copy even if it is diverged.
[17:24] <Stavros> hmm, how does it do that?
[17:24] <radix> I thought pull doesn't do anything if the branches have diverged.
[17:25] <fullermd> Well, I mean the WT diverged; local uncommitted changes.
[17:25] <radix> oh. I see.
[17:25] <fullermd> If the branches are diverged of course it just says "No way"
[17:25] <Stavros> how does it update the working copy if it diverged?
[17:26] <fullermd> Pretty much the same was 'cvs up' will try to merge in local uncommitted changes.
[17:27] <Stavros> ah
[17:27] <Stavros> what's the difference between a bound branch and doing "push" after "commit"?
[17:28] <fullermd> The bound branch won't let you commit if you're out of date.
[17:29] <fullermd> It's not a bound branch, it's a checkout.
[17:29] <Stavros> ah, so it has to communicate to the server at all times
[17:29] <Stavros> like a centralized vcs
[17:29] <fullermd> When you commit, certainly.
[17:29] <fullermd> Yeah, that's the workflow.
[17:29] <Stavros> aha, thanks
[17:39] <AnMaster> hey it seems trac-bzr is broken with trac 0.11
[17:40] <AnMaster> in #trac they said it was a problem in the plugin and iirc that means I got to ask in this channel
[17:40] <AnMaster> http://rafb.net/p/TNLFPz34.html
[17:41] <Stavros> does that plugin generally work well?
[17:42] <AnMaster> yes it worked with 0.10.4
[17:43] <Stavros> aha, i must try it
[17:44] <AnMaster> Stavros, however completely broken with 0.11, tried all the branches at launchpad
[17:44] <AnMaster> and no recent development
[17:49] <Stavros> hmm :/
[17:51] <Verterok_> AnMaster: I fixed (it's only a workaround) to work with 0.11ç
[17:51] <AnMaster> Verterok_, how?
[17:51]  * Verterok_ searching for the url to the branch
[17:56] <AnMaster> Verterok_, ?
[17:57] <AnMaster> brb phone, will check it when I get back
[17:57] <Verterok_> AnMaster: I'm on it...
[17:58] <Verterok> AnMaster: https://code.launchpad.net/~guillo.gonzo/trac-bzr/trac-0.11dev
[17:59] <Verterok> AnMaster: I'm running a trac instance with that plugin for bzr-eclipse (but I'm moving it to launchpad)
[18:02] <Verterok> AnMaster: don't know if it still work for the current trunk of trac :P
[18:04] <AnMaster> Verterok, tried it, didn't work
[18:04] <AnMaster> and I'm using pre-release 0.11b1
[18:04] <AnMaster> so not trunk
[18:04] <AnMaster> beta1
[18:09] <abentley> jrydberg_: shelve probably works with the bzr-svn plugin :-)
[18:10] <Verterok> AnMaster: I'l take a look and see if I can fix it
[18:11] <abentley> mgedmin: There is the --show-diff commit option, which will allow you to see the diff.
[18:11] <mgedmin> yay, good
[18:12] <mgedmin> now I need to make some changes to see the diff :)
[18:17] <mgedmin> mhm, no short version of --show-diff...
[18:17] <mgedmin> vim doesn't know how to syntax-highlight diffs in the commit message
[18:17] <dato> mgedmin: http://chistera.yi.org/~adeodato/code/bzr/bzr-vim/
[18:18] <dato> I should really try to get my version to replace or enhance the current one bundled with vim
[18:18] <mgedmin> thanks
[18:48] <jrydberg_> abentley: hehe
[18:48] <jrydberg_> abentley: anyhow, i ripped out the shelf parts from bzrtools and wrote a patchsource for subversion.  easy as 1 2 3.
[18:48] <abentley> Ah, cool.
[18:49] <jrydberg_> os.popen('svn diff') :)
[18:49] <abentley> I think it would be nice if bzr was a good svn client.
[19:04] <mgedmin> that reminds me
[19:04] <mgedmin> last time I tried, it wasn't
[19:04] <mgedmin> it's time to try again
[19:09] <Verterok> AnMaster: I just get a trac-0.11b1 running with timhatch branch: https://code.launchpad.net/~timhatch/trac-bzr/thatch-dev
[19:10] <AnMaster> Verterok, odd, I tried that here without success
[19:10] <AnMaster> did you do anything special?
[19:10] <AnMaster> Verterok, and did you try to enter plugin page in webadmin ui (where I got the error)
[19:11] <Verterok> AnMaster: no just borowse source, let's try
[19:11] <Verterok> AnMaster: I need to setup an admin user, right?
[19:12] <AnMaster> yes, someone with TRAC_ADMIN iirc
[19:13] <Verterok> ok
[19:14] <Peaker_> is there a way to get a passwordless login with a paramiko public key (sftp) in Windows?
[19:14] <Leonidas> dennda: hast du grad noch nen moment zeit?
[19:14] <Leonidas> oh, sorry, wrong channel
[19:14] <dennda> :)
[19:15] <AnMaster> Peaker_, well use ssh keys?
[19:15] <Peaker_> AnMaster, I know how to do that with ssh, but how to do it with paramiko?
[19:15] <Peaker_> AnMaster, How do I know what the public key is to add it to authorized_keys2?
[19:15] <AnMaster> hm it doesn't make use of putty?
[19:16] <Peaker_> AFAIK, it used paramiko only, but I do have putty here
[19:16]  * AnMaster is a linux/freebsd user
[19:16] <AnMaster> since 5 years
[19:16] <Peaker_> AnMaster, me too, I'm visiting my folks and they use Windows :-(
[19:16] <Peaker_> Maybe I'll just install Ubuntu here somewhere...
[19:17] <AnMaster> well iirc putty got some ssh-agent thingy
[19:17] <AnMaster> and paramiko (or whatever) does use ssh-agent on linux at least
[19:20] <Peaker_> I haven't told it about putty's existence, so I'm guessing paramiko uses its own/pycrypto implementation
[19:20] <Peaker_> I found how to create a key pair with paramiko, but not sure how to get bzr to use that key
[19:24] <AnMaster> Verterok, result?
[19:24] <Verterok> same error
[19:25] <Verterok> but I think I'm close to find the cause :)
[19:26] <mgedmin> ouch
[19:26] <mgedmin> 21578 mg        18   0 1162m 861m 3456 R   67 43.4  12:01.54 bzr
[19:27] <mgedmin> that's me attempting to bzr co svn+ssh from a repo with 5620 revisions
[19:27] <mgedmin> and it fails with bzr: ERROR: mismatched lock context and write group after 18 minutes
[19:28] <mgedmin> a gig of ram is a bit excessive for < 30 megs of source code
[19:28] <mgedmin> fwiw git-svn is also unable to cope with this repo, if that's any consolation
[19:30] <LarstiQ> mgedmin: http://subversion.tigris.org/issues/show_bug.cgi?id=3052
[19:33] <mgedmin> fixed 3 days ago, yay
[19:34] <LarstiQ> mgedmin: and possibly in 1.4.7
[19:34] <mgedmin> gutsy has 1.4.4dfsg1-1ubuntu3
[19:34] <LarstiQ> mgedmin: 1.4.7 is still in the release process
[19:36] <dato> mgedmin, LarstiQ: jelmer commited to bzr-svn code to workaround a  memory leak in the bindings (see r806). maybe just running bzr-svn from the branch will help.
[19:36] <mgedmin> which branch?
[19:37] <Verterok> AnMaster: I just find  workaround for the erro ;)
[19:37] <dato> mgedmin: http://people.samba.org/bzr/jelmer/bzr-svn/0.4/
[19:37] <AnMaster> Verterok, you found one?
[19:37] <dato> mgedmin: cd ~/.bazaar/plugins && bzr get http://people.samba.org/bzr/jelmer/bzr-svn/0.4 svn
[19:38] <jelmer> The workaround in bzr-svn itself only works around the main memory leak
[19:38] <dato> aha
[19:38] <jelmer> the fix in subversion upstream fixes all leaks
[19:38] <mgedmin> is there more than one?
[19:38] <mgedmin> sounds fun
[19:38] <Verterok> AnMaster: in backend.py add define a top level/global variable: version = '0.2'
[19:38] <Verterok> AnMaster: that should do the trick :)
[19:38]  * mgedmin upgraded ram to 2 gigs just last week
[19:38] <AnMaster> I will try it shortly, got some telephone calls to make and such
[19:38] <jelmer> however, you probably won't notice the others leaks because they're quite small
[19:39] <Verterok> ok
[20:05] <mgedmin> 16 minutes and BAM!
[20:05] <mgedmin> bzr: ERROR: exceptions.TypeError: int argument required
[20:08] <mgedmin> https://bugs.launchpad.net/bzr/+bug/178149
[20:08] <ubotu> Launchpad bug 178149 in bzr "bzr co svn+ssh:/// gets a TypeError" [Undecided,New]
[20:12] <luks> that looks like a bug in bzr-svn, not bzr
[20:12] <jelmer> mgedmin, yeah, I just reassigned
[20:13] <mgedmin> sorry, I just clicked on the "please report this bug here" link
[20:13] <mgedmin> without paying much attention
[20:13] <jelmer> no worries
[20:13] <jelmer> mgedmin, Any chance you can run it again with BZR_PDB=1 set?
[20:13] <mgedmin> sure
[20:14] <mgedmin> that was quick
[20:14] <mgedmin> bzr: ERROR: File exists: u'/home/mg/tmp/trunk/.bzr'
[20:14] <mgedmin> heh, I typed du when I meant rm -rf
[20:15] <mgedmin> (fwiw the old checkout left after the crash was 48 megs)
[20:15] <mgedmin> I probably shouldn't say checkout given that it's a full-fledged bzr branch, no?
[20:15] <mgedmin> wait, I did bzr co, not bzr get
[20:15] <jelmer> checkout is the appropriate term
[20:15] <jelmer> the other thing is "lightweight checkout" which is just a working tree
[20:16] <jelmer> without a full-fledged branch
[20:16] <jelmer> mgedmin: Are you using the 0.4 branch?
[20:16] <mgedmin> late saturday evening -> brain not at its best
[20:16] <mgedmin> yes, 0.4 branch
[20:16] <mgedmin> bzr revno says 822
[20:19] <jelmer> yep, that's the latest
[20:33] <mgedmin> (Pdb)
[20:33] <mgedmin> /usr/lib/python2.5/site-packages/bzrlib/xml5.py(216)write_inventory()
[20:33] <mgedmin> ie.text_size is None
[20:34] <mgedmin> which seems interesting to me
[20:34] <mgedmin> ie is an InventoryFile, and it seems to be a symlink in subversion
[20:35] <mgedmin> yep, that revision added a symlink to the svn repo
[20:35] <mgedmin> does bzr-svn support symlinks?
[20:35] <mgedmin> ie.kind == 'file'
[20:36] <jelmer> was this a revision pushed by bzr-svn ?
[20:37] <mgedmin> no
[20:37] <mgedmin> but I've had trouble with symlinks in that svn repo before
[20:37] <mgedmin> symlinks suddenly becoming plain files with 'link ../../lalala' inside
[20:37] <mgedmin> and svn st not noticing anything strange
[20:37] <mgedmin> svn revert failing to fix the problem
[20:38] <mgedmin> but rm'ing and svn up'ing would fix the problem
[20:38] <mgedmin> in the end I removed all symlinks and replaced them with copies
[20:39] <jelmer> Symlinks in Subversion are basically regular files with "link ../foo" inside
[20:39] <jelmer> and a special property "svn:special" set to "*"
[20:39] <mgedmin> and a special property
[20:39] <mgedmin> yes
[20:39] <mgedmin> svn proplist -r url-to-that-file gives me an empty list
[20:39] <mgedmin> weird
[20:40] <jelmer> are you still in the debugger?
[20:40] <jelmer> can you paste the contents of ie?
[20:40] <mgedmin> yes
[20:40] <mgedmin> InventoryFile('6777@1f28630d-58db-0310-90fc-ab02c05bae6f:trunk:team%2Fbrowser%2Ftexts%2Fspelling.tt', u'spelling.tt', parent_id='1990@1f28630d-58db-0310-90fc-ab02c05bae6f:trunk:team%2Fbrowser%2Ftexts', sha1=None, len=None)
[20:41] <jelmer> and ie.kind == 'file' ?
[20:41] <mgedmin> yes
[20:41] <mgedmin> aha
[20:41] <mgedmin> svn log on that file gives me two revisions:
[20:42] <mgedmin> 6777 where I added the symlink
[20:42] <mgedmin> and 6779 where I manually set svn:special to "*"
[20:42] <mgedmin> because svn proplist in my working directory showed it
[20:42] <mgedmin> but svn proplist in a fresh checkout didn't
[20:42] <jelmer> ah
[20:43] <mgedmin> I don't know how I managed to convince svn to commit it this way to the repo
[20:43] <mgedmin> IIRC I once spent an afternoon trying to recreate any of my symlink problems with svn so I could file a proper bug report
[20:44] <jelmer> what does "svn cat -r6779 <that-file>" show?
[20:44] <mgedmin> but I failed at that
[20:44] <mgedmin> svn cat of both 6779 and 6777 show "link ../../../threesixty/browser/texts/spelling.tt" (no trailing newline)
[20:46] <jelmer> I think I know what the problem is
[20:46] <jelmer> bzr-svn supports changing the kind of a file
[20:46] <jelmer> but only if the contents of that file also change
[20:47] <mgedmin> heh
[20:47] <jelmer> that usually always happens,  because you don't tend to have files that contain "link .../..," that you then turn into a symlink
[20:47] <mgedmin> not by choice, no
[20:47]  * jelmer sees if he can reproduce in a bzr-svn testcase
[20:48] <abentley> Ah, heh.  Tricky.
[20:48] <abentley> I had to deal with that issue when writing _iter_changes, too.
[20:59] <jelmer> yeah, these are really funny corner cases
[20:59] <jelmer> it looks like subversion doesn't allow kind changes in general, it just requires you to delete and re-add
[20:59] <jelmer> however, Marius somehow seems to've worked around their usual checks :-)
[21:02] <jelmer> mgedmin, the patch at http://samba.org/~jelmer/bzr-svn-ensure-kind.diff may help
[21:02]  * mgedmin whistles nonchalantly
[21:02] <jelmer> it's untested as I haven't found a way to make svn stop complaining about changes to svn:special
[21:03] <jelmer> if you still remember how you managed that, I'm interested to hear about it :-)
[21:03] <mgedmin> I can't remember what I don't know :/
[21:07] <mgedmin> it's somewhat unfair how bugs in svn make bzr-svn look bad
[21:08] <jelmer> heh, yeah
[21:16] <mgedmin> As others have pointed out in stronger terms, I’m not a physicist. (On the other hand, the gentleman linked to in the previous sentence is not correct about my being paid by the NSA to discredit Canadian quantum computing efforts: it’s actually the GCHQ and the Mossad.)
[21:16] <mgedmin>     -- http://scottaaronson.com/blog/
[21:24] <mgedmin> jelmer: nope, that patch doesn't fix the problem
[21:25] <mgedmin> same error in same place
[21:26] <mgedmin> I'll try to create a small svn repo with the same sort of kind change
[21:26] <jelmer> are you sure? I just reproduced the problem here and the patch seems to fix the problem
[21:26] <mgedmin> if I feel bored during the holidays
[21:26]  * mgedmin is staring at the pdb prompt
[21:27]  * mgedmin runs bzr diff in ~/.bazaar/plugins/svn
[21:28] <jelmer> now also committed as 823
[21:30]  * mgedmin runs bzr pull
[21:30] <mgedmin> yep, I had that patch applied, and bzr pull merged it cleanly
[21:31] <mgedmin> yet ie.kind == 'file'
[21:31] <mgedmin> nm, it's not like it's an urgent problem for me
[21:31] <mgedmin> for a while yet I've been investigating bzr and bzr-svn, waiting until switching to it becomes pain-free
[21:32] <mgedmin> this was just another of those idle curiosity attempts
[21:34] <jelmer> mgedmin: well, it'd be nice to get a testcase done now
[21:39]  * mgedmin wrestles with svnadmin dump
[21:41] <mgedmin> I don't get it
[21:41] <mgedmin> rev 6777 was a tiny one that added 4 lines to one text file and added one symlink
[21:42] <mgedmin> yet svnadmin dump -r 6777 produces who-knows-what
[21:42] <mgedmin> oh, right
[21:42] <mgedmin> I forgot the --incremental
[21:43] <mgedmin> here's what svnadmin dump says: http://bzr.pastey.net/79411
[21:43] <mgedmin> Node-action: replace
[21:43] <mgedmin> no properties
[21:44] <mgedmin> haha
[21:45] <jelmer> re
[21:45] <mgedmin> I know how I replaced that file:
[21:45] <mgedmin> cd workingdir; svn rm regularfile; ln -s target regularfile; svn add regularfile; svn ci -m "replace file with symlink"
[21:46] <mgedmin> hm, but it works fine when I try it today
[21:47] <mgedmin> the original commit was on 2007-11-20, so I used the same version of svn then (the one in gutsy)
[21:48] <mgedmin> weird
[21:48] <jelmer> hmm, so the new file that replaced the original didn't actually have svn:special set?
[21:48] <mgedmin> in the real repo -- didn't
[21:48] <mgedmin> in my test repo -- did
[21:52] <jelmer> did r6778?
[21:53] <mgedmin> http://bzr.pastey.net/79412
[21:54] <mgedmin> 6778 changed two unrelated files
[21:54] <mgedmin> 6779 changed just the svn props
[21:54] <mgedmin> fwiw the repository is version '3'
[21:54] <mgedmin> while svn 1.4 introduced version '5'
[21:54] <mgedmin> I never did the dump/reload to convert it
[21:54] <jelmer> the <...> in the bit you just pasted were the contents of the file?
[21:55] <mgedmin> no, that was the commit message and unrelated metadata
[21:56] <mgedmin> it's possible that I did the svn propset svn:special '*' with a svn 1.3 client (on ubuntu dapper)
[21:56] <mgedmin> svn 1.4 from ubuntu gutsy refuses to commit that propset
[21:56] <mgedmin> sadly svn metadata doesn't record the client version or the hostname
[21:57] <jelmer> you may be able to make a change using a svndump
[21:58] <mgedmin> I suppose so
[21:59] <mgedmin> but "don't fix what ain't broke" applies here -- svn seems to work fine with it
[21:59] <mgedmin> it'll be something to keep in mind when we eventually decide to migrate to another tool
[22:04] <jelmer> mgedmin, any chance you can paste the relevant bit of the svndump from 6777?
[22:05] <mgedmin> what is the relevant bit?
[22:05] <mgedmin> I already pasted  http://bzr.pastey.net/79411
[22:05] <mgedmin> it's from 6777
[22:05] <jelmer> ah, thanks
[22:08] <jelmer> and 6778 didn't change this file?
[22:10] <mgedmin> no
[22:10] <mgedmin> but a later revision did
[22:11] <mgedmin> no, actually not
[22:11] <mgedmin> I thought I replaced that symlink with a regular file
[22:11] <mgedmin> I didn't
[22:11] <mgedmin> it's still a symlink
[22:11] <mgedmin> svn log on it shows only two revisions
[22:12] <mgedmin> forget whatever I said about svn rm regularfile; ln -s; svn add regularfile ---- that was a completely different one in another part of the source tree
[22:12] <mgedmin> it is possible though that I svn added a regular file, and then changed my mind and silently replaced it with a symlink before committing
[22:13] <jelmer> ah, ok
[22:14] <jelmer> mgedmin: Btw, when you retried with the patch, did you blow away the bzr repository you were fetching into?
[22:14] <mgedmin> yes
[22:14] <mgedmin> bzr aborts very early if I don't do that anyway
[22:15] <mgedmin> what, bzr-svn won't allow me to check out a subtree?
[22:15] <mgedmin> how un-svn-like
[22:15] <mgedmin> I wanted to try again without waiting for 15 minutes
[22:15] <jelmer> try removing ~/.bazaar/subversion.conf and trying again
[22:16] <jelmer> that's a bit of a hack, as bzr doesn't have much of a ui for checking out subtrees yet
[22:16] <mgedmin> 33 revisions, 9 seconds, no errors
[22:16] <jelmer> and that included the problematic file?
[22:16] <mgedmin> yes
[22:17] <mgedmin> it's a broken symlink
[22:17] <mgedmin> but if I try to do that with the parent directory, boom
[22:17] <mgedmin> same error after 16 seconds
[22:18] <mgedmin> interesting, isn't it?
[22:18] <mgedmin> bzr co svn+ssh://.../trunk/team/browser/texts succeeds
[22:18] <mgedmin> bzr co svn+ssh://.../trunk/team/browser fails
[22:18] <jelmer> yeah, that's really odd
[22:18] <mgedmin> the inventory file object on the failure refers to trunk/team/browser/texts/spelling.tt
[22:19] <mgedmin> wait, this is interesting
[22:19] <mgedmin> ah, no it isn't
[22:19] <mgedmin> I just saw a : instead of a %2F
[22:19] <mgedmin> and then realized it's how bzr replaces the branch name from the directory name
[22:19] <mgedmin> s/replaces/separates/
[22:19] <mgedmin> s/realized/guessed/
[22:21] <``Cube> hello
[22:21] <``Cube> im a tango artist
[22:21] <``Cube> a long time ago, someone from you asked me to create some icons
[22:21] <``Cube> I created some, but they, (sorry for that languaged) sucked
[22:21] <``Cube> now, I'd like to retry
[22:22] <jelmer> hi ``Cube
[22:22] <``Cube> hello jelmer
[22:22] <jelmer> ``Cube: do you remember who you had contact with earlier?
[22:22] <``Cube> well
[22:22]  * mgedmin sometimes dreams about asking a tango artist to create some icons for gtimelog
[22:22] <``Cube> ill look
[22:22] <``Cube> gtimelog?
[22:22] <``Cube> tell me what icons you need!
[22:22] <mgedmin> http://mg.pov.lt/gtimelog/
[22:23] <``Cube> yep
[22:23] <``Cube> got him
[22:23] <mgedmin> an application icon would be enough
[22:23] <``Cube> (mgedmin, later, ok?)
[22:23] <``Cube> oh, I love making app icons
[22:23] <mgedmin> sure
[22:23] <``Cube> ill do that
[22:23] <mgedmin> I wish I had talent for making icons...
[22:23] <``Cube> but for now, first id like to finish this ok?
[22:23] <``Cube> :P
[22:23] <mgedmin> sure
[22:23] <``Cube> I don't even know if I have, we will see :P
[22:23] <``Cube> ill add you...
[22:24] <``Cube> ok
[22:24] <``Cube> jelmer: Daniel Schierbek
[22:24] <``Cube> *Schierbeck
[22:24] <jelmer> ah, ok
[22:24] <``Cube> know him, right?
[22:24] <jelmer> yep
[22:24] <jelmer> He's asked about bzr-gtk I presume?
[22:24] <``Cube> I don't know
[22:24] <``Cube> its a long time ago now
[22:24] <``Cube> tell him these icons were really bad
[22:24] <``Cube> I had actually no tango skill yet
[22:25] <``Cube> I hope I have now :P
[22:25] <``Cube> we will see
[22:25] <``Cube> I need a list of icons and what sizes you need
[22:25] <jelmer> Having better icons would be very nice! :-)
[22:25]  * mgedmin checks whether his email is on that page... yep, it's there at the bottom
[22:25] <``Cube> and I'd love to be the author of 'em
[22:26] <jelmer> ``Cube: Do you need the list right now? It would be nice to bring up on the bzr-gtk mailing list
[22:26] <``Cube> sure
[22:26] <``Cube> well :D
[22:26] <``Cube> I reinstalled my os today
[22:26] <``Cube> have no mail app installed yet
[22:27] <``Cube> I don't need the list right now, but having it would be nice
[22:27] <``Cube> so, if I can't start with bazaar now
[22:28] <``Cube> mgedmin: it's time for you!
[22:28] <mgedmin> uh oh
[22:28] <``Cube> hehe ;)
[22:29] <``Cube> ah I see you're the author
[22:29] <``Cube> do you already have an idea for the icon?
[22:29] <``Cube> something with a clock?
[22:29] <``Cube> maybe a list with a clock?
[22:29] <mgedmin> yes, currently I stol^H^H^H *borrowed* one of the GNOME icons that had a clock in it
[22:29] <``Cube> I think this is the main idea of the program -> to track (~list) your time?
[22:29] <mgedmin> yes
[22:30] <``Cube> would that be a good idea?
[22:30] <mgedmin> yes
[22:30] <mgedmin> oh, my, it's past midnight
[22:30] <mgedmin> time to go home
[22:30]  * mgedmin at work, but not precisely working ;)
[22:30] <``Cube> ;)
[22:30]  * ``Cube asks where there will be a windows version of your program?
[22:30] <mgedmin> many thanks for your kind offer
[22:30] <``Cube> uh
[22:31] <mgedmin> it's written in python, and works on windows
[22:31] <``Cube> don't thank to early, maybe the icon will SUCK
[22:31] <``Cube> oh, cool
[22:31] <mgedmin> but there's no convenient installer right now
[22:31] <mgedmin> so you have to download python and pygtk manually
[22:31] <``Cube> hmm ok
[22:31] <mgedmin> maybe one day I'll figure out how to use py2exe
[22:31] <``Cube> is there any alternative to your program?
[22:31] <mgedmin> lots
[22:31] <``Cube> oh :D
[22:31] <mgedmin> :)
[22:32] <``Cube> any example?
[22:32] <mgedmin> but when I was looking for some, I was looking for linux ones
[22:32] <mgedmin> so if you want a windows one, I can't help you
[22:32] <``Cube> a nice, open source, well designed one
[22:32] <``Cube> oh yes, sure
[22:32] <``Cube> I mean, your if nice of course too
[22:32] <TFKyle> hmm, that reminds me, need to figure out how to extend py2exe so it gets the newest gtk runtime automatically
[22:32] <``Cube> just asking
[22:32] <``Cube> ok
[22:32] <``Cube> im gona start desning
[22:32] <``Cube> are you gonna stay long here, mgedmin?
[22:32] <mgedmin> hm does bzr-gtk have a convenient windows installer?
[22:33] <mgedmin> I might want to steal some ideas
[22:33] <mgedmin> ``Cube: not really
[22:33] <``Cube> hmm ok
[22:33]  * mgedmin a bit sleepy
[22:33] <jelmer> hmm
[22:33]  * ``Cube too
[22:33]  * jelmer gives gtimelog a try
[22:33] <jelmer> I've actually been looking for something like this
[22:34]  * ``Cube also thinks gtimelog ain't a bad idea
[22:34] <jelmer> strange way to come across it now :-)
[22:34]  * ``Cube is going to use it maybe...
[22:34] <``Cube> but first icon!
[22:34] <mgedmin> I've heard some people at canonical are using it
[22:34]  * fullermd will stick with vi and flat-files   :p
[22:34] <mgedmin> it's a bit ironic that I stopped using it myself
[22:34] <mgedmin> (low productivity -> sad-looking reports -> depression -> even lower productivity)
[22:34] <``Cube> juhu! 30 minutes and its my birthday!
[22:34] <mgedmin> (bad vicious cycle)
[22:35] <mgedmin> ``Cube: congratulations!
[22:35] <``Cube> :P thanks
[22:36] <jelmer> mgedmin: Thanks for the help tracking down at least one bug in bzr-svn
[22:36] <mgedmin> any time you want a broken svn repo, come to me
[22:36] <mgedmin> have I told about the one (a repo of my home directory) that made svn loop forever eating more and more memory?
[22:36] <mgedmin> ah, that was fun
[22:36] <jelmer> wow
[22:37] <jelmer> How did you manage to get it to do that?
[22:37] <mgedmin> somehow the revision graph became cyclic
[22:37]  * mgedmin just uses stuff, and stuff usually breaks on its own
[22:37] <jelmer> :-)
[22:38] <mgedmin> maybe not the revision graph, just the delta-based storage for the svn:ignore property on /
[22:38] <mgedmin> rev X is rev Y plus this change, while rev Y is rev X plus this other change
[22:38]  * mgedmin had to edit C code to unbreak the repo
[22:38]  * mgedmin converted all his repos from bdb to fsfs the next day
[22:40] <mgedmin> ``Cube: if you ever get bored, http://mg.pov.lt/pyspacewar/ also could use an icon -- and it runs on windows too, if you install pygame
[22:40] <mgedmin> bye, all!
[22:40] <``Cube> see you
[22:40] <jelmer> goodnight Marius
[23:29] <deepjoy> Hi is there anywhere I can see more detailed development targets and status than in launchpad Blueprints?
[23:32] <Verterok> deepjoy: the other place I look for info is http://bazaar-vcs.org/
[23:37] <jelmer> deepjoy: The mailing list should give you some indication of what people are working on
[23:38] <jelmer> deepjoy: Are you looking for development targets in general or rather what the plans are for particular targets?
[23:51] <Verterok> jelmer: do have a minute to chat about: Bug #161830 ?
[23:51] <ubotu> Launchpad bug 161830 in bzr-svn "log should show subversion revision numbers as well as branch/bzr revision info" [Wishlist,Triaged] https://launchpad.net/bugs/161830
[23:52] <jelmer> sure
[23:53] <Verterok> as I have been working a bit with log formatters for the xmloutput plugin
[23:54] <Verterok> a simple solution to that bug could be to add a show_properties function, just like the LogFormatter have a begin_log and end_log functions
[23:56] <Verterok> the only thing I didn't figured out yet is where the call to show_properties should go
[23:56] <jelmer> Verterok: and show_properties() would get a dictionary or something?
[23:57] <Verterok> actually it's a method of LogFormatter so it have access to the revision
[23:57] <Verterok> and to all the properties in it
[23:59] <Verterok> but it should be better that show_propeties get a dict with the right properties. i.e: without branch-nick because log show it later


[15:56] <smoser> o/
[16:00] <smoser> #startmeeting ubuntu-server-team
[16:00] <meetingology> Meeting started Tue Dec 10 16:00:32 2013 UTC.  The chair is smoser. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[16:00] <meetingology> Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #endvote #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #progress #rejected #replay #restrictlogs #save #startmeeting #subtopic #topic #unchair #undo #unlurk #vote #voters #votesrequired
[16:00] <smoser> welcome to this weeks' exciting adventure of the Ubuntu Server Team meeting.
[16:00] <jamespage> o/
[16:01] <smoser> #link https://wiki.ubuntu.com/ServerTeam/Meeting
[16:01] <smoser> that link above is for all who are playing along at home.
[16:01] <smoser> #topic Review ACTION points from previous meeting
[16:01] <smoser> * gaughen file bug with status.u.c to get ubuntu server topic tracking in there (carry over)
[16:02] <smoser> gaughen, is that http://status.ubuntu.com/ubuntu-t/group/topic-t-servercloud-overview.html ?
[16:02] <jamespage> we appear to still be missing quite a few bp's - I'm not sure whether its status of what
[16:02] <smoser> I think it is, so if no one objects i'm calling that one done. if someone does object, bother me later. moving on.
[16:03] <smoser> missing bps ?
[16:03] <smoser> oh, yeah, we do.
[16:03] <smoser> hm..
[16:03] <smoser> well, i'll carry that over then.
[16:04] <smoser> #ACTION gaughen or jamespage or smoser: get all server blueprints represented at /topic-t-servercloud-overview.html
[16:04] <meetingology> ACTION: gaughen or jamespage or smoser: get all server blueprints represented at /topic-t-servercloud-overview.html
[16:04] <smoser>  * everyone look at grep-merges output and merge/sync as much and early as possible
[16:04] <smoser> if you've been doing the above, please continue. if you've not, please start looking atmerges.
[16:05] <smoser> merges are a good way to get started with ubuntu development and someone (smoser) can help you if you want to get started and need to find osmething that would make a good target for that.
[16:06] <smoser>   * jamespage to send email on server seed [carry over)
[16:06] <jamespage> done
[16:06] <smoser> that looks to me to be done at done at https://lists.ubuntu.com/archives/ubuntu-devel/2013-December/037849.html
[16:06] <smoser> #topic Trusty Development
[16:06] <smoser> #link https://wiki.ubuntu.com/TrustyTahr/ReleaseSchedule
[16:06] <smoser> we do have an alpha1 coming up on the 19th
[16:07] <smoser> and we're planning on alpha1 cloud images.
[16:07] <smoser> #link http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-t-tracking-bug-tasks.html#server
[16:07] <smoser> #subtopic Release Bugs
[16:07] <smoser> #link http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-t-tracking-bug-tasks.html#server
[16:08] <smoser> i dont really want to walk through stuff there.
[16:10] <smoser> please just take a look at those bugs and if you *should* be working on them, do , and if you want to help out, pleease feel free for that.
[16:10] <smoser> #subtopic Blueprints
[16:10] <smoser> #link http://status.ubuntu.com/ubuntu-t/group/topic-t-servercloud-overview.html
[16:10] <smoser> as pointed out, we need to get that list updated.
[16:10] <smoser> jamespage and I and gaughen went through the list last week, and go tmost into reasonable order.
[16:11] <hallyn_> we might want https://blueprints.launchpad.net/ubuntu/+spec/core-1311-cgroup-manager tracked there
[16:11] <smoser> https://blueprints.launchpad.net/ubuntu/?searchtext=servercloud-1311
[16:12] <smoser> please follow up with gaughen to get that done, hallyn.
[16:13] <caribou> did someone had a chance to congratulate hallyn_ on making lwn.net's first page with that topic ?
[16:13] <smoser> :). lets hold that to the open discussion.
[16:13] <caribou> smoser: sorry, I coudln't resist
[16:13] <smoser> so for blueprints, the work item there is that you should work on your blueprints and the material they reference.
[16:14] <smoser> jamespage, or i or gaughen or jcastro maybe will make sure they get into that pretty tracker
[16:14] <smoser> #topic Server & Cloud Bugs (caribou)
[16:14] <smoser> caribou, now its your turn to talk.
[16:14] <caribou> smoser: nothing on my end, thank you
[16:14] <smoser> #topic Weekly Updates & Questions for the QA Team (psivaa)
[16:15] <smoser> psivaa,
[16:15] <psivaa> smoser: no updates from us
[16:15] <smoser> #topic Weekly Updates & Questions for the Kernel Team (smb)
[16:15] <smb> Nothing exiting from here. Finally completed the Xen MRE updates, starting with security, maybe return with more MRE. Xen from libvirt in Trusty currently broken. Looking at zul's ppa of 1.2.0 still seems to come up blank. ;) Started to look on bug 1258631.
[16:15] <smoser> yeah, thanks for that smb
[16:16] <smoser> also, sforeshee did a bit of investigation for me on viability of a "server" kernel
[16:17] <utlemming> smoser: is there a bug for tracking that investigation?
[16:17] <smoser> the end goal would b to have a cloud image and default 'server' kernel that were the same. and that would give us a cloud image that "just worked" on most server hardware also.
[16:18] <smoser> this would likely cost us some size in the cloud image, but would make us more functional.
[16:18] <smoser> investigation continues.
[16:18] <smoser> utlemming, there isn't a bug. i can forward you (and anyone else) what sforeshee sent me on it.
[16:18] <smoser> #topic Weekly Updates & Questions regarding Ubuntu ARM Server (rbasak)
[16:18] <rbasak> Nothing to report. Any questions for me?
[16:19] <smoser> #topic Open Discussion
[16:20] <smoser> #subtopic congratulations to the super rock star hallyn_
[16:20] <hallyn_> sigh
[16:20] <smoser> https://lwn.net/Articles/575672/
[16:20]  * rharper claps
[16:20] <hallyn_> all right all right
[16:20] <smoser> hallyn_, why can't you just use systemd ?
[16:20]  * smoser ducks
[16:20] <hallyn_> smoser won't let me
[16:20] <smoser> touche
[16:21] <smoser> #topic Ubuntu Server Team Events
[16:21] <smoser> anyone have any thing here?
[16:21] <smoser> #topic Announce next meeting date and time
[16:23] <smoser> the next meeting will be held in this same place exactly 603403 seconds from now.
[16:24] <caribou> smoser: is that octal or decimal ?
[16:24] <rbasak> caribou: base 10.
[16:24] <caribou> rbasak: roger that
[16:24] <smoser> hmm..
[16:24] <smoser> $ echo "next meeting is in: $(($(date +%s --utc --date="Dec 17 16:00") - $(date +%s))) seconds"
[16:24] <smoser> next meeting is in: 603313 seconds
[16:25] <smoser> caribou, feel free to fix that to do binary if you'd like.
[16:25] <smoser> next meeting:
[16:25] <smoser> Tue Dec 17 16:00:00 EST 2013
[16:25] <rbasak> caribou: http://i.stack.imgur.com/ldNco.png :)
[16:25] <smoser> #endmeeting
[16:25] <meetingology> Meeting ended Tue Dec 10 16:25:38 2013 UTC.
[16:25] <meetingology> Minutes (wiki):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2013/ubuntu-meeting.2013-12-10-16.00.moin.txt
[16:25] <meetingology> Minutes (html):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2013/ubuntu-meeting.2013-12-10-16.00.html
[16:26] <smoser> rbasak, nice.
[17:00] <jsalisbury> ##
[17:00] <jsalisbury> ##
[17:00] <meetingology> Meeting started Tue Dec 10 17:00:20 2013 UTC.  The chair is jsalisbury. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[17:00] <meetingology> Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #endvote #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #progress #rejected #replay #restrictlogs #save #startmeeting #subtopic #topic #unchair #undo #unlurk #vote #voters #votesrequired
[17:00] <jsalisbury> [LINK] https://wiki.ubuntu.com/KernelTeam/ReleaseStatus/Trusty
[17:00] <ppisati> o/
[17:00] <bjf> o/
[17:00] <arges> o/
[17:00] <cking> \o
[17:00] <henrix> o/
[17:00] <kamal> o/
[17:00] <smb> \o/
[17:01] <jsalisbury> [TOPIC] ARM Status (ppisati)
[17:01] <ppisati> nothing new to report this week
[17:01] <ppisati> ..
[17:01] <jsalisbury> [TOPIC] Release Metrics and Incoming Bugs (jsalisbury)
[17:01] <jsalisbury> Release metrics and incoming bug data can be reviewed at the following link:
[17:01] <jsalisbury> [LINK] http://people.canonical.com/~kernel/reports/kt-meeting.txt
[17:01] <jsalisbury> [TOPIC] Milestone Targeted Work Items (ogasawara)
[17:01] <ogasawara> yeek, 2 secs
[17:01] <ogasawara> [LINK] https://launchpad.net/~canonical-kernel-distro-team/+upcomingwork
[17:01] <ogasawara> [LINK] http://status.ubuntu.com/ubuntu-t/canonical-kernel-distro-team.html
[17:01] <ogasawara> || apw       || core-1311-kernel                || 5 work items ||
[17:01] <ogasawara> ||           || core-1311-cross-compilation     || 2 work items ||
[17:01] <ogasawara> ||           || core-1311-hwe-plans             || 1 work item  ||
[17:01] <ogasawara> || bjf       || core-1311-dmraid2mdadm          || 1 work item  ||
[17:01] <ogasawara> || ogasawara || core-1311-kernel                || 4 work items ||
[17:01] <ogasawara> ||           || client-1311-xorg-general        || 1 work item  ||
[17:02] <ogasawara> || sforshee  || servercloud-1311-cloud-images   || 1 work item  ||
[17:02] <ogasawara> || smb       || core-1311-dmraid2mdadm          || 1 work item  ||
[17:02] <ogasawara> ||           || servercloud-1311-openstack-virt || 5 work items ||
[17:02] <ogasawara> || rtg       || core-1311-hwe-plans             || 1 work item  ||
[17:02] <ogasawara> ||           || core-1311-kernel                || 1 work item  ||
[17:02] <ogasawara> ..
[17:02] <jsalisbury> [TOPIC] Status: Trusty Development Kernel (ogasawara)
[17:02] <ogasawara> The master branch for trusty has been rebased to the latest v3.12.4
[17:02] <ogasawara> upstream stable kernel.  We also continue to track the latest v3.13
[17:02] <ogasawara> kernel on our unstable branch and most recently rebased to v3.13-rc3.
[17:02] <ogasawara> We anticipate uploading a v3.13 based Trusty kernel to the archive after
[17:02] <ogasawara> the new year.
[17:02] <ogasawara> -----
[17:02] <ogasawara> Important upcoming dates:
[17:02] <ogasawara> [LINK] https://wiki.ubuntu.com/TrustyTahr/ReleaseSchedule
[17:02] <ogasawara> Thurs Dec 19 - Alpha 1 (~1 week away)
[17:02] <ogasawara> Thurs Jan 23 - Alpha 2 (~6 weeks away)
[17:02] <ogasawara> [LINK] https://wiki.ubuntu.com/PrecisePangolin/ReleaseSchedule
[17:02] <ogasawara> Thurs Dec 12 - 12.04.4 Kernel Freeze (this week!)
[17:02] <ogasawara> Thurs Jan 23 - 12.04.4 Final Release (~6 weeks away)
[17:02] <ogasawara> ..
[17:03] <jsalisbury> [TOPIC] Status: CVE's
[17:03] <jsalisbury> The current CVE status can be reviewed at the following link:
[17:03] <jsalisbury> http://people.canonical.com/~kernel/cve/pkg/ALL-linux.html
[17:03] <jsalisbury> ..
[17:03] <jsalisbury> [TOPIC] Status: Stable, Security, and Bugfix Kernel Updates - Saucy/Raring/Quantal/Precise/Lucid (bjf/henrix/sconklin)
[17:03] <bjf> Status for the main kernels, until today (Nov. 26):
[17:03] <bjf>   *   Lucid - Verification & Regression Testing
[17:03] <bjf>   * Precise - Verification & Regression Testing
[17:03] <bjf>   * Quantal - Verification & Regression Testing
[17:03] <bjf>   *  Raring - Verification & Regression Testing
[17:03] <bjf>   *   Saucy - Verification & Regression Testing
[17:03] <bjf> Current opened tracking bugs details:
[17:03] <bjf>   * http://people.canonical.com/~kernel/reports/kernel-sru-workflow.html
[17:03] <bjf> For SRUs, SRU report is a good source of information:
[17:03] <bjf>   * http://people.canonical.com/~kernel/reports/sru-report.html
[17:03] <bjf> ..
[17:04] <jsalisbury> [TOPIC] Open Discussion or Questions? Raise your hand to be recognized (o/)
[17:04] <jsalisbury> Thanks everyone
[17:04] <jsalisbury> #endmeeting
[17:04] <meetingology> Meeting ended Tue Dec 10 17:04:37 2013 UTC.
[17:04] <meetingology> Minutes (wiki):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2013/ubuntu-meeting.2013-12-10-17.00.moin.txt
[17:04] <meetingology> Minutes (html):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2013/ubuntu-meeting.2013-12-10-17.00.html
[17:04] <cking> thanks jsalisbury
[17:04] <kamal> thanks jsalisbury


[02:55] <kramer3d> hi
[02:55] <kramer3d> im trying to get the source from a project
[02:56] <kramer3d> and i keep getting this error You have not informed bzr of your Launchpad ID, and you must do this to write to Launchpad or access private data.  See "bzr help launchpad-login".
[04:45] <fullermd> kramer3d: That's usually not an error, just informative.
[04:45] <kramer3d> ok
[04:45] <kramer3d> ya i noticed it actually downloaded lol


[10:51] <rick_h> Morning
[13:05] <cmaloney> morning
[13:05] <cmaloney> rick_h: How was the trek to Cedar Point?
[13:06] <rick_h> cmaloney: it was good. Got the boy on three roller coasters so mission accomplished
[13:06] <rick_h> cmaloney: but then he wore out around 4pm and melted down on the log flume ride and we got tossed off it
[13:06] <rick_h> "Sir, I can't make him go on the ride if he doesn't want do"
[13:07] <rick_h> So it ended with a bang, but everyone agrees it should become an annual trip from now on so woot
[13:07] <cmaloney> rick_h: I can completely understand his reluctance on the lig flume
[13:07] <cmaloney> s/lig/log/
[13:07] <rick_h> well it the downhill looks scarier because of the running water I think
[13:07] <rick_h> "it's so steep!"
  I just asked my son this past week if he wanted to go to cedar point, and he said he was afraid haha.  we'll see.   How old is your boy?  Mine is 11.
[13:14] <rick_h> shakes808: 7
[13:14] <rick_h> shakes808: we're doing disney after thanksgiving so we're working on getting him used to some rides before we go there
[13:14] <cmaloney> Hey, nothing wrong with being afraid of falling. That's just good thinking
[13:15] <rick_h> shakes808: heh, I was carried onto my first roller coaster around 12 I think? So trying to help him not be like his old man
[13:15] <cmaloney> rick_h: Space Mountain is scarier than it seems
[13:15] <rick_h> hah
[13:15] <cmaloney> it's not that steep, but it gives you the illusion that it's worse than it is
[13:15] <rick_h> he's 50" so he can go on about half the stuff at cedar point so it was good.
[13:16] <shakes808> rick_h: HAHA.  I went on the X-Flight at some smaller venue because my grandfather was going on it and called me a puss for not going on it.  I think i was 13ish.
[13:16] <cmaloney> Yeah, I liked the spinning rides much better
[13:16] <shakes808> cmaloney: where's the adventure?!
[13:16] <cmaloney> shakes808: Terra Firma, Earth
[13:16] <rick_h> cmaloney: yea, I think his favorite was the scrambler where he got to squish mom
[13:17] <cmaloney> heh
[13:17] <rick_h> shakes808: well, of course after getting carried on I decided coasters were ok, but upside down was a no go
[13:17] <rick_h> shakes808: then in high school went with friends and the old peer pressure did me in and now I'll go on anything
[13:17] <cmaloney> My first coaster was the corkscrew-coaster at Bob-Li
[13:17] <cmaloney> Bob-lo
[13:17] <cmaloney> (whatever it's called)
[13:18] <cmaloney> Then I graduated to the *Streak coaster at BobLo
[13:18] <cmaloney> (Mean Streak?)
[13:18] <cmaloney> the one with the lap belt that makes it scarier than any coaster at Cedar point
[13:18] <cmaloney> as your butt leaves the seat
[13:19] <shakes808> just being at BobLo was scary.  haha
[13:19] <cmaloney> Nah, bobLo was awesome
[13:20] <cmaloney> even if it was trending toward shithole
[13:21] <shakes808> when i went there it was at its' end of life
[13:21] <shakes808> i heard they reopened it though and kicked all the bums off the island haha
[13:21] <shakes808> i want to go back.  supposedly has a nice aquarium
[13:22] <cmaloney> There's foks living on the island
[13:22] <cmaloney> I think you're thinking of Belle Isle though
[13:22] <cmaloney> iirc BobLo is now all private land
[13:24] <shakes808> hmmm maybe
[13:25] <shakes808> very well could be :)
[17:27] <shakes808> http://www.bestbuy.com/site/msi-vr-one-backpack-desktop-intel-core-i7-7820hk-16gb-memory-nvidia-geforce-gtx-1070-512gb-solid-state-drive-black/5853622.p?skuId=5853622
[17:27] <shakes808> :)
[18:08] <cmaloney> shakes808: So when you lose your balance playing your VR game you can take out over $3K of computer equipment as well?
[18:08] <cmaloney> Bargain
[18:12] <shakes808> cmaloney: HAHA, right!!!!
[18:33] <shakes808> something non-tech related: https://www.highstreettv.com/squat-magic.html
[18:33] <shakes808> Shake Weight move over :)


[14:11] <stokachu> anyone ever run into https://bugs.launchpad.net/juju-core/+bug/1380337?
[14:11] <mup> Bug #1380337: adding machine after destroying another fails <add-machine> <cloud-installer> <destroy-machine> <juju-core:New> <https://launchpad.net/bugs/1380337>
[17:08] <rogpeppe2> minor update to the juju errors package to use the new location for errgo: https://github.com/juju/errors/pull/8
[17:08] <rogpeppe2> reviews appreciated
[17:27] <TheMue> rogpeppe2: LGTM
[17:28] <rogpeppe2> TheMue: thanks!
[17:41] <TheMue> rogpeppe2: yw
[17:46] <rogpeppe2> anyone know anything about the bitbucket.org/kardianos/osext and bitbucket.org/kardianos/service dependencies?
[17:46] <rogpeppe2> they don't appear to be used by anything
[17:46] <jcw4> rogpeppe2: aren't they windows dependencies?
[17:46] <rogpeppe2> jcw4: possibly, but i haven't found anything that uses them
[17:47] <jcw4> rogpeppe2: I see... it's only in cmd/jujud/main_windows.go that it's even imported
[17:47] <jcw4> osext is a dependency of service
[17:48] <rogpeppe2> jcw4: ah, thanks
[17:48] <rogpeppe2> jcw4: i don't know why i didn't find that
[17:48] <jcw4> rogpeppe2: I just remember the second level dependency issue when I bumped into the same question recently
[17:49] <rogpeppe2> jcw4: it's a pity that the dependencies aren't findable by godeps. i should fix that.
[17:49] <jcw4> yeah. since it's only in the _windows.go files go needs a little prodding to find them I guess
[17:49] <jcw4> (when you're not on windows)
[17:50] <rogpeppe2> jcw4: yeah. godeps should try with different build flags.
[18:22] <bodie_> did someone ping me or is my IRC client highlighting this channel for no reason?  sigh
[20:44] <jcw4> rogpeppe2 I'm seeing this error in builds:
[20:44] <jcw4> Extant directories unknown:
[20:44] <jcw4>  gopkg.in/errgo.v1
[20:45] <jcw4> for example: http://juju-ci.vapour.ws:8080/job/github-merge-juju/914/console
[20:46] <jcw4> doesnt make sense to me because nothing in juju master refers to that yet, so it must be a transitive dependency
[20:50] <jcw4> Also, I can't find any transitive dependencies on that yet either.
[20:50] <jcw4> mgz: I think it's a build script issue... do you know why it's trying to pull in gopkg.in/errgo.v1 since that isn't in the dependencies.tsv, and doesn't seem to be a transitive dependency either
[20:52] <thumper> jcw4: is it from the juju/charms package?
[20:53] <rick_h_> jcw4: that was a branch that landed today
[20:53] <rick_h_> jcw4: make sure to update, I saw it go by in the email
[20:54] <jcw4> rick_h_: I am fully updated to juju master
[20:54] <jcw4> thumper: I'm trying to decipher what "it" is :)
[20:54] <rick_h_> jcw4: looking
[20:54] <jcw4> this error is when the build script is initially pulling down dependencies
[20:54]  * thumper sighs
[20:54] <thumper> found an intermittent test failure in worker/provisioner
[20:56] <jcw4> thumper: I've seen worker/provisioner fail a couple times intermittently, but I see worker/peergrouper fail fairly often locally
[20:56] <rick_h_> jcw4: https://github.com/juju/errors/pull/8 is the pr I was thinking of
[20:56]  * thumper sighs heavily
[20:56] <jcw4> rick_h_: yeah, that was why I pinged rogpeppe initially
[20:56]  * thumper is going to *fix* juju/errors
[20:57] <jcw4> YAY
[20:57] <jcw4> what baffles me is why the build script is even pulling it at all
[20:57] <jcw4> juju-core doesn't reference it yet
[20:57] <jcw4> and I couldn't find any dependencies of juju-core that referenced it either
[20:58] <rick_h_> like thumper said, probably juju/charm
[20:58] <thumper> I was told that errgo wasn't going to sneak into dependent packages
[20:58] <jcw4> thumper, rick_h_ I don't see how it could have
[20:58] <thumper> and it was only going to be used outside of juju/errors in the charmstore
[20:59] <rick_h_> thumper: jcw4 ok, justcccc ccbgjgvcveghhillduiklnblheujreenhtsnkubdrcjf
[20:59] <rick_h_> bah gueccccsccbgjgvscuneviintrdikfgbvegt
[20:59] <rick_h_> idhvdfvudkdkjb
[20:59] <rick_h_> double bah
[20:59] <thumper> wat?
[20:59] <rick_h_> called rick sitting in the hotel bumping his yubikey
[20:59] <thumper> rick_h_: you ok?
[20:59] <jcw4> haha
[20:59] <rick_h_> no, I'm still in brussels :P
[20:59] <thumper> rick_h_: you lucky fella
[21:00] <jcw4> rick_h_: did you go see the Atomium?
[21:00] <thumper> rick_h_: I was looking at the schedule for the first few days
[21:00] <thumper> $ git diff master | wc -l
[21:00] <thumper> 1731
[21:00] <thumper> hmm
[21:00] <thumper> this branch isn't going to break up well
[21:01] <urulama> thumper: errgo should stay within charmstore limits, yes.
[21:01]  * thumper puts hacking hat back on and ignores all y'all for a while
[21:03] <thumper> ah crap...
[21:04] <thumper> new struct from a merge has broken my work...
[21:04]  * thumper works around it
[21:04] <rick_h_> chase them down and make them eat pie
[21:05] <jcw4> wait, before committing to that course of action... which struct?
[21:05] <jcw4> rick_h_: isn't it LATE in Brussels?
[21:05] <jcw4> 11pm or so?
[21:06] <rick_h_> jcw4: yes
[21:06] <thumper> jcw4: not you
[21:06]  * jcw4 wonders if the initial pull for imports uses the HEAD revision of juju/errors to find child imports
[21:07] <urulama> thumper: btw, let me know if errgo somehow sneaks into the code ...
[21:07] <jcw4> thumper: whew
[21:07] <thumper> jcw4: was cmars's branch for login v2
[21:07] <thumper> urulama: ack
[21:07] <thumper> urulama: you home?
[21:07] <urulama> thumper: was having fun trying to QA all the "landed" branches from last week ... could have missed some though
[21:07] <urulama> thumper: i am
[21:08] <urulama> thumper: my flight was about 1h 20min ;)
[21:08] <thumper> urulama: I have a branch for juju/errors that needs updating based on our conversations in nuremberg
[21:08] <thumper> urulama: I got home yesterday just before lunch
[21:08] <thumper> urulama: working today/tomorrow taking thu/fri off in lieu
[21:08] <thumper> but today is finishing off what I started pre-sprint
[21:09] <urulama> thumper: enjoy :)
[21:09] <thumper> \o/
[21:09] <urulama> thumper: seen that errors branch, looks nice
[21:10] <thumper> I'll see if I can get to it tomorrow
[21:10] <thumper> or may this afternoon if I can fix all the test failures I caused
[21:10] <thumper> by changing a bucketload of API calls
[21:10] <urulama> that's always a good thing! :D
[21:10]  * thumper is full steam ahead on finishing identity bits
[21:11] <thumper> OOPS: 268 passed, 6 FAILED, 5 PANICKED
[21:11] <thumper> need to fix the failed and panicked
[21:11] <jcw4> yikes
[21:11] <thumper> :)
[21:11] <jcw4> :)
[21:11] <jcw4> where is the code that actually runs the CI build?  I dont' think its the jenkins-github-lander repo
[21:11] <urulama> don't panic
[21:12] <thumper> urulama: thanks for that :)
[21:12] <thumper> jcw4: not entirely sure sorry
[21:12] <jcw4> thanks thumper you can ignore me while you're dealing with your panic attacks
[21:12] <jcw4> :)
[21:13] <thumper> cheers buddy
[21:13]  * thumper goes back to it
[21:13] <jcw4> I bet its https://launchpad.net/juju-ci-tools
[21:17] <mgz> jcw4: rog borked it
[21:17] <jcw4> mgz: yay :)
[21:18] <mgz> with this change: https://github.com/juju/errors/pull/8
[21:18] <jcw4> mgz: it seems like the build script might be getting imports from the HEAD revisions of first level imports?
[21:19] <jcw4> mgz: right, but that's just on the errors repo, and juju-core wasn't updated to use that revision in the dependencies.tsv
[21:19] <mgz> yeah, something's up
[21:19] <mgz> godeps likely doesn't do exactly the right thing
[21:20] <jcw4> mgz: yeah, interesting
[21:21] <mgz> I'll have a poke around
[21:23] <thumper> mgz: just revert the merge for now
[21:23] <thumper> mgz: poke around later
[21:23] <mgz> jcw4: the repo is just getting lp:juju-release-tools and running `./make-release-tarball.bash master`
[21:24] <thumper> mgz: this is how we deal with broken builds
[21:24] <thumper> dvcs FTW
[21:24] <mgz> thumper: fair enough
[21:24] <jcw4> thumper: thanks!
[21:24] <jcw4> mgz: thanks!
[21:28] <jcw4> mgz: I see the problem I think
[21:28] <jcw4> compare_dependencies in check_dependencies.py doesn't seem to like any packages that are not accounted for in the dependencies.tsv file
[21:29] <jcw4> I bet godeps is just pulling down second level imports before updating first level imports to the specified revision
[21:30] <jcw4> which would bring gopkg.in/errgo.v1 into the pristine GOPATH, and then compare_dependencies complains
[21:58] <jcw4> mgz: thumper, rogpeppe2 -- I reverted https://github.com/juju/errors/pull/8 so that juju-core will build again.
[21:58] <jcw4> rogpeppe2: sorry! Hopefully we can figure out the build process so that we can land your change again
[21:58] <thumper> jcw4: kk


[20:24] <jose> working on membership board announcement for fridge
[22:25] <tsimonq2> jose: gracias
[22:37] <jose> np


[00:04] <apachelogger> rbelem: sort of pong
[00:05] <rbelem> apachelogger, :-D
[00:05] <rbelem> apachelogger, how was you flight?
[00:05] <apachelogger> Quintasan_: before core-dev you should touch more packages than kubuntu ones :P
[00:06] <apachelogger> also you should get brushed up on all the techy wacky stuff, the interview is quite horrible
[00:06] <apachelogger> rbelem: short and pointless
[00:16] <nigelb> DS over?
[00:16] <rbelem> apachelogger, :-)
[00:16] <apachelogger> nigelb: no
[00:16]  * apachelogger is still not quite sure he should go to the kde e.v. general assembly
[00:19] <rbelem> apachelogger, do you had chance to take a look on those branches?
[00:19] <apachelogger> nope
[00:19] <apachelogger> didnt read mails for like 3 days
[00:41] <rbelem> apachelogger, np ;-)
[00:41] <apachelogger> rbelem: did you see dragon player 3?
[00:47] <rbelem> apachelogger, yup :-D
[00:47] <rbelem> apachelogger, awesome
[01:02] <apachelogger> groovy :D
[08:48] <debfx> yofel: we can't install org.freedesktop.MediaPlayer*.xml because there are other players which implement the MPRIS stadard as well
[09:31] <felimwhiteley> hi folks
[09:32]  * felimwhiteley been suffering serious issue since 4.7 upgrade
[09:33] <felimwhiteley> not sure if there is any major known issues with akonadi?   There is an open ntrack bug where libntrack will sometimes cause a process to take 100% CPU and you have to kill the process.
[12:18] <Quintasan> yofel: You gotta explain this NM mess to me later when I get back home
[12:18] <ScottK> Maybe it's related to that.
[12:19] <yofel> Quintasan: rather easiy, kde-workspace ships solid for NM 0.8. We have 0.9 in oneiric so the solid stuff doesn't build but the plasma widget ships it's own solid lib instead.
[12:19] <Quintasan> ScottK: Do you recall your Droid's battery capacity?
[12:20] <ScottK> Quintasan: "Not very much"
[12:21] <Quintasan> That's quite descriptive. And I though it's only me who gets battery made out of wood
[12:21] <felimwhiteley> ScottK: no it's the 4 or 5 akonadi_[contact...etc] processes that each hog 25-40%
[12:21] <Quintasan> yofel: so backporting workspace to natty shouldnt pose any problems, should it?
[12:22] <Quintasan> felimwhiteley: IIRC akonadi uses ntrack
[12:22] <felimwhiteley> maybe I really do have corruption.. is there an akondi check.. I struggle finding info on it
[12:22] <ScottK> felimwhiteley: No idea then.
[12:22]  * felimwhiteley is a bit clueless with akonadi tbh
[12:22]  * Quintasan pats felimwhiteley
[12:22] <ScottK> Join the club.
[12:22] <Quintasan> You are not the only one ;)
[12:22] <yofel> Quintasan: well, the solid stuff doesn't build in O, but does in N and natty plasma widget DOESN'T ship it's own solid lib
[12:23] <felimwhiteley> lol
[12:23] <yofel> os if you do a straigth backport without fixing install files you have no NM solid backend
[12:23] <yofel> s/os/so/
[12:23] <kubotu> yofel meant: "so if you do a straigth backport without fixing install files you have no NM solid backend"
[12:23] <ScottK> Quintasan: My droid is a year and a half old and the not so great battery capacity that I started with is not what it once was.
[12:23] <Quintasan> derp
[12:24] <ScottK> And if you don't have a solid back end it's hard to sit properly.
[12:24] <Quintasan> yofel: so that's how I broke nm in ~ppa5 upload?
[12:24] <yofel> yep
[12:24] <Quintasan> grr
[12:25]  * yofel is starting to get a headache from looking at digikam linking errors...
[12:27] <ScottK> yofel: Don't panic about digikam.  If it's not ready by Thursday, I'll give an FFe for it as long as it's soon.  I'd rather have it right than now (fsvo right and now).
[12:27] <yofel> sure, I probably won't finish this in time, seems like it'll need a MIR for openvc too unless I try to rip libkface out
[12:28] <yofel> oh, and kipi-plugins is inside digikam too as additional crazyness
[12:36] <ScottK> Sigh.
[12:36] <dslogger> yofel: did ye push a nu amarok yet?
[12:36] <yofel> dslogger: amarok is in backports
[12:36] <dslogger> swell
[12:36] <dslogger> yofel++
[12:37] <dslogger> ScottK: yofel is jolly useful I might say
[12:37] <yofel> ^^
[12:37] <ScottK> dslogger: Definitely.
[12:37] <Quintasan> Gah, Back.
[12:37] <ScottK> In case there was confusion the sigh was at digikam upstream, not yofel.
[12:38] <Quintasan> It's damn hot outside and it's raining at the same time
[12:38]  * yofel is pretty happy
[12:38] <yofel> we finally got a wired connection here :D
[12:38] <Quintasan> ...
[12:39] <Quintasan> and back to cleaning the house :S
[12:39] <Quintasan> bbl
[12:39] <ScottK> yofel: Since digikam didn't conveniently release a new kipi-plugins you might mail them and ask if we are expected to ship the embedded one as our new system kipi-plugins.  Be forwarned they don't seem very distro friendly.
[12:39] <yofel> ScottK: will do
[12:40] <ScottK> Good luck.
[12:40] <nigelb> r'
[13:00] <yofel> grrrr, I don't get this
[13:00] <yofel> /usr/bin/ld: /usr/lib/libgphoto2.so: undefined reference to symbol 'gp_port_free'
[13:00] <yofel> /usr/bin/ld: note: 'gp_port_free' is defined in DSO /usr/lib/libgphoto2_port.so so try adding it to the linker command line
[13:00] <yofel> /usr/lib/libgphoto2_port.so: could not read symbols: Invalid operation
[13:00] <yofel> it links with:
[13:00] <yofel> -L/usr/lib -lgphoto2_port -L/usr/lib -lgphoto2 -lgphoto2_port
[13:00] <yofel> o.O?
[13:16] <ScottK> Might be an ordering issue.
[14:13] <yofel> bah, someone else that icecc 0.9.7-1 still errors out on liblto_plugin.so?
[14:14] <yofel> s/?/for?/
[15:51] <cyphermox> ScottK: to get back to ntrack/kde-runtime; I've uploaded both to https://launchpad.net/~mathieu-tl/+archive/kubuntu-dev ; will be done publishing any time now
[15:51] <ScottK> Anyone on Oneiric can test ^^^?
[15:52] <ScottK> (my oneiric box has no networking at the moment due to an install failure for Alpha 3)
[15:52] <cyphermox> I'll be installing a kubuntu box with the daily image shortly, but I'll need pointers to know exactly what to test
[15:53] <ScottK> If it fails badly and you're on a network, you'll know...
[16:01] <cyphermox> guess so, I was expecting that it would be a little bit more subtle
[16:27] <ScottK> It might.
[16:28] <ScottK> the current issue I'm seeing is Natty is a once per few  days some newtwork using process will take 100% CPU and not give it back.
[16:28] <dslogger> yofel: ping
[16:28] <dslogger> yofel: you make a tomahawk package
[16:28] <dslogger> like right now
[16:29] <dslogger> or muesli will give yer a beatin
[16:29] <dslogger> find him in #tomahawk
[16:29] <yofel> huh?
[16:29] <yofel> well, I can take a look at it...
[16:34] <CIA-52> [kde-workspace] Philip Muškovac * 543 * debian/ (changelog patches/kubuntu_03_kdewallpapers_install.diff) make the default wallpapers install button install kde-wallpapers as well
[16:36] <ScottK> yofel: Make sure you're working with an up to date workspace.  I uploaded it last night.
[16:36] <yofel> I used ubuntu4 as base, this needs a review anyway
[16:37] <yofel> https://code.launchpad.net/~yofel/kubuntu-packaging/kde-workspace_install-workspace-wallpapers-too/+merge/70924 someone look at it please. So far IT BUILDS™
[16:37] <yofel> since qapt-batch crashes in oneiric I can't really test it
[17:39] <CIA-52> [kde-workspace] Philip Muškovac * 544 * debian/patches/kubuntu_03_kdewallpapers_install.diff Fix cout syntax
[17:42] <yofel> debfx: fixed, thanks
[18:04] <dslogger> Blizzz: pingggggggg
[18:04] <dslogger> pinnngggggg
[18:05] <dslogger> yofel: are you not islanding?
[18:14] <yofel> Dslogger: i just arrived
[18:14] <dslogger> yofel: we are not attending
[18:14] <dslogger> its like 50 minutes away from our apartment
[18:14] <yofel> take the s-bahn ?
[18:16] <yofel> Well, + bus
[18:38] <dslogger> yofel: still 50 minutes
[21:28] <bambee> evening
[21:28] <ScottK> bambee: Back ashore?
[21:33] <bambee> ScottK: yeah until tomorrow :)
[21:33] <ScottK> bambee: OK.  How's it going?
[21:36] <bambee> ScottK: really fine, except I got seasick today lol
[21:37] <ScottK> Make sure you get good drugs for tomorrow then.
[21:37] <bambee> ScottK: no drugs needed, just sleep and water for me (I sleep a lot when I am sick :P)
[21:38] <ScottK> Right, but as a preventative.
[21:38] <bambee> the weather is better tomorrow, today it was bad... the sea was very agitated
[21:39] <bambee> ScottK: I've drugs if I'm really sick :)
[21:40] <ScottK> IME prevention works way better than the cure for sea sickness.
[21:40] <bambee> right
[22:17] <Quintasan_> Y U NO DETECT ME SECOND SCRREN