[00:08] <cjwatson> jtaylor: I only merged subversion to get through the perl 5.14 transition; I have to admit it's a pretty long time since I looked at the subversion codebase non-trivially
[01:11] <infinity> cjwatson: The patch referenced in the bug is pretty trivial.
[01:11] <infinity> cjwatson: The setup required to verify it is significantly less so, however. :/
[01:12] <infinity> cjwatson: (Otherwise, I would have just done the SRU upload when I saw mention of it earlier)
[02:16] <doomrobo> Hi, how exactly are program arguments passed to **argv?
[02:44] <psusi> vanhoof, ping
[02:58] <dobey> doomrobo: that's a rather vague question; and this probably isn't the channel for it. this channel is more about packaging in ubuntu
[02:59] <doomrobo> ok, I've already tried ##linux, ##friendly-coders, and ##c in that order. I'm not sure where else to ask
[02:59] <doomrobo> I haven't found *any* hard docs for this
[03:00] <dobey> doomrobo: well, i'm not sure what you're trying to do exactly, but i can at least now guess that you want to do it in C, as opposed to some other language :)
[03:01] <doomrobo> I don't want to do anything, per sei, I just want to know how the argument list gets into **argv when I run a program from the command line.
[03:04] <doomrobo> on another note: how should I get started developing Ubuntu if I know C and C++ and I like to program and solve problems?
[03:05] <dobey> doomrobo: for that you could search through the bugs filed against packages written in those languages, and work with ubuntu developers and upstreams, to fix them
[03:06] <dobey> or find a bug that annoys you and fix it; or write some type of application that would be useful to the greater ubuntu community
[03:06] <dobey> there are lots of ways to do that :)
[03:08] <dobey> for the argument handling question, it's OS-dependant, but you might want to look at the POSIX section on command line handling, for specifics on how it generally works on most of the OSes you probably care about
[03:08] <doomrobo> thank you
[03:10] <ajmitch> doomrobo: something like http://linuxgazette.net/issue84/hawk.html might explain how the pieces work together
[03:15] <doomrobo> ajmitch, THANK YOU! It's in sys_execve()!
[03:15] <SpamapS> oi.. 6 hours and counting on mysql build on armel.. :-P
[03:16] <doomrobo> and...error missing semicolon
[04:16] <achiang> './usr/share/doc/libqt4-network/LGPL_EXCEPTION.txt' is different from the same file on the system -- known issue in precise?
[04:16] <achiang> Errors were encountered while processing:
[04:16] <achiang>  /var/cache/apt/archives/libqtgui4_4%3a4.7.4-1ubuntu3_i386.deb
[04:18] <achiang> someone else already filed it, i guess: #893832
[04:19] <achiang> and #893826 is essentially the same thing
[05:18] <pitti> Good morning
[05:20] <pitti> RainCT: that's quite deliberate; we anonymize username, hostname, cwd, etc.
[05:22] <pitti> RainCT: thanks for pointing out, I filed that as bug 893863
[07:26] <SpamapS> argh.. arm builds fine.. now amd64 failing some insanely complex test
[07:26]  * SpamapS curses mysql-5.5
[07:50]  * pitti pats SpamapS on the back and hands him another bucket of patience
[08:01] <dholbach> good morning
[09:53] <tjaalton> anyone using sbuild/schroot? even if the chroot has a correct resolv.conf, it fails to resolv hosts on the local dns (which is the default)
[09:54] <tjaalton> so i can't use my local mirror for builds
[09:54] <tjaalton> wondering what's wrong with it..
[10:07] <infinity> tjaalton: I certainly have no such issues with chroots...
[10:08] <cjwatson> Nor I
[10:09] <tjaalton> hmm, ok. must check my configs then
[10:09] <cjwatson> Wrong nsswitch.conf or something?
[10:09] <tjaalton> nsswitch.conf looks fine
[10:11] <infinity> Define "resolve hosts on the local dns".
[10:11] <infinity> Are you resolving FQDNS, or short hostnames?
[10:11] <tjaalton> FQDNS
[10:11] <tjaalton> sources.list has my mirror (and a.u.c) on it
[10:11] <infinity> And you're positive the right IP for your nameserver is in resolv.conf?
[10:11] <tjaalton> yep
[10:12] <infinity> And said nameserver allows requests from said machine? :P
[10:12] <tjaalton> using plain chroot seems to work fine
[10:12] <infinity> Oh, that's even stranger.
[10:12] <tjaalton> it's the same machine
[10:12] <tjaalton> :)
[10:12] <tjaalton> do-it-all monster
[10:12] <infinity> There should be no functional difference between schroot and chroot, from the POV of name resolution.
[10:12] <infinity> Unless someone's done something very hackishly evil.
[10:13] <debfx> is dh_builddeb supposed to call dpkg-deb in the order of the packages in debian/control?
[10:14] <tjaalton> uh oh
[10:14] <tjaalton> so the chroot actually had the wrong hostname on sources.list..
[10:14] <tjaalton> duh
[10:14] <tjaalton> :P
[10:15] <infinity> tjaalton: *slow clap*
[10:15] <debfx> it doesn't do so causing pkgstripfiles to symlink doc files nondeterministically which breaks multi-arch
[10:15] <tjaalton> infinity: :)
[10:16] <tjaalton> actually no, the chroot only has a.u.c, so it's defined elsewhere.. but anyway
[10:16] <debfx> pitti: ^
[10:22] <infinity> cjwatson: Are you still merging P-a-s from Debian on a regular basis?
[10:24] <cjwatson> infinity: now and again at least - why?
[10:25] <infinity> cjwatson: I've been led to believe some armhf bits landed upstream recently, and it would be shiny if we had those before I go and create a bunch of build records.
[10:25] <cjwatson> I just merged, no armhf stuff there yet
[10:25] <cjwatson> unless it was VERY recenet
[10:26] <infinity> lool may have misled me.  Looking. :P
[10:28] <cjwatson> not seeing anything in git
[10:28] <infinity> cjwatson: I'm seeing armhf stuff added and then removed (as entire entries were removed) in git. :P
[10:29] <cjwatson> yeah
[10:29] <infinity> cjwatson: And still some things that look wrong.  Though maybe for packages I don't care about.
[10:30] <cjwatson> you could just land them in the Ubuntu branch for now if you're in a rush
[10:30] <infinity> (gpart springs out)
[10:30] <infinity> Yeah, I might do so tomorrow.
[10:30] <infinity> Or, rather, "right before I create build records". :P
[10:31] <infinity> I wonder if this is still accurate:
[10:31] <infinity>  %wvstreams: !armel                                     # no working getcontext()
[10:31] <infinity> Meh.  I'll look again when it's not 3:30am.
[10:33] <ogra_> its 3:31 now
[10:33] <ogra_> or even 33 :P
[10:33] <infinity> ogra_: Helpful.
[10:38] <pitti> debfx: do you see an actual package which breaks due to different symlinking? pkgbinarymangler already has some checks for this
[10:38] <pitti> debfx: and the linking direction is quite predictable in all practical cases that I've seen; it wouldn't be for circular dependencies, though (which are rare fortunately)
[10:38] <debfx> pitti: bug #893826
[10:41] <pitti> debfx: ah, thanks; will have a look
[10:42] <lool> cjwatson, infinity: The armhf stuff was merged into Ubuntu some weeks ago; I had already poked cjwatson about it back then, and P-a-s was up-to-date
[10:43] <lool> cjwatson, infinity: http://lists.debian.org/debian-arm/2011/10/msg00047.html
[10:43] <infinity> lool: It's just that, entertainingly, the string armhf doesn't show up anywhere in P-a-s. ;)
[10:43] <lool> the patches were merged and then Colin merged P-a-s
[10:43] <debfx> qt4-x11 has a circular dependency libqt4-dbus <-> qdbus but these packages don't seem to be involved
[10:43] <lool> infinity: Which is good  :-)
[10:44] <infinity> lool: Not really, given that armel does...
[10:44] <lool> infinity: The reason is that when packages got reviewed, the likely outcome was to remove them from P-a-s entirely
[10:44] <lool> infinity: Because it's preferred to document these things in the Source package itself nowadays
[10:45] <lool> infinity: So whenever the Source package was correct and P-a-s wasn't, I've asked for the entry to be removed
[10:45] <infinity> lool: I see lots of armel in P-a-s.  Those entries won't get build records on armhf.
[10:45] <lool> infinity: I think I reviewed all of the Debian entries in my debian-arm@ email; I didn't check the Ubuntu one, but differences were minimal
[10:45] <lool> infinity: Some of them truly need porting, some of them are old cruft that we don't need to worry about
[10:46] <lool> 2 or 3 I couldn't test
[10:46] <infinity> lool: Kay, but some of them weren't removed (kexec-tools, for instance)
[10:46] <infinity> lool: But I'll just mangle the Ubuntu branch for now.
[10:47] <lool> infinity: Debian lacks armhf in control, I've filed a bug to remove the P-a-s entry
[10:47] <infinity> lool: linux-wlan-ng, etc, etc.
[10:47] <cjwatson> jamespage: hey, did you get anywhere with converting libcommons-discovery-java back to ant?
[10:48] <lool> infinity: Debian #645652 + Debian #645675
[10:48] <jamespage> cjwatson:  not yet - will look today
[10:48] <infinity> lool: Sure.  But open bugs aren't quite the same as your claim that it was all merged. ;)
[10:48] <pitti> cjwatson: d-i i386 failed to upload due to a "connection timed out" (WTH); I'll retry, ok?
[10:48] <lool> infinity: I will poke pkern on the latter bug; I thought he had applied them, but he only applied the other bugs' patches
[10:48] <infinity> lool: Like I said, I'll just fix it up locally for now.
[10:48] <lool> infinity: pkern merged a bunch of fixes already, I hadn't realized he had left one open with 9 patches
[10:49] <infinity> I probably should ask pkern for P-a-s commit access back, but it's been rather freeing not having to maintain it for a couple of years. :P
[10:50] <lool> I poked him
[10:52] <cjwatson> jamespage: thanks
[10:52] <cjwatson> pitti: yes please
[10:53] <pitti> debfx: oh, seems the Depends: field differs on i386 and amd64 then? as it goes in that order
[10:54] <pitti> debfx: but anyway, I'll sort it before, to ensure predictability
[10:54] <lool> infinity: outside of kexec-tools, which I've uploaded with armhf in control and for which I've updated Ubuntu's P-a-s now, do you have other packages of concern?
[10:54] <infinity> pitti: You could still run into cases where you symlink to a package that doesn't exist on all arches...
[10:55] <infinity> lool: I was just looking at "grep armel P-a-s"
[10:55] <pitti> infinity: right, but that doesn't seem to be the case here
[10:55] <cjwatson> I thought dpkg-gencontrol already sorted dependencies these days
[10:55] <infinity> lool: Pretty much everything there (except for the d-i kernels) is a cause for concern, though some are clearly less interesting.
[10:55] <infinity> pitti: No, but it's still a potential breakage.
[10:55] <cjwatson> maybe only partially or in some cases
[10:56] <infinity> pitti: I'm wondering how sane this "symlink to save space" thing is, when combined with multiarch's sctrict requirement of sameness across arches.
[10:56] <lool> infinity: Seriously?  they all seem boring to me; I see fpc and qemu-kvm as potential issues for our images
[10:56] <infinity> lool: Uhh.  Boring?
[10:56] <lool> infinity: Yeah, irrelevant things for armhf hardware
[10:56] <infinity> lool: We don't tend to refuse to build packages because they don't excite you. :P
[10:57] <pitti> infinity: well, so far it kept up quite well; it already skips cases like "arch: any to arch: all dependency"
[10:57] <lool> and definitely not on the critical path to building the archive, but I might have missed the goal
[10:57] <infinity> lool: The goal is correctness.
[10:57] <lool> sure, eventually it will be correct; the patches will get merged and packages will be fixed  :-)
[10:57] <cjwatson> lool: it's good to get P-a-s right early, as if we fail to do so then we have to reupload packages to get build records created for them
[10:58] <debfx> pitti: the order of the dependencies is the same but on i386 pkgbinarymangler has already processed libqt4-network before libqt4-xmlpatterns
[10:58] <infinity> cjwatson: Not technically true, mind you. ;)
[10:58] <lool> yup, but the said number of packages is small and they aren't relevant to our images and most of the time to our users
[10:58] <infinity> cjwatson: But that seems to have been the annoying status quo for a few years.
[10:58] <pitti> debfx: ah, I see
[10:58] <cjwatson> infinity: in practice, though - the last time I asked the Soyuz people to do it otherwise, they ummed and ahhed and eventually told me it was easier to reupload
[10:59] <cjwatson> infinity: speaking of annoying reuploads, please to be making sure that we start out with current imagemagick and icu as well as perl :-)
[11:00] <cjwatson> oh, and ocaml
[11:00] <infinity> Any other transitions? :P
[11:02] <cjwatson> ghc, exiv2, libjpeg; and mysql is due to start soon
[11:02] <cjwatson> I think that's about it
[11:02] <infinity> Yeah, I've noticed libjpeg.  And aren't we about to do it again?
[11:03] <pitti> meh, d-i hates me
[11:03] <pitti> the first time it built fine on i386 and failed to uploaod
[11:03] <infinity> Though, I guess ljt is meant to be a drop-in replacement for lj8
[11:03] <pitti> the retry now fails to build
[11:03] <pitti> "Disk full"
[11:03] <cjwatson> they claim that libjpeg-turbo matches libjpeg8's ABI, so I've told them that they should just make it build the same binary package; I don't want another transition for no reason
[11:03] <cjwatson> ah, that would be a kernel change
[11:03] <cjwatson> leave it with me
[11:04] <infinity> cjwatson: Any word on when the mysql bit's meant to land?
[11:04]  * infinity is tempted to P-a-s out mysql until it does, to avoid wasting the cycles.
[11:05] <pitti> infinity: mysql> how do you mean? it built on all arches, and is in NEW
[11:05] <infinity> pitti: Ahh, I was going with Colin's "mysql is due to start soon".
[11:06] <infinity> pitti: I guess very soon, then. :P
[11:06] <cjwatson> SpamapS seemed to be having build problems last night?
[11:06] <pitti> https://launchpad.net/ubuntu/+source/mysql-5.5/5.5.17-4ubuntu2 looks fine
[11:06] <Laney> there was an upstream patch that got cherry-picked
[11:06] <cjwatson> but yeah, it's built everywhere now
[11:06] <pitti> but I saw the "argh amd64 test failure" as well, not sure
[11:07] <pitti> maybe he retried
[11:07] <pitti> amd64 "Started 3 hours ago" -> looks like it
[11:07] <pitti> "Retry this build", aka. "the knob of desperation"
[11:08] <infinity> pitti: There is no way that I can make "knob of desperation" not sound filthy right now.
[11:08]  * infinity thinks it might be time for sleep.
[11:08]  * ogra_ sees pitti rarely does arm ... for us its often the "knob of relief" 
[11:08]  * cjwatson chokes
[11:08] <infinity> ogra_: And "knob of relief" is even worse...
[11:08] <Laney> ahem.
[11:08] <ogra_> *g* sorry :)
[11:08]  * pitti sticks fingers in his ears, sings LALALA and goes back to real work
[11:09] <lool> infinity: I merged the remaining armhf changes that Debian hadn't merged; the remaining packages need to be looked at before enabling (see notes on debian-arm)
[12:04] <jamespage> cjwatson: libcommons-discovery-java build system switched and uploaded - should clear down component-mismatches significantly
[12:29] <cjwatson> jamespage: yay
[12:59] <lool> cjwatson, infinity: Merged latest P-a-s changes from an hour ago that Phil pushed; he had missed the last bug in the BTS noise; also enabled qemu-kvm on armhf since Debian and Ubuntu differ on the qemu/qemu-kvm/kvm/qemu-linaro packaging here
[12:59]  * cjwatson works on fixing the php5 build failure and feels dirty

