[18:00] <kees> jdstran, mdeslaur, sbeattie: meetin' time?
[18:00] <mdeslaur> kees: yessir
[18:01] <kees> okidoky. i'm still reorganizing after conferences
[18:01] <kees> openjdk is out
[18:01] <kees> i'm going to spend this week auditing the kernel some more
[18:01] <kees> and writing trip reports :)
[18:02] <sbeattie> kees: hey
[18:03] <kees> oops, forgot to wait for everyone
[18:06] <jdstrand> o/
[18:06] <kees> whee
[18:06] <kees> okay, that's it from me, basically. mdeslaur is up
[18:06] <jjohansen> \o
[18:07] <mdeslaur> whoops, sorry
[18:07] <mdeslaur> so, I just did my trip report
[18:07] <mdeslaur> and have freetype updates pending, just need to test them
[18:08] <mdeslaur> and will be pushing apache2 that fixes CVE-2009-3555 to the sec-upd-proposed PPA. Once that's done, I'll do some openssl/apache2 testing and then we'll push them to -proposed
[18:08] <mdeslaur> and I'll be testing virt-manager to make sure it works okay with jdstrand's new libvirt
[18:08] <mdeslaur> that's it from me for this week
[18:08] <mdeslaur> jdstrand?
[18:09] <jdstrand> hey
[18:09] <jdstrand> as mdeslaur implied, I got libvirt merged in maverick last week
[18:10] <jdstrand> that has the fixes for what I plan to have in the security update, and I haven't seen any bugs for people upgrading (good)
[18:10] <jdstrand> so I plan to work on libvirt this week, get koffice out today and shadow kees. I may pick up something from the queue if I have time
[18:11] <jdstrand> that's it from me
[18:11] <jdstrand> sbeattie: you're up
[18:11] <sbeattie> last week, I published my first USNs, for openldap and w3m.
[18:11] <jdstrand> \o/
[18:11] <sbeattie> (finally!)
[18:12] <kees> jdstrand: smb is working on kernel patches, but we're blocked a bit by 10.04.1 so we're jumping over what's in proposed
[18:12] <sbeattie> I also fixed up the mysql-testsuite to work properly in maverick and in doing so, fixed up an issue with its apparmor profile.
[18:12] <sbeattie> I then integrated the testsuite into qa-r-t, though it takes about 2 hours to run here.
[18:12] <kees> sbeattie: \o/
[18:13] <sbeattie> I'm on triage this week, though I'm taking 1.5 days off at the end of the week (going camping)
[18:14] <mdeslaur> sbeattie: whaaaaaaa...you don't bring your laptop with you on camping trips? :)
[18:14] <kees> heheh
[18:14] <sbeattie> mdeslaur: heh, actually, I'm planning on taking it in to the shop to get the backlight fixed while I'm out.
[18:15] <sbeattie> (since I didn't get around to it last week)
[18:15] <sbeattie> That's it for me.
[18:16] <sbeattie> Does anyone else have anything to raise with the security team?
[18:16]  * kees looks around
[18:17] <robbiew> I think that's a no
[18:17] <robbiew> lol
[18:17] <kees> okay then, all done; thanks everyone!
[18:17] <mdeslaur> thanks!


[10:25] <mamarley> ricotz: On a whim I decided to try NVIDIA 396 with xorg 1.20-RC5 and it almost works.  It doesn't even complain about ABI mismatch, but for some reason the GLX module fails to load.
[11:38] <ricotz> mamarley, hmm, a new xserver release without ABI breaks doesn't sound right
[11:38] <tjaalton> are you sure it doesn't already support the abi?
[11:38] <mamarley> ricotz: 1.20 does go from ABI 23 to 24 (and trying to run it with NVIDIA 390 does make an ABI warning).
[11:39] <mamarley> But with both drivers, the GLX module fails to load (it says something about too many errors, despite no errors having been printed in the X log).
[11:42] <ricotz> tjaalton, hmm, I thought the last bump was for 1.19, but yeah, abi 24 is for 1.20 which doesn't mean they broke/finalized it last minute ;)
[11:43] <mamarley> I'm curious as to why the GLX module fails to load if the ABI is supported though.
[11:43] <ricotz> (the bump to abi 24 was done over a year ago)
[11:45] <ricotz> (so don't take this number check for evidence)


[01:25] <neil_d> Hi, I was wondering if there is a URL on how to setup a client with a HDD so it can be used as a server backup ?
[09:58] <stgraber> ogra_cmpc, ogra : bug 201536
[09:58] <ubotu> Launchpad bug 201536 in italc "FF exception, new release of iTalc (1.0.7)" [Undecided,New] https://launchpad.net/bugs/201536
[10:16] <ogra_cmpc> stgraber, seen the bug update ?
[10:16] <ogra_cmpc> :)
[10:32] <stgraber> ogra_cmpc: yeah !!!
[10:32] <ogra_cmpc> :)
[10:32] <stgraber> ogra_cmpc: Upstream will be happy :)
[10:32] <ogra_cmpc> and we too i hope :)
[10:33] <stgraber> I'm just waiting for a patch fixing screen resizing on amd64 (MMX thing) and will upload the new package somewhere so you can have a look at it
[10:33] <ogra_cmpc> good
[10:42] <Nubae> do you think this: /etc/udev/rules.d/88-ltsp.rules - interferes with local automount on a low fat client?
[10:44] <laga> Nubae: i just removed the ltsp-client-core init script instead.
[10:44] <Nubae> entirely?
[10:44] <laga> actually, my solution wa snot to install ltsp-client, i just install ltsp-client-core instead AFAIK
[10:44] <laga> i think
[10:44] <laga> let me check ;)
[10:45] <Nubae> ok, I'm not sure if automounting isn't working because of thin client init scripts or real local automounting not working
[10:45] <Nubae> but I managed to get local printers to work yesterday, which I'm happy about
[10:47] <laga> yeah, ltsp-client-core doesn't install that file... ltspfsd comes with the /lib/udev/add_fstab_entry scripts
[10:48] <laga> i don't need ltspfsd on my clients so i don't install it
[10:56] <Nubae> I can try and take it out as well then, not sure if I need it or not, I'm guessing not
[10:57] <Nubae> so when ltsp-client-core starts, normally it install ltspfsd and you took that out?
[10:58] <ogra_cmpc> it wont work without ldm tunnel in place anyway
[10:59] <ogra_cmpc> and the udev rule would prevent you from using any kind of removable device
[10:59] <ogra_cmpc> so remove it
[10:59] <laga> ltsp-client-core is an init script.. if i ever find a init script on my box which apt-get installs packages, it'll be removed in no time :)
[10:59] <laga> Nubae: i suggest you review the dependencies for ltsp-client and check if it's really needed. maybe ltsp-client-core will be good enough for you.
[11:00] <ogra_cmpc> last time i looked ltsp-client-core was a package
[11:00] <laga> you'll also find that /etc/fstab gets overwritten on boot
[11:00] <ogra_cmpc> but it contains an initscript :)
[11:00] <laga> ogra_cmpc: /etc/init.d/ltsp-client-core ;)
[11:00] <Nubae> yeah taking out ltspfsd takes out ltsp-client also
[11:00] <laga> ogra_cmpc: and packages don't "start" ;)
[11:00] <ogra_cmpc> it never installed any packages though
[11:00] <Nubae> so does /etc/hosts
[11:01] <ogra_cmpc> but indeed its for configuring a parebone thin client system ...
[11:01] <laga> wrt overwriting of fstab: this will hopefully be configurable once ogra upload a new ltsp package to hardy ;)
[11:01] <ogra_cmpc> which means there is no /etc/hosts, no /etc/fstab and the like
[11:01] <laga> fstab is overwritten in /etc/init.d/ltsp-client-setup
[11:01] <Nubae> what about /etc/hosts?
[11:01] <ogra_cmpc> read what i wrote :)
[11:01] <laga> which i'd like to keep actually because it contains some useful things
[11:02] <ogra_cmpc> the ltsp-client packages purpose is to configure a barebone thin client system which is usually not configured at all and lacking these files
[11:03] <laga> yes. i'm not complaining about that.
[11:03] <ogra_cmpc> if you use ltsp in any other context the first thong your script should do is: update-rc.d ltsp-client-setup remove
[11:04] <ogra_cmpc> laga, for now patching is fine, but i would like to move the common functions out of the initscript
[11:04] <ogra_cmpc> so you can source a -functions file and just call thin_client_fstab() which then would create a default fstab
[11:05] <laga> sounds more versatile so it's good
[11:05] <ogra_cmpc> so your scripts can just source the functions and you should switch off the actual ltsp related stuff
[11:05] <ogra_cmpc> that avoids confusion and results in cleaner code
[11:06] <laga> i'd actually remove ltsp-client-core instead of ltsp-client-setup from init.. ltsp-client-core seems more harmful for my purposes
[11:06] <laga> yup
[11:06]  * laga shouldn't be discussing technical stuff when X is taking 100% CPU, making his box lag like hell
[11:08] <ogra_cmpc> get a better graphics card or stop playing WoW while discussing :P
[11:08] <laga> grr
[11:08] <laga> i blame hardy
[11:35] <stgraber> ogra_cmpc: looks like I have a fix for the MMX thing
[11:35] <ogra_cmpc> yay
[11:36] <stgraber> he basically was trying to use MMX on amd64 ...
[11:36] <ogra_cmpc> ouch
[11:39] <stgraber> let's upload that to the local package builder and see if that also work on i386
[11:46] <stgraber> no !!!, my pbuilder chroots have the new libc ...
[11:53] <ogra_cmpc> wait a moment, the fix is already built for x86 ... waiting for the other arches
[12:56] <Nubae> is there a page I can look at to know exactly how update-rc.d works, I've tried adding cupsys to it, doing update-rc.d cupsys default, but that doesn't seem to work
[12:59] <ogra_cmpc> man
[12:59] <ogra_cmpc> or man update-rc.d
[12:59] <ogra_cmpc> :)
[13:00] <Nuba1> does anyone know where I can get some more info on update-rc.d, looking through google is not bringing up anything
[13:04] <ogra_cmpc> man update-rc.d
[13:04] <ogra_cmpc> Nuba1, ^^^
[13:04] <Nuba1> :-P
[13:04] <ogra_cmpc> Nuba1, btw is your wiki name Dvanassche ?
[13:05] <Nuba1> yeah
[13:05] <ogra_cmpc> there was someone looking for you last night
[13:05]  * ogra_cmpc looks through the log
[13:05] <ogra_cmpc> .. subsume|work
[13:05] <Nuba1> heh, well I have kde4 installed at home and weirdly, kopete has no irc plugins!!
[13:06] <Nuba1> yeah, he seems to be working on the low fat client wiki too
[13:06] <ogra_cmpc> right, i thinkl he wanted to discuss something with you
[13:07] <Nuba1> k, well, I'll try to stay around a bit more, see if I can run into him
[13:15] <Nuba1> is there something wrong with calling the ltsp chroot something other than i386 (ie, in my case I call it fati386)?
[13:19] <ogra_cmpc> no
[13:19] <ogra_cmpc> if you find that something chokes on it, please file a bug
[13:19] <ogra_cmpc> all scripts should work with a changed chroot name
[13:20] <ogra_cmpc> (with teh respective options indeed)
[13:30] <Nuba1> its been fine for me, there's just a mention on the wiki that people have had problems calling it anything but i386
[13:34] <ogra_cmpc> well, we wouldnt have added the --chroot option if we wanted to force that path upon users :)
[15:19] <stgraber> ogra_cmpc: iTalc 1.0.7 test packages : http://www.stgraber.org/download/ubuntu/italc/
[15:21] <stgraber> ogra, ogra_cmpc : I have tested it on amd64, I'll try it on i386 later today
[15:21] <ogra_cmpc> thanks a lot :)
[21:21] <crimsun> ogra_cmpc: ping RE: "profiling".  I was sitting at work thinking about a workaround, and I was wondering if you (or other devs) have investigated it.
[21:22] <ogra_cmpc> crimsun, intrepid is supposed to have a focus on performance improvement and size reduction so that will be an essential part then
[21:23] <crimsun> ogra_cmpc: ah ok
[21:23] <crimsun> ogra_cmpc: I started implementing something at work that takes the post-install initramfs and compares it to what's actually used from lsmod.
[21:24] <crimsun> ogra_cmpc: it's pretty hacky, but I can already strip considerable modules from the initramfs
[21:24] <ogra_cmpc> heh
[21:24] <crimsun> ogra_cmpc: e.g., pci_hotplug and friends cause a 60-second probe/stall here
[21:24] <ogra_cmpc> thats pretty much what i do on the classmate to speed up booting
[21:25] <ogra_cmpc> even though i additionally cut down that list manually
[21:25] <crimsun> ogra_cmpc: how are you doing it programatically?
[21:25] <crimsun> ah
[21:26] <ogra_cmpc> but alone cating the output from lsmod into /etc/modules and redoing the initramfs brought about 30% speedup
[21:26] <crimsun> right.
[21:26] <crimsun> I suspect you're going further and actually comparing the usage field?
[21:28]  * Paladine is off to Skegness Grammar School tomorrow :)
[21:29] <ogra_cmpc> hmm, no, thats actually something i havent thought of ... the thing with the classmate is that it doesnt need to be dynamic the hw doesnt change
[21:29] <crimsun> right.
[21:29] <ogra_cmpc> at least not during boot
[21:29] <ogra_cmpc> do you plan to be at UDS this time ?
[21:31] <crimsun> ogra_cmpc: nope.  I was at the last one.
[21:32] <ogra_cmpc> i know ...
[21:32] <ogra_cmpc> there i was very occupied by edu stuff ... this time will be more tech for me ...
[21:35] <crimsun> ogra_cmpc: I will see about documenting something using the wiki in the meantime.
[21:36] <ogra_cmpc> i'll ping you if i put up specs for UDS so that gets discussed and included at the right place :)
[21:50] <crimsun> ogra_cmpc: excellent, thanks!


