[00:00] <CynthiaG> Ok
[00:00] <CynthiaG> I was just getting ready for these tests now, I'll boot into the two dailies on all the computers I have access to
[00:38] <slangasek> lifeless: well, the thing about that is that this particular error indicates there was a *previous* error on import; I don't know what caused the tag to fail to be set previously, or if that bug still exists.  Do you still want me to open a bug report against UDD for it?
[00:43] <maco2> slangasek: i think james_w mentioned having fixed the bug that makes tags not get set on import the other day
[00:43] <maco2> but that he hadn't found all the failed ones to go back and retroactively tag them
[00:50] <slangasek> maco2: right, makes sense
[01:24] <CynthiaG> cjwatson: results in table form  http://paste.ubuntu.com/445820/
[02:12] <slangasek> nhandler: do you have a toshiba laptop that uses fnfxd?  I was trying to figure out why fnfx isn't simply in sync with Debian, and I see you last merged it
[02:16] <lifeless> slangasek: I want bugs for everything that goes wrong
[02:17] <slangasek> lifeless: I could just file a bug that says "http://package-import.ubuntu.com/failures/ is not empty"? :)
[02:17] <lifeless> slangasek: yes, but also ones about the bits that aren't empty.
[02:17] <lifeless> :)
[02:18] <lifeless> ok -> into the wild
[02:26] <funkyHat> How can I request that a package is rebuilt? mpd needs a rebuild for maverick
[02:27] <micahg> funkyHat: open a bug w/a debdiff if you don't have upload rights
[02:27] <funkyHat> micahg: there's no need for a debdiff, the package just needs to be rebuilt
[02:28] <micahg> funkyHat: right, but it needs a version bump if it wasn't and FTBFS
[02:28] <micahg> *an
[02:29] <funkyHat> micahg: it isn't ftbfs either, it just won't start
[02:29] <funkyHat> I can do that anyway though
[02:29] <micahg> funkyHat: k, so file a bug w/a version bump and subscribe sponsors if you can't find someone to do it for you
[02:30] <funkyHat> Ok. Thanks ⢁)
[02:49] <nhandler> slangasek: Nope, sorry. I don't have a toshiba laptop
[02:49] <slangasek> nhandler: ok, no worries
[02:50] <slangasek> I am inclined to drop the Ubuntu delta, it looks like it's meant for a bygone age
[02:50] <slangasek> (before we started doing all acpi keys across input devs)
[03:47] <reduz> hi guys, questio!!!n how do i report a bug in ubuntu itself and not in a package?
[03:48] <reduz> well, question i meant
[03:48] <CynthiaG> What would this elusive bug be? Are you sure it's in Ubuntu and not a package?
[03:49] <reduz> yes it's in ubuntu, (or at lest in a core package), networking gets disabled in ubuntu after laptop suspends, if i edit /var/lib/NetworkManager/NetworkManager.state and enable it again, it works again
[03:52] <CynthiaG> Then the bug is eiter in acpid or network-manager
[03:52] <CynthiaG> Ask #ubuntu-bugs to tell you what they think is the best package to report under
[03:53] <reduz> ok!
[03:53] <RAOF> I'd probably start by filing it under network-manager (with ubuntu-bug network-manager), as that's likely to pick up the most interesting logs.
[07:38] <pitti> Good morning
[07:39] <CynthiaG> Hi there :)
[07:59] <dholbach> good morning
[09:54] <hrw> ~curse LP very badly
[10:00] <atrefre34> hi
[11:08] <rsajdok> #j warszawajug
[11:27] <LucidFox> It's Mark!
[11:27]  * LucidFox salutes
[12:01] <ogra_cmpc> lamont, is there any reason why we use "apt-get -y --purge install" everywhere across livecd-rootfs ? the --purge doesnt seem to make any sense in connection with install
[12:01] <lamont> ogra_cmpc: as much historical as anything else, I always use --purge so that anything that gets conflicted out gets purged instead of just removed
[12:02] <ogra_cmpc> ah
[12:02] <lamont> but yeah, there _shouldn't_ be any conflicts there
[12:03] <ogra_cmpc> well, i was just irritated by using it with install
[12:04] <lamont> ah, don't be irritated by it :-p
[12:04] <ogra_cmpc> :)
[12:16] <aretrfre34> where's ubuntu-games channel?
[12:18] <aretrfre34> boom
[12:18] <aretrfre34> !boom
[12:19] <ansgar> aretrfre34: The Debian/Ubuntu Games Team has a channel on OFTC to discuss packaging (#debian-games).
[12:31] <ogra> lamont, cjwatson, does that change look sane to you ? http://paste.ubuntu.com/446049/
[12:31] <ogra> (i know its evil to do it in the kernel part, but i found it better than to introduce another subarch check somewhere else )
[12:31] <dholbach> stefanlsd, james_w: bobbo just fixed bug 586787 (mvo will upload it later)
[12:34] <lamont> ogra: which livecd images are being made for omap?
[12:34] <lamont> because, um, ew
[12:34] <ogra> lamont, netbook atm
[12:34] <ogra> but it might be that we will also build base or something like that later
[12:34] <lamont> I'd rather introduce another subarch check than magically post-edit LIVELIST
[12:34] <ogra> ok
[12:35] <lamont> on that note, afk for a few
[12:39] <mvo> dholbach: I merged it into ubuntu-dev-tools already
[12:39] <dholbach> mvo: awesome
[12:39] <CynthiaG> cjwatson: ping
[13:16] <Daviey> james_w: If i wanted to sign using a different GPG key using bzr-buildpackage, how would i do it?  Using debuild i'd just do -k$DEBEMAIL, but i can't see a logical way to do it using bzr-buildpackage.. Any pointers?
[13:16] <Laney> you can pass arbitrary options to debuild
[13:17] <Laney> I think it's bzr bd ... -- -kBLAH
[13:17] <Laney> or DEBSIGN_KEYID=blah bzr bd ... might also work
[13:17] <Laney> Daviey: ^
[13:18] <Daviey> Laney: interesting, didn't see that in --help
[13:18] <Laney> I could have just fabricated the whole thing but I hope not
[13:18] <Laney> I could also be thinking of gbp
[13:20] <Daviey> Laney: if not, i suppose i could overide "--builder="debuild -k$DEBEMAIL""
[13:22] <RAOF> Laney: No, you're thinking of bzr-buiddeb
[13:22] <Daviey> i thought they were the same.. :/
[13:23] <Laney> aren't they?
[13:24] <Laney> laney@chicken> tail -2 /usr/bin/bzr-buildpackage                                                                                              ~/dev/banshee
[13:24] <Daviey> $ bzr-buildpackage --help | tail -n1
[13:24] <Daviey> From:     plugin "builddeb"
[13:24] <Laney> bzr builddeb "$@"
[13:24] <Daviey> \o/ $ bzr bd -S --builder="debuild -k$DEBEMAIL"
[13:25]  * Daviey ponders raising a bug to make it support -k natively
[13:36] <mpt> If anyone knows how a computer program can tell the difference between a transitional Ubuntu package and a non-transitional one, please let us know in bug 526330
[13:38] <seb128> mpt, it can't really I think
[13:38] <seb128> check with mvo though
[13:39] <seb128> mpt, seems we would need to add extra informations in the system somewhat
[13:40] <mpt> seb128, how about "Depends on one other package and contains no files itself"?
[13:41] <seb128> mpt, those have files, ie copyright, etc
[13:41] <chrisccoulson> "no files itself" is normally incorrect
[13:41] <mvo> mpt: not trivially, there is a idea to add a "transitional" section that would solve it nicely
[13:41] <chrisccoulson> yeah ;)
[13:41] <seb128> so it would be "no file out of the standard ones"
[13:41] <seb128> but they are not the only one in this case
[13:41] <mvo> and we don't know the filelist until we downloaded it
[13:41] <seb128> like we have common packages stripped from translations matching as well
[13:44] <mpt> mvo, is anyone/anything tracking the progress of the "transitional" section idea?
[13:44] <Laney> there's a lintian tag empty-binary-package
[13:45] <Laney> you could look how that works
[13:45] <Laney> I think it looks at the description to decide to exclude transitional packages, so inverting that logic could fly
[13:46] <mvo> mpt: not currently :( its something that ideally would be part of the debian policy and is useful for other things (like automatic dependency tracking). the best way forward is probably to start a discussion on debian-devel
[13:46] <mpt> mvo, hello by the way. :-)
[13:47] <mpt> mvo, anything in USC that urgently needs design?
[13:49] <seb128> Laney, it would still catch things like common binaries stripped from translations
[13:49] <seb128> Laney, so that's still not a solid way to do it
[13:51] <Laney> no I don't think it would catch all cases, but it might go some way
[13:52] <JontheEchidna> empty-binary-package + arch-all?
[13:52] <JontheEchidna> assuming that all transitional packages have been properly set to arch-all ;)
[13:53] <seb128> JontheEchidna, doesn't solve the translation case
[13:53] <JontheEchidna> hmm, true
[13:54] <mvo> mpt: not urgently afaics, it would be nice to know more about the presentation for new apps and for-pay apps, but not that urgent as a lot of the actual code is not done yet anyway
[13:54] <mvo> mpt: hello to you too :)
[16:06] <micahg> doko: ping re openjdk
[16:10] <doko> micahg: ?
[16:10] <micahg> doko: hi, how do you feel about backporting latest openjdk to hardy?
[16:10] <micahg> doko: or rather me doing it
[16:11] <doko> micahg: it's done. just regenerate debian/control
[16:11] <doko> see https://edge.launchpad.net/~openjdk/+archive/ppa
[16:12] <micahg> doko: k, thanks, as long as I have you here, what about for jaunty/karmic?
[16:12] <micahg> doko: can we push to -security with the mozilla updates though?
[16:12] <doko> micahg: jaunty/karmic: done as well, did you look at the URL???
[16:13] <doko> mozilla updates?
[16:13] <micahg> doko: yes, I know it can be done, but can we push it with this: https://wiki.ubuntu.com/DesktopTeam/Mozilla/FirefoxHardyJaunty
[16:14] <micahg> doko: and do we have to then test every java app before we push this update?
[16:14] <doko> micahg: no, just run the TCK (at least for jaunty)
[16:15] <micahg> doko: k, thanks
[17:01] <Keybuk> pitti: I'm going to need you to look over the udev update
[17:01] <Keybuk> you've backported so many changes from trunk
[17:01] <Keybuk> and introduced so many of your own changes that don't seem to be upstream
[17:01] <Keybuk> that I'm not sure I'm not reverting fixes
[17:01] <pitti> Keybuk: sure, np; I'm just aware of one non-upstream change, the other stuff should all be in trunk
[17:02] <Keybuk> all of the rules changes
[17:02] <Keybuk> e.g.
[17:02] <Keybuk> <<<<<<< TREE
[17:02] <Keybuk> ENV{DMI_VENDOR}=="[sS][aA][mM][sS][uU][nN][gG]*", ATTR{[dmi/id]product_name}=="*N130*|*N140*|*SR70S/SR71S*|*Q210/P210*", RUN+="keyboard-force-release.sh $devpath samsung-other"
[17:02] <Keybuk> [17:02] <Keybuk> ENV{DMI_VENDOR}=="[sS][aA][mM][sS][uU][nN][gG]*", ATTR{[dmi/id]product_name}=="*N128*|*N130*|*N140*|*SR70S/SR71S*|*Q210/P210*", RUN+="keyboard-force-release.sh $devpath samsung-other"
[17:02] <Keybuk> >>>>>>> MERGE-SOURCE
[17:02] <Keybuk> it looks like you've removed N128 there?
[17:03] <Keybuk> is the non-upstream change you're aware of adding hd[a-z] to cdrom_id.rules ?
[17:04] <bjf> pitti, is it possible to add log collection to apport, things that have to be run as root?
[17:04] <pitti> right; and it was just a workaround, TheMuso told me that newer powerpc kernels should work with scsi
[17:04]  * pitti on phone, will answer in a bit
[17:04] <bjf> pitti, thanks
[17:06] <pitti> Keybuk: just checked the changelog, all other fixes were trunk backports
[17:12] <Keybuk> pitti: http://bazaar.launchpad.net/~ubuntu-core-dev/udev/ubuntu/revision/2586
[17:12] <pitti> bjf: only through gksu
[17:12] <Keybuk> if you could review that though, I'd appreciate it
[17:13] <pitti> bjf: /usr/share/apport/package-hooks/source_xorg.py has an example
[17:13] <Keybuk> err
[17:13] <Keybuk> http://bazaar.launchpad.net/~ubuntu-core-dev/udev/ubuntu/revision/2585
[17:13] <Keybuk> :p
[17:13] <bjf> pitti, I saw a "root_command_output" function in the utils but didn't see anything that used it,
[17:13] <bjf> pitti, thanks
[17:13] <pitti> Keybuk: so if there's any conflict, the upstream version should win
[17:14] <pitti> Keybuk: I'm not aware of an Ubuntu change for the N128
[17:15] <Keybuk> kk
[17:15]  * pitti looks at bzr head
[17:16] <Keybuk> I can't work out how to make bzr diff compare a given old revision
[17:17] <james_w> bzr diff -r <old rev>
[17:17] <james_w> to see the changes made in that rev from its first parent: bzr diff -c <rev>
[17:18] <Keybuk> james_w: old rev is in a different branch
[17:18] <Keybuk> how do I compare my current tree with a given rev of trunk?
[17:18] <james_w> -r branch:lp:whatever:rev might work
[17:19] <james_w> or "--old lp:whatever -r <rev>" might
[17:19] <pitti> Keybuk: so there's a diff in extras/hid2hci/70-hid2hci.rules, is that intended?
[17:19] <pitti> Keybuk: the lbm-drm change in 70-acl.rules looks Ubuntu specific, and fine to me
[17:20] <Keybuk> pitti: I can't work that one out either
[17:20] <Keybuk> james_w: revno:x:../trunk seemed to work
[17:20] <james_w> ah, option number 3
[17:21] <pitti> Keybuk: do you know why 78-graphics-card.rules isn't upstream?
[17:21] <Keybuk> pitti: because kay doesn't like it
[17:21] <pitti> Keybuk: ah, the hid change was 8b56bada9a9d9a73af06d27634e53648be0cc612
[17:21] <Keybuk> everyone else builds fbcon in (and so do we as of maverick)
[17:21] <pitti> Keybuk: I think we should revert our change too, and ask superm1 what breaks :)
[17:22] <Keybuk> pitti: yeah, I've reverted that back to upstream
[17:22] <pitti> Keybuk: ok, that also explains the modprobe fbcon change; so if those two will go away as well, then we are down to lbm-drm and powerpc cdrom hda, which seems fine to me
[17:22]  * pitti is even inclined to drop the cdrom change as well
[17:22] <quidam-> hi, can i disable the new question for "install / live system" on ubuntu 10.04?, i want to start the live system directly
[17:23] <Keybuk> pitti: will leave that for now, can reevaluate later
[17:23] <Keybuk> I ported the change to the new rules file
[17:23] <pitti> ok
[17:24] <cjwatson> quidam-: you mean the one at the boot screen, or the one in X?
[17:24] <cjwatson> in fact I think you must mean the latter
[17:24] <cjwatson> quidam-: just don't boot with the maybe-ubiquity boot option
[17:24] <quidam-> cjwatson, hi! but that option is not include into the syslinux config file
[17:26] <cjwatson> quidam-: it's done dynamically ... can you please back up and give me a bit more context?  are you remastering a CD, or are you just booting the Ubuntu CD?
[17:26] <h0ar3> Hi guys.. any WUBI developers here?
[17:29] <quidam-> cjwatson, im making a remastering, usually i justchange the options on isolinux/text.cfg file and thats all, i've seen the new option "maybe-ubiquity" on /proc/cmdline but i can't find it in any config file
[17:30] <cjwatson> quidam-: you get it if the user just lets the splash screen time out rather than pressing a key at it and selecting "Try Ubuntu"
[17:30] <cjwatson> quidam-: remove hidden-timeout=1 from gfxboot.cfg and you won't get the splash screen and hence you'll never get maybe-ubiquity
[17:30] <quidam-> cjwatson, perfect, thanks! :)
[17:34] <alkisg> Hi, tuxpaint got in universe in Lucid, and its translations are now stripped but they don't end up in a langpack. Is that a packaging problem or a launchpad problem? Where can I find the build log so that I can see why the translations got stripped?
[17:35] <cjwatson> packages aren't automatically rebuilt when they're moved from main to universe.  somebody probably just needs to manually reupload it
[17:36] <alkisg> Thank you. I'll mention that to the bug report.
[17:36] <alkisg> https://bugs.launchpad.net/ubuntu/+source/tuxpaint/+bug/572994
[17:37] <h0ar3> Hi guys.. any WUBI developers here?
[17:37] <cjwatson> you would do better to ask your question directly
[17:42] <h0ar3> it is about wubi source.
[17:43] <h0ar3> checked out the code and it does not work
[17:43] <h0ar3> it seems there are missing things in v9.04
[17:43] <h0ar3> when actual developers come here?
[17:43] <cjwatson> no idea what the state of 9.04 is.  "does not work" does not constitute a bug report or anything that can really be replied to, though
[17:44] <cjwatson> as far as I remember the version on the 9.04 CD images was tested
[17:44] <h0ar3> cjwatson: they have migrated from NSIS to python in v9.04
[17:44] <cjwatson> I'm aware of that
[17:44] <h0ar3> however on windows I checkedout it.
[17:44] <h0ar3> and I saw that import ...s were incorrect
[17:45] <cjwatson> which ones?
[17:45] <h0ar3> code was not completed.
[17:45] <superm1> pitti, which change are you referring to?
[17:45] <h0ar3> cjwatson: i.e. it says from win32.backend import WindowsBackend
[17:45] <h0ar3> but there is no class named WindowsBackend etc.
[17:45] <h0ar3> there is no part
[17:45] <cjwatson> ./src/wubi/backends/win32/backend.py:43:class WindowsBackend(Backend):
[17:45] <h0ar3> does the actual loopmounting job....
[17:45] <h0ar3> ok try frontent
[17:45] <h0ar3> end*
[17:46] <cjwatson> ./src/wubi/frontends/win32/frontend.py:37:class WindowsFrontend(ui.Frontend):
[17:46] <cjwatson> loop-mounting is done in partman-auto-loop
[17:46] <h0ar3> now go to application.py
[17:46] <cjwatson> separate source package, integrated in Ubuntu
[17:47] <h0ar3> http://bazaar.launchpad.net/~ubuntu-installer/wubi/trunk/annotate/head:/src/wubi/application.py
[17:47] <h0ar3> from wubi.backends.win32 import WindowsBackend
[17:47] <h0ar3> from wubi.frontends.win32 import WindowsFrontend
[17:47] <cjwatson> that seems fine
[17:48] <h0ar3> oh
[17:48] <cjwatson> src/wubi/backends/win32/__init__.py and src/wubi/frontends/win32/__init__.py sort out the symbol resolution
[17:48] <h0ar3> does not it need ......frontends.backends.win32.backend imp..
[17:48] <h0ar3> ?
[17:48] <cjwatson> nope
[17:48] <cjwatson> ./src/wubi/backends/win32/__init__.py:1:from backend import WindowsBackend
[17:48] <h0ar3> hmm
[17:48] <cjwatson> (same for frontend)
[17:48] <h0ar3> does it run initially when we import from win32?
[17:48] <cjwatson> yes
[17:49] <h0ar3> interesting
[17:49] <h0ar3> okay
[17:49] <h0ar3> then I could not find the file where the grub4dos or lpvm things are done
[17:49] <cjwatson> grub is handled in the grub-installer package
[17:49] <cjwatson> I don't think lpvm is done at all at the moment
[17:49] <cjwatson> (er you mean lvpm right?)
[17:50] <h0ar3> where does it call grub-installer in python?
[17:50] <h0ar3> lvpm yeah
[17:50] <cjwatson> it doesn't call it directly - it preseeds the Ubuntu installer and sets it going, and the installer calls grub-installer as one of its many steps
[17:50] <cjwatson> data/preseed.lupin is the skeleton preseed file
[17:51] <ari-tczew> cjwatson: ping on e-mail's request
[17:51] <h0ar3> actually I am trying to develop something like wubi
[17:51] <h0ar3> for another linux distro which is not debian based
[17:51] <cjwatson> ari-tczew: sorry, I have had no time yet.  What is the deadline?
[17:51] <cjwatson> h0ar3: then you'll have to port wubi to use that distribution's automatic installation facilities
[17:51] <cjwatson> (if it has any)
[17:52] <ari-tczew> cjwatson: don't worry. enough time. just I ping you, I guess that you forgot about this
[17:53] <cjwatson> indeed, I'm in meetings for much of this week too
[18:12] <Sarvatt> pitti, Keybuk: the lbm-drm stuff has absolutely no use anymore even in lucid, by all means drop it :)
[18:13] <Keybuk> Sarvatt: I thought that there was still a need to be able to backport nvidia driver updates?
[18:14] <Sarvatt> nope, the nouveau userspace in lucid isn't compatible with kernels >= 2.6.34 anyhow
[18:17] <Keybuk> ok
[18:27] <h0ar3> cjwatson: thanks for helping. do you work at canonical?
[18:29] <LucidFox> Is there any theme at the moment that uses GTK CSD?
[18:31] <LucidFox> or any way I can force GTK to draw CSD?
[18:57] <slangasek> has anyone written a script to turn a dep3 patch header into a debian/changelog entry automatically?
[19:20] <cjwatson> h0ar3: yes (though that doesn't matter here, the main wubi author doesn't work for Canonical)
[19:46] <mathiaz> kees: hi - is -updates enabled in the build chroot by default?
[19:47] <mathiaz> kees: https://wiki.ubuntu.com/SecurityTeam/BuildEnvironment <- suggests to create sbuild chroot with --skip-updates
[19:49] <slangasek> mathiaz: "the build chroot" - which one?
[19:49] <slangasek> mathiaz: security is meant to apply cleanly w/o having to enable -updates
[19:50] <slangasek> so the stacking is release < security < updates < proposed
[19:50] <mathiaz> slangasek: the ones on the buildds
[19:50] <slangasek> yes, *which* ones on the buildds :)
[19:50] <slangasek> it depends on what you're building for
[19:50] <mathiaz> slangasek: oh ok
[19:51] <mathiaz> slangasek: so 1. for maverick (for now)
[19:51] <mathiaz> slangasek: which components should be enabled for the maverick sbuild chroot?
[19:52] <slangasek> that depends on whether you think you'll use it more for building for -proposed or for -security once maverick is released.  I would assume -proposed is more common if you're not on the security team, so would enable -updates (and that's what I do)
[19:53] <mathiaz> slangasek: gotcha
[20:21] <BlackZ> please, sponsor bug #590481
[20:51] <dobey> hi all
[20:51] <dobey> is there any clear documentation on dealing with python module api breaking in the packages?
[20:56] <ScottK> dobey: It's crazy talk to ever assume a python module doesn't break api with every release.
[20:57] <ScottK> barry is working on fixing that though.
[20:57] <dobey> huh?
[20:57] <ScottK> It's pretty normal for python module authors not to have a strong focus on maintaining API compatibility.
[20:58] <ScottK> (I'm assuming we're talking about something outside the core python distribution)
[20:58] <dobey> so the answer is "we just ignore the problem for now"
[20:58] <dobey> yes
[20:58] <dobey> i don't see anything in policy for dealing with it, which is why i ask
[20:58] <ScottK> We don't currently have a good way to deal with this.
[20:59] <ScottK> There is work being done upstream to give us the tools to manage it better.
[20:59] <dobey> and i figured "conflict with every package that depends on it" is not a great solution
[20:59] <ScottK> It's more like port the reverse depends to the new API and version the depend/build-depend.
[21:00] <dobey> well the problem comes when you upgrade the module but not those things that depend on it
[21:00] <ScottK> I have a vague recollection of porting the old API forward into a new version of a package once because it was easier (lots of repends)
[21:00] <ScottK> Agreed.
[21:00] <ScottK> repends/rdepends
[21:01] <ScottK> With the current technology we are pretty much at the mercy of module author's willingness to DTRT.
[21:02] <dobey> sometimes TRT is breaking API (as is in this case)
[21:03] <ScottK> In that case it would also involve some coordination with packages that use the old API.
[21:03] <ScottK> Standard best practices of deprecating for a release or two before removing old API are also good.
[21:05] <dobey> i think there's only one package that uses the api right now, and we maintain it, so that should be ok
[21:06] <dobey> it's hard to 'deprecate' something that is 'stop shadowing a core python module' :)
[21:12] <ScottK> dobey: What's the package?
[21:12] <dobey> python-ubuntuone-storageprotocol
[21:13] <dobey> i think ubuntuone-client is all that uses it so far :)
[21:14] <ScottK> That's likely true given the subject.
[21:15] <ScottK> dobey: You ought to check with the gsoc student that's doing the KDE client to make sure he's not using it in his project (he's normallly somewhat allergic to Python, so it's unlikely).
[21:15] <ScottK> dobey: Actually he is.
[21:16] <ScottK> So you've got another customer at least in development.
[21:16] <dobey> hrmm, i thought he was writing all c++
[21:16] <ScottK> dobey: "[16:15:06] <apachelogger> to do the pairing with desktopcouch"
[21:17] <ScottK> That's all.
[21:19] <dobey> well that's desktopcouch, which is a different module/package
[21:20] <CynthiaG> cjwatson: one last ping, I think we have a timezone issue (you're here as I'm not; I'm here as you're not), but if you're here, please pong
[21:20]  * apachelogger notes that there is no telling whether a organisation/company adopted the API internally
[21:21] <dobey> well primarily i'm concerned with "stuff in ubuntu"
[21:21] <dobey> if your stuff isn't in ubuntu, then it's up to you to keep it up to date with change to ubuntu if you want to support it
[21:21] <ScottK> apachelogger: True, but OTOH since this is all about connecting to Ubuntu One, the Ubuntu One people can probably tell if other stuff is connecting to it.
[21:21] <ScottK> apachelogger: Sounds like you ought to quick upload something.
[21:22] <dobey> it doesn't matter because this doesn't break apachelogger's gsoc stuff
[21:22] <apachelogger> aight
[21:22]  * apachelogger delegates that stuff to the syncdaemon ;)
[21:22] <dobey> and the gsoc stuff is supposed to be developed to be merged back into ubuntuone-client as i understand it anyway
[21:23] <dobey> so i still win :)
[21:23] <apachelogger> lol
[21:23] <cjwatson> CynthiaG: sort of here, for the record it helps with timezone desync if you just say what's on your mind rather than doing the ping/pong thing
[21:24] <CynthiaG> Well,  http://paste.ubuntu.com/445820/  These are the results of the benchmark you wanted, between June 4 and June 5 daily builds + your change to the mkisofs ordering
[21:24] <cjwatson> thanks.  it seems like a net improvement
[21:24] <CynthiaG> If you got it already on June 6, apologies
[21:24] <CynthiaG> Because I did say "cjwatson: link" then
[21:24] <cjwatson> I did, thanks
[21:24] <CynthiaG> Ok
[21:25] <cjwatson> I've been in meetings most of the time though
[21:25] <cjwatson> I think that's enough for me to say keep that change, at any rate
[21:25] <CynthiaG> Ah I see. Thanks a lot for your time :)
[21:25] <cjwatson> thanks for the testing!
[21:25] <CynthiaG> You're welcome
[21:30] <apachelogger> dobey: btw, do you happen to know who I can blame for evolution not obeying the contact schema from fdo?
[21:31] <dobey> apachelogger: i guess you could talk to rodrigo about evoultion issues
[21:32] <apachelogger> dobey: will do that, thanks :)
[21:49] <ScottK> apachelogger: Isn't this the same contact schema that breaks existing standards and requires the on disk format to be changed that there was an attempted SRU for a bit ago?
[21:49] <apachelogger> yes
[21:50] <apachelogger> well, breaking standards is a bit of a strong description there
[21:50] <apachelogger> more like - does not use them
[21:50] <apachelogger> which is rather weird IMHO
[21:50]  * apachelogger would think that it is much easier to seralize to vcard instead of a essentially completely new format
[21:50] <ScottK> So I think step zero would be align the FDO thing to existing stuff like vcard.
[22:50] <ccheney> anyone know of a way i can set a binaries $0 from a script when running it? i need to convince lvm to run when i have a script inline logging its output
[22:50] <ccheney> so i tried moving it to lvm.real and having a script lvm call it but that didn't work, and neither did replacing eg vgscan which is a symlink to lvm with my script
[22:50] <ccheney> since when calling lvm it then knows its $0 is not vgscan
[22:51] <ccheney> and thus refuses to work even when called eg:  lvm vgscan
[22:53] <cjwatson> the only way I know of is to use 'exec -a NAME', although that isn't portable so you'll probably have to use #! /bin/bash
[23:01] <ccheney> cjwatson, thanks
[23:11] <soren> ccheney: Are you just testing something locally, or do you want a solution that can be packaged?
[23:11] <ccheney> soren, testing bug locally
[23:11] <soren> ccheney: lvm accepts being named lvm.static as well.
[23:12] <ccheney> soren, oh ok
[23:14] <soren> ccheney: So use that instead of lvm.real and I /think/ you'll be ok.
[23:14] <ccheney> soren, ok thanks
[23:15] <ccheney> exec -a also worked for me with bash :)
[23:15] <soren> ccheney: Ok, cool :)
[23:57] <playya_> is it possible to use multiple distributions in the changelog or do i have to upload a tarball for every distribution?