[01:59] <Kano> hi,did you patch busybox in order to boot from ext4?
[02:16] <MattJ> http://paste.ubuntu.com/165234/
[02:17] <MattJ> Anyone an idea of what might be going wrong?
[02:20] <andersk> Maybe your pbuilder chroot is missing universe?
[02:21] <MattJ> Any idea how to add/check that? :)
[02:22] <MattJ> I've had pbuilder working before, and I think I did exactly the same as last time
[02:23] <andersk> `pbuilder --login` might be the easiest way.
[02:23] <MattJ> libidn11-dev is in main
[02:23] <MattJ> Ah
[02:23] <andersk> txt2man is not.
[02:32] <MattJ> Is there something I can do to make it persist? Changes seem to be lost as soon as I log out
[02:32] <MattJ> I guess I should go find some pbuilder manual :)
[02:32] <MattJ> I was following the packaging guide on the wiki
[02:34] <Hobbsee> use --save-after-login
[02:34] <Hobbsee> !pbuilder
[02:35] <MattJ> Thanks
[02:42] <MattJ> andersk: Looks like you were right, thanks :)
[02:50] <pedahzur> Hi!  Is there a similar kubuntu-devel list, or is it all done on this channel?
[02:51] <Hobbsee> pedahzur: sure, #kubuntu-devel
[02:52] <Hobbsee> and there's a kubuntu devel mailing list, in the same place as the ubuntu devel list
[02:52] <pedahzur> Hobbsee: Thanks...for some reason it didn't come up when I listed channels.  I should have just tried to join it. Sorry for the noise.
[02:52] <Hobbsee> pedahzur: no problem.  good luck!
[02:53] <pedahzur> Thanks!
[03:35] <the_dark_warrio> What is the Image Magick package for ubuntu?
[03:35] <TonyTheTiger> hello is this channel for development of ubuntu?
[03:36] <Pici> TonyTheTiger: yes.
[03:36] <Hobbsee> the_dark_warrio: apt-cache show imagemagick
[03:36] <TonyTheTiger> I am interested in writing a driver for a device i have, I dont mind taking time to learn how to do it.
[03:38] <the_dark_warrio> Hobbsee: Sorry, I'm looking for the dev packages.. I tried installing libmagick-dev, libmagick++-dev, libmagic-dev, etc. But everytime I install a new lib, I get another error trying to compile the code
[03:43] <TonyTheTiger> is there a channel for driver development for ubuntu?
[03:43] <Hobbsee> the_dark_warrio: i don't know, you'd have to give a pastebin of the errors
[03:44] <the_dark_warrio> Hobbsee: I'm getting help on Inkscape channel, I will see if they know what is the bug
[03:45] <Hobbsee> the_dark_warrio: OK, cool.  They'd probably know better anyway
[03:51] <the_dark_warrio> Hobbsee: thanks, I think I got it working now
[03:52] <Hobbsee> the_dark_warrio: hurrah!
[03:52] <the_dark_warrio> Hobbsee: ;) cia!
[03:59] <calc> can i get someone to process libbase-openoffice.org it is a new package that has built
[03:59] <calc> Hobbsee: do you have access for that? :)
[05:57] <calc> ooo 3.1.0~rc2-1ubuntu1 in process of uploading now :)
[05:58] <jdong> shiny!
[05:58] <jdong> will there be a PPA build?
[05:59] <calc> yea for h/i/j
[05:59] <calc> now i just have to upload around 600MB over my crap dsl
[05:59] <TheMuso> ouch
[06:01] <nixternal> dput-torrent :p
[06:02]  * calc wished he had access to somewhere will really good upload speed for times like this
[06:02]  * nixternal has 6mb up
[06:02] <calc> i have 512k :\
[06:03] <nixternal> though you can't tell when doing dput
[06:03] <nixternal> ya, 512 wouldn't cut it for me after getting used to 6mb
[06:04] <StevenK> calc: Get a VPS and rsync your uploads to it?
[06:08] <StevenK> % sudo rm -f /dev/sdb
[06:08]  * StevenK twitches a little
[06:08] <calc> StevenK: well i do upload to a server before dput but it still takes forever, i guess if i did all my building on a remote server it would be faster but then i would have to download any time i needed to test the packages
[06:09]  * calc just needs to move somewhere with fios
[06:09] <StevenK> calc: If your downstream connection is much faster, that sounds worthwhile
[06:10] <calc> well downstream is only 3M so not too much better
[06:10] <StevenK> calc: Find a better wet string?
[06:13] <Amaranth> hahahaha
[06:13] <calc> i'm about 800ft too far away to get 18/1
[06:13] <Amaranth> ouch
[06:14] <calc> i had faster internet than this 9 years ago :\
[06:14] <calc> back then i had 8/1 dsl
[06:14] <Amaranth> i've got 5/0.5
[06:15] <StevenK> Mine is roughly 6/256k
[06:16] <Amaranth> I used to have 3/256k so I'm moving up
[06:27] <Keybuk> cjwatson: heh, forgot to upload ;)
[06:27] <pitti> Good morning
[06:27] <pitti> NCommander: hi
[06:27] <NCommander> hey pitti, what's up?
[06:28] <pitti> NCommander: you pung me over night
[06:28] <TonyTheTiger> Hello guys how hard is it to write a driver for a device? (assuming I have programming background, but no experience in this topic)
[06:28] <NCommander> pitti, I think I was curious if I needed something spnsored but I don't remember
[06:31] <calc> pitti: can you approve libbase-openoffice.org (its stuck at new)
[06:37] <TonyTheTiger> Where can I view the source code to a driver?
[06:48] <maxb> i386 buildd has caught up :-)
[06:48] <lifeless> maxb: :)
[06:48] <lifeless> maxb: are you still contributing to cygwin?
[06:49] <pitti> TonyTheTiger: most device drivers are in the linux kernel nowadays (you can browse it in gitweb, or apt-get source linux); but there are all kinds of other drivers around (such as libgphoto for PtP cameras) which live in userspace; you have to be more concrete
[06:50] <maxb> lifeless: No, I fully extricated myself from Windows a while back
[06:51] <lifeless> I appear to have finally done that today
[06:51] <TonyTheTiger> pitti, I want to get my controller supported in ubuntu so I thought Ill go ahead and add support for it myself. Sick and tired of people tell me "do it yourself".
[06:53] <calc> ok in about 5 hours all 4 copies of OOo should magically appear, the three in the ppa and in karmic
[06:53]  * calc is headed to bed now
[07:18] <YokoZar> "All right here's a weird "bug" for you, if you want to call it that. The notifications cause my clock radio, which is about 5 feet away from my tower, to emit an audible vibration and buzzing noise. "
[07:24] <pwnguin> hahahaha
[07:28] <savvas> is it usb connected or wireless :p
[07:32] <dholbach> good morning
[08:37] <smb> Anybody knows by heart what method/config normally should start metacity and gnome-panel? After playing around with the desktop-switcher this does not happen automatically...
[08:40] <pitti> smb: gnome-session usually starts those through some .desktop files; seb128 would know more details
[08:40] <pitti> smb: ah, nevermind
[08:40] <pitti> smb: it's a gconf setting in gnome-session, /desktop/gnome/session/required_components_list
[08:41] <pitti>          <default>[windowmanager,panel,filemanager]</default>
[08:41] <seb128> right
[08:41] <seb128> the base composents are in gconf keys
[08:41] <seb128> autostart is for everything else
[08:41] <smb> Hm, I thought I saw those being there...
[08:48] <smb> seb128, Looking into the gconf-editor I find those keys. But it does not seem to happen. Any log files I might look into?
[08:48] <seb128> what did you change to break it ?
[08:48] <seb128> does it work for an another use on your box ?
[08:49] <smb> repeatedly using the desktop-switcher to go from the unr desktop to the standard and back
[08:49] <smb> seb128, let me add one and try
[08:49] <seb128> you can use the guest session to try
[08:50] <seb128> njpatel: ^ what is that desktop switcher doing?
[08:50] <seb128> it seems smb managed to unset required gconf keys by using it
[08:50] <njpatel> seb128: apart from screwing up some peoples desktops in it's current version in jaunty, it switches from netbook mode to classic mode (normal ubuntu look)
[08:51] <njpatel> seb128: I've already fixed the bug, and StevenK was going to help with an SRU
[08:51] <smb> njpatel, So it is a known "feature" then? :)
[08:51] <njpatel> (i've fixed it in a way that it repairs existing breakage too)
[08:51] <njpatel> smb: unfortunately. Couldn't get it in before release
[08:51] <njpatel> i hope we can get an sru soon
[08:52]  * njpatel hasn't done sru before, so any help would be appreciated
[08:52] <pwnguin> got the bug number handy?
[08:52] <seb128> njpatel: can you explain what to do change to manually fix it?
[08:52] <StevenK> njpatel: Step one: Fix it in Karmic
[08:52] <smb> Just was about to ask
[08:53] <njpatel> https://bugs.edge.launchpad.net/desktop-switcher/+bug/349519
[08:54] <njpatel> seb128: pwnguin ^
[08:54] <njpatel> StevenK: I've already made a release of desktop-switcher with the bug fixed, could we get that into karmic?
[08:54] <StevenK> njpatel: It's on LP?
[08:55] <pwnguin> heh
[08:55] <njpatel> StevenK: yep,it should be
[08:55] <StevenK> njpatel: Certainly, I'll do it tomorrow.
[08:55] <pwnguin> is stevenK still allergic to lp?
[08:55] <njpatel> StevenK: thanks!
[08:55] <StevenK> I was allergic?
[08:55] <pwnguin> perhaps my memory is foggy
[08:56] <pwnguin> it is 3am here
[08:56] <smb> njpatel, Thanks for the link. Looking at the runes now
[08:56] <njpatel> awesome, thanks
[08:57] <pwnguin> this raises a question for me
[08:57] <pwnguin> if a bug is known upstream and affects ubuntu
[08:57] <pwnguin> hmm. i should find, read and then quote what i saw earlier
[08:58] <pwnguin> rather than attempt to do anything from memory right now
[08:58] <StevenK> njpatel: Doing it now, since ... I don't know :-P
[08:58] <njpatel> :)
[09:00] <pwnguin> ""
[09:00] <pwnguin> thanks for the report, but there's no need to open the bug on Ubuntu if there's already one on the upstream bug tracker, it only creates extra work for developers and triagers, thanks.
[09:01] <pwnguin> how does that mesh with the SRU process?
[09:01] <StevenK> It should be tracked in Ubuntu Karmic and Ubuntu Jaunty for the SRU process
[09:02] <pwnguin> https://bugs.launchpad.net/ubuntu/+source/evolution-mapi/+bug/351493
[09:02] <pwnguin> i guess i dont understand what the triager is asking for on this bug
[09:02] <pwnguin> dont report bugs in LP if they're already upstream in bugzilla?
[09:03] <StevenK> njpatel: I'm going to twiddle that bug to add a desktop-switcher task for Karmic and Jaunty.
[09:03] <StevenK> njpatel: The Karmic task will get closed after I upload
[09:03] <njpatel> okay, thanks. and I'll hassle seb128 later on today :)
[09:04] <maxb> Well, there's no real point reporting to LP if it's already upstream, *unless* it's for the specific purpose of nominating for SRU
[09:06] <seb128> pwnguin: there is no need to report upstream bugs in launchpad if they are already known upstream yes
[09:06] <StevenK> njpatel: Uploading
[09:06] <StevenK> s/ing/ed/
[09:09] <smb> njpatel, cool, manually fixed it here. thanks
[10:04] <cjwatson> pitti: would you mind if I disabled pkgsanitychecks for udebs? http://launchpadlibrarian.net/26375427/buildlog_ubuntu-karmic-i386.rootskel-gtk_1.15ubuntu1_FAILEDTOBUILD.txt.gz is an interesting build failure - the udeb just installs a /usr/local/etc symlink to work around some problem elsewhere
[10:05] <pitti> cjwatson: no problem at all
[10:05] <cjwatson> pitti: while this should probably be dealt with so it doesn't need to do that, none of the checks in pkgsanitychecks really seem all that important for udebs; it's not as though it's important to provide the sysadmin with an area where his local changes will be preserved :-)
[10:05] <pitti> exactly
[10:05] <cjwatson> (I've uploaded rootskel-gtk with NO_PKG_MANGLE=1 for now, but ...)
[10:06] <pitti> I think udebs just weren't taken into consideration when this was written
[10:06] <cjwatson> this is the first time I've noticed it failing
[10:06] <cjwatson> is there a bzr branch for pkgbinarymangler?
[10:06] <pitti> no, this isn't in bzr
[10:06] <cjwatson> ok
[10:17] <pitti> Keybuk: \o/ system-tools-backends finally dropped its init script
[10:50] <pitti> cjwatson: intrepid-proposed doesn't have a matching d-i for the -14 kernel; how important is it to be in sync?
[10:51] <pitti> cjwatson: the kernel team asked me to move the -proposed kernel to -updates, but I stalled it because I wasn't sure about the impact of this
[10:57] <cjwatson> pitti: there's one in the queue ...
[10:58] <cjwatson> the problem with them getting out of sync is that the installer images previously published in intrepid-updates will break
[10:59] <cjwatson> it won't break people using the images in dists/intrepid/, but I know there are some people using the images in intrepid-updates, due to bug 293586 if nothing else
[10:59] <cjwatson> so I like to keep them in sync
[10:59] <cjwatson> people would still have to download fresh installer images; there isn't much to be done about that
[11:04] <pitti> cjwatson: ok, I'll accept the upload for that (thanks), and let it build, before I move it then
[11:05] <pitti> cjwatson: also, I was told that after copy-package'ing d-i for hardy, there's some extra magic necessary to copy the netboot images; is that documented somewhere?
[11:05] <pitti> I'm sure I did that once like a year ago, but I'm afraid I forgot it
[11:24] <ebroder> pitti: for bug #362691, I guess I need to get approval from ubuntu-sru again?
[11:25] <pitti> ebroder: haven't looked at the patch yet
[11:25] <ebroder> Ah, ok. No worries, then
[11:25] <pitti> ebroder: but usually, it's more a question of finding a sponsor to upload it
[11:25] <cjwatson> pitti: documented on ArchiveAdministration now
[11:25] <pitti> (someone from server team, preferably)
[11:25] <pitti> cjwatson: thank you
[11:29] <pitti> ebroder: commented now
[11:31] <ebroder> pitti: The version numbering still needs to be consistent, right? So this would still be 3.3.0-1ubuntu9.2, not 3.3.0-1ubuntu9.1?
[11:32] <pitti> ebroder: right, 9.1 got burned now
[11:45] <Keybuk> pitti: sweet
[13:12] <lamont> Keybuk: debian bug 527229
[13:23] <soren> Why is it that /etc/localtime is a copy of a timezone file rather than a symlink to it? Is it to make sure things don't fall apart before /usr is mounted or is there more to it than that?
[13:23] <cjwatson> soren: your hypothesis is correct
[13:25] <ion_> Let’s get rid of /usr already. :-P
[13:27] <directhex> ion_, http://gobolinux.org/?page=at_a_glance
[13:28] <cjwatson> note how it has no users ;-)
[13:28] <cjwatson> (to a first approximation)
[13:28] <ion_> directhex: Capital letters in filenames are just bad as long as we have a case-sensitive filesystem. Or have they changed that as well?
[13:31] <directhex> dunno
[13:31] <directhex> but points for doing something different!
[13:31] <directhex> not sure how LSB-compliant they are ;)
[13:47] <Keybuk> lamont: oh?
[13:47] <Keybuk> lamont: well, firstly I sent you a patch to use /dev/rtc0 rather than /dev/rtc <g>
[13:48] <Keybuk> lamont: ask them what hwclock --debug --rtc=/dev/rtc0 says?
[13:48] <soren> cjwatson: Lovely, thanks.
[14:28] <Keybuk> seb128: how do I debug telepathy/jabber not working?
[14:28] <Keybuk> it just says "Network error"
[14:28] <Keybuk> but it doesn't even look like it's starting telepathy-gabble
[14:30] <cjwatson> mvo: funky apt-ftparchive failure in http://launchpadlibrarian.net/26391921/buildlog_ubuntu-karmic-armel.debian-installer_20081029ubuntu35_FAILEDTOBUILD.txt.gz
[14:30] <cjwatson> apt-ftparchive: symbol lookup error: /usr/lib/libstdc++.so.6: undefined symbol: __sync_fetch_and_add_4
[14:31] <mvo> cjwatson: sweet
[14:31] <mvo> cjwatson: I have a look
[14:32] <cjwatson> ta
[14:32] <seb128> Keybuk: http://telepathy.freedesktop.org/wiki/Debugging
[14:32] <cjwatson> slangasek: d-i is in place on i386 now; awaiting build on amd64
[14:33] <ogra> oooh, there is an image build attempt from last night !
[14:33]  * ogra didnt notice yet
[14:33] <cjwatson> it won't be very useful
[14:33] <ogra> the desktop one ?
[14:33] <cjwatson> err, and where do you see this attempt? :)
[14:33] <ogra> http://cdimage.ubuntu.com/ports/daily-live/20090506
[14:34] <seb128> Keybuk: or ask Zdra or cassidy on the #ubuntu-desktop channel ;-)
[14:34] <cjwatson> oh, a livefs build attempt
[14:34] <cjwatson> http://cdimage.ubuntu.com/ports/daily-live/20090506 is pretty useless since it was still trying to build for jaunty
[14:34] <ogra> yeah, i just see that
[14:34] <ogra> old kernel and all
[14:35] <cjwatson> I changed cdimage to default to karmic this morning
[14:35] <ogra> ah
[14:35] <ogra> ok, waiting for the explosion of the image with teh next build then :)
[14:35] <cjwatson> mvo: FWIW, apt-xapian-index is currently uninstallable due to insufficient versions of python-apt and python-debian
[14:36] <james_w> there is a sponsor request open for the python-debian merge
[14:39] <mvo> cjwatson: thanks
[14:39] <mvo> cjwatson: I take care of this too (the python-apt merge is almost ready)
[14:40] <cjwatson> hyperair: I'm syncing nautilus-share, since it seems possible now and the older version causes livefs build problems (http://people.ubuntu.com/~ubuntu-archive/livefs-build-logs/karmic/ubuntu/latest/livecd-20090506-i386.out)
[14:45] <calc> hmm really uploading now, i forgot that i needed to adjust the at time due to uploading from a server not in my own timezone :-\
[15:10] <hyperair> cjwatson: sure.
[15:11] <xaaab> Hi. I've been using 8.04 for a long time without problems. but since my upgrade to 9.04, my xorg has a memory leak. when I leave it running for several hours it consumes almost 5 gb of ram and it consumes a lot of CPU time, although I'm not at my PC. is this a known issue? any fixes?
[15:12] <pitti> xaaab: it certainly doesn't happen for everyone in that magnitude
[15:13] <cjwatson> you might want to use xrestop to find out whether it's actually the X server's fault directly or whether it's due to some application leaking pixmaps into X
[15:14] <soren> xrestop, eh?
[15:14]  * soren apt-gets
[15:14]  * xaaab just did
[15:15] <xaaab> cjwatson, so... when I start xrestop, I just have to watch what the "total" column says and identify the culprit?
[15:17] <cjwatson> it's a place to start to avoid embarrassingly claiming that it's the X server's fault when it's actually a particular application, anyway. I'm no expert so have no more help to offer :)
[15:26] <calc> ok all of OOo is uploaded now and waiting to build
[15:55] <mok0> Why does "Build-Depends: a | b" fail, even though b is available?
[15:59] <mok0> Ah sbuild does that by default.
[16:00] <slangasek> cjwatson: yippee :)
[16:07] <directhex> mok0, s/by default/because it hates humans/
[16:08] <directhex> mok0, as far as sbuild is concerned, anything after a | in a build-dep may as well be a comment
[16:08] <mok0> directhex: it appears you can change its behaviour... but I can't get that to work either
[16:09] <TheMuso> dtchen: we have 1.0.20 of alsa. I will check tomorrow to see if there are any kernelspace/userspace differences that need to be sorted before we can bump to 1.0.20.
[16:09] <mok0> directhex: sbuild -d karmic --check-depends-algorithm=alternatives
[16:09] <mok0> grrrrr
[16:10] <directhex> mok0, convince all the debian buildd admins to make that happen and we'll talk
[16:10] <mok0> directhex: sounds like you know something I don't
[16:12] <cjwatson> we hacked it in Ubuntu to fall back to non-primary alternatives
[16:12] <cjwatson> but that was precisely because we weren't Debian
[16:13] <cjwatson> I mean, the fact that it's done in Ubuntu is not a demonstration that it should be done in Debian - we were doing it because in places we wanted to specifically avoid the primary alternative in Ubuntu
[16:13] <mok0> cjwatson: it seems that doesn
[16:13] <mok0> t work...
[16:13] <cjwatson> in Debian, I fail to see why you wouldn't just put the alternative you want first!
[16:13] <mok0> cjwatson: right
[16:13] <cjwatson> mok0: used to, talk to infinity if you have a clear demonstration of the problem
[16:14] <mok0> cjwatson: "infinity" is a nick, right? :-)
[16:14] <ogra> heh
[16:14] <cjwatson> yes
[16:14] <ogra> for a person, yes
[16:15]  * apw goes a bit mad ... anyone know what is driving OSD for volume?
[16:15] <mok0> infinity: are you here?
[16:15] <apw> (audio volume)
[16:15] <ogra> apw, hal ?
[16:15] <ogra> (just a guess)
[16:15] <apw> i can't see it doing it ...
[16:16] <apw> it seems to generate a hal event for the volume-up key
[16:16] <ogra> dbus-monitor should show where its coming from
[16:17] <ogra> apw, gnome-settings-daemon it seems
[16:17] <ogra> at least for my system here
[16:17] <apw> hrm ... obviously
[16:17] <apw> thanks ogra
[16:17] <slangasek> cjwatson: the libgnomecanvas2-dbg binary on amd64 is timestamped May 6 01:05, which seems to postdate your new-binary-debian-universe fix; strange
[16:18] <cjwatson> any archive admin remember accepting libgnomecanvas/amd64?
[16:20] <seb128> I didn't
[16:29]  * pitti didn't
[16:33] <directhex> wasn't me
[16:43] <jdstrand> pitti: hi! can you look at the debdiff I attached in bug #224365? I'd like to upload, but wanted to make sure I didn't step on your toes. :)
[16:45] <pitti> jdstrand: well, someone already uploaded an ubuntu specific package, so that's fine
[16:46] <pitti> jdstrand: I'll commit the changes to bzr and sync them back from debian soon
[16:46] <pitti> jdstrand: so please go ahead
[16:48] <jdstrand> pitti: thanks! :)
[16:50] <jdstrand> pitti: looking at this, would you prefer I upload based off of jaunty's ubuntu3?
[16:50] <jdstrand> pitti: karmic still has the sync'd version from jaunty
[16:50] <jdstrand> (ubuntu1)
[16:50] <pitti> jdstrand: you can, but it really doesn't matter much; I'll thrash the ubuntu specific version soon anyway :)
[16:51] <pitti> jdstrand: so in fact, if you don't consider it super-urgent, just add the debdiff to the bug and assign it to me
[16:51] <pitti> and I'll get it done tomorrow
[16:52] <jdstrand> pitti: no, it isn't super urgent. I'll assign it to you to reduce archive churn
[16:52] <pitti> jdstrand: argh, I'm not going to apply that -- dac_override?
[16:53] <pitti> jdstrand: that's precisely what I don't want to give to hacks like cups-pdf
[16:53] <jdstrand> pitti: yeah, it is required when $HOME is 700
[16:53] <pitti> *shrug* then don't set it to 700 :)
[16:53] <pitti> 701 is fine as well, you also need it for public_html and such
[16:53] <jdstrand> pitti: sure, but the problem is that the error message is totally cryptic for the end user
[16:53] <pitti> jdstrand: I really wouldn't like to see cups-pdf getting more privs that it absolutely needs
[16:54] <pitti> jdstrand: that should probably be improved then, yes
[16:54] <jdstrand> pitti: basically, the user sees nothing in the ui
[16:54] <jdstrand> pitti: and then in kern.log, has:
[16:55] <jdstrand> kernel: [33228.304167] type=1503 audit(1241581234.818:31): operation="capable" name="dac_override" pid=4905 profile="/usr/lib/cups/backend/cups-pdf"
[16:55] <jdstrand> to me, that doesn't scream 'you need to chmod 701 your directory' :)
[16:58] <jdstrand> pitti: also, this isn't as simple as "don't chmod 700 your directory" because encrypted home directories via ecryptsfs do precisely that, and I think in karmic, kirkland is hoping to make this generally available
[16:59] <jdstrand> of course, he could 701 it...
[16:59] <pitti> jdstrand: can we just kill cups-pdf then? :-)
[17:00] <kirkland> jdstrand: sorry, do i need to catchup with this conversation?
[17:00] <jdstrand> pitti: well, interestinly enough, I tried to do that with an important user of mine (my wife) who has an application that doesn't use the gnome print UI, and had no way to print to pdf without cups-pdf.  Feel free to 'Invalid'ate if you think that is the best course (I certainly see your point of view)
[17:03] <pitti> jdstrand: well, I'll ponder it
[17:03] <pitti> jdstrand: if the apparmor rules restrict access to /home thoroughly, it's probalby not too bad
[17:03] <pitti> but it would be able to write stuff into /etc or other places which teh profile doesn't cover
[17:05] <lamont> slangasek: default-mta provides and exim4/postfix... le sigh, and yeah, I guess their argument wins
[17:05] <lamont> sadly
[17:05] <slangasek> which argument?
[17:06] <slangasek> I think default-mta as a stand-alone package would be a little better for derivs
[17:06] <jdstrand> pitti: I'm looking at the profile, and I don't see that you gave rw to anything in /etc, so I don't think that is a problem
[17:21] <slangasek> mvo: hmm; using the update-manager in jaunty-updates, I just had a weird experience where update-manager wanted me to have 50MB free on /usr when the actual update only required 123KB additional space
[17:22] <mvo> slangasek: 123kb addtional diskspace + 49mb downloaded debs? or were allt the debs downloaded already?
[17:22] <mvo> slangasek: is it reproducable?
[17:23] <slangasek> mvo: the .debs added up to < 5MB in size
[17:23] <slangasek> dunno; I can try downgrading those packages later to see
[17:24] <mvo> slangasek: right, sorry, I just checked the source and it has this as a safety buffer (min 50mb free) - I admit its a bit much
[17:24] <slangasek> ah
[17:25] <mvo> slangasek: its a leftover from the days when the free space checker would only check for release upgrades, then 50mb extra was ok, but for normal updates with just 4 pkgs its not
[17:25]  * mvo adds it to his todo list
[17:25] <slangasek> want a bug report? :)
[17:25] <mvo> slangasek: feel free :)
[17:25] <mvo> slangasek: otherwise I will file it to my postit notes :)
[17:26] <slangasek> ok :)
[17:30] <kees> asac: how do I get n-m TO manage my wired interface?  it seems to ignore it now
[17:36] <asac> kees: guess you havent configured that in /etc/network/interfaces?
[17:47] <kees> asac: in /etc/network/interfaces it says: auto eth6  and   iface eth6 inet dhcp
[17:48] <kees> aarg
[17:48] <asac> kees: so eth6 is the device you want to see managed by NM?
[17:48] <kees> asac: right
[17:49] <asac> kees: do you need it to be configured in there? otherwise just remove the eth6 entry from interfaces
[17:49] <kees> asac: ah, no, don't need it in there.  removing it will fix n-m to use it again?
[17:50] <asac> kees: yeah. NM runs in ifupdown-unmanaged mode by default. so everything configured in there will be ignored. two ways to fix this: a) remove that configureation (preferred), b) enable managed mode in /etc/NetworkManager/nm-system-settings.conf
[17:51] <kees> ah-ha, yes, I see the "managed=false" setting now.  the semantics for what n-m keeps changing.  :)  thanks, I'll give "a)" a shot.
[17:51] <asac> kees: that didnt change since it was introduced ;)
[18:39] <jdstrand> pitti: ok, I played with dac_override a little bit to make sure my understanding is correct
[18:40] <jdstrand> pitti: if dac_override is not set, then DAC is checked first. if DAC doesn't permit it, then no access. if DAC does allow it, then the profile is checked and access is determined there
[18:40] <jdstrand> pitti: if dac_override is set, then DAC simply is not consulted and only the profile is checked
[18:41] <pitti> jdstrand: right; root has DAC_OVERRIDE usually, which is what allows him to ignore file permissions
[18:41] <pitti> so if we give that priv, the policy can't rely on DAC any more, and needs to be super-tight
[18:41] <jdstrand> pitti: apparmor requires explicitly allowing access to files, so unless the profile is too loose to begin with, there shouldn't be a problem
[18:41] <jdstrand> pitti: correct
[18:42] <jdstrand> pitti: however, looking at the cups-pdf policy, it looks super-tight anyway
[18:43] <jdstrand> pitti: so, I'll defer to your judgement, but adding dac_override seems ok to me based on the current profile
[18:43] <pitti> jdstrand: I'll look at it again
[18:43] <pitti> jdstrand: sorry, have to run to sports now
[18:43] <jdstrand> pitti: np. have fun! :)
[18:43] <pitti> jdstrand: thanks for the investigations!
[18:45] <jdstrand> pitti: sure! this actually served as dual-purpose cause I'm going to be working on a test-apparmor.py script this week and dac_override will be part of the tests :)
[19:47] <slangasek> mvo: do you have plans to merge python-apt soon?  (breaks apt-xapian-index)
[20:15] <mvo> slangasek: yes, its almost ready
[20:16] <calc> is there a lpia live cd somewhere?
[20:33] <slangasek> mvo: cool, thanks
[20:37] <chrisccoulson> if i propose to merge a bzr branch in to another one (say, my branch in to an ubuntu-core-dev branch), should i assign a reviewer to it? does anyone get notified of the merge proposal if i don't specify a reviewer?
[20:42] <ScottK> Every core-dev gets notified.
[20:42] <chrisccoulson> ScottK - thanks:)
[20:51] <james_w> chrisccoulson: the default reviewer of an ubuntu-core-dev branch is ubuntu-core-dev which leads to a mail to ubuntu-devel@ now, so plenty of people see it
[20:51] <james_w> however, we need to do better at having a list of outstanding requests, which is something I am working with the LP team on
[20:52] <chrisccoulson> james_w - thanks. perhaps i would have been better off assigning a reviewer rather than spamming the whole list;)
[20:53] <james_w> chrisccoulson: it makes sense if there is a particular person. It would be a bit like subscribing that person directly to a sponsorship bug instead of u-m-s, except that u-m-s doesn't cause a mail to ubuntu-devel@
[20:54] <ScottK> james_w: I'm glad to hear you are working on this.  Thanks.
[20:55] <james_w> np
[20:55] <james_w> I'd like to have a better system that what we currently have
[20:55] <james_w> it's just not that easy because we are slightly odd :-)
[20:57] <ScottK> I think distro 'development' is different in many respects than upstream development and LP seems more focused on the latter use case than the former.
[20:57] <james_w> yeah
[20:57] <james_w> especially for merge proposals so far, as it wasn't available for distributions before
[20:57] <james_w> they are keen to fix that, there just aren't obvious answers
[20:59] <mweichert> hello, I'm trying to preseed a hardy installation. I want to slipstream all of the hardy updates on the cd so that after I finish the installation, I'm not left with 200+ packages to upgrade.
[20:59] <mweichert> to do this, do I just replace /dists and /pool on the live cd with those that are in archive.ubuntu.com ?
[20:59] <james_w> mweichert: nope, the live install doesn't install from debs
[21:00] <james_w> you would need to build a new live environment with the updates
[21:00] <mweichert> james_w, okay, in the squashfs image?
[21:00] <mweichert> james_w, what's /dists and /pool for then?
[21:00] <james_w> yeah
[21:01] <james_w> extra packages that are available, but not actually installed
[21:01] <mweichert> hmm, ok
[21:01] <mweichert> james_w, so the installer just copies the squashfs to /target, is that right?
[21:02] <james_w> not "just", no, but to a first approximation, yes
[21:04] <mweichert> james_w, sorry - that was over-simplifying.. I guess what I'm trying to determine is that if I edit the squashfs by installing the debs I want, those debs will get installed on /target.
[21:04] <mweichert> james_w, is that a safe assumption you think?
[21:04] <james_w> I've no idea whether it will work, sorry
[21:08] <MattJ> Hmm, does anyone know if it is possible to build for etch using the Ubuntu pbuilder?
[21:08] <MattJ> The wiki suggests it should be, but I'm having problems
[21:08] <james_w> it should be
[21:09] <mweichert> james_w, okay, thanks for your help. I really appreciate it. I've been having a hard time trying to find this information.
[21:09] <mweichert> james_w, to be sure though, you're certain that /pool just contains extras?
[21:10] <james_w> mweichert: I guess there aren't enough debs in there to make a full system?
[21:10] <ScottK> MattJ: Yes.  I do it all the time.
[21:10] <MattJ> From: https://wiki.ubuntu.com/PbuilderHowto it says use: sudo DIST=etch pbuilder create, but the first line pbuilder prints is "Distribution is jaunty."
[21:10] <james_w> if there were then you would only be able to use the half the space on the CD for the live environment.
[21:11] <MattJ> ScottK: I'm using 8.04, could that be an issue?
[21:11] <james_w> mweichert: #ubuntu-installer is the dedicated channel for this stuff
[21:11] <ScottK> MattJ: I did it with that too, so I don't think so.
[21:12] <MattJ> ScottK: I see: Failed getting release file http://gb.archive.ubuntu.com/ubuntu/dists/etch/Release
[21:12] <MattJ> I tried --othermirror, but it seems to have no effect
[21:12] <ScottK> MattJ: http://pastebin.com/f78072aa4 is the pbuilder wrapper script I use.  If you name that pbuilder-sid it should just work.
[21:13] <MattJ> Hmm, I'll try it... thanks :)
[21:15] <MattJ> ScottK: Excellent, it appears to be working :)
[21:16] <ScottK> MattJ: Glad to hear it.
[21:21] <calc> kees: can you process bug 372756 for me? pitti told me it didn't need a MIR
[21:24] <ScottK> Did we decide 1.37 is the target boost for Karmic?
[21:24] <calc> ScottK: well we really need to be targeting 1.38 for Karmic but its FTBFS atm
[21:24] <ScottK> Since Debian is planning on 1.38 for Squeeze, I wonder if it might be better.
[21:24] <ScottK> Agreed.
[21:24] <calc> and 1.35 also seems to cause other things to FTBFS if they attempt to use it due to gcc 4.4 (afaict)
[21:25] <kees> calc: one sec...
[21:25] <calc> kees: thanks
[21:26] <kees> calc: approved
[21:26] <calc> thanks :)
[21:26] <kees> np
[21:33] <calc> http://cdimage.ubuntu.com/daily-live/current/ <- is that actually karmic or are we doing new dailys of jaunty?
[21:34] <james_w> karmic
[21:34] <calc> probably the description needs updating then :)
[21:35] <calc> and filenames, etc
[21:36] <james_w> oh, maybe the ones there aren't karmic then
[21:36] <james_w> there was a karmic CD build last night though
[21:37] <slangasek> daily-live/current isn't karmic in any meaningful sense
[21:37] <slangasek> we don't have successful livefs builds yet
[21:40]  * calc wonders why ubuntu-mir doesn't also have archive access to do the promotions, heh
[21:41] <calc> slangasek: so since 327756 is approved now... could you maybe promote it for me, please? 8-)
[21:41] <slangasek> calc: wrong bug #?
[21:42] <calc> er 372756
[21:42] <slangasek> calc: anyway, the process is MIR approval -> reference the package from main -> ends up on component-mismatches -> ubuntu-archive cleans it up
[21:43] <calc> the references from main is a package depending on it, or something else?
[21:43] <slangasek> depends, build-depends, or seeded
[21:44] <calc> ok, so yea OOo 3.1.0~rc2-1ubuntu1 already does that via build-depends
[21:44] <calc> i somehow forgot to add that to bug report
[21:45] <calc> added to the bug report
[21:50] <james_w> calc: it's already on component-mismatches, it should get cleaned up next time an archive admin processes the list
[21:51] <calc> ok
[22:02] <bigon> http://launchpadlibrarian.net/26409322/buildlog_ubuntu-karmic-i386.telepathy-farsight_0.0.6-1_FAILEDTOBUILD.txt.gz << I know I've already asked but why this packages build cleanly inside a pbuilder?
[22:03] <bigon> hahah
[22:04] <bigon> obscédé par la repression
[22:05] <james_w> bigon: different versions of cdbs installed?
[22:05] <bigon> oups wrong channel for the 2last sencence :p
[22:05] <bigon> james_w: I don't think so
[22:06] <NCommander> james_w, its also pkgbinmanagler doing something it shouldn't
[22:06] <ajmitch> NCommander: it's nor very verbose about it
[22:06] <NCommander> Hrm
[22:07] <NCommander> bigon, which PPA is that package in?
[22:07] <NCommander> Oh, thats a distro upload, isn't it :-P
[22:07] <james_w> NCommander: what is pkgbinarymangler doing that it shouldn't?
[22:08] <bigon> NCommander: yeah
[22:08] <NCommander> james_w, I dunno, I'm going to try and reproduce with a buildd chroot and a normal pbuilder chroot
[22:08] <james_w> bigon: do you have pkgbinarymangler installed in your pbuilder?
[22:09] <NCommander> james_w, there are other pieces of voodoo in the chroots :-/
[22:10] <bigon> james_w: I don't think so
[22:10] <james_w> NCommander: yeah, but this seems to be a simple case of a file being installed in the wrong place and pkgsanitychecks complaining
[22:10] <james_w> bigon: well, that's the reason then
[22:10] <NCommander> james_w, I've *never* seen a build fail because of that before
[22:11] <james_w> well, we fixed most of them
[22:11] <NCommander> james_w, we should provide a set of instructions on how to reproduce buildd chroots
[22:11] <james_w> true
[22:11] <NCommander> (there is a lot of voodoo with the lpia especially)
[22:12] <james_w> it needs autoreconfing
[22:12] <james_w> that should fix it
[22:14]  * NCommander continues to work on merges
[22:14] <james_w> nope, that's not right
[22:15] <NCommander> james_w, ?
[22:16] <calc> can someone process a couple NEW packages for me (there is a long chain of build depends) - libloader-openoffice.org and libformula-openoffice.org
[22:19] <DktrKranz> bigon, that's because python2.6 expects to find modules in dist-package, not site-packages and pkgbinarymangler rejects it
[22:24] <bigon> DktrKranz: yeah but on my pbuilder without pkgbinarymangler I get an explicit message saying that the files inside the site-packages have been moved to dist-packages
[22:27] <DktrKranz> bigon, weird. did you use python.mk macros?
[22:28] <DktrKranz> $(call py_libdir, <python version>) and thelike
[22:29] <bigon> http://pastebin.com/f7bc52325
[22:30] <DktrKranz> it doesn't seem to use distutils, right?
[22:32] <bigon> no autotools
[22:33]  * DktrKranz tries to build it in a karmic pbuilder
[22:34] <bigon> already done
[22:34] <bigon> same result it works inside it
[22:39] <slangasek> calc: will you be coordinating getting the other reverse-deps of boost1.35 transitioned, too, so we don't have to continue carrying that one?
[22:42] <james_w> heh, it's some quoting weirdness
[22:43] <james_w> bigon: it does $PYTHON -c "from distutils import sysconfig; print sysconfig.get_python_lib(0,0,prefix='$PYTHON_PREFIX')"
[22:44] <james_w> which is supposed to return ${prefix}/lib/python2.6/dist-packages
[22:44] <james_w> but returns site-packages instead
[22:44] <bigon> mmm
[22:44] <james_w> well, not quoting weirdness, but that confused my investigation
[22:45] <james_w> will it want ${prefix} in the path, or is that supposed to be expanded in this path?
[22:46] <bigon> I can confirm that inside my pbuilder it FTBFS with pkgbinarymangler installed
[22:46] <james_w>         elif is_default_prefix and 'PYTHONUSERBASE' not in os.environ and 'real_prefix' not in sys.__dict__:
[22:46] <james_w>             return os.path.join(libpython, "dist-packages")
[22:46] <james_w>         else:
[22:46] <james_w>             return os.path.join(libpython, "site-packages")
[22:46] <james_w> in distutils
[22:46] <BUGabundo> hi everyone
[22:46] <rrp81> hi!
[22:46] <BUGabundo> so todays backport-modules reverted all the good of rt2500 pci??
[22:46] <BUGabundo> on jaunty
[22:46] <james_w> so if you pass it /usr as the path, not '${prefix}' you get dist-packages, otherwise you get site-packages
[22:47] <james_w> which seems to be what python wants
[22:47] <BUGabundo> apw: ping
[22:47] <rrp81> today's updates screwd up backport-modules, I can't update them or revert them
[22:47] <rrp81> I need them for my rt2500 pci
[22:47] <BUGabundo> rrp81: you can downgrade it.
[22:48] <BUGabundo> just get the previous version from LP cache
[22:48] <rrp81> no, i can't, it won't let me
[22:48] <james_w> so telepathy-farsight trying to preserve '${prefix}' leads to the wrong path being used, and as distutils isn't used cdbs' disutils.mk can't clean it up
[22:48] <james_w> bigon: does that make sense?
[22:48] <BUGabundo> $ sudo dkpg -I linux.......deb
[22:52] <bigon> james_w: I've not followed everything :o
[22:52] <james_w> bigon: you have two easy options, either make it expand ${prefix} before passing it in there
[22:53] <james_w> or add a mv in debian/rules (or something with .install) to fix it up
[22:53] <james_w> I'm not clear on what the effects of the first will be given the fact that it is done that way currently
[22:54] <bigon> james_w: yeah but without binpkgmangler the file are automagically moved
[22:54] <james_w> by what?
[22:55] <james_w> pkgbinarymangler is throwing it out at dpkg-deb time, so it's too late to move by then isn't it?
[22:55] <james_w> I'm not sure that it interferes before
[22:55] <bigon> let me check again
[22:58] <calc> slangasek: i'm not really in platform (more or less) for the next 6 months
[22:58] <slangasek> oh?
[22:58] <slangasek> I guess I missed that memo
[22:58] <calc> slangasek: moved to oem with doko and persia
[22:59] <slangasek> ... but still dealing with OOo? :)
[22:59] <calc> i have 20% time for OOo but i doubt that would be enough to do OOo and boost traisntion, not even enough to do bug triage really :\
[22:59] <slangasek> ok
[22:59] <calc> gah typing too fast to see my words leads to typos, heh
[22:59] <BUGabundo> sorry to hear calc! I did a great job up until now
[23:00] <calc> slangasek: but ideally we will be doing a transition from 1.35/1.37 to 1.38
[23:00] <slangasek> ah
[23:00] <calc> 1.38 currently FTBFS though :\
[23:03] <calc> slangasek: aiui 1.37 is supposed to be removed from Debian sometime soon
[23:03] <slangasek> hmm, ok
[23:03] <slangasek> I'll have a look at the 1.38 ftbfs, then
[23:03] <NCommander> calc, thats a nasty FTBFS :-/
[23:12] <directhex> boost?
[23:16] <calc> directhex: yea
[23:16] <directhex> have fun. extra fun thanks to apps build-depending on specific versions of boost rather than the un-abi'd -dev packages
[23:18] <BUGabundo> ok, what's boost?
[23:20] <calc> directhex: iirc the un-abi'd version is 1.34
[23:20] <calc> yea 1.34.1
[23:20] <calc> BUGabundo: http://www.boost.org/
[23:23] <directhex> calc, i'll bite: "why is the default (un-ABI'd version) neolithic?"
[23:24] <dtchen> TheMuso: from a prelim glance, current git HEAD of linux-2.6 is nearly 1.0.20 without some quirks, but the core and mid-layer are identical
[23:25] <calc> directhex: no idea
[23:25] <calc> directhex: probably for historical reasons
[23:25] <dtchen> TheMuso: i'm chasing a -plugins sig11 atm
[23:25] <directhex> calc, historical raisins be damned, this is ubuntu, not debian!
[23:25] <calc> directhex: it may be versioned for newer ones due to api changes (my guess anyway)
[23:26] <calc> directhex: if is the case it explains why they didn't bother to fix it for 1.34 since the proper fix would be to have no libboost-dev at all
[23:26] <slangasek> nono, the proper fix would be to have no libboost.* at all ;)
[23:27] <directhex> slangasek, <partisan> oh dear, then no gnote. what a dreadful shame!
[23:27] <mathiaz> slangasek: hm - IIUC there is a library transition (or something like that) currently hapening in debian wrt to the upload krb5 1.7 to unstable
[23:27] <directhex> calc, that seems horribly broken to me - version the deps, fix the software
[23:27] <mathiaz> slangasek: what does this mean for Ubuntu?
[23:28] <mathiaz> slangasek: ie - I'd like to get krb5 1.7 synced in karmic.
[23:28] <slangasek> mathiaz: should just require rebuilds, I think
[23:29] <mathiaz> slangasek: IIUC the main point is that krb4 is dropped
[23:29] <slangasek> yep
[23:30] <mathiaz> slangasek: so - what should I do to get things moving? Ask a sync request and upload all necessary packages?
[23:30] <slangasek> mathiaz: sounds right :)
[23:31] <mathiaz> slangasek: should I test that all necessary packages build before asking for the sync to happen?
[23:31] <mathiaz> slangasek: or ask for the sync and start uploading once the new krb5 is published?
[23:31] <slangasek> mathiaz: the latter is fine
[23:32] <mathiaz> slangasek: great - thanks. I'll go get the list of packages to rebuild :)
[23:32] <directhex> what's the policy on upstream versions for gnome? gnome 2.28 seems to be coming out terribly close to release
[23:33] <ajmitch> directhex: usually gnome releases at the same time as the beta release for ubuntu
[23:34] <ajmitch> afaik there's a standing exception for getting new upstream releases of gnome in
[23:34] <directhex> ajmitch, short version: will tomboy 1.0.0 (part of gnome 2.28) definitely be allowed in, and if so, is it worth making a 0ubuntu1 of the latest development release?
[23:35] <ajmitch> directhex: ask an RM :)
[23:35] <directhex> slangasek, i think he means you!
[23:36] <slangasek> directhex: if tomboy is releasing on time with GNOME 2.28, then yes, please track its dev releases
[23:36] <directhex> gotcha
[23:42] <mathiaz> slangasek: hm - I'm not sure I completely understand how the libkrb53 is done in debian.
[23:42] <mathiaz> slangasek: relevant changelog entries are 1.6.dfsg.4~beta1-7, 1.6.dfsg.4~beta1-8, 1.7dfsg~beta1-2 and 1.7dfsg~beta1-3
[23:43] <mathiaz> slangasek: the last entry mentioned an change that will be reverted before end of may 2009.
[23:55] <apachelogger> james_w: do you know if there is any script to create released branches of a given set of development branches (i.e. branch /ubuntu to /jaunty)?
[23:55] <james_w> "bzr branch"? :-)
[23:56] <slangasek> mathiaz: hmm, I'm quite confused by that last entry
[23:57] <slangasek> may have been a no-op, really