[00:13] <Peng_> lifeless: The LP URL isn't stored anywhere. The code can usually guess it, but not always.
[00:13] <Peng_> lifeless: Plus, not every branch is mirrored on LP.
[00:13] <Peng_> lifeless: It's probably still do-able, but it requires a little thinking, which I haven't wanted to do. :P
[00:14] <SamB_XP> Peng: americans these days!
[00:14] <wgrant> Why are the branches not hosted on LP?
[00:14] <Peng_> wgrant: Why don't I host my branches on LP?
[00:14] <wgrant> Peng_: Right.
[00:15] <Peng_> wgrant: Eh. If I did host them on LP, I'd only be using my VPS for ntp and irssi. How'd that be fun?
[00:18] <SamB_XP> Peng: it sounds better if you claim to be "testing" it ;-P
[01:41] <igc> morning (ish)
[01:41] <poolie> hello
[01:41] <poolie> how're the old positrons? :)
[01:47] <offby1> they keep annihilating the electrons.
[02:30] <igc> hi poolie!
[02:30] <poolie> hi igc
[02:30] <igc> poolie: how's the email mountain? :-)
[02:31] <poolie> substantial :)
[02:34] <lifeless> .-=^=-.
[03:54] <jam> mwhudson: question about python for you
[03:54] <jam> It seems that subclassing from tuple gives me an object that is 8-bytes bigger
[03:54] <jam> until I add an attribute, then it seems to grow a __dict__ and blossom another 140 bytes
[03:54] <lifeless> heh
[03:54] <jam> Even adding __slots__ = ()
[03:54] <jam> it still seems to have the extra 8 bytes
[03:54] <jam> do you know why?
[03:55] <lifeless> python type vs native type?
[03:55] <jam> lifeless: yeah, I was worried that the pure-python StaticTuple would have a __dict__ all the time, so I added __slots__ = (), only to find 0 change on normal instances.
[03:57] <jam> anyway, I haven't found the code that handles subclassing builtins, other than "tuple_subtype_new"
[03:57] <jam> but that doesn't seem to indicate what 'tp_alloc' is set to for the new class instance
[03:59] <spiv> jam: hmm, that does seem to be the key question
[03:59] <jam> spiv: anyway, I can live with 8 bytes overhead for StaticTuple instances when they don't compile extensions
[04:00] <jam> versus 28 for the ST instance if we wrapped a tuple instead of subclassing it
[04:00] <mwhudson> jam: not off the top of my head
[04:01] <spiv> jam: gdb says PyType_GenericAlloc
[04:01] <jam> mwhudson: I thought you might have some inkling, as I thought you mentioned when 'tp_dict' is negative
[04:01] <mwhudson> jam: i probably knew once :)
[04:01] <jam> spiv: right and that is just based on "tp_itemsize" and "tp_basicsize"
[04:01] <jam> so we need to figure out what is setting "tp_basicsize"
[04:02]  * igc lunch
[04:03] <spiv> jam: for me, the tp_itemsize and tp_basicsize are the same for a trival "class T(tuple): __slots__ = ()" and tuple.
[04:04] <jam> spiv: so I posted some testing here:
[04:04] <jam> https://code.launchpad.net/~jameinel/bzr/2.1-pure-static-tuple/+merge/14006
[04:04] <jam> can you reproduce?
[04:04] <jam> (creating 1M instances of a child of tuple is 8 bytes more memory than 1M instances of tuple)
[04:04] <jam> which is 16 bytes more memory than 1M instances of _static_tuple_c.StaticTuple
[04:04] <jam> regardless of __slots__
[04:07] <jam> spiv: I *do* see that if you have "add_dict" set, then it adds a pointer to the end of the instance. And I think I see that add_dict should be set to 0 if __slots__ is set.
[04:08] <jam> but that doesn't seem to be what I'm seeing in practice...
[04:11] <lifeless> sure its not a type pointer?
[04:11]  * lifeless is speculating
[04:12] <jam> lifeless: all objects in python have a type pointer, even 'tuple'
[04:12] <jam> so it should be able to just re-use that location
[04:12] <jam> since it is fixed for inspection
[04:12] <jam> it could be a mro or something like that
[04:13] <jam> however, looking at "typeobject.c"
[04:13] <jam> essentially "type->tp_basicsize = base->tp_basicsize + (add_dict ? 1 : 0) + (add_weakref ? 1 : 0) + (num_slots)
[04:17] <jam> spiv: in my testing, I even see it if I comment out all of StaticTuple's implementation except for the __slots__ statement.
[04:18] <spiv> jam: I see no memory difference under 2.6 between [tuple([n]) for n in range(1000000)] and s/tuple/T/, where T is that trivial subclass with empty __slots__.
[04:19] <jam> spiv: oddly enough, I *do*
[04:20] <spiv> jam: I *do* see different results with zero-length tuples
[04:20] <spiv> i.e. pass [] instead of [n]
[04:20] <jam> spiv: well there it is because 'tuple()' is a singleton
[04:20] <spiv> Right.
[04:21] <spiv> jam: my testing method is pretty simple, I'm running this:
[04:21] <spiv> python -c "T = type('T', (tuple,), {'__slots__': ()}); x = [T([n]) for n in range(1000000)]; print 'ready'; raw_input()"
[04:21] <spiv> jam: and then looking at /proc/<pid>/status
[04:21] <lifeless> jam: what python version do you have?
[04:21] <jam> lifeless: 2.6.2
[04:21] <lifeless> spiv: and you ?
[04:21] <jam> spiv: "trace.debug_memory()" on windows
[04:21] <jam> which looks at /proc/pid/status on linux
[04:21] <spiv> 2.6.4rc2
[04:21] <lifeless> right
[04:22] <lifeless> I suspect its the __slots__ change which broken boost-python in 2.6.3
[04:22]  * lifeless handwaves furiously
[04:22] <jam> lifeless: that could be...
[04:27] <jam> spiv: on Python 2.4.3 under linux I see no difference with __slots__ and 8 bytes without __slots__
[04:31] <spiv> jam: *nod*
[04:34] <jam> spiv: I just upgraded to python 2.6.4, and I still see the same thing...
[04:34] <jam> very very strange
[04:35] <jam> w/ or w/o __slots__ it adds 8 bytes
[04:35] <jam> maybe an alignment thing?
[04:35] <jam> subclasses not being as tightly aligned...
[04:36] <jam> anyway, the merge proposal is still good to have, as it helps somewhere (on spiv's machine. :)
[04:45]  * jam wanders off to bed
[04:46] <spiv> jam: I just hit approve, btw
[04:46] <spiv> jam: in case you want to do a PQM submission from bed ;)
[05:40] <igc> lifeless: do your changes in dirstate2 reduce it's size? IIRC, you were looking to take one of the 'columns' out weren't you?
[05:56] <lifeless> igc: I haven't done that
[06:29] <wgrant> Will anything blow up if I symlink a shared repo's .bzr into a subdirectory, in order to segregate my branches?
[06:30] <poolie> wgrant: the .bzr/repository directory?
[06:30] <poolie> mm
[06:30] <poolie> it's not really supported
[06:30] <wgrant> poolie: I was thinking the entire .bzr.
[06:30] <poolie> what exactly do you mean?
[06:31] <wgrant> poolie: I have ~/launchpad/lp-branches with lots of branches in it.
[06:31] <wgrant> I have a particular line of work which will need about a dozen branches.
[06:31] <wgrant> I want this to live in a subdirectory.
[06:32] <wgrant> So the related branches are obvious and separated from the rest.
[06:32] <poolie> ok
[06:32] <lifeless> igc: I'd be delighted to brain dump/find my old notes on removing columns
[06:32] <lifeless> wgrant: it will work fine
[06:33] <poolie> so i don't think you need to do anything with symlinks
[06:33] <lifeless> wgrant: but its not need, just use a subdir
[06:33] <wgrant> lifeless: That's what I thought, but best to be safe. Thanks.
[06:33] <poolie> just make a subdir
[06:33] <lifeless> wgrant: 'mkdir project'; bzr branch trunk project/1
[06:33] <lifeless> etc
[06:33] <spiv> wgrant: you can have an arbitrary number of subdirectories between a repo and a branch, though..
[06:33] <wgrant> spiv: Oh, it will look all the way up?
[06:33] <lifeless> wgrant: yes
[06:33] <wgrant> That's convenient.
[06:33] <wgrant> didn't know that...
[06:33] <lifeless> wgrant: we aim to please
[06:33] <igc> lifeless: I think there was a bug report for removing a column. Maybe add them there?
[06:33] <wgrant> lifeless: You succeed.
[06:33] <spiv> :)
[06:34] <lifeless> igc: are you considering picking up dirstate2 and running with it?
[06:34] <lifeless> I won't be following up for a while..
[06:34] <igc> wgrant: if there's somewhere in the doc I should change to make that more obvious, please let me know
[06:34] <igc> lifeless: no
[06:34] <igc> lifeless: I was just trying to understand some benchmark results
[06:35] <wgrant> igc: I haven't read the bzr docs in at least three years. I have no idea what they're like now.
[06:35] <igc> lifeless: see #461651
[06:36] <igc> wgrant: I guess that answers that question :-)
[06:36] <lifeless> bug 461651
[06:36] <lifeless> igc: yes, I saw that
[06:37] <igc> 11M for a FireFox dirstate seemed large
[06:41] <lifeless> igc: getting rid of the the extra tree columns wouldn't shrink that any
[06:41] <lifeless> as its not a merged dirstate
[06:42] <igc> lifeless: ah - ok. Thanks
[07:10] <vila> hi all
[07:10] <poolie> hello vila!
[07:11] <vila> welcome back poolie :)
[07:12] <poolie> thanks, it's good to be back
[07:18] <igc> hi vila!
[07:24] <wgrant> igc: So, I decided I should read through some of the docs. They really are excellent these days.
[07:24] <wgrant> (where do I file typos in them?)
[07:25] <igc> wgrant: the docs are genuinely a community effort but, hey, I'll take the credit :-) :-)
[07:25] <igc> wgrant: unfortunately, it depends
[07:25] <igc> wgrant: most of the docs are in the core but some, like the migration docs, are separate projects
[07:26] <igc> wgrant: if you file doc bugs against the core, we can shuffle the assigned project if appropriate
[07:26] <wgrant> igc: 'Why Switch to Bazaar?' is the one I just found a typo in.
[07:26] <igc> wgrant: it's in lp:bzr-migration-docs
[07:27] <wgrant> igc: Thanks.
[07:32] <wgrant> igc: One other thing I noticed (horrible horrible nitpicking, I know) is that the migration docs don't seem sure on whether to use sentence or title case for various levels of headings. It just makes it look that bit unpolished.
[07:33] <igc> wgrant: the unwritten rule is Title case for document headings, sentence case otherwise
[07:37] <lifeless> igc: I'd be a lot happier if all the docs were in the core
[07:37] <lifeless> so the debian package would include them
[07:38] <igc> lifeless: all the docs can't be in the core - many of them are built from plugins
[07:39] <lifeless> igc: I thought that was just the plugin guide one?
[07:39] <igc> lifeless: other like the website and doc-website bridge multiple releases
[07:39] <lifeless> igc: well, the website is differnet
[07:40] <lifeless> its /docs/ I care about
[07:40]  * wgrant will submit a couple of migration docs MPs later tonight.
[07:40] <lifeless> if the ReST were generated and committed to trunk, then it could be included in the deb package
[08:21] <GaryvdM> Hi lifeless
[08:21] <GaryvdM> lifeless: I'm looking at bug 320236.
[08:21] <GaryvdM> lifeless: Would it be allright if specified the field that a term applies to in the document_key
[08:22] <GaryvdM> lifeless: e.g. for authors/commiter : ('r','a',rev_id)
[08:23] <lifeless> I'd hesitate to do that
[08:23] <lifeless> its not a good use of the index space
[08:23] <lifeless> either index with a more appropriate term
[08:24] <lifeless> ('author', 'fred')
[08:24] <lifeless> or query the matching revisions to filter more
[08:24] <GaryvdM> lifeless: Ok - I think I'll index with a more appropriate term
[08:25] <lifeless> GaryvdM: my advice though
[08:25] <lifeless> GaryvdM: post process
[08:25] <lifeless> accessing revisions is fast
[08:25] <lifeless> and you'll already have a short list
[08:25] <GaryvdM> lifeless: Ok
[08:25] <lifeless> adding more data to the search index is likely to just slow things down
[08:26] <lifeless> *if* data shows that it would make a huge difference, then I'll happily drill into this in more detail with you
[08:27] <lifeless> consider though - how many revisions would have a hit for 'Robert' and not have that be author/committer
[08:27] <lifeless> [remember that you won't be comparing against file texts here]
[08:28] <GaryvdM> lifeless: Yes - that makes sense.
[08:40] <vila> lifeless: you know there are still  3 test failures for loom ? (Related to switch)
[08:40] <lifeless> vila: no, I didn't
[08:40] <lifeless> unless, perhaps, I put up a branch for review
[08:44] <vila> lifeless: ./bzr selftest -s bb.test_switch trigger them all
[08:47]  * igc dinner
[08:49] <lifeless> vila: have you filed a bug on loom? if not, please do so
[08:51] <vila> lifeless: ok
[08:54] <vila> bug #461743
[09:36] <hsn> anybody have experience with bzr support in maven? it seems that bzr protocol is unsupported and sf.net servers does not provide http access to bzr repo
[12:27] <GaryvdM> Hi igc
[12:28] <igc> hi garyvdm
[12:29] <GaryvdM> igc: I've been thinking about rename/move for qbzr.
[12:29] <GaryvdM> I want to hear your ideas on ui.
[12:29] <GaryvdM> And bounce some of my own.
[12:31] <igc> bug 298242
[12:31] <igc> garyvdm:^
[12:32] <GaryvdM> So the idea I have is that from the treewidget (i.e. qcommit, and qbrowse) you can right click, rename, or you can drag and drop move
[12:33] <igc> garyvdm: sounds great
[12:33] <GaryvdM> igc: Sorry - I forgot that you had the right up in the bug.
[12:34] <igc> garyvdm:I like you ideas
[12:34] <GaryvdM> And the other idea that I have is that you can highlight a missing file, and a unversioned file, and right click, "Mark as Move"
[12:34] <GaryvdM> igc: Cool
[12:34] <igc> we could combine them by just showing the dialog I outlined, with ...
[12:35] <igc> the relevant radio button pre-selected
[12:35] <GaryvdM> igc: I see
[12:37] <igc> drag n drop would be really nice for move
[12:37] <igc> garyvdm:^
[12:39] <igc> garyvdm: it's my bed time - any other questions?
[12:39] <GaryvdM> igc: Nope. Thanks for your time.
[12:39] <GaryvdM> igc: Sleep well.
[12:39] <igc> garyvdm: thanks!
[12:40] <igc> night all
[13:53] <jam> morning all
[13:57] <vila> morning jam !!!
[13:58] <vila> did you intended to vote but forgot on the dwim revspec ?
[14:00] <vila> jam: the tone of your comment sounds like a vibrant approve but... :)
[14:01] <jam> vila: I intended to enter the discussion.
[14:01] <jam> though I do approve the change
[14:02] <jam> vila: there, feel better :)
[14:03] <vila> lol, thanks for fullermd :)
[14:09] <jam> Peng: https://code.edge.launchpad.net/~jameinel/bzr/2.1-st-from-iterable/+merge/14027
[14:13] <jam> vila: I'll go ahead and submit his patch then.
[14:14] <vila> jam: I'm doing right now if you haven't started...
[14:14] <jam> vila: ah, please do
[14:14] <jam> I just didn't see it in PQM yet
[14:14] <vila> pqm'ed
[14:15] <vila> I had some... weirdness-I-dont-even-want-to-start-looking-at
[14:15] <jam> rockstar: are you around for a bit of a chat?
[14:19] <Peng_> The question is, how do I mark my merge proposal as superseded?
[14:37] <gioele> mwhudson: hi, have you got a tarball of the generated bzrlib API?
[14:58] <jam> Peng_: you can mark it as "work in progress" and it will be hidden from the review queue
[14:59] <jam> or "Merged" if you want to treat it as merged into mine...
[14:59] <jam> I don't have a better way
[15:01] <jam> Peng_: Or just wait until the patch lands and see if lp marks it merged for you
[15:09] <rockstar> jam, hi
[15:10] <jam> good morning rockstar
[15:10] <jam> I hope you've had your coffee this morning :)
[15:10] <Peng_> jam: I'm confident that LP will mark it merged.
[15:10] <jam> I'd like to pick your brain a bit about things that the bzr team can do to help you guys
[15:10] <Peng_> Huh, set(['foo bar']) is a lot faster than set(StaticTuple('foo bar'))
[15:10] <jam> most notably, things that *I* should focus on :)
[15:11] <rockstar> jam, great.  I don't drink coffee shop, but I'm about to head out to one.
[15:11] <rockstar> jam, can it wait about an hour?  I have some branches to land.
[15:11] <jam> rockstar: absolutely
[15:11] <rockstar> jam, great.
[15:13] <Bear10_> when I do a bzr add dir it says it ignored 2 files but doesn't say which
[15:13] <Bear10_> any ideas how to find out which?
[15:15] <jam> Bear10_: bzr ignored
[15:24] <Bear10_> thanks
[15:25] <Bear10_> see :)
[15:25] <Bear10_> woops wrong window
[15:40] <Peng_> jam: Thanks for all of your help recently. :)
[15:48] <jam> Peng_: thanks for your interest
[16:04] <Bear10_> has anyone experienced problems where the icons just never update, and you have to manually update to see if your still on the same version as the binded branch?
[16:49] <Arc> does bazaar support commit hooks such as buildbots, special handling of certain file types (ie, unzipping an ODF so it's contents are stored in VCS and diffed vs the zip as a binary blob, metadata checked and passed, etc)
[16:49] <Peng_> Bazaar does have good hook support, so they can probably be used for all of that.
[16:50] <Arc> do the hook distribute to users?
[16:50] <Arc> or do they need to be manually installed by each committer
[16:52] <Arc> looking at bazaar from the mercurial model
[16:52] <Arc> especially for hosting media
[16:54] <Peng_> Arc: Manually installed.
[16:55] <Arc> so we're not really better off with bzr over hg
[16:56] <Arc> except for perhaps the licensing issue, which hg is very sub-optimal for
[16:57] <Peng_> It is?
[16:57] <jfroy|work> mornin'
[16:57] <Arc> GPLv2 only vs GPLv2+
[16:57] <Arc> GPLv2-only is not AGPLv3 compatible
[16:57] <Peng_> Arc: I think they're working on GPLv2+.
[16:57] <Peng_> Or already did it.
[16:58] <Arc> really?  I thought their maintainer was dead set against it
[17:00] <Peng_> Arc: I think he suddenly and quietly changed his mind. I'm not sure, though.
[17:00] <Arc> ok
[17:02] <james_w> Is GPLv2+ AGPLv3 compatible?
[17:02] <james_w> I wouldn't have thought that it would be
[17:03] <Arc> yes, because the GPLv3 is AGPLv3 compatible
[17:04] <Arc> GPLv2->GPLv3->AGPLv3
[17:04] <Arc> GPLv3 section 13 makes it so
[17:06] <james_w> ah, thanks
[17:07] <Arc> we're building a web framework for our project that is licensed under the AGPLv3, and would really like to get mercurial integration
[17:11] <Peng_> Arc: See the thread in mercurial-devel "Re-licensing email", starting 2009-10-14.
[17:12] <Arc> Peng_: i just read, thanks :-)
[17:14] <Tak> is there anything special I need to do to `import bzrlib` on windows, having installed with the default installer?
[17:17] <Tak> aha, got it!
[17:17] <Tak> didn't think to look in the zipfile
[17:32] <cjwatson> jelmer: can I interest you in what appears to be a bzr-svn data corruption bug? it's happening to the grub project, who are just looking at adopting bzr; unfortunately at the moment they're using the bzr/bzr-svn from Debian lenny (but could be persuaded to upgrade if I can demonstrate that some of their problems would go away with newer code)
[17:33] <cjwatson> jelmer: jml took a look at it here and said "uh, this probably needs John or Jelmer" :-)
[17:34] <Tak> anyone with python on win64 want to do a `python -c "import sys; print sys.platform"` for me?
[17:34] <jml> cjwatson, I was _so_ much more eloquent than that.
[17:35] <jml> cjwatson, I was using internal rhyme and everything.
[17:35] <cjwatson> jml: :-)
[17:36] <Peng_> mwhudson: ping, if you don't mind doing some hand-holding.
[17:36] <Peng_> Tak: Maybe try #python.
[17:37] <Peng_> What OSes are used at Canonical? Just Ubuntu? :D
[17:37] <Tak> or maybe not!!!
[17:37] <Peng_> Tak: Why not?
[17:40] <GaryvdM> Peng_: bzr is cross platform!
[17:46] <cjwatson> jelmer: bug 462109, if you're interested
[17:50] <Peng_> mwhudson: Semi-unping. (Sorry, I know that's not very helpful.)
[17:55] <Tak> in case anybody cares, the result is "win32"
[18:02] <GaryvdM> Hi
[18:03] <GaryvdM> Is there a way to get a tree for NULL_REVISION without a reference to a repository?
[18:05] <GaryvdM> Ah - nvm - I grep and I grep, but I could not find. I asked here, then switch back to my IDE, and it was right in my face :-P
[18:05] <GaryvdM> RevisionTree(self, Inventory(root_id=None), NULL_REVISION)
[18:30] <BrianBatchelder> I'm trying to figure out how to prevent the merging of a particular file whenever I merge between two branches.  We have a hierarchical branch setup, with branch "A" as our release branch, and "A.1", "A.2", etc. as development branches.  When a dev branch is ready to release, it merges to branch "A", and then that code is merged down to the rest of the development branches.  But I have one branch-specific file that can't be merged during this process.
[18:30] <BrianBatchelder> must be version controlled, because it is needed in checkouts of the development branches.  Any ideas of how to do this?  Thanks.
[18:30] <maxb> bzr revert it in between merge and commit, always?
[18:30] <dash> BrianBatchelder: revert it before you commit the merge?
[18:31] <BrianBatchelder> I'm not the only one who does the merges, so I'd like it to be automatic.
[18:31] <dash> shell script time :)
[18:32] <BrianBatchelder> Is there a simple way to hook the merge operation and automatically revert it?
[18:36] <BrianBatchelder> Or perhaps limit the users who can modify that file?
[19:15] <mwhudson> Peng_: good <time of day>
[19:21] <Tak> jelmer: http://img148.imageshack.us/img148/1204/mdbzrwin32.png
[19:27] <Peng_> mwhudson: Hi. :)
[19:33] <Peng_> mwhudson: So anyway, never mind about the ping. I was trying to figure out loggerhead.wholehistory, and managed it well enough.
[19:33] <mwhudson> Peng_: cool
[19:34] <Peng_> Not that I understand it, but I was able to accomplish what I was working on. :P
[19:34] <Peng_> The revision graph cache is one scary data structure. :P
[19:43] <mwhudson> yes, and it should be fixed by deletion really
[19:43] <mwhudson> otoh, we can't escape the need for revision numbering for now
[20:03] <jfroy|work> jelmer: is the svn revno corresponding to a particular bzr revision available to hooks?
[20:04] <jfroy|work> I'd like to write some sort of post-revision-push hook (if that's possible) that would need to know the corresponding svn revno (and possibly the push URL) of each pushed revision.
[20:46] <samokk> hey. wondering about something simple : I see that bzr 2 has a new repository format 'nearly as efficient as git', and also supports the import of git branches. if the 2a format is only nearly as efficient, then why not use git repo format by default ?
[20:46] <dash> git doesn't support all of bzr's features
[20:47] <samokk> oh ok
[20:56] <faheem> can anyone point me to large public bzr repos for testing? i'm using 2.0.1
[21:02] <hsn> faheem: mysql
[21:21] <maxb> faheem: Launchpad's own source is pretty large
[21:30] <lifeless> faheem: what sort of testing
[21:30] <lifeless> hsn: mysql haven't upgraded their branches, so aren't a very good test case for testing - still performs slowly
[21:41] <bob2> drizzle otoh is about to upgrade
[21:42] <igc> morning
[21:49] <lifeless> bob2: cool; I only lurk in IRC, you're in the list?
[21:50] <bob2> yeah
[21:52] <apm121> mysql migrate from ? svn or cvs ?
[21:53] <bob2> they came from bk
[22:25] <wgrant> bzr-git doesn't seem to be able to branch over HTTP yet. Is that the case?
[22:28] <mwhudson> wgrant: it is
[22:29] <wgrant> mwhudson: I guess I'll do a local clone and branch from that. Thanks.
[22:44] <poolie> hello
[22:46] <lifeless> hi
[22:48] <mwhudson> i have this vague notion that bzr plugins can't be in eggs
[22:48] <mwhudson> is there something fundamental about this, or could it be fixed?
[22:52] <lifeless> mwhudson: it could be fixed I guess
[22:53] <lifeless> mwhudson: plugins are just packages that we do 'import bzrlib.plugins.package'
[22:53] <mwhudson> hm
[22:53] <lifeless> mwhudson: plugin loading is thus in two phases: setup an appropriate python path on bzrlib.plugins.__path__
[22:53] <lifeless> scan manually for all packages in that path
[22:53] <lifeless> call 'import bzrlib.plugins.package' for the resulting names
[22:54] <mwhudson> i guess it's the "scan manually" part that goes awry with eggs?
[22:54] <lifeless> yes
[22:54] <lifeless> now, things keep getting tweaked there
[22:54] <lifeless> I mean to go into the code, delete all the cruft and make it simple again
[22:54] <lifeless> (for instance, I believe bzr in a .zip is handled differently, for no good reason)
[22:55] <mwhudson> so if i were to focus very narrowly on what i'm thinking about right now, which is launchpad, i could probably put (say) bzr-svn in an egg and import it by hand
[22:56] <lifeless> oh yes
[22:56] <lifeless> I'd expect that work fine
[22:56] <lifeless> see also IRC log for me chatting with vila about allowing specifications of individual plugins on BZR_PLUGIN_PATH
[23:21] <mwhudson> hmm
[23:21] <mwhudson> BzrError: Attempt to escape test isolation: 'file:///var/tmp/codeimport/data/worker-for-branch-1/bzr_working_tree/' [u'/tmp/testbzr-MThLsv.tmp/', 'file:///tmp/testbzr-MThLsv.tmp/', u'/tmp/testbzr-MThLsv.tmp/lp.codehosting.codeimport.tests.test_worker.TestSubversionImport.test_import/', 'file:///tmp/testbzr-MThLsv.tmp/lp.codehosting.codeimport.tests.test_worker.TestSubversionImport.test_import/', 'file:///tmp/testbzr-MThLsv.tmp/']
[23:21] <mwhudson> what is this trying to tell me?
[23:23] <mwhudson> oh, i see
[23:23] <mwhudson> not the most helpful error message
[23:23] <spiv> No, I guess not.
[23:24] <johnf> jelmer: you about?
[23:24] <spiv> Some text like "is not inside one of" between the url and the list of acceptable locations would probably help.
[23:26] <spiv> And maybe "Attempt to open BzrDir outside test isolation" would be better too.
[23:26] <johnf> anyone know if there is a solution to this problem when running bzr check "reason: Parent not in inventory." It is from a branch that was originally branched from SVN
[23:26] <mwhudson> spiv: yeah
[23:28] <spiv> Huh, PQM is only just now playing my merge requests from yesterday.  I wonder where they got stuck.
[23:36] <poolie> hello spiv, igc, mwh
[23:55] <igc> hi poolie
[23:57] <poolie> hi there igc
[23:58] <igc> poolie: can you review https://code.edge.launchpad.net/~ian-clatworthy/bzr/filtering-revert-bug/+merge/14022 today? Given you're not working on the content filtering bug, I'm going to take it back on board. This is step 1.
[23:58] <poolie> ok, i'll try


