**** BEGIN LOGGING AT Fri Jan 22 02:59:57 2010 Jan 22 08:10:46 moin moin Jan 22 08:38:53 yawn yawn Jan 22 08:39:57 asac: ogra morning guys Jan 22 08:40:25 cooloney, hey, thanks for poking the NIC issue :) Jan 22 08:40:52 dmart: there? Jan 22 08:40:57 hi cooloney Jan 22 08:42:15 ogra: no problem, i got no clue about that, so asked for help. heh Jan 22 08:43:35 gah, seems i dont het uboot off my back today ... Jan 22 08:43:39 *get Jan 22 09:34:13 asac, no go for the NIC fix Jan 22 09:54:02 huh? Jan 22 09:54:13 ogra: thought you ignore that until we get input from fsl Jan 22 10:19:53 asac, FSL attached a patch to bug 507887# Jan 22 10:19:54 Launchpad bug 507887 in uboot-imx "NIC not properly initialized in uboot code" [High,Confirmed] https://launchpad.net/bugs/507887 Jan 22 10:20:41 but seems its only half the fix Jan 22 10:26:13 ogra: cool. and not ;) Jan 22 10:26:20 right Jan 22 10:26:32 there were 3 patches overall attached to three bugs Jan 22 10:26:47 sadly none for the MMC issue and all of them against 2009.08 Jan 22 10:27:06 so nothing that helps us Jan 22 10:27:25 the L2 fix looks intresting though Jan 22 10:27:28 the NIC patch looks simple enough Jan 22 10:27:34 to check if it would work on .01 Jan 22 10:27:53 where is the L2 patch attached? Jan 22 10:28:02 mail Jan 22 10:28:10 the NIC patch doesnt work Jan 22 10:28:36 as i said above (and in teh bug), we seem to miss the actual patch that implements the function Jan 22 10:29:32 heh. can you reply in bug and to mail? Jan 22 10:29:39 i did Jan 22 10:29:47 well, not by mail though Jan 22 10:30:18 kk Jan 22 10:30:22 see commants 3,4 and 5 on bug 507887 Jan 22 10:30:23 Launchpad bug 507887 in uboot-imx "NIC not properly initialized in uboot code" [High,Confirmed] https://launchpad.net/bugs/507887 Jan 22 13:48:49 fsck from util-linux-ng 2.16 Jan 22 13:48:49 e2fsck 1.41.9 (22-Aug-2009) Jan 22 13:48:49 /dev/sda6: clean, 146136/2321984 files, 948823/9277521 blocks (check deferred; on battery) Jan 22 13:49:00 * ogra pokes his babbage with a pointy stick ... Jan 22 13:49:09 you got no battery you darn thing !!! Jan 22 13:51:37 ogra@babbage2:~$ sudo cat /proc/apm Jan 22 13:51:37 1.13 1.2 0x02 0xff 0xff 0xff -1% -1 ? Jan 22 13:51:39 mumble Jan 22 14:24:45 bug 456659 Jan 22 14:24:47 Launchpad bug 456659 in linux-fsl-imx51 "suspend/resume failure on imx51" [High,In progress] https://launchpad.net/bugs/456659 Jan 22 14:25:43 bug 488267 Jan 22 14:25:45 Launchpad bug 488267 in ffmpeg "ffmpeg should be built with -marm for lucid on armel" [Low,Fix released] https://launchpad.net/bugs/488267 Jan 22 15:16:37 cooloney, do you know if the FSL kernel patches change anything wrt /proc/apm output ? Jan 22 15:28:23 https://wiki.ubuntu.com/MobileTeam/ReleaseStatus/Lucid Jan 22 15:28:36 ogra: plars: GrueMaster: persia: dyfet: ^^ Jan 22 15:29:50 asac, i think the fact that we have an outdated uboot is also RC (if RC means release critical :) ) Jan 22 15:30:33 i.e. i doubt we'll ever get a fix for the MMC issues for 2009.01 ... so i think they should still be on release team radar Jan 22 15:30:54 (which in turn enforces us to update to .08) Jan 22 15:30:59 ogra: well. thats covered Jan 22 15:31:05 or do we have a bug for that? Jan 22 15:31:11 imo its well covered by the other two problems Jan 22 15:31:22 which reminds me that i should RC the other bug if its not yet Jan 22 15:31:27 we have a bug for the MMC issue Jan 22 15:31:38 not for "hey we chose an old version" :) Jan 22 15:31:43 ogra: can you target for lucid + milestone alpha-3 Jan 22 15:31:46 and gimme bug id ;) Jan 22 15:31:52 * ogra digs Jan 22 15:32:18 Bug 506761 Jan 22 15:32:20 Launchpad bug 506761 in uboot-imx "lucid uboot hangs on fatload uImage on fsl TO2 TO2.5 and TO3" [Medium,Confirmed] https://launchpad.net/bugs/506761 Jan 22 15:32:30 thx Jan 22 15:33:05 ogra: why is that wontfix for lucid? Jan 22 15:33:11 that demotes that to non-RC ;) Jan 22 15:33:23 uh Jan 22 15:33:23 * asac changes that Jan 22 15:33:42 also its medium ;) Jan 22 15:33:48 thats overly polite -> critical now Jan 22 15:34:03 you did set the Wontfix :P Jan 22 15:34:13 and the Medium :) Jan 22 15:34:20 really? Jan 22 15:34:20 ouch Jan 22 15:34:37 oh... maybe when i thought that the paritioning was good enough Jan 22 15:34:43 right Jan 22 15:34:54 right after the commant about partitioning Jan 22 15:35:19 ogra: the version revision thing is not RC? Jan 22 15:35:21 because it "doesnt block release" Jan 22 15:35:31 not for now imho Jan 22 15:35:47 dyfet: did busybox -marm work? Jan 22 15:35:51 as long as FSL stands to their promises and we get a fixed release Jan 22 15:35:54 yeah Jan 22 15:35:55 ok Jan 22 15:36:01 asac: yes Jan 22 15:36:01 asac, i'm about to upload busybox Jan 22 15:36:12 asac: already posted for sponsor Jan 22 15:36:15 Bug 511197 Jan 22 15:36:17 Launchpad bug 511197 in busybox "fails to build on arm lucid (thumb2)" [Undecided,Confirmed] https://launchpad.net/bugs/511197 Jan 22 15:36:21 dyfet: where? Jan 22 15:36:32 got that in my queue ... Jan 22 15:36:33 ah in the bug Jan 22 15:36:37 just ping me here ;) Jan 22 15:36:38 just didnt get to it yet Jan 22 15:36:51 i read bugmail at most twice a decade :-P Jan 22 15:36:55 lol Jan 22 15:37:04 asac, dont worry, i need some sponsoring points anyway ;) Jan 22 15:38:42 asac, did you talk with doko about Bug 417009 (shipping the jaunty libgcc_uno.so Jan 22 15:38:44 ) Jan 22 15:38:44 Launchpad bug 417009 in openoffice.org "all openoffice apps die in 'com::sun::star::ucb::InteractiveAugmentedIOException' on armel in karmic" [High,Confirmed] https://launchpad.net/bugs/417009 Jan 22 15:39:31 its still "confirmed" so i assume we still ship the hack Jan 22 15:40:14 asac, if you want the hack gone that should be on our list Jan 22 15:43:28 ogra: talked to doko about this today Jan 22 15:43:36 ah, good Jan 22 15:43:45 does he see a chance to get that fixed ? Jan 22 15:43:45 he said its not RC if we ensure that we build it again from fresh sources Jan 22 15:43:52 aka the lib Jan 22 15:44:06 well, we still ship old crap :) Jan 22 15:44:13 not RC because the fix is so unlikely, that it doesnt make sense to stirr up release team Jan 22 15:44:20 ok Jan 22 15:44:57 plars: so after talking to doko about python dove killage, he mentioned that python wasnt even build in lucid yet, so maybe the python2.6 package that is building right now, will help Jan 22 15:50:00 fsck from util-linux-ng 2.16 Jan 22 15:50:00 e2fsck 1.41.9 (22-Aug-2009) Jan 22 15:50:00 /dev/sda6 has been mounted 40 times without being checked, check forced. Jan 22 15:50:00 Pass 1: Checking inodes, blocks, and sizes Jan 22 15:50:03 GEEZ !!!! Jan 22 15:50:14 i only added a printf ! Jan 22 15:50:27 why the heck does it not think its on battery anymore °! Jan 22 15:51:25 * ogra reboots again Jan 22 15:52:00 ogra: wrong negation? feels ok if it doesnt think its on battery ;) Jan 22 15:52:05 unless you have a battery :-P Jan 22 15:52:13 oh Jan 22 15:52:17 * asac should read more backlog Jan 22 15:52:19 good Jan 22 15:52:20 well, you saw the code before Jan 22 15:52:27 ogra: do you get a warning during build? Jan 22 15:52:30 like missing prototype? Jan 22 15:52:37 i just added a printf to print out the value of the ac Jan 22 15:52:42 nope Jan 22 15:52:52 so stdio is probably included ;)= Jan 22 15:52:53 ? Jan 22 15:52:54 ok Jan 22 15:53:16 lets see, probably it was actually an enforced check because 40 mounts were done Jan 22 15:53:20 does it build with all warnings? Jan 22 15:53:24 maybe Jan 22 15:53:28 mountall: Could not connect to Plymouth Jan 22 15:53:28 fsck from util-linux-ng 2.16 Jan 22 15:53:28 e2fsck 1.41.9 (22-Aug-2009) Jan 22 15:53:28 /dev/sda6: clean, 146112/2321984 files, 949695/9277521 blocks Jan 22 15:53:28 init: plymouth-log main process (3168) terminated with status 111 Jan 22 15:53:43 hmm, it really doesnt see the battery anymore Jan 22 15:53:54 now thats weird Jan 22 15:55:47 if (fscanf(f, "%s %s %s %x", tmp, tmp, tmp, &acflag) != 4) Jan 22 15:55:49 acflag = 1; Jan 22 15:55:57 is the original code Jan 22 15:56:05 if (fscanf(f, "%s %s %s %x", tmp, tmp, tmp, &acflag) != 4) Jan 22 15:56:05 printf("acflag is: %x", acflag); Jan 22 15:56:05 acflag = 1; Jan 22 15:56:13 is what i made out of it Jan 22 15:56:53 it doesnt exec the printf ... nor does it set acflag Jan 22 16:23:47 asac: cool, will give it a try Jan 22 16:48:06 uff Jan 22 16:48:11 so next week i want a better meeting Jan 22 16:48:12 ;) Jan 22 16:48:15 more success to report Jan 22 16:48:19 please make that happen :) Jan 22 16:48:23 heh Jan 22 16:49:32 at least you didnt have to report many disasters :) Jan 22 16:56:10 ogra: when did pitti send that announce? Jan 22 16:56:14 was that in a thread? Jan 22 16:56:17 i cant even find it ;) Jan 22 16:56:44 you mean the moving of people from rookery to a new machine ? Jan 22 16:56:59 no. the moving of the work itesm from macaroni to people ;) Jan 22 16:57:03 http://people.canonical.com/~pitti/workitems/canonical-mobile.html Jan 22 16:57:04 vs Jan 22 16:57:10 http://macaroni.canonical.com/~pitti/workitems/canonical-mobile.html Jan 22 16:57:29 hmm Jan 22 16:58:27 asac, ubuntu-platform@ Jan 22 16:58:50 ogra: right. but was that standalone mail or a reply to an existing thread? Jan 22 16:58:54 20.01.2010 14:25:05 Jan 22 16:58:58 standalone Jan 22 16:58:58 i have all that in my main inbox Jan 22 16:59:07 with a big ANNOUNCE tag Jan 22 16:59:19 ok i dont have it ;) Jan 22 16:59:21 look for ANNOUNCE in the subject Jan 22 16:59:33 guess it was killed in a my eager zero inbox effort ;) Jan 22 16:59:51 heh Jan 22 17:01:05 hmm, so powertop seems to miss some kernel options on imx51 Jan 22 17:58:13 asac: what about snapdragon? :) Jan 22 18:01:34 fta: i will demote the ffmpeg depends for this upload ... so its not rejected because depends arent fulfillable Jan 22 18:01:39 we can put that back when its in Jan 22 18:02:24 asac, /me sad. why not use !armel instead? Jan 22 18:02:43 fta: we have it on armel. just not in the archive Jan 22 18:02:51 its not because of armel ... just because of archive Jan 22 18:03:06 i dont want to block the chromium upload on first getting the other stuff up Jan 22 18:03:10 why is it rejected in the 1st place? Jan 22 18:03:18 if its not fulfillable Jan 22 18:03:21 then it cant go in Jan 22 18:03:27 all depends need to be there Jan 22 18:03:33 so its recommends now. Jan 22 18:03:39 you can drive the ffmpeg als in Jan 22 18:03:43 why not submit it first? Jan 22 18:03:44 its just licensing for that Jan 22 18:03:50 because i dont want to wait any longer Jan 22 18:03:57 *sigh* ok Jan 22 18:03:58 you could have uploaded it ;) Jan 22 18:04:03 would be great if you could do. Jan 22 18:19:14 asac: chromium now fails for me :P Jan 22 18:19:40 export LD_LIBRARY_PATH=/var/tmp/portage/www-client/chromium-9999/work/chromium-9999/out/Release/lib.host:/var/tmp/portage/www-client/chromium-9999/work/chromium-9999/out/Release/lib.target:$LD_LIBRARY_PATH; cd v8/tools/gyp; mkdir -p /var/tmp/portage/www-client/chromium-9999/work/chromium-9999/out/Release/obj.target/geni; "/var/tmp/portage/www-client/chromium-9999/work/chromium-9999/out/Release/mksnapshot" "/var/tmp/portage/www-client/chrom Jan 22 18:19:40 ium-9999/work/chromium-9999/out/Release/obj.target/geni/snapshot.cc" Jan 22 18:19:40 pure virtual method called Jan 22 18:19:40 terminate called without an active exception Jan 22 18:22:20 what was that error about? Jan 22 18:23:18 and i'm using gcc-4.3 Jan 22 18:35:03 that was about -fno-strict-alias breakage for ggc 4.3 Jan 22 18:35:22 if you are really sure everything uses gcc 4.3 on your system now then i dont know Jan 22 18:35:25 but i would expect it doesnt Jan 22 18:35:57 you can try -fno-tree-sink Jan 22 18:36:03 grab the patch from our packaging .head Jan 22 18:36:14 no_tree_sink_v8.patch Jan 22 18:36:15 * asac out Jan 22 18:38:20 well, but the -fno-tree-sink is used only if gcc_version=44 Jan 22 18:38:49 and it worked before, i'm wondering if you now need gcc-4.4 :P Jan 22 19:32:04 new python didn't help btw Jan 22 20:47:27 damn Jan 22 20:47:32 plars: there? Jan 22 20:48:06 plars: so you basically can go to console, and make the board hang by running import pybootchargui right? Jan 22 20:48:08 asac: yes Jan 22 20:48:41 asac: right, that one and uno both seem to do it so far. Haven't found others yet Jan 22 20:48:47 plars: so idea is to run python -v Jan 22 20:49:01 that should spit out the modules that get implicitly imported Jan 22 20:49:25 if you | tee that to a file you might be able to try each of those until you find which import causes this Jan 22 20:49:38 ah, neat, didn't know about that Jan 22 20:49:41 right Jan 22 20:50:15 ok, the last thing I see it trying to import was cStringIO Jan 22 20:50:15 need to reboot, sec Jan 22 20:50:15 yeah Jan 22 20:50:20 so check if that alone causes it ;) Jan 22 20:50:24 then we can check what it does etc. Jan 22 20:50:47 also ... did you find any module you could import without a hang? Jan 22 20:51:36 asac: yes, plenty. These had been the only two so far that I found that caused it to hang Jan 22 20:52:45 cat ./Modules/cStringIO.c | pastebinit Jan 22 20:52:45 http://pastebin.com/f51e45d28 Jan 22 20:52:54 cStringIO imports ok, must be something after that Jan 22 20:53:52 plars: so we dont see the module that fails to import? Jan 22 20:54:05 e.g. it hangs before the dump? Jan 22 20:54:14 asac: correct Jan 22 20:54:58 plars: can you paste the current import list? Jan 22 20:56:35 asac: I don't think it's an import from there... Jan 22 20:56:59 asac: importing socket gives me the same impot list with python -v, and that's the last thing that this module imports Jan 22 20:57:29 from where? Jan 22 20:58:25 let me check something Jan 22 20:58:38 asac: I'm still looking at uno Jan 22 20:59:17 ah Jan 22 20:59:57 http://paste.ubuntu.com/360871/ Jan 22 21:00:01 thats import uno on x86 Jan 22 21:00:20 >>> import pybootchartgui Jan 22 21:00:21 import pybootchartgui # directory /usr/lib/pymodules/python2.6/pybootchartgui Jan 22 21:00:24 # /usr/lib/pymodules/python2.6/pybootchartgui/__init__.pyc matches /usr/lib/pymodules/python2.6/pybootchartgui/__init__.py Jan 22 21:00:27 import pybootchartgui # precompiled from /usr/lib/pymodules/python2.6/pybootchartgui/__init__.pyc Jan 22 21:00:30 thats the thing i get for bootchart Jan 22 21:00:34 so its not that easy :( Jan 22 21:08:56 plars: do you know about other modules that cause this hang? Jan 22 21:09:11 asac: those are the only two I've found so far Jan 22 21:10:48 # pybootchartgui/__init__.pyc has bad magic Jan 22 21:10:51 what does that mean? Jan 22 21:13:12 plars: maybe removing the precompiled bits helps? sudo rm /usr/lib/pymodules/python2.6/pybootchartgui/*.pyc Jan 22 21:13:58 sorry... just trying random things Jan 22 21:18:03 >>> import pybootchartgui Jan 22 21:18:03 import pybootchartgui # directory pybootchartgui Jan 22 21:18:03 # pybootchartgui/__init__.pyc has bad magic Jan 22 21:18:03 import pybootchartgui # from pybootchartgui/__init__.py Jan 22 21:18:06 # wrote pybootchartgui/__init__.pyc Jan 22 21:18:29 ah ... now i see where its coming from. Jan 22 21:18:38 the package ships an old __init__.pyc here: Jan 22 21:18:44 /usr/share/python-support/pybootchartgui/pybootchartgui/__init__.pyc Jan 22 21:18:46 remove that ;) Jan 22 21:19:12 asac: interesting Jan 22 21:19:46 I don't have that file Jan 22 21:20:11 and I don't see any .pyc file in the dpkg -L list Jan 22 21:20:24 odd Jan 22 21:20:37 dpkg -L pybootchartgui | grep pyc$ Jan 22 21:20:38 /usr/share/python-support/pybootchartgui/pybootchartgui/__init__.pyc Jan 22 21:20:41 well. its karmic Jan 22 21:20:43 however after the earlier rm, I seem to be able to run pybootchartgui Jan 22 21:20:45 so its probably clean ;) Jan 22 21:20:51 cool ;) Jan 22 21:20:57 so maybe... but what about uno? Jan 22 21:21:07 and where did some stray .pyc come from? this was a new install Jan 22 21:21:14 plars: have you tried to reinstall pybootchargui after python upgrade? Jan 22 21:21:16 maybe give that a try Jan 22 21:21:20 no Jan 22 21:21:23 maybe it needs just fresh .pyc Jan 22 21:21:44 the other directory i asked you to clean is generated during install Jan 22 21:21:49 by python-central or something Jan 22 21:22:07 not sure if tere are triggers that recreate all .pyc if python is updated though Jan 22 21:22:24 to be sure check if reinstalling still keeps pybootchartgui working Jan 22 21:22:27 also... Jan 22 21:22:29 sudo rm /usr/lib/python2.6/dist-packages/uno.pyc Jan 22 21:22:33 import uno still hangs Jan 22 21:23:56 plars: uno is something different. thats ooo Jan 22 21:24:00 thats a different beast Jan 22 21:24:08 asac: right, but symptom is the same Jan 22 21:24:11 yes Jan 22 21:24:27 plars: so does reinstalling pybootchartgui make keep it working? Jan 22 21:24:28 ;) Jan 22 21:24:42 asac: have to wait for the reboot Jan 22 21:24:58 I hung it again trying uno Jan 22 21:25:35 ah ok Jan 22 21:26:01 * asac checks something Jan 22 21:27:56 asac: pybootchartgui seems to be working now Jan 22 21:28:59 very good Jan 22 21:30:03 plars: have you tried to remove /usr/lib/python2.6/socket.pyc as well? Jan 22 21:30:19 asac: no, but importing socket seemd ok Jan 22 21:30:53 asac: no help Jan 22 21:30:58 ok. Jan 22 21:31:13 so i somehow dont get rid of the thought that the uno issue has something to do with the Jan 22 21:31:21 uno thin we have in OOO Jan 22 21:31:32 e.g. the bug that requires us to ship the jaunty so Jan 22 21:31:39 i am not sure if that is pyuno.so though Jan 22 21:31:41 do you remember? Jan 22 21:31:49 asac: no idea, sorry Jan 22 21:31:59 the bug about this was https://bugs.edge.launchpad.net/ubuntu/+source/binutils/+bug/436617 Jan 22 21:32:02 Launchpad bug 436617 in binutils "ARM unwind table linker processing broke OO's uno2cpp" [High,Confirmed] Jan 22 21:32:12 will be interesting to boot the next livecd if it has the new python in it and see if it works Jan 22 21:32:13 let me poke chris Jan 22 21:38:49 plars: so ... pyuno.so pulls in that ugly jaunty libgcc3_uno.so Jan 22 21:38:58 through libpyuno.so Jan 22 21:39:05 somehow Jan 22 21:39:22 guess thats not build with thumb2 Jan 22 21:39:37 I see Jan 22 21:39:56 I'm afraid that all of this may be hit or miss until x0 Jan 22 21:40:09 from the sounds of things, this all likely relates back to that Jan 22 21:40:20 the gcc3_uno.so thing probably yes. Jan 22 21:44:05 plars: anyway, so with just removing pyuno we get a booting desktop now? Jan 22 21:44:13 plars: if thats the case thats all we can hope for ;) Jan 22 21:44:24 and we should consider to just do it to get working images until we get X0 to test Jan 22 21:44:49 asac: oh, pyuno was never preventing it from booting, just happened to be another pythong module I noticed that caused trouble. Previously I was able to get it booting by taking pybootchartgui out of the init Jan 22 21:45:02 asac: so no reason to remove uno Jan 22 21:45:10 plars: cool. so basically with a reinstalled bootchart it works? Jan 22 21:45:34 asac: seems to be, tomorrows image will be good to double-check with Jan 22 21:45:41 guess we have flaky but working images tomorrow with some luck then ;) Jan 22 21:46:11 plars: great. with that you can go and do more positive stuff until we get news on hardware/kernel front i guess. thanks a lot!!! Jan 22 21:46:56 asac: thanks for all your help! Jan 22 21:48:01 no thanks to you ... at least i can somehow sleep again ;) Jan 22 21:48:24 the good I get out of this is that if we have everything recompiled the Y1 boards might become more and more stable ;) Jan 22 21:53:07 asac: I didn't think you ever slept! Jan 22 21:53:32 its those things i tell you :-P Jan 22 21:54:08 actually i skip the timezone lag for sprints this way Jan 22 21:54:19 i just keep my live going in central US time ;) Jan 22 21:54:32 anti-jetlag method its called Jan 22 21:55:20 heh Jan 22 23:19:32 persia: http://pastebin.com/f429b20ae ... anything else you would like to see there? Jan 22 23:23:51 asac: From policy 4.1.4, missing bits include: Jan 22 23:24:14 1. how to generate the fully patched source, in a form ready for editing, that would be built to create Debian packages. Jan 22 23:24:34 (most people do this with debian/rules patch, which might work for your CDBS mess) Jan 22 23:25:25 3. Remove source modifications that are currently being applied when building the package Jan 22 23:25:42 This might just be telling someone to unroll the tarball, but I'm not sure. Jan 22 23:26:09 You've hit #2 and #4 well, and added lots of other interesting stuff :) Jan 22 23:30:00 persia: 1. is covered in patching Jan 22 23:30:02 section Jan 22 23:30:21 imo Jan 22 23:30:26 and 3. sounds odd ;) Jan 22 23:30:31 not sure what that means Jan 22 23:30:46 some patches are feature patches, some are needed to build (or at least there might be patches) Jan 22 23:31:05 i dont think anyone can ask for keeping those separately documented ;) Jan 22 23:31:15 for me patching section also tells 3. Jan 22 23:31:15 asac: You7re supposed to provide a step-by-step guide, not say "start a local build and break in" :) Jan 22 23:31:37 yeah. thats bad ;) but debian/rules patch is broken :-P Jan 22 23:31:42 the joy of cdbs Jan 22 23:31:58 I've always interpretedf "remove source modifications" as being both classes of packages. Someone who does silly things gets to keep both parts. Jan 22 23:32:06 anyway, for a reasonably educated guy this shouldnt be a problem ;) Jan 22 23:32:15 You know, lots of people don't use CDBS anymore :) Jan 22 23:32:29 right. but kick off a local build is quite generic ;) Jan 22 23:32:42 you can even use the instructions in the section above ;) Jan 22 23:32:53 good. i think all is fine. thanks! Jan 22 23:32:53 Well, but it's also a non-ideal way to do it, because you have to break it. Jan 22 23:33:02 thats a bug Jan 22 23:33:17 debian/rules patch should just work, but last time i checked it didnt Jan 22 23:33:29 There's probably a CDBS rule like secret-internal-quilt-patched-but-not-built-but-you-don't-know-the-rule-name: rule that one could call. Jan 22 23:33:39 heh. we tried a bit Jan 22 23:33:45 its a bug in the tarball.mk i think Jan 22 23:33:53 Oh. Ugh. Jan 22 23:33:56 we have that in firefox etc. Jan 22 23:34:04 Did I mention that tarball-in-tarball is ugly too :) Jan 22 23:34:05 but let me assure oyu its not a practical problem Jan 22 23:34:15 you want to edit and then usually continue build anyway ... Jan 22 23:34:35 yes, but without tarball in tarball you dont want to build the sources regularly Jan 22 23:34:38 Anyway, your README.source is massively better than not having one at all, especially for such a confusing package using a strange special private CDBS derivative. Jan 22 23:34:48 heh Jan 22 23:35:01 I understand the problem, I just think the solution is more RAM :) Jan 22 23:42:58 so with enough ram, even cdbs-edit-patch would be great experience ;) Jan 22 23:43:41 Well, not as bad, assuming the content was fully cached or one is operating on a tmpfs Jan 22 23:44:28 I'd probably still use quilt, but that's just because I've come to not like digging through CDBS when I wanted to figure out how to do something. dh(1) makes my life easier. Jan 22 23:46:12 aha **** ENDING LOGGING AT Sat Jan 23 02:59:57 2010