[00:44] <qengho> Zaoshanghao, good morning, everyone.
[04:40] <hikiko> Hi
[04:44] <qengho> hikiko: hi ki ko
[05:40] <hikiko> hi qengho
[05:50] <pitti> Good mornning
[06:00] <hikiko> good morning pitti
[07:32] <Trevinho> Morning
[08:01] <willcooke> hey Trevinho
[08:19] <andyrock> morning all
[08:24] <seb128> hey andyrock, how are you?
[08:24] <andyrock> hey seb128 trying to finish the branch of the copy dialog by the end of the day :D
[08:24] <andyrock> you?
[08:26] <seb128> I'm good thanks
[08:39] <hikiko> Trevinho, since I accidentally fixed compiz's show desktop too I did an MP here: https://code.launchpad.net/~hikiko/compiz/compiz.shodesktop-skip-anim-option/+merge/299276 maybe people who use compiz on mate or other DEs want to skip the fade in showdesktop :)
[08:48] <willcooke> seb128, I'm trying to rebuild u-c-c, but I don't want to make a whole .deb package, just a binary so I can test a patch.
[08:49] <willcooke> when I run autogen and then make it's looking in /usr/local/share/foo for the ui instead of /usr/share/foo
[08:49] <seb128> right
[08:49] <willcooke> I had a look at the rules file, but I can't work out how to tweak that at build time
[08:49] <seb128> --prefix=/usr
[08:49] <willcooke> hm, I tried that and it didnt work
[08:49] <seb128> ?
[08:49] <willcooke> seb128, do that with ./configure --prefix=/usr right?
[08:50] <seb128> correct
[08:50] <willcooke> I'll try again
[08:52] <Trevinho> seb128: hey
[08:52] <Trevinho> seb128: can you publish this too https://requests.ci-train.ubuntu.com/#/ticket/1614 ?
[08:53]  * Trevinho fixes the bugs in the mean time
[08:53] <Trevinho> hikiko: ok thanks.
[08:54] <seb128> Trevinho, you ignored my comment about the upstart job and g-s-d, let's see if the SRU team blocks the SRU due to it
[08:54] <Trevinho> seb128: I didn't ignore...
[08:55] <seb128> well I said that it needs to go or to be documented in the changelog
[08:55] <Trevinho> seb128: I really hope not... They're generally good people :-P
[08:55] <seb128> it's still there and still undocumented
[08:55] <seb128> well, if they do their work they should
[08:55] <seb128> their job is to catch undocumented changes
[08:55] <seb128> because those have no business being in a SRU
[08:55] <seb128> they are more often than not errors
[08:56] <seb128> they can't mind read that you wanted to remove that alternative and why
[08:56] <seb128> and you didn't asset the potential impact
[08:56] <seb128> anyway pressing the button, let's see
[08:56] <willcooke> seb128, grr - make clean
[08:56] <willcooke> :)
[08:56] <seb128> willcooke, ;-)
[08:57] <seb128> willcooke, working now?
[08:57] <willcooke> better
[08:57] <willcooke> but
[08:57] <willcooke> Failed to look up menu_file for "/usr/etc/xdg/menus/unitycc.menu"
[08:57] <seb128> lol
[08:57] <Trevinho> seb128: triggering a rebuild because of that .... Mh, ok
[08:57] <Trevinho> seb128: I'll add itt
[08:57] <seb128> Trevinho, I published
[08:58] <seb128> so too late for this round
[08:58] <Trevinho> seb128: ah ok.
[08:58] <seb128> sorry, you didn't seem open to do the change
[08:58] <seb128> let's see what SRU team says
[08:58] <seb128> willcooke, --sysconfdir=/etc
[08:58] <seb128> willcooke, unsure why you don't simply build the package which use all the right flags/options
[08:58] <seb128> easier than building 10 times and poking for what to do manually
[08:59] <willcooke> but then I have to do the install / remove dance
[08:59] <seb128> ?
[08:59] <willcooke> I have to install the .deb right?
[08:59] <willcooke> oh
[08:59] <seb128> why would you?
[08:59] <willcooke> maybe I dont
[08:59] <willcooke> because the binaries will still be there right?
[08:59] <seb128> to build the deb it does a source build
[08:59] <seb128> yes
[09:00] <seb128> also you can ctrl-C before the end of the build
[09:00] <seb128> just let it do the configure for you
[09:00] <seb128> then ctrl-C and do make
[09:00] <seb128> at least you get all the flags set up for you
[09:00] <willcooke> ah, interesting
[09:00] <willcooke> oki, I'll read up on that.  It's been a long while.  I remember something about fakeroot and that's abou tit
[09:00] <willcooke> about it
[09:02] <seb128> sudo apt-get install debscripts
[09:02] <seb128> sudo apt-get build-dep unity-control-center
[09:02] <seb128> sorry
[09:02] <seb128> sudo apt-get install devscripts
[09:02] <seb128> was a typo
[09:03] <seb128> if you use the vcs you can install bzr-buildpackage and bzr bd
[09:03] <seb128> if you get the source just use "debuild"
[09:03] <seb128> in the srcdir
[09:03] <willcooke> woo! thanks seb128
[09:04] <seb128> yw
[09:04] <seb128> works now?
[09:04] <willcooke> building
[09:04] <willcooke> if this doesnt work though, I give up :)
[09:04] <willcooke> I tried just commenting out the xml, but that didnt work
[09:05] <willcooke> needs a change in corresponding panel code too
[09:05] <willcooke> which I think is just a couple of lines commented out
[09:06] <willcooke> line 1010 in cc-power-panel.c
[09:06] <willcooke> and 1011
[09:11] <willcooke> booo
[09:11] <willcooke> but at least it built ok :)
[09:13] <seb128> willcooke, it doesn't load the panel .so from the local build
[09:13] <willcooke> ahhhhh
[09:13] <seb128> you need to copy panel/power/.libs/libpower.so over the system one
[09:14] <seb128> dpkg -S libpower.so
[09:14] <willcooke> hidden directories, of course :)
[09:16] <flexiondotorg> willcooke, I've rounded up all the duplicates for LP: #1585863
[09:17] <flexiondotorg> And have seen this LP: #1589557
[09:17] <flexiondotorg> It that SRU intended as the actual solution?
[09:22] <popey> willcooke: maybe worth keeping an eye on https://bugzilla.gnome.org/show_bug.cgi?id=764841 - GNOME Maps uses a tile provider which is changing T&C, so we may get an update from them which changes to a different tile set
[09:22] <popey> because AIUI (I think) GNOME Maps will break on Monday.
[09:26] <willcooke> flexiondotorg, I think that wifi/resume issue was fixed in upstream 1.2.2, so SRUing the new version is the intended fix.  But happyaron should comment further
[09:26] <willcooke> popey, thanks.  We get gnome-maps from Debian, so we might need to resync
[09:26] <flexiondotorg> willcooke, Thanks.
[09:27] <willcooke> flexiondotorg, did I understand the question correctly?
[09:27] <flexiondotorg> Yep :-)
[09:27] <willcooke> \o/
[09:27] <flexiondotorg> There is so much mis-information flying around about the Network Manager issues in "the community".
[09:28] <flexiondotorg> I'm just trying to get a handle on the main issues and the road to solutions.
[09:28] <flexiondotorg> Basically, trying to quite down the peanut gallery.
[09:28] <willcooke> thank you flexiondotorg
[09:28] <flexiondotorg> s/quite/quiet/
[10:05] <willcooke> seb128, sucess - of sorts
[10:05] <willcooke> now meeting, then try again
[10:05] <willcooke> and make it a bit tidier
[10:15] <seb128> willcooke, working but not really as you wanted??
[10:17] <willcooke> seb128, working, but I might have found an easier way
[10:17] <seb128> k, good
[10:18] <seb128> popey, gnome-maps is a direct sync from debian and in universe/not something we maintain, any reason it should be a concern for us?
[10:19] <popey> Only that AIUI it will break on monday. So expect bug reports in launchpad if they haven't already been reported
[10:19] <seb128> k
[10:19] <seb128> well, we are not subscribed to that component
[10:20] <seb128> so I guess it can go to the launchpad spam box :p
[10:20] <seb128> but thanks for pointing it out
[10:20] <seb128> also it's likely that Debian fixes it and than we get a direct sync
[10:20] <popey> wouldn't that need an SRU?
[10:20] <seb128> if that has users who care on stable series I guess
[10:21] <seb128> unsure how used that app is
[10:21] <seb128> I never tried it nor saw it mentioned on this channel before today
[11:26] <Trevinho> seb128: I don't see anything changed on that silo, is publication pending or what?
[11:26] <Trevinho> seb128: ah.
[11:26] <Trevinho>  Publish failed: bamf has merges in bad states.
[11:26] <Trevinho> libunity has merges in bad states.
[11:26] <Trevinho> unity has merges in bad states.
[11:26] <Trevinho> unity-lens-applications has merges in bad states
[11:27] <seb128> I pressed the button
[11:27] <seb128> didn't check the logs
[11:27] <seb128> so it failed? what is bad state?
[11:27] <Trevinho> seb128: yeah, not approved :)
[11:28] <Trevinho> seb128: andyrock is on them, once he ACK'ed I ping you again
[11:28] <seb128> k
[11:29] <seb128> you can maybe fix the upstart job, or at least the commit msg ;-)
[11:31] <andyrock> seb128 Trevinho done
[11:32] <seb128> thanks
[11:33] <pitti> does anyone know how we start a Mir session exactly? I. e. the parts between lightdm and running the session leader?
[11:33] <pitti> I suppose we don't have any Xsession.d equivalent there
[11:34] <Trevinho> pitti: mh, you want the clean way then?
[11:34] <pitti> is that just calling the equivalent of /usr/share/xsessions/my_DE.desktop?
[11:34] <pitti> which then starts the session leader, and as  soon as that stops teh session is gone?
[11:34] <pitti> Trevinho: just interested in how it works today, and how it's meant to work (they might not necessarily be the same, yes: :) )
[11:34] <Trevinho> pitti: AFAIK using unity-system-compositor you need to pass to it the FDs of lightdm for securty purposes
[11:35] <Trevinho> So you launch that trhough lightdm, but I'm not that aware of the internals
[11:35] <seb128> pitti, you would need robert_ancell for somebody who masters the details
[11:35] <Trevinho> Saviq knows that better for sure ^
[11:35] <seb128> or maybe mterry
[11:35] <pitti> so apparently if gdm wants to start a wayland session, the only thing it does is to run the corresponding .desktop from /usr/share/wayland-sessions/
[11:35] <Trevinho> yeah, these too
[11:36] <pitti> Trevinho: not interested in the details, just how a "session" is defined from the POV of the DM
[11:36] <pitti> for X it's currently "run the Exec= from the session .desktop through Xsession.d/" (or very similar)
[11:37] <Trevinho> pitti: looking at unity8-desktop-session should help you
[11:37] <Trevinho> we've /usr/share/lightdm/sessions/unity8.desktop
[11:37] <Trevinho> with X-LightDM-Session-Type=mir and Exec=lightdm-unity8-session
[11:38] <pitti> ah, so lightdm-unity8-session is the "session leader" shell script
[11:38] <Trevinho> where lightdm-unity8-session is just a script that calls lightdm-session with some qt/mir related enviromnet var sets
[11:38] <Trevinho> yes
[11:38] <Saviq> pitti, yeah and lightdm has dedicated code paths for mir to make sure it sets up unity-system-compositor
[11:38] <pitti> so lightdm doesn't really need to know about Mir, the only interface is the unity8.desktop, and no Xsession.d/
[11:39] <pitti> I'm glad the Xsession.d/ shell script madness is gone :)
[11:39] <pitti> thanks Saviq and Trevinho!
[11:39] <Trevinho> yeah, I think upstart/systemd usage is the future for that
[11:39] <pitti> that's what I'm currently discussing with upstream, yes
[11:40] <pitti> cleaning up my initial prototype
[11:40] <pitti> and I was wondering what to replace the Xsession.d wrapper with
[11:40] <pitti> I think we mostly just want to put that into the .desktop Exec= instead
[11:40] <Trevinho> I guess just having a trigger for events, then it's up to scripts..
[11:40] <Trevinho> yeah
[12:07] <willcooke> Laney, seb128 - any chance of a review and merge of this this week? https://bugs.launchpad.net/ubuntu/+source/ubuntu-themes/+bug/1594816
[12:08] <seb128> willcooke, let's see if Laney replies, I can have a look tomorrow otherwise
[12:08] <seb128> it's simple enough that I can probably approve it if needed
[12:08] <willcooke> thanks seb128.  I guess this is tricky because it won't go in to 16.10 because of Gtk versions
[12:08] <seb128> but by css foo is weak, Laney probably has a much better understanding of the theme by now
[12:08] <seb128> well, Gtk isn't update
[12:08] <seb128> so we can land it now
[12:08] <willcooke> ah
[12:08] <seb128> even if it gets changed later
[12:08] <seb128> *updated
[12:09] <willcooke> seb128, also I did only need to change the power.ui file to get rid of the "when power is critically low" issue:  https://bugs.launchpad.net/ubuntu/+source/unity-control-center/+bug/1599264
[12:10] <seb128> willcooke, do you want that in the .1?
[12:10] <willcooke> seb128, hmmmmmmm
[12:10] <seb128> willcooke, Trevinho is having a u-c-c update with the compiz lowgfx changeset
[12:10] <seb128> so we need to merge them/respin
[12:10] <willcooke> Yeah, I think so, but it's a UI change - so might need special exceptions?
[12:11] <seb128> if you want it included
[12:11] <willcooke> seb128, I'd be +1, what do you think?
[12:11] <seb128> yeah, good point
[12:11] <seb128> well if the settings is not working should be fine for a SRU
[12:11] <seb128> but we should talk to the documentation team
[12:11] <willcooke> I'll ask for a UI freeze exception anyway
[12:11] <seb128> is that setting documented there?
[12:12] <seb128> k
[12:14] <willcooke> asked in #ubuntu-doc
[12:16] <seb128> k, let me know if you get a reply
[12:16] <willcooke> seb128, would you mind testing that real quick?
[12:17] <seb128> the .ui change?
[12:17] <willcooke> yeah, just apply the patch and see if it's gone
[12:17] <seb128> can do
[12:17] <seb128> did you see the upstream commit I pointed yesterday evening when we discussed it?
[12:17] <seb128> they removed a bit of backend code which isn't needed without the ui as well
[12:18] <seb128> we might want to do the same
[12:18] <willcooke> ah, no, I missed that
[12:18] <willcooke> lemme see
[12:18] <seb128> I think I pointed one?
[12:18]  * seb128 looks at log
[12:19] <seb128> oh, I pointed to the bugzilla bug
[12:19] <seb128> same
[12:19] <willcooke> yeah
[12:20] <willcooke> so I could remove the same bits and add another patch, is that OK?
[12:21] <willcooke> or should we sync from u/s
[12:28] <willcooke> hrm, this one is waaay different to anything we have: https://bugzilla.gnome.org/attachment.cgi?id=303524&action=diff
[12:30] <willcooke> hrm, seb128 I'm out of my depth patching cc-power-panel.c
[12:32] <ricotz> hey desktopers
[12:32] <ricotz> willcooke, hi, do you mind a pm?
[12:34] <seb128> willcooke, I guess it's just a matter of removing the callback for the UI bit ... where is your .ui change?
[12:39] <willcooke> ricotz, sure
[12:42] <willcooke> seb128, https://launchpadlibrarian.net/271261080/powerui.patch
[12:42] <willcooke> is that what you meant?
[12:42] <willcooke> I think I've found the bit in cc-power-panel.c
[12:46] <seb128> willcooke, the .ui change looks fine ... k, let me know if you need help with the .c
[12:48] <willcooke> seb128, looks like we're a little way behind with out fork, but I think I got it now
[12:48] <seb128> yeah, we are way behind
[12:48] <seb128> which was sort of why we forked, they redesign the UI and we didn't want the new look
[12:48] <willcooke> doesnt matter too much though I think, as long as it works, it's not something we need to keep on the cutting edge with
[12:49] <willcooke> ahh
[12:49] <willcooke> I see
[13:10] <desrt> good morning people
[13:10] <seb128> hey desrt, wb!
[13:11] <seb128> how are you?
[13:11] <seb128> how was Canada day?
[13:12] <desrt> i'm not sure
[13:12] <desrt> probably pretty good, though :)
[13:12] <seb128> that was not monday?
[13:12]  * seb128 is unsure
[13:12] <desrt> no.  friday was the holiday
[13:13] <desrt> which, indeed, is odd
[13:13] <desrt> normally they make it on monday, but i guess because it was natively on friday, which already made it a 3-day weekend, they just left it there
[13:13] <seb128> ah ok
[13:14] <desrt> that entire long weekend was the pride parades, anyway
[13:14] <desrt> which i mostly stayed home for
[13:14]  * desrt hasn't been feeling 100% lately
[13:14] <seb128> k
[13:15] <seb128> oh :-/ hope you are going to feel better soon!
[13:15] <desrt> i should be.  i think the problem has been identified :)
[13:15] <seb128> good :-)
[14:34] <willcooke> seb128, I'm down a rabbit hole now with u-c-c :( - I think I do need to build and install a .deb because I'm trying to copy libs around to test and getting it very wrong
[14:35] <willcooke> once I do a debuild - what's the next step to get a .deb I can install?
[14:35] <seb128> what lib? how wrong?
[14:35] <seb128> debuild procudes a deb
[14:40] <didrocks> (if the build succeed :p)
[14:40] <willcooke> seb128, @ libs - I think I need to copy new ones in to the right place after I made changes to the power panel C code
[14:41] <willcooke> seb128, and wrong - like I might have deleted the proper ones and replaced them with garbage
[14:41] <willcooke> :)
[14:41] <seb128> lol
[14:41] <seb128> willcooke, well, the panel is libpower.so
[14:42] <willcooke> I was getting warnings from libunity-control-center.so.1.0.0
[14:42] <willcooke> so I tried to copy that over as well
[14:42] <seb128> and now?
[14:42] <seb128> you get an error?
[14:42] <willcooke> well, I'm getting some warnings which I think are related to the changes
[14:42] <willcooke> it's not building a deb because:
[14:43] <willcooke> oh, it's trying to sign it as you
[14:45] <seb128> that's not an error
[14:45] <seb128> it should still produce the deb
[14:45] <seb128> in the maindir, like outside the srcdir
[14:45] <seb128> or in build-area/
[14:45] <willcooke> ohhhhhhhh
[14:45] <willcooke> thanks
[14:45] <seb128> yw
[14:58] <willcooke> wooo
[14:59] <willcooke> warnings gone
[14:59] <seb128> woot
[15:06] <flocculant> willcooke: or are they ...
[15:06] <flocculant> just thought I would throw that in there :p
[15:06] <willcooke> gee, thanks pal
[15:53] <Sweet5hark1> ricotz: thanks for your enthusiasm on updating https://git.launchpad.net/~libreoffice/ubuntu/+source/libreoffice/commit/?h=ubuntu-yakkety-5.2&id=97262150e06b39605a4a63b6921a4010371da6ad
[15:53] <Sweet5hark1> ricotz: a few things though:
[15:53] <Sweet5hark1> ricotz: a/ please dont push changes I wrote onto the branch. All changes I push to lp are already locally commited in git, so when you recreate those changes with a newly created commit, that just creates conflicts. Also, if I have pushed something to lp, but not to the git repo, there is a good chance that there either is a problem with the change or it wasnt tested yet. As such please assume it to be _intentionally_ not pushed yet --
[15:53] <Sweet5hark1> ricotz: b/ Also, if you push changes written by others, please use --author to properly mark them for git blame etc. If you do changes inspired by someone, but which are not verbatim their work, it might be better to just name/thank the author in the commit message.
[15:53] <Sweet5hark1> ricotz: I also noted you asked upstream about rc2. Thats good in general as upstream should stick to its schedule unless there are good reasons. However, please refrain from creating tarballs from upstream tags for Ubuntu unless I am very late with that (read: like half a week). If you create the tarballs, that is not helping, because it actually creates _more_ work for me to diff/check/verify those against some I independantly created
[15:57] <Sweet5hark1> ricotz: if you want to help with the upstream tarballs, as cloph said upstream: the best way is to get into reviewing the outstanding patches that still block the tag. Alternatively, if you want to help with the Ubuntu tarballs, recreating them and verifying that there is no diff to when I upload isnt corrupted (and thus has no diff beyond e.g. fetch.log) would help too.
[16:01] <Sweet5hark1> ricotz: but -- as said in the opening, your work is much welcome, but keep in mind that packaging LibreOffice is and should be a rather slow business: Its like navigating an oil tanker. --- If you prefer something moving faster, upstream _development_ (not releng) might be something for you, and I most happily would give you an intro on how to get started ;)
[16:04] <willcooke> seb128, pour vous?  https://code.launchpad.net/~willcooke/ubuntu-themes/gtkswitchoverflow/+merge/298028
[16:05] <ricotz> Sweet5hark1, hi, thanks for the flaming and not answering to my previous messages -- I noted your complaints, but slow as in weeks-later is not helping, and you not pushing your changes is not unusual, just rebase the branch as you wish
[16:06] <seb128> sorry can't read you, hate that bug
[16:06] <ricotz> Sweet5hark1, I simply asked for an eta for the new tag nothing more
[16:06] <seb128> http://people.canonical.com/~seb128/bug.png
[16:07] <seb128> I can see notifications with text though :p
[16:07] <seb128> need to reboot but I was testing something in a snap env and didn't want to close it
[16:11] <seb128> back
[16:11] <seb128> willcooke, +1
[16:15] <Sweet5hark1> ricotz: yes, In general I need to change my unhelpful custom of pushing only rarely now that I am not alone there. But that is not what is happened here: https://launchpad.net/~bjoern-michaelsen/+archive/ubuntu/libreoffice-staging/+sourcepub/6496156/+listing-archive-extra ftbfs, so I didnt commit/push before investigating that. So umm, taking changes from someone elses private ppa that apparently broke and pushing it to the branch with
[16:17] <ricotz> Sweet5hark1, the way I did it you can easily see what I changed and you can simply rebase to your local branch by skipping the squashed commit
[16:20] <seb128> going for some exercice, bbiab
[16:25] <jbicha> popey: Ubuntu GNOME 15.10 and 16.04 ships gnome-maps
[16:26] <popey> jbicha: i thought they might
[17:38] <ricotz> Sweet5hark1, why didn't you rebase it?
[17:40] <ricotz> Sweet5hark1, also a transitional package for libreoffice-gtk might be wise to ease updating
[17:43] <Sweet5hark1> ricotz: rebase your changes on top of mine? because that would then create a different branch and thus require a forced push, "changing history"/diverted history. One should _never_ force push to a public branch.
[17:45] <ricotz> Sweet5hark1, as you said there are like 2 people working on it, so just do it
[17:45] <ricotz> Sweet5hark1, rebasing public branch is done all the time or over the places
[17:46] <Sweet5hark1> ricotz: rebasing published branches might be done. however, its never done in sane places.
[17:47] <ricotz> Sweet5hark1, dont call this branch a sane place ;P
[17:48] <Sweet5hark1> ricotz: for the next time, a workable solution, if you urgently want to have something to be included in the packaging branches is that you push to a different named branch (e.g. "feature/$something"). It can then be easily cherry-picked/merged/whatever in the ubuntu-yakkety-5.2 branch. (thats a bit like a "github pull request" -- just without the nice web-UI).
[17:49] <ricotz> Sweet5hark1, I am aware of what git is capable
[17:51] <ricotz> Sweet5hark1, and again there were weeks between your upload/changes and me pushing this
[17:57] <Sweet5hark1> ricotz: yes, I wanted to squeeze in a rc1 release on friday. but the CVE nonsense pointlessly ate too much time.
[18:08] <ricotz> Sweet5hark1, https://paste.debian.net/plain/777801
[18:13] <Sweet5hark1> ricotz: thx, willdo tomorrow.
[18:33] <willcooke> night all
[21:20] <tjaalton> anyone know if unity7 has some autoscaling applied with intel driver? because there's no scaling with the modesetting driver
[22:58] <Trevinho> tjaalton: there's no autoscaling by default
[22:58] <Trevinho> tjaalton: there's a branch that does that which we'll likely merge soon, though
[23:10] <tjaalton> Trevinho: ok, somehow it does scale with intel.. even on xenial
[23:11] <Trevinho> tjaalton: gdk might apply that automatically, but..... it shouldn't
[23:12] <tjaalton> alright