[01:17] <slangasek> so I'm wondering if we should revert the whoopsie NM integration
[01:17] <infinity> slangasek: I've only been half-heartedly following the whoopsie drama.
[01:18] <infinity> slangasek: Is it pretty much past the point of "we should just effin' fix it" and deep down some "ngh, don't know how" rabbit hole?
[01:18] <infinity> slangasek: If so, reverting seems sane.
[01:18] <slangasek> it's clearly still not working right, as it's causing 20s boot speed regressions on some (but not all) systems
[01:18] <infinity> Oh, so it's basically mountall, part 2. :P
[01:19] <infinity> (I still get that /tmp thing, you need to step me through some debugging/logging sometime)
[01:19] <infinity> Of course, when we try to debug it, it won't happen, just to spite me.
[01:19] <slangasek> there's a workaround in place for ubiquity-dm, but that basically stops whoopsie from running at all in the live env, which isn't what we want either
[01:19] <infinity> Right.
[01:20] <slangasek> infinity: do you have a particularly full /tmp, which is a subdir of / rather than a separate mount point?
[01:20] <infinity> Is there a clear "this version was fine", and no rdep issues with a straight revert?  If so, let's just do it.
[01:20] <infinity> slangasek: My /tmp isn't a tmpfs, but my / isn't remotely full.
[01:20] <slangasek> infinity: I think you have the same mountall issue as xnox, which we've tracked down to "wrong message presented when the system is actually busy cleaning /tmp"
[01:20] <slangasek> full as in "full of stuff", not "out of disk"
[01:21] <infinity> slangasek: And it's not ever all that full.  Maybe a few unpacked trees from aborted debdiffs here and there.  But then it does the "waiting 30s" thing, which is excessive, if the cleaning only takes 5.
[01:21] <slangasek> infinity: there definitely is a "this version was fine" whoopsie - though given that there are other bug fixes intertwined, I'm inclined to revert just the libnm part
[01:21] <slangasek> waiting 30s?
[01:21] <slangasek> I don't know anything about that one
[01:21] <infinity> slangasek: If the feature revert is clear and obvious to you, go for it. :)
[01:22] <infinity> slangasek: As for mountall, yeah, it seems to just go into a timeout loop.  But this is all unscientific, I've not bootcharted or logged in any meaningful way, just watched it sit there for a $very_long_time that feels like an artificial delay.
[01:23] <slangasek> hmm
[01:23] <infinity> Cause if it was just waiting on an rm -rf, I'd expect it to flash the message for a few seconds, then carry on.
[01:23] <infinity> And it's much, much longer than that.
[01:24] <slangasek> infinity: well, you could try building from lp:ubuntu/mountall and see if the message goes away; that's the fix for xnox's bug
[01:24] <slangasek> (committed, not yet uploaded)
[01:24] <infinity> Sure.  I'll have to do a few reboots here first and make sure it's still reproducible, and see how often.
[01:24] <infinity> So I have some data going into the test.
[01:24] <infinity> I reboot, like, once a month, so my data's a bit suspect.
[01:25] <infinity> (Uptime on laptops has become ridiculous since we actually started suspending and resuming properly...)
[01:28] <infinity> slangasek: Anyhow, sorry to sidetrack.  If the feature revert is clean, clear, and obvious, JFDI, IMO.  If not, a full version revert might be sane to at least have things not borked over the weekend, and it can be revisited on Monday.
[01:29] <slangasek> ack
[01:30] <slangasek> I'm having a quick scan over the whole diff to make sure it is a severable change
[01:33] <infinity> slangasek: Before I go deep into trying to sort out this mountall business, it wouldn't be weirdly confused by this bit in my fstab, would it?
[01:33] <infinity> schroot        /var/lib/schroot/union/overlay/            tmpfs   size=75%          0       0
[01:34] <infinity> Like, it doesn't seem tmpfses and just have a crazy?
[01:34] <slangasek> it doesn't just have a crazy
[01:34] <infinity> s/seem/see/
[01:34] <infinity> Check. :)
[01:34] <slangasek> it does automount them, and consider the "virtual filesystem" stage not done until they're all mounted
[09:11] <cjwatson> fixed cdimage.germinate, rebuilding the images that failed due to that
[09:24] <ogra_> heh
[09:24]  * ogra_ just discovered it
[10:10] <cjwatson> ogra_: cdimage is up to nearly 3000 lines of Python now (and another >3000 of tests); it'd have been surprising if none of it was broken ...
[10:10] <cjwatson> I think I'm ready to tackle build-image-set next