[00:03] <visik7> but if a replay fail due to a conflict there is no replay continue like rebase
[00:04] <jelmer> visik7, yes, you can use "bzr rebase-continue"
[00:04] <jelmer> ah, no
[00:04] <jelmer> nevermind
[00:04] <visik7> :\
[00:04] <jelmer> you can commit and run "bzr replay" again though from the point where it aborted
[00:05] <visik7> nevermind seems it's working
[00:05] <visik7> ok I think is ok
[00:06] <visik7> now I need to clean it up branching again ?
[00:06] <igc> poolie: I'd like to rename the (about to be released) diffinternals plugin to crosscheck. Is that ok with you?
[00:06] <poolie> igc, that sounds better to me
[00:07] <igc> poolie: cool. me too.
[00:08] <jelmer> visik7, yeah, branch it to a different location
[00:08] <jelmer> visik7, (replay wasn't really designed for this sort of thing)
[00:27] <visik7> jelmer: I see anyway it worked so, thanks for the help and hope soon we will have something like git-filter-branch
[00:33] <jelmer> visik7, cool
[00:38] <p_masho> can anyone give me a helping hand.. bit confused as used to svn and cvs(spits).......
[00:38] <visik7> good night thank you again jelmer
[00:39] <jelmer> p_masho, hi
[00:41] <p_masho> hi jelmer.. late at night here in wales.. and got this zim on my ubuntu box - http://bazaar.launchpad.net/%7Epardus-cpan/zim/pyzim/
[00:41] <p_masho> so I been hacking away... and have already modified and not creaed a branch...
[00:42] <p_masho> I'm looking for 1) - equivelent of svn copy foo.x bar.x ?
[00:43] <jelmer> p_masho, copying a branch or a file/directory ?
[00:43] <jelmer> p_masho, to copy a branch, use "bzr branch <old-branch> <new-branch>"
[00:43] <jelmer> to copy a file, simple copy it using cp and then add it
[00:44] <p_masho> Ok. advice.. am used to svn.. so be gentle.. please
[00:44] <p_masho> I go this branch bzr branch lp:~pardus-cpan/zim/pyzim = /home/zim/pyzim on my machine
[00:45] <p_masho> so I hacked that a bit and got a diff file.....
[00:45] <jelmer> p_masho, what are you trying to copy? a file?
[00:45] <p_masho> What I want to know is how I can create a new "version" on my machine copying all the mods I got
[00:46] <p_masho> and then restore the master branch to tha release from launchpad...
[00:46] <p_masho> sorrry if this sounds confusing...
[00:47] <p_masho> Suppose the question really is.. first ..
[00:47] <jelmer> sorry, phone..
[00:47] <p_masho> How do I branch off the mods I already done and restore the "main/HEAD" to main repos
[00:48] <lifeless> p_masho: to make a new branch, 'bzr branch'
[00:48] <lifeless> p_masho: e.g. 'bzr branch . ../new-branch'
[00:48] <lifeless> p_masho: if you haven't committed your changes, do so first
[00:49] <lifeless> p_masho: I don't know what you mean about the main repos, you haven't altered the mainline afaict
[00:49] <p_masho> thats the problem (as sv user) I made changes to head...
[00:50] <lifeless> you have?
[01:01]  * Sidnei is away: I'm busy
[01:23]  * igc lunch, etc. - bbl
[01:34] <jelmer> poolie1, hi
[02:37] <poolie1> hi jelmer
[02:37] <poolie1> spiv, thanks for that note!
[02:49] <spiv> poolie1: you're welcome :)
[03:14]  * spiv -> lunch
[03:16] <poolie> spiv, still here?
[03:17] <poolie> to build on that mail, i'd like to get a page like the smart push analysis, that for each scenario says what operations we _should_ be doing
[03:20] <poolie> in other words: we have a list of what is done at the moment and we have some vectors we can apply to them but i'd like to see where the expected endpoint is too
[03:25] <Peng_> Yay. "bzr heads" + ack + sed + bash == easy upgrade from subtrees to rich-roots.
[03:25] <Peng_> "bzr upgrade' would've been even easier, of course. Whinewhine.
[03:26] <jelmer> since lifeless doesn't appear to be here...
[03:26] <jelmer> Peng_: "Patches welcome" :-)
[03:26]  * Peng_ cries
[03:27] <Peng_> Wait, I was upgrading a copy of bzr-svn, so I can blame you for putting me in this situation in the first place! :P
[03:27]  * Peng_ hides
[03:27] <beuno> Peng_, recursive-upgrade?
[03:27] <Peng_> That was actually pretty painless. :)
[03:27] <Peng_> beuno: ?
[03:27] <beuno> I know jelmer doesn't want you to know about it
[03:27] <beuno> but he wrote a plugin
[03:27] <beuno> http://people.samba.org/bzr/jelmer/bzr-recursive-upgrade/trunk
[03:27] <Peng_> Oh?
[03:28] <jelmer> Peng, subtrees is more than just a version string
[03:29] <jelmer> Peng, the inventory format is also different afaik
[03:29] <Peng_> jelmer: So? I don't care. I just want to be able to convert my repos easily. I can live with it burning some extra CPU.
[03:30]  * Peng_ gets grumpy when thinking about this. :P
[03:30] <jelmer> Peng_: I wasn't sure what you were doing exactly, but just editing .bzr/repository-format isn't sufficient
[03:30] <Peng_> jelmer: Yeah, I know. I didn't do that.
[03:30] <jelmer> Ok, I'll shut up then :-)
[03:31] <Peng_> I used "bzr heads" to grab all of the heads, created a new repo and a branch, and used "bzr pull --overwrite -r revid:..." to copy all of the revisions into it.
[03:33] <Peng_> And...let's see...frozenset(bzrlib.branch.open_containing('.')[0].repository.all_revision_ids()) to verify it went well. :)
[03:34] <poolie> lifeless: can you point me to a mail about dev3 making some loggerhead pages much faster?
[03:39] <lifeless> poolie: no, there isn't one
[03:39] <lifeless> poolie: there is a branch with a merge request in LP that makes lh compatible with bb-core
[03:40] <lifeless> poolie: and its --development4 that works for lh, fwiw
[03:41] <beuno> lifeless, about that, I didn't quite understand what you meant
[03:41] <beuno> it breaks with the current bzr
[03:41] <beuno> what is it that I'm missing?
[03:41] <lifeless> beuno: works for me
[03:41]  * beuno tests again
[03:42] <beuno> lifeless, hrm, it seems to as well now for me...
[03:42] <beuno> I'll run the tests and merge
[03:43] <spiv> (back)
[03:45] <lifeless> beuno: :P
[03:45] <poolie> lifeless: but it has been measured to make some pages faster? the diff display, i'd presume?
[03:45] <beuno> lifeless, so I had a b0rked copy of bzr?
[03:45] <lifeless> poolie: unscientifically yes
[03:46] <lifeless> poolie: revision display for instance
[03:47] <beuno> lifeless, merged. Thanks for the patch
[03:48] <beuno> 101  branches owned by 24  people and 1  team, 75  commits by 12  people in the last month
[03:48] <beuno> ^  Loggerhead
[03:48]  * beuno dances
[03:48] <poolie> :)
[03:51] <lifeless> beuno: no probs
[03:51] <hydrapheetz> Hm, tempting to write a bazaar branch browser django app, but laziness D:
[03:56] <lifeless> reuse loggerhead?
[03:57] <hydrapheetz> I should try that.
[03:58]  * beuno thinks "loggerheadlib" and looks at thumper
[04:00] <thumper> why me?
[04:00] <thumper> beuno: JFDI
[04:00] <beuno> thumper, sure sure, and world peace, and all that
[04:00] <beuno> BUT
[04:01] <beuno> there are some interesting opportunities to work on that
[04:01] <beuno> like re-writing the log FILE bit which leaks billions of litres of memory
[04:04] <beuno> maybe during UDS
[04:04] <beuno> lifeless, poolie, will you guys be at UDS?
[04:06] <beuno> ah!  you are!
[04:07]  * beuno starts ploting on how to take advantage of their presence
[04:07] <AfC> Memory being measured in terms of three dimensional volume. Neat.
[04:12] <thumper> AfC: if you squeeze memory enough, you can get liquid out
[04:14] <lifeless> silicon-juice?
[04:59] <Peng_> Hm..what do btree indexes do for Loggerhead?
[04:59] <poolie> they should make it faster
[05:27] <poolie> lifeless: do you know if brisbane-core with vila's changes is now passing all tests, or not quite?
[05:28] <lifeless> poolie: its either close or all passing
[05:28] <lifeless> which isn't really helpful, sorry
[05:28] <poolie> it's approximately helpful :)
[05:29] <lifeless> he made all the intertree ones pass; I don't know about the entire test set though
[05:30] <poolie> me either
[05:47] <Peng_> No, it's not all passing.
[05:53] <Peng_> Um, there were 6 errors and 5 failures total, in test_merge, test_pack_repository and test_repository.
[06:05] <poolie> Peng_: thanks!
[06:05] <poolie> you should fix them :)
[06:42] <Peng_> What would be the use of upgrading bzr.dev to the 1.6 format?
[06:42] <Peng_> Does doing "bzr branch --stacked" require the source branch to support stacking?
[06:54] <abentley1> Peng_: No, but default stacking policies, which Launchpad uses, require that.
[07:00] <Peng_> Oh
[07:00] <vila> hi alla
[07:00] <vila> ?? Hi all :)
[07:01] <Peng_> ...What are default stacking policies, exactly? "bzr branch" will stack by default?
[07:01] <vila> poolie: I think it's "quite close" if merged with a recent bzr.dev, but the failing ones are still a bit hard to fix (I can dig to more precise if you will)
[07:02] <vila> poolie: I think it's "quite close" if merged with a recent bzr.dev, but the failing ones are still a bit hard to fix (I can dig to be more precise if you will)
[07:02] <jml> Peng_: bzr push will.
[07:02] <jml> Peng_: tbh, I haven't tried branch.
[07:04] <Peng_> Oh.
[07:05] <Peng_> ...http://bazaar-vcs.org/bzr/ needs that?
[07:08]  * spiv finishes for the day
[07:12] <spiv> abentley1: I don't have time to give your remoterepo stacking fix a proper review atm, but at a glance it looks good
[07:12] <spiv> abentley1: if it hasn't already had a review by the time I start tomorrow I'll certainly review it then.
[07:12] <abentley1> spiv: Cool
[07:16] <poolie> hi abentley!
[07:16] <abentley> poolie: hi!
[07:21] <lifeless> ciao
[07:22] <lifeless> I'm on leave now ;), I may drop by and chat when playing with pet projects, but I'll be focusing on relaxing and zoning out mainly :)
[07:32] <abentley> lifeless: have fun.
[07:54] <Peng_> lifeless: I know I'm saying this just after you left, but what are you planning to do about group_size in bzr-search?
[08:03] <lifeless> Peng_: right now? nothin
[08:04] <lifeless> abentley: tanks
[08:05] <Peng_> Heh, okay.
[08:29] <igc> night all
[08:31] <Peng_> Good night.
[08:32] <Peng_> Ehhh?
[08:33] <Peng_> I think I may have just figured out the cause of my weird Loggerhead issues: a simple typo. That's what I get for not reading the error messages well?
[08:35] <Peng_> Oh, no, the typo is new, I think.
[08:40] <lifeless> jml: right, one less TUIT; testresources now sorts properly
[08:40] <Peng_> Hm...what's the right way to get a patch into Loggerhead? Usually I just bug someone on IRC. :P
[08:41] <lifeless> push a branch to lp
[08:41] <lifeless> file a merge request in lp
[08:41] <Peng_> :)
[08:48] <mwhudson> man i wish i could just click a button to land that branch
[08:48] <Peng_> Hi. :)
[08:48] <Peng_> See? Bugging people on IRC is more efficient. :P
[08:53] <mwhudson> Peng_: merged, ta
[08:53] <mwhudson> and ooh, the merge proposal is automatically marked merged :)
[08:54] <Peng_> Thanks. :)
[08:55] <mwhudson> Peng_: do you want to join ~loggerhead-team?
[08:58] <Peng_> mwhudson: Meaning I could push to the trunk without needing to go through you?
[08:58] <Peng_> Or just to have a neat badge?
[08:58] <mwhudson> the former
[08:59] <mwhudson> (i don't think ~loggerhead-team has a badge...)
[08:59] <Peng_> No badge? That's no fun. :P
[08:59] <mwhudson> heh
[08:59] <mwhudson> i guess we'd also want you to commit to being happy to assign (c) Canonical on your work
[09:01] <Peng_> I dunno. I don't contribute enough code to be a major review burden. If I ever contributed something large, I'd want it to be reviewed anyway, and my small things aren't really high-priority.
[09:09] <lifeless> mwhudson: I wouldn't tie the things together; surely a committment to stay under the paragraph limit when pushing (until a cc assignment is done) is enough
[09:09] <lifeless> mwhudson: can always uncommit after all
[09:10] <mwhudson> lifeless: true
[09:17] <Peng_> Honestly, I dislike copyright assignments, but I never contribute anything large enough to be worth caring about the rights of anyway. :P
[09:17] <Peng_> (That doesn't mean I'd be unwilling to sign one.)
[09:19] <Peng_> Then I get to the part where I'm not even an adult, so I don't know if I legally *can* sign one, and then I decide to put it off and go watch TV. :\
[09:22] <lifeless> Peng_: adult is a state of mind
[09:24] <Peng_> So when I turn 18, I still won't be an adult? Damn. :(
[09:33] <mwhudson> i don't _think_ there's an age thing with copyright is there?  maybe there is
[09:35] <Peng_> I don't think so either, but copyright assignments are legal document thingies, right? so there might be one there.
[09:36] <mwhudson> hmm
[12:45] <Peng_> lifeless: FYI, I let a "bzr index" of bzr.dev with a group_size of 50 run to completion. It took 54.5 minutes. :D But it peaked at only about 115 MB of RAM. :)
[13:37] <Peng_> lifeless: Also FYI, group_size = 100 took 33:00.01 and used 122 MB of RAM.
[13:59] <rocky> hey... i understand what the push and pull branches that a remembered are, but what is the "submit" branch?
[13:59] <Peng_> rocky: For "bzr send".
[14:00] <rocky> so the first time i pull in merge info from a particular source branch, it gets remembered as the "submit" branch?
[15:51] <lamont> bzrlib/_dirstate_helpers_c.c:7704: warning: dereferencing type-punned pointer will break strict-aliasing rules
[15:51] <lamont> shame on bzrlib
[15:51] <lamont> (one of many, grabbed at random)
[16:10] <Peng_> lamont: Shame on Pyrex.
[16:11] <lamont> ok
[16:11] <lamont> only 104 occurances of type-punned in the log :-(
[16:11] <Peng_> lamont: There are generally fewer warnings with newer versions of Pyrex.
[16:12] <lamont> yeah, that's building 1.9 on hardy
[16:12] <Peng_> But I don't remember ever seeing "type-punned".
[16:12] <lamont> google will tell you what gcc really means there.
[16:12] <lamont> "ZOMG this might not do what you want in some strange corner-case"
[16:12] <lamont> or something like that
[16:14] <jdong> it's a clever feature, not a bug (tm)
[16:14] <lamont> jdong: DENIED
[16:33] <Kinnison> the warning is completely valid
[16:33] <Kinnison> just compile -fno-strict-aliasing if you don't want it
[16:56] <darkness51> Hola a todos, como les va?
[16:56] <darkness51> tengo una duda, cuales son los comandos para usar bzr en forma distribuida
[16:57] <Kinnison> darkness51: ingles?
[16:59] <Jc2k> morning thumper_laptop
[17:03] <darkness51> Kinnison: i am understand english, but i don't write fine
[17:04] <darkness51> what command use form distribute work
[17:05] <Kinnison> darkness51: 'bzr push' can be used to upload your branch to another location. E.g. bzr push sftp://my-fileserver/home/me/projects/mything
[17:08] <darkness51> what is the use of bzr pull??
[17:10] <Kinnison> The 'pull' command lets you fetch changes from a remote branch into your local one. E.g. Pretend I have a project 'proj' and I work on my laptop and my desktop. I have a server and I keep a branch on there for synchronising.
[17:10] <Kinnison> I make a change on my desktop and push it to the server with 'bzr push'
[17:10] <Kinnison> Then on my laptop I can do 'bzr pull' to get the change onto my laptop
[17:11] <Kinnison> Naturally this requires you to tell it the location of the server first time. After that it will remember for itself.
[17:13] <darkness51> ok, thank's Kinnison
[17:14] <elmo> tuna 17:13 ~/scratch % bzr branch lp:~ubuntu-core-dev/livecd-rootfs/trunk/
[17:14] <elmo> You have not informed bzr of your launchpad login. If you are attempting a
[17:14] <elmo> write operation and it fails, run "bzr launchpad-login YOUR_ID" and try again.
[17:14] <elmo> can't it tell? :-P
[17:15] <fullermd> Well, not with the brain of a tuna   :p
[17:15] <Odd_Bloke> My Launchpad login isn't the same as my local login.
[17:18] <beuno> Odd_Bloke, maybe you need to set it in .ssh/config
[17:18] <beuno> Host bazaar.launchpad.net
[17:18] <beuno> User Odd_Bloke
[17:18] <beuno> or whaeva'
[17:18] <elmo> Odd_Bloke: I meant, can't it tell if it's a write operation
[17:18] <Odd_Bloke> elmo: Ah, I see.
[17:18] <Odd_Bloke> Not easily, IIRC. :)
[17:19] <james_w> not with the current layering
[17:30] <jam> morning vila
[17:30] <jam> morning #bzr
[17:30] <jam> markh: what are you still doing up? :)
[17:32] <jam> elmo: We can know that "bzr branch" is a readonly operation. I believe the problem is that people often do a readonly operation, and then shortly thereafter do a write operation which fails, but we have lost the info about the LP url they used to get the branch.
[17:32] <jam> The most common one is:
[17:32] <jam> "bzr co lp:foo"
[17:32] <jam> cd foo
[17:32] <jam> bzr commit -m "this will fail, because of something about HTTP"
[17:33] <vila> jam: morning jam, evening jam (jetlag making me falling asleep again :-/)
[17:34] <jam> vila: sorry to hear that. I do believe I had a harder time coming home than I did going to Sydney
[17:34] <jam> I'm not sure if it is heading East
[17:34] <jam> or if it is coming home to a baby with an ear-infection
[17:35] <jam> my guess is the latter
[17:35] <abentley> Odd_Bloke: if you're using bzr 1.9, you don't need to configure ssh.  At most, you need to launchpad-login again, but any lp: lookup will do that for you.
[17:35] <vila> baby's ear-infections are bad for dad's sleep for sure :-/
[17:36] <abentley> elmo: And no, it can't tell.  We don't "open for write" or "open for read".  We just open, and after that we're dealing with real URLs.
[17:37] <vila> jetlag seems better than last week though, but I have a lot of sleep to catch up since I almost *not* sleep from Saturday morning to Monday morning (including the full day in Singapore as an added bonus for delayed flight :)
[17:37]  * elmo trollingly proposes rich-rich-root which records the original lp: url
[17:37] <elmo> abentley/jam: fair enough :-p
[17:39] <jam> abentley: then again, that may change in the future. We are looking at having a Branch.open_or_create_locked() which would allow us to know that we will be writing to it.
[17:39] <jam> elmo: And yes, we've discussed recording the original lp: url rather than its redirection
[17:40] <jam> vila: ouch on the extra day. I at least managed ~4 hrs of sleep on the plane, and I arrived home at 9pm, which is a great time to reset your internal clock and go straight to bed :)
[17:44] <vila> jam: well, I did sleep well last night, so hopefully I will too this night and be ok tomorrow :)
[17:44] <jam> So did you manage to get out of the Airport in Singapore, or was it just 24-hours of airport-chair pain?
[17:55] <mthaddon> hi folks, I'm getting the following error from config manager - "bzrlib.errors.TagsNotSupported: Tags not supported by BzrBranch5('file:///blah/blah/blah); you may be able to use bzr upgrade." using bzr 1.6.1 - should I "bzr upgrade" that directory?
[17:55] <jam> mthaddon: It sounds like you have a remote source with a newer format than the local source.
[17:56] <jam> And the remote source also has tags included.
[17:56] <jam> (which we are failing to fetch)
[17:56] <jam> I would recommend upgrading to whatever the remote format has.
[17:56] <jam> (You can upgrade even further, but the safe bet is to just stay in step)
[17:56] <mthaddon> jam, how to I verify the remote format version - bzr info?
[17:56] <jam> I'm not sure about how CM works, but perhaps just deleting the branch will recreate it at the right format.
[17:57] <jam> bzr info URL should work, IIRC
[17:57] <mthaddon> thx
[17:57] <beuno> if it's a remote branch, just with http to get the proper format
[17:57] <beuno> bzr+ssh always says nonsense
[17:59] <Peng_> You could use nosmart+bzr+ssh to get the real info.
[18:05] <mthaddon> bzr info bzr+ssh says "Standalone branch (format: unnamed)", bzr info nosmart+bzr+ssh says "Standalone branch (format: pack-0.92)"
[18:06] <Peng_> mthaddon: Run "bzr upgrade" in your local branch then.
[18:06] <vila> jam: well, the airport-chair pain was in Brisbane where they announced 1-hour delay... 7 times :-)
[18:07] <mthaddon> Peng_, that seems to have fixed it - thx
[18:07] <jam> vila: what airline?
[18:07] <jam> and yeah, ouch
[18:07] <jam> if they told you in advance it was going to be 7 hours, you could have at least done something
[18:07] <jam> I guess you at least weren't already *on* the plane
[18:08] <vila> when we finally got to Singapore, the connecting flights were long gone so they transfered us to an hotel and re-book the same flights only 24h later
[18:08] <jam> There was something about JetBlue in the states doing that
[18:08] <vila> Quantas from Brisbane
[18:08] <jam> http://gettingtomaybe.blogspot.com/2007/02/jet-blue-delay.html
[18:08] <jam> Quote: News broke last week that passengers on Jet Blue flights were subjected to 10 hour delays inside the plane, while on the runway.
[18:08] <tetha_> ouch, thats even worse than my regular train delays
[18:08] <jam> It was a big deal, as they didn't even have food for the passengers, etc.
[18:09] <jam> Since they are budget flights
[18:09] <vila> The hotel were nice, but I was so sleep deprived already that I only half enjoyed the sight-seeing in Singapore :-)
[18:10] <vila> Quantas did pretty well, giving vouchers in Brisbane for refreshments and so on, the hotel was nice too (even if I ended up in a smoking *level*, ha ha the irony)
[18:10] <tetha_> oops, now I did it. my proof for tomorrows algorithm class finally brake apart
[19:40] <jelmer> jam, What happened to your "This week in Bazaar" posts?
[19:44] <lamalex> anyone experience with LP here
[19:44] <lamalex> nm, i'll go to #launchpad
[19:44] <lamalex> sorry
[20:21] <jelmer> crap, I just realized I'm halfway through reimplementing Subversion in Python..
[20:24] <LarstiQ> jelmer: ai
[20:24] <fullermd> A painful realization, to be sure.
[20:25] <fullermd> 'course, you could always reimplement half of git in python to recover  :p
[20:25] <dobey> or you could just fix bugs in bzr and make it fast
[20:57] <jml> lifeless: sweet
[20:58] <jml> lifeless: does it solve the TSP or what?
[20:59] <jml> bzr alias upll="pull"
[20:59]  * LarstiQ has bpvl aliased
[21:03] <thumper> LarstiQ: to what?
[21:04] <LarstiQ> thumper: bzr pull -v | less
[21:04] <mwhudson> jelmer: because writing libsvn bindings is too painful?
[21:05] <thumper> jelmer: how is the bzr-git work going?
[21:36] <jelmer> thumper: Pretty good; I'm working on two things at the moment - getting more familiar with git's pack format to be able to implement that for bzr-git and factoring out code that is shared by bzr-svn and bzr-git
[21:40] <james_w> jelmer: I found git's pack format to be pretty clear when I looked, how are you finding it?
[21:44] <jelmer> james_w, Yeah, it's quite simple
[21:46] <jelmer> btw, I was thinking of renaming the python-git code you originally wrote to "Dulwich"
[21:46] <jelmer> (after the Monty Python sketch about a cocktail party there featuring a Mr and Mrs Git)
[21:46] <james_w> heh :-)
[21:50] <thumper> jelmer: have you talked with Jc2k about git and python?
[21:50] <thumper> jelmer: I think he did something...
[21:50] <thumper> jelmer: or perhaps he was working in C, I'm not entirely sure
[21:50] <jelmer> thumper, Yeah, we talked about it a bit during the summer
[21:50]  * thumper nods
[21:50] <jelmer> thumper, That was indeed in C - based on the upstream git code
[21:51] <thumper> ah ok
[21:52] <eydaimon> Unable to obtain lock chroot-14417232:///srv/bzr/ ... If you're sure that it's not being modified, use bzr break-lock chroot-14417232:///srv/bzr/.... $ bzr break-lock chroot-14417232:///srv/bzr/ ... bzr: ERROR: Unsupported protocol for url "chroot-14417232:///srv/bzr/... that's not terribly useful
[21:52] <eydaimon> how can I get it to break this lock?
[21:52] <jelmer> eydaimon, I think the error message may be a bit clearer in newer versions of bzr
[21:52] <jelmer> eydaimon, generally, you should be able to run "bzr break-lock" on the URL that was giving you problems
[21:53] <abentley> jelmer: Really?  I thought it was still leaking underlying paths in the latest versions.
[21:53] <eydaimon> jelmer: but it says unsupported protocol for url
[21:53] <eydaimon> how do I deal with that?
[21:53] <jelmer> eydaimon, You should be able to run "bzr break-lock" on the URL you were trying to pull from/push to/branch from/etc
[21:54] <eydaimon> ok
[21:54] <abentley> eydaimon: You ignore the URL it specifies.  Use the normal URL for the branch.
[21:54] <jelmer> abentley, Sorry, I must be mistaken then
[21:54] <jelmer> ISTR some patch for this going in
[21:55] <eydaimon> jelmer: thanks, that fixed it
[21:56] <jelmer> eydaimon: You're welcome. Hopefully the URL in that error message will get fixed at some point.
[21:56] <eydaimon> that's probably helpful :)
[22:11] <Lethalman> hello
[22:11] <Lethalman> I have commit A -> B locally, then pushed to the remote repository
[22:12] <Lethalman> I then uncommitted B and committed C
[22:12] <Lethalman> when I push it says of course that branches diverge
[22:12] <Lethalman> how can I force to push A -> C?
[22:12] <beuno_> Lethalman, push --overwrite
[22:12] <bob2> push --overwrite
[22:12] <bob2> if you're sure
[22:12] <Lethalman> ah
[22:12] <Lethalman> yes i'm sure
[22:13] <bob2> or merge from then push to
[22:13] <Lethalman> thanks very much
[22:34] <rockstar> abentley, can you give me a rundown of the proper way to push a loom to launchpad?
[22:39] <abentley> rockstar: the loom must be in format 6.  Then pushing it should work, but won't stack.
[22:41] <rockstar> abentley, I apparently forgot to record before I pushed.  So I deleted the pushed branch, recorded, and pushed again.
[22:41] <rockstar> But when I pull from another system, the loom appears to only have one thread.
[22:42] <abentley> rockstar: I'm the wrong guy to answer this, because I never push looms on purpose.
[22:42] <rockstar> abentley, :)
[23:07] <jfroy|work> jelmer: do I need to set some things up to run bzr-svn's unit tests?
[23:07] <jfroy|work> I'm getting failures across the board
[23:07] <jelmer> jfroy|work, no, just run "bzr selftest --starting-with=bzrlib.plugins.svn"
[23:12] <jfroy|work> jelmer: eh, it didn't even make it to the end :p
[23:12] <jfroy|work> OSError, "too many files open"
[23:13] <jelmer> I've never run the testsuite on Mac OS X, so I'm not sure how well it works there
[23:13] <jfroy|work> Apparently it massively fails.
[23:13] <jfroy|work> Hum, any known issues with Python 2.6?
[23:14] <jelmer> oh, yeah, python2.6 still has issues
[23:14] <jelmer> sqlite3 has slightly different behaviour, for example
[23:14] <jfroy|work> right
[23:14] <jfroy|work> I'll try to run the tests on 2.5
[23:15] <jelmer> I'll be back in ~45 minutes
[23:24] <markh> jam: you here and got a sec?
[23:45] <jfroy|work> jelmer: sent you a merge bundle as the first parter of a workaround for my situation
[23:58] <thrope> is it possible to use local svn repo with bzr-svn


[16:54] <cjwatson> PPA SFTP uploads for the last few hours will have been lost due to a bad upgrade.  Apologies!  Use FTP for now, and reupload
[17:00] <cjwatson> SFTP is working again now after a rollback