[00:22] <ScottK> Riddell: Thanks.
[00:23] <ScottK> I'll remember not to harass you about it tomorrow then.
[00:24] <maco> Riddell: quarter? do you have quarters over there?
[00:24] <Laney> a 20p and a 5p!
[00:25] <Riddell> maco: that's the size my slice of cake needs to be :)
[00:25] <maco> Riddell: ahhhh
[00:25] <maco> Riddell: how many cm should the total cake be?
[00:25] <maco> because a quarter of a cupcake and a quarter of a sheet cake are a bit different
[00:26] <maco> hmm how many cm³ i mean?
[00:27] <Riddell> lots :)
[00:42] <SpamapS> am I crazy or is bug 610975 just a simple noop rebuild?
[00:46] <RAOF> It does indeed look like a no-change rebuild.
[00:46] <RAOF> Also, it looks like wxwidgets needs to be hit with the SONAME bat.
[00:48] <SpamapS> indeed, there's a bug in the way wxwidgets does its own linking IIRC
[00:48] <SpamapS> the debian bug that is linked to mentions it
[00:50] <ScottK> WX doing insane things is not surprising.
[00:53] <SpamapS> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=540060#105
[01:41] <mfilipe> hi! where is the ubuntu reviewboard? I want suggest the ubuntu-10.10 uses v86d+uvesafb
[01:43] <mfilipe> or... how do I suggest change in ubuntu?
[08:11] <dholbach> good morning
[08:55]  * dholbach hugs warp10 back
[08:55] <dholbach> warp10: happy birthday :)
[08:56]  * warp10 hugs dholbach
[08:56] <warp10> dholbach: Thank you Daniel! :D
[08:57] <dholbach> :-D
[08:57]  * DktrKranz tells happy bd to warp10, let's hope he reply back tomorrow for DktrKranz's one :)
[08:59] <warp10> DktrKranz: Thank you! BTW: I will definitely reply: Facebook reminder is my friend :P
[09:05] <dholbach> pitti, bdrung, mvo, seb128, tjaalton, Riddell, didrocks: thanks a lot for all the sponsoring you did
[09:06] <bdrung> dholbach: yw
[09:06] <didrocks> dholbach: yw :)
[09:06] <mvo> dholbach: cheers
[09:06] <dholbach> tumbleweed: ^ you too
[09:06] <bdrung> dholbach: you sponsored quite a lot, too
[09:07] <bdrung> dholbach: did you played with syncpackage?
[09:07] <bdrung> s/did/have/
[09:07] <dholbach> bdrung: there's others who thanked me for it already, so I didn't need to thank myself ;-)
[09:07] <dholbach> bdrung: no, didn't take a look at it yet
[09:08] <tumbleweed> dholbach: thanks
[09:08] <seb128> dholbach, you're welcome
[09:09] <didrocks> bdrung: syncpackage working well here (played with it three/four times, in the week-end, mostly)
[09:11] <bdrung> didrocks: great to hear
[09:14] <baptistemm> hello, why http://packages.ubuntu.com/search?searchon=sourcenames&keywords=bluez doesn't list maverick ?
[09:15] <baptistemm> hmmm -> http://packages.ubuntu.com/maverick/
[09:18] <geser> baptistemm: it's still waiting on a fix
[09:18] <dholbach> https://launchpad.net/ubuntu/+source/bluez should have it though
[09:19] <dholbach> baptistemm: can you update that merge proposal again? there's a merge conflict
[09:27] <ara> pitti, morning
[09:35] <bdrung> dholbach: can you have a look at bug #378240?
[09:36] <dholbach> bdrung: I'd prefer if I didn't have to
[09:36] <dholbach> bdrung: can somebody of the server team help out?
[09:37] <bdrung> dholbach: whom of the server team could i ask?
[09:37] <dholbach> I dunno, somebody in #ubuntu-server maybe
[09:37] <dholbach> I have no idea about xen, how to test it, etc.
[09:37] <dholbach> and need to get some other stuff sorted out :)
[09:38]  * ajmitch would suggest zul, perhaps
[09:38] <ajmitch> or he'd at least know who to talk to
[09:39] <bdrung> he's not online
[09:42] <bdrung> tumbleweed: ack-sync avoids duplicate work. i saw that you took the bugs that i would have taken. :)
[09:42] <psurbhi> hie! On choosing encrypted disk and lvm during Lucid installation, ext2 is chosen by default for /boot. Is there a particular reason for doing that?
[09:43] <bdrung> tumbleweed: you didn't reload bug #616190
[09:43] <tumbleweed> bdrung: it was already in my ack-sync queue
[09:43] <tumbleweed> I think mine took it when you'd already unassigned yourself
[09:43] <bdrung> yes
[09:44] <bdrung> tumbleweed: maybe ack-sync should check if ubuntu-sponsors is subscribed
[09:44] <tumbleweed> how about setting fix-committed at upload?
[09:45] <tumbleweed> (before unsubscribing)
[09:45] <tumbleweed> of course, there's another race there, because if the upload is processed before the fix-committed has set, we'll go confirmed -> released -> committed
[09:46] <bdrung> tumbleweed: yes, we have to do the upload as last step
[09:46] <tumbleweed> committed, unassign, upload?
[09:47] <bdrung> yes
[09:47] <bdrung> and fixing this bug before: task = list(bug.bug_tasks)[0]
[09:47] <bdrung> it's not always the first
[10:21] <hyperair> kirkland: ping.
[10:21] <hyperair> kirkland: if i stuff ecryptfs-add-passphrase into initramfs, what else does it need?
[11:18] <baptistemm> dholbach: I doubt I will, I will suppress the merge request
[11:18] <dholbach> baptistemm: ok :/
[11:20] <Riddell> ev: ping
[11:28] <sebner> RAOF: hola! Do you happen to know if the nvidia binary 3D driver is new xserver ready? :)
[11:34] <RAOF> sebner: Yes - it is, as long as you add IgnoreABI to xorg.conf.  It shouldn't be installable, but it is because of a packaging bug.
[11:36] <sebner> RAOF: lol, thx for the info :) I'm already using maverick, was just wondering if I can install the xserver upgrades :)
[11:37] <RAOF> You can, and it'll break nvidia unless you add IgnoreABI.
[11:38] <sebner> RAOF: fine, good to know. thanks again!
[11:49] <bdrung> Riddell: can you have a look at bug #607483?
[12:06] <Riddell> bdrung: have you checked what is still relevant in the current packagekit?
[12:14] <Riddell> should the "Version number suggests Ubuntu changes, but Maintainer: does not have Ubuntu address" error in dpkg-source be changes to allow linaro as well?
[12:47] <Freeaqingme> Hi folks. Kde 4.5 has been released today (or something real close to that), what would be a realistic eta to see that in ubuntu's repos?
[12:48] <Riddell> Freeaqingme: yesterday
[12:49] <Freeaqingme> I meant the stable repo
[12:49] <Riddell> see kubuntu.org
[12:50] <Freeaqingme> hmm, tnx. Wasn't meant to bother you for support though, sorry
[12:59] <megabraker> hi everybody, i have downloaded ubuntu lynx 10,01 i tried so hard to boot the live CD , erors occur i have runned it from vmx it works as  dream ,i have really a bad connection and sufer from windows XD , is there any tutorial describing how to ceate my one ubun lynx iso file or create live usb and thanks
[12:59] <megabraker> *create
[13:03] <megabraker> btw happy ramadam to erbody
[13:05] <diwic> megabraker, please use #ubuntu for support
[13:07] <megabraker> diwic i don think ubutnu would provide advenced live usb creation manual
[13:07] <diwic> megabraker, the "#ubuntu" irc channel
[13:48] <Riddell> seb128: is there some transition going on?  running ubiquity-gtk I get "RepositoryError: Failed to load typelib file '/usr/lib/girepository-1.0/GObject-2.0.typelib' for namespace 'GObject': Typelib version mismatch; expected 3, found 2
[13:48] <seb128> urg
[13:49] <seb128> Riddell, what version of gir1.0-glib-2.0 do you have?
[13:49] <seb128> do you get the issue with other pygtk softwares?
[13:49] <seb128> ie gdebi-gtk or update-manager
[13:51] <Riddell> gir1.0-glib-2.0: Installed: 0.6.14-1ubuntu2 Candidate: 0.9.3-0ubuntu2
[13:51] <mvo> Riddell: I had this as well, but upgrading cured it
[13:51] <Riddell> yes upgrading gir1.0-glib-2.0 fixed it
[13:51] <Riddell> guess something needs a tighter depend
[13:52] <Riddell> thanks
[13:52] <seb128> hum
[13:52] <seb128> is ubiquity using gobject introspection?
[13:52] <seb128> Riddell, I guess python-gobject should have an updated depends
[14:43] <tkamppeter> Does the build process in the buildds run as root or as a normal user?
[14:52] <sistpoty|work> tkamppeter: guessing from a build log on amd64 as a normal user + fakeroot: /usr/bin/fakeroot debian/rules clean
[15:04] <tkamppeter> How can I make pbuilder run the build process as non-root?
[15:04] <geser> doesn't pbuilder do it by default?
[15:05] <sistpoty|work> If I recall correctly: yes
[15:05] <tkamppeter> I have done a build and inside pbuiler python ignore PYTHONPATH, this is a behavior of python which it shows when one runs it as root.
[15:07] <tkamppeter> What I want to do is to run a Python program with some modules during a package build, but I do not want to install the program, to avoid creating a new package in main one day before FF.
[15:08] <sistpoty|work> hm... arch:all package then? I think there's a switch for pbuilder to call the -indep targets, maybe that's the problem? (geser: do you recall that switch)?
[15:09] <sebner> huhu sistpoty|work :)
[15:09] <tkamppeter> Yes, the binary package for which I run Python is arch:all, so the Python call is in the -indep target. The package is HPLIP.
[15:09] <sistpoty|work> hi sebner
[15:10] <geser> --binary-arch IIRC (it's mentioned in the pbuilder manpage)
[15:21] <tkamppeter> sistpoty|work, geser, which --binary-arch seeting do I have to use with pbuilder?
[15:22] <sistpoty|work> tkamppeter: actually I think it's not --binary-arch, but should be --debbuildopts -A to build (only) the arch:all package
[15:23] <sistpoty|work> (though I thougth there was a specific switch that does the same... *shrug*)
[15:25] <sistpoty|work> tkamppeter_: read the last statement?
[15:39] <dupondje> bdrung: https://bugs.launchpad.net/ubuntu/+source/xterm/+bug/616100 quite wrong patch :(
[15:44] <superm1> pitti, unfortunately same hash sum mismatch from the job running 10 min later :( http://people.canonical.com/~ubuntu-archive/cd-build-logs/mythbuntu/maverick/daily-live-20100811.log
[15:49] <tkamppeter> sistpoty|work, yes, I am trying now.
[15:49] <sistpoty|work> ah, k :)
[15:53] <tkamppeter> sistpoty|work, with
[15:53] <tkamppeter> sudo pbuilder build ../build-area/hplip_3.10.6-1ubuntu2.dsc --debbuildopts -A
[15:53] <tkamppeter> the PYTHONPATH still gets ignored.
[15:54] <sistpoty|work> tkamppeter: hm... in which rule do you use it? in clean/install or during build-*? (as afaict bulid will be called as a normal user, whereas install and clean has to be called as root or using fakeroot)
[15:56] <tkamppeter> sistpoty|work, in install-indep
[15:57] <sistpoty|work> tkamppeter: ah, that'll still be called with root (or fakeroot)...
[15:57] <tkamppeter> sistpoty|work, seems that already fakeroot triggers the security functionality of Python.
[15:58] <sistpoty|work> most probably, if python uses the c library and checks for the uid, then it won't see a difference between fakeroot and root
[16:06] <tkamppeter> sistpoty|work, but
[16:06] <tkamppeter> PYTHONPATH=. fakeroot python bin/pyppd /usr/share/ppd/splix/
[16:06] <tkamppeter> directly entered on the command line works.
[16:14] <tkamppeter> sistpoty|work, now I have simply uploaded the HPLIP package to see whether the buildds behaves different, but it also does not allow PYTHONPATH=. in that stage.
[16:15] <tkamppeter> sistpoty|work, is there a possibility to override this in Python?
[16:16] <sistpoty|work> tkamppeter: hm... no idea actually, I'm not a python expert
[16:19] <sistpoty|work> tkamppeter: maybe it's a different problem? PYTHONPATH=. bin/pyppd doesn't seem to work for me here (though I'm on debian/stable here at work)
[16:25] <sistpoty|work> tkamppeter: do you have got a __init__.py in the directory that contains the module files? even an empty one seems to suffice for me that PYTHONPATH works
[16:25]  * ogra misses slangasek as release manager, isnt it FF tomorrow ? nobody sent a reminder mail to u-d-announce
[16:26] <nigelb> ogra: heh :)
[16:33] <tkamppeter> sistpoty|work, there is an __init__.py.
[16:33] <tkamppeter> sistpoty|work, strange is also that the same Python script works in the foomatic-db build, but that package is quilt-style.
[16:35] <sistpoty|work> tkamppeter: hplip (3.10.6-1ubuntu2)? if I extract that, there's no __init__.py in debian/local/pyppd/pyppd
[16:36] <dupondje> https://bugs.launchpad.net/ubuntu/+source/xterm/+bug/616100 => added good patch :)
[16:38] <sistpoty|work> tkamppeter: aha, empty files aren't part of the unified diff, so __init__.py probably got removed since it was empty... that also explains why it works for a quilt-style package
[16:40]  * dupondje slaps grold  :)
[16:41] <tkamppeter> sistpoty|work, great, currently I am trying with an alternative command line:
[16:41] <tkamppeter> python -c 'import sys; sys.path[0] = "'`pwd`'"; from pyppd import runner; runner.run()' $(CURDIR)/debian/hplip-data/usr/share/ppd/hplip
[16:42] <tkamppeter> sistpoty|work, so the simplest fix had been a "touch pyppd/__init__.py" before the Python call.
[16:43] <sistpoty|work> tkamppeter: yes, or just add a newline to __init__.py so that it'll be part of the .diff.gz
[16:43] <grold> dupondje, I did't saw that you did the patch :) - almost a the same time
[16:43] <sistpoty|work> (or other whitespace, or change debian source format to 3.0 version that can copy with empty files)
[16:44] <dupondje> well the slap was for the bad fix :P
[16:44] <grold> is's the case for using "assigned to" function :)
[16:44] <grold> yes, my mistake
[16:44] <dupondje> as long it gets fixed :)
[16:45] <tkamppeter> sistpoty|work, alternative command line does not work, doing fill with whitespace approach.
[16:51] <tkamppeter> sistpoty|work, using the touch approach, to keep the pyppd stuff identical to upstream.
[16:57] <tkamppeter> sistpoty|work, thanks for the help, now the PPD compressor is working under pbuilder.
[17:04] <tkamppeter> sistpoty|work, fixed HPLIP package is uploaded now.
[17:06] <sistpoty|work> tkamppeter: yw :)
[17:34] <didrocks> bzr-builddeb: " * Fixed a logic error that stops -r working in merge-upstream"
[17:34]  * didrocks hugs james_w
[17:35] <james_w> didrocks: it was a stupid issue, sorry
[17:35] <james_w> didrocks: and it never worked :-)
[17:35] <didrocks> james_w: no worry, having this fixed will make my life soooo easier :-)
[17:35] <james_w> didrocks: I'll sync it today
[17:35]  * didrocks removes his <foo>-release branch ;)
[17:35] <didrocks> james_w: great! thanks
[17:42] <SpamapS> james_w: did you see my question about package-import ?
[17:44] <james_w> SpamapS: I did, and it's a bug lower in the stack than I was willing to deal with last night
[17:45] <james_w> SpamapS: if it's blocking you then I can dig around
[17:47] <SpamapS> james_w: I'm concerned that we won't be able to ship moin-1.9.3 in maverick, which has some XSS bugfixes
[17:47] <SpamapS> james_w: I can certainly hand-merge .. but it seems the MoM is also broken for moin. :-/
[17:48] <bilalakhtar> Hey, M-O-M is down!
[17:48] <SpamapS> james_w: james_w that said, its not crazy urgent.. just seems like a lot of packages are stuck and unmergeable by old or new methods. :-/
[17:50] <ScottK> SpamapS: They can be merged by hand.  This is painful, but may be the best move for something that needs to get in before feature freeze.
[17:51] <SpamapS> ScottK: yeah thats what I'm doing. The actual delta we're retaining is really small, so its not that hard actually.
[17:51] <ScottK> debian/changelog is usually the most painful.
[17:51] <SpamapS> ScottK: its like taking the bus because your lamborghini is in the shop tho. :-/
[20:12] <micahg> lamont: you rock :)
[20:14] <lamont> micahg: well, there was this deadline, you seee...
[20:15] <micahg> lamont: heh, I'm trying to do the same for a few things :)
[20:16]  * lamont wanders off for a while
[20:23] <[reed]> how does one request that a package get rebuilt to fix dependency problems?
[20:30] <lamont> [reed]: one uploads a new version that differs from the previous only in that the version has been bumped in debian/changelog
[20:31] <lamont> [reed]: if it's synced from debian, then 1.2-3 would become 1.2-3build1
[20:31]  * lamont wanders
[20:31] <[reed]> hmm
[20:33] <[reed]> wonder if there are directions for this somewhere ;)
[20:44] <micahg> [reed]: man dch?
[20:45] <[reed]> micahg: I meant the whole process ;)
[20:45] <micahg> :)
[20:45] <[reed]> never uploaded a new package before
[20:46] <asac> [reed]: did the package fail before?
[20:46] <asac> if so you need to ask someone to retry/give back who has the powers
[20:46] <[reed]> asac: it's libetpan-dev
[20:46] <[reed]> trying to install it complains about libdb4.7-dev
[20:47] <[reed]> because that's deprecated... it should be using libdb4.8-dev
[20:47] <[reed]> however, it's not hardcoded... rebuilding the package (which I've done locally) correctly adds libdb4.8-dev as a dependency
[20:47] <[reed]> (rather than libdb4.7-dev)
[20:47] <asac> [reed]: sure you mean -dev package? not the non-dev lib packages?
[20:48] <asac> let me look ;)
[20:48] <[reed]> asac: https://bugs.edge.launchpad.net/ubuntu/+source/libetpan/+bug/616474
[20:48] <[reed]> that's the bug I filed
[20:48] <asac> [reed]: yes, needs a build1
[20:49] <[reed]> wanna walk me through that or point me to some guide that tells me how to do that? :)
[20:50] <asac> [reed]: apt-get source libepan .... dch -i: here you replace the ubuntu1 with build1 in the top most line, then add a sane comment that contains "LP:BUGID" somehow to auto close the bug on upload
[20:51] <asac> produce the new source pieces: debuild -S (if you have devscripts installed) ... and make a debdiff *.dsc (old and new .dsc) to get a patch to attach to bug
[20:51] <asac> and ask for sponsor ship ;)
[20:51] <asac> in the dch -i step remember to check that your email isnt too bad ;)
[20:51] <[reed]> oke
[20:51] <asac> you can set NAME and DEBEMAIL in env to change whatever it picks
[20:52] <[reed]> yeah, pretty sure my env already has those set
[20:52] <asac> right. then you just need dch -i which is in devscripts package too
[20:55] <asac> [reed]: as comment you could use something along the line: "* fix LP:XXXXX - no change rebuild to pick up libdb4.8-dev in maverick"
[20:58] <[reed]> asac: ok, attaching debdiff now
[20:59] <[reed]> asac: attached
[20:59] <[reed]> asac: want to sponsor me? :p
[21:12] <bdrung> Riddell: no. you gave the last comment and according to your comment the bug could be closed. you should know best what you did.
[21:13] <bdrung> dupondje: not my fault, it's dholbach's fault (because he sponsored it) ;)
[21:29] <asac> [reed]: one mistake ... since you are on lucid dch -i generated "lucid" rather than maverick ;)
[21:29] <asac> i will fix that
[21:29] <[reed]> well, lucid needs to be fixed, too
[21:29] <[reed]> :p
[21:30] <asac> rsajdok: uploaded
[21:30] <asac> [reed]:
[21:30] <asac> [reed]: for lucid you need to make a SRU ;)
[21:30] <[reed]> how do I do that?
[21:31] <highvoltage> [reed]: https://wiki.ubuntu.com/StableReleaseUpdates
[21:31] <[reed]> highvoltage: thanks
[21:31] <asac> [reed]: complicated ... err ... easy. instead of build1 you use build0.10.4.1 ;) ... and instead of maverick lucid-proposed
[21:31] <asac> then attach debdiff ... nominate bug for lucid
[21:32] <[reed]> ok
[21:32] <asac> whoever sponsors it should probably do the right subscription of teams etc.
[21:50] <seb128> kees, there?
[21:56] <kees> seb128: hi! (at linuxcon)
[21:56] <seb128> kees, hey
[21:57] <seb128> kees, when you give +1 on mir does that means it can be promoted or does it still need some other review?
[21:57] <kees> seb128: means it can be promoted
[21:57] <seb128> ok thanks
[21:57] <kees> np
[21:57] <seb128> kees, what about -1, what do we need to solve the issue?
[21:58] <seb128> kees, our default photo mananager fail to build right now because your nacked bug #607757
[21:58] <kees> seb128: usually I say, but it's not always a very specific thing to be fixed. which one in particular?
[21:58] <seb128> kees, I'm not sure how to solve that
[21:58] <kees> oh yeah, libraw looks to be _really_ poor code quality.
[21:59] <seb128> I don't think we want to go f-spot because of that one lib though
[21:59] <seb128> go back rather
[21:59] <kees> if it was already in main, that's scary, but i guess it kind of invalidates my nack
[21:59] <seb128> no it was not
[21:59] <seb128> it's new
[22:00] <seb128> but the code it's based on is in main it seems yes
[22:00] <kees> right, that's what I meant.
[22:00] <seb128> what would you suggest we do next?
[22:00] <seb128> we need our default photo manager to build by some way
[22:01] <seb128> so either we need to go back to f-spot or try to drop that requirement or to promote the lib
[22:01] <kees> right. so, it seems like libraw is a library version of dcraw?
[22:01] <seb128> seems so
[22:01] <seb128> I've not checked myself but robert_ancell suggests that
[22:01] <seb128> reading his comment
[22:01] <kees> well, my nack is based on code quality, so if it's already in main, it's nonsense to nack it out now
[22:01] <kees> things could already call out of dcraw, so the library may not be worse.
[22:02] <ajmitch> just how nasty is the code?
[22:02] <kees> ajmitch: lack of bounds checking at the very least, didn't look to hard for integer overflows, though.
[22:03] <ajmitch> probably my fault that dcraw got into main a few years ago anyway :)
[22:03] <kees> seb128: so, if it's really the same code as dcraw, then I'm forced to un-nack, but if it's new, I would want to find a new RAW library.
[22:03] <seb128> kees, ok, so let's say we can promote it for now, I'm still interested to get better quality though so we might still want to fix obvious issue on the lib
[22:03] <kees> seb128: are there any others?
[22:04] <seb128> kees, libopenraw it seems
[22:04] <seb128> kees, not sure if it's any better though
[22:06] <seb128> kees, can we promote the lib for now so we get shotwell to build and can test it and take a work item to investigate alternatives to this lib?
[22:06] <kees> seb128: it looks to be C++, and a quick check seems to show it has at least some kind of stream management instead of crazy array poking
[22:08] <hrw> hi
[22:09] <hrw> what is a procedure to get package from Debian to be available in Ubuntu?
[22:09] <hrw> other then "compile it by yourself and keep it locally"
[22:09] <ajmitch> generally just a sync request is needed to get it into the development release, though we're pretty much at feature freeze
[22:10] <sladen> hrw: sync request
[22:10] <sladen> hrw: but you've got about 2 hours left to make it during this release cycle :)
[22:10] <ajmitch> once it's in the development release a backport to stable releases can be requested
[22:10] <hrw> ajmitch: I do not care about lucid
[22:10] <kees> seb128: I've +1'd it now
[22:10] <sladen> hrw: what is the package?
[22:10] <maco> which reminds me... any archive admins around?
[22:11] <seb128> kees, thank you
[22:11] <hrw> sladen: bluedevil + libbluedevil
[22:11] <kees> seb128: sure thing, thanks
[22:11] <hrw> sladen: Bluetooth integration for KDE 4
[22:11] <ajmitch> kde bluetooth stack? yeah, that looks useful
[22:11] <seb128> maco, why?
[22:11] <maco> seb128: new queue request with a cupcake as a bribe?
[22:11] <hrw> builds fine with fresh maverick - just finishing rebuild
[22:12] <seb128> maco, what in new?
[22:12] <maco> seb128: gally
[22:12] <sladen> Riddell: ^^ bluedevil+libbluedevil for Qt/KDE.  Would have be something sensible to have synched from Debian?
[22:12] <sladen> s/have/that/
[22:12] <maco> i told Riddell that if he did it id get him a cupcake during UDS
[22:13] <maco> but he's afk so... who wants a cupcake at uds? :P
[22:13] <ajmitch> maco: I do! :)
[22:15] <maco> i think seb128's interest means he's going to win the cupcake
[22:15] <seb128> I might ;-)
[22:15] <ajmitch> bah
[22:15] <ebroder> Where is the next UDS?
[22:15] <hrw> what should I use as 'consumer' in manage-credentials?
[22:15] <ajmitch> hrw: ubuntu-dev-tools, iirc
[22:16] <ajmitch> the manpage gives an example of it
[22:16] <hrw> thx
[22:18] <hrw> o. looks like someone added it (bluedevil) but it not got to archive
[22:18] <hrw> 11 hours ago
[22:18] <hrw> ;D
[22:19] <ajmitch> even better
[22:22] <hrw> yep
[22:24] <maco> ebroder: florida
[22:24] <ebroder> Oh, cool. I wonder if I can make that one
[22:30] <micahg> is Feature freeze at midnight UTC or morning EU time?
[22:31]  * micahg wanted to put stuff in later tonight
[22:31] <Laney> is it tomorrow already? :O
[22:31] <ajmitch> it's thursday here :)
[22:32] <chrisccoulson> i don't know what day it is here, my days all blur in to 1 ;)
[22:32] <ajmitch> stay away from strong drink & sleep deprivation :)
[22:32] <micahg> as in I was hoping to get stuff in w/in the next 9 hrs
[22:43] <sladen> micahg: more uploading and less asking :)
[22:44] <micahg> sladen: i'm at $WORK for another 3 hrs :)
[22:50] <directhex> mono 2.6.7 is Real Soon Now(tm), and is upstream's enterprise release.
[22:50] <directhex> i should push xsp and libgdiplus up
[22:51] <directhex> maybe when i feel less tired
[22:51] <sladen> directhex: wonder if that'll fix the non-ASCII rendered as squares issue I never tracked down
[22:52] <sladen> directhex: although upstream Mono reckoned that was a distro issue
[22:52] <directhex> sladen, maybe, cairo does dodgy things sometimes. i like blaming cairo for stuff
[22:53] <directhex> sladen, i wouldn't worry much about problems with winforms apps, they're not important to ubuntu
[22:54] <sladen> directhex: it's still a bug.  And quite a major one for any !English users
[22:55] <sladen> directhex: as in /every/ accented or CJK glyph is drawn as a square box in Winforms
[22:55] <directhex> i agree it's a bug, but i wouldn't say it's a priority one. winforms is for compatibility only, really. it's a garbage toolkit
[22:55] <directhex> i'd sooner use xaw3d
[23:32] <ScottK> sladen: bluedevil is already sync'ed a few days ago.
[23:35] <sladen> hrw: ^^ seems it was already done...