[00:20] <tonyyarusso> Alpha_Cluster: so what's the status of a release party up there eh?
[00:20] <Alpha_Cluster> um non that i know of so far sorry :(
[00:24] <tonyyarusso> Alpha_Cluster: You're supposed to make one happen.  :P
[00:24] <Alpha_Cluster> lol
[00:24] <Alpha_Cluster> yeah the problem i have nothing to do that with right now...
[00:25] <tonyyarusso> what do you mean?
[00:26] <Alpha_Cluster> i dont have people really interested or any computers personallly running it..
[00:27] <tonyyarusso> People get interested because you tell them to be interested!
[00:28] <Alpha_Cluster> lol that doesnt work up here as well as down there we have a much smaller pool of people
[00:28] <tonyyarusso> so you get fewer.  So?
[00:28] <Alpha_Cluster> ill talk to richard about it though if i see him on in the next day or so
[00:35] <Alpha_Cluster> tonyyarusso: did you miss hte whole iplayer fiasco with the BBC>
[00:35] <Alpha_Cluster> ?
[00:35] <Alpha_Cluster> btw would it be considered approriate to do a ubuntu presentation using keynote on a iPad?
[00:36] <tonyyarusso> Alpha_Cluster: I didn't miss it, but nor did I pay attention to it.
[00:36] <tonyyarusso> haha, a little odd, but you could...
[00:36] <Alpha_Cluster> ahh cause there was a bunch of complaints about hem using flash when it original came out
[10:47] <kermit> http://en.wikipedia.org/wiki/Ubuntu_Cola


[01:44] <callmepk> good morning
[01:49] <jamesh> morning callmepk
[01:50] <callmepk> morning jamesh
[06:11] <didrocks> good morning
[06:21] <duflu> Hi didrocks
[06:26] <didrocks> hey duflu
[06:30] <seb128> goood morning desktopers
[06:40] <didrocks> salut seb128, bon week-end ?
[07:27] <duflu> seb128, anyone, could someone please hit retry on https://people.canonical.com/~ubuntu-archive/proposed-migration/bionic/update_excuses.html#libxau
[07:27] <duflu> It looks like a network issue
[07:28] <didrocks> duflu: done
[07:29] <duflu> Ta didrocks
[08:01] <seb128> lut, ouais ça va, et toi?
[08:03] <didrocks> ça va :)
[08:04] <Laney> hi
[08:04] <Laney> it's a NEW WEEK!
[08:05] <Laney> I forgot my terminal shortcut to switch windows and just had to try all of the combinations until I found the right one
[08:06] <Laney> must have been a good/long weekend
[08:12] <didrocks> hey hey Laney
[08:12] <didrocks> heh, too long
[08:14] <duflu> Hi Laney. Weekend successful then
[08:18] <Laney> not long enough, I want to forget where all of the letters on the keyboard are too!
[08:18] <Laney> hey didrocks duflu
[08:18] <Laney> going ok?
[08:21] <didrocks> Laney: going fine, uneventful week-end :)
[08:22] <seb128> hey Laney, how are you?
[08:23] <seb128> Laney, just buy an azerty keyboard, will give you the same feeling :)
[08:23] <didrocks> with the afnor norm, please!
[08:24]  * didrocks can’t type anymore on a classic azerty keyboard though :/
[08:25] <Laney> hey seb128, i'm pretty good!
[08:25] <Laney> you?
[08:25] <Laney> what is afnor norm?
[08:25] <Laney> there are multiple types of french keyboard layout?
[08:26] <seb128> I'm fine
[08:26] <seb128> and yeah, they 'modernized' the azerty layout
[08:26] <seb128> so you can find old style and new style azerty now
[08:27] <Laney> eek
[08:27] <didrocks> supposively, there is only one, because the old one was never normalized
[08:28] <didrocks> (afnor is the norm institution)
[08:28] <Laney> so that one is supposed to go away over time?
[08:29] <didrocks> don’t know, because everyone is using the old one, so, habits… Getting risk to change for laptop/leyboard builder
[08:29] <didrocks> keyboard*
[08:29] <didrocks> who knows how it will go
[08:30] <jibel> and the simple quotes on the afnor layout is incompatible with gettext
[08:31] <seb128> how can a char be incompatible with gettext?
[08:31] <seb128> it's not utf-8?
[08:32] <didrocks> it*’*s utf-8, but gettext is busy
[08:33] <seb128> 'busy'?
[08:33] <didrocks> buggy
[08:33] <didrocks> sorry :)
[08:33] <seb128> ah
[08:33] <seb128> we should backport the fix if there is one
[08:33] <seb128> I expect it's just a simple bug?
[08:33] <didrocks> I didn’t find anything, but I didn’t dig more
[08:33] <didrocks> I need to, on my backlog
[08:34] <seb128> if you tell me what's buggy/the test case to trigger the issue I can try to have a look
[08:34] <seb128> you are off soon enough and I guess we will not get to that before being back
[08:35] <didrocks> seb128: let’s plan that once I’m back?
[08:35] <seb128> sure, no hurry
[08:35] <didrocks> happy to give you a simple test case
[08:35] <didrocks> great :)
[10:06]  * seb128 wonders what's going on there
[10:06] <seb128> http://autopkgtest.ubuntu.com/packages/u/upower/groovy/amd64
[10:07] <seb128> trigger libimobiledevice/1.3.0-2
[10:07] <seb128> Get:27 http://ftpmaster.internal/ubuntu groovy/main i386 libimobiledevice6 i386 1.2.1~git20191129.9f79242-1build1 [73.4 kB]
[10:07] <seb128> so not only the right version
[10:07] <seb128> but :i386?
[11:03] <seb128> hum, retried worked, probably some archive issue...
[15:32] <hellsworth> good morning desktopers!
[15:32] <hellsworth> (i missed you all these last few days)
[16:37] <kenvandine> @hellsworth good morning
[16:42] <hellsworth> hi kenvandine !


