[00:00] 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] ugh [00:00] wpa supplicant is worse [00:00] ok [00:01] kees: btw, in case you hadn't seen it: http://www.coresecurity.com/content/vinagre-format-string [00:01] pochu: ah, I hadn't. thanks! [00:02] pochu: though, strangely, still no CVE [00:04] 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] kees: I think upstream confused that with a cve :) [00:05] kees: so no idea if there's one... [00:06] RAOF: yes I tried that with no success, I will try again :\ [00:07] RAOF: VLC doesn't play anythin, I can't use totem as it crashes when I use ATI properitary drivers [00:07] pochu: s'okay [00:07] why am I finding all of the bugs for? :) [00:07] MacSlow: http://www.kubuntu.org/~jriddell/tmp/notifier.py [00:08] http://www.kubuntu.org/~jriddell/tmp/notifier.notifyrc [00:08] that does into /usr/share/apps/kde4/notifier/ [00:35] 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] um... context? [00:36] was this the sync you were waiting for a while ago? [00:38] slangasek: it's related, yes [00:38] slangasek: but it should have already been pulled in. [00:38] hmm [00:38] (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] kees: ok; looking [00:39] seeing as LP doesn't seem to know about a source. [00:39] slangasek: cool. mostly I just don't know where it might be hiding. [00:39] Hobbsee: it seems to know it exists, but without any files. [00:40] kees: that's why I suspect it's the ppa bug [00:40] aaah [00:40] kees: ppas were creating those pages for any new source that was uploaded to a ppa, as a package in ubuntu [00:41] but never had sources attached to them, as the sources weren't actually in ubuntu. [00:41] Hobbsee: yucky. this package _should_ exist in Ubuntu, but ... I don't know where. It would have been NEW on Nov 28. [00:41] (assuming a debian-sync was run then) [00:41] while they fixed the bug, i don't think they ever removed the pages that shouldn't ahve been generated. [00:42] i presume slangasek will try to resync it [00:42] yes, currently trying [00:42] since I didn't do archive admin duties yesterday anyway :) [00:48] feisty's dead right? [00:48] Yes pwnguin [00:48] sigh, users... [00:48] It has reached its End of Life [00:49] heh [00:49] i was just thinking, if they sit on this for much longer [00:49] there wont be a good upgrade plan [01:27] Riddell: we need to talk. Celeste knows why [01:34] tseliot: that sounds worrying :) [01:34] I'm in the desktop room [01:35] doko: is gcc-spu meant to be in main instead of universe? (newlib dep-wait on powerpc) [01:35] kees: ^^ newlib is the package going a little funny during the autosync [01:35] so I'm following through on that, maybe it fixes us [01:36] 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] Launchpad bug 306257 in mlt++ "Please sync mlt++ 0.3.2-1 (universe) from Debian unstable (main)." [Wishlist,Confirmed] https://launchpad.net/bugs/306257 [01:37] I think mlt is still in NEW [01:37] sladen: yes please [01:37] StevenK: mlt didn't just FTBFS on all archs? That's where it was last I'd looked [01:38] It got given back on lpia [01:38] and it succeeded? [01:38] Riddell: so am I, I hadn't noticed. No, it's nothing to worry about [01:39] doko: fixed [01:40] oh aye, there you are [01:40] kees: bah, have to wait for a publishing run to be sure I know what's going on there [01:40] slangasek: I think it should be given-back everywhere, since it was Build-Depends things [01:41] crimsun: Did you attach the pulseaudio jaunty debdiff to bug 202089? [01:41] mlt built on i386 and amd64 [01:41] Launchpad bug 202089 in pulseaudio "Pulseaudio is blocking normal sound after resume" [Low,In progress] https://launchpad.net/bugs/202089 [01:41] TheMuso: no, I can do that now (it's also in my ppa) [01:41] StevenK, ScottK: ah, ok [01:41] StevenK: mlt is out of New and built at least on amd64 and ii386 [01:41] crimsun: No need, I'll fetch from your PPA. [01:41] TheMuso: ok. [01:41] 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] slangasek: cool, I'm not in a rush, just deeply curious. thanks for digging. did you see doko's mis-tab? [01:42] slangasek: oh, you did, I can't read [01:42] :-) [01:42] I was ignoring mlt since it hadn't built everywhere [01:42] oops [01:47] 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] ScottK: doh, out of time and not there yet, will pick it up after heading back to the hotel [02:23] 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] candrews: does XBMC use some ffmpeg type stack? [02:24] they do, but they also include python, faad, pulseaudio, mplayer, and a whole lot more :-) [02:24] I totally understand ffmpeg being included, that situation is nuts. [02:24] yeah I was going to point out that they probably have a reason to do this with ABI-unstable multimedia stack [02:24] ffmpeg and faad I'd put on that list. mplayer possibly. [02:24] s/ABI/API/ :( [02:25] but no excuse for Python or pulseaudio [02:25] RAOF: yeah, it's both :D [02:25] candrews: http://people.redhat.com/drepper/no_static_linking.html [02:25] Here's the conversation if anyone is interested: http://xbmc.org/forum/showthread.php?p=252592 [02:26] It's driving me nuts - if I was a distro (like Ubuntu) I would never accept such a package... [02:27] With PIE enabled would it even run? === nhandler_ is now known as nhandler [02:27] only on i386 IIRC [02:28] sdl, mad, sqlite, hal, glew, boost, libjpeg, libpng are also statically included [02:28] there's way more too - it's like it's own distro [02:28] ok we'd absolutely not accept that. [02:28] it is basically its own distro. [02:28] but then again, I don't feel you should use distribution policies as a bullying tactic for changing the project... [02:28] that's a decision for the project to make [02:29] perhaps for their purpose they'd rather have a no-dependencies bundled distribution [02:30] What do you think though? If you were them and all... [02:34] well... if I were them I'd have two separate distributions. [02:35] I understand their motivation for an all-in-one build [02:35] but at the same time I understand why that's a horrible nightmare for distributions. [02:35] 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] 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] auto = audio [02:36] 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] 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] 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] RAOF: I will try :) but I am no expert in that area [02:37] jdong: And then provide patches to the project, yes. [02:37] RAOF: right I was getting to that. Honest :) [02:37] RAOF: What is your affilation with the ubuntu project if you don't mind me asking? [02:37] phix: I'm a MOTU. [02:37] 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] It's always good to do something productive/constructive instead of standing there whining, in the open source world. [02:38] RAOF: I am not familiar with that acronym [02:38] phix: it means he's a scapegoat for not-very-maintained packages having bugs. [02:38] (joking) [02:39] 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] candrews: heh, what is this? [02:40] candrews: the developers probably feel the same way about debundling. [02:40] candrews: hence why I suggested it's probably not productive to whine at upstream to debundle [02:40] phix xbmc [02:40] I would like to contribute to the Ubuntu project, what can I do? :) [02:40] candrews: no idea what that is :) [02:40] phix: you can start by doing my decision theory homework... [02:40] www.xbmc.org [02:41] jdong: heh [02:41] * candrews cringes, and is quite glad he's out of college. [02:41] ditto [02:42] RAOF: Nice, a fellow Aussie [03:48] guys, i want to customize the live cd , i wanna change the kernel on it , any idea ? [03:50] 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] how can I create a repository with a pool directory? [04:47] MiladKhajavi, reprepro [04:50] cody-somerville: thank a lot [05:16] any gnome-app-install gurus happen to be around? === fta2 is now known as fta [08:25] doko: hppa should be on the main FTBFS list in about 15 minutes, I guess. LP is slow. === ma101 is now known as ma10 [08:52] What is this?! === Trewas666 is now known as Trewas [11:40] hey all [11:40] i think i've found a rather large bug that's somehow slipped thorugh the cracks [11:40] the 8.10 alternate cd never installs a bootloader === spacey_ is now known as spacey [13:07] hello === j1mc is now known as _j1mc [14:12] bdmurray, ping [14:14] Ah NCommander :) [14:15] morning lionel [14:15] Would you mind to approve this backport https://bugs..launchpad.net/hardy-backports/+bug/303265 [14:15] Launchpad bug 303265 in hardy-backports "please backport lightning-extension-locales from intrepid to hardy" [Undecided,Confirmed] [14:15] it would unbreak hardy-backports for lightning users :) [14:16] sure, I'll ack it [14:16] As a side note [14:16] Don't used confirmed in backport trackers [14:17] That's a good wayt o make sure your bug isnt' seen :-) [14:17] rah, sorry. Second time I've done it :( [14:17] Let me just test build this [14:18] NCommander: that beeing said, you use "In progress" when you approved it and waiting for backport for archive admin [14:18] YEah [14:18] DOn't ask, it really doesn't make a whole lot of sense to me either [14:19] https://help.ubuntu.com/community/UbuntuBackports -> this say to put as "Confirmed" when built and tested... [14:20] A backporters is supposed to do it [14:20] s/s//g [14:20] test building now [14:21] hum... that's not what I have observed in backports for some years, I think we should clarify this [14:21] (but that's not the topic today) [14:21] Anyway, once it test builds, I'll ack it [14:33] I thought anyone could confirm, but only a backporter could approve it [15:16] Anyway, once it test builds, I'll ack it [15:16] 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] +trust [15:21] Don't used confirmed in backport trackers <--- but https://help.ubuntu.com/community/UbuntuBackports says you should! [15:21] I fail :-P [15:41] interesting that lightning backport caused so much trouble. [15:41] it would seem like from bug 220166 that it received a good deal of testing. [15:41] Launchpad bug 220166 in lightning-sunbird "New upstream version available (v0.8)" [Wishlist,Fix released] https://launchpad.net/bugs/220166 [15:41] I guess nobody hit all the rdepends. [15:42] I am brainstorming on a prevu QA suite for backporting that tests installability, upgradability of a requested package and all its rdepends [15:42] jdong: if nobody use locales, it's not catched [15:43] jdong: my "pb" is that I opened the bug two weeks ago and we can not get this fixed [15:43] (more than things get broken, it's the game with backport) [15:47] NCommander: anything holding us back in your opinion on approving said backport? === ryu2 is now known as ryu === LucidFox is now known as The_Doctor === The_Doctor is now known as LucidFox [16:31] as far as i can tell io.py that is installed by python-stats breaks lxml.etree.parse [16:31] makes it segfault [16:38] Greetings what is the esiest way to create a deb file from a binary? [16:38] from a binary? [16:39] 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] the webapp is a .war file [16:39] Well the same way you make a deb from a source package [16:40] only you won't have a "build" target but only an install target [16:41] can you recomend any guide for creating a deb? [16:42] I think it's usually a mistake to look for "guides" that teach you to do a single operation without understanding it [16:43] Especially because people very seldom write them! [16:43] you are correct [16:44] Unfortunately I'm not immediately aware of the right doc to recommend for starting to learn deb packaging [16:44] It's something I've absorbed over time [16:45] I found an article about how to create a deb for debian, is there any difference with debian and ubuntu debs? [16:45] or are they the same? [16:45] I read something about creating a file called debian [16:45] very little, in general. In fact, very many Ubuntu packages are built from the Debian source, unmodified [16:45] sorry I mean directory [16:46] and in that file create controlfiles for how the deb should be assembled [16:46] 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] 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] ruthgard: you want this: http://www.debian-administration.org/articles/336 [16:51] Good morning [16:52] kees: was the libhttp-response-encoding-pel issue resolved? [16:58] StevenK, https://bugs.edge.launchpad.net/intrepid-backports/+bug/303245 [16:58] Launchpad bug 303245 in intrepid-backports "Please backport amule-adunanza" [Wishlist,In progress] [16:59] pitti: let me check, one moment [17:00] pitti: no: https://launchpad.net/ubuntu/+source/libhttp-response-encoding-perl [17:00] pitti: slangasek had some theories and was letting soyuz settle before poking at it some more. [17:01] 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] NCommander: Found it [17:13] StevenK, where did it go? [17:13] NCommander: I can't read, and grep can [17:14] Is there documentation somewhere on the process for requesting a package get imported from Debian experimental? [17:15] Like, I've seen wiki pages on DIF, but nothing on the Debian import itself [17:16] ebroder: https://wiki.ubuntu.com/SyncRequestProcess [17:16] crimsun: Ah, thanks. I'll check that out [17:17] ebroder: (there's also a tool in the ubuntu-dev-tools binary package called requestsync) [17:17] Even better. I'll check that out, too [17:19] NCommander: NEWed [17:19] Thanks StevenK [17:19] I appreciate it [17:22] crimsun: Does requestsync assume that you want to sync from unstable? === greg_g is now known as greg-g [17:23] ebroder: yes, but see -d [17:24] Hmm...that's not documented in my requestsync. New after Hardy? [17:25] ebroder: yes, in intrepid === dickydoo2 is now known as WelshDragon [17:27] mvo [17:27] where is he [17:28] gicmo: He is currently in a session, and may or may not be online. [17:28] Since I can't see him on IRC, I'd say not. === sabdfl1 is now known as sabdfl [17:42] Any backporters around who could ACK LP #301302 and LP #305001 ? [17:42] Launchpad bug 301302 in hardy-backports "Please backport pyyaml (3.05-2) and libyaml (0.1.1-1) from Intrepid to Hardy" [Undecided,New] https://launchpad.net/bugs/301302 [17:42] Launchpad bug 305001 in hardy-backports "Please backport sqlalchemy 0.4.8 from Jaunty to Hardy" [Undecided,New] https://launchpad.net/bugs/305001 === ivoks_ is now known as ivoks === fta2_ is now known as fta [17:53] hi [18:14] ebroder: I'll have a look at the first one. [18:14] ebroder: Why not 3.06-1 from Jaunty? [18:15] hey ScottK [18:15] Heya NCommander. [18:15] ScottK, I just had a good talk with mvo on selective backports installation [18:15] And ... [18:15] ScottK, he'd be interested in extending APT to do what we want [18:15] Excellent. [18:16] (the base is there, libapt needs a write interface, and synaptic needs an interface) [18:16] how are you planning to support that ? [18:16] NCommander: It'd probably be good to touch base with the bpo people too and see what they'd like. [18:16] Well, one person showed up at my backports meeting [18:16] (mvo showed, but had to run) [18:17] NCommander, do you have those ideas somewhere I can read ? [18:17] joaopinto, I posted it in a spec [18:17] https://wiki.ubuntu.com/Backports/SelectiveInstallation#preview [18:17] ScottK: No good reason. 3.06-1 should be fine [18:18] NCommander, checking, tks [18:19] NCommander: if you have mvo hostage there's something else I want to poke him about [18:19] jdong, I'm eating lunch w/ him [18:19] 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] Is there an appropriate place to assign bugs in the Ubuntu APT archive itself, such as bug 201179? [18:22] Launchpad bug 201179 in ubuntu "Contents.gz empty in dapper" [Undecided,Confirmed] https://launchpad.net/bugs/201179 [18:24] andersk: a mirror, or archive.ubuntu.com? [18:24] archive.ubuntu.com [18:26] that's not what the bug says? [18:26] us.archive.ubuntu.com is a mirror [18:26] sorry, i was probably unclear [18:26] andersk: ubuntu-mirror-admins, iirc. [18:26] archive.ubuntu.com has the same bug. [18:27] So this is not just a mirror problem. [18:27] oh, so it is [18:28] slangasek: where should https://launchpad.net/bugs/201179 get reassigned to, if it's wrong on a.u.c? [18:28] Launchpad bug 201179 in ubuntu "archive.ubuntu.com Contents.gz empty in dapper" [Undecided,Confirmed] [18:31] Soyuz [18:33] Thanks. I assigned it to Soyuz, can someone confirm? [18:36] 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:36] Launchpad bug 306723 in udev "udev breaks compatibility with multipath" [Undecided,Won't fix] https://launchpad.net/bugs/306723 [18:38] 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] Right [18:39] 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] so, unlike now, you must be sure that the package on backports have proper versions on the dependends, right ? [18:40] Hobbsee: I don't have a better place for it than where it currently is :/ [18:40] Hobbsee: "ubuntu-archive is subscribed" is more meaningful than anything else, I fear [18:41] ok, got it [18:43] slangasek: ah, so it's ubuntu-archive fixable? [18:45] NCommander, the implementation should be generic, so you can use this selectivity feature with PPAs or 3rd party repositories [18:56] ScottK: Who is the comment on LP 301302 directed at? Me? [18:56] Launchpad bug 301302 in hardy-backports "Please backport pyyaml (3.05-2) and libyaml (0.1.1-1) from Intrepid to Hardy" [Undecided,New] https://launchpad.net/bugs/301302 [18:56] Oh - did you want me to switch it to use pyyaml 3.06-1? [18:56] ebroder: Yes and yes. [18:56] Ok, cool - I'll check that now [18:57] 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. === ryanakca_ is now known as ryanakca [19:00] Hi ScottK-laptop, could you have a look at #303265 please? [19:04] lionel: Ack'ed. It's up to the archive admins now. [19:04] Hobbsee: should be, at least in coordination with soyuz [19:05] ScottK-laptop: thanks a lot! [19:05] slangasek: oh good [19:07] ScottK: I've updated LP 301302 - it does b/i/r on Hardy [19:07] Launchpad bug 301302 in hardy-backports "Please backport pyyaml (3.06-1) and libyaml (0.1.1-1) from Jaunty to Hardy" [Undecided,New] https://launchpad.net/bugs/301302 [19:09] * ScottK-laptop looks [19:25] ebroder: Ack'ed now it's up to when an archive admin has time to process it. [19:27] ScottK: Thanks a lot === robbiew1 is now known as robbiew [19:34] Oh my.... the synaptics driver is indented with tabs /and/ spaces, by the same person! [19:34] 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] ScottK-laptop: just the blueprint [19:54] doko: Thanks. That's more than I knew before. [20:09] im trying to build the gvfs backends package but I get this error --> http://rafb.net/p/RcDYTK61.html [20:09] what am I doing wrong? [20:09] mnemo: You don't have the build dependencies installed [20:10] ok thanks [20:10] You should build packages with something like dpkg-buildpackage or debuild - those will tell you if you're missing build deps === reed is now known as [reed] [20:10] ebroder: what is the exact command for building with these tools? [20:11] With debuild, you can basically just run debuild. With dpkg-buildpackage, I think you want to do dpkg-buildpackage -rfakeroot [20:11] ebroder: ok thanks I will try those [20:12] 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] It'll error, but it's harmless [20:12] (That is, it'll error if you don't pass -us -uc) [20:12] apt-get build-deps packagename is also useful. [20:13] sorry, build-dep [20:15] Hobbsee: I know that one already, but thank you [20:16] y/w [20:33] tjaalton: please fix mesa, ftbfs on armel and lpia, causing build failures on other packages [20:34] doko: yes, ideas abou the problem? [20:34] +t [20:35] what to those archs share that makes it fail? [20:35] s/to/do/ [20:35] tjaalton: create a lpia chroot and check ... [20:36] doko: hmm ok [20:37] c [20:39] Keybuk: do you see a reason to not upgrade jaunty's udev to 130? [20:39] Keybuk: it's needed for latest DK-Power [20:39] Denmark! [20:43] Keybuk: in fact, current Devkit itself needs it already [20:45] 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] mnemo: man dh_strip [20:46] aha! mnemo is here [20:46] right at the time I am about to leave for lunch [20:46] hey gicmo :) [20:47] did you see the patch Peter Christoffersen attached? [21:05] cr3: https://code.edge.launchpad.net/%7Echeckbox-dev/checkbox/trunk/+merges [21:06] cr3: its odd that there isn't a ubuntu branch for this, which any ubuntu dev/motu can write to [21:56] 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:56] Launchpad bug 303122 in elisa "[win32] File "lost.305.hdtv-lol.avi" plays partially on XP" [Undecided,New] https://launchpad.net/bugs/303122 [21:57] Sorry, LP bug #303112 [21:57] Launchpad bug 303112 in openafs "Please upgrade to 1.4.8 for Jaunty kernel 2.6.28 support" [Wishlist,Confirmed] https://launchpad.net/bugs/303112 [21:58] lol at 303122 [22:01] andersk: I had a look yesterday night. I wanted to give it more tests before uploading [22:01] andersk: how did you test it? server/client part? [22:02] 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] andersk: looks ok for the client, but for the server [22:05] Hmm. Testing the server is...complicated. [22:05] I know [22:05] but that would be cool to have some basic test for it [22:06] http://dietrichschroff.blogspot.com/2008/07/openafs-on-debian-configuration.html [22:07] andersk: yeah, I configured it once, but that's not an "easy" task [22:08] Possibly the /usr/sbin/afs-newcell makes this easier. [22:09] 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] Great, thanks. [22:09] andersk: fell free to ping me again if it's not done over the week-end === chuck__ is now known as zul [23:25] pitti: btw mdz is asking for you in the online services session (in the desktop room) if you're not otherwise occupied [23:26] bryce_: he's leading a language pack session with danilo [23:27] seb128: thanks [23:28] mnemo: hmm [23:39] doko: the mesa build problems are because lpia/armel don't have MAP_ANONYMOUS? [23:39] doko: You ran away! [23:40] wgrant: no, you did ;) anyway, meet in the lobby? [23:40] doko: Bah, only for a moment. Which building? [23:40] wgrant: coffe lobby [23:41] Sure, I'll be there in a minute or so. [23:41] $ fgrep -r MAP_ANONYMOUS /usr/include/ [23:41] /usr/include/bits/mman.h:# define MAP_ANONYMOUS 0x20 /* Don't use a file. */ [23:41] /usr/include/bits/mman.h:# define MAP_ANON MAP_ANONYMOUS [23:41] /usr/include/asm-generic/mman.h:#define MAP_ANONYMOUS 0x20 /* don't use a file */ [23:42] tjaalton: ^^^ [23:42] doko: so bits/mman.h, not sys/mman.h [23:42] tjaalton: did you check on lpia? [23:42] doko: nope [23:43] but x86 has sys/mman.h [23:44] doko: I'll try the chroot [23:55] doko: no match for lpia [23:55] oh wait [23:57] 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] doko: sorry, bits/mman.h is included by sys/mman.h, so it's something different then