[14:09] <nigelb> didrocks: Man, you've been working hard today!
[14:09]  * nigelb just saw MPs on Tarmac :)
[14:10] <didrocks> nigelb: heh, I just push all the work that I needed for the unity integration :)
[14:12] <nigelb> :)
[14:42] <smoser> @pilot in
[14:43] <cjwatson> ev: are you really still patch piloting? :)
[14:44] <ev> oops!
[14:44] <ev> @pilot out
[14:50] <SpamapS> cjwatson: indeed, looks like that test just has a short timeout.. I may need to raise it if we see buildd failures again.
[14:51]  * SpamapS does the happy dance and prepares to start the rebuilds.. only 2 days late. :-P
[14:52] <cjwatson> heh, I'm just uploading php5 right now
[14:52] <cjwatson> I guess that will need another rebuild?  needed to fix the build failure though
[14:54] <SpamapS> Was it failing because libmysqlclient is multiarch now?
[14:54] <cjwatson> yes, I fixed that
[14:54] <SpamapS> If so, then you sir have saved me half a day. :)
[14:54] <cjwatson> oh, we need to process mysql-5.5 through NEW don't we
[14:54] <SpamapS> binary new's probably haven't passed yet
[14:54] <SpamapS> forgot about that
[14:54] <cjwatson> would it make sense for me to c-c this php5 upload until mysql-5.5 is NEWed?
[14:54] <cjwatson> speak now if soo
[14:54] <cjwatson> *so
[14:55] <cjwatson> I think it will, so I've interrupted the upload
[14:55] <SpamapS> yes it would
[14:55]  * cjwatson goes to process NEW
[14:56] <SpamapS> hmmm maybe somebody already did?
[14:56] <SpamapS> I only see translations
[14:57] <cjwatson> they're still in NEW
[14:57] <cjwatson> translations go with the binary uploads
[14:59] <cjwatson> accepted now
[15:02] <cjwatson> SpamapS: you should be able to start uploads in about 20 minutes.  I'll tell you when
[15:03] <SpamapS> cjwatson: ok that should give me time to eat breakfast. :)
[15:05] <nigelb> pitti: The Apport retrace sounds handy! :-)
[15:05] <pitti> thanks :)
[15:24] <cjwatson> SpamapS: you can start now
[15:26] <cjwatson> SpamapS: I'll upload php5 now - it's at level2, but only because of cyrus-sasl2 and I've checked that that doesn't matter here
[15:38] <hallyn> Jinkeys, powertop claims multitail really sucks power.
[15:39] <SpamapS> cjwatson: thanks, will start uploading shortly
[15:56] <SpamapS> cjwatson: php5 failed because of missing libmysqlclient_r .. will fix that (its a deprecated library as of 5.5)
[15:57] <cjwatson> yeah, I saw that - please do, thanks :-)
[15:57] <cjwatson> silly me for only test-building with 5.1
[16:20] <pitti> skaet: can I send my release report tomorrow morning? tl;dr is "no breakage" :)
[16:27] <SpamapS> hrm.. not having libmysqlclient_r seemed like a good idea at the time.. but I think I may need to add it back in ... <sigh>
[16:43] <cjwatson> SpamapS: http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html - oof
[16:43] <cjwatson> what went wrong there, I wonder
[16:44] <Laney> would be nice if it said why they were uninstallable
[16:44] <SpamapS> cjwatson: not sure, I've been testing installing them.. looking into it now
[16:44] <cjwatson> Laney: would be nice if it knew, yes
[16:45] <SpamapS> cjwatson: need to do another upload of mysql-5.5 to restore libmysqlclient_r ..
[16:45] <cjwatson> that's output from britney, it's not very informative
[16:45] <cjwatson> SpamapS: let's see what this is in case it can be fixed at the same time
[16:45] <Laney> oh, britney output
[16:45]  * Laney backs away slowly
[16:45] <SpamapS> cjwatson: indeed
[16:45]  * cjwatson updates a relevant chdist tree
[16:45] <cjwatson> Laney: my thoughts exactly
[16:47] <cjwatson> hmm, can't reproduce in chdist
[16:49] <cjwatson> SpamapS: let's not worry about this for now, if chdist doesn't show it up it's probably transient somehow
[16:49] <cjwatson> or britney being confused, although that's IME extremely rare (in fact I can't remember a case where that was true)
[16:50] <SpamapS> I don't see those packages on archive.ubuntu.com yet...
[16:50] <cjwatson> I just moved that code to a different machine so maybe that's at fault somehow
[16:50] <cjwatson> it has a special back door
[16:50] <SpamapS> ahh
[16:50] <SpamapS> of course it does ;)
[16:50] <cjwatson> rsyncs directly off ftpmaster
[16:51] <mterry> barry, do you know much about zope?
[16:51] <SpamapS> cjwatson: installing the deps manually in the right order seems to work in a precise chroot tho
[16:51] <cjwatson> ah, you know, I think this actually is britney being wrong!
[16:51] <barry> mterry: a bit
[16:51] <cjwatson> I believe it's confused by there being multiple versions of mysql-common in Packages
[16:51] <barry> mterry: what's up?
[16:52] <SpamapS> cjwatson: I'd have thought that wouldn't happen
[16:53] <mterry> barry, zope2.12 is FTBFS because it is currently demanding python2.6 (which was the supported version at time of release).  It builds if I change it to python2.7, but I'm not sure how likely that is to be safe run time wise.  Any ideas?
[16:53] <cjwatson> SpamapS: relatively recent intentional LP change, to smooth out architecture skew
[16:54] <barry> mterry: the what's new in zope 2.13 says it's added explicit support for 2.7
[16:54] <mterry> barry, yeah, but the source package itself is "zope2.12" and 2.13 isn't packaged yet in Debian
[16:55] <smoser> jamesh, were you going to merge https://code.launchpad.net/~cldunlap1/ubuntu/natty/mountall/fix2-for-805509/+merge/78135 ?
[16:55] <smoser> or were you expecting something back.
[16:55] <smoser> i can just mkae your two suggested changes, merge them and upload to precise.
[16:56]  * SpamapS wonders if mysql's developers have *ever* used shared libraries..
[16:56] <SpamapS> lrwxrwxrwx root/root         0 2011-11-23 08:52 ./usr/lib/x86_64-linux-gnu/libmysqlclient_r.so.18.0.0 -> libmysqlclient.so
[16:56] <SpamapS> >:|
[16:56] <mterry> barry, I suppose I could try to see if they applied a big "2.7 support" patch in their VCS and use it if so.  But I doubt it will be so easy
[16:56] <barry> mterry: hmm.  you might pop over to #launchpad-dev and ask flacoste, gary_poster, or benji.  they probably know more detailed specifics on 2.7 support
[16:57] <barry> mterry: right, probably not.
[16:57] <mterry> barry, OK, thanks
[16:57] <barry> mterry: let me know how it goes!
[17:00] <skaet> pitti,  ok by me.
[17:05] <smoser> mpt, could you maybe comment on https://code.launchpad.net/~cldunlap1/ubuntu/oneiric/xchat/fix-for-816506/+merge/80118 ? it seems that barry's logic is sane , but you are called out by name.
[17:12] <mterry> barry, gary_poster pointed me at some email addresses, which I'm following up on.  will let you know
[17:19] <cjwatson> so the problem is definitely that britney is selecting the earlier version of mysql-common
[17:19] <cjwatson> I'm working on untangling that
[17:20] <SpamapS> cjwatson: about ready to upload another version of mysql-5.5.. sounds like I don't need to hold off?
[17:21] <cjwatson> SpamapS: go for it, this is purely a reporting bug
[17:21] <cjwatson> to my amazement
[17:23] <SpamapS> cjwatson: ok, test rebuild almost complete then I'll push it up
[17:23] <SpamapS> hopefully I won't have to retry amd64 twice again
[17:23]  * SpamapS ponders disabling the test
[17:23] <cr3> if I package a python project that needs python-dev in buil-depends and I use makefile trickery in debian/rules (PYTHON_VERSIONS=$(shell pyversions -r); build-stamp: $(PYTHON_VERSIONS:%=build-ext-%)...), what happens if there are two versions of python installed, like 2.6 and 2.7 for example?
[17:24] <cjwatson> that would cause both build-ext-2.6 and build-ext-2.7 targets to be built
[17:24] <cr3> cjwatson: would python-dev be installed in the build environment for the corresponding version?
[17:25] <cjwatson> you should depend on python-all-dev for that
[17:25] <cjwatson> er, build-depend
[17:27] <cr3> cjwatson: ah, and I guess I should also depend on python-all instead of just python. I didn't know about that magical package, thanks!
[17:35] <smoser> @pilot out
[17:36]  * smoser probably owes dholbach more piloting time. 
[17:36] <Daviey> smoser: you owe it to yourself :)
[17:42] <cjwatson> SpamapS: I am victorious
[17:42] <cjwatson> SpamapS: (reporting bug fixed)
[17:42]  * SpamapS annoints cjwatson with oil
[17:43] <SpamapS> might want to avoid open flames for a while
[17:44] <dantti> cnd: I found out how to probe the info from the trackpad (using the packateLogger),  I'm trying to test it now..
[17:50] <mpt> smoser, done
[17:50] <cnd> dantti, great!
[17:51] <cnd> just this past week someone else has posted patches on linux-input for getting power from hid devices
[17:51] <cnd> once you get the data, it may make sense to use that framework too
[17:52] <dantti> cnd: yes, I saw it, first I tought it would grab the data it self, but it seems just to be a framework for that..
[17:53] <dantti> cnd: actually I think I'll have to add a get_feature_report(int id) to the hid-core since it seems that 0x43 is the code to grab features, and OSX sends 0x43 and 0x47 which is the report id of the battery status
[17:54] <jasox> Does someone know where is configuration files of alt tab in unity ?
[17:54] <cnd> dantti, it looks to my like the hid battery framework works properly for hid-compliant devices
[17:54] <cnd> or at least for the patch submitters device
[17:54] <cr3> is there a way to optionally require a package if it happens to be available? the problem is that python-zope.testrunner was added and breaks some of the functionality of python-zope.testing, the latter is always required but the former only when available on later releases of ubuntu, but I don't want to branch the project on a per ubuntu release basis :(
[17:54] <cnd> but apple products aren't hid-compliant for multitouch
[17:55] <cnd> so they may not be for battery either
[17:55] <dantti> cnd: but the patch does not grab the features values
[17:55] <cnd> dantti, I think it may be handled by generic hid layer stuff
[17:55] <cnd> I'm mostly making this assumption based on the submitter's message where he says it is working for him
[17:56] <dantti> the HID spec says that to grab some feature you should call GetFeature(report_id) and it seems linux hid does not have that..
[17:56] <cnd> hmm... I dunno
[17:56] <dantti> well at least the battery stuff seems hid compliant
[17:56] <cnd> ok
[17:57] <cnd> have you tried his patch to see if it works magically?
[17:57] <dantti> yes, and it didn't
[17:57] <cnd> ok
[17:57] <cnd> well, it sounds like you're on the right track at least :)
[17:57] <dantti> now I'm recompiling everything because somehow my patch in magic mouse module to do tests is not loading anymore..
[17:58] <dantti> cnd: yes, packagelogger said it very clear GET_FEATURE_REPORT , response: batery level 84% and the hex codes...
[17:58] <dantti> reverse engeneering made easy :P
[18:00] <cnd> yep
[18:10] <SpamapS> ahh and more missing files found..
[18:31] <JLuc> hello
[18:32] <JLuc> dear ubuntu canonical team : please read https://plus.google.com/u/0/104550365344856778857/posts/ELAYPthqToL
[18:33] <mterry> Who do I bug about problems with the wiki?   A page just got deleted when I tried to edit it...  I'd like to see if there's a backup somewhere
[18:45] <sladen> mterry: #is?
[18:45] <mterry> sladen, I'm in there now, thanks
[18:46] <sladen> JLuc: you want dpm
[18:46] <JLuc> i just want to share the linked concern
[18:46] <sladen> JLuc: https://launchpad.net/%7Edpm/+contactuser
[18:47] <sladen> JLuc: and it'll go to the person who can look into that, reply and do something about it
[18:47] <JLuc> ok
[19:21] <mterry> barry, FYI, the consensus is that zope2.12 and python2.7 should not be mixed (may not directly blow up, but there are security concerns, test failures, and it's just not a supported combo).  Talking to Debian about publishing zope2.13
[19:21] <barry> mterry: sounds good, thanks
[21:28] <mterry> jono, how did the Chuck meme start?
[21:28] <jono> mterry, I took a picture of chuck in front of a golf cart, cut it out and photobombed him
[21:28] <jono> it went on from there
[21:29] <ajmitch> poor chuck
[21:29] <chrisccoulson> lol
[21:29] <ajmitch> though I haven't seen as many new chuck images in the last couple of days
[21:29]  * chrisccoulson reminds himself to not get in the way of jono's camera
[21:29] <mterry> jono, :)
[21:30] <jono> haha
[21:31] <zul> its very much to do on my list next time
[21:32] <infinity> jono: At least it seems to have distracted you from other memes...
[21:33] <ajmitch> zul: paper bags help
[21:34] <zul> ill have to find more wham cds
[21:35] <jono> infinity, lol
[21:35] <jono> dig!
[21:35] <jono> ding!
[21:35] <infinity> There it is.
[21:40] <jono> :-)
[21:51] <chrisccoulson> jono, did you ever find out who left you the wham CD at UDS?
[21:52]  * SpamapS so wishes it was him
[21:53] <jono> chrisccoulson, I did, Krafty
[21:53] <jono> and popey left me the Village People one
[21:53] <seb128> lol
[21:54] <popey> :D
[22:00] <popey> http://popey.com/~alan/bargain_bucket.jpg <- sladen rummaging in the bargain bucket for YMCA
[22:01] <sladen> still don't know anything about the Wham one
[22:01] <sladen> but for about an hour I did briefly own a Village People CD
[22:02] <popey> and those pancakes were ace
[22:03] <dobey> heh
[22:05] <popey> it was somewhat surreal driving round orlando with sladen with YMCA blaring out
[22:06] <SpamapS> argh... 5 more hours until mysql 5.5 finishes building on arm.. :-P
[22:06] <infinity> SpamapS: Aww, pumpkin.
[22:08] <SpamapS> are we ever going to get like.. real ARM servers?! The thingy we saw at UDS was interesting.. but.. show me the money! :)
[22:09] <infinity> SpamapS: As a man who's been bootstrapping a new port on the cell phones on his desk, I suspect I'm grumpier than most on that front. :P
[22:09] <zul> infinity: dude grumpy is default for you
[22:10] <infinity> zul: Slanderous lies.  I'm both happy and go-lucky.
[22:10] <zul> infinity: sunshine and rainbows for everyone right?
[22:10]  * infinity glares congenially.
[22:11] <zul> heh
[22:15] <mwhudson> well hey, the work i am doing right now is in the overall effort of "make the kernel work on a15" so ...
[22:16] <infinity> mwhudson: Imaginary hardware, FTW?
[22:17] <mwhudson> infinity: yep
[22:18] <mwhudson> infinity: arm fast models, to be precise
[23:27] <szymon_g> hi
[23:49] <TheMuso> .c