[14:48] <hjd> Any opinions on whether to reopen bug 965272 or if I should simply file a new bug?
[15:22] <da3m0n22> hello, anybody could review this bug please? https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1273261
[15:23] <da3m0n22> after being confirmed, we fell into this issue too, and i'm unable to fix that, if anybody knows workaround, it isn't posted there
[15:23] <da3m0n22> and i haven't found it either
[15:24] <penguin42> da3m0n22: Does it dump you at an initramfs prompt?
[15:25] <da3m0n22> penguin42: nope, it dumps core
[15:26] <penguin42> da3m0n22: What do you actually mean by dumps core?
[15:27] <da3m0n22> kernel panic, with core dumped error message
[15:27] <penguin42> da3m0n22: Can you get a capture of that - photo ?
[15:28] <penguin42> da3m0n22: I'm wondering what dumped; it sounds like init perhaps
[15:29] <da3m0n22> penguin42: yes, it's init dumped, showing lines of "plymouth-upstart-bridge--started terminated with status 6", "error.c:219 Assertion failed in _nih_error_raise_system: errno > 0"
[15:29] <da3m0n22> and "Error whie reading from descriptor: Bad file descriptor"
[15:30] <da3m0n22> penguin42: see images, https://plus.google.com/photos/115401880503838928078/albums/6066739816541481313?banner=pwa
[15:31] <da3m0n22> first is core dump, it's scrolled too far down, if i append "recovery" into boot params, it won't scroll so far
[15:31] <da3m0n22> second appears to be the same issue as in linked bug
[15:32] <da3m0n22> azur is volume group, root is partition
[15:32] <da3m0n22> penguin42: ^
[15:33] <da3m0n22> it's root filesystem, encrypted, which is game stopper for now
[15:33] <penguin42> da3m0n22: I've marked that bug 'high' - are you sure it's the same bug though
[15:33] <da3m0n22> it appears from second image
[15:33] <penguin42> da3m0n22: Their initial report doesn't mention the cores
[15:34] <da3m0n22> penguin42: honestly, it may be another issue than which we are facing
[15:35] <penguin42> da3m0n22: Can you post yours as a new bug, and file it against plymouth
[15:36] <penguin42> da3m0n22: Mention that other bug in the message, and tell us the bug number and I'll also mark it high
[15:37] <da3m0n22> penguin42: i'll do, thanks
[15:37] <penguin42> da3m0n22: The thing is anything that causes the decryption/lvm setup to fail will probably get you a similar error about not finding the /dev entry - but those abort's are better diagnosis for a particular cause
[15:37] <da3m0n22> penguin42: from what you see, do you think there is something which could be done now?
[15:37] <da3m0n22> i've been into rescue, volume mounts correctly, tried update-initramfs which didn't helped
[15:38] <penguin42> da3m0n22: It's hard; most of the time when these thing screw up they drop you to an initramfs and you can manually recover, but it looks like that's crashing
[15:38] <penguin42> da3m0n22: I'd try disabling the graphical boot
[15:38] <da3m0n22> yup, i've tried to add sh/ash into scripts/cryptsetup but that only screwes up the booting screen
[15:38] <penguin42> da3m0n22: See if you can remove plymouth?
[15:39] <da3m0n22> penguin42: i could probably, will test in a minute
[15:43] <da3m0n22> penguin42: oh, actually this lead me to this, https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1294284
[15:43] <da3m0n22> we also have 14.04 box
[15:45] <da3m0n22> is it possible for AppArmor to interfere in initrd creation ?
[15:45] <penguin42> A screwed up AppArmor could break anything - but I've not seen it break initrd
[15:46] <penguin42> da3m0n22: Just checking, your /boot isn't full is it?
[15:47]  * penguin42 gets confused between High: 'For example if the system fails to boot' and  Critical: 'Renders the system temporarily or permanently unusable'
[15:47] <penguin42> but I tend to leave critical to bugs that actually corrupt data or emit smoke
[15:48] <da3m0n22> penguin42: /boot is 68% full, leaving 146M free
[15:49] <penguin42> da3m0n22: OK, probably not that; I often see /boot get full during updates and cause complete chaos creating the initramfs
[15:49] <da3m0n22> also, aptitude from recovery reports segfault
[15:50] <penguin42> that's also not good; I'm wondering if you've got any other problems
[15:51] <da3m0n22> penguin42: me too, colleague who suffers from this issue is trying to remove the plymouth/apparmor
[15:51] <penguin42> da3m0n22: I'd advise against removing any of the apparmor stuff
[15:52] <da3m0n22> penguin42: even with backups?
[15:53] <penguin42> da3m0n22: It just sounds like it'll create more pain
[15:56] <da3m0n22> penguin42: plymouth is not easy to be removed, some conflicts appear with xorg, nvidia and udev
[15:56] <penguin42> hmm ok


