[00:00] <RAOF> phix: You'll want to file a bug, attaching the output of alsa-info.sh (see https://wiki.ubuntu.com/DebuggingSoundProblems) and a pulseaudio log; you can get that by killing the current daemon with "pulseaudio -k" and starting a new one with "pulseaudio -vvv 2>&1 > pulseaudio-debug-log"
[00:00] <Keybuk> ugh
[00:00] <Keybuk> wpa supplicant is worse
[00:00] <phix> ok
[00:01] <pochu> kees: btw, in case you hadn't seen it: http://www.coresecurity.com/content/vinagre-format-string
[00:01] <kees> pochu: ah, I hadn't.  thanks!
[00:02] <kees> pochu: though, strangely, still no CVE
[00:04] <RAOF> phix: As a work around you can probably edit /etc/pulse/default.pa and defining a static alsa sink using hw:0,3 - the comments should make it obvious how to do this.
[00:05] <pochu> kees: I think upstream confused that with a cve :)
[00:05] <pochu> kees: so no idea if there's one...
[00:06] <phix> RAOF: yes I tried that with no success, I will try again :\
[00:07] <phix> RAOF: VLC doesn't play anythin, I can't use totem as it crashes when I use ATI properitary drivers
[00:07] <kees> pochu: s'okay
[00:07] <phix> why am I finding all of the bugs for? :)
[00:07] <Riddell> MacSlow: http://www.kubuntu.org/~jriddell/tmp/notifier.py
[00:08] <Riddell> http://www.kubuntu.org/~jriddell/tmp/notifier.notifyrc
[00:08] <Riddell> that does into /usr/share/apps/kde4/notifier/
[00:35] <kees> pitti, slangasek: uhm, okay, where is libhttp-response-encoding-perl ?  I don't see a build and I don't see it in NEW...
[00:36] <slangasek> um... context?
[00:36] <slangasek> was this the sync you were waiting for a while ago?
[00:38] <kees> slangasek: it's related, yes
[00:38] <kees> slangasek: but it should have already been pulled in.
[00:38] <slangasek> hmm
[00:38] <kees> (it's a build-dep for the thing I was waiting on)
[00:38]  * Hobbsee wonders if that's a ppa bug, coming back to bite us
[00:39] <slangasek> kees: ok; looking
[00:39] <Hobbsee> seeing as LP doesn't seem to know about a source.
[00:39] <kees> slangasek: cool.  mostly I just don't know where it might be hiding.
[00:39] <kees> Hobbsee: it seems to know it exists, but without any files.
[00:40] <Hobbsee> kees: that's why I suspect it's the ppa bug
[00:40] <kees> aaah
[00:40] <Hobbsee> kees: ppas were creating those pages for any new source that was uploaded to a ppa, as a package in ubuntu
[00:41] <Hobbsee> but never had sources attached to them, as the sources weren't actually in ubuntu.
[00:41] <kees> Hobbsee: yucky.  this package _should_ exist in Ubuntu, but ... I don't know where.  It would have been NEW on Nov 28.
[00:41] <kees> (assuming a debian-sync was run then)
[00:41] <Hobbsee> while they fixed the bug, i don't think they ever removed the pages that shouldn't ahve been generated.
[00:42] <Hobbsee> i presume slangasek will try to resync it
[00:42] <slangasek> yes, currently trying
[00:42] <slangasek> since I didn't do archive admin duties yesterday anyway :)
[00:48] <pwnguin> feisty's dead right?
[00:48] <nhandler_> Yes pwnguin
[00:48] <pwnguin> sigh, users...
[00:48] <nhandler_> It has reached its End of Life
[00:49] <pwnguin> heh
[00:49] <pwnguin> i was just thinking, if they sit on this for much longer
[00:49] <pwnguin> there wont be a good upgrade plan
[01:27] <tseliot> Riddell: we need to talk. Celeste knows why
[01:34] <Riddell> tseliot: that sounds worrying :)
[01:34] <Riddell> I'm in the desktop room
[01:35] <slangasek> doko: is gcc-spu meant to be in main instead of universe? (newlib dep-wait on powerpc)
[01:35] <slangasek> kees: ^^ newlib is the package going a little funny during the autosync
[01:35] <slangasek> so I'm following through on that, maybe it fixes us
[01:36] <ScottK> slangasek: If you've still got your archive-admin hat on, I'd appreciate it if you'd also sync mlt++ (Bug 306257)
[01:37] <StevenK> I think mlt is still in NEW
[01:37] <doko> sladen: yes please
[01:37] <slangasek> StevenK: mlt didn't just FTBFS on all archs?  That's where it was last I'd looked
[01:38] <StevenK> It got given back on lpia
[01:38] <slangasek> and it succeeded?
[01:38] <tseliot> Riddell: so am I, I hadn't noticed. No, it's nothing to worry about
[01:39] <slangasek> doko: fixed
[01:40] <Riddell> oh aye, there you are
[01:40] <slangasek> kees: bah, have to wait for a publishing run to be sure I know what's going on there
[01:40] <StevenK> slangasek: I think it should be given-back everywhere, since it was Build-Depends things
[01:41] <TheMuso> crimsun: Did you attach the pulseaudio jaunty debdiff to bug 202089?
[01:41] <ScottK> mlt built on i386 and amd64
[01:41] <crimsun> TheMuso: no, I can do that now (it's also in my ppa)
[01:41] <slangasek> StevenK, ScottK: ah, ok
[01:41] <ScottK> StevenK: mlt is out of New and built at least on amd64 and ii386
[01:41] <TheMuso> crimsun: No need, I'll fetch from your PPA.
[01:41] <crimsun> TheMuso: ok.
[01:41] <slangasek> thanks, I'll take mlt off my to-be-followed-up list :)
[01:41]  * ScottK knew he'd done a test build somehow
[01:42] <kees> slangasek: cool, I'm not in a rush, just deeply curious.  thanks for digging.  did you see doko's mis-tab?
[01:42] <kees> slangasek: oh, you did, I can't read
[01:42] <slangasek> :-)
[01:42] <StevenK> I was ignoring mlt since it hadn't built everywhere
[01:42] <doko> oops
[01:47] <slangasek> ScottK: looking now, but there are some other requests ahead of that one in the queue so it'll be a few minutes to churn through them
[02:01] <slangasek> ScottK: doh, out of time and not there yet, will pick it up after heading back to the hotel
[02:23] <candrews> I'm trying to convince XBMC to use dynamic linking instead of including all the source in their own tree and compiling everything in. Can anyone point me to a policy of Ubuntu, Debian, or another distro that demonstrated why dynamic linking is important?
[02:23] <jdong> candrews: does XBMC use some ffmpeg type stack?
[02:24] <candrews> they do, but they also include python, faad, pulseaudio, mplayer, and a whole lot more :-)
[02:24] <candrews> I totally understand ffmpeg being included, that situation is nuts.
[02:24] <jdong> yeah I was going to point out that they probably have a reason to do this with ABI-unstable multimedia stack
[02:24] <jdong> ffmpeg and faad I'd put on that list. mplayer possibly.
[02:24] <RAOF> s/ABI/API/ :(
[02:25] <jdong> but no excuse for Python or pulseaudio
[02:25] <jdong> RAOF: yeah, it's both :D
[02:25] <ScottK> candrews: http://people.redhat.com/drepper/no_static_linking.html
[02:25] <candrews> Here's the conversation if anyone is interested: http://xbmc.org/forum/showthread.php?p=252592
[02:26] <candrews> It's driving me nuts - if I was a distro (like Ubuntu) I would never accept such a package...
[02:27] <ScottK> With PIE enabled would it even run?
[02:27] <jdong> only on i386 IIRC
[02:28] <candrews> sdl, mad, sqlite, hal, glew, boost, libjpeg, libpng are also statically included
[02:28] <candrews> there's way more too - it's like it's own distro
[02:28] <jdong> ok we'd absolutely not accept that.
[02:28] <jdong> it is basically its own distro.
[02:28] <jdong> but then again, I don't feel you should use distribution policies as a bullying tactic for changing the project...
[02:28] <jdong> that's a decision for the project to make
[02:29] <jdong> perhaps for their purpose they'd rather have a no-dependencies bundled distribution
[02:30] <candrews> What do you think though? If you were them and all...
[02:34] <jdong> well... if I were them I'd have two separate distributions.
[02:35] <jdong> I understand their motivation for an all-in-one build
[02:35] <jdong> but at the same time I understand why that's a horrible nightmare for distributions.
[02:35] <jdong> But, if I were them, I would be annoyed as hell if every 2 days someone came asking for the libraries to be de-bundled.
[02:35] <phix> RAOF: I finally got HDMI set as default auto device :D  but it should of done that by default as it was the only device there.
[02:36] <phix> auto = audio
[02:36] <jdong> in my opinion the correct thing to do here is for the packaging community to debundle the libraries themselves for the reasonable libraries to debundle
[02:36] <RAOF> phix: Right.  Which is why you should file a bug to document (a) your set up (b) what was wrong, and (c) how you fixed it, so we can possibly make it Just Work. :)
[02:37] <jdong> I'd probably leave mplayer and ffmpeg bundled because those have very version-specific bugs, quirks, and APIs and I'd rather not be introducing extra bugs by mutant hybrid compiles of their code :)
[02:37] <phix> RAOF: I will try :) but I am no expert in that area
[02:37] <RAOF> jdong: And then provide patches to the project, yes.
[02:37] <jdong> RAOF: right I was getting to that. Honest :)
[02:37] <phix> RAOF: What is your affilation with the ubuntu project if you don't mind me asking?
[02:37] <RAOF> phix: I'm a MOTU.
[02:37] <jdong> I was going to say that with time upstream will probably appreciate the work you're doing and you can happily merge your efforts as an integral part of upstream.
[02:37] <jdong> It's always good to do something productive/constructive instead of standing there whining, in the open source world.
[02:38] <phix> RAOF: I am not familiar with that acronym
[02:38] <jdong> phix: it means he's a scapegoat for not-very-maintained packages having bugs.
[02:38] <jdong> (joking)
[02:39] <candrews> jdong - indeed! But, I'm not that familiar with C, especially not on the sheer scale and complexity of that project... and their build system is very large and frankly scares me.
[02:40] <phix> candrews: heh, what is this?
[02:40] <jdong> candrews: the developers probably feel the same way about debundling.
[02:40] <jdong> candrews: hence why I suggested it's probably not productive to whine at upstream to debundle
[02:40] <candrews> phix xbmc
[02:40] <phix> I would like to contribute to the Ubuntu project, what can I do? :)
[02:40] <phix> candrews: no idea what that is :)
[02:40] <jdong> phix: you can start by doing my decision theory homework...
[02:40] <candrews> www.xbmc.org
[02:41] <phix> jdong: heh
[02:41]  * candrews cringes, and is quite glad he's out of college.
[02:41] <phix> ditto
[02:42] <phix> RAOF: Nice, a fellow Aussie
[03:48] <mnabil_> guys, i want to customize the live cd , i wanna change the kernel on it , any idea ?
[03:50] <mnabil_> guys really i got sick from the ubuntu livecd customization how to's  all failed with me, always the live cd drops the initramfs shell
[04:35] <MiladKhajavi> how can I create a repository with a pool directory?
[04:47] <cody-somerville> MiladKhajavi, reprepro
[04:50] <MiladKhajavi> cody-somerville: thank a lot
[05:16] <LaserJock> any gnome-app-install gurus happen to be around?
[08:25] <wgrant> doko: hppa should be on the main FTBFS list in about 15 minutes, I guess. LP is slow.
[08:52] <AtomicSpark> What is this?!
[11:40] <catmando> hey all
[11:40] <catmando> i think i've found a rather large bug that's somehow slipped thorugh the cracks
[11:40] <catmando> the 8.10 alternate cd never installs a bootloader
[13:07] <Sockan> hello
[14:12] <NCommander> bdmurray, ping
[14:14] <lionel> Ah NCommander :)
[14:15] <NCommander> morning lionel
[14:15] <lionel> Would you mind to approve this backport https://bugs..launchpad.net/hardy-backports/+bug/303265
[14:15] <lionel> it would unbreak hardy-backports for lightning users :)
[14:16] <NCommander> sure, I'll ack it
[14:16] <NCommander> As a side note
[14:16] <NCommander> Don't used confirmed in backport trackers
[14:17] <NCommander> That's a good wayt o make sure your bug isnt' seen :-)
[14:17] <lionel> rah, sorry. Second time I've done it :(
[14:17] <NCommander> Let me just test build this
[14:18] <lionel> NCommander: that beeing said, you use "In progress" when you approved it and waiting for backport for archive admin
[14:18] <NCommander> YEah
[14:18] <NCommander> DOn't ask, it really doesn't make a whole lot of sense to me either
[14:19] <lionel> https://help.ubuntu.com/community/UbuntuBackports -> this say to put as "Confirmed" when built and tested...
[14:20] <NCommander> A backporters is supposed to do it
[14:20] <NCommander> s/s//g
[14:20] <NCommander> test building now
[14:21] <lionel> hum... that's not what I have observed in backports for some years, I think we should clarify this
[14:21] <lionel> (but that's not the topic today)
[14:21] <NCommander> Anyway, once it test builds, I'll ack it
[14:33] <Laney> I thought anyone could confirm, but only a backporter could approve it
 Anyway, once it test builds, I'll ack it
[15:16] <lionel> I'm a bit surprised by the fact that you can not a MOTU trust but somebody ack the lightning backport without even checking rdepends...
[15:16] <lionel> +trust
 Don't used confirmed in backport trackers <--- but https://help.ubuntu.com/community/UbuntuBackports  says you should!
[15:21] <NCommander> I fail :-P
[15:41] <jdong> interesting that lightning backport caused so much trouble.
[15:41] <jdong> it would seem like from bug 220166 that it received a good deal of testing.
[15:41] <jdong> I guess nobody hit all the rdepends.
[15:42] <jdong> I am brainstorming on a prevu QA suite for backporting that tests installability, upgradability of a requested package and all its rdepends
[15:42] <lionel> jdong: if nobody use locales, it's not catched
[15:43] <lionel> jdong: my "pb" is that I opened the bug two weeks ago and we can not get this fixed
[15:43] <lionel> (more than things get broken, it's the game with backport)
[15:47] <jdong> NCommander: anything holding us back in your opinion on approving said backport?
[16:31] <tclineks> as far as i can tell io.py that is installed by python-stats breaks lxml.etree.parse
[16:31] <tclineks> makes it segfault
[16:38] <ruthgard> Greetings what is the esiest way to create a deb file from a binary?
[16:38] <jdong> from a binary?
[16:39] <ruthgard> I have a tomcat webapp that I want to make deb file from, I want it to depend on apache tomcat and to put a file in the conf/Catalina/localhost folder for the tomcat configuration.
[16:39] <ruthgard> the webapp is a .war file
[16:39] <jdong> Well the same way you make a deb from a source package
[16:40] <jdong> only you won't have a "build" target but only an install target
[16:41] <ruthgard> can you recomend any guide for creating a deb?
[16:42] <maxb> I think it's usually a mistake to look for "guides" that teach you to do a single operation without understanding it
[16:43] <maxb> Especially because people very seldom write them!
[16:43] <ruthgard> you are correct
[16:44] <maxb> Unfortunately I'm not immediately aware of the right doc to recommend for starting to learn deb packaging
[16:44] <maxb> It's something I've absorbed over time
[16:45] <ruthgard> I found an article about how to create a deb for debian, is there any difference with debian and ubuntu debs?
[16:45] <ruthgard> or are they the same?
[16:45] <ruthgard> I read something about creating a file called debian
[16:45] <maxb> very little, in general. In fact, very many Ubuntu packages are built from the Debian source, unmodified
[16:45] <ruthgard> sorry I mean directory
[16:46] <ruthgard> and in that file create controlfiles for how the deb should be assembled
[16:46] <maxb> In this case, the "debian" directory refers to the packaging system, rather than the distribution - i.e. yes, it's "debian" for ubuntu packages too
[16:47] <maxb> Oh, one key thing to know is that many of the details of the format of debian packages are specified in the "Debian Policy Manual" - despite the name, it contains a *lot* of material on packaging too
[16:49] <tormod> ruthgard: you want this: http://www.debian-administration.org/articles/336
[16:51] <pitti> Good morning
[16:52] <pitti> kees: was the libhttp-response-encoding-pel issue resolved?
[16:58] <NCommander> StevenK, https://bugs.edge.launchpad.net/intrepid-backports/+bug/303245
[16:59] <kees> pitti: let me check, one moment
[17:00] <kees> pitti: no: https://launchpad.net/ubuntu/+source/libhttp-response-encoding-perl
[17:00] <kees> pitti: slangasek had some theories and was letting soyuz settle before poking at it some more.
[17:01] <slangasek> kees: pitti: it's a bug in sync-sources, plain and simple; I need to have a look to see exactly where the bug is
[17:13] <StevenK> NCommander: Found it
[17:13] <NCommander> StevenK, where did it go?
[17:13] <StevenK> NCommander: I can't read, and grep can
[17:14] <ebroder> Is there documentation somewhere on the process for requesting a package get imported from Debian experimental?
[17:15] <ebroder> Like, I've seen wiki pages on DIF, but nothing on the Debian import itself
[17:16] <crimsun> ebroder: https://wiki.ubuntu.com/SyncRequestProcess
[17:16] <ebroder> crimsun: Ah, thanks. I'll check that out
[17:17] <crimsun> ebroder: (there's also a tool in the ubuntu-dev-tools binary package called requestsync)
[17:17] <ebroder> Even better. I'll check that out, too
[17:19] <StevenK> NCommander: NEWed
[17:19] <NCommander> Thanks StevenK
[17:19] <NCommander> I appreciate it
[17:22] <ebroder> crimsun: Does requestsync assume that you want to sync from unstable?
[17:23] <crimsun> ebroder: yes, but see -d
[17:24] <ebroder> Hmm...that's not documented in my requestsync. New after Hardy?
[17:25] <crimsun> ebroder: yes, in intrepid
[17:27] <gicmo> mvo
[17:27] <gicmo> where is he
[17:28] <TheMuso> gicmo: He is currently in a session, and may or may not be online.
[17:28] <TheMuso> Since I can't see him on IRC, I'd say not.
[17:42] <ebroder> Any backporters around who could ACK LP #301302 and LP #305001 ?
[17:53] <Meztli-Xictli> hi
[18:14] <ScottK> ebroder: I'll have a look at the first one.
[18:14] <ScottK> ebroder: Why not 3.06-1 from Jaunty?
[18:15] <NCommander> hey ScottK
[18:15] <ScottK> Heya NCommander.
[18:15] <NCommander> ScottK, I just had a good talk with mvo on selective backports installation
[18:15] <ScottK> And ...
[18:15] <NCommander> ScottK, he'd be interested in extending APT to do what we want
[18:15] <ScottK> Excellent.
[18:16] <NCommander> (the base is there, libapt needs a write interface, and synaptic needs an interface)
[18:16] <joaopinto> how are you planning to support that ?
[18:16] <ScottK> NCommander: It'd probably be good to touch base with the bpo people too and see what they'd like.
[18:16] <NCommander> Well, one person showed up at my backports meeting
[18:16] <NCommander> (mvo showed, but had to run)
[18:17] <joaopinto> NCommander, do you have those ideas somewhere I can read  ?
[18:17] <NCommander> joaopinto, I posted it in a spec
[18:17] <NCommander> https://wiki.ubuntu.com/Backports/SelectiveInstallation#preview
[18:17] <ebroder> ScottK: No good reason. 3.06-1 should be fine
[18:18] <joaopinto> NCommander, checking, tks
[18:19] <jdong> NCommander: if you have mvo hostage there's something else I want to poke him about
[18:19] <NCommander> jdong, I'm eating lunch w/ him
[18:19] <jdong> NCommander: in the case when a backport causes a package to be uninstallable it'd be nice for APT / synaptic to fall back on the regular non-backported version if it is installable.
[18:22] <andersk> Is there an appropriate place to assign bugs in the Ubuntu APT archive itself, such as bug 201179?
[18:24] <Hobbsee> andersk: a mirror, or archive.ubuntu.com?
[18:24] <andersk> archive.ubuntu.com
[18:26] <Hobbsee> that's not what the bug says?
[18:26] <Hobbsee> us.archive.ubuntu.com is a mirror
[18:26] <Hobbsee> sorry, i was probably unclear
[18:26] <Hobbsee> andersk: ubuntu-mirror-admins, iirc.
[18:26] <andersk> archive.ubuntu.com has the same bug.
[18:27] <andersk> So this is not just a mirror problem.
[18:27] <Hobbsee> oh, so it is
[18:28] <Hobbsee> slangasek: where should https://launchpad.net/bugs/201179 get reassigned to, if it's wrong on a.u.c?
[18:31] <StevenK> Soyuz
[18:33] <andersk> Thanks.  I assigned it to Soyuz, can someone confirm?
[18:36] <btm> Are there any plans to pull multipath-tools from upstream or patch multipath-tools for an intrepid SRU to fix the API issues with udev? (LP #306723)
[18:38] <joaopinto> NCommander, I am not sure I got a clear understanding of the "Pinning dependencies" section, the text "Depends line which explicately pulls in the new version", means it will only pull the version if it's the dependency as a version requirement provided by the backports repos ?
[18:39] <NCommander> Right
[18:39] <NCommander> That means if we have a security fix in a backported library, we'd have to update its rdepends to pull it in unless the deps were pinned
[18:40] <joaopinto> so, unlike now, you must be sure that the package on backports have proper versions on the dependends, right ?
[18:40] <slangasek> Hobbsee: I don't have a better place for it than where it currently is :/
[18:40] <slangasek> Hobbsee: "ubuntu-archive is subscribed" is more meaningful than anything else, I fear
[18:41] <joaopinto> ok, got it
[18:43] <Hobbsee> slangasek: ah, so it's ubuntu-archive fixable?
[18:45] <joaopinto> NCommander, the implementation should be generic, so you can use this selectivity feature with PPAs or 3rd party repositories
[18:56] <ebroder> ScottK: Who is the comment on LP 301302 directed at? Me?
[18:56] <ebroder> Oh - did you want me to switch it to use pyyaml 3.06-1?
[18:56] <ScottK-laptop> ebroder: Yes and yes.
[18:56] <ebroder> Ok, cool - I'll check that now
[18:57] <ScottK-laptop> ebroder: You don't actually have to change anything for a no change backport.  Just build it locally, test that it installs and runs, and then say so in the bug.
[19:00] <lionel> Hi ScottK-laptop, could you have a look at #303265 please?
[19:04] <ScottK-laptop> lionel: Ack'ed.  It's up to the archive admins now.
[19:04] <slangasek> Hobbsee: should be, at least in coordination with soyuz
[19:05] <lionel> ScottK-laptop: thanks a lot!
[19:05] <Hobbsee> slangasek: oh good
[19:07] <ebroder> ScottK: I've updated LP 301302 - it does b/i/r on Hardy
[19:09]  * ScottK-laptop looks
[19:25] <ScottK-laptop> ebroder: Ack'ed now it's up to when an archive admin has time to process it.
[19:27] <ebroder> ScottK: Thanks a lot
[19:34] <Picklesworth> Oh my.... the synaptics driver is indented with tabs /and/ spaces, by the same person!
[19:34] <ScottK-laptop> doko: Is there some summary of yesterday's Python discussion written up somewhere?  I was trying to listen in, but could hear almost none of it.
[19:42] <doko> ScottK-laptop: just the blueprint
[19:54] <ScottK-laptop> doko: Thanks.  That's more than I knew before.
[20:09] <mnemo> im trying to build the gvfs backends package but I get this error --> http://rafb.net/p/RcDYTK61.html
[20:09] <mnemo> what am I doing wrong?
[20:09] <ebroder> mnemo: You don't have the build dependencies installed
[20:10] <mnemo> ok thanks
[20:10] <ebroder> You should build packages with something like dpkg-buildpackage or debuild - those will tell you if you're missing build deps
[20:10] <mnemo> ebroder: what is the exact command for building with these tools?
[20:11] <ebroder> With debuild, you can basically just run debuild. With dpkg-buildpackage, I think you want to do dpkg-buildpackage -rfakeroot
[20:11] <mnemo> ebroder: ok thanks I will try those
[20:12] <ebroder> Both of them will attempt to GPG-sign packages, so you may want to add -us -uc to the command line args to keep them from doing that
[20:12] <ebroder> It'll error, but it's harmless
[20:12] <ebroder> (That is, it'll error if you don't pass -us -uc)
[20:12] <Hobbsee> apt-get build-deps packagename is also useful.
[20:13] <Hobbsee> sorry, build-dep
[20:15] <mnemo> Hobbsee: I know that one already, but thank you
[20:16] <Hobbsee> y/w
[20:33] <doko> tjaalton: please fix mesa, ftbfs on armel and lpia, causing build failures on other packages
[20:34] <tjaalton> doko: yes, ideas abou the problem?
[20:34] <tjaalton> +t
[20:35] <tjaalton> what to those archs share that makes it fail?
[20:35] <tjaalton> s/to/do/
[20:35] <doko> tjaalton: create a lpia chroot and check ...
[20:36] <tjaalton> doko: hmm ok
[20:37] <TheMuso> c
[20:39] <pitti> Keybuk: do you see a reason to not upgrade jaunty's udev to 130?
[20:39] <pitti> Keybuk: it's needed for latest DK-Power
[20:39] <Nafallo> Denmark!
[20:43] <pitti> Keybuk: in fact, current Devkit itself needs it already
[20:45] <mnemo> im building a package using "fakeroot debian/rules binary" and then I do "dpkg -i ..." etc.... but can I do the same and also get debug symbols built into the binary???
[20:46] <mok0> mnemo: man dh_strip
[20:46] <gicmo> aha! mnemo is here
[20:46] <gicmo> right at the time I am about to leave for lunch
[20:46] <mnemo> hey gicmo :)
[20:47] <mnemo> did you see the patch Peter Christoffersen attached?
[21:05] <lifeless> cr3: https://code.edge.launchpad.net/%7Echeckbox-dev/checkbox/trunk/+merges
[21:06] <lifeless> cr3: its odd that there isn't a ubuntu branch for this, which any ubuntu dev/motu can write to
[21:56] <andersk> I'm trying to get a new upstream version of OpenAFS into Jaunty so that it will work on the Jaunty kernel: LP bug #303122.  Have I done everything right to request sponsorship for this upload?
[21:57] <andersk> Sorry, LP bug #303112
[21:58] <jdong> lol at 303122
[22:01] <lionel> andersk: I had a look yesterday night. I wanted to give it more tests before uploading
[22:01] <lionel> andersk: how did you test it? server/client part?
[22:02] <andersk> After installing the openafs-client package, you run m-a a-i openafs to build and install the kernel module.  Then you should be able to /etc/init.d/openafs start and see a bunch of stuff in /afs.
[22:04] <lionel> andersk: looks ok for the client, but for the server
[22:05] <andersk> Hmm.  Testing the server is...complicated.
[22:05] <lionel> I know
[22:05] <lionel> but that would be cool to have some basic test for it
[22:06] <andersk> http://dietrichschroff.blogspot.com/2008/07/openafs-on-debian-configuration.html
[22:07] <lionel> andersk: yeah, I configured it once, but that's not an "easy" task
[22:08] <andersk> Possibly the /usr/sbin/afs-newcell makes this easier.
[22:09] <lionel> andersk: well, will continue my work on it. You bug is complete, there is no problem about it, just we are a bit slow processing
[22:09] <andersk> Great, thanks.
[22:09] <lionel> andersk: fell free to ping me again if it's not done over the week-end
[23:25] <bryce_> pitti: btw mdz is asking for you in the online services session (in the desktop room) if you're not otherwise occupied
[23:26] <seb128> bryce_: he's leading a language pack session with danilo
[23:27] <bryce_> seb128: thanks
[23:28] <gicmo> mnemo: hmm
[23:39] <tjaalton> doko: the mesa build problems are because lpia/armel don't have MAP_ANONYMOUS?
[23:39] <wgrant> doko: You ran away!
[23:40] <doko> wgrant: no, you did ;) anyway, meet in the lobby?
[23:40] <wgrant> doko: Bah, only for a moment. Which building?
[23:40] <doko> wgrant: coffe lobby
[23:41] <wgrant> Sure, I'll be there in a minute or so.
[23:41] <doko> $ fgrep -r MAP_ANONYMOUS /usr/include/
[23:41] <doko> /usr/include/bits/mman.h:# define MAP_ANONYMOUS 0x20            /* Don't use a file.  */
[23:41] <doko> /usr/include/bits/mman.h:# define MAP_ANON      MAP_ANONYMOUS
[23:41] <doko> /usr/include/asm-generic/mman.h:#define MAP_ANONYMOUS   0x20            /* don't use a file */
[23:42] <doko> tjaalton: ^^^
[23:42] <tjaalton> doko: so bits/mman.h, not sys/mman.h
[23:42] <doko> tjaalton: did you check on lpia?
[23:42] <tjaalton> doko: nope
[23:43] <tjaalton> but x86 has sys/mman.h
[23:44] <tjaalton> doko: I'll try the chroot
[23:55] <tjaalton> doko: no match for lpia
[23:55] <tjaalton> oh wait
[23:57] <tjaalton> doko: right, better to install libc6-dev before checking that. anyway, it's the same as with armel, so mesa should be patched to check bits/
[23:58] <\sh> grmpf...why is the updated hardy kernel build with 4.2.3 but on upgraded hardy there is gcc 4.2.4?
[23:59] <tjaalton> doko: sorry, bits/mman.h is included by sys/mman.h, so it's something different then