=== III1 is now known as III [06:25] is anyone about? === cooloney is now known as cooloney-afk === cooloney-afk is now known as cooloney [09:23] ogra: Ping [09:41] morgen [09:46] hrw: Morning [09:46] hrw: Thanks for the Linked-in add [09:46] np [09:46] hrw: You'd do well to change your picture [09:46] :) [09:46] You don't look like that anymore :) [09:47] I am lazy when it comes to pictures [09:49] It's the reason I didn't recognise you in Prague [09:49] I shaved and haircut on Thursday [09:50] Did you have hair before then? [09:52] yep [09:52] A big change for you then [09:52] It looks better now [10:19] mythripk: ping [11:00] heh makes ubuntu sound like a cult, must shave head before meeting :-) [11:02] Well you know that computer programmers have a reputation for being intimidating and hard! ;) [11:04] * XorA wonders if Henry Rollins is an ubuntu developer [11:06] I hear Charles Bronson also dabbles [11:17] I wrote nice patch during sprint - it dropped hrw@ubuntu.com from binutils/README.cross as such one does not exists [11:17] * hrw is neither Debian or Ubuntu developer [11:18] Would someone know which host is the armel porter box in the Canonical DC? [11:18] I tried rimu and jocote, but these are dead apparently [11:37] lool: kakadu [11:45] lag: kakadu to you too [11:45] oh wait, is that an hostname? :) [11:45] lool: Yes :) [11:46] lag: Works, thanks [11:47] lool: np [11:48] lag: Do you know how to install build-deps? [11:48] hmm apt-get install [11:49] lool: What are you trying to do? [11:49] lag: install build-deps of a package; sudo apt-get install works [11:49] ERROR: package 'libjack0' marked for removal but the system does not allow removals [11:49] hmpf [11:51] :) [11:51] Nothing to do with me [11:51] You'll have to speak to IS [11:51] it's ok, I can live without the package I was missing; it seems it will meed mvo to fix some rapt script [11:51] first time I see this script BTW [11:54] chrisccoulson: Hey [11:55] hi! [11:55] chrisccoulson: Unfortunately, yao is .cn and michaelh .nz, and they are both offline now [11:55] ah, ok [11:55] (they are the main folks looking into the issue, and the other folks have other tasks) [11:56] i'm just trying to figure out how to run it without jit (i know it's possible to do that when creating the JSContext, but i'm not sure if it looks for something in the environment) [11:57] lool: apt-get build-dep package [11:57] hrw: this doesnt work in the porter boxes [11:57] hrw: only apt-get install is allowed [11:57] ok, good to know [11:57] * hrw avoids foreign machines [11:59] chrisccoulson: Running it on imacro_asm.js alone is enough to crash it, but on an empty file or on imacros.jsasm, it doesn't crash [11:59] lool: apt-get install -o "Dir::Etc::SourceList $HOME/mysources.list" setuidbash :-) [11:59] lool, yeah, i'm seeing the same behaviour here [11:59] ukleinek: Eh [12:03] chrisccoulson: A trivial file with "i = 0;" [12:03] breaks it [12:04] lool - i think it's already running without JIT (in any case, running with "-j" still causes it to crash, and that option toggles the state of JIT) [12:05] chrisccoulson: Hmm ok, there's also a -o jit, but I couldn't unset it properly [12:05] chrisccoulson: Would it make sense to try to build the tip of the js tree from mozilla-central to see if it's still there? [12:06] i just had a look at the code for the shell, and passing "-j" causes it to do "JS_ToggleOptions(cx, JSOPTION_JIT);" [12:06] chrisccoulson: a workaround we could try is -fno-strict-aliasing [12:07] chrisccoulson: lunch here, bbl [12:38] * lag wonders where ogra is today [12:38] busy with non IRC stuff, sorry [12:38] whats up ? [12:39] np [12:39] The daily builds appear to have stopped building on the 20th? [12:40] yes, there are issues with the image size of the filesystem [12:40] i'm working on debugging it [12:40] chrisccoulson: back [12:40] ogra: And the 20th is the one that's broken [12:40] somehow we create to small images for no apparent reasons [12:41] so the cp'ing of the chroot content fails with "no space left on device" errors [12:41] Is this something you're working on right now? [12:41] yes [12:41] Then I'll leave you to it [12:41] i dont get the reason though [12:41] Can you poke me when it's complete [12:41] df -ks |cut -f1 is how we get the size [12:42] df: invalid option -- 's' [12:42] Try `df --help' for more information. [12:42] dd if=/dev/zero of= bs=1024 count=0 seek= ... is how we create the image [12:42] err [12:42] du -ks, sorry [12:42] Okay, that works [12:42] according to the manpage du -ks gives me the value of 1k bytes [12:43] so using bs=1024 needs to create an exactly sized image file [12:44] i dont get where the overhead comes from [12:44] apparently there is some [12:44] lool - i was just about to try building our firefox-4.0 package, which is basically what's in mozilla-central; [12:44] ogra: what do you du? [12:44] ogra: Yes it does [12:44] lool, creating ext2 images [12:44] chrisccoulson: Ok, I copied over src/js and ran autoconf, configure, and am building now [12:44] chrisccoulson: But your plan sounds good [12:45] ogra: there is some fs overhead, no? [12:45] ogra: Do you du the .img file, or the contents of the image? [12:45] lool, the build chroot [12:45] even if you du all files in the fs, there is more space used by the fs [12:45] with fs structures [12:45] superblocks for instance are obviously not accounted per file [12:45] we also add 10M for a potential journal to the size variable [12:46] yeah [12:46] i would have expected to have some overhead, but more than 10 meg ? [12:46] this seems really fragile [12:47] it is what livecd-roofs uses for the squashfs size computation [12:47] seems ext*fs has some more overhead [12:47] (the same code is used by angstrom for creating their images btw) [12:48] ogra: apt-cache show genext2fs [12:48] ukleinek, thats what causes my headdache [12:49] and why i'm working at the code :) [12:49] ah, I thought there was no need to specify an image-size [12:49] chrisccoulson: Happy to hear when you have a firefox-4.0 build finished; if my tip build doesn't help, I'll try with -fno-strict-aliasing [12:49] genext2fs allocates the whole size of the target image in ram [12:49] before copying anything into it [12:50] with our 1.6G images that takes 2h and about 2G swap [12:50] huh [12:50] we initially used genext2fs ... i'm currently attempting to switch to a loop mounted img file instead [12:52] loop-mounted? doesn't that require root? [12:53] lool, we have root on the livefs builders [12:54] no prob there [12:54] just not on antimony [12:54] oh right [12:54] 21032 blocks (5.00%) reserved for the super user [12:54] heh [12:54] silly me :P [13:08] chrisccoulson: js from mozilla-central segfaults too [13:09] lool - ah, ok. i can probably stop the firefox-4 build then [13:12] chrisccoulson: Hmm it doesn't use any shared libs or anything does it? [13:12] chrisccoulson: I'm running gdb on the unstripped shell/js file, but the stacktrace is worthless, did you do anything to get a nice backtrace? [13:12] Reading symbols from /home/lool/js/src/shell/js...(no debugging symbols found)...done. [13:12] uh [13:12] ah, not built with -g *me bangs head* [13:13] heh ;) [13:13] * lool builds with -g -ggdb -O0 -fno-strict-aliasing now [13:13] chrisccoulson: ~lool/js/src.tgz is a base tree ifyou like [13:14] * lool grmpfs - mozilla configure doesn't take CFLAGS on the cmdline [13:18] ~curse linux-meta ubuntu crap [13:19] apt-get source linux-what-it-is-called-today suxx [13:21] hrw: it is always linux-image- [13:21] no, it is linux-image-version-abi-flavour [13:22] and version and abi changes daily, twice daily, weekly, randomly [13:22] I thought you wanted meta source? [13:22] no [13:22] I want source [13:22] sure, whats wrong with abi changing? [13:22] if I want meta I do 'apt-get source linux-meta' [13:22] apt-get source linux ? [13:22] ogra: will grab linux-meta instead [13:22] oh, right [13:22] * ogra always forgets that [13:23] ogra: there was bug about it since ubuntu 3.04 or older [13:23] bug #-2 [13:23] hrw: apt-get --only-source source linux [13:24] lool: thx [13:31] crap, I have to pass CXXFLAGS as well [13:33] There, finally, it builds with the proper flags === asac_ is now known as asac [13:35] ogra: hi! I have not had a chance to unpack yet [13:36] dyfet, take your time [13:36] well, I also have some pain killers for my eye... [13:47] GRR -O3 overrides my user-specified -O0 [13:48] and -fstrict-aliasing as well [13:48] chrisccoulson: How is one expected to pass flags to the builds? [13:48] lool, what flags do you want to pass? [13:49] chrisccoulson: I'd like to pass CFLAGS="-g -ggdb -O0 -fno-strict-aliasing -Wall" CXXFLAGS="$CFLAGS" [13:49] MODULE_OPTIMIZE_FLAGS is apparently what I'm supposed to set [13:49] and INTERP_OPTIMIZER, sigh [13:50] lool - doing "export CFLAGS=...." before running configure should work [13:50] chrisccoulson: does not, MODULE_OPTIMIZE_FLAGS and INTERP_OPTIMIZER take precedence (my flags are passed, but overriden later in command-lines) [13:51] I see some -Os now, from /somewhere/ [13:52] chrisccoulson: The evil thing is that different files are compiled with different opts, so it seemed like I was finally using the proper ones, but no, I wasn't for some files :-/ [13:52] lool - does it work if you build with --disable-optimize? [13:53] chrisccoulson: Didn't try that one [13:53] MOZ_OPTIMIZE_FLAGS is where -Os comes from [13:53] --disable-optimize should switch off building different files with different optimizations [13:54] I will pass that *and* turn all the nasty flags off explicitly on make [13:59] * lool looks hard and doesn't see any -Os or -O3 or -fstrict-aliasing anymore [13:59] and the build is faster in -O0 [14:06] chrisccoulson: Yep, same issue with every opt turned off [14:07] same bt [14:07] #0 0x00072688 in js_CheckForStringIndex (id=1514652) at jsobj.cpp:4006 [14:07] #1 0x00073c9c in js_SetPropertyHelper (cx=0x1b7900, obj=0x40602000, id=1514652, defineHow=9, vp=0xbeb433c0) at jsobj.cpp:5012 [14:07] lool: if you want to use the same -Ox everywhere you can say: --enable-optmize="-Os" for instance ... this will override all subtree optimization etc. (not sure if thats what you ask) [14:08] asac: that was the goal, yes, well that and other flags [14:09] lool: the subtree optimizes are tuned by mozilla. they would be happy to get better tuning for armel from talking to a few folks at moz summit. but just -O2 etc. wont be right. [14:09] what problem triggers this? [14:09] crashes with our new toolchain? [14:10] chrisccoulson: eh, s == 0x00000008 now [14:11] asac: the js interpreter in xulrunner/firefox builds is broken with the new toolchain [14:11] asac: What I hate with the mozilla thing is that my flags don't get precedence [14:11] kk [14:12] which flags do you want to remove/add? [14:12] lool: ? [14:13] asac: it's ok now, the flags were discussed earlier here: -O0, -g, -ggdb, -Wall, -fno-strict-aliasing and such [14:13] k [14:13] I managed to pass the flags, but now I'm trying to debug, and it doesn't look too nice [14:13] lool: for best debugging you could use --disable-optimize and --enable-debug [14:14] and then start it from dist/bin directly [14:14] (but i guess that was already mentioned too) [14:19] asac: This is the information I was looking for earlier, but now I have a debug build [14:19] asac: Are you tempted to look into this? [14:21] lool: --enable-debug also enables assertion logging etc. so it might be helpful if you dont get that atm. (e.g. if you start you should see a bunch of prints etc.) [14:22] lool: i dont think i will be able figure these toolchain induced problems easily. [14:39] zumbi: thx for mail - will reply [14:39] morning [14:40] hrw: no problem.. I do not know why i did not see it before [14:46] zumbi: number of your ITP is? [14:48] hrw: why? [14:50] 553682 [14:50] 553683 [14:50] 553684 [14:50] 553685 [14:50] 553687 [14:51] and discussion upon -devel [14:52] zumbi: So what's the model for these sources? [14:53] zumbi: Is it the same source tree uploaded multiple times? [14:53] gcc-4.3, does someone still care about this?? [14:53] zumbi: what about linux headers? [14:54] 553679 [14:55] zumbi: wanted to read [14:56] hrw: read? [14:56] lool: yes, read - I do such thing with bug reports [14:57] zumbi: So I see only one gcc and one eglibc source package; I understand you will go through 6 or so uploads at least everytime the linux headers change or something [14:57] lool: i prefer delay discussion for debconf [14:57] zumbi: Your ITPs seem to use the same model I was using for my cross-toolchain source tree, is that the one? [14:57] zumbi: bookmarked those [14:58] zumbi: will mail debian-embedded/linaro-toolchain with more info [14:58] lool: not exactly, but i keep you in copyright files [14:58] hrw: thanks [14:59] zumbi: I personally concluded that this wasn't a sane model [14:59] Too many uploads, or out of date toolchains, and too many source packages [15:00] lool: is not your model, and what do you care? I am the one who step up for maintainance [15:00] within Debian [15:00] I have been holding upload for later discussion [15:00] multiarch, sysroot and emdebian way of doing things [15:00] zumbi: I care because I will be using Debian cross-toolchains too, and because I care about Debian! [15:01] I would prefer to coordinate with you all, so I propose to discuss this at debconf [15:01] zumbi: Discussing at Debconf is fine too, but we can as well discuss some of it now? [15:01] please note I am not against you [15:01] One doesn't prevent the other :) [15:01] zumbi: now we have "source binary packages" for eglibc, gcc-4.[45], linux, binutils [15:01] zumbi: I'm not saying you're against me [15:01] lool: I am at work [15:02] none pais me to do this work [15:02] zumbi: Ok; if you can't chat now, we can chat later or only at debconf [15:02] zumbi: soon (before maverick alpha3 if all go ok) we will have stages support in eglibc/gcc/linux and also their debian/rules* in *-source packages [15:02] later should be fine, but i rather have a meeting at debconf if you really care (on all arches) [15:02] zumbi: I don't think the arches matter really [15:02] hrw: but only working on armel :/ [15:03] zumbi: no - any non-bi/triarch [15:03] zumbi: It's unfortunate that we broke other arches, but it's not intended and am sure it can be fixes [15:03] *fixed [15:03] zumbi: tested only for armel yes [15:04] hey guys, lets better discuss later or by mail if you do not mind [15:04] sure [15:04] please, and I am not against you [15:04] does maverick-ARM run under QEMU at all ? [15:04] I hope that we (Linaro and Emdebian) will have a chance once to meet in one place and discuss [15:04] rsavoye: should [15:05] is it faster than a beagle ? :-) [15:05] zumbi: I am trying to be as much as possible not against anyone. If I will became such then tell [15:05] rsavoye: maybe on 30GHz x86-64... [15:05] that zero is not mistake [15:06] oh well... [15:06] hrw: no, you are fine [15:06] too bad cross-compiling is so broken for most packages [15:07] rsavoye: thats debian/ubuntu errors [15:07] hrw: but i have the feeling that lool, slangasek and partialy doko, do not undetrstand me and they are somehow mad at me. But it is just a feeling. [15:07] hrw has the patches to fix thousands of cross compile issues :-) [15:07] rsavoye: openembedded has thousands of cross compiled ones [15:07] I know, but I prefer to not use the OE build style [15:08] zumbi: they did less crosscompilations that we did [15:08] zumbi: I'm not mad at you :-) [15:08] zumbi: I'm not mad at you, but you clearly working at cross-purposes to what we're trying to achieve with multiarch [15:08] rsavoye: so merge our (OE) patches [15:08] unfortunately it was OpenJDK I was hoping to cross compile, but it looks like a mess [15:08] zumbi: You seem to be pushing for solutions which we identified as incomplete already [15:08] rsavoye: it is a mess but crossbuildable mess [15:08] and I've already explained how this is the case, so I'm at a loss to how I can clarify this [15:08] slangasek: happy to hear that I hope we can discuss further at debconf [15:09] so far I am ignoring 'multiarch' word and just do cross stuff [15:09] I see the long list of patches, I have to decide if I want to apply them all, and then fix things to cross compile with your toolchain, not OE [15:09] rsavoye: I know [15:10] lool: I am not pushing anything, I could have the upload done and end with the issue. But I hold because I want consensus. Let's better talk at debconf and please also consider Squeeze release in mind [15:10] hrw: how does OE build their cross toolchains? do they use sysroot? [15:10] hrw: have you experienced the with-libs/with-headers pain? [15:11] zumbi: sysroot only now [15:11] zumbi: non sysroot way is argh but I feel that multiarch debian will force that way [15:12] yes, everybody does, I do not know why do not work for lool [15:12] anyway, lets better delay discussion for later (or debconf) [15:13] I hope for notes from debconf meeting [15:14] hrw: I always try to be transparent -- do not worry for that [15:15] zumbi: Well if you had proceeded with an upload, you wouldn't have put an end to the issue, since I would be unhappy :-) [15:16] zumbi: There are multiple discussions going on; one is about cross-compiler packages, and another one is about cross-compiling Debian [15:16] Concerning cross-compiler packages, what you used to do should still be possible in the future, but might be temporarily broken (patches welcome); it should also be more solid going forward [15:16] Since we don't have parallel sets of rules for cross versus non-cross [15:17] It will *also* allow uploading a single cross-toolchain-armel package which will trigger a while toolchain bootstrap [15:17] You don't seem to look at the latter, I don't understand why [15:17] zumbi: to satisfy the requirements for multiarch, the trees for all architectures *must* have the same root, and it must be /; and consequently, sysroot will fail to allow coinstallability, because the architecture tuple is part of the sysroot path, *not* part of the paths for the subdirectories [15:17] I rather have binutils-cross which builds all binutils targets [15:17] I went with the 4 source packages + 6 uploads route myself, just like the one you ITP-ed, and it's *pain*, and we have another way which seems superior? [15:18] zumbi: 'all binutils targets' == all arches? [15:18] zumbi: This is a valid approach, it's not what you ITP-ed; I don't think it's a good approach either, but for different reasons [15:18] hrw: *That's what I understood at least) [15:19] slangasek: yes, at the end, I understand your point :) -- but I am still convinced that multiarch and sysroot should be compatible and that is not going to happen for Squeeze, later we can change [15:19] I don't see any reason they wouldn't be compatible [15:20] it's just that neither helps the goals of the other [15:20] lool: sure, ITP should be renamed then, I though on that after filing the ITP, but that time none care, so I did not had to coordinate much [15:21] slangasek: true, I saw your point, makes sense to me [15:22] zumbi: I don't think having multiarch and sysroot compatible wouldn't land for squeeze, it's not a complex patch, just need to agree on pathnames [15:25] lool: sure, lets talk later or at debconf about it. And let me repeat, I am not against you, but I was the only one caring on cross tools on the last 5-6 years, and doko does not even allow me to touch his tree. [15:25] but hey.. does not matter! We are good friends and we can discuss this like persons [15:27] * ogra GRRs at the archive [15:32] zumbi: I'm not against you, I'm against the proposal of -armel packages because I went through that and I think that's heavy, and I'm against the proposal of -cross packages because I think that's ugly, but we can talk this over :-) [15:33] lool: sure - I am open for discussion :) [15:34] lool: indeed, that was doko plan, he wanted only armel in the archive, but there are other devels that would like to have any-to-any arch, like we had on lenny [15:35] zumbi: I would like to allow amy-to-any, but I'm not sure the Debian archive is the best place for this [15:35] In Ubuntu, I understand only cross-armel will be provided [15:35] now who is amy ? [15:35] on i386 and amd64 === asac_ is now known as asac [16:36] robclark: ping [16:36] lag: pong [16:37] robclark: Can you explain to me in simple terms what a lost-digit is please? [16:37] lag: basically I think it means that sync is lost.. although I'm not yet sure why it happens over and over a gazillion times [16:39] Oh, you see that too? [16:39] I thought it was just me and my weird monitor [16:43] robclark: ? [16:43] lag: yeah.. [16:43] (sorry, multitasking) [16:44] Mythri's patch fixes this issue for me [16:44] yeah, I'm still cleaning up my patch, and then I need to rebase on mythripk's latest [16:44] I'm hoping that helps === amitk is now known as amit-afk === fta_ is now known as fta [17:07] ~curse libelf<>libelfg === fta_ is now known as fta === fta_ is now known as fta [18:19] lool - i'm not sure whether you noticed this already, but the jsid is getting mangled between frames 1 and 2 of https://pastebin.canonical.com/35036/ [18:20] #1 0x2a043c86 in js_DefineNativeProperty (cx=0x2a0d6b80, obj=0x2a0f80c0, [18:20] id=705479548, value=22, getter=0x2a03f695 , [18:20] setter=0x2a03f631 , attrs=69, flags=4, shortid=0, [18:20] propp=0x0, defineHow=0) [18:20] #2 0x2a0440a2 in js_DefineBlockVariable (cx=0x2a0cc37c, obj=0x2a0cc378, [18:20] id=705523208, index=) [18:20] the id parameters should be the same [18:25] in fact, all of the arguments passed to js_DefineNativeProperty are wrong [18:26] bah lucid x86 dual boot broken :-( [18:27] chrisccoulson: Oh [18:27] chrisccoulson: that's very interesting === fta_ is now known as fta === hrw is now known as hrw|gone === fta_ is now known as fta [19:37] all - Where can I find daily build images for OMAP4/ubuntu? [19:45] jayabharath: http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/current [19:46] there you can find the omap 3 and omap 4 images [19:47] jayabharath: http://testcases.qa.ubuntu.com/Install/ARM/PreinstalledImage if you need instructions to install it === fta_ is now known as fta [19:54] rsalveti: thanks. Do these images work on OMAP4 Blaze platform? [19:55] GrueMaster: did you ever test this image on blaze? [19:55] jayabharath: I'm not sure, but I believe it should work [19:56] I just tested/saw it on a normal panda [19:56] rsalveti: I don't have a blaze (yet). [19:56] I see... ogra should have it (my guess) [19:56] anyway will check it out and go from there [19:57] jayabharath: yeah, let us know if it worked or not [19:57] ok === fta_ is now known as fta === fta_ is now known as fta [21:15] Hallo word de arm-wm8505 ondersteunt === fta_ is now known as fta [21:33] boo [21:58] davidm ? === fta_ is now known as fta === andy is now known as andyj [23:10] segfaults in system-config-printer when poking at a windows network [23:22] cwillu_at_work: please, report the bug [23:23] pcacjr, seems to be dups around, I'm still reading through them, and being distracted by other folks :p [23:23] cwillu_at_work, oh, i see. heh :-) [23:37] pcacjr, https://bugs.launchpad.net/ubuntu/+source/nss-mdns/+bug/370293 looks pretty similar [23:37] Ubuntu bug 370293 in nss-mdns (Ubuntu) "system-config-printer.py crashed with SIGSEGV in strlen@plt() (affects: 4) (dups: 1) (heat: 11)" [Medium,New] [23:38] if I install apport, will I get a decent trace out of it? [23:38] cwillu_at_work, will take a look. i dunno.. [23:38] just testing... [23:39] I'm browsing for the printer, and it dies when I click on a hostname [23:39] the hostnames themselves show up in the workgroup tree though [23:39] * pcacjr nods [23:40] i'm looking into it right now [23:49] pcacjr, booting up a fresh card right now in case the card in question was the problem [23:51] okay, it's not the card [23:52] might be privilege related [23:52] I need to test again, but the first attempt under root worked fine [23:52] (I'm generally working as an unprivileged user in lp and lpadmin groups) [23:52] I can provide you with ssh access to the box in question if you want [23:53] nope, spoke too soon, died on the next machine I clicked on [23:53] but that implies that it's not completely deterministic [23:53] pcacjr, ^ === fta_ is now known as fta