[00:43] <[reed]> fta: yes
[00:44] <fta> [reed], why don't you maintain the packages? they're staled
[00:44] <fta> !info bugzilla3
[00:45] <[reed]> I don't have the time, sadly. :/
[00:45] <fta> 3.6.3 in natty and debian
[00:45] <fta> vulnerable
[00:45] <[reed]> 4.0 is latest
[00:45] <fta> i know
[00:45] <fta> it sucks
[00:45] <[reed]> I agree
[00:45] <[reed]> and I wish I could help
[00:45] <[reed]> I just don't have the time at all
[00:45] <[reed]> :(
[00:46] <fta> i need a bts, i can't find any that don't suck
[00:46] <[reed]> you could install it from bzr directly ;)
[00:47] <fta> no, i won't have time to maintain it afterwards either
[00:47] <fta> hence the need for a well maintained deb
[14:43] <anteaya> can I ask questions about a troublesome spidermonkey build in here?
[15:07] <BUGabundo> fta: desktop notifications stop working!
[15:07] <BUGabundo> newer builds seem to not allow me to enable them :\


Funerals are always fun (well, two I've been to really were...)


[07:56] <omnipotentfaggot> hello folks! does anyone know anything about Canonical's new CEO, Jane Silber?
[07:56] <omnipotentfaggot> (Mark Shuttleworth's successor)
[07:59] <AlanBell> omnipotentfaggot: that isn't very new news
[08:03] <travelhard> hi to all
[08:52] <omnipotentfaggot> when is ubuntu going to overtake windows?
[08:52] <AlanBell> already has
[08:53] <AlanBell> it is much better
[08:53] <omnipotentfaggot> I mean in popularity
[08:54] <k1l> AlanBell++ :)
[08:55] <AlanBell> hard to say really, they don't seem to be targetting the desktop at work very much
[08:55] <AlanBell> it is becoming a home user operating system really
[08:56] <AlanBell> Mac is the main competition, Windows is just inertia in the workplace
[08:57] <omnipotentfaggot> if any hardware manufacturing company would actually sell ubuntu computers that'd be a start. Dell did at one point, under the table
[08:57] <omnipotentfaggot> windows is trying to squeeze out the competition. e.g. with secured boot so you can't install any other operating system but the factory-installed one (Windows) without modifying the hardware
[08:58] <k1l> the problem is the microsofts market power. if you take a look at the netbook history you know what i mean
[08:59] <k1l> and with the secureboot thing on arm they demand back the arm market, which they obviously lost
[08:59] <AlanBell> Dell is going to sell an ultrabook again
[08:59] <omnipotentfaggot> 'arm'?
[09:00] <k1l> omnipotentfaggot: the other cpu architecture than x86. its build in in smartphones and tablets etc
[09:00] <omnipotentfaggot> 32-bit, 64-bit...
[09:02]  * popey hugs his arm laptop
[09:02] <popey> and tablet
[09:02] <popey> \o/ ubuntu
[09:02] <k1l> i have a ubuntu port on my hp touchpad. but its really alpha state
[09:03] <omnipotentfaggot> http://www.ubuntu.com/partners/dell
[09:03] <AlanBell> popey: the Asus transformer infinity should be out next week here
[09:03] <AlanBell> would love one of those running Ubuntu
[09:04] <popey> is it tegra3?
[09:04] <omnipotentfaggot> k1l it's a tablet?
[09:04] <AlanBell> yes
[09:04] <k1l> omnipotentfaggot: yes?
[09:04] <omnipotentfaggot> cool. is it useable?
[09:04] <popey> my SmartQ T20 has Ubuntu on it
[09:04] <AlanBell> there were two processor options, but I think the quad core tegra 3 is the one we get
[09:05] <popey> Ubuntu doesn't work very well on tablets right now
[09:05] <k1l> omnipotentfaggot: early alpha state. thats enough to say i think :)
[09:05] <popey> AlanBell, what was the other option? please say OMAP4?
[09:07] <omnipotentfaggot> the ubuntu.com page about dell is kind of funny. "Dell and Canonical engineers collaborate every day to certify Dell hardware on Ubuntu, to a level that customers can rely on." i have a new dell laptop and I had to manually edit some code to get headphones to work when i installed ubuntu
[09:08] <k1l> i got an old dell and it runs ootb :)
[09:09] <elky> my 2009-ish dell is ootb too
[09:09] <AlanBell> Qualcomm® MSM 8260A Snapdragon™ S4 Krait Dual-core 1.5Ghz CPU(3G )
[09:09] <AlanBell> NVIDIA® Tegra® 3 Quad-core T33@ 1.6GHz (WIFI)
[09:10] <AlanBell> are the two processor options popey, but I only see tegra3 mentioned in recent articles
[09:10] <AlanBell> probably because we don't get the funky 4G mobile signal in the UK
[09:13] <popey> omnipotentfaggot, most new dells should 'just work', pretty much every dell model is certified to run ubuntu
[09:13] <omnipotentfaggot> now is a quad-core processor in a tablet actually equivalent to a laptop's quad-core?
[09:13] <omnipotentfaggot> popey - including Studio 17
[09:14] <omnipotentfaggot> ?
[09:14] <popey> i dont know that particular model, but we work with them to certify them all
[09:14] <AlanBell> it is just quad core, most quad core laptops are quad core hyperthreaded, so appear as 8 distinct processing units
[09:15] <omnipotentfaggot> I love ubuntu, but I have to say "just works" has been just the opposite of my experience :)
[09:15] <omnipotentfaggot> just as well tho
[09:16] <popey> yeah, everyone has those experiences now and then
[09:16]  * popey stabs the wifi in his imac
[09:16] <omnipotentfaggot> learning to pop the hood to fix a problem teaches you how to pop the hood for creative purposes
[09:25] <omnipotentfaggot> one thing that is absolutely fantastic is the level of documentation for every single error I have encountered on ubuntu. you can google your way out of any problem. you don't even need to come on IRC and ask for help
[20:54] <icequeen> howdy
[21:16] <MrChrisDruif> Aloha sissyphus
[21:18] <sissyphus> what's up friend?
[21:19] <MrChrisDruif> Nothing much, just some ceiling.... ;-)
[21:24] <sissyphus> lol. that took me a minute
[21:45] <MrChrisDruif> Almost of to bed tbh
[21:45] <sissyphus> jeez, are you in europe?
[21:46] <MrChrisDruif> No, I'm in Holland ;-P
[21:46] <MrChrisDruif> Sorry, troll-mode seems on.
[21:46] <MrChrisDruif> But yeah, Europe. CEST timezone


