| === bjf is now known as bjf-afk | ||
| === plars_ is now known as plars | ||
| === bjf-afk is now known as bjf | ||
| === bjf is now known as bjf-afk | ||
| ogra | lool, what kind of images do you usually use with qemu ? (/me is till trying to find out why big task installs hang) | 09:13 |
|---|---|---|
| ogra | *still | 09:14 |
| ogra | i wonder if converting to qcow2 before switching to the VM gains me anything wrt stability | 09:15 |
| persia | Not really. qcow2 just saves space. | 09:17 |
| persia | Assuming no bugs in the converter, it's a no-op, and if the converter is buggy, it's less stable (the converter isn't that buggy) | 09:17 |
| wao | oh hai | 09:52 |
| wao | what is actually available arm smartbooks? | 09:53 |
| wao | pegatron neo seems is far away from open sale. | 09:53 |
| persia | The Sharp Netwalker is the only one I know to be on the market today. | 09:53 |
| wao | and touchbook one, i just forget on it | 09:56 |
| wao | just touchbook from alwaysinovating | 09:56 |
| lool | ogra: I'm using ext4 | 09:57 |
| lool | On real files provisioned for the full space | 09:57 |
| ogra | lool, i mean the underlying format | 09:57 |
| lool | i.e 2 GB of zeroes in a file | 09:57 |
| persia | touchbook from alwaysinnovating is shipping now? | 09:57 |
| ogra | so raw with qemu-img | 09:57 |
| lool | Yes | 09:57 |
| ogra | or dd | 09:57 |
| ogra | hmm | 09:58 |
| ogra | rootstock uses qemu-img too ... but gets that hang :/ | 09:58 |
| lool | I'm using dd, but I don't think that makes any difference | 09:58 |
| ogra | the diff between the old qemu that workeed and todays which doent work for me installing bigger tasks has disk handling changes | 09:59 |
| lool | You can try stracing or gdbing qemu-system | 09:59 |
| ogra | *doesnt | 09:59 |
| lool | I fixed the missing symbols in recent uploads, so the ddeb has them | 09:59 |
| ogra | i tried stracing, outside it only gives me clock accesses | 09:59 |
| wao | persia: well, my friend has one since.. november? but that have so long delays at shipping :l | 09:59 |
| lool | That's probably too late then | 09:59 |
| ogra | inside, actually stracing apt doesnt get me anything wrong | 09:59 |
| wao | *they | 09:59 |
| lool | ogra: Try bisecting using the upstream qemu-kvm.git if you can reproduce easily | 10:00 |
| ogra | lool, i can, it reliably hangs at unpacking iso-codes if i install ubuntu-netbook^ | 10:00 |
| ogra | no matter if its rootstock or plain qemu-system-arm | 10:00 |
| persia | wao: Thanks. I'll add it to my list of available hardware. | 10:01 |
| ogra | i initially thought its the way rootstock initializes the system ... i.e. that i miss something ... but using it plain does get me the same hang | 10:01 |
| wao | persia: well these day at cebit nowthing comes out :( just some tablets | 10:01 |
| persia | I only know of AlwaysInnovating Touchbook, Sharp Netwalker, Genesi Efika MX. I'd love to hear of more stuff. | 10:02 |
| wao | something from mobinova was released | 10:03 |
| wao | at some congress in taipei | 10:03 |
| ogra | lool, well, the only thing i see (or asac did yesterday when he bisected out of boredom) is http://paste.ubuntu.com/387762/ | 10:04 |
| ogra | which made me think it might be an image thing | 10:04 |
| ogra | or I/O to the image | 10:04 |
| lool | ogra: Send a mail to the qemu-devel list Cc:ing the author of the problematic patch? | 10:06 |
| persia | wao: The mobinnova elan? Announced but not shipping as far as I can tell. | 10:06 |
| ogra | well, i'm not sure its the problematic one ... especially since you dont see any issues | 10:06 |
| ogra | which confuses me | 10:06 |
| wao | persia: well, they announced price tag, that's all | 10:08 |
| persia | wao: Yeah. I like to wait until I know people can buy things before recommending them :) | 10:08 |
| persia | I prefer to know someone who has one who can tell me if they like it, and in which ways it's inferior. | 10:08 |
| lool | ogra: I'm not doing full installs either | 10:09 |
| ogra | ah | 10:09 |
| lool | ogra: and it might appear due to e.g. your super-fast SSD host disk | 10:09 |
| ogra | hmm | 10:10 |
| ogra | i would expect to see anything in the logs | 10:10 |
| ogra | but thats an intresting theory, i'll try to build on a USB disk | 10:10 |
| lool | I mean the bug might be trigerred by a race which only happens on your hardware | 10:11 |
| ogra | yes, i'll try to verify that using a slow disk | 10:12 |
| ogra | i thought you mean r/w issues on the disk :) | 10:12 |
| * ogra goes to find some breakfast | 10:13 | |
| wao | persia: well, if you know something new about saling smartbooks, just inform me:) | 10:15 |
| persia | wao: Right now I only know of three devices (previously listed). People usually mention their hardware here, if you read backscroll. | 10:16 |
| asac | ogra: so lool doesnt see the rootstock issues? should i try? | 10:25 |
| ogra | asac, well, he doesnt do such massive installs in his setups | 10:26 |
| ogra | asac, feel free ... do a rootstock build with -s ubuntu.netbook^ | 10:26 |
| ogra | err | 10:26 |
| ogra | -s ubuntu-netbook^ | 10:26 |
| ogra | and see if it hangs at "Unpacking iso-codes from ...." | 10:26 |
| ogra | note it will take over 1h to get there | 10:27 |
| dmart | Hi all, has anyone been trying to use the 20100303 ubuntu-netbook armel image? | 10:36 |
| dmart | I get a weird problem: | 10:36 |
| dmart | If I open a terminal and press enter, ^\ is printed in console text over the top of the framebuffer and then the X session dies | 10:37 |
| ogra | known bug | 10:37 |
| lool | Sounds like the plymouth race | 10:37 |
| ogra | ask asac he fought with it for some days | 10:37 |
| dmart | yeuch | 10:37 |
| dmart | ok | 10:37 |
| ogra | uninstall plymouth | 10:37 |
| lool | dmart: if you login again, it shouldn't happen I think? | 10:38 |
| dmart | Glad it's known about, I wouldn't have guessed what to report the bug on! | 10:38 |
| * dmart tries | 10:38 | |
| * lool reported the bug against plymouth, but I'm pretty sure it got ignored and discussions is happening somewhere else | 10:38 | |
| persia | I think there's a few bugs about it based on #ubuntu-bugs traffic | 10:38 |
| dmart | What's the default password for the ubuntu user (tried "ubuntu" but it didn't log in) | 10:39 |
| ogra | lool, seb takes it serious ... he was the one who told me about it | 10:40 |
| lool | ogra: I know it's taken seriously, I'm just saying that I don't know where discussion is happening about it | 10:41 |
| lool | I filed a bug against plymouth (couldn't find any other one) and it got no feedback, wasn't merged etc. | 10:42 |
| lool | I *think* Scott is working on this, perhaps slangasek too, but I'm not sure | 10:42 |
| dmart | Ubunstalling plymouth and restarting gdm seemed to fix it | 10:42 |
| dmart | I see there is a panel icon to get back to the launcher now | 10:42 |
| persia | dmart: default password is nothing at all. | 10:43 |
| dmart | Ah, right. That's more sensible I guess; newbie users mightn't guess "ubuntu" | 10:44 |
| persia | dmart: Also it means that ssh can't work (even if someone installs sshd) and similar, whereas a real default password would leave systems open to the default password hole. | 10:45 |
| dmart | Good point | 10:45 |
| lool | dmart: Ubunstalling, very cute :) | 10:46 |
| dmart | eh? | 10:46 |
| lool | 11:42 < dmart> Ubunstalling plymouth and restarting gdm seemed to fix it | 10:46 |
| ogra_ | sweet | 10:46 |
| dmart | Oops, if you can believe it, that was a typo... | 10:47 |
| ogra_ | dmart, you dont inted to move to marketing, do you ? | 10:47 |
| lool | dmart: I can, I'll add it to my collection of really cute typos | 10:47 |
| dmart | (A bit like the way I tended to mispell all words starting with P as "PRINT" in BASIC programming days...) | 10:47 |
| lool | SWPeriously? | 10:47 |
| === ogra_ is now known as ogra | ||
| dmart | (onily when daydreaming) | 10:49 |
| dmart | Did anyone ever manage to get hold of a hub to look into the network slowness on imx51? | 10:51 |
| dmart | Currently I must use one of those nettop things as a "switch"... they have wireless. Uplinking via that is ~20x faster than a direct cable connection to a hub. | 10:55 |
| dmart | ~Z | 10:57 |
| dmart | Unfortunately I don't know how to debug this. | 11:00 |
| lool | dmart: Sounds like you might want to involve Freescale on that; they are usually interested in buying the hardware when we mention that the boards doesn't work with that hard disk or that monitor | 11:03 |
| lool | dmart: I remember there are two ethernet drivers in the tree, I'm not sure we're using the most recent FSL one, so that might help too | 11:04 |
| ogra | dmart, i know i still own one, but searching for it two times didnt bring it up yet | 11:04 |
| ogra | lool, we use full BSP in lucid | 11:05 |
| ogra | no own patches | 11:05 |
| ogra | so FSL should see the same issues with their kernel if its a driver issue | 11:05 |
| lool | Still, we might be configuring the tree for the wrong driver; that might be unlikely though, I'm not intimate with imx51 anymore | 11:05 |
| ogra | no, we switched to use the same they define in their defconfig | 11:06 |
| dmart | I'll try and raise it with Freescale; maybe this is something they know about | 11:17 |
| ogra | dmart, it might be related to bug 457878 | 11:41 |
| ubot4 | Launchpad bug 457878 in linux-fsl-imx51 (Ubuntu Lucid) (and 1 other project) "imx51 on board ethernet plug/unplug events not detected (affects: 2)" [Medium,Confirmed] https://launchpad.net/bugs/457878 | 11:41 |
| dmart | Yeah, someone suggested that before. It's possible. | 11:41 |
| ogra | given the phy layer is busted it might fail proper autonegotiation | 11:41 |
| dmart | I added a cross-reference. | 11:45 |
| ogra | thanks | 11:45 |
| ogra | heh, now i have john cleese's voice in my head | 11:46 |
| persia | Well, give it back. He might have a use for it. | 11:49 |
| ogra | lol | 11:53 |
| === dmart_ is now known as dmart | ||
| === bjf-afk is now known as bjf | ||
| nemo | Hey guys. I don't know which endianness you guys use, but wanted to note we finally resolved a few of our issues on that front, and also have our engine running on iphone... | 15:46 |
| nemo | so I was wondering if anyone here would be interested in pulling the ubuntu x86/x86_64 hedgewars package into arm | 15:47 |
| nemo | esp once we release .13 w/ endian probs all squashed | 15:47 |
| ogra | we use little endian (thus the architecture package name armel, arm endian little) | 15:48 |
| ogra | if hedgewars is in the archive it will just be built on armel automatically | 15:49 |
| nemo | oh? huh. last I checked I only saw x86 arch listed | 15:50 |
| nemo | maybe there's some other issue | 15:51 |
| ogra | then talk to the package maintainer | 15:51 |
| nemo | aight. I don't know much about ubuntu processes | 15:51 |
| ogra | you can explicitly make a package build only on one arch if you want to | 15:51 |
| persia | We ship hedgewars for armel | 15:51 |
| ogra | persia, ah, great | 15:51 |
| ogra | i didnt bothe to look :) | 15:51 |
| ogra | +r | 15:51 |
| nemo | http://packages.ubuntu.com/lucid/hedgewars | 15:52 |
| nemo | only shows amd64/i386 | 15:52 |
| * persia is on the Games team and keeps track of these things. | 15:52 | |
| persia | nemo: Don't trust packages.ubuntu.com. Ask launchpad. | 15:52 |
| ogra | nemo, packages.u.c doesnt have armel | 15:52 |
| nemo | I don't actually have an arm machine yet, but I (hopefully) will finally be getting a pandora | 15:52 |
| ogra | right | 15:52 |
| persia | https://launchpad.net/ubuntu/+source/hedgewards | 15:52 |
| persia | https://launchpad.net/ubuntu/+source/hedgewars | 15:52 |
| ogra | look at launchpad | 15:52 |
| nemo | woah | 15:53 |
| nemo | wait. powerpc?? | 15:53 |
| nemo | how the heck are they doing that? | 15:53 |
| nemo | there should be some colour issues | 15:53 |
| nemo | well... cool. | 15:53 |
| nemo | hopefully .13 will make it run even better :) | 15:53 |
| ogra | that it built doesnt mean it also runs :) | 15:53 |
| ogra | or that anyone tested it :) | 15:54 |
| nemo | heh. you'd think there'd still be a few gamers on esoteric platforms | 15:55 |
| nemo | well. esp ARM | 15:55 |
| persia | I don't think we have any gamers on ia64 or sparc, but we do have them on the rest of the platforms. | 15:59 |
| persia | But that doesn't necessarily mean everything is fixed :) | 15:59 |
| ogra | you never know :) | 15:59 |
| persia | Well, I do know we don't have any games maintainers on ia64 at least, and I haven't seen any games uploads from sparc, but yeah, I can't actually know. | 15:59 |
| * ogra bets there are nethack people on sparc :) | 16:01 | |
| nemo | heh | 16:01 |
| nemo | there are probably some nethack people on TI-83s | 16:01 |
| nemo | well. thanks for the info. now I just need to find a gamer running ubuntu on arm to try it out. | 16:02 |
| nemo | stupid pandora delays :-/ | 16:02 |
| nemo | talked to dude doing iphone port, he's pretty sure ppc should be totally unplayable in .12 | 16:04 |
| JamieBennett | dmart: can you give me your opinion on the correct way to fix a build failure? | 16:23 |
| JamieBennett | http://pastebin.ubuntu.com/388361/ | 16:23 |
| JamieBennett | this is the code that checks for specific arch's | 16:24 |
| JamieBennett | I want a define for ARMv7, not specifically thumb, just wondered what to use | 16:24 |
| dmart | hang on a mo | 16:25 |
| dmart | You could use __ARM_ARCH_7A__ | 16:25 |
| dmart | The main annoyance there is that the code will repeatedly break if builrding for a subsequent architecture. | 16:26 |
| dmart | What is the code protected by these #ifdefs? | 16:26 |
| JamieBennett | dmart: indeed | 16:26 |
| JamieBennett | some defines for nop, read_barrier and write_barrier stuff | 16:26 |
| JamieBennett | dmart: http://pastebin.ubuntu.com/388370/ | 16:27 |
| dmart | Is there v6 / v7 code? | 16:27 |
| dmart | (and what package is this?) | 16:27 |
| JamieBennett | just that | 16:28 |
| JamieBennett | fio | 16:28 |
| dmart | So there are no definitions of nop, read_barrier and write_barrier for the newer archs? | 16:28 |
| JamieBennett | dmart: thats why its failing | 16:28 |
| dmart | ok | 16:28 |
| JamieBennett | I belive its just not defining them because the right ARCH check isn't satisfied | 16:29 |
| dmart | Weell, v6 and v7 (especially SMP) should have non-trivial definitions for these. | 16:29 |
| dmart | Is this from an embedded snapshot of another library? The code looks a bit familiar. | 16:29 |
| JamieBennett | its in fio (arch/arch-arm.h) | 16:30 |
| dmart | OK, I guess it may be unique-ish to that package then | 16:30 |
| JamieBennett | so the __ARCH_ARM_7A__ define may be sufficient or does this require something more? | 16:31 |
| dmart | The code will "work", but it won't function as intended, especially if we want SMP to work properly. Hold on, I'll have a quick think... | 16:34 |
| JamieBennett | dmart: cool | 16:34 |
| dmart | The cleanest way might be to do something like this http://pastebin.ubuntu.com/388382/ | 16:40 |
| dmart | HAVE_GCC_ATOMICS can be detected using configure tests similar to what's been done for other packages (asac and dyfet have already done that elsewhere) | 16:41 |
| * JamieBennett looks | 16:41 | |
| dmart | HAVE_ARM_NOP could be detected using a configure test (try and assemble a "nop" instruction) ... or using the __ARM_ARCH_... macros (__ARM_ARCH_6__ || __ARM_ARCH_6K__ || ARM_ARCH_6KZ__ || __ARM_ARCH_7__ || __ARM_ARCH_7A__ ... and maintain it... ugh) | 16:43 |
| JamieBennett | OK, I think I need to do a bit of background reading, thanks for the pointers | 16:44 |
| dyfet | well, if we are interested in whether the specific gcc being used to compile supports atomic functions, then we need a configure test for that | 16:44 |
| dmart | Basically, it is cleaner not to add SMP correctness for GCC+kernel combinations which don't support this ... only people using ancient tools, ancient kernel, or a platform where it doesn't matter will fail to get the SMP-safe definitions. | 16:45 |
| dmart | Otherwise we would need some special-case inline asm for this case, which will likely cause confusion and maintenance problems in the future. | 16:46 |
| dmart | See https://wiki.ubuntu.com/ARM/Thumb2PortingHowto#Atomic%20operations%20and%20SMP%20safety%20(SWP,%20LDREX,%20STREX;%20memory%20barriers) | 16:50 |
| dmart | (background on atomics) | 16:50 |
| * JamieBennett reads | 16:50 | |
| * dmart admires the URLs generated by wiki.ubuntu.com | 16:51 | |
| persia | Because they are readable, or because they are confusing? | 16:51 |
| JamieBennett | dyfet: can you point me to a package that you did the configure checks in so I can reference it please | 16:52 |
| dyfet | Hmm...I think maybe gmp...or boost, that has a very good example in cmake | 16:53 |
| JamieBennett | dyfet: thanks | 16:53 |
| JamieBennett | :q | 16:55 |
| JamieBennett | doh | 16:55 |
| dmart | NCommander: would you be able to provide Ramana with debug objects for the OOo build problem? It sounds like debug info would be useful, and I think you were doing a build? | 17:02 |
| dmart | (my build attempt ftbfs: http://pastebin.ubuntu.com/388391/) | 17:02 |
| ogra | lool, so i tried a buiold on an USB key, no change ... what was intresting though was that the activity light on the stick kept blinking for nearly 20min even though the output from apt was already stuck in unpacking iso-codes | 17:27 |
| ogra | i wonder if there is some buffer thats overrunning or something so apt still does its work in the bg but doesnt present the output | 17:28 |
| dmart | Was the kernel just committing the page cache to USB? This can go on for a long time after a lot of data is written to a filesystem. (Though 20 mins suggests a very large amount of data, dpkg's unpack phase could have this effect) | 17:30 |
| ogra | well, i dont know how my host kernel behaves regarding the VM | 17:31 |
| ogra | the first step would likely be to find out which of the two kernels does the caching here :) | 17:32 |
| ogra | its a quite tricky situation | 17:32 |
| dmart | Maybe the storage emulation in the VM is slow, so there is a constant trickle of data to the real USB device for a long time. | 17:37 |
| ogra | yeah, and maybe that causes the hiccup that makes apt get stuck | 17:37 |
| * ogra decides to kill rootsock now before the intel CPU pops out through the bottom of the laptop ... i guess its glowing :) | 17:38 | |
| asac__ | ogra: what should i try for rootstock? | 17:40 |
| * asac__ fires it up | 17:42 | |
| asac__ | what is EST? | 17:48 |
| asac__ | is that UTC-5? | 17:48 |
| asac__ | yeah seems so | 17:50 |
| |nfecteD | argh! all this s*** that doesn't compile and doesn't work | 18:02 |
| |nfecteD | Snes9x no go... VICE won't compile :/ | 18:03 |
| |nfecteD | blargh | 18:03 |
| persia | |nfecteD: Thanks for the care :) | 18:28 |
| NCommander | dmart: welcome to the pain of building OOo | 18:30 |
| NCommander | dmart: I managed to build OOo, but its really not trivial to do so, but I don't mine letting him loose on the GDB setup I have :-) | 18:31 |
| dmart | I did succeed once before... but a long time ago. Took a few days too | 18:31 |
| NCommander | dmart: successful build time is roughly two-three days if your lucky | 18:31 |
| dmart | I did try to use distcc, but you seem to lose as much as you gain. make doesn't know to parallelise certain things and not others. | 18:32 |
| NCommander | dmart: youcan use ooo-build with icecc for slightly better results, but my experience was about the same | 18:35 |
| dmart | Did you get a debug build yet? | 18:35 |
| NCommander | dmart: yes, I did, and I posted debug traces to the bug | 18:36 |
| NCommander | dmart: but they don't tell us anything very useful unfortuately | 18:37 |
| dmart | I got some questions here about whether we have all the .o files needed to build gcc3_uno (or whatever it's called) | 18:37 |
| dmart | What's the bug number again? | 18:38 |
| NCommander | dmart: https://bugs.edge.launchpad.net/ubuntu/+source/openoffice.org/+bug/417009 | 18:38 |
| ubot4 | Launchpad bug 417009 in openoffice.org (Ubuntu Karmic) (and 3 other projects) "all openoffice apps die in 'com::sun::star::ucb::InteractiveAugmentedIOException' on armel in karmic (affects: 1)" [Low,Won't fix] | 18:38 |
| dmart | Can you post the relevant .o files? I haven't been able to get a build going here --- it falls over during patching. | 18:39 |
| NCommander | dmart: its not trivial to do so | 18:44 |
| NCommander | dmart: and you can't get a useful trace of OOo without a *full* build* even if you just build a debug version of the module that is crahsing | 18:44 |
| dmart | It's not trivial for me to build it, or for you to send the .o files ? ;) | 18:44 |
| NCommander | dmart: bandwidth is an issue | 18:45 |
| dmart | It's slow, but the normal debuild route ought to work, right? | 18:45 |
| NCommander | oooh | 18:45 |
| dmart | (me building I mean) | 18:45 |
| * NCommander just managed to build a working UNO library on a karmic chroot | 18:45 | |
| dyfet | oh?! | 18:45 |
| dmart | eh? | 18:45 |
| NCommander | dmart: UNO is the bit of OOo that keeps crashing | 18:45 |
| NCommander | dyfet: I forced an old glibc in the chroot, and then rebuild the uno library | 18:46 |
| NCommander | and it works | 18:46 |
| dyfet | oh...hmm...then it suggests it is more tied to some issue in glibc? | 18:46 |
| dmart | that's a bit scary | 18:46 |
| NCommander | dyfet: I had to use gcc 4.3 over 4.4, but 4.3+eglibc from karmic also got a bust | 18:46 |
| NCommander | dmart: yeah, I tried downgrading binutils and GCC first to try and flush out where we might have a regression :-/ | 18:46 |
| dmart | what about 4.4+karmic eglibc? | 18:47 |
| NCommander | dmart: bust. | 18:47 |
| dyfet | dmart: this is a stack unwinding issue....(I guess still is...) | 18:47 |
| dmart | Maybe there is some unwinding brokenness in libc? | 18:47 |
| NCommander | dyfet: dmart: I confirmed we're blowing up in the unwind exception handler in phase2 (careful debugging found this) | 18:47 |
| NCommander | dmart: looks like it, but it doesn't make sense why I can build uno ina jaunty chroot, copy it into a karmic or lucid system work, and get a working binary | 18:48 |
| dyfet | Hmm...do we need to migrate older glibc stack unwinding support into the current glibc for arm? That could be ugly :) | 18:48 |
| NCommander | dyfet: you *don't* want to know how I forced an older glibc into a karmic system | 18:48 |
| * NCommander had apps explodjng left and right | 18:48 | |
| dyfet | NCommander: when you moved the jaunty build of uno, it probably still linked against older libc version code/loaded the older library.... | 18:49 |
| NCommander | dyfet: we don't have the old libraris in karmic/lucid | 18:49 |
| NCommander | ENOABIBREAK | 18:49 |
| NCommander | *libraries | 18:50 |
| dyfet | NCommander: I think we do for backward compat... | 18:50 |
| NCommander | dyfet: ldd says otherwise | 18:50 |
| dyfet | NCommander: Okay, if you confirmed it with ldd, I am satisfied :) | 18:50 |
| persia | Note that an individual install of jaunty upgraded to karmic may have some old libraries left around, and we do keep some stuff in Section: oldlibs when porting is very hard, but nothing relevant to OOo. | 18:51 |
| NCommander | persia: these are clean installations and chroots :-/ | 18:52 |
| persia | NCommander: I know, and even if they weren't it wouldn't matter because it's OO.o I'm only mentioning for completeness. | 18:52 |
| * NCommander is scared at the notion of bisecting glibc | 18:56 | |
| dmart | Well, catch you tomorrow... | 18:59 |
| * NCommander just missed him | 19:01 | |
| NCommander | bugger | 19:01 |
| lool | ogra: So can you log from another console while it's hung? | 19:03 |
| lool | ogra: Would you be able to gdb apt? | 19:03 |
| armin76 | NCommander: i'm here though :D | 19:06 |
| NCommander | armin76: want to bisect glibc? :-) | 19:07 |
| armin76 | i need a board first *g* | 19:07 |
| NCommander | armin76: SSH access could be arranged | 19:08 |
| armin76 | i like video! :D | 19:08 |
| NCommander | armin76: a *really* long DVI cable? | 19:08 |
| armin76 | sure, why not :D | 19:10 |
| ogra | lool, not under rootstock but in a normal VM session ... i'll do that tomorrow, it always takes ages to get to the point, nothing for tonight anymore | 19:19 |
| ogra | asac, just running rootstock with a -s ubuntu-netbook^ task should do | 19:19 |
| ogra | but i suspect you'll see the same as i do anyway ... | 19:20 |
| * ogra is off again until meeting | 19:20 | |
| lool | ogra: You should buy a faster hard disk | 19:26 |
| === dyfet` is now known as dyfet | ||
| JamieBennett | dyfet: around? | 19:36 |
| dyfet | yes | 19:37 |
| dyfet | Was just setting up a lucid server.... | 19:37 |
| JamieBennett | cool, got time to hand-hold me through this fio problem so I can learn how to do it properly | 19:37 |
| JamieBennett | ? | 19:37 |
| dyfet | lol okay...which package are we talking about? | 19:37 |
| JamieBennett | fio | 19:38 |
| dyfet | oh, there is one :) | 19:38 |
| JamieBennett | apt-get source fio ;) | 19:38 |
| dyfet | just did | 19:38 |
| JamieBennett | OK, the problem is in arch/arch-arm.h | 19:39 |
| JamieBennett | I know the fix for there but need to ensure that HAVE_GCC_ATOMICS and HAVE_ARM_NOP are defined properly | 19:39 |
| JamieBennett | not sure where to add the checks for them | 19:40 |
| dyfet | Ah...this is using barriers...? | 19:40 |
| JamieBennett | yes | 19:40 |
| JamieBennett | So basically I can fix that file to check for the appropriate defines but I need to setup the defines somewhere | 19:41 |
| dyfet | Hmm...this package does not use configure? | 19:42 |
| JamieBennett | no, just a makefile hence my wanting to know what is best practice | 19:42 |
| dyfet | Well, a cheap way to do it is to add it to CFLAGS in the debian/rules on a check for architecture.... | 19:42 |
| dyfet | We did that in a couple of cases | 19:43 |
| JamieBennett | oh, can you give me an example of which package does that? | 19:43 |
| dyfet | I am looking right now... | 19:43 |
| dyfet | Well, you can start with DEB_BUILD_ARCH ?= $(shell dpkg-architecture -qDEB_BUILD_ARCH) | 19:44 |
| dyfet | and then do something like ifeq *$(DEB_BUILD_ARCH), arm) | 19:44 |
| dyfet | CFLAGS += HAVE_GCC_ATOMICS | 19:45 |
| dyfet | endif | 19:45 |
| dyfet | Something like this is in boos1.40-1.40/debian/rules...though it does it through setting TOOLSET_CONFIG, but the same idea... | 19:45 |
| dyfet | (CFLAGS += -DHAVE_GCC_ATOMICS :) | 19:46 |
| * JamieBennett goes to look | 19:46 | |
| dyfet | Another example of this can be found in gmp-4.3.2+dfsg/debian/rules which is perhaps closer | 19:47 |
| dyfet | DEB_HOST_ARCH ?= $(shell dpkg-architecture -qDEB_HOST_ARCH) | 19:48 |
| dyfet | ifneq (,$(findstring $(DEB_HOST_ARCH), armel)) | 19:48 |
| dyfet | CFLAGS += -Wa,--defsym,USES_THUMB=1 | 19:48 |
| dyfet | endif | 19:48 |
| dyfet | In this case, you would just need CFLAGS += -DGCC_ATOMICS... | 19:49 |
| JamieBennett | dumb question, this adds GCC_ATOMICS to the flags but this is undesirable for all ARM architectures or am I missing some check for ARMv7 somewhere? | 19:49 |
| dyfet | Well, if the rules file is unique to ubuntu/lucid or later, then all our arm architectures are this :)...But yes, we should not do this to something meant to push back to debian unchanged | 19:51 |
| JamieBennett | agreed | 19:51 |
| dyfet | On packages that use autotools, we can test for gcc atomics, but fio doesn't have it... | 19:52 |
| dyfet | But it would also mean we have to patch configure and then regenerate it in the rules... | 19:53 |
| dyfet | For that, where autotools are used, it's best to submit the configure change upstream to the package maintainer, I think | 19:53 |
| JamieBennett | so is it best practice to add a check to the Makefile or to debian/rules in this case? | 19:55 |
| dyfet | For autotools you could use something like AC_CHECK_FUNC(__sync_synchronize) and then test on HAVE__SYNC_SYNCHRONIZE, for example... | 19:57 |
| dyfet | As to best case when not using autotools or cmake, I am not sure, I choose the rules files after several people suggested doing it there | 19:58 |
| JamieBennett | OK, I'll do it there then, thanks for the pointers dyfet | 19:58 |
| JamieBennett | plars: not at the moment, maybe for lucid+1 | 21:44 |
| JamieBennett | doh | 21:44 |
| mturquette | how do I find out which seeds are supported in roostock? | 22:10 |
| mturquette | neither --help or manpage give info. | 22:10 |
| mturquette | ah, they are dpkgs! of course. | 22:12 |
| lool | mturquette: They should be tasks; you can list tasks with taskel | 22:18 |
| lool | *tasksel | 22:19 |
| lool | (tasksel --list-tasks) | 22:19 |
| === asac__ is now known as asac_the_2nd | ||
| james_l | Does anyone know where tslib stores it's configuration information? | 23:52 |
| mturquette | lool: thanks much. | 23:55 |
| asac_the_2nd | james_l: not sure ... /etc/ts.conf ? | 23:56 |
| james_l | Not it, unfortunately. | 23:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!