[00:01] https://bugs.launchpad.net/ubuntu/+source/blogtk/+bug/204895 is available for people wanting to work on fixing FTBFS. [00:02] doko: ^^^ is the list of all the packages that FTBFS and depend on python-central in a recent archive rebuilding test. [00:02] ScottK: thanks, watching the debian archive might make sense (and requesting syncs) [00:02] ok i'll check a pbuilder tut [00:04] ScottK2: it didnt work [00:04] ScottK2: i dont understand [00:04] it should have worked now [00:06] everything is where it should be, my patch in the debian/patched folder and in the patches [00:06] and when i ran dpatch-edit-patch y did the changes and then exit 0 [00:07] Bruno1: What's ths problem? [00:07] i dont know what went wrong [00:07] Laney: i applied a patch to the cryptsetup man page [00:08] and after appling the patch and building the .deb its not working [00:08] the changes are not showing up [00:10] doko: RE python-central I mentioned looking for sync's in the bug. [00:11] Laney: bug #164181 [00:11] Launchpad bug 164181 in cryptsetup "Manual page typos" [Low,In progress] https://launchpad.net/bugs/164181 [00:11] Bruno1: Did you edit debian/rules to apply the patches? [00:12] ScottK2: http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-new-pycentral;users=doko@cs.tu-berlin.de [00:12] Laney: no, what do i have to edit? [00:13] Bruno1: Did cryptsetup already have patches in debian/patches? [00:13] Laney: yes [00:15] doko: Thanks [00:15] Bruno1: Weird. I suggest you double check 00list to see if you listed your patch correctly. If so, check debian/rules to see how the patches are being applied. `man dpatch' (section "DPATCH IN DEBIAN PACKAGES") has some useful information on the structure of debian/rules. [00:16] Laney: ok, i'll check the dpatch man page [00:16] Laney: the 00list is ok [00:17] * ScottK2 fires a shot at the do nothing MC. === Pici` is now known as Pici [00:20] Laney: there is no patch: patch-stamp in the rules, is that normal? [00:21] Bruno1: Did your package use dptach before you started? [00:21] If not, you need to add that stuff to debian/rules [00:21] Is anyone interested in sponsoring a sync request (Bug 190744)? [00:21] Launchpad bug 190744 in libgdamm3.0 "Request: Upgrade libgdamm3.0 to upstream version 2.9.81" [High,Confirmed] https://launchpad.net/bugs/190744 [00:22] Bruno1: Does it include dpatch or dpatch.make? [00:22] Laney: it has dpatch.make [00:22] The FFE has already been approved. [00:23] ScottK2: yeah it used dpatch [00:23] Bruno1: Then (afaik) you don't need to explicitly give a (un)patch rule [00:24] Bruno1: Do you see the rest of the patches being applied when you run debuild? [00:27] Laney: no, but i cant scroll upwards enough to see the beginning of the output [00:27] Bruno1: You can always pipe it to more [00:28] Laney: how [00:28] Bruno1: debuild | more [00:28] oh, but building it again? [00:28] Bruno1: Sure [00:30] Laney: this time it didnt build [00:31] http://pastebin.ca/952264 [00:32] Laney: should start the whole process again? [00:33] Bruno1: I think that dpatch expects your patch to have been applied, but is finding something different. [00:34] Laney: so the patches are not being applied? [00:35] Bruno1: No, before you build the package "debian/rules clean" is run to return the working directory to a clean state. It's failing there. [00:35] Part of clean is unapplying any patches from debian/patches. [00:37] You could try "patch -p0 < debian/patches/07_manpage_typo_fix" and then debuild if that works [00:37] I'm pretty new to this stuff myself ;) [00:38] Laney: ok :) [00:38] Laney: should run that command right now, or in a new source directory [00:39] Bruno1: Now [00:40] Laney: it said [00:40] can't find file to patch at input line 11 [00:40] Perhaps you used the wrong -p or --strip option? [00:40] The text leading up to this was: [00:41] http://pastebin.ca/952272 [00:41] and then it asks for a file to patch [00:42] cryptsetup.8~, is that the right file? [00:45] yeah [00:46] With the tilde? [00:46] no [00:47] there is no such file [00:48] it should be without the tilde [00:48] ;) [00:49] but where do i edit that [00:49] so that it doesnt come with the tilde [00:49] Bruno1: You can try just editing the patch, I guess [00:50] \sh_away: Welcome to UUS :) [00:51] Laney: ok i edited the patch [00:51] how do i update tha package [00:51] Laney: i just make a new one? [00:51] Bruno1: Yes, try debuild. [00:53] Laney: again, debian/rules clean failed [00:53] Laney: this time it failed retrieving a patch already made [00:54] Bruno1: What's the message? [00:54] Heya gang [00:54] hey [00:54] hi [00:54] this is just the last part [00:54] http://pastebin.ca/952280 [00:57] hi bddebian [00:57] Heya sistpoty [00:57] Bruno1: try "dpatch apply-all" [00:58] did that and it went ok [00:58] then debuild and i got the same message [00:59] Bruno1: The error when unapplying? What about if you do dpatch apply-all then dpatch deapply-all? [01:00] Laney: patch 06 fails [01:00] Even though it applies correctly. I'm confused now [01:00] there's probably something wrong with patch 06 [01:01] Laney: im going to try unpacking the source again, coping my patch and appling it again and the debuild [01:02] Bruno1: OK good luck. I've got to go to bed anyway, Easter celebrations tomorrow [01:02] nn all [01:02] The recommended way to include a patch in the debian/ dir is to use quilt, right? [01:02] Laney: ok thanks, bye [01:03] The quilt howto makes it seem fairly easy to use. [01:05] slicer: there is no real recommended way, quilt, dpatch, simple-patch-sys are option to consider though (likewise, I prefer not to have a patch system and use a vcs instead) [01:06] I just saw some wiki page a while back refering to "no source packages" or something like that which strongly recommended quilt. [01:07] * slicer jumps in with feet first. [01:07] well, quilt is recommended by quite some people (haven't used it yet though, and can't say about advantages/disadvantes hence)... iirc dpatch/simple-patchsys is however used more often (but that may change) [01:10] * bddebian likes dpatch [01:13] 130619892becekia4815162342 [01:16] I have a debdiff for a bug report which also fixes a few other bugs not reported on launchpad. Do I upload the debdiff to the launchpad bug report and subscribe uus to that or do I open a new bug? [01:16] slicer, Up to you. [01:16] quilt worked like a charm, btw. Though dpatch looks more powerfull. [01:16] slicer, But make sure to mention all the bugs you close in your changelog [01:16] slicer: If you plan to reuse the bug, be sure to update the description to make it clear what you are accomplishing. [01:16] cody-somerville: Have done :) [01:16] :) [01:18] missing-build-dependency quilt .. bah! [01:19] it didnt work. again. [01:19] could someone help me out with bug #164181 [01:19] Launchpad bug 164181 in cryptsetup "Manual page typos" [Low,In progress] https://launchpad.net/bugs/164181 [01:28] persia: Are you familiar with a Com_Error() function/ [01:28] s////?/ [01:38] bddebian: Never heard of it. Are you encountering an error in python, or in quake? === santiago-pgsql is now known as santiago-ve [01:39] I'm messing with quake2 clients. r1q2 works but no sound and input problems. aprq2 gets undefined symbol Com_Error :-( [01:39] http://csourcesearch.net/package/aaquake2/0.1/quake2-3.21/qcommon/common.c/function/Com_Error/178,1 looks to be the place, although I'm not sure how that gets mangled into those clients. [01:40] For no sound and input, is it r1q2 using bare-metal, or SDL? [01:41] bare-metal? [01:41] Err. s/bare-metal/something else/ [01:41] gl [01:41] For sound and input? Hmm... [01:41] Hmm there is qcommon/common.c in the source that defines Com_Error. Why the hell is it *UND* in the shared object :-( [01:42] Maybe a linking error? [01:42] Alternately, you might have a collision in types. Is the call in the same format as the definition? [01:47] Afaict, yes [01:48] Is there a .h file that goes with qcommon/common.c, and is that included in the .c file that uses it? [01:48] s/it\?/Com_Error()/ [02:14] * mneptok tunnels around inside jono [02:14] hehe [02:14] heya mneptok === Czessi_ is now known as Czessi [02:15] hey big fella [02:15] jono: travelling, or up late? [02:15] mneptok: up late :) [02:16] jono: i'm flying solo tonight, if you want to spend some time in one of our "special channels" *winknudge* [02:16] hehe [02:17] * mneptok 's social skills strike again [02:18] Damn it's such a simple build system, wtf [02:26] bddebian: now you sound like all my ex-girlfriends :/ [02:28] heh [03:08] Note to self: if you're going to try to use an LVM snapshot to test xorg git, it's vitally important to change fstab *on the snapshot, not the original fs*. [03:15] RAOF: Oh dear, you didn't? I always remember to do that now, after I made that mistake and destroyed things some years ago. [03:23] Fujitsu: Yeah. It seems my base fs now has xserver 1.5.99.1. So it's not _destroyed_ as such, but it's not quite the clean testing environment I was aiming for. [03:26] Well, nouveau can get a bit more testing on a git xserver until I blow this install away. [03:31] How's nouveau going these days? [03:32] Extremely well, as long as you don't have a geforce 8xxx, don't want 3d, and don't need to suspend. [03:32] How's 3D support going? [03:33] OpenArena runs well on my lappy. Other things, to a greater or lesser extent. [03:33] Compiz doesn't (otherwise I'd just fire it up on nouveau, and say a welcome goodbye to the blob) [03:34] Ah, so it's not entirely absent. Very good. [03:35] Yeah, not entirely absent. nouveau is also pretty much the best 2d driver for any hardware kicking around, too (it outperforms/outfeatures the blob on my hardware). [03:35] Very nice indeed. [03:36] Yeah. Judging from the git commits that sail into my PPA changelogs, there's a _lot_ of nv5x (geforce 8xxx) work happening now. [03:37] wohoo... maybe I can get rid of the blob then soon :) [03:37] It's my hope that libdrm sees a release, and we can start shipping nouveau as the default nvidia driver in Intrepid. [03:43] Maybe by Intrepid+1 we can ship a free nvidia driver that does 3d :) [03:44] That'd be very nice. [03:44] Is there any reason to prefer nv over nouveau? [03:45] It supports nv5x better at the moment. [03:45] Oh, and you might be able to suspend with nv, I don't know. [03:46] Apart from that, it's slower, has worse visual quality, and fewer features than nouveau :) [03:46] How exactly can 2D quality differ between drivers? [03:47] If, for example, you have a laptop, then it almost certainly has a 18bpp LCD panel. Which looks _crap_ under nv. [03:47] Nouveau dithers properly, os it doesn't have horrible banding. [03:48] Also, nouveau's got a bi-cubic Xv adapter, for better-quality video. [03:48] wouldnt most lcd laptops internally dither by now? [03:48] Not mine. [03:48] And my laptop is only a year old. [03:48] ah [03:49] some drivers have faster 2d too i noticed [03:49] i mean vesa is 2d, but nv is faster [03:52] is nouveau at all easy to use in any form now? it would be neat to give 2d a test run [03:58] persia: just reading your mail regarding the charter... interesting enough, the charter was never approved though, so actually MC doesn't have any powers :P [03:59] sistpoty: Ah. I somehow missed that. Makes it even harder then... [03:59] persia: yes, that's my fault for not following up hard enough in the beginning phase... imho we should really get it approved ASAP ;)( [03:59] * persia will add approval of the MC charter to the MOTU Meeting agenda once there is confirmation that the meeting can be attended. [04:00] sistpoty: Will you be able to make the next meeting? I'm still unsure. [04:00] persia: when's the next meeting? at 4.00 UTC or 20.00 UTC (was confused by the mail to -motu) [04:00] I believe it's 4:00 [04:01] https://wiki.ubuntu.com/MOTU agrees with me [04:01] oh, unlikely that I'll show up... I'll try, but I know my sleep behaviour to well :( [04:02] That's about sunrise for you, or will it still be dark? [04:03] still dark, and I usually don't get up before 8 UTC [04:03] (which I really want to change though *g*) [04:04] Still dark is definitely too early. [04:04] sistpoty: Would you please ack Bug 204959 [04:04] Launchpad bug 204959 in xapian-bindings "Please sync xapian-bindings 1.0.5-1 (universe) from Debian unstable (main)." [Wishlist,New] https://launchpad.net/bugs/204959 [04:04] It builds which is better we have now. [04:05] Isn't that version also required to match the current libxapian? [04:06] Yes [04:06] But it's a new upstream, so I want an ack. [04:09] ScottK2: there are two rdepends... did the API change? [04:09] (in an incompatible way) [04:10] * ScottK2 looks. [04:14] sistpoty: From reading Changelog and NEWS, no. Currently we have xapien-bindings and xapiend-core on different versions. I think having them the same and having the bindings buildable is way better than whatever risk there is of bumping. [04:16] ScottK2: hm.. I don't see a xapiend-core? [04:17] It would help if I could spell [04:17] https://launchpad.net/ubuntu/+source/xapian-core [04:17] heh [04:18] yes, that makes sense to me, ACK'd [04:19] Thanks [04:19] thanks to *you* who does the work ;) [04:45] * ScottK2 will mention again Bug #204895 if someone is looking for something worthwhile to work on. [04:45] Launchpad bug 204895 in python-scipy "Packages failed archive rebuild test possibly due to python-central transition" [Undecided,Fix released] https://launchpad.net/bugs/204895 [04:49] Lots more package not fixed in there. [04:56] hi... [04:56] I want to become an ubuntu developer, can anyone help please? [04:57] rpg: Sure. What do you want to do? [04:57] well how do I get in ubuntu development [04:57] You show up here and get to work. [04:57] i know C/C++/Java [04:58] rpg: The easiest way is to find a bug, and fix it. I recommend reading https://wiki.ubuntu.com/MOTU/Contributing as a guide to some of the initial processes. [05:04] ok... brb... checking out the link [05:04] will ubuntu development help me improve my portfolio, when going into computer research [05:04] ? [05:12] rpg: Quite possibly. Having a portfolio of open code makes review of an application easier, and further, using Ubuntu development in concert with your research goals might provide a strong basis for continued work (or grants, etc.) [05:14] awesome... :) [06:02] RAOF: did you win? [06:34] ScottK: man, you're really giving me lots of LP work to do tonight :-) [06:34] * Hobbsee looks for ways of giving LaserJock more work [06:35] I'm trying to write my monthly report here [06:35] gimme a break ;-) [06:35] `LP devs again deferred all of our bugs 6 releases.' [06:38] Fujitsu: nah, not nearly that bad [06:39] about 50% of our bugs have been fixed [06:39] Yay! [06:39] 4 interesting bugs this upcoming rollout [06:52] LaserJock: How do you determine "our" bugs? Do you need any special notification when a bug is reported? [06:52] LaserJock: I'm not seeing how the bugtracker deletion one is particularly interesting to us. [06:53] Fujitsu: because having a good bug tracker system is important [06:53] although hopefully they'll let more than admins do it [06:54] persia: well, I don't have a particular way of knowing so it's nice to get a ping if you think there's an important bug for MOTU [06:54] Fujitsu: no, only soyuz. [06:54] Looking at the draft report, should I ping you, or just add a MOTU tag? [06:55] ping me preferably [06:55] * persia reviews the subscribed bug list vs. the report list. [06:56] the usefulness of the tag is inversely proportional to the number of bugs tagged [06:56] and the LP guys requested that I keep it fairly low [06:56] bug #160439 looks interesting [06:56] Launchpad bug 160439 in launchpad-buildd "Some builds fail when they should depwait" [Medium,Triaged] https://launchpad.net/bugs/160439 [06:57] Is that one of mine? [06:57] I forget. I've filed too many. [06:57] bug #4780 as well [06:57] Launchpad bug 4780 in malone "Rows in bug listings should indicate if a patch exists" [Wishlist,Confirmed] https://launchpad.net/bugs/4780 [06:57] And oh my god LP is so slowwwww. [06:57] persia: can you email me? [06:57] I have to go to bed and it appears my / is read-only [06:57] LaserJock: If you like, but Ubuntu won't be as helpful that way :) [07:02] Fujitsu: you should file less bugs. [07:03] Hobbsee: But then they'll get fixed even slower. === G0SUB_ is now known as G0SUB [07:57] G'morning. [08:07] How can I search for a particular 'Provides' in package cache? [08:08] Fujitsu: there is that. [08:08] apt-cache showpkg [08:09] slangasek: thanks. What is expected output if there is a package? [08:12] slangasek: Actually I am trying to debug mplayer build problem on powerpc. mplayer latest version is built only on i386 and amd64. [08:23] slytherin: Wrong. mplayer FTBFS everywhere. [08:23] In the archive rebuild, and the version that isn't uploaded yet. [08:23] (it's not uploaded because it FTBFS everywhere) [08:24] Fujitsu: oh, then it is due to that libsvga1-dev build-dep [08:24] If you could fix that, I'd be most pleased. [08:24] I have a few security fixes pending in bzr. [08:25] Fujitsu: I am currently updating my powerpc alternet CD image. So it will takle at least an hour before I can do any 'get-source and build'. [08:26] Fujitsu: I wonder why the last version of mplayer built on i386 and amd64. At least launchpad says so. [08:26] slytherin: Some dep changed, I guess. [08:27] Hm, maybe it FTBFS on i386 but not amd64. I'm sure it FTBFS on amd64 when I last tried it, though. [08:27] http://builder.ubuntuwire.com:9998/package/mplayer [08:31] How do I remove untracked files from a svn co? [08:38] elmargol: untracked? [08:39] files .swp files etc [08:39] svn rm? Just rm? [08:39] for this I have to find them first === olegb_ is now known as olegb [09:07] how can I define different build dependencies for different architectures? [09:07] * pwnguin has a question about deb tarballs versus the .diff [09:07] if you upgrade a package to a new svn revision from upstream, does that go in as a new tarball or a large .diff? [09:08] pwnguin: new tarball [09:09] so what should i do if a developer pushed it as a large diff and kept the debian .tar.gz [09:11] pwnguin: I can not answer that. I am not a developer myself. :-) [09:24] Doing it as a large diff isn't wrong. [09:24] The tarball should be an upstream source, which is often a release, but may be a VCS snapshot. [09:25] diff.gz is everything added (which may be VCS updates from the last release) [09:25] lemme tell you, its really hard to pick out what ubuntu changed that way [09:26] pwnguin: It is the case that there is neither a patch system in use nor Vcs-* hints in debian/control? [09:27] pwnguin: Why does it make it harder to work out? [09:27] hmm. [09:27] im blind [09:27] skipped straight over that patches dir [09:27] There you go... [09:27] that was the first thing i looked for too =/ [09:27] hmm [09:27] thats a bit scary [09:28] oh, that was my package [09:28] hmm [09:29] no, no patches dir and no Vcs in control [09:30] slytherin: I can't find athe documentation for arch-specific build-deps right now, but apt-cache showsrc gcc should show you the syntax. [09:30] i know the vcs url for upstream [09:30] is that what that's for? [09:31] pwnguin: I'd consider no patches dir and no Vcs-* in control with a huge patch without documentation to be a minor bug. Not worth reporting in LP against a Debian-derived package, but worth reporting in LP against an Ubuntu-local package or in the BTS against a Debian package. [09:31] The debian/control Vcs-* fields should point to the packaging. [09:32] ah, well, technically this is for main, not universe, but i figured the general idea was the same [09:32] It should be the same. Why does main/universe matter? [09:33] not sure. keybuk's a smart guy [09:33] If that's the maintainer, there is surely a VCS for the packaging. [09:33] thinkfinger [09:42] pwnguin, there is MIR open for that right now [09:43] i'd make sure you talk to Keybuk first before you touch it [09:43] persia: thanks [09:43] superm1: i have no touching powers [09:43] pwnguin, oh okay :) [09:44] im just curious what the hell he patched [09:44] as i have a package in my ppa [09:44] and id like to make sure it doesn't suck [09:44] in ppa or main === DktrKran12 is now known as DktrKranz2 [10:36] Hi all [10:36] Does anyone know why the command update-mozilla-firefox-chrome is not available in beta 4 of firefox 3? [10:36] I am in the beta of Hardy now [10:37] I am trying to do this https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/204719 [10:37] Launchpad bug 204719 in firefox "Firefox 3 language packs missing" [Undecided,In progress] [10:37] [10:37] But I think I need is to command the firefox recognize translations [10:38] I just lack that ... :-/ [10:43] Festor: You likely want to ask in #ubuntu+1 or in #ubuntu-bugs [10:43] thanks persia :D [10:43] or #ubuntu-mozillateam [10:44] There possibly as well. [10:44] I am already there Hobbsee [10:49] f/part === asac_ is now known as asac [11:33] Hobbsee: Did I win what? I won a round of Cambridge standard five card Mao, certainly. [11:33] RAOF: nice! [11:34] RAOF: the git xserver stuff. [11:34] The commit which broke stuff is one of a series of 5, none of which build. [11:35] And my main Hardy install now has a git head xserver, which doesn't load the nvidia binary driver. So I can't reproduce it here on vanilla git. [11:35] try harder. [11:36] Fujitsu tried harder (git + Intel), but didn't manage 3d, so alse didn't get compiz, so didn't manage to reproduce. I updated the LP bug, linked it to the upstream Xorg bug, and added some info to that. [11:38] RAOF: I got Compiz, but at a frame every few seconds. glxinfo said no DRI. [11:38] Fujitsu: Oh, wow. I didn't think compiz ran without DRI. [11:39] RAOF: Neither did I... I was very confused. [11:39] I think I might update my nouveau libdrm packages to use module-assistant, and make it easy(er) to build the git DRM stuff for all the cards. [11:40] Fujitsu: It's possible you needed to play the Gallium fandango or something. I think xorg git is in quite a lot of flux right now. === pgquiles__ is now known as pgquiles [12:22] DktrKranz: I'm sorry, I attached the wrong debdiff for bug #203978. :( I have attached a new one that should really work now. [12:22] Launchpad bug 203978 in cedar-backup2 "2.14.0-2 FTBFS in hardy" [Medium,Confirmed] https://launchpad.net/bugs/203978 [12:38] hefe_bia, thanks :) [12:49] Hobbsee, have you time to give-back ocamlcreal on amd64? [12:50] DktrKranz: done, and i tend not to need the arch, just the package (and the release, if not hardy) [12:50] DktrKranz: the script checks all arches, and rebuilds the dead ones [12:50] Hobbsee, ah, nice to know. thanks :) [12:50] yw === gouki_ is now known as gouki [13:23] Hey [13:24] Hi RainCT [13:33] can someone try to op in here now? [13:34] jpatrick: not you. you have access already. [13:34] Hobbsee: hehe [13:34] drat. [13:34] Hmh [13:34] PriceChild: did you do the reset too? [13:35] Hobbsee: I haven't touched it... I just got you set as contact. [13:35] PriceChild: oh. can you do the reset too please? [13:35] (To anyone not in the loop, MC told irc council we are responsible) [13:36] Hobbsee: /cs #ubuntu-motu identify [13:36] /cs level #ubuntu-motu reset [13:36] Hobbsee: You're contact, identify and do it? *has no chanserv powahs* [13:36] [00:35] [Notice] -ChanServ- Contact access is required for [LEVEL] [13:36] oh, right, i need to register to chanserv as well as nickserv. [13:36] Fujitsu: Have you seen the patch proposed in bug 202759? [13:36] Launchpad bug 202759 in sarg "Please sync sarg 2.2.5-1 (universe) from Debian unstable (main)" [High,Confirmed] https://launchpad.net/bugs/202759 [13:37] StevenK, RainCT now try? [13:38] ChanServ(ChanServ@services.)- An access level of [10] is required for [OP] on #ubuntu-motu [13:38] good. [13:38] !yay | Hobbsee [13:38] Hobbsee: Glad you made it! :-) [13:38] PriceChild: Huh? I thought you told me that the people who were ops in each channel were responsible for that channel, and beholden to IRC Council. My apologies for any confusion. [13:38] jpatrick: we should be good now [13:38] persia: ie, it's my domain to hijack the channel, and change it :) [13:38] RainCT: thanks [13:39] np :) [13:39] Hobbsee: Sure, as long as it's not MC telling someone they are specifically responsible. I don't think MC has authority to do that. [13:39] persia: yes, i've become aware hwo little authority the MC actually has, so it seems that the protocol is saying "i'm going to take responsibility for this" and then doing it. [13:40] Hobbsee: Excellent. Just wanted to make sure someone was doing that, rather than it being an MC directive, as implied by PriceChild's earlier comment. [13:40] persia: freenode staff are very picky about it all [13:42] Fujitsu: I get this erro when I try to rebuild current version of mplayer, the one that is present already in hardy - http://pastebin.com/m5fc57a5a Any idea? [13:51] Heya gang [13:51] persia: Can you help with above mplayer build problem? [13:52] slytherin: No. Youve generated a compiler warning with which I am entirely unfamiliar. Sorry. [13:53] persia: Ok. Actually Fujitsu said that current version failed in the rebuild activity on all arch. So I was just trying to see what the problem is. I have found some references on google but I am not too familiar with compiler flags [13:54] I'm not that familiar with low-level routines, but it appears to me that the code is trying to allocate hardware resources that are not declared as available. Might be a missing include, or just odd code. It may be worth comparing with upstream VCS to see if there was a change recently, although it may be due to the updated toolchain. [13:58] persia: I am not able to find the affected code in upstream svn. I am confused. :-( [13:58] Upstream SVN doesn't have h264.c or cabac.h? [14:00] persia: Let me look carefully [14:09] persia: I was looking at wrong place. There is a bzr branch in launchpad. [14:09] slytherin: There you go :) [14:22] persia: You bored? :) [14:22] bddebian: I wish :) === tb1 is now known as tbf [14:28] So, it must be getting close to release time: my computer is crashing again :) [14:28] Heya geser [14:28] persia: :) [14:28] bddebian: What is it that you sought I might do if I were bored? [14:29] Hi bddebian [14:31] persia: This aprq2 thing. You know what an idiot I am. :-( [14:33] bddebian: Ah. The include is there, in the .c file of the caller, and the format is the same, and it can't find it? Does the linker look in the directory of the compiled quake_common.c to link against quake_common.o? Do you have a build log? [14:35] is it normal for GDM to use 130MB memory? [14:36] (ie, the memory usage incrementing in 130MB after doing "sudo /etc/init.d/gdm start") [14:37] persia: Yeah, it's very simplistic [14:42] persia: There's a make1.log here: http://www.bddebian.com/junk/aprq2/ [14:42] Along with the source .zip file [14:43] bddebian: Wait, so it builds fine, and then it won't run? [14:43]