[00:01] <lifeless> very much so
[00:05] <poolie> hello jelmer
[00:05] <poolie> and lifeless and gary
[00:05] <lifeless> hai
[00:08] <poolie> jelmer: when you use bzr-svn on a svn repo that's had changes merged from a branch into trunk
[00:08] <lifeless> jelmer: not all bugs need tags :P
[00:08] <poolie> will bzr see the history of changes to a file on the branch before they're merged in?
[00:09] <jelmer> hi poolie
[00:09] <jelmer> poolie: In what context?
[00:10] <jelmer> lifeless: It's so easy to add them now I'm trying to add some that seem relevant when possible
[00:10] <jelmer> lifeless: I find them useful when looking for dupes
[00:10] <poolie> i think it's worth adding tags about proportional to the frequency you use them
[00:10] <poolie> i didn't use them much previously, now they're a bit useful
[00:11] <poolie> jelmer, well if you run log or annotate within bzr for example
[00:11] <poolie> the specific case was
[00:11] <jelmer> being able to edit them without having to go to a different page makes them a lot more useful
[00:11] <poolie> > 1. import /trunk/foo.txt
[00:11] <poolie> > 2. branch /trunk to /branches/mybranch
[00:11] <poolie> > 3. edit /mybranch/foo.txt
[00:11] <poolie> > 4. merge /mybranch to /trunk
[00:11] <poolie> will bzr see step 3?
[00:12] <lifeless> jelmer: I think tags that are reused a lot are great
[00:12] <jelmer> poolie: depends on how (4) was done
[00:12] <jelmer> poolie: if it was a merge done using bzr and pushed using bzr-svn, then bzr will see it
[00:12] <mwhudson> jml: is bzr 1.16 in any ppa yet?
[00:12] <jelmer> poolie: otherwise, it won't, even with svn 1.5 (since it only supports tracking cherrypick merges, not "full" merges)
[00:13] <lifeless> jelmer: but when there are few bugs for that tag its no better than searching
[00:13] <jelmer> lifeless: right
[00:14] <poolie> mwhudson: "apt-cache madison bzr"
[00:14] <poolie> well, assuming you have them all added
[00:15] <lifeless> poolie: rmadison bzr
[00:15] <lifeless> oh damn
[00:15] <lifeless> ppas
[00:15] <lifeless> rmadison should be able to query ppa
[00:15] <poolie> what's rmadison?
[00:15] <mwhudson> seems not
[00:15] <poolie> remote madison?
[00:15] <lifeless> yah
[00:15] <lifeless> queries lp/debian
[00:16] <lifeless> rmadison -u debian bzr
[00:17] <poolie> jelmer: in the mail i have, the person asserts that svn can follow the distory of that file
[00:17] <poolie> maybe because it didn't exist on trunk at all before the merge?
[00:18] <poolie> so svn just represented it as a copy (speculating)
[00:18] <poolie> in that case i think bzr-svn will track it?
[00:20] <lifeless> spiv: ping
[00:20] <poolie> where should we put the ppa debs?
[00:20] <poolie> i guess we could manually maintain an archive somewhere...
[00:21] <jelmer> poolie: svn would be able to see which revisions have been cherrypicked onto trunk
[00:21] <jelmer> poolie: but bzr isn't able to deal with cherrypicks, so bzr-svn ignores that data
[00:22] <jelmer> poolie: it could do analysis to see if a range of merged revisions is a "full" merge and then add the appropriate parents, but I'm worried about the performance of that analysis if it has to be done for each revision and it seems like it'd just be a stopgap until proper cherrypicking tracking is in place
[00:24] <poolie> right
[00:30] <garyvdm> Hi poolie
[00:33] <poolie> spiv, any ideas about bug 389087?
[00:35] <lifeless> jml: mwhudson: thumper: is https://bugs.edge.launchpad.net/bzr/+bug/372881 still affecting you ?
[00:37] <jml> lifeless, I couldn't say.
[00:38] <mwhudson> lifeless: haven't heard anyone complain about it for a while
[00:39] <jrwren> jam: i'm back to where I was at 16:45 EDT.  what is this trace class of which you speak for me to trace.mutter ?
[00:40] <jrwren> nvm, google first.
[00:40] <thumper> lifeless: not me personally
[00:48] <jrwren> will mutter messages always been output to STDOUT or STDERR?
[00:49] <jelmer> jrwren: only to ~/.bzr.log afaik
[00:49] <RenatoSilva> If I have two different features to implement and propose for merging, should I use one branch for each one, or one single branch?
[00:50] <jrwren> i don't have that file, do I need to touch it?
[00:50] <jrwren> or maybe on windows it goes to that APPDATA place?
[00:50] <Peng_> RenatoSilva: Two branches, if it makes sense. Obviously, if one depends on the other, that'd be harder.
[00:50] <Peng_> Could still use looms, I suppose.
[00:51] <RenatoSilva> Peng_: the problem is that the branch is a bzr plugin, and I'm using both modifications locally. They don't rely on each other, but I do reply on both of them :)
[00:53] <RenatoSilva> Peng_: maybe I could have 3 branches locally, 2 of them for development, and one for local use. I would merge the 2 branches into the thrid one once in a while. How about it?
[00:54] <Peng_> RenatoSilva: Sure.
[00:54] <RenatoSilva> ok, thanks
[01:01] <spiv> lifeless: pong
[01:02] <lifeless> network deltas
[01:02] <lifeless> I'm blocked on check, and picking the next thing to do
[01:03] <ebroder> How do people usually submit one-line patches to LP projects? Branch it and request a merge? Just file an LP bug?
[01:04] <lifeless> #launchpad might have a better answer; I'd say branch and submit a merge (without doing that its rather hard to test :P)
[01:04] <lifeless> but if its just a typo or something, sure  abug with a diff inline
[01:05]  * ebroder nods
[01:05] <lifeless> whatever gets the devs attention and is appropriate for the ammount of work really
[01:05] <ebroder> *shrug* I'm used to the amount of prep work for a fix being disproportional to the fix itself :)
[01:06] <spiv> poolie: regarding that AbsentContentFactory bug, it's almost certainly a dupe of 354036, those are both stacked branches that were created before 1.14.1.
[01:06] <spiv> (and I see it's already been marked as a dupe)
[01:07] <lifeless> spiv: 'network deltas' wass in reply to your pong
[01:10] <poolie> spiv, lifeless, thanks, i thought it probably was
[01:10] <lifeless> poolie: 'bzr info <branch>' is a fast way to check if branches are stacked
[01:11] <spiv> lifeless: network deltas would be great to do, I still haven't got to them :(
[01:13] <poolie> lifeless: i know, why?
[01:13] <poolie> i mean, why do you mention that?
[01:14] <lifeless> poolie: just seemed like the time to handoff that bug was about the same as doing a quick check and duping
[01:16] <RenatoSilva> Peng_: optionally, I can merge the 2 branches to the 3rd one, and keep the merge uncommitted. When I have new changes in the 2 branches, I just bzr revert and merge again. I think it's the easiest way...
[01:17] <poolie> sigh
[01:17] <lifeless> poolie: it was just a though
[01:17] <lifeless> t
[01:17] <poolie> if you actually mean to say "checking that it's stacked is a 100% reliable way to know it's a dupe" then that i didn't know
[01:17] <poolie> and i'm not sure i believe it
[01:18] <lifeless> poolie: its extremely high probability. In this particular case I know 100% that the current branch was a dupe, because I ran the fixer and it found missing inventories.
[01:18] <poolie> ok
[01:18] <lifeless> poolie: the lp-code people have not yet run the fixer across launchpad stacked branches
[01:18] <RenatoSilva> humm I can't merge twice without commiting the first merge :(
[01:18] <lifeless> RenatoSilva: you can by passing --force to merge; but its unusual to do this.
[01:19] <poolie> jam, are you still around? want to talk sometime?
[01:19] <RenatoSilva> lifeless: I'm afraidn you're following the discussion, but I think it's a good solution in my case, I'll try --force, thanks!
[01:20] <RenatoSilva> clear
[01:20] <lifeless> I did follow it.
[01:20] <RenatoSilva> clear
[01:20] <RenatoSilva> lifeless: ok
[01:21] <AfC> Is there a technical reason why the text metadata in a bundle all has to come at the beginning, _above_ the patch? Could we not have a one or so line header
[01:21] <RenatoSilva> the 3rd branch is read-only
[01:21] <AfC> # Bazaar merge directive format 3 (Bazaar 1.17)
[01:21] <AfC> and then the patch
[01:22] <AfC> and then the revision id crap?
[01:22] <AfC> or better yet,
[01:22] <poolie> AfC: probably not a good reason
[01:22] <poolie> possibly showing the target branch there is useful
[01:22] <lifeless> RenatoSilva: that doesn't make a difference AFAICT
[01:23] <lifeless> RenatoSilva: doing merge,commit,merge,commit and merge,merge--force,commit is not altered by the read state of the third branch
[01:23] <AfC> poolie: oh, still showing it (if necessary) but down below, after the patch, above the base64 [or whatever] blob of data
[01:23] <poolie> jam, nice work on bug 345998
[01:24] <RenatoSilva> lifeless: I mean that I won`t deliver the 3rd patch
[01:24] <RenatoSilva> lifeless: If I want to change something, I will do it in the other branches
[01:25] <RenatoSilva> lifeless: s/3rd patch/3rd branch
[01:35] <lamont> lifeless: how soon do you think 1.16 will be released?  (as in installable on an ubuntu box)
[01:35] <lamont> s/lifeless/poolie/
[01:35] <RenatoSilva> clear
[01:37] <lifeless> lamont: PPA should be up shortly
[01:37] <lifeless> johnf is reasonably prompt
[01:37] <lamont> yay
[01:38] <lifeless> he offers a two day SLA
[01:38] <lifeless> but - 1.16rc1 is pretty close to 1.16.
[01:38] <lamont> actually, there's a 1.16-1 in debian, I assume that should just work, no?
[01:38] <lifeless> and thats alrady in the ppa
[01:38] <lifeless> I'd expect so,yes
[01:38] <lifeless> just get it synced()
[01:38] <lamont> lifeless: I'm pretty sure you know why I'm asking, and what the rules are for me to live within.
[01:39] <lifeless> lamont: wasn't, but just noticed now.
[01:44] <lifeless> jam: are you still around at all?
[01:46] <lifeless> jelmer: help me understand https://bugs.edge.launchpad.net/bzr/+bug/386079
[01:49] <jelmer> lifeless: as far as I've understood it the problem is that if there's other svn dlls in directories in PATH those get used rather than the DLLs that subvertpy was linked against
[01:51] <jelmer> lifeless: so it's probably not important enough to be critical, but John would be better able to tell you
[01:53] <lifeless> thanks
[01:57] <garyvdm> lifeless: I got my widget to load lazily :-) And so for working trees, I only create copies of items that are shown.
[01:59] <lifeless> james_w: if you're around, is there a good link on bzr packaging at the moment?
[02:00] <lamont> lifeless: in the painful case, it's a merge of the diffs in 1.15->1.15-x to s/5/6/g
[02:00] <lifeless> there are diffs?
[02:00] <lamont> which is part of why I got out of that business
[02:01] <lamont> apt-get source is your friend
[02:01] <lamont> some of them are only a diff in debian/changelog
[02:01] <lifeless> garh
[02:01] <lamont> others have debian/control and debian/rules changes
[02:01] <lamont> others... well, ISTR one setup.py patch one time
[02:02] <poolie> jml, lamont suggests not doing the announcement mail until we have installers for say ubuntu and windows at least
[02:02] <poolie> interesting idea
[02:03] <lifeless> I don't like it
[02:03] <lifeless> because redhat + bsd + suse etc
[02:04] <lifeless> unless we want to take responsibility for building all of them too
[02:04] <lamont> lifeless: I do.  makes it get done before I get the privilege of explaining that it's not out to people who think I should install it NAO
[02:04] <lamont> lifeless: you could block on $everyplatform - that'd be more software industry standard
[02:04] <jml> poolie, for that to work & still have time-based releases, building those installers would have to be the RM's job, I think.
[02:04] <lifeless> lamont: the people in question should know better :)
[02:04] <poolie> well, making sure that someone builds it
[02:05] <jml> poolie, which would mean that building those installers would have to be as easy as falling off a log.
[02:05] <poolie> it tends to make the RM's job bigger
[02:05] <thumper> if I have a light weight checkout, can I just switch the underlying repository format under it?
[02:05] <poolie> which is undesirable
[02:05] <poolie> thumper: probably yes
[02:05] <lifeless> thumper: yes
[02:05] <thumper> move my packs repo out of the way, move 2a in and have it work
[02:05] <thumper> cool
[02:05] <lifeless> oh
[02:05] <jml> poolie, making sure someone builds it drags out the process further, because of hand-offs & TZ issues.
[02:05] <lifeless> actually 'no'
[02:05] <lifeless> thumper: the root data in the dirstate will be invalid
[02:05] <thumper> lifeless: why?
[02:06] <lifeless> of course, its likely that I've just realised that 'bzr upgrade' has a critical bug with respect to rich root changes
[02:06] <thumper> :(
[02:08] <lifeless> thumper: recreate the tree
[02:08] <thumper> ok
[02:08] <lifeless> thumper: you should do this for all trees when you upgrade the repo across a model change (non-rich-root to rich-root)
[02:08] <thumper> ok
[02:09] <lamont> lifeless: if the announcement said "we'll have binaries shortly" or some such, that'd help.
[02:09] <poolie> i think it normally does
[02:09] <lamont> right now, if I go to bazaar-vcs.org and click on what appears to be the link to go get ubuntu install info for 1.16, I get.... 1.15-1
[02:09] <lamont> which is kinda confusing to a newbie
[02:09] <poolie> which link?
[02:10] <lamont> Downloads and installation instructions
[02:10] <lamont> then
[02:10] <lamont> ppa repository,
[02:10] <lamont> downloads and install being a link under 1.16
[02:12] <lamont> which, of course is one of 2 ways that I check to see if it's out already.
[02:12] <lamont> the other being apt-get update; apt-get showsrc bzr | grep Version
[02:13] <thumper> lifeless: branching from my server to my laptop where both repos are 2a over bzr+ssh I'm getting CPU maxing on the server, and very little network traffic
[02:13] <thumper> lifeless: fetching revisions
[02:13] <RenatoSilva> clear
[02:14] <lifeless> thumper: is it an initial branch?
[02:14] <lifeless> thumper: that is, is the target repo empty?
[02:14] <lamont> anyway, family time gluing a floor down.  later.
[02:14] <thumper> lifeless: yes
[02:14] <lifeless> ciao lamont
[02:15] <lifeless> bug 388269
[02:15]  * thumper nods
[02:15] <thumper> ok
[02:16] <thumper> we probably want this fixed before everyone tries to grab LP :)
[02:17] <lifeless> not going to happen
[02:17] <lifeless> theres a bunch of stuff we /have/ to get done which if we don't things will be consistently bad much more often
[02:18] <lifeless> and you have a fixed date for the LP code; I don't see us getting through everything for 2 before then; *if* we do then perhaps - but this isn't a regression
[02:18] <lifeless> its been like this for a long time, and the LP code base is no worse than mysql's, AFAIK
[02:33] <Peng_> lifeless: ...I totally didn't know about merge --force. I'll have to remember that!
[03:20] <lifeless> igc1: ping
[03:22] <lifeless> jelmer: hi
[03:22] <lifeless> jelmer: I have a small request for you while you are touching bugs
[03:22] <ahn> I'm new to bzr and am trying to figure out a way to merge converted repositories.
[03:22] <Peng_> ahn: What exactly do you mean?
[03:23] <lifeless> jelmer: as you qualify as a dev, perhaps you could try to move the bug forward a step at the same time?
[03:23] <ahn> I have a bzr repository A, which is a conversion from CVS with full history, that includes versions from say 2000-2005.
[03:23] <ahn> I have a bzr repository B, which a conversion from darcs with full history, that includes version from say 2006-2009.
[03:23] <ahn> I'd like to know if there is a way to essentially "concatenate" the two repositories so that the histories are in series.
[03:24] <lifeless> jelmer: specifically, after you touch it, it should be either incomplete needing more info, waiting for someone more knowledgable than you to comment/analyse, or ready-to-code.
[03:24] <lifeless> jelmer: ^ not a requirement, but if you can, its actually more useful than merely categorising many bugs to do that to a smaller number of bugs
[03:25] <lifeless> ahn: what you may find works best is to export B as a fast-export and use fast-import to append it to A
[03:25] <ahn> lifeless: fast-import appends to an existing repository while preserving full history?
[03:26] <lifeless> I'm fairly sure it can
[03:26] <lifeless> of course, work on a backup until you've got the process tuned for you
[03:26] <lifeless> fast-export and fast-import are in the bzr-fast-import plugin
[03:26] <ahn> I will investigate, thanks.
[03:47] <Peng_> jelmer: FYI, you had a revision of bzr-rebase's trunk that marked it as compatible with bzr 1.16 and 1.17, but it's been replaced by the 0.5.1 release.
[04:34] <treeform> i am trying to get another project member using bzr
[04:34] <treeform> he he is running into all sort of porblems like this
[04:34] <treeform> http://pastebin.com/d58e1f99
[04:34] <lifeless> treeform: use a newer version, that bug was fixed
[04:35] <treeform> lifeless: thanks!
[04:36] <treeform> lifeless: hmm there is no 1.1.6 windows build yet
[04:36] <treeform> 1.1.6*
[04:36] <treeform> grr
[04:36] <treeform> 1.16*
[04:37] <lifeless> should be a 1.15.x one though
[04:37] <treeform> no they got new on up in another place
[04:38] <jml> https://edge.launchpad.net/bzr/1.16/1.16 has windows builds
[04:38] <treeform> thanks
[04:38] <treeform> but its not main link at the site
[04:40] <igc> hi all
[04:40] <igc> pong lifeless
[04:40] <treeform> sup igc
[04:41] <lifeless> igc: iter_changes; are you blocked/its on the shelf/its all done vis-a-vis commit?
[04:41] <lifeless> igc: if its on the shelf I may do it next week
[04:42] <jml> treeform, is now :)
[04:42] <igc> lifeless, it's on the shelf for at least a few more days
[04:42] <jml> (yay wikis)
[04:42] <igc> igc: if you got to it, that would be really great
[04:42] <igc> lifeless: ^^
[04:42] <lifeless> igc: ok. Monday I'll page it in and make a call about doing it/not.
[04:42] <treeform> jml: i love open source :)
[04:43] <igc> lifeless: sweet. I did put a fair amount into it but nothing beyond my initial terrible-to-ok-but-not-great patch that's worth sharing
[04:43] <lifeless> igc: kk
[04:49] <treeform> "bzr: ERROR: Unable to look up default port for ssh" ?
[04:49] <treeform> hmm its 20 or 22?
[04:50] <treeform> should bzr know that?
[04:50] <treeform> 22 wins!
[04:50] <lifeless> never seen that error before
[04:50] <lifeless> you might like to file a bug
[04:51] <treeform> http://pastebin.com/d79ccb48f
[04:51] <treeform> i think his problem is that
[04:51] <treeform> he cant break lock
[04:51] <treeform> because of this stupid ssh error
[04:51] <treeform> and he cant rebind
[04:51] <treeform> because of the stupid lock
[04:51] <lifeless> if you run with -Derror you will get a backtrace that may help debugging
[04:52] <treeform> is there a way to break lock manually?
[04:52] <lifeless> I'm not sure why you have a lock that needs breaking anyway
[04:52] <lifeless> that should be very rare
[04:52] <spiv> treeform: have you tried "bzr break-lock bzr+ssh://host:22/..." ?
[04:52] <treeform> no
[04:52] <treeform> there is no lock on the server
[04:52] <treeform> its local
[04:52] <treeform> i ran bzr break-lock on the server
[04:52] <treeform> nothing cameup
[04:53] <lifeless> run bzr unbind; bzr break-lock; bzr bind
[04:54] <spiv> Also, maybe your %SYSTEMROOT%\System32\Drivers\Etc\Services
[04:54] <spiv> needs fixing?
[04:54] <spiv> (that's just a wild guess, though)
[04:54] <lifeless> the backtrace will tell us
[04:56] <treeform> hmm
[04:56] <treeform> how to disable default bzr-tortouze stuff on windows?
[04:56] <treeform> his computer is lagging like hell because of it
[05:38] <lifeless> treeform: I'm not sure
[05:44] <treeform> i think i found it
[06:33] <RenatoSilva> any bzr-eclipse folk here?
[06:42] <johnjosephbachir> hey folks
[06:43] <johnjosephbachir> workflow question: i'm working on some code, i want to merge in upstream changes. i get the message "ERROR: Working tree "blah blah/" has uncommitted changes"
[06:43] <johnjosephbachir> what are my reasonable options here?
[06:43] <lifeless> either commit before merging, or shelve before merging
[06:44] <lifeless> merging changes your tree and then you need to commit what you merged
[06:45] <johnjosephbachir> what i want to do, is bring in the new changes, and then carry on with what i was doing.
[06:45] <johnjosephbachir> to do that, do i shelve, merge, unshelve?
[06:45] <lifeless> shelve; merge; commit; unshelve
[06:45] <johnjosephbachir> ahhhh
[06:45] <johnjosephbachir> okay
[06:45] <johnjosephbachir> thanks!
[06:45] <lifeless> or
[06:45] <lifeless> commit; merge; commit
[06:46] <lifeless> depending on whether you have reached a suitable point to commit your own changes
[06:46] <johnjosephbachir> yeah, i haven't
[06:47] <johnjosephbachir> okay, i just did bzr shelve, and then y y y y
[06:47] <johnjosephbachir> but bzr status still shows modified files
[06:47] <johnjosephbachir> do i need to manually rever them?
[06:47] <johnjosephbachir> by manually i mean, explicitely, with bzr
[06:47] <lifeless> uhm
[06:47] <johnjosephbachir> and/or: won't merge still complain?
[06:48] <lifeless> 'bzr shelve --all' should save everything such that 'bzr st' will show no changes
[06:48] <johnjosephbachir> okay
[06:48] <lifeless> if it doesn't, what bzr version are you using?
[06:53] <johnjosephbachir> --all did it
[06:53] <johnjosephbachir> i wonder if i was hitting y / return so fast that it missed a couple ys
[06:55] <lifeless> johnjosephbachir: I'd say so ;)
[06:55] <ttyType> hi people
[06:55] <ttyType> my kitteh just managed to catapult my spoon out of my cereal bowl, so my monotor was covered in soy milk spatter
[06:55] <ttyType> (it's a lappy)
[06:56] <ttyType> it looked like someone has been looking at pr0n
[06:56] <ttyType> *monitor
[07:19] <poolie> anyone want to comment on the proposed phrasing in bug 346677?
[07:41] <spiv> poolie: commented
[08:27] <poolie> thanks spiv
[08:39] <treeform> hmm lifeless, jml  windows bzr just not working for us... the guy i was working with gave up
[08:40] <jml> treeform, that sucks.
[08:40] <treeform> i dont know what to do
[08:40] <treeform> i been using bzr for so long
[08:41] <treeform> but when other people try to use it it just breaks for them
[08:41] <jml> treeform, there's a couple of things I can think of.
[08:42] <treeform> part of the problem might be that the bzr repo is 1GB of data
[08:42] <jml> treeform, the first is look for the failures in Bazaar's bug tracker: https://bugs.launchpad.net/bzr
[08:42] <treeform> and we dont have great network connectsion
[08:42] <treeform> so its always a bother pushing this much data around
[08:43] <treeform> jml: i have opend some bugz in that list
[08:43] <jml> treeform, although my mental powers are to be greatly feared, they do not extend to mind-reading.
[08:44] <vila> hi all
[08:44] <treeform> well what do you want me to do?
[08:44] <jml> treeform, explicitly describing the observed failures is often half the battle.
[08:45] <treeform> yeah
[08:45] <jml> vila, hi :)
[08:45] <lifeless> treeform: where did you get stuck with your friend?
[08:45] <treeform> when working with some one who is not verly technical its a real pain
[08:45] <vila> jml: hey !
[08:45] <lifeless> I'm not really here right now
[08:45] <lifeless> but I'd say
[08:45] <lifeless> be sure they don't run random commands, if they are having trouble flailing will make it worse.
[08:45] <lifeless> if bzr gives an error that you don't recognise file a bug etc
[08:46] <treeform> well it started out with sftp
[08:46] <treeform> basically i did an update
[08:46] <treeform> it did a repack
[08:46] <treeform> and it when redownloading everything
[08:46] <treeform> so i say
[08:46] <treeform> hmm
[08:47] <treeform> ok lets switch to bzr+ssh
[08:47] <treeform> just kill the update
[08:47] <treeform> which was running now for 2 hours
[08:47] <treeform> so he broke it
[08:47] <treeform> now lets rebind
[08:47] <treeform> cant
[08:47] <treeform> its locked
[08:47] <treeform> lets break lock
[08:47] <treeform> cant break lock
[08:47] <treeform> then you guys suggested to update
[08:47] <treeform> ok we update
[08:47] <treeform> still cant break lock
[08:48] <treeform> because now we cant ssh
[08:48] <treeform> so another thing broke during update
[08:48] <treeform> on the other hand i cant really blame bzr
[08:48] <treeform> because its turning more into people problem then a software problem
[08:48] <treeform> --- end of rant --- sorry
[09:05]  * igc dinner
[09:17] <jml> treeform, the situation certainly sounds complex.
[09:17] <jml> treeform, maybe sending an email to the bazaar list is your best bet.
[09:18] <treeform> bzr is being blamed for making computer run really really slow
[09:18] <treeform> it can be a virus
[09:18] <treeform> he is uninstalling to conform
[10:09] <jtv> jml: more bzrlib complications...  I think I need to get a trans-id for a directory in my revision tree.
[10:09] <jtv> I know how to get its id, but not its trans id.
[10:11] <lifeless> doesn't exist
[10:11] <lifeless> trans-ids only exist during a tree transform, they are transient
[10:11] <lifeless> why do you think you need it
[10:11] <lifeless> ?
[10:16] <jtv> lifeless: nm, I've got it now, from the transform preview.
[10:16] <jtv> lifeless: this is still for the direct-commit-to-branch stuff.
[10:56] <poolie> spiv, lifeless, bug 389413 is strange
[10:57] <poolie> is that a dupe maybe?
[10:57] <lifeless> poolie: are you burning out? logoff :)
[10:57] <poolie> mm, why?
[10:57] <poolie> should i know what it is?
[10:57] <spiv> I think he's saying it's nearly 8pm :)
[10:57] <lifeless> no, uhm have you seen Jono's talk on burnout?
[10:58] <spiv> (I'm certainly about to logoff...)
[10:58] <poolie> i believe it is that time in the northern suburbs too :)
[10:58] <poolie> i am too actually
[10:58] <poolie> i'm staying on because i'm enjoying it
[10:58] <lifeless> I'm online, but doing personal stuff
[11:00] <spiv> poolie: if it's a recent regression, the traceback suggests it may be fallout from my get_rev_id_for_revno patch.
[11:01] <poolie> mm i thought so
[11:01] <spiv> In which case I'd guess cmd_diff isn't locking early enough...
[11:01] <poolie> it should go without saying you don't need to fix it tonight :)
[11:01] <poolie> i was just wondering
[11:02] <poolie> otoh launchpad seems pretty fast after the 1.16 rollout
[11:03] <LarstiQ> moin
[11:03] <spiv> Yeah, I won't fix it tonight :)
[11:03] <spiv> cmd_diff isn't exactly trivial ;)
[11:03] <spiv> Well, it is, but the helper it calls isn't...
[11:05] <spiv> G'night all :)
[11:06] <lifeless> spiv: more likely a remote.py bug
[11:06] <lifeless> unless its using --old or something
[11:06] <spiv> lifeless: maybe, either way it's my fault ;)
[11:07] <lifeless> :P just trying to aim things :)
[11:07] <lifeless> as pack_repo is very strict on locks itself
[11:11] <poolie> ok, good night
[11:25] <vxnick> hi guys - I'm getting the following error when trying to commit: bzr: ERROR: No such file: '/home/vxnick/bzr/repo_name/trunk/.bzr/branch/last-revision': [Errno 2] No such file. This happened after I had to break-lock because bzr commit was hanging
[11:26] <vxnick> this is also a remote repo
[11:26] <lifeless> you shouldn't ever need to break-lock
[11:26] <lifeless> unless bzr advises you to
[11:27] <lifeless> have a look in that directory, see if there is a last-revision.* - some sort of tem file
[11:27] <lifeless> temp
[11:27] <vxnick> yeah there is
[11:28] <vxnick> there's two - one with a prefix of tmp and one with a suffix of tmp
[11:28] <lifeless> check the datestamps
[11:28] <lifeless> and/or the contents
[11:28] <lifeless> one will will have higher revno and be newer
[11:28] <lifeless> rename that to last-revision
[11:28] <lifeless> why did you think commit had hung?
[11:29] <vxnick> I think my connection to the server was dodgy
[11:29] <vxnick> it took 6 minutes to commit a couple of lines
[11:29] <lifeless> are you using sftp ?
[11:29] <vxnick> yeah
[11:29] <lifeless> ok, that could explain it; with sftp we cannot do atomic operations so we emulate
[11:30] <vxnick> I've been looking at using the bzr server but am unsure as to how stable it is atm
[11:30] <lifeless> that should be the only oddity you'll have; if you can use bzr+ssh it will be faster and more robust
[11:30] <lifeless> we're still evolving it but as a user you shouldn't notice that.
[11:31] <vxnick> is "bzr serve" the same as SmartServer?
[11:31] <lifeless> yes
[11:31] <vxnick> thanks
[11:31] <lifeless> you can just install bzr on the server
[11:31] <lifeless> and then replace sftp with bzr in your urls
[11:31] <vxnick> I need to use ~/.bazaar/authentication.conf for the server don't I?
[11:31] <lifeless> unless you have /~/ in your url, in which case you need to change that to an absolute path
[11:31] <fullermd> ITYM "with bzr+ssh".
[11:31] <lifeless> sorry, as fullermd says, with 'bzr+ssh'
[11:32] <lifeless> vxnick: no, it uses ssh, same as sftp
[11:32] <vxnick> gotcha
[11:32] <lifeless> vxnick: there should be no need to change anything else.
[11:33] <fullermd> vxnick: The smart server actually has 3 different interfaces, but you can ignore two of them and just use bzr+ssh (no need to config anything on the server beyond having bzr installed and in $PATH)
[11:33] <vxnick> it's more efficient than using sftp right?
[11:33] <fullermd> In general, it's somewhat more efficient.  Occasionally, it's mind-zonkingly more efficient.
[11:33] <vxnick> :)
[11:35] <vxnick> lifeless: thanks for your help with the last-revision, it seems to be working now :)
[13:52] <vila> jam: Pping
[13:53] <vila> err, ping I meant
[13:58] <ddaa> Hey. Where can I read about bzr new shiny beta branch format?
[13:58] <ddaa> ("in the mind of bzr devs, Spock-style" is not an acceptable answer)
[14:16] <vila> ddaa: ML archives, doc/developers, sources :)
[14:17] <ddaa> vila: can you give me a single URL?
[14:17] <ddaa> I stopped reading the ML eons ago because I want to have other sources of informations and still do something in my day.
[14:17] <vila> ddaa: bazaar-vcs.org has docs online AFAIR
[14:21]  * LarstiQ has a look
[14:22] <LarstiQ> ddaa: http://doc.bazaar-vcs.org/latest/developers/improved_chk_index.html is not what you're looking for I suppose
[14:23] <LarstiQ> ddaa: http://doc.bazaar-vcs.org/latest/developers/development-repo.html
[14:23] <ddaa> definitely interesting, I'll put it on my reading list, but a weeeee bit too detailed.
[14:23] <LarstiQ> yes
[14:23] <LarstiQ> and the later one is a bit stingy on details
[14:24] <ddaa> the later one appearst to be a process document
[14:24] <ddaa> not a technical summary
[14:25] <LarstiQ> ddaa: sorry, at the very end
[14:25] <LarstiQ> ddaa: http://doc.bazaar-vcs.org/latest/developers/development-repo.html#format-details
[14:25] <ddaa> Right, thanks.
[14:26] <ddaa> So in summary: 1. groupcompress delta 2. CHK inventory store
[14:27] <bialix> jam: hi
[14:27] <ddaa> could use something intermediate between that and the chk_index spec :)
[14:37] <vila> ddaa: patches welcome :)
[14:37] <ddaa> I'll just wait for the bargraphs
[14:38] <ddaa> sooner or later jam will generate new ones because they are known to make Mark happy :)
[14:40] <bialix> ифкпкфзры,
[14:40] <bialix> bargraphs?
[14:52] <vila> bialix: graphics  with bars to show results (sales, performances, etc)
[14:57] <bialix> sales... sounds good
[15:03] <LarstiQ> bialix: the ones jam makes are usually about performance :)
[15:03] <jam> hi bialix, ddaa
[15:04] <bialix> jam: hi
[15:04] <jam> ddaa: http://jam-bazaar.blogspot.com/2009/03/brisbane-core.html ?
[15:04] <ddaa> jam: hi
[15:04] <bialix> LarstiQ: vila knows better ;-) I guess
[15:04] <jam> vila: pong
[15:04] <ddaa> jam: thanks, readitlatered
[15:06] <bialix> jam: I think the size of imageplugins could be dramatically reduced
[15:06] <bialix> I'm just not sure how to write the support for bundling them into bzr.exe
[15:06] <bialix> what version of PyQt4 you have installed on your build machine?
[15:06] <vila> jam: The needds fixing was about gdfo to be declared as long right ?
[15:07] <vila> jam: auddenly I had a doubt about 'Needs Fixing' == 'tweak'
[15:07] <jam> vila: and generally pyrex improvements
[15:07] <jam> vila: which I was willing to work on before we land
[15:07] <vila> ha, so I don't submit then ?
[15:07] <jam> I have no idea what is "tweak" versus what is "resubmit"
[15:08] <jam> bialix: I'll check
[15:08] <vila> jam: resubmit exists as such...
[15:10] <jam> vila: resubmit actually *resubmits* the request
[15:10] <jam> as in, start a new merge request
[15:10] <jam> not, "come back later with a new one"
[15:10] <jam> more "I updated my branch, here is a resubmitted version"
[15:10] <jam> bialix: py -c "import PyQt4.QtCore; print PyQt4.QtCore.qVersion()" gives
[15:11] <jam> '4.4.1'
[15:13] <bialix> thx
[15:14] <abentley> jam, there's a bug in reconcile that's affecting mars.  Any chance you can take a look at it? https://pastebin.canonical.com/18735/
[15:15] <jam> abentley: I think that is the wrong paste
[15:15] <jam> that is a 'bzr info' one
[15:15] <abentley> jam: Sorry, it's a bit hectic in #launchpad-code today.  https://pastebin.canonical.com/18733/
[15:16] <abentley> jam: We upgraded to the 2a format overnight.
[15:16] <jam> ah
[15:17] <jam> abentley: .... the traceback makes no sense
[15:17] <jam> build_details is a dict
[15:17] <jam> but "iteritems" is just a method
[15:17] <abentley> jam: could it be a mismatch between the .py and the .pyc?
[15:17] <jam> abentley: possibly
[15:18] <jam> certainly _get_components_positions() is used all the time
[15:18] <jam> and not just for reconcile
[15:18] <jam> I wonder if there might be a bug in the compiled extensions.
[15:18] <jam> He might try without them
[15:18] <jam> (at least that random of an error makes me wonder about random memory corruption.)
[15:26] <mars> hi jam
[15:26] <mars> jam, would you be able to tell me how I would go about running bzr without the extensions?
[15:43] <jam> mars: well, the easiest is to grab a tarball of bzr, extract it into a folder
[15:43] <jam> and then run from there
[15:44] <jam> without running 'make' first
[15:44] <jam> https://edge.launchpad.net/bzr/1.16/1.16
[15:44] <jam> you can just do "~/path/to/bzr reconcile"
[15:44] <jam> (we support running directly from the source tree)
[15:44] <jam> sorry, I'll be a bit in and out for the next couple of hours
[15:45] <mars> jam, ok, I'll give that a try
[15:46] <vila> jam: if you intend to work on it, be sure to grab the latest from lp:~vila/bzr/gdfo-heads/
[15:46] <jam> mars: As an added bonus, that makes it easier for us to tweak things and see what works
[15:46] <jam> if it *does* work that way
[15:46] <jam> then try running "make"
[15:46] <jam> mars: (first copy your repo)
[15:46] <jam> and see if "bzr reconcile" breaks after "make"
[15:47] <jam> (well, "~/path/to/bzr")
[15:47] <mars> right
[15:56] <vila> Oook ?
[15:57] <vila> abentley:     from bzrlib.plugins.bzrtools.tests import test_fetch_ghosts
[15:57] <vila> ImportError: cannot import name test_fetch_ghosts
[15:57] <vila> abentley: I was so sure you fixed that 8-/
[15:58] <abentley> vila: Should be there as of revno 709
[15:58] <mars> abentley, before running the bzr reconcile, should I reset the repository state?  Perhaps by copying backup.bzr to .bzr, or something similar?
[15:58] <vila> 715...
[16:00] <abentley> mars: I'm not clear whether reconcile creates backup.bzr
[16:00] <vila> abentley: eeerk ! system-wide plugin ! Sorry for the noise
[16:00] <mars> abentley, ah, right, it could have been the 1.6 upgrade
[16:00] <abentley> vila: np
[16:42] <visik7> hi
[16:42] <visik7> a question
[16:43] <visik7> if A commit to revision 1 than B commit to revision 2 than A modify a file and update to rev 2
[16:43] <visik7> does the file get a conflict ?
[16:45] <mars> hmm.  if bzr reconcile runs the disk out of space, it doesn't clean up after itself after aborting, thus cleaning up the space it used :(
[16:47] <luks> visik7: that depends on the changes
[16:48] <visik7> luks: in which sense ?
[16:48] <luks> visik7: they might conflict or not :)
[16:48] <luks> if they change the same code in a different way, it will report a conflict
[16:49] <luks> but if they change e.g. different function, it will not
[16:53] <visik7> no wait
[16:53] <visik7> A put a revision 1
[16:53] <visik7> with 2 files
[16:54] <visik7> for example with main.c and functions.c
[16:54] <visik7> B commit rev 2
[16:54] <visik7> modifying file function.c
[16:54] <visik7> now A modify main.c
[16:54] <visik7> and before commit he run an update
[16:55] <visik7> the conflict should not happen, right ?
[16:55] <luks> right
[16:57] <visik7> ok now I'm going to check why it had happen
[17:05] <mars> abentley, found a new bzr reconcile issue using the tarball, san-extensions, as jam suggested: SHA1KnitCorrupt: https://pastebin.canonical.com/18752/
[17:07] <abentley> mars: I'm not sure what to do about that.
[17:08] <jam> abentley: given that this is an inventory, and that it is mismatching the raw content, I'm guessing its our old friend
[17:08] <jam> inventories not consistent with inconsistent ghosts
[17:08] <jam> it is also failing on the Knit side
[17:09] <jam> not the GC side
[17:09] <jam> certainly that is a different error, but I don't understand why you would ever be getting the first one
[17:09] <jam> hmm... maybe in an exception clause, let me check
[18:33] <flacoste> I'm trying to move a LP branch from my old repo to a 2a repo
[18:33] <flacoste> and i get this error:
[18:33] <flacoste> KnitCorrupt: Knit <bzrlib.groupcompress._GCGraphIndex object at 0x7f925da0e510> corrupt: inconsistent details in add_records: ('53507751 66036 91238 118445', ((('01creation.txt-20071122132843-ajpxh023ndwrzebk-2', 'kiko@canonical.com-20080801032521-84uzp66nlpu511ur'), ('01creation.txt-20071122132843-ajpxh023ndwrzebk-2', 'abel.deuring@canonical.com-20090612090543-dz2kjihx7jnbj0f6')),)) ('65<PHONE_NUMBER>183 1707390', ((('01creation.txt-
[18:33] <flacoste><PHONE_NUMBER>2843-ajpxh023ndwrzebk-2', 'abel.deuring@canonical.com-20090612090543-dz2kjihx7jnbj0f6'),),))
[18:34] <flacoste> i did run bzr reconcile in the old repo beforehand
[18:43] <jam> flacoste: weird. for the file "01creation.txt" in a given revision
[18:43] <jam> one side claims 2 parents
[18:43] <jam> the other side claims only a single parent
[18:44] <jam> both claim "abel.deuring..." but the first claims<EMAIL_ADDRESS>[18:44] <flacoste> unfortunately, i have no idea on why this is happening
[18:44] <jam> so... you *do* have inconsistent information for that entry... but I couldn't tell you why
[18:44] <jfroy> jelmer: thanks for the two bug fixes
[18:44] <flacoste> jam: anything i can do about it?
[18:44] <jam> flacoste: well, other than cry?
[18:44] <flacoste> jam: or should I just recreate a new branch and apply a diff?
[18:45] <flacoste> ok!
[18:45] <jam> flacoste: how big is the branch?
[18:45] <jam> how important?
[18:45] <flacoste> it's trivial to recreat
[18:45] <jam> We can try, but it would take time and effort
[18:45] <flacoste> e
[18:45] <flacoste> not even a 100 lines
[18:45] <flacoste> i'm reporting it more as part of the dogfood effort
[18:45] <flacoste> and making it a super experience for everyone else
[18:46] <flacoste> i think it points either to a bug in reconcile
[18:46] <flacoste> or in the uprade to 2a
[19:33] <jelmer> jfroy: can you still reproduce bug 269669?
[19:34] <jfroy> jelmer: I have not seen that bug again
[19:34] <jfroy> I doubt I can reproduce it either.
[19:34] <jfroy> Closing as invalid.
[19:34] <jelmer> jfroy: thanks
[19:35] <jfroy> For the record, Invalid is a lame status :p
[19:35] <jfroy> I'd prefer "No to be fixed" or "Works as designed™"
[19:35] <bialix> jelmer: did you saw bzr-svn test.log @ win32?
[19:36] <jelmer> bialix: no, where was that?
[19:37] <bialix> yesterday
[19:37] <bialix> http://permalink.gmane.org/gmane.comp.version-control.bazaar-ng.general/59156
[19:37] <jelmer> bialix: thanks
[19:38] <bialix> maybe you need to persuade jam to get tdb bundled into bzr.exe
[19:39] <jelmer> I doubt it builds on windows
[19:40] <bialix> ah
[20:13] <johnjosephbachir> how do i view the differences between my local committed code, and the code in the remote repo to which i push?
[20:14] <beuno> johnjosephbachir, I use:  bzr send REMOTE_BRANCH -o review.diff
[20:14] <johnjosephbachir> beuno: muy bueno, thanks, i'll read the docs on send and the -o flag
[20:15] <dash> hm, i think the other way is "bzr diff -rsubmit:"
[20:21] <bialix> bzr diff -rbranch::push
[20:22] <dash> hah, ok. I didn't know about :push
[20:23] <bialix> there is a few of them
[20:23] <bialix> :parent, :submit
[20:23] <bialix> I'm not sure where these aliases actually documented
[20:24] <bialix> but I'd stick to beuno reciepe
[20:25] <fullermd> I'm pretty sure they're not.
[20:25] <jskulski> hey I'm using bzr-svn to work with a svn repository (initially i bzr branch file://var/svn..) now I am trying to get updates from that repository, bzr update says i am updated, bzr pull and merge fail saying I have uncommited changes
[20:26] <jskulski> can anyone give me some direction
[20:26] <dash> 'bzr update' just makes sure your working tree is in sync with your local branch
[20:27] <bialix> look what `bzr status` says
[20:27] <dash> jskulski: you can't bring in new changes from a remote branch (your svn repo) if you have uncommited changes to your working copy
[20:27] <Tak> what? since when?
[20:27] <dash> jskulski: what I usually do in that case is 'bzr shelve' if it's changes I want to keep
[20:27] <jskulski> dash is that just part of the bzr workflow? (I am new to bzr and DVCS in generall)
[20:27] <jskulski> bialix i have a few unknown files and one modified
[20:27] <bialix> dash: I think pull should work even if you have uncommitted changes
[20:27] <dash> jskulski: yes
[20:28] <bialix> try bzr pull
[20:28] <bialix> bzr pull ~= svn update
[20:28] <Tak> pull Works For Me when I have uncommitted changes - I do this all the time
[20:28] <dash> oh, true. pull works
[20:28] <dash> i got confused :)
[20:28] <jskulski> i get
[20:28] <jskulski> bzr: ERROR: These branches have diverged. Use the merge command to reconcile them.
[20:29] <bialix> I suspect this
[20:29] <dash> right. so in that case you _do_ need to shelve or commit (or revert) your changes until the merge is done
[20:29] <bialix> you can bzr merge --force
[20:29] <bialix> but better if you to do as dash said
[20:30] <Tak> if you commit changes, you'll still have to merge
[20:30] <dash> well. no matter what you'd still have to merge
[20:30] <bialix> jskulski: you can compare 2 branches with `bzr missing` and you'll see what the difference in histories
[20:31] <jskulski> yaya
[20:31] <bialix> naturlich
[20:32] <jskulski> i shelved my changes and bzr merged, it pulled it changes, and unshelved
[20:32] <jskulski> thanks bialix Tak dash
[20:32] <jskulski> !
[20:32] <dash> <3
[20:32] <bialix> it was easy
[20:33] <jskulski> yeah
[20:33] <bialix> dash: what it means? (<3)
[20:33] <jskulski> <3
[20:35] <bialix> interesting...
[20:36] <dash> bialix: it is supposed to be a heart shape.
[20:37] <bialix> and?
[20:39] <bialix> igc made incredible work with bzr explorer
[20:44] <jfroy_> jelmer: do you foresee problems with doing uncommits?
[20:44] <jfroy_> on a local branch of a svn branch
[20:44] <fullermd> bialix: Oh, BTW, since I got my new workstation up, I finally got to try out qlog.  Pretty nifty.
[20:45] <bialix> fullermd: kudos to garyvdm
[20:46] <fullermd> I did come across one or two wishlist items...
[20:47] <bialix> about?
[20:48] <fullermd> I'd like to be able to 'expand all' on the merge revs.
[20:48] <bialix> yep, sometimes me too
[20:49] <fullermd> And maybe set the diff window to default to unidiff mode rather than SxS.
[20:49] <bialix> you can send your feedback to qbzr ml, or file a bugs
[20:49] <bialix> qdiff should be controlled via command-line options
[20:50] <bialix> or you talking about invoking qdiff from qlog?
[20:50] <fullermd> From qlog, yah.
[20:50] <bialix> yep
[20:51] <bialix> bug a file
[20:52] <johnjosephbachir> how can i see the results of bzr revert?
[20:52] <beuno> johnjosephbachir, bzr diff
[20:52] <johnjosephbachir> beuno: okay, i'll check that out... but what about, just simply obvserving the basic state of my repo?
[20:52] <johnjosephbachir> i.e., what i have reverted back to?
[20:53] <bialix> bzr cat?
[20:53] <johnjosephbachir> haha
[20:53] <dash> 'bzr log -l1' maybe
[20:54] <johnjosephbachir> dash: exactly-- that does NOT change after i run revert
[20:54] <dash> not sure i understand the question
[20:54] <bialix> johnjosephbachir: your question is also haha
[20:54] <fullermd> johnjosephbachir: revert doesn't change anything in the branch/repo; it only affects your working tree.
[20:54] <dash> yeah i was just thuinking that
[20:54] <dash> thinking
[20:54] <fullermd> So it would never affect log or like commands.
[20:55] <johnjosephbachir> okay
[20:56] <johnjosephbachir> bzr diff has no output.
[20:57] <bialix> anybody knows how can I made good looking screenshot page at http://bazaar-vcs.org/BzrExplorer/Screenshots?
[20:57] <bialix> for some reason moin stretch the images
[20:58] <johnjosephbachir> bialix: when you suggested cat, i was hahaing my own ineptness at presenting my question
[20:59] <johnjosephbachir> fullermd: after i run revert, how can i then observe the changes that it made to my working tree?
[20:59] <bialix> if you revert then you lost your changes
[20:59] <Tak> bzr time-machine?
[21:00] <dash> johnjosephbachir: are you talking about 'bzr revert -r somerev'?
[21:00] <johnjosephbachir> dash: i thought revert went back a changeset at a time with each invocation
[21:00] <dash> no
[21:00] <fullermd> Well, it'll [under some circumstances] make backups of the files it changes named like $FILE.~1~.  That's not necessarily reliable across multiple reverts though, and it doesn't tell you anything about renames etc. that it reverted.
[21:01] <johnjosephbachir> Tak: lol
[21:01] <dash> johnjosephbachir: with no args, revert just removes existing differences with the branch tip from the WC
[21:02] <johnjosephbachir> dash: Oh. Okay. That sounds very subversion-like. for some reason i thought it was different. so revert is still the best way to roll back changesets, right? (with the -r flag)
[21:03] <bialix> no, you need uncommit for this
[21:03] <fullermd> I think a much more precise definition of "roll back changesets" is needed to answer that...
[21:03] <dash> yeah, this is different from svn, 'bzr revert -r X' is equivalent to 'svn up -r X'
[21:03] <johnjosephbachir> bialix: fullermd: dash: okay, that clears everything up -- thank you!
[21:04] <fullermd> Not exactly it's not...
[21:04] <dash> so if you want to create a new revision that undoes the changes of a previous one, sure. 'bzr revert -r X', 'bzr ci'
[21:04]  * bialix nods
[21:04] <dash> fullermd: i should have said "analagous to"
[21:04] <dash> since bzr and svn are obviously different. :)
[21:05] <johnjosephbachir> bialix: yeah i was thinking of uncommit dash: right, so that is the svn way, but uncommit is the bzr way (more or less)
[21:05] <dash> johnjosephbachir: eeeeh
[21:05] <fullermd> But that doesn't undo [X+1], it commits the state exactly as of X.  So it would undo _any_ changes you made post-X, not just those in [X+1].
[21:05] <dash> johnjosephbachir: uncommit actually removes commits from your branch
[21:05] <johnjosephbachir> dash: yep, that's what i want in this case.
[21:06] <dash> johnjosephbachir: the main use case for that is when you check stuff in, and befor you push, realize you made a mistake
[21:06] <johnjosephbachir> yeah
[21:06] <johnjosephbachir> exactamente
[21:06] <dash> if you've already shared this revision with other people, it's often a good idea to not do that. :)
[21:07] <Tak> hmm, if you uncommit, it tells you the branches diverged when you try to push, doesn't it?
[21:07] <dash> Tak: if you uncommit stuff that's in the remote branch, yes
[21:08] <bialix> push --overwrite can do magic
[21:08] <dash> "do magic" means "break things" ;-)
[21:10]  * fullermd grabs a Dremel and does magic.
[21:10] <bialix> rats
[21:10] <bialix> this moinmoin made me crazy
[21:12] <bialix> what's wrong with my png?
[21:13] <bialix> pheww
[21:13] <bialix> firefox increase images
[21:15] <johnjosephbachir> grrr. my ports system doesn't have bzrtools up to date for my version of bzr
[21:16] <johnjosephbachir> so i can't use clean-tree
[21:17] <fullermd> Which ports system?
[21:17] <bialix> install by hands, no?
[21:17] <johnjosephbachir> macports
[21:17] <fullermd> What versions does it have?
[21:18] <johnjosephbachir> bzr 1.15, bzrtools 1.13
[21:19] <johnjosephbachir> i'm installing from source now... does the main source distribution have bzrtools or do i have to install that separately?
[21:20] <fullermd> Well, the quick short solution would be to grab the bzrtools 1.15 tarball and stick it in your ~/.bazaar/plugins/.
[21:20] <fullermd> That saves you from doing any system-wide screwing around.
[21:21]  * fullermd grumbles at the wiki.
[21:21] <johnjosephbachir> fullermd: ah okay-- fantastic
[21:22] <johnjosephbachir> fullermd: worked perfectly, thank you so much, you saved me 30 minutes of pain
[21:23] <fullermd> You'll get my bill in the mail   ;)
[22:08] <johnjosephbachir> bzr is throwing an exception when i try to unshelve something... is there any way i can save my shelved changes?
[22:09] <dash> they're in .bzr/checkout/shelf
[22:11] <johnjosephbachir> yay
[22:11] <dash> what's the exception?
[22:11] <johnjosephbachir> https://bugs.launchpad.net/bzr/+bug/389674
[22:13] <dash> Oh dang
[22:13] <dash> that's not happy
[23:42] <mwhudson> jelmer: hi, do you know anything about this failure? https://code.edge.launchpad.net/~vcs-imports/mnemosyne-proj/maemosyne
[23:54] <lifeless> wow, odd to have maemosyne in git... mnemosyne is bzr


[13:02] <sarnold> mir meeting? :)
[13:05]  * didrocks is around
[13:06] <didrocks> but part of the team is in a sprint, so unsure
[13:06] <sarnold> yeah, I figured that was a possibility :) hehe


[00:10] <robru> why :sobs:
[08:29] <popey> sil2100: would you mind if I added to https://wiki.ubuntu.com/Touch/ReleaseNotes/OTA-11 "Wireless display support (aethercast)"  the text " - turbo [Meizu Pro 5] only for now"  ?
[08:35] <popey> sil2100: also, I heard we were going to land aethercast in the M10, but that hasn't happened for OTA-11, right? (cc morphis)
[08:35] <morphis> popey: yes
[08:35] <morphis> popey: its planed for OTA 12
[08:35] <popey> ok
[08:35] <morphis> popey: but it could be that you can enable it manually
[08:36] <morphis> abeato: did you merge all changes for aethercast on M10 into OTA 11 on the device tarball side?
[08:36] <popey> morphis: how? from the command line?
[08:37] <morphis> popey: yes
[08:37] <popey> i have rc-proposed on my m10 and the system settings option doesn't allow wireless display
[08:37] <Saviq> popey, aethercastctl in terminal
[08:37] <morphis> popey: setprop ubuntu.widi.supported 1
[08:37] <Saviq> or that ;)
[08:37] <morphis> and restart settings
[08:38] <morphis> popey: or yeah, aethercastctl on the terminal is a way too :-)
[08:38] <morphis> popey: but its not very stable if it works
[08:38] <morphis> also a lot slower than on turbo
[08:38] <abeato> morphis, all there, but I reverted the property used to show the option in system settings
[08:39] <morphis> abeato: ok
[08:39] <popey> ok
[08:39] <morphis> popey: do you already saw my answer on https://bugs.launchpad.net/aethercast/+bug/1585534 ?
[08:40] <popey> morphis: yeah, will try and reproduce later today and gather that data
[08:40] <morphis> popey: thanks
[08:41] <popey> do i have to run aethercastctl as root?
[08:42] <popey> "Failed to scan:GDBus.Error.org.aethercast.Error.NotReady: Not ready" morphis
[08:42] <morphis> popey: no, as normal user
[08:42] <morphis> but "enable" first
[08:43] <popey> oh
[10:20] <Saviq> sil2100, hey, did you see bug #1586541 ? looks like the lttng backport wasn't complete
[10:28] <sil2100> Saviq: hey! I'll take a look, I basically only backported the upstream version of ust - I guess we need to port a bit more
[10:28] <Saviq> sil2100, yeah, packaging could use some love it seems
[10:29] <sil2100> I guess it's as tsdgeos mentioned, ltt-control needs back-porting as well, this could have been a bit more obvious that the two are no longer compatible
[11:01] <Saviq> trainguards, can you please add cimi to ~ci-train-users? thanks
[11:01] <Mirv> Saviq: ok
[11:01] <Mirv> Saviq: he is already
[11:01] <Saviq> Mirv, oh
[11:02] <Mirv> Saviq: since Feb
[11:02]  * Saviq couldn't find him
[11:02] <Mirv> https://launchpad.net/~ci-train-users/+members
[11:02] <Saviq> cimi, you can make a silo yourself, then
[11:02] <Saviq> Mirv, yes, sorry, my eyes playing tricks on me
[15:10] <dbarth> rvr: i approved the merge proposals that were blocking those 2 silos
[15:12] <rvr> dbarth: Great, unblocking
[15:44] <kdub> so, for the mir landing (silo 69), should I switch to triple landing? or still xenial + v-o?
[15:51] <Saviq> kdub, yes, everything should triple-land by now
[15:52] <Saviq> rvr, hey, any update on the unity8 landing?
[15:53] <kdub> Saviq, thanks, will transition to triple landing
[15:53] <rvr> Saviq: Testing :)
[15:54] <Saviq> rvr, ack :)
[16:38] <rvr> ltinkl: ping
[16:59] <ltinkl> rvr, pong
[17:00] <rvr> ltinkl: Hi
[17:00] <rvr> ltinkl: I'm checking https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1581498
[17:00] <ltinkl> rvr, yup, any prob?
[17:00] <rvr> ltinkl: Do you know how can those notifications be triggered from command line?
[17:01] <ltinkl> rvr, hmmpf, maybe there's a way, but I tested with the SIM PIN unlock screen + USB debugging prompt
[17:03] <Saviq> rvr, you can install python-notify and use those examples https://bazaar.launchpad.net/~unity-api-team/unity-notifications/trunk/files/head:/examples/
[17:03] <Saviq> ltinkl, for reference ↑
[17:04] <ltinkl> Saviq, rvr: yup, and using UT Tweak Tool from Open Store, you can re-enable the USB debugging promtp
[17:05] <ltinkl> rvr, Tweak Tool -> System -> ADB settings
[17:05] <rvr> ltinkl: Let me see
[17:15] <rvr> ltinkl: Thanks, UT Tweak did the trick
[17:17] <ltinkl> rvr, when testing the fullscreen notifications (actually just the SIM PIN dialog), you should see the other (USB) notification go under it
[17:19] <rvr> ltinkl: Yeah, I can't see the USB dialog
[17:19] <ltinkl> rvr, you should see it once you dismiss the SIM dialog
[17:19] <rvr> ltinkl: Right
[17:19] <ltinkl> rvr, good :)
[17:19] <rvr> I took a look to the screenshots, and seemed fixed :)
[18:42] <Saviq> rvr, so no verdict on unity8 silo today?
[21:07] <robru> yep, get your builds done now, train is going offline at UTC 1, that's 4 hours from now, for a big rollout.
[21:15]  * mterry hugs robru for comment support
[21:28] <Saviq> robru, looks like the train should look at response code... https://requests.ci-train.ubuntu.com/#/ticket/1426
[21:29] <robru> Saviq: it is correctly noticing the http request has failed and is saving the error message to the ticket, the issue is just that it's a big html dump in a text field. I'll have to clean that up
[21:31] <Saviq> robru, right, I meant that maybe it should ignore the err and just say that it was 503
[21:31] <Saviq> ?
[21:32] <robru> Saviq: yeah. Can you file a bug? I'm gearing up for a huge rollout
[21:33] <Saviq> robru, ack, doing
[21:34] <robru> Saviq: thanks
[21:36] <Saviq> robru, bug #1587651
[21:36] <robru> Thanks


[07:31] <CIA-6> ubiquity: superm1 * r3637 ubiquity/ (bin/ubiquity-wrapper debian/changelog):
[07:31] <CIA-6> ubiquity: Only run hal-lock if hald is actually running due to changes in
[07:31] <CIA-6> ubiquity: hal 0.5.14-0ubuntu2.
[09:35] <CIA-6> ubiquity: superm1 * r3638 ubiquity/ (debian/changelog ubiquity/frontend/gtk_ui.py):
[09:35] <CIA-6> ubiquity: Widget names are no longer stored in the widget's internal name, but
[09:35] <CIA-6> ubiquity: rather in the object data. Sync this information back to the widget's
[09:35] <CIA-6> ubiquity: internal name. (LP: #503710)
[09:36] <CIA-6> ubiquity: superm1 * r3639 ubiquity/ (d-i/manifest debian/changelog):
[09:36] <CIA-6> ubiquity: Automatic update of included source packages: grub-installer
[09:36] <CIA-6> ubiquity: 1.49ubuntu1.
[09:37] <CIA-6> ubiquity: superm1 * r3640 ubiquity/debian/changelog: releasing version 2.1.7
[17:22] <davmor2> cjwatson: you about?
[17:33] <davmor2> cjwatson: I'm getting a bug with ubiquity crashing bug 503885
[17:34] <davmor2> unprivatised it for you
[17:35] <superm1> davmor2, i think that's the same thing i fixed last night
[17:35] <superm1> in ubiquity 2.1.7 it should be fine
[17:36] <davmor2> superm1: Cool I'll just check the version on the cd
[17:36] <superm1> see bug 503710 for more info
[17:36] <charlie-tca> superm1: Will that be in tomorrows image?
[17:37] <charlie-tca> Xubuntu has the same error
[17:37] <superm1> charlie-tca, should be in the next image generated yes
[17:37] <superm1> charlie-tca, are you seeing something weird in the xubuntu where the xfce-panel is it's own window too?
[17:37] <superm1> if you boot into the live env mode ((not directly ubiquity install mode))
[17:38] <charlie-tca> yes, both top and bottom panels. It is reported on bug 503633
[17:38] <charlie-tca> I still can't install from live environment
[17:39] <charlie-tca> The panel thing started yesterday
[17:39] <superm1> yup
[17:39] <superm1> i'm not sure what the delta that caused it yet is though
[17:39] <superm1> charlie-tca, to install from the live env, update ubiquity to 2.1.7 (it's on the repos)
[17:40] <charlie-tca> The other one is the Xfce4-power-manager pop-up
[17:40] <charlie-tca> okay
[17:40] <superm1> http://pastebin.com/f67f07fb2 that was the delta between mythbuntu disks between when the panel started showing like that
[17:41] <superm1> so i'd probably blame it on the new gtk+ upload if anything
[17:41] <charlie-tca> That's what I think, but what do I know ;-)
[17:41] <davmor2> superm1: 2.1.6 is still on the cd so I'm assuming it will get picked up tomorrow
[17:42] <superm1> davmor2, yeah those CDs must have been built before the new one published
[17:43] <charlie-tca> yup
[17:43] <charlie-tca> I ran updates, logout login, ubiquity works
[17:44] <charlie-tca> Thanks, superm1
[17:44] <superm1> cool, good
[17:44] <superm1> looks like that panel thing should be fixed in the next xfce4-panel version: http://bugzilla.xfce.org/show_bug.cgi?id=6117
[17:45] <charlie-tca> Hopefully that is not too far out
[17:47] <superm1> oh nice, the new version is actually already in debian
[17:47] <superm1> someone just needs to go and merge it
[17:52] <cjwatson> davmor2: sorry, swamped
[17:52] <cjwatson> but glad to see superm1 reckons it's fixed
[17:53] <davmor2> cjwatson: no probs sorted now :)
[17:53] <davmor2> will try again tomorrow :)
[17:53] <charlie-tca> I have ubiquity running an install from the live desktop after updating
[18:15] <CIA-6> ubiquity: evand * r3641 trunk/ (3 files in 3 dirs):
[18:15] <CIA-6> ubiquity: On the timezone page, replace the GTK Comboboxes with ComboboxEntrys and
[18:15] <CIA-6> ubiquity: add support for typeahead by country/region and city.
[18:22] <CIA-6> ubiquity: evand * r3642 trunk/ubiquity/components/ubi-timezone.py: Slight improvement on previous commit. Automatically select an entry if the user types the full city name.
[22:17] <CIA-6> usb-creator: superm1 * r255 usb-creator/ (debian/changelog usbcreator/frontends/gtk/frontend.py):
[22:17] <CIA-6> usb-creator: Widget names are no longer stored in the widget's internal name, but
[22:17] <CIA-6> usb-creator: rather in the object data. Sync this information back to the widget's
[22:17] <CIA-6> usb-creator: internal name. (LP: #503710)
[22:18] <superm1> ev, you'll probably want to do a new release of usbcreator for that ^, otherwise it'll be quite broken
[22:19] <TheMuso> /c/c
[22:24] <ev> superm1: ah, awesome.  Thanks!
[22:25] <superm1> np
[22:37] <CIA-6> usb-creator: evand * r256 trunk/debian/changelog: releasing version 0.2.14