[00:00] <igc> lifeless: well done!
[00:01] <igc> lifeless: I'll review that other patch this morning
[00:01] <igc> morning all
[00:01] <jml> good morning.
[00:03] <faceprint> I've got what is probably a dumb question, but I haven't been able to find an answer in any online docs or mailing list archives.  Is there a way to put a setting into branch.conf, commit it (or something to that effect) so it is shared?
[00:04] <james_w> thanks for releasing 1.17 jml
[00:05] <lifeless> faceprint: not currently
[00:10] <garyvdm> faceprint: you can push it some where that is shared though. What do you want to do exactly?
[00:12] <faceprint> i've written a plugin, and I want to put some settings for it into branch.conf so the entire team doesn't have to manually keep settings in sync
[00:13] <garyvdm> Ok - Now I understand. Sorry - can
[00:13] <garyvdm> 't help
[00:14] <lifeless> faceprint: you could have your plugin read from the tree
[00:21] <jml> james_w, my pleasure.
[00:31] <poolie> hi igc
[00:31] <igc> hi poolie
[00:31] <jml> can I set a submit branch without editing locations.conf?
[00:32] <poolie> jml, i don't think so
[00:32] <poolie> sending mail for a new rm
[00:33] <jml> thanks.
[00:34] <poolie> thanks jml, it's been good
[00:34] <Raim> jml: bzr send --remember? but probably not what you were looking for...
[00:35] <jml> Raim, it's pretty close actually, if I tack on a --no-bundle and -o-
[00:36] <jml> hmm. I get a warning about masked values.
[00:37]  * jml sets this problem aside
[00:40] <poolie> jml, our 4w schedule would have 2.0rc1 on 6 August and the final on the 13th
[00:41] <poolie> any comments on how that fits with lp rollout?
[00:42]  * jml checks out the calendar
[00:42] <mwhudson> launchpad isn't going to rollout in august most likely
[00:43] <jml> Next roll-out after 2.2.7 is 2.2.9 on Sept 23rd. Someone's going to announce this properly on the blog soon.
[00:43] <poolie> mm i saw that
[00:43] <poolie> well, let's say not 'rollout' in particular, but lp's development cycle in general
[00:44] <jml> poolie, a bzr upgrade is going to have to be special-cased no matter when it is.
[00:44] <jml> poolie, so, those dates are just fine.
[00:44] <poolie> k thanks
[00:45] <poolie> you know some people at canonical would not have said the second sentence and would have just left me wondering :)
[00:46] <jml> poolie, well, in this case I was figuring it out as I went along. the idiosyncrasies of a synchronous medium, don't you know?
[01:24] <lifeless> http://paste.ubuntu.com/223141/
[01:24] <lifeless> poolie: ^
[01:24] <lifeless> I'm about to ring to double check this
[01:24] <lifeless> and talk about the other stuff you msged me
[01:24] <poolie> to ring me
[01:24]  * poolie braces
[01:24] <poolie> ok then
[02:53] <mwhudson> more things that aren't thread safe in bzrlib!
[02:54] <mwhudson> progress bars
[02:55]  * mwhudson attempts to phrase this more usefully
[02:55] <poolie> hm
[02:56] <mwhudson> basically i think one wants a ui factory per thread
[02:57] <mwhudson> i also don't know if the consequences of the unsafety are at all important
[03:04]  * igc lunch
[03:05] <mwhudson> seems likely it's pretty harmless
[03:21] <poolie> mwhudson: it's not clear to me what kind of threadsafety it ought to work
[03:22] <mwhudson> poolie: the
[03:22] <mwhudson>             warnings.warn("%r is not the active task %r"
[03:22] <mwhudson>                 % (task, self._task_stack[-1]))
[03:22] <mwhudson> warning trips occasionally
[03:23] <poolie> yeah
[03:23] <poolie> this uifactory assumes the code is singlethreaded
[03:23] <poolie> so the warning is saying, you need something else
[03:23] <SamB> GTK isn't threadsafe either
[03:23] <poolie> the text mode progress bars will be unhappy if you run multiple threads there
[03:23] <SamB> it freaks out if you call the it from more than one thread
[03:23] <poolie> if this happens even when you have them off, as it probably does, it's a bug
[03:23] <poolie> that i may fix sometime
[03:24] <poolie> but more seriously, lots of code in bzr has state that's unsafe to run concurrently
[03:24] <lifeless> thats ok, python can't do it anyway
[03:24] <poolie> there's not really any contract that you're allowed to do it
[03:24] <poolie> or to do it under particular conditions
[03:25] <SamB> poolie: just stop mutating stuff
[03:25] <SamB> then you're fine!
[03:28] <mwhudson> poolie: this happens with SilentUIFactory too
[03:29] <poolie> ok i agree that's a bug; probably not worth filing as i'll probably fix it next time i refactor there...
[03:29] <mwhudson> cool
[03:29] <mwhudson> i got a bit worried that it was screwing things up, but that was something else
[03:29] <mwhudson> if it just produces a warning now and then (which i think is what it does) i don't really care
[03:30] <poolie> if you're keen you can change silentuifactory not to have that code
[03:31] <mwhudson> i still owe you a patch to make TextProgressView more parameterizable i think
[03:35] <mwhudson> hm, is merge --preview broken?
[03:46] <lifeless> mwhudson: details
[03:47] <mwhudson> lifeless: https://bugs.edge.launchpad.net/bzr/+bug/402022
[04:00] <jfroy> $ bzr log -r -1 lp:rivenx/trunk/0.8
[04:00] <jfroy> bzr: ERROR: bzrlib.errors.ObjectNotLocked: _KnitGraphIndex(CombinedGraphIndex()) is not locked
[04:00] <jfroy> :sad:
[04:01] <fullermd> Objects just wanna be free.
[04:14] <poolie> mwhudson: looks like a qbzr problem, try updating that first?
[04:15] <poolie> hi jfroy, look for an existing bug, it sounds familiar and may be fixed
[04:15] <jfroy> well not in 1.17 :|
[04:15] <jfroy> not a huge deal
[04:16] <mwhudson> poolie: seems you are right
[04:16] <mwhudson> sorry for the noise
[04:17] <poolie> maybe apport should automatically google for the exception :)
[04:17] <poolie> jfroy: https://bugs.edge.launchpad.net/bzr/+bug/389413
[04:18] <jfroy> Similar, though my command was log
[04:19] <jfroy> Added a comment to say so.
[04:29] <spiv> jfroy: I think jml or mwhudson filed one about log recently
[04:30] <jml> I did.
[04:30] <spiv> Possibly the same bug, possibly not.
[04:30] <jml> It's probably a dupe.
[04:32] <jml> missing doesn't take a -d parameter. woe. :(
[04:45] <SamB> grr ... latest bzr nightly seems to make the bzr-fastimport tests fail
[04:59] <SamB> igc: did you notice that bzr-fastimport breaks w/ the latest nightly PPA bzr?
[05:00] <igc> samB: no, but I half expected it
[05:00] <lifeless> bad deltas?
[05:01] <igc> samB: please raise a bug and I'll look at it soon
[05:01] <igc> lifeless: I'd expect so
[05:01] <fullermd> Is the expected half the fast or the import?   O:-)
[05:01] <igc> fullermd: the import
[05:02] <igc> fullermd: it will be *real* fast I expect
[05:02] <fullermd> Shucks.  Oh well, at least it's still fast.
[05:02] <lifeless> igc: I'd hope not
[05:02] <igc> fullermd: it will exit quickly I suspect :-)
[05:03] <igc> fullermd: it just won't work as such
[05:03] <SamB> igc: I also discovered that bug #401249 is worse than I thought
[05:03] <SamB> well, that might also be better, though
[05:04] <SamB> since it means I definately don't have to untangle anything from the head-tracking code ;-)
[05:05] <SamB> igc: what format would you like the test results pasted in?
[05:05] <igc> samB: not sure I understand the question
[05:06] <SamB> just regular, or subunit, or?
[05:06] <igc> SamB: regular is fine
[05:07] <lifeless> :P
[05:16] <SamB> https://bugs.launchpad.net/bzr-fastimport/+bug/402041
[05:17] <SamB> ubottu: that's not an ubuntu bug!
[05:17] <SamB> I sure don't!
[05:34] <lifeless> SamB: wheee, fun
[05:34] <SamB> lifeless: the selftest errors?
[05:34] <lifeless> yah
[06:39] <lifeless> EOD For me
[06:39] <lifeless> see youall tomorrow
[06:39] <lifeless> https://code.edge.launchpad.net/~lifeless/bzr/bug-367632/+merge/8928 still needs review
[06:48] <lifeless> jml: any chance you'll review my subunit branch this avo?
[06:48] <jml> lifeless, a reasonably strong one actually.
[06:48] <lifeless> woo
[06:48] <lifeless> thanks
[06:49] <lifeless> I'm going to do another patch tonight to output time:
[06:49] <lifeless> would you enjoy a subunit talk @ slug?
[06:50] <jml> I haven't been to slug since 2007
[06:50] <jml> :)
[06:50] <jml> lifeless, but it sounds like a good idea.
[07:49] <poolie> lifeless, all the cool kids go to fp-syd now :)
[07:49] <poolie> it's just about functional too :)
[07:50] <lifeless> poolie: sadly, fp-syd is on thursdays
[07:56] <poolie> wow
[07:57] <lifeless> poolie: ?
[07:57] <poolie> the release
[07:57] <poolie> that's great
[08:00] <jml> which release?
[08:00] <jml> :D
[08:01] <bob2> 57408   .bzr/repository
[08:01] <bob2> 174084  backup.bzr/repository
[08:01] <bob2> ^ good work
[08:01] <lifeless> welcome to bzr 2
[08:17] <bialix> igc: helllo
[08:18] <igc> hi bialix! How are you?
[08:18] <bialix> I'm still trying to enter work-mode
[08:18] <bialix> sorry for delay with tarballs
[08:19] <bialix> I'll upload them now
[08:19] <igc> bialix: yes, it took me several days last week to get going again - well after the 900 emails in my inbox were triaged :-)
[08:19] <bialix> the same here
[08:19] <igc> bialix: the tarball is done, the Windows installer is not
[08:20] <bialix> ok
[08:20] <bialix> will do
[08:21] <bialix> last night I've realized there is hidden bug in my check of bzr version
[08:23] <bialix> igc: so what revno I should package to installer? rev 191 tagged as release-0.5, but there is also rev 192
[08:23] <igc> bialix: 192
[08:24] <bialix> I'll update the tag
[08:24] <igc> I tried to move the tag using qtag but it may not have pushed correctly
[08:25] <bialix> push --overwrite should do. I've pushed updated tag. please, check it
[08:28] <bialix> igc: there is two test package now?
[08:28] <bialix> one in the root and other in lib
[08:31] <garyvdm> Hi bialix/igc
[08:32] <bialix> hi garyvdm
[08:35] <bialix> igc: installer has been uploaded
[08:35] <igc> bialix: thanks
[08:35] <igc> hi garyvdm!
[08:49] <bialix> garyvdm: I'd like to have buttons Refresh and Diff swapped in qcommit
[08:50] <poolie> hi bialix, garyvdm
[08:50] <bialix> hi poolie
[08:53] <bialix> garyvdm: btw, your error dialog is very nice, but I wonder if we should suggest to users file bugs against qbzr and not bzr itself?
[09:06] <LarstiQ> bialix: can you detect which part the bug lies?
[09:07] <bialix> well, I mean errors in GUI very often occurs because of internal qbzr error
[09:07] <bialix> anyway we can reassign bug later
[09:08]  * LarstiQ nods
[09:08] <LarstiQ> bialix: it sounds good to me.
[09:08] <LarstiQ> bialix: but detecting where the problem lies would be cool. Even better if you can detect why, next step is automatically fixing it! ;)
[09:08] <bialix> by recompiling python bytecode!
[09:09] <bialix> like in Chrome browser
[09:09] <LarstiQ> changing running programs I sometimes really miss
[09:22]  * igc dinner
[09:24]  * bialix bbl
[12:01] <LarstiQ> lifeless: can you upload bzr 1.17 to Debian, or should someone else do that?
[12:01] <lifeless> LarstiQ: someone  else should :)
[12:01] <LarstiQ> ok
[12:01] <lifeless> little busy atm
[12:01]  * LarstiQ will see if he can prepare that
[12:03] <jelmer> LarstiQ: I've got it prepared here, just need to find my gpg key
[12:03] <LarstiQ> jelmer: sweet!
[12:04] <jelmer> bzr: ERROR: http://bazaar.launchpad.net/~launchpad-pqm/launchpad/db-devel/.bzr/repository/packs/c0ae45a26df55c3bfbb79c0523c4de78.pack is redirected to https://launchpad.net
[12:04] <LarstiQ> jelmer: does anyone over there know anything about openpgp cards with non-sha1 yet?
[12:05] <LarstiQ> jelmer: could you try again? some admin fiddling was going on
[12:06]  * jelmer tries again
[12:09] <lifeless> jelmer: we had a server issue
[12:10] <lifeless> jelmer: its resolved-for-now, but the root cause requires code changes. mwhudson is working on those.
[12:10] <jelmer> lifeless: ah, thanks
[12:42] <gnomefreak> is there another way to push to a branch other than lp:~? its stalling at 43%
[13:07] <TheJosh> Hi all
[13:09] <TheJosh> does a bzr+ssh server require regular ssh accounts on the server (i.e. user accounts)
[13:13] <bob2> yes
[13:13] <bob2> it is over ssh, after all ;)
[13:15] <TheJosh> so is there a way to tell sshd to only accept bzr connections, but not shell connections? I would prefer if my various users were not able to have shell access to my server
[13:18] <awilkins> TheJosh: Make the default shell for their user /bin/false
[13:18] <TheJosh> thanks
[13:28] <garyvdm> gnomefreak: I think you can push to lp using sftp.
[13:28] <LarstiQ> bob2, TheJosh: you can also use a custom ssh server
[13:29] <garyvdm> gnomefreak: try changing the the bzr+ssh://bazaar.lau... address to sftp://bazaar.lau...
[13:29] <garyvdm> gnomefreak: It will probably be much slower.
[13:31] <gnomefreak> garyvdm: as long as it doesnt stall im happy. ill try now
[13:32] <TheJosh> Now I'm getting "bzr: ERROR: Connection closed: please check connectivity and permissions" when I try to checkout. I thought I read something about that somewhere, but I cannot remember where
[13:32] <gnomefreak> garyvdm: this command? bzr push sftp://bazaar.launchpad.netgnomefreak/firefox/firefox.dev
[13:33] <garyvdm> yes
[13:33] <gnomefreak> garyvdm: thanks
[13:34] <gnomefreak> im getting permission denied and i know my ssh key passphrase is right
[13:35] <LarstiQ> gnomefreak: you're missing a slash there
[13:35] <LarstiQ> and a ~
[13:35] <gnomefreak> bzr: ERROR: Permission denied: "/gnomefreak/firefox/firefox.dev": [Errno 13] mkdir failed
[13:35] <LarstiQ> gnomefreak: ~gnomefreak/
[13:35] <gnomefreak> LarstiQ: i fixed the slash
[13:35] <gnomefreak> ah thanks LarstiQ
[13:35] <LarstiQ> TheJosh: does it mention a public key?
[13:36] <TheJosh> Nope. What I pasted is the entire error message
[13:36] <gnomefreak> LarstiQ: thats working ill let you know if it stalls too
[13:36] <garyvdm> gnomefreak: I suspect that launchpad may be slow today due to a rush to download the launchpad code.
[13:36]  * garyvdm checks if it's on slashdot yet.
[13:37] <garyvdm> Nope not on slashdot yet.
[13:37] <LarstiQ> garyvdm: this would be an opportune moment to make use of the decentralized nature of bzr
[13:38] <LarstiQ> TheJosh: could you pastebin the complete transcript from the point where you enter the command used?
[13:38] <TheJosh> sure
[13:39] <garyvdm> larstiq: But of course people will want to get it from the _canonical_ location...
[13:39] <TheJosh> http://pastebin.com/d67cd919
[13:39] <garyvdm> lame...
[13:39]  * awilkins beats garyvdm with the punstick
[13:39] <LarstiQ> fwiw I have a copy I could seed
[13:40] <awilkins> I've already decided to grab the LP sources _later_
[13:40] <awilkins> Not least because the dependancies are huge and my ISP will throttle my connection unless I download them after 2100
[13:40] <LarstiQ> TheJosh: k, you could try and see if adding -Derror enlightens more, but at this point I would try and see if `ssh<EMAIL_ADDRESS>works
[13:41] <awilkins> From #launchpad : < wgrant> Currently downloading Launchpad at 0KB/s
[13:41] <TheJosh> It connects, and then dies instantly - because I set the shell to /bin/false
[13:41] <awilkins> Methinks LP is doomed to be rather slow for quite a few hours
[13:42] <garyvdm> Hi bialix
[13:42] <bialix> hi Gary
[13:44] <garyvdm> bialix: Can't reproduce bug 402103, and I have no idea what it could be.
[13:45] <garyvdm> Can you try a minimal test case:
[13:45] <garyvdm> cb = QtGui.QCheckbox()
[13:46] <garyvdm> cb.setCheckState(0)
[13:46] <bialix> you want me to check it in python shell?
[13:46] <garyvdm> yes please
[13:46] <bialix> it will be not fair experiment
[13:46] <bialix> because I'm running bzr.exe
[13:48] <LarstiQ> TheJosh: can you ssh in?
[13:48] <TheJosh> I can SSH in
[13:48] <TheJosh> LarstiQ, I can SSH in, but the shell exits straight away because I set the shell to be /bin/false
[13:49] <bialix> garyvdm: QWidget: Must construct a QApplication before a QPaintDevice
[13:49] <bialix> I have segfault
[13:49] <LarstiQ> TheJosh: ah, that may be it.
[13:50] <LarstiQ> TheJosh: have a look at contrib/bzr_access instead
[13:50] <bialix> (Pdb) cb.setCheckState(0) *** TypeError: argument 1 of QCheckBox.setCheckState() has an invalid type
[13:52] <garyvdm> bialix:  Please can you try:
[13:52] <TheJosh> LarstiQ, How does that help my problem?
[13:52] <garyvdm> cb.setCheckState(QtCore.Qt.Unchecked)
[13:52] <LarstiQ> TheJosh: instead of setting to /bin/false, which I'm rather sure is what is denying you to login
[13:52] <LarstiQ> or well
[13:53] <LarstiQ> run bzr over ssh
[13:53] <garyvdm> bialix: I suspect that if you upgrade to PyQt4.4 it will be fixed.
[13:53] <bialix> garyvdm: I'm already running PyQt 4.4.3
[13:53] <TheJosh> LarstiQ, isn't that what i'm trying to do, run bzr over ssh (i.e. bzr+ssh://)
[13:53] <garyvdm> Oh
[13:53] <LarstiQ> TheJosh: yes, but you can't, because your shell is /bin/false
[13:54] <LarstiQ> TheJosh: I might be wrong, but that is how I analyze the situation
[13:54] <bialix> garyvdm: as discussed we stopped to support 4.3, and I've switched to latest available
[13:54] <awilkins> LarstiQ: That might be my fault... I was of the opinion that it would prevent shell logins.. .but not running bzr
[13:54] <TheJosh> or I just run through sftp://
[13:55] <bialix> awilkins: hi, can you explain what's wrong with qconflicts so you don;t use it?
[13:55] <awilkins> bialix: Didn't know it was there!
[13:55] <awilkins> bialix: Ooh, shiny
[13:55] <awilkins> bialix: IT was absent when I first started using qbzr
[13:55] <bialix> garyvdm: cb.setCheckState(QtCore.Qt.Unchecked) is worked
[13:56] <bialix> awilkins: it was added many months agop
[13:56] <gnomefreak> using sftp im getting Connection to bazaar.launchpad.net closed by remote host.d 1211/1295
[13:56] <LarstiQ> TheJosh: sure, that is an option, though slower
[13:57]  * garyvdm wonders how many other cool qbzr feature there are that people are not aware of.
[13:57] <bialix> btw vila broke qpush
[13:57] <gnomefreak> list them in bzr --help?
[13:57]  * awilkins awilkins runs `bzr help commands | grep q`
[13:57] <TheJosh> So why does bzr not have any decent access controls, thus preventing me from using the bzr:// smart-server directly. Argh so annoying!
[13:58] <bialix> and vila away on vacation, rats, I have no person to poke
[13:58] <garyvdm> awilkins: Not just commands.
[13:59] <gnomefreak> i dont get it sunbird pushed fine but firefox branch wont push
[13:59] <awilkins> TheJosh: The only access you can control in a DVCS is to transports, so it doesn't make sense for bzr to implement access controls when there are so many nice implementations on existing transports
[13:59] <luks> awilkins: the first version of qconflicts was actually written for you exclusively, because you were complaining how that's the only thing you use bzr-gtk for :P
[13:59] <bialix> hi luks
[13:59] <luks> hey
[14:00]  * awilkins blsuhes
[14:00] <garyvdm> gnomefreak: I suspect that this is a hosting issue. Maybe they will be able to help you at #launchpad
[14:00] <garyvdm> Hi luks
[14:00] <gnomefreak> garyvdm: thanks ill ask
[14:01] <garyvdm> bialix: How is qpush broken?
[14:01] <awilkins> qbzr and external merge apps ; does it permit selection on patterns?
[14:02] <awilkins> And does the definition permit formats?
[14:02] <bialix> garyvdm: push complains when wt is not clean, me working with lightweight checkout, but qpush is started in the root of the master branch that has out-of-date tree
[14:02] <bialix> so now we have to "fix" qpush, thanks to vila
[14:03] <LarstiQ> bialix: --no-strict?
[14:03] <bialix> maybe, but anyway it's not there right now
[14:04] <luks> awilkins: I'm not sure I understand the question, but it uses the same format as extmerge
[14:05] <awilkins> luks: I patched bzr-gtk for my own use to accept a python format-string because the way it built args didn't work too well on windows
[14:06] <awilkins> luks: Looking at the implementation in qbzr it looks similar only it uses replace instead of format
[14:11] <garyvdm> luks: I also use a patched version of extmerge. And I could not get conflicts to do what I wanted - I should just fix it my self but I've not had time.
[14:12] <garyvdm> I want it to run meld bar.py.THIS bar.py bar.py.OTHER
[14:14] <luks> "meld %t %r %o" doesn't work?
[14:18] <bialix> btw, qconflicts does not support winmerge
[14:18] <TheJosh> awilkins, surely a 'smart' server, which provides its own transport, should be able to proved basic authentication
[14:20] <LarstiQ> TheJosh: very little people run bzr://
[14:20] <LarstiQ> hmm, that came out wrong
[14:21] <TheJosh> LarstiQ, perhaps because it doesn't have authentication
[14:21] <LarstiQ> TheJosh: rather, because we alread have ssh I think
[14:21] <TheJosh> yeah, but then I am opening up everyone to my entire VPS.
[14:22] <LarstiQ> TheJosh: but have a look at http://pypi.python.org/pypi/ClueBzrServer/0.2
[14:23] <TheJosh> thanks
[14:25] <garyvdm> bialix: please will you see if lp:~garyvdm/qbzr/bug402103 works
[14:29] <bialix> garyvdm: it works, but strange
[14:29] <garyvdm> bialix: Your PyQt is more fussy than mine.
[14:30] <bialix> if I have tree w/o changes and then change file and refresh there appears additional columns: date/size etc
[14:30] <garyvdm> bialix: TreeWidget never shows the size.
[14:31] <garyvdm> Is this is qcommit?
[14:31] <garyvdm> *in
[14:31] <bialix> garyvdm: it seems like PyQt4.4.x Windows build is much worse than 4.3.1
[14:31] <bialix> in qcommit, yes
[14:32] <garyvdm> bialix: That's surprising. Please will you imagebin a screenshot.
[14:33] <bialix> may be I need file a bug?
[14:34] <garyvdm> bialix: ok
[14:34] <bialix> garyvdm: http://imagebin.ca/view/5nu7sR.html
[14:35] <garyvdm> bialix: it should be easy to change qpush to change subprocess starting dir, instead of using -d
[14:36] <garyvdm> bialix: that is a bug.
[14:36] <bialix> I'll file it
[14:37] <luks> speaking of qci, would somebody object if I get rid of the help text in the Branch group (when committing to a checkout)?
[14:37] <bialix> garyvdm: any ideas about bug 402100?
[14:37] <luks> I don't think it belongs there and it takes space
[14:37] <garyvdm> bialix: looking at that screen shot, I realized that Bug 402100
[14:37] <garyvdm> is due to your pyqt version
[14:38] <garyvdm> I'll boot into windows just now to fix it.
[14:38] <bialix> luks: it was idea of Mark Hammond, I never was big fan of big texts there
[14:38] <awilkins> What do you dudes use to make the UI? QtCreator?
[14:38] <bialix> QtDesigner
[14:38] <luks> I'd rather write a manual than have that text in UI
[14:38] <garyvdm> aqilkins: some times
[14:39] <bialix> some dialogs hand written
[14:39] <garyvdm> ^^^ most of the time.
[14:39] <bialix> :-)
[14:39] <bialix> Designer is very good to mock UI
[14:41] <bialix> garyvdm: btw about your cool idea to show revision message in qdiff: may be we need to do it all the time when qdiff running as qdiff -cN ?
[14:42] <garyvdm> Yes
[14:42] <luks> yeah, I'd like that too
[14:43] <garyvdm> I personally don't use that very often. I normally go into qlog - then dbl click on a rev.
[14:44] <bialix> IIRC gitk shows diff right in the log window when user selects revision
[14:44] <garyvdm> and vis shows it in a tab
[14:45] <bialix> garyvdm: https://bugs.launchpad.net/qbzr/+bug/402218
[14:45] <garyvdm> bialix: thanks
[14:45] <luks> gitk can do that, because git is fast enough :)
[14:46] <luks> even getting the revision delta is slow in bzr
[14:46] <CaMason> hi guys. I took a branch, and I've made a number of commits to it. I've now made a change to a single file, and I'd like to merge that single change into the parent branch. Is this possible?
[14:47] <awilkins> CaMason: Yes, for given values of yes
[14:47] <garyvdm> luks: meld %t %r %o - gives me "Error while running merge tool (code 0)"
[14:47] <luks> hm
[14:47] <CaMason> would you mind explaining the process at all?
[14:47] <awilkins> CaMason: You can i) Cherrypick that revision into parent, ii) start a new branch off parent, make the change there and merge it into both branches
[14:47] <CaMason> brilliant, thanks I'll look that up
[14:50] <CaMason> with option2, should I uncommit from my branch before merging it in from the new new branch?
[15:05] <garyvdm> bialix: I can't reproduce  bug 402218.
[15:05] <garyvdm> I tried in a lw checkout
[15:06] <garyvdm> Where the wt tip is older than the master branch tip
[15:07] <bialix> bug 402218 is not related to lt checkout I guess
[15:07] <garyvdm> Ah - bialix: If you scroll to the right, do you see the status column
[15:07] <garyvdm> I think that all columns are visible
[15:08] <garyvdm> I originally thought that it was because it had a RevisionTree, and not a WorkingTree.
[15:08] <bialix> garyvdm: yes, the status column here
[15:09] <bialix> I've used small window size to reduce screenshot
[15:10] <bialix> garyvdm: additional columns appears only if you start qci in clean tree (without any changes)
[15:52]  * GaryvdM reading the comments in http://news.slashdot.org/story/09/07/21/1224259/Canonical-Fully-Open-Sources-the-Launchpad-Code while I wait for bzr to pull lp:qbzr very slowly...
[15:59] <Tak> heh
[16:35] <bialix> GaryvdM: another problem with qci: when I have pending merge and many many renamed files in subfolder then scrolling wt view does not repaint it until I click mouse on some item
[16:36] <GaryvdM> bialix: Ok - please will you try get a screenshot
[16:36] <bialix> screenshot?
[16:37] <bialix> I'm not sure
[16:37] <bialix> it's need to see in action
[16:38] <GaryvdM> bialix: ok - Please log a bug.
[16:39] <GaryvdM> I just managed to fix one of the column bugs. - Looking up the bug number.
[16:44] <GaryvdM> bialix: Bug 402218 fixed :-)
[16:44] <ubott2> Launchpad bug 402218 in qbzr "qcommit: after refresh there is additional columns in file view" [Medium,Fix released] https://launchpad.net/bugs/402218
[16:45] <ubott2> Ubuntu bug 402218 in qbzr "qcommit: after refresh there is additional columns in file view" [Medium,Fix released]
[16:45] <ubott2> Launchpad bug 402218 in qbzr "qcommit: after refresh there is additional columns in file view" [Medium,Fix released] https://launchpad.net/bugs/402218
[16:45] <bialix> lol
[16:45] <bialix> ubottu fight with ubott2
[16:45] <GaryvdM> These bots need to chill!
[16:49] <beuno> I don't have op access to remove him  :/
[16:53] <GaryvdM> Hi beuno
[16:53] <beuno> hi GaryvdM!
[16:54] <GaryvdM> Must be an exciting day for everyone at Canonical!
[16:56] <beuno> it is  :)
[16:56] <beuno> we're very happy about the release
[16:56] <beuno> you don't drop a few million lines of code into the world every day
[16:57] <bialix> amazing
[17:01] <bialix> interesting, why codehosting is open sourced in the end?
[17:02] <beuno> bialix, Mark decided to release everything. That's about as much as any of us know  :)
[17:02] <bialix> hm
[17:03] <luks> marketing is usually the reason for such decisions :)
[17:03] <beuno> luks, not in Canonical  ;)
[17:04] <luks> I don't believe that
[17:04] <beuno> you should work for us for a while then
[17:09] <GaryvdM> bialix: bug 402100 seems to be a qt bug with using ResizeToContents and having check boxes.
[17:10] <ubott2> Launchpad bug 402100 in qbzr "qcommit: filename is not fully visible and column is not resizable" [High,Confirmed] https://launchpad.net/bugs/402100
[17:10] <ubott2> Ubuntu bug 402100 in qbzr "qcommit: filename is not fully visible and column is not resizable" [High,Confirmed]
[17:10] <ubott2> Launchpad bug 402100 in qbzr "qcommit: filename is not fully visible and column is not resizable" [High,Confirmed] https://launchpad.net/bugs/402100
[17:10] <bialix> any chance on workaround?
[17:11] <GaryvdM> One solution would be to Stretch the filename and ResizeToContents of the status.
[17:11] <GaryvdM> That did not work to well with qbrowse - cause the status is then to far away from the filename
[17:13] <bialix> GaryvdM: maybe just to not use ResizeToContents in qci?
[17:14] <GaryvdM> ok
[17:16] <bialix> GaryvdM: btw, many thanks to qlog branch1 branch2 --> it's fantastic for doing complex repeated merge of 2 diverged branches!
[17:16] <bialix> I mean refresh
[17:16] <GaryvdM> :-)
[17:24] <igc> night all
[17:30]  * bialix waves
[18:03] <KhaZ> Hrmm, weird problem I'm having.  I'm running bzr under cygwin.  I've got a ~/.bazaar/bazaar.conf with an alias set up for bzr st.  If I use the bzr that ships with cygwin, the alias gets triggered on bzr st.  If I use the win32 native bzr, the alias doesn't trigger.
[18:03] <KhaZ> Does the native and the cygwin binaries have different locations for $HOME?
[18:03] <KhaZ> Oh, just read online about %APPDATA%... Damn.
[18:04] <luks> you can put your config to %APPDATA% and make a symlink to that from cygwin's home
[18:04] <KhaZ> I thought symlinks don't work properly in cygwin - aren't they just copies?
[18:04] <luks> I don't know actually
[18:04] <luks> I just expected them to work
[18:04] <KhaZ> Yeah; me too. :(
[18:05] <KhaZ> That said, it would work.  The only irritation is that I version control my home directory, so now I have to install something outside of my home directory to make this work.
[18:05] <KhaZ> I wonder why the difference between Windows an Unix versions?  It would be so convenient to always have it in $HOME, at least in (my) theory. ;)
[18:06] <luks> native applications on windows don't put their data directly in the home directory
[18:06] <luks> while native applications on unix do that
[18:06] <KhaZ> Right.  So is it just a matter of following the default policy on the platform you're on?
[18:06] <luks> I guess so
[18:06] <KhaZ> As in, bzr has no requirement to use $APPDATA except for conforming to the OS it's on?
[18:07] <KhaZ> (Just curious here.)
[18:07] <luks> you can set $BZR_HOME if you want
[18:07] <luks> yes
[18:07] <KhaZ> Oh.  That sounbds awesomer.
[18:09] <KhaZ> Huh.  Setting BZR_HOME yields a No handlers could be found for logger "bzr" error.
[18:10] <KhaZ> "bzr: ERROR: [Error 3] The system cannot find the path specified: '/cygdrive/c/Documents and Settings/eparker/bazaar'"
[18:10] <KhaZ> export BZR_HOME="$HOME" should work, no?
[18:10] <luks> you can't access that path from native windows
[18:11] <KhaZ> Oh.  Duh
[18:11] <KhaZ> Right
[18:11] <KhaZ> It's using the native binary but it doesn't know WTH /cygdrive is.
[18:11] <KhaZ> My bad.
[18:17] <KhaZ> Ack.  $BZR_HOME doesn't set the root of where the config files.  I still need to duplicate my configs.  I'm reading the ConfiguringBzr page and there doesn't seem to be an env-var for 'this is the root of bazaar\'s configs variable'.  Any chance you know of one, luks?
[18:17] <KhaZ> (Right now I've got ~/.bazaar/[my config files] and ~/.bazaar/bazaar/2.0/[my config files], which is rather uggo.
[18:18] <luks> can't you just set BZR_HOME differently on windows and cygwin?
[18:19] <luks> make it point to %APPDATA%/bazaar/2.0 on windows
[18:19] <luks> and ~/.bazaar on cygwin
[18:19] <KhaZ> I can, but it looks like on windows/cygwin they append the directory bazaar/2.0/ to whatever BZR_HOME is.  On Linux they just append .bazaar to it.
[18:19] <luks> oh, hm
[18:19] <KhaZ> Hence my problem.  I need two directories to version my config files.
[18:20] <KhaZ> I suppose I could read the source to figure it out if need be.
[18:20] <KhaZ> It seems like a strange behaviour to have an env var for a partial path.
[18:21] <luks> that sucks, there doesn't seem to be a way around it
[18:22] <KhaZ> That does suck.  Maybe I'll write a ticket about it; see if the devs think it's a good idea.  Definitely would help me.
[18:22] <luks> changing the behavior of BZR_HOME is most likely not an option
[18:22] <luks> but a new variable could be added
[18:23] <KhaZ> That's what I'm thinking.  I hate to suggest yet another env var, but that would probably hurt the least people.
[18:24] <KhaZ> Ah; looks like there's already a bug for it.
[18:24] <KhaZ> https://bugs.launchpad.net/bzr/+bug/348640
[18:24] <ubott2> Ubuntu bug 348640 in bzr "Want a variable to override location of ~/.bazaar etc" [Low,Confirmed]
[18:26] <luks> this is trivial to fix
[18:27] <luks> but there is no way I'm sending a patch to bzr again :)
[18:28] <KhaZ> Hah; why's that luks ? :)
[18:30] <luks> let's not discuss that :)
[18:30] <luks> http://paste.pocoo.org/show/129942/
[18:30] <luks> if you want you can take this, add a test and submit it
[18:31] <KhaZ> Oh, hot.  Easiest fix I never had to write. ;)
[18:31] <KhaZ> I'll monkey with that and see.  I wonder if my last patch ever got taken... I never did follow up on it.
[18:37] <nickoe> How do I update to a specific revision?
[18:42] <luks> nickoe: you can't update a checkout to a specific revision
[18:42] <luks> nickoe: what exactly do you want to do?
[18:42] <nickoe> revert a file
[18:43] <luks> then "bzr revert -rX FILE"
[18:46] <nickoe> luks: $  bzr revert -rX main.c
[18:46] <nickoe> bzr: ERROR: No namespace registered for string: u'X'
[18:47] <luks> replace X is the revision you want
[18:47] <luks> or use "bzr revert main.c" if you want the last committed revision
[18:47] <luks> er, s/is/with/
[18:49] <nickoe> $  bzr revert -r1 main.c
[18:49] <nickoe> bzr: ERROR: Not a branch: "/some/silly path to my file/main.c/".
[18:49] <nickoe> i am exec in /some/silly path to my file/
[18:50] <nickoe> luks, what is wrong?
[18:50] <luks> /some/silly path to my file/ is probably not a branch
[18:50] <nickoe> luks, does it have to be?
[18:51] <luks> you normally want to rever a versioned file
[18:51] <luks> *revert
[18:51] <luks> and such a file must be in a branch
[18:52] <nickoe> ohh, ofc, I am in the woring project, :P
[18:54] <Kinnison> Anyone know how harmful messages like this are: inconsistent details in skipped record: ('michael.hudson@canonical.com-20070704120851-qih0ajr8ie2csj6m',) ('97295 243 0 276', ((('michael.hudson@canonical.com-20070704120556-wd7z1ffquvavt3so',),),)) ('781826 243 0 276', ([('michael.hudson@canonical.com-20070704120556-wd7z1ffquvavt3so',)],))
[19:00] <nickoe> luks, thank you, bye
[20:25] <j^> why does  bzr branch lp:launchpad need like 500mb ram?
[20:27] <j^> looks like its even still growing
[20:28] <j^> this is with Bazaar (bzr) 1.16.1
[20:29] <j^> 912m 708m 1592 S   44 36.3   3:07.53 bzr
[20:33] <LarstiQ> j^: is that over http or ssh?
[20:34] <j^> LarstiQ, i think http, i have an account on lp though and it usually uses ssh if i do bzr lp:something
[20:34] <j^> upgrading now to 1.17 and will try again
[20:35] <LarstiQ> j^: I think the relevant bug might be https://bugs.edge.launchpad.net/bzr/+bug/402657
[20:36] <LarstiQ> j^: hmm, or maybe a related one
[20:37] <j^> [#########/          ]   3792KB    46KB/s | Fetching revisions:Inserting stream
[20:37] <LarstiQ> j^: does ~/.bzr.log illuminate?
[20:38] <j^> that looks like http
[20:38] <j^> 159.916  25 bytes left on the HTTP socket
[20:38] <LarstiQ> j^: right
[20:38] <LarstiQ> j^: what does `bzr launchpad-login` report?
[20:38] <j^> j
[20:39] <LarstiQ> hmm, why doesn't it pick ssh then
[20:40] <j^> 1.17 still uses all my ram
[20:40]  * LarstiQ nods
[20:40] <LarstiQ> j^: you can do it in bits and pieces
[20:41] <LarstiQ> j^: were you using a shared repository to branch into?
[20:41] <j^> bzr branch lp:launchpad/edge  launchpad uses ssh
[20:42] <LarstiQ> ok
[20:42] <j^> LarstiQ, i was not using a shared repository was just trying bzr branch lp:launchpad
[20:42] <LarstiQ> j^: right
[20:42] <LarstiQ> then it is slightly trickier to do it in batches
[20:43] <LarstiQ> j^: bzr branch -r 1 lp:launchpad launchpad; cd launchpad; bzr pull -r 1000; bzr pull -r 2000; etc
[20:43] <j^> i am happy to get it in a shared repos if that helps
[20:44] <j^> how would i use a shared repos?
[20:44] <LarstiQ> j^: if you plan to do development on launchpad that would be the recommendation
[20:44] <j^> for now i wanted to read the code
[20:44] <j^> since the webinterface does not list the files
[20:44] <j^> it lists them but does not show the contents
[20:44] <LarstiQ> j^: `bzr init-repo --2a ~/src/launchpad; bzr branch lp:launchpad ~/src/launchpad/trunk` for instance
[20:45] <LarstiQ> j^: or you could use the trick I just showed you
[20:46] <j^> will try the shared repos first, i might start hacking on it
[20:46] <LarstiQ> j^: there, https://bugs.edge.launchpad.net/bzr/+bug/402139 might be the bug I was looking for
[20:52] <Kinnison> Anyone have any idea why bar is giving me annoying messages like 'SHA1KnitCorrupt' when I try and pull the dulwich repo?
[20:53] <LarstiQ> Kinnison: I do not, jelmer might
[20:54] <Kinnison> Are there any bzr people at debconf this year?
[20:55] <LarstiQ> Kinnison: Jelmer is
[20:55]  * LarstiQ sadly is not :(
[20:56] <LarstiQ> Kinnison: are you there?
[21:12] <Kinnison> I am, sorry, was re-reading bits of soyuz and reminiscing
[21:12] <Kinnison> jelmer: I should prod you about this dulwich problem, but perhaps tomorrow?
[21:21] <jelmer> Kinnison: yeah, I should be around tomorrow
[21:21] <Kinnison> coolbeans
[21:21]  * Kinnison decides to head to the lobby with some cards
[21:22] <LarstiQ> ooh
[21:22]  * LarstiQ really needs to find some Debian people geographically close soon
[21:32] <|malibu|> Help!
[21:32] <|malibu|> I had a commit hang on me.  I broke out of it and now I have a remote lock
[21:32] <|malibu|> Anyone know how I clear this out and redo the commit?
[21:33] <beuno> |malibu|, and bzr break-lock REMOTE_URL doesn't work?
[21:36] <|malibu|> didn't know about that one
[21:37] <|malibu|> ok seems to have worked..
[21:37] <LarstiQ> |malibu|: break-lock should be suggested to you if you try any operation on a locked branch?
[21:37] <|malibu|> commit again should catch everything?
[21:37] <LarstiQ> |malibu|: yeah
[21:38] <|malibu|> ok cool, thanks
[21:38] <|malibu|> I did bzr -h but didn't see break-lock in there
[21:38] <LarstiQ> |malibu|: `bzr help commands` lists it
[21:38] <|malibu|> ah
[21:53] <Hillshum> How do I clone a cvs repo?
[21:59] <Hillshum> anyone?
[22:19] <Leonidas> Hillshum: CVS repos don't get cloned, they get checked out
[22:20] <Leonidas> uhm, bzr 1.17 depends on zlib for building, why is that so?
[22:22] <Hillshum> Leonidas, Yeah, I think I have it now, so "bzr checkout http://some.box.com/trunk" ?
[22:22] <sender> Can anyone help me get started to contribute translations for bzr plugins?
[22:22] <Leonidas> Hillshum: CVS does not use HTTP
[22:23] <Hillshum> Leonidas, what protocol then?
[22:23] <Leonidas> Hillshum: most of the time it is 'pserver'
[22:24] <Leonidas> Hillshum: what do you want to do in the first place?
[22:24] <sender> E.g. how do I add a new translation to bzr-explorer (https://translations.launchpad.net/bzr-explorer/trunk) ?
[22:24] <Hillshum> Start woking on a antiquated cvs repos
[22:25] <Hillshum> hillshum@ibook:~$ bzr checkout pserver://parliament.cvs.sourceforge.net/cvsroot/parliament
[22:25] <Hillshum> bzr: ERROR: Unsupported protocol for url "pserver://parliament.cvs.sourceforge.net/cvsroot/parliament"
[22:30] <Leonidas> bzr does not support cvs directly
[22:30] <amanica> sender, I think you may need to join the team
[22:30] <Leonidas> Hillshum: let launchpad import the project, then clone it.
[22:30] <amanica> also it may automatically show your language if launchpad knows it
[22:30] <amanica> sender: i.e if you added your language to your launchpad preferences
[22:31] <sender> amanica: thanks, you are right. I notified LP of my language and now I can select it.. :)
[22:31] <amanica> sender: I'm just guessing
[22:31] <amanica> cool
[22:31] <sender> amanica: do you know if I can use a local app to translate instead of the LP interface?
[22:31] <amanica> yes you can
[22:31] <sender> amanica: and how can I test bzr-explorer with the translation?
[22:32] <amanica> I have not used it yet though
[22:32] <sender> amanica: I've got poedit here, but do not have a clue how to start off
[22:32] <amanica> sender: mmm.. maybe bialix or ianc can help you there
[22:33] <LarstiQ> Leonidas: because bzr uses zlib and the C extension needs to include headers/build against it
[22:33] <amanica> sender: maybe ask this on the mailinglist
[22:33] <amanica> I'm sure you'd get a responce
[22:34] <sender> amanica: will do, thanx :)
[22:34] <amanica> cool
[22:35] <Leonidas> LarstiQ: this seems to be a new feature, right?
[22:38] <LarstiQ> Leonidas: yes. I can look up which exact bzr version introduced it if you want.
[22:47] <lifeless> moin
[22:49] <DaffyDuck_> Let's say we are two working on a project. A shared repository is located on a dedicated server. My friend makes changes, and "bzr push":es changes. Then I make changes and push changes. This causes a conflict. How is this handled? Do I merge from the server, and then push the merged changes?
[22:50] <amanica> goodnight
[22:52] <Leonidas> LarstiQ: thanks, don't bother. I just saw it today because the usual easy_install -U bzr failed and somewhere inside of the _terribly helpful_ messages of GCC was a missing header error.
[22:55] <awilkins> DaffyDuck_: are you working in a branch, or a checkout?
[22:56] <awilkins> DaffyDuck_: But yes, you can merge, and push the changes. Then your friend will have to pull your changes (or merge later after he commits some more)
[22:59] <lifeless> DaffyDuck_: if youre pushing to the same branch, I suggest using a checkout
[23:03] <DaffyDuck_> awilkins: Um.. What's the difference between a branch and a checkout? I always do "bzr branch ...", but I assume I can do a "bzr checkout ..."?
[23:05] <DaffyDuck_> Ah, so a checkout is simply set of working files?
[23:06] <awilkins> DaffyDuck_: Checkout is "bound" to the master branch so all commits are also comitted there
[23:06] <awilkins> Unless they changed it already so that checkouts are all lightweight ones (no local repository branch)
[23:07] <awilkins> If you've used SVN, a lightweight checkout is like an SVN working copy
[23:07] <lifeless> DaffyDuck_: a checkout provides the cvs/svn style centralised workflow
[23:07] <DaffyDuck_> Ah, ok. That makes sense.
[23:07] <lifeless> where commits to a common object are serialised and the left hand history is preserved
[23:07] <lifeless> at an implementation level the default checkout is a 'bound branch'
[23:08] <lifeless> but you can also create one with no history attached, if you pass --lightweight. This is not a good idea from a performance angle if you're working over anythin other than a LAN
[23:08] <DaffyDuck_> checkout = centralized, branch = decentralized (but push/pull can make it semi-centralized).
[23:08] <awilkins> Or if you ever use your laptop on the train :-)
[23:09] <DaffyDuck_> awilkins: I use my laptop on the train almost every day. :)
[23:09] <lifeless> DaffyDuck_: a normal checkout will work fine on the train, you just can't commit
[23:10] <lifeless> DaffyDuck_: the way I do this is I have a couple of branches for projects with shared mainlines
[23:10] <DaffyDuck_> lifeless: Yeah, but it's commit I want. :)
[23:10] <lifeless> one that is a checkout
[23:10] <lifeless> and one that is a normal branch
[23:10] <lifeless> when I'm offline, or doing speculative stuff, I use the normal branch
[23:10] <lifeless> once its reviewed and ready to land, I merge it to the checkout and commit
[23:10] <lifeless> which simultaneously pushes it and enforces the mainline
[23:10] <awilkins> You can commit to Â"heavy" checkouts, there are just extra steps (nd parameters)
[23:11] <DaffyDuck_> lifeless: Thanks for the tip. That feels like a very natural way to work, so I just may adopt it.
[23:11] <awilkins> I tend to have a local no-trees repository and take lightweight checkouts from it, branch as I wish locally, and merge and push my changes when required
[23:12] <lifeless> awilkins: oh, I have these branches in a shared repo; but the key thing is checkout+regular branches ;)
[23:12] <awilkins> I'll commit my patches, switch my working tree back to the mainline, merge from the local branch, and then push
[23:12] <DaffyDuck_> So both of you have something like proxy checkouts. Hmm..
[23:13] <awilkins> We do the same thing we just use different infrastructure
[23:13] <|malibu|> Does bazaar have commit hooks on the server side?
[23:13] <lifeless> yes
[23:13] <|malibu|> awesome, tks
[23:13] <awilkins> I'm really still interested in seeing a version of pipeline that supports parallel pipes
[23:14] <awilkins> Or just a straight port of Mercurial pbranches
[23:14] <awilkins> (which I was tempted to do after I saw it was just one source file)
[23:14] <|malibu|> BTW.. bzr with light checkout makes an awesome dropbox-type thing
[23:16] <|malibu|> I'd really like to get it to do a commit every time I write a file.. but even with a batched up commit it works great
[23:20] <DaffyDuck_> Is "init-repo" (shared repository) merely a way of collecting several branches of a project in a single entity on a server?
[23:20] <fullermd> No, it doesn't make a single entity of anything.  It's a way of sharing storage among branches with common history.
[23:21] <DaffyDuck_> fullermd: So, if I have a dev, and a stable. I merge dev to stable, then stable actuallty uses the storage of dev (if I do no changes)?
[23:22] <fullermd> Well...    yes, I guess, but that's a confusing way of looking at it.
[23:22] <fullermd> Better is "if I have a dev and a stable, they both store their history in one common place"
[23:23] <fullermd> (and thus any common history, which is probably most of it, is only stored once rather than twice)
[23:24] <fullermd> Every branch always has a repository, because that's where revisions are stored.  init-repo is used to create shared repos, so that multiple branches can use the same repository.
[23:25] <DaffyDuck_> fullermd: Ah, ok. From the init-repo example, it looked like they smiply created two different branches inside a "init-repo" directory, and I was wondering if the branches can simply be moved out of that init-repo directory and be used individually, but I guess there's more to it than that.
[23:26] <DaffyDuck_> Hmm... It seems like init-repo is what I want to do. I need to experiment with it a little.
[23:26] <fullermd> Yes, if you move them out of the shared repo, they can't find it anymore.  That would be Bad(tm).
[23:27] <fullermd> You can move them around all you want underneath it though.
[23:27] <DaffyDuck_> Oh. Hmm... I find that cool, yet confusing.
[23:27] <fullermd> (of course, if you 'bzr init' two branches inside a repo, they don't have any shared history, so there's no real win)
[23:28] <DaffyDuck_> fullermd: Yeah, I figured. You init one "branch", and then "branch" the others to get full usage?
[23:29] <fullermd> Well, most of the time, you'd "branch" an existing branch of the project, then "branch" from that (or from other existing branches)
[23:30] <fullermd> But 'init' creates a branch ab ovo.  There's no history [yet], and any future history is thus divorced from the history of any existing branch, or any separately init'd branch.
[23:32] <DaffyDuck_> fullermd: Ah. So - technically - bzr will check if it is inside a?shared repo when a "branch" is created?
[23:32] <lifeless> DaffyDuck_: if you're starting new stuff in bzr, I encourage you to pass --2a to your init-repo command
[23:32] <lifeless> DaffyDuck_: this is the format that will be default in 2.0
[23:33] <fullermd> DaffyDuck_: Yes, an existing repo will be used if it's found, otherwise we'll create a new (unshared) one specifically for that branch.
[23:33] <lifeless> jam: around?
[23:33] <DaffyDuck_> lifeless: Ok. The description doesn't tell me anything, but I'll take you advise.
[23:34] <DaffyDuck_> fullermd: Excellent. The puzzle is coming together.
[23:34] <fullermd> DaffyDuck_: So, if you have a repo at /repo, and you go to /repo and run "bzr branch http://some/project/ a", the branch 'a' will use the repo.
[23:34] <fullermd> DaffyDuck_: And if you run "bzr branch http://some/project/ b" after that, b will also use the repo, so it will finish very quickly since it already has all the revisions in the repo from when it branch'd into 'a'.
[23:34] <lifeless> DaffyDuck_: we're hopinh to make it the default in about a month
[23:35] <DaffyDuck_> I'll start experimenting (best way of learning) with shared repos tomorrow. Thanks for the information, all of you.
[23:35] <DaffyDuck_> I can't believe we stuck with subversion this long. :(
[23:35] <DaffyDuck_> Expect more questions tomorrow. :)
[23:35] <lifeless> DaffyDuck_: the only caveat is you need bzr 1.16.1 or newer
[23:36] <lifeless> DaffyDuck_: but you want that anyway :)
[23:36] <DaffyDuck_> lifeless: It appears I have 1.16.1.


[23:02] <wgrant> blr: Could you please have a look at https://code.launchpad.net/~wgrant/charms/trusty/turnip/single-dir/+merge/251873?
[23:02] <wgrant> Oh, you already have. I must have blackholed all charm mail.
[23:03] <blr> even without other services running on the instance, that seems better.
[23:10] <wgrant> Yeah
[23:10] <wgrant> My intent is that I should be able to deploy eg. both on one unit.
[23:10] <wgrant> I'm going to add a new relation this morning.
[23:11] <wgrant> To automate the turnip <-> turnipcake setup entirely.
[23:11] <wgrant> Currently you have to deploy both, relate them, then set the virt endpoint on the turnip unit, when that should be fetched from the relation by default.
[23:11] <wgrant> So it'll be deploy, deploy, add-relation, oh look you have a git server.


[15:50] <mdeslaur> could someone please kill this spammer, please: https://bugs.launchpad.net/~c649199fe
[16:11] <cjwatson> mdeslaur: done
[16:13] <mdeslaur> cjwatson: thanks!
[20:06] <teward> there's no way to trick the ppa builders into building non-i386/non-amd64 packages is there?
[20:14] <dobey> teward: request enblement of the other architecutre you're interested in via launchpad answers
[20:54] <teward> dobey: i thought that was restricted to arm?
[20:54] <teward> rather than $allarchs
[21:07] <dobey> teward: what arch do you want? arm isn't i386 or amd64 :)
[21:08] <teward> dobey: good point.  PPC came to mind, but meh.  :P
[21:08] <teward> ppc being evil as hell itself, though... probably best for me to not bother anyone about it
[21:08] <teward> seeing the build farm for PPAs doesn't have ppc
[21:09] <teward> anyways, done, I'll let it sit in the queue :)
[23:50] <teward> dobey: armhf has been enabled now, thanks.  are arm64 and armel requestable, or no?
[23:50] <teward> wgrant: ^ if you're there (you processed the request)
[23:50] <wgrant> teward: armel is dead; if you want armel you're confused.
[23:50] <wgrant> I can do arm64, but qemu-user-arm64 isn't very reliable yet.
[23:51] <teward> wgrant: was asking because there's one weirdo using armel >.<
[23:51] <wgrant> Tell them they're confused :P
[23:51] <wgrant> qemu is slow, I'd prefer not to enable an extra expensive arch because a single person is using a dead arch :)
[23:51] <teward> wgrant: that's on my list :P
[23:51] <teward> wgrant: should be fine with armhf
[23:52] <teward> ooooo interesting... depwait in precise for this... o.o
[23:52] <teward> wgrant: if arm64 becomes reliable in the future i might request it, but.
[23:52] <wgrant> teward: Given qemu-user-arm64's unreliability, and the unavailability of any affordable usable hardware atm, I'd suggest holding off on it unless you really feel you need it.
[23:52] <wgrant> Yep
[23:52] <teward> wgrant: read my mind
[23:52] <teward> hate depwaits though
[23:53] <teward> oh well that explains it, FTBFS in armhf in precise


[22:44] <mup> Bug #1480616 opened: juju with RackSpace configuration <juju-core:New> <https://launchpad.net/bugs/1480616>


[08:09] <slomo> pitti: can we get gstreamer0.10 and gst-plugins-bad0.10 synced again? :) the latter only is the final release now, no code changes only translation updates... the former is http://freedesktop.org/cgi-bin/viewcvs.cgi/gstreamer/gstreamer/libs/gst/base/gstbasetransform.c.diff?r1=1.127&r2=1.128  (http://bugzilla.gnome.org/show_bug.cgi?id=557649)
[08:18] <pitti> slomo: default answer is "no, needs to go into SRU" now; slangasek coordinates CD builds now, so if it's super-urgent, you need to convince him :)
[08:18] <pitti> slomo: but I don't think it's a release breaker, is it?
[08:28] <slomo> pitti: no, it would be just nice to have... sru sounds good then ;)
[08:41] <mvo> seb128: did you get my mail about gnome-terminal ?
[08:41] <seb128> mvo: no
[08:43] <mvo> seb128: hm, let me bounce it to you again
[08:43] <seb128> ok
[08:43] <seb128> or discuss on IRC directly?
[08:47] <mvo> seb128: is it there now?
[08:47] <seb128> mvo: I'm working on an evolution bug fix upload which has to land before the next publisher run in 15 minutes so wait
[08:49] <mvo> seb128: ok, sorry for being pushy, I was just a bit worried that my mail might be broken (or eating mails)
[08:55] <huats> morning all
[08:55] <huats> hey crevette
[08:55] <huats> o/ seb128
[08:55] <crevette> hello there
[08:55] <seb128> lut huats
[08:57] <seb128> mvo: ok, got the mail this time, I might have spammed it before by mistake or something
[08:58] <seb128> mvo: it's late now for changes, keeping the current version seems fair enough
[08:58] <mvo> thanks
[09:42] <pochu> pitti, slomo: hello! gst-plugins-bad is not on the CDs ;)
[09:42] <pochu> (it's in universe)
[10:27] <Laney> mvo: Hey, didn't manage to catch you before. I guess updating g-t is out (reading the above)?
[10:29] <mvo> laney: did you get my mail?
[10:29] <mvo> laney: unless I miss something the current version is good, no?
[10:29] <Laney> I think it has a crash bug
[10:29] <Laney> but other than that, basically yes
[10:30] <mvo> laney: hm, which bit (or commit) of 2.24.1 -> <IP_ADDRESS> is that?
[10:31] <mvo> laney: I went through the diff and my impression was that its just a revert of the previous commit
[10:31] <Laney> Hold on, I'm just testing
[10:31] <mvo> laney: if there is a crash fix missing, I will do a SRU
[10:35] <Laney> mvo: It seems fine, my bad.
[10:35] <mvo> excellent, thanks for testing laney
[10:35] <mvo> and sorry that this all took so long to resolve, but its busy times :)
[10:35] <mvo> (or time?)
[10:35] <Laney> I understand
[10:35] <Laney> "it's a busy time"
[10:36] <Laney> I expect a bug about the missing keybinding editor options though
[10:37] <mvo> right, we will have to point them to gconf (or you could do a version in your PPA or the gnome team PPA) with the editor
[10:39] <Laney> I don't have access to the gnome team PPA
[10:40] <Laney> but I'll just push what's in the bzr branch to mine
[10:41]  * mvo nods
[10:42] <Laney> Ooh! Couple of interesting kernel talks at uni today
[10:42] <Laney> someone from redhat is here
[14:09] <tedg> mpt: So, if we use "Available" should the "Offline" got "Unavailable" then?
[14:09] <tedg> I guess that's what busy is for.
[14:09]  * tedg lines "disconnected" but that's probably too long.
[14:09] <mpt> What's wrong with Offline?
[14:09] <tedg> s/lines/likes/
[14:10] <tedg> It seems like Online and Offline match.  Changing one should imply changing the other?
[14:10] <mpt> ah
[14:10] <mpt> but no
[14:11] <mpt> That was precisely why Online needed changing: because it *wasn't* the opposite of Offline.
[14:13] <tedg> Okay, I can see that.
[16:10] <asomething> Anyone know what happened to gnome-font-viewer? I think it was part of gnome-control-center. I still have a desktop file for it in my menu, but the program doesn't appear to exist any more. I don't see anything in gnome-control-center's changelog about it being removed...
[16:11] <dobey> there was never a gnome-font-viewer in gnome-control-center afaicr
[16:12] <dobey> if there's a menu item still in your menu, it's probably because you customized/created it at some point, and it's till in your ~/.local/share/applications/ folder
[16:12] <asomething> hmmm... the desktop file has these fields: X-GNOME-Bugzilla-Product=gnome-control-center
[16:12] <asomething> X-Ubuntu-Gettext-Domain=gnome-control-center-2.0
[16:13] <dobey> hrmm. i don't know. perhaps it was a part of the fonts:/// vfs thing, and that was in control-center
[16:16] <awalton__> it was
[16:16] <asomething> it is in ~/.local/share/applications/ folder, so it's not a bug in the upgrade process. I must have added it myself. Though I'd still like to the program. I guess I'll just have to use gnome-specimen or something. thanks...
[16:16] <awalton__> fontilus and the theme one too lived in g-c-c
[16:21] <asomething> hmmm... gnome-specimen doesn't seem to be able to look at uninstalled fonts. any ideas for a  gnome-font-viewer replacement?
[17:08] <lapo> hi
[17:09] <seb128> hey lapo
[17:09] <lapo> ciao seb128
[17:09] <Keybuk> seb128: who is upstream for xchat-gnome?
[17:09] <Keybuk> is there one?
[17:09] <lapo> I just upgraded to intrepid, nice work guys slick upgrade
[17:10] <lapo> Keybuk: David Trowbridge IIRC
[17:11] <lapo> purplecow or something on irc
[17:11] <seb128> Keybuk: nobody is really working on it nowadays, cassidy was working on it some months ago but stopped since apparently, chpe did code cleaning and update but he does that randomly on GNOME components so I would not call him a maintainer either
[17:11] <seb128> Keybuk: why?
[17:12] <Keybuk> it really annoys me that when you focus the window, the notification icon goes away
[17:12] <Keybuk> even if you don't read the message it was notifying you about
[17:12] <Keybuk> so I fixed it :p
[17:12] <cassidy> I think chpe is the one closer the be the new xchat-gnome maintainer
[17:12] <Keybuk> now the notification icon stays as long as you have unread messages
[17:12] <cassidy> as nobody else worked on it since months
[17:13] <seb128> Keybuk: bugzilla it
[17:14] <Keybuk> it's sufficiently invasive that I didn't really want to do that without talking to the maintainer
[17:15] <seb128> Keybuk: try talking to chpe on the gnome irc then
[17:15] <Keybuk> thanks
[17:22] <seb128> mvo: bug #289950, can you look if you get the issue when using alsa? I bet that's another pulseaudio issue
[17:26] <mvo> seb128: sure, give me a sec (you are quick!)
[17:29] <mvo> seb128: hm, does not seem to make a difference, but I get some debug output I think
[17:30] <seb128> mvo: can you get a stacktrace of totem while it's hanging?
[17:30] <mvo> seb128: hm, looks ike it does not honor when I switch with gstreamer-properties to alsa
[17:30] <mvo> the message is "gst_pluseink_prepare()
[17:30] <seb128> stop pulseaudio the time to try?
[17:31] <mvo> http://paste.ubuntu.com/63316
[17:33] <mvo> killal pulseaudio
[17:33] <mvo> helps
[17:34] <seb128> ok, either gstreamer, alsa or pulseaudio then
[17:35] <seb128> I think I got the issue in a virt-manager while trying the rc too
[17:35] <seb128> I've no real clue what is to blame but since that's only an issue when trying to play sound on a machine which has no soundcard I think I'll not bother too much for intrepid
[17:36] <seb128> you can restart your pulseaudio ;-)
[17:59] <jcastro> Is packagekit a blessed gnome dependancy yet?
[18:02] <dobey> jcastro: i don't think so
[18:02] <crevette> jcastro, nope
[18:02] <dobey> jcastro: http://live.gnome.org/TwoPointTwentythree/ExternalDependencies
[18:03] <jcastro> thanks guys


[08:49] <smartboyhw> Finding some bugs to play with (fixing) ca n I do Bug 1137716?
[08:49] <_mup_> Bug #1137716: Code page suggests using invalid bzr flag --use-existing <bzr> <lp-code> <trivial> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1137716 >
[11:42] <cjwatson> smartboyhw: Generally I think you can just go ahead, at least for simple things like that that don't involve major reengineering
[11:42] <smartboyhw> cjwatson, :)
[11:43] <smartboyhw> cjwatson, done and merge proposal proposed.
[11:44] <smartboyhw> How come the merge proposal went timeout!?!!?!??!
[11:49] <cjwatson> I don't know.  Do you have an OOPS id?
[11:49] <czajkowski> smartboyhw: whats the oops id ?
[11:49] <czajkowski> \o/
[11:49] <smartboyhw> czajkowski, cjwatson anyway I think it works now:P
[11:50] <cjwatson> LP's own code tends to hit pathological cases in the code component, unfortunately
[11:50] <cjwatson> (Lots of revisions, lots of merges)
[11:50] <smartboyhw> .....
[11:50] <StevenK> smartboyhw: I'd prefer a lot less brevity in the MP description.
[11:50] <smartboyhw> StevenK, brevity = ?
[11:50] <cjwatson> After pushing an LP branch it's often necessary to delete it after a while and push again
[11:51] <cjwatson> (But not in this case - I mean if it fails to scan the branch)
[11:51] <cjwatson> smartboyhw: Please follow https://dev.launchpad.net/PatchSubmission
[11:51] <cjwatson> brevity = shortness
[11:51] <smartboyhw> cjwatson, OK sorry
[11:53] <smartboyhw> Is this Lint thing strange?
[11:53] <smartboyhw> Missing ./download-cache.
[11:53] <smartboyhw> Developers: please run utilities/link-external-sourcecode.
[11:53] <smartboyhw> make: *** [download-cache] Error 1
[11:53] <smartboyhw> smartboyhw@smartboyhw-Compaq-Presario-CQ41-Notebook-PC:~/launchpad$ ./utilities/link-external-sourcecode
[11:53] <smartboyhw> Usage: link-external-sourcecode [options] [parent]
[11:55] <cjwatson> You need to run it in the branch you're changing
[11:55] <cjwatson> And it will help if your branches are in the conventional layout
[11:56] <cjwatson> You ought to have a clean devel branch locally, and do your work in a separate local branch of that
[11:56] <cjwatson> Rather than e.g. just branching lp:launchpad directly and then pushing the result back
[11:57] <cjwatson> https://dev.launchpad.net/Running


[00:37] <blair> tumbleweed, opened 5 tickets, last one for pyside-tools is https://bugs.launchpad.net/bugs/925206
[00:55] <Riddell> blair: why do you care about pyside out of interest?
[00:56] <blair> Riddell, we're moving a PyQt 3 app to pyside instead of pyqt and i'm also trying to get our facility to move from fedora 13 to 12.04, so i want the latest version available
[00:56] <Riddell> blair: why are you moving an app to pyside?
[00:56] <blair> we have an app already, it's just in pyqt3
[00:57] <blair> are you asking why pyside instead of pyqt?
[00:57] <Riddell> blair: right
[00:58] <Riddell> on terminology PyQt3 means python bindings for Qt 3, I expect you mean PyQt4 with Python 3?
[00:59] <blair> yes, PyQt3 means Python 2.x with Qt3 bindings
[00:59] <Riddell> oh I see
[00:59] <blair> and the choices are moving to Python 2.x with PyQt4 or pyside
[00:59] <Riddell> so you're porting to Qt 4 as well as PyQt -> PySide
[00:59] <blair> we're not looking to move to python 3
[00:59] <blair> yes
[01:00] <Riddell> which still leaves the question of why PySide and not PyQt4
[01:00] <blair> i understand you can code them with a shim layer that can work with either
[01:00] <blair> but pyside has nokia developers
[01:01] <blair> off to a meeting, can discuss more later
[01:04] <Riddell> blair: you should be able to just change the import and it'll work with either (mostly)
[01:04] <Riddell> but PySide is losing its Nokia support and it's unknown if it can survive as a community project http://lists.pyside.org/pipermail/pyside/2011-December/003259.html
[01:05] <Riddell> whereas PyQt has a well established company behind it
[01:05] <Riddell> (one man company)
[01:54] <blair> Riddell, there's one advantage to pyside, it's LGPL while pyqt is GPL
[01:56] <blair> Riddell, didn't know about them loosing support, we decided 3-4 months ago to go with pyside and haven't started the porting effort, so this is news
[08:01] <dholbach> good morning
[08:02] <geser> Guten Morgen dholbach
[08:02] <dholbach> hey geser :)
[08:02] <ajmitch> hi dholbach, geser
[08:03] <geser> Hi ajmitch
[11:04] <_rahmat_> hi everyone. i'm using quickly in ubuntu 10.04 and following video tutorial in http://developer.ubuntu.com everything work fine, until I type quickly package, quickly get error with error message "An error has occured during package building ERROR: package command failed Aborting" here is screenshot of quickly http://paste.ubuntu.com/826217/ . Any idea? thanks
[14:32] <alucardni> hello, is there a way to use bzr behind a proxy???
[14:52] <dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek Day 3 (last day) starting in 8 minutes in #ubuntu-classroom
[15:49] <Zhenech_> mh, is there no backport of a dh_python2 enabled python to lucid?
[17:01] <tumbleweed> debfx: Been running update-rdepends with your patches
[17:01] <tumbleweed> so far 707MB, and I started it 4 hours ago :P
[17:01] <tumbleweed> (compared to 287)
[17:02] <tumbleweed> ah, and it finished
[17:47] <Rhonda> hmm.  I have issues with my wesnoth-1.10 backport.  It will require packaging changes because of the droids fonts changed their install path in precise.
[17:48] <Rhonda> It will require two changes in debian/rules and the different package name in debian/control.  Would that be acceptable for backports?
[18:18] <micahg> Rhonda: yes
[18:18] <micahg> Rhonda: just attach a debdiff to the backports bug
[21:18] <ScottK> jtaylor: So are you going to fix Debian Bug#639995 in Ubuntu then?
[21:18] <jtaylor> ScottK: already working on it
[21:18] <ScottK> Excellent.  Thanks.
[21:48] <Laney> iulian: http://www.haskell.org/pipermail/glasgow-haskell-users/2012-February/021764.html ? ;-)
[21:51] <iulian> Uh!
[22:25] <directhex> Laney, does it have a stable ABI yet?
[22:26] <Laney> nah who needs that
[22:27] <iulian> :)
[22:28]  * Laney wonders why dist-upgrade wants to remove half the world
[22:30] <stgraber> Laney: can you define "half the world"?
[22:30] <Laney> quite precisely, yes
[22:30] <Laney> http://paste.debian.net/154552/
[22:31] <stgraber> Laney: that looks like glib
[22:31] <stgraber> or maybe gtk, both were uploaded earlier
[22:31] <stgraber> Laney: yep, just got the same here, that's indeed glib
[22:32] <Laney> what about it? skew?
[22:33] <Laney> ah, I need to wait for gtk to read me
[22:33] <Laney> reach
[22:33] <stgraber> I don't see anything stuck in new, so yeah, I'd thing it's an archive skew
[22:35] <Laney>     - Breaks on gtk << 3.3.12, glib and gtk needs to be updated together
[22:35] <Laney>       due to the gmenu parser changes
[22:40]  * ajmitch shall be careful not to blindly upgrade today :)
[22:42] <stgraber> upgrading just after a freeze is usually a bad idea ;)
[22:42] <ajmitch> upgrading just after feature freeze has to be about the worst
[22:43] <ajmitch> hopefully there won't be too much breakage around freeze time in precise, but it's usually a bit chaotic
[22:43] <stgraber> agreed :)
[22:55] <broder> can we slap somebody for not staging massive breakage like that in a PPA?
[23:02] <RAOF> broder: I think that should become standard practice, yes.  Possibly once we have the ability to get things *out* of a PPA into the archive, though.
[23:02] <broder> oh, i didn't realize that was unusually difficult
[23:02] <Laney> is it?
[23:02] <broder> we also talked about staging transitions in -proposed pre-release, which presumably wouldn't suffer from those problems
[23:02] <Laney> Possibly copyPackage is broken with include_binaries=True
[23:02]  * ajmitch thought it still required some manual intervention copying to the archive
[23:03] <Laney> but syncSource works afaik
[23:03] <RAOF> Yeah.
[23:03] <RAOF> When we wanted to copy the X stack out of staging we needed an archive admin to do the deed.
[23:03] <Laney> I'll try copyPackage when I next get a chance
[23:04] <RAOF> Also we'd really want armel/armhf to be working for virtualised PPAs first; otherwise we just dump the breakage on architectures we don't test as a matter of daily routine, and which are hard pressed to build things :)
[23:05] <broder> RAOF: but s/PPA/-proposed/ would have worked for you guys, right?
[23:05] <RAOF> I think so?
[23:06] <RAOF> I mean, I'm fairly sure it'd work for *me*, but that's because I have archive admin privs.
[23:17] <broder> oh, should copyPackage theoretically work just using your standard upload privileges?
[23:18] <Laney> ye
[23:18] <broder> fancy


[03:27] <TowerPower> Hi, I'm trying to set up a basic upstart job to launch a tmux session. In pre-start, I'm running 'tmux has-session -t foo' and then testing the exit code. Problem is, when the code is 1 (failed), the script stops. I guess I want to make sure that that's expected behaviour, reading the docs I can't find any reference to a command in a script failing making the whole job fail. Any suggestions to workaround?
[03:31] <TowerPower> I misspoke on the exit code. Perhaps a more succinct way of putting it is: if pre-start contains the line false (exit code 0), the whole job fails. Is that expected behaviour and is there a way to make the job not fail?
[05:21] <JanC> TowerPower: upstart runs all scripts with "/bin/sh -e"
[05:26] <JanC> from the manual: """script ... end script / This stanza defines the process to be run as a shell script that will be executed using sh(1).  The -e shell option is always used, so any command that fails will terminate the script."""