[00:08] 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] cjwatson: The patch referenced in the bug is pretty trivial. [01:11] cjwatson: The setup required to verify it is significantly less so, however. :/ [01:12] cjwatson: (Otherwise, I would have just done the SRU upload when I saw mention of it earlier) [02:16] Hi, how exactly are program arguments passed to **argv? [02:44] vanhoof, ping [02:58] 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] ok, I've already tried ##linux, ##friendly-coders, and ##c in that order. I'm not sure where else to ask [02:59] I haven't found *any* hard docs for this [03:00] 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] 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] 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] 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] 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] there are lots of ways to do that :) [03:08] 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] thank you [03:10] doomrobo: something like http://linuxgazette.net/issue84/hawk.html might explain how the pieces work together [03:15] ajmitch, THANK YOU! It's in sys_execve()! [03:15] oi.. 6 hours and counting on mysql build on armel.. :-P [03:16] and...error missing semicolon [04:16] './usr/share/doc/libqt4-network/LGPL_EXCEPTION.txt' is different from the same file on the system -- known issue in precise? [04:16] Errors were encountered while processing: [04:16] /var/cache/apt/archives/libqtgui4_4%3a4.7.4-1ubuntu3_i386.deb [04:18] someone else already filed it, i guess: #893832 [04:19] and #893826 is essentially the same thing [05:18] Good morning [05:20] RainCT: that's quite deliberate; we anonymize username, hostname, cwd, etc. [05:22] RainCT: thanks for pointing out, I filed that as bug 893863 [05:23] Launchpad bug 893863 in apport (Ubuntu) "Standard bug title does not get anonymized" [Medium,Triaged] https://launchpad.net/bugs/893863 [07:26] 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] good morning [09:53] 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] so i can't use my local mirror for builds [09:54] wondering what's wrong with it.. [10:07] tjaalton: I certainly have no such issues with chroots... [10:08] Nor I [10:09] hmm, ok. must check my configs then [10:09] Wrong nsswitch.conf or something? [10:09] nsswitch.conf looks fine [10:11] Define "resolve hosts on the local dns". [10:11] Are you resolving FQDNS, or short hostnames? [10:11] FQDNS [10:11] sources.list has my mirror (and a.u.c) on it [10:11] And you're positive the right IP for your nameserver is in resolv.conf? [10:11] yep [10:12] And said nameserver allows requests from said machine? :P [10:12] using plain chroot seems to work fine [10:12] Oh, that's even stranger. [10:12] it's the same machine [10:12] :) [10:12] do-it-all monster [10:12] There should be no functional difference between schroot and chroot, from the POV of name resolution. [10:12] Unless someone's done something very hackishly evil. [10:13] is dh_builddeb supposed to call dpkg-deb in the order of the packages in debian/control? [10:14] uh oh [10:14] so the chroot actually had the wrong hostname on sources.list.. [10:14] duh [10:14] :P [10:15] tjaalton: *slow clap* [10:15] it doesn't do so causing pkgstripfiles to symlink doc files nondeterministically which breaks multi-arch [10:15] infinity: :) [10:16] actually no, the chroot only has a.u.c, so it's defined elsewhere.. but anyway [10:16] pitti: ^ [10:22] cjwatson: Are you still merging P-a-s from Debian on a regular basis? [10:24] infinity: now and again at least - why? [10:25] 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] I just merged, no armhf stuff there yet [10:25] unless it was VERY recenet [10:26] lool may have misled me. Looking. :P [10:28] not seeing anything in git [10:28] cjwatson: I'm seeing armhf stuff added and then removed (as entire entries were removed) in git. :P [10:29] yeah [10:29] cjwatson: And still some things that look wrong. Though maybe for packages I don't care about. [10:30] you could just land them in the Ubuntu branch for now if you're in a rush [10:30] (gpart springs out) [10:30] Yeah, I might do so tomorrow. [10:30] Or, rather, "right before I create build records". :P [10:31] I wonder if this is still accurate: [10:31] %wvstreams: !armel # no working getcontext() [10:31] Meh. I'll look again when it's not 3:30am. [10:33] its 3:31 now [10:33] or even 33 :P [10:33] ogra_: Helpful. [10:38] debfx: do you see an actual package which breaks due to different symlinking? pkgbinarymangler already has some checks for this [10:38] 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] pitti: bug #893826 [10:38] Launchpad bug 893826 in qt4-x11 (Ubuntu) "package libqt4-xmlpatterns 4:4.7.4-1ubuntu3 failed to install/upgrade: ErrorMessage: './usr/share/doc/libqt4-xmlpatterns/LGPL_EXCEPTION.txt' is different from the same file on the system" [High,Confirmed] https://launchpad.net/bugs/893826 [10:41] debfx: ah, thanks; will have a look [10:42] 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 === smb` is now known as smb [10:43] cjwatson, infinity: http://lists.debian.org/debian-arm/2011/10/msg00047.html [10:43] lool: It's just that, entertainingly, the string armhf doesn't show up anywhere in P-a-s. ;) [10:43] the patches were merged and then Colin merged P-a-s [10:43] qt4-x11 has a circular dependency libqt4-dbus <-> qdbus but these packages don't seem to be involved [10:43] infinity: Which is good :-) [10:44] lool: Not really, given that armel does... [10:44] infinity: The reason is that when packages got reviewed, the likely outcome was to remove them from P-a-s entirely [10:44] infinity: Because it's preferred to document these things in the Source package itself nowadays [10:45] 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] lool: I see lots of armel in P-a-s. Those entries won't get build records on armhf. === tkamppeter_ is now known as tkamppeter [10:45] 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] infinity: Some of them truly need porting, some of them are old cruft that we don't need to worry about [10:46] 2 or 3 I couldn't test [10:46] lool: Kay, but some of them weren't removed (kexec-tools, for instance) [10:46] lool: But I'll just mangle the Ubuntu branch for now. [10:47] infinity: Debian lacks armhf in control, I've filed a bug to remove the P-a-s entry [10:47] lool: linux-wlan-ng, etc, etc. [10:47] jamespage: hey, did you get anywhere with converting libcommons-discovery-java back to ant? [10:48] infinity: Debian #645652 + Debian #645675 [10:48] Debian bug 645652 in kexec-tools "Please add armhf to Architecture list" [Wishlist,Open] http://bugs.debian.org/645652 [10:48] Debian bug 645675 in buildd.debian.org "[p-a-s] misc armhf updates" [Wishlist,Open] http://bugs.debian.org/645675 [10:48] cjwatson: not yet - will look today [10:48] lool: Sure. But open bugs aren't quite the same as your claim that it was all merged. ;) [10:48] cjwatson: d-i i386 failed to upload due to a "connection timed out" (WTH); I'll retry, ok? [10:48] 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] lool: Like I said, I'll just fix it up locally for now. [10:48] infinity: pkern merged a bunch of fixes already, I hadn't realized he had left one open with 9 patches [10:49] 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] I poked him [10:52] jamespage: thanks [10:52] pitti: yes please [10:53] debfx: oh, seems the Depends: field differs on i386 and amd64 then? as it goes in that order [10:54] debfx: but anyway, I'll sort it before, to ensure predictability [10:54] 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] pitti: You could still run into cases where you symlink to a package that doesn't exist on all arches... [10:55] lool: I was just looking at "grep armel P-a-s" [10:55] infinity: right, but that doesn't seem to be the case here [10:55] I thought dpkg-gencontrol already sorted dependencies these days [10:55] lool: Pretty much everything there (except for the d-i kernels) is a cause for concern, though some are clearly less interesting. [10:55] pitti: No, but it's still a potential breakage. [10:55] maybe only partially or in some cases === Quintasan_ is now known as Quintasan [10:56] 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] infinity: Seriously? they all seem boring to me; I see fpc and qemu-kvm as potential issues for our images [10:56] lool: Uhh. Boring? [10:56] infinity: Yeah, irrelevant things for armhf hardware [10:56] lool: We don't tend to refuse to build packages because they don't excite you. :P [10:57] infinity: well, so far it kept up quite well; it already skips cases like "arch: any to arch: all dependency" [10:57] and definitely not on the critical path to building the archive, but I might have missed the goal [10:57] lool: The goal is correctness. [10:57] sure, eventually it will be correct; the patches will get merged and packages will be fixed :-) [10:57] 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] pitti: the order of the dependencies is the same but on i386 pkgbinarymangler has already processed libqt4-network before libqt4-xmlpatterns [10:58] cjwatson: Not technically true, mind you. ;) [10:58] 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] cjwatson: But that seems to have been the annoying status quo for a few years. [10:58] debfx: ah, I see [10:58] 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] 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] oh, and ocaml [11:00] Any other transitions? :P [11:02] ghc, exiv2, libjpeg; and mysql is due to start soon [11:02] I think that's about it [11:02] Yeah, I've noticed libjpeg. And aren't we about to do it again? [11:03] meh, d-i hates me [11:03] the first time it built fine on i386 and failed to uploaod [11:03] Though, I guess ljt is meant to be a drop-in replacement for lj8 [11:03] the retry now fails to build [11:03] "Disk full" [11:03] 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] ah, that would be a kernel change [11:03] leave it with me [11:04] 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] infinity: mysql> how do you mean? it built on all arches, and is in NEW [11:05] pitti: Ahh, I was going with Colin's "mysql is due to start soon". [11:06] pitti: I guess very soon, then. :P [11:06] SpamapS seemed to be having build problems last night? [11:06] https://launchpad.net/ubuntu/+source/mysql-5.5/5.5.17-4ubuntu2 looks fine [11:06] there was an upstream patch that got cherry-picked [11:06] but yeah, it's built everywhere now [11:06] but I saw the "argh amd64 test failure" as well, not sure [11:07] maybe he retried [11:07] amd64 "Started 3 hours ago" -> looks like it [11:07] "Retry this build", aka. "the knob of desperation" [11:08] 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] ogra_: And "knob of relief" is even worse... [11:08] ahem. [11:08] *g* sorry :) [11:08] * pitti sticks fingers in his ears, sings LALALA and goes back to real work [11:09] 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) === _salem is now known as salem_ [12:04] cjwatson: libcommons-discovery-java build system switched and uploaded - should clear down component-mismatches significantly === MacSlow is now known as MacSlow|lunch [12:29] jamespage: yay === doko_ is now known as doko [12:59] 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 [13:05] === SolidLiq is now known as solid_liq === MacSlow|lunch is now known as MacSlow [14:09] didrocks: Man, you've been working hard today! [14:09] * nigelb just saw MPs on Tarmac :) [14:10] nigelb: heh, I just push all the work that I needed for the unity integration :) [14:12] :) [14:42] @pilot in === udevbot_ changed the topic of #ubuntu-devel to: Precise open for uploads | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: ev, smoser [14:43] ev: are you really still patch piloting? :) [14:44] oops! [14:44] @pilot out === udevbot_ changed the topic of #ubuntu-devel to: Precise open for uploads | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: smoser [14:50] 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] heh, I'm just uploading php5 right now [14:52] I guess that will need another rebuild? needed to fix the build failure though [14:54] Was it failing because libmysqlclient is multiarch now? [14:54] yes, I fixed that [14:54] If so, then you sir have saved me half a day. :) [14:54] oh, we need to process mysql-5.5 through NEW don't we [14:54] binary new's probably haven't passed yet [14:54] forgot about that [14:54] would it make sense for me to c-c this php5 upload until mysql-5.5 is NEWed? [14:54] speak now if soo [14:54] *so [14:55] I think it will, so I've interrupted the upload [14:55] yes it would [14:55] * cjwatson goes to process NEW [14:56] hmmm maybe somebody already did? [14:56] I only see translations [14:57] they're still in NEW [14:57] translations go with the binary uploads [14:59] accepted now [15:02] SpamapS: you should be able to start uploads in about 20 minutes. I'll tell you when [15:03] cjwatson: ok that should give me time to eat breakfast. :) [15:05] pitti: The Apport retrace sounds handy! :-) [15:05] thanks :) [15:24] SpamapS: you can start now [15:26] 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 === dendrobates is now known as dendro-afk [15:38] Jinkeys, powertop claims multitail really sucks power. [15:39] cjwatson: thanks, will start uploading shortly [15:56] cjwatson: php5 failed because of missing libmysqlclient_r .. will fix that (its a deprecated library as of 5.5) [15:57] yeah, I saw that - please do, thanks :-) [15:57] silly me for only test-building with 5.1 === bregma_ is now known as bregma [16:20] skaet: can I send my release report tomorrow morning? tl;dr is "no breakage" :) === yofel_ is now known as yofel [16:27] hrm.. not having libmysqlclient_r seemed like a good idea at the time.. but I think I may need to add it back in ... [16:43] SpamapS: http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html - oof [16:43] what went wrong there, I wonder [16:44] would be nice if it said why they were uninstallable [16:44] cjwatson: not sure, I've been testing installing them.. looking into it now [16:44] Laney: would be nice if it knew, yes [16:45] cjwatson: need to do another upload of mysql-5.5 to restore libmysqlclient_r .. [16:45] that's output from britney, it's not very informative [16:45] SpamapS: let's see what this is in case it can be fixed at the same time [16:45] oh, britney output [16:45] * Laney backs away slowly [16:45] cjwatson: indeed [16:45] * cjwatson updates a relevant chdist tree [16:45] Laney: my thoughts exactly [16:47] hmm, can't reproduce in chdist [16:49] SpamapS: let's not worry about this for now, if chdist doesn't show it up it's probably transient somehow [16:49] or britney being confused, although that's IME extremely rare (in fact I can't remember a case where that was true) [16:50] I don't see those packages on archive.ubuntu.com yet... [16:50] I just moved that code to a different machine so maybe that's at fault somehow [16:50] it has a special back door [16:50] ahh [16:50] of course it does ;) [16:50] rsyncs directly off ftpmaster [16:51] barry, do you know much about zope? [16:51] cjwatson: installing the deps manually in the right order seems to work in a precise chroot tho [16:51] ah, you know, I think this actually is britney being wrong! [16:51] mterry: a bit [16:51] I believe it's confused by there being multiple versions of mysql-common in Packages [16:51] mterry: what's up? [16:52] cjwatson: I'd have thought that wouldn't happen [16:53] 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] SpamapS: relatively recent intentional LP change, to smooth out architecture skew [16:54] mterry: the what's new in zope 2.13 says it's added explicit support for 2.7 [16:54] barry, yeah, but the source package itself is "zope2.12" and 2.13 isn't packaged yet in Debian [16:55] jamesh, were you going to merge https://code.launchpad.net/~cldunlap1/ubuntu/natty/mountall/fix2-for-805509/+merge/78135 ? [16:55] or were you expecting something back. [16:55] 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] 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] >:| [16:56] 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] 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] mterry: right, probably not. [16:57] barry, OK, thanks [16:57] mterry: let me know how it goes! [17:00] pitti, ok by me. [17:05] 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] barry, gary_poster pointed me at some email addresses, which I'm following up on. will let you know [17:19] so the problem is definitely that britney is selecting the earlier version of mysql-common [17:19] I'm working on untangling that [17:20] cjwatson: about ready to upload another version of mysql-5.5.. sounds like I don't need to hold off? [17:21] SpamapS: go for it, this is purely a reporting bug [17:21] to my amazement [17:23] cjwatson: ok, test rebuild almost complete then I'll push it up [17:23] hopefully I won't have to retry amd64 twice again [17:23] * SpamapS ponders disabling the test [17:23] 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] that would cause both build-ext-2.6 and build-ext-2.7 targets to be built [17:24] cjwatson: would python-dev be installed in the build environment for the corresponding version? [17:25] you should depend on python-all-dev for that [17:25] er, build-depend [17:27] 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] @pilot out === udevbot_ changed the topic of #ubuntu-devel to: Precise open for uploads | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: [17:36] * smoser probably owes dholbach more piloting time. [17:36] smoser: you owe it to yourself :) [17:42] SpamapS: I am victorious [17:42] SpamapS: (reporting bug fixed) [17:42] * SpamapS annoints cjwatson with oil [17:43] might want to avoid open flames for a while [17:44] cnd: I found out how to probe the info from the trackpad (using the packateLogger), I'm trying to test it now.. [17:50] smoser, done [17:50] dantti, great! [17:51] just this past week someone else has posted patches on linux-input for getting power from hid devices [17:51] once you get the data, it may make sense to use that framework too [17:52] 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] 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] Does someone know where is configuration files of alt tab in unity ? [17:54] dantti, it looks to my like the hid battery framework works properly for hid-compliant devices [17:54] or at least for the patch submitters device [17:54] 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] but apple products aren't hid-compliant for multitouch [17:55] so they may not be for battery either [17:55] cnd: but the patch does not grab the features values [17:55] dantti, I think it may be handled by generic hid layer stuff [17:55] I'm mostly making this assumption based on the submitter's message where he says it is working for him [17:56] 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] hmm... I dunno [17:56] well at least the battery stuff seems hid compliant [17:56] ok [17:57] have you tried his patch to see if it works magically? [17:57] yes, and it didn't [17:57] ok [17:57] well, it sounds like you're on the right track at least :) [17:57] now I'm recompiling everything because somehow my patch in magic mouse module to do tests is not loading anymore.. [17:58] cnd: yes, packagelogger said it very clear GET_FEATURE_REPORT , response: batery level 84% and the hex codes... [17:58] reverse engeneering made easy :P [18:00] yep [18:10] ahh and more missing files found.. [18:31] hello [18:32] dear ubuntu canonical team : please read https://plus.google.com/u/0/104550365344856778857/posts/ELAYPthqToL [18:33] 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] mterry: #is? [18:45] sladen, I'm in there now, thanks [18:46] JLuc: you want dpm [18:46] i just want to share the linked concern [18:46] JLuc: https://launchpad.net/%7Edpm/+contactuser [18:47] JLuc: and it'll go to the person who can look into that, reply and do something about it [18:47] ok [19:21] 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] mterry: sounds good, thanks === negronjl_mobile is now known as negronjl === salem_ is now known as _salem [21:28] jono, how did the Chuck meme start? [21:28] mterry, I took a picture of chuck in front of a golf cart, cut it out and photobombed him [21:28] it went on from there [21:29] poor chuck [21:29] lol [21:29] 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] jono, :) [21:30] haha [21:31] its very much to do on my list next time [21:32] jono: At least it seems to have distracted you from other memes... [21:33] zul: paper bags help [21:34] ill have to find more wham cds [21:35] infinity, lol [21:35] dig! [21:35] ding! [21:35] There it is. [21:40] :-) [21:51] jono, did you ever find out who left you the wham CD at UDS? [21:52] * SpamapS so wishes it was him [21:53] chrisccoulson, I did, Krafty [21:53] and popey left me the Village People one [21:53] lol [21:54] :D [22:00] http://popey.com/~alan/bargain_bucket.jpg <- sladen rummaging in the bargain bucket for YMCA [22:01] still don't know anything about the Wham one [22:01] but for about an hour I did briefly own a Village People CD [22:02] and those pancakes were ace [22:03] heh [22:05] it was somewhat surreal driving round orlando with sladen with YMCA blaring out [22:06] argh... 5 more hours until mysql 5.5 finishes building on arm.. :-P [22:06] SpamapS: Aww, pumpkin. [22:08] 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] 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] infinity: dude grumpy is default for you [22:10] zul: Slanderous lies. I'm both happy and go-lucky. [22:10] infinity: sunshine and rainbows for everyone right? [22:10] * infinity glares congenially. [22:11] heh [22:15] well hey, the work i am doing right now is in the overall effort of "make the kernel work on a15" so ... [22:16] mwhudson: Imaginary hardware, FTW? [22:17] infinity: yep [22:18] infinity: arm fast models, to be precise [23:27] hi [23:49] .c