asacnot using jit for mono makes compiler hit bad C code ...bails out00:19
=== persia` is now known as persia
sevenseekerhowdy, where can I obtain binaries of 9.04 for a sheevaplug?  Googling is giving me all sorts of goofy pages02:03
persiaports.ubuntu.com ought have individual packages.  No idea where to get images.02:12
persiaNote that upgrading to 9.10 will break your system on a sheevaplug, and require reinstall.02:12
sevenseekerpersia, yes thank you… I just read the 9.10 warning and was wondering if there is enough community to support maintaining a non VFP version of ubuntu02:14
sevenseekerjust now starting to research02:14
persiasevenseeker: There's a bunch of people, but not enough infrastructure.02:18
sevenseekerpersia: what does launchpad currently (if any) support?  I am new to embedded ubuntu, but have used launchpad to make packages for my ppa before02:20
persiaThis isn't the best place to talk about embedded ubuntu, because we don't do anything to make it more embedded friendly: we just do Ubuntu on armel.02:21
persiaMind you, many "embedded" systems are now powerful enough that this doesn't matter.02:21
persiaBut I wouldn't try to install Ubuntu on a network interface, for example :)02:21
persiaAnyway, that aside ...02:21
persialaunchpad PPAs don't suppprt armel at all right now.02:22
sevenseekeraha, good to know02:22
persia(same as powerpc, sparc, ia64)02:22
sevenseekersad I am, but still good to know, lol02:22
persiaBut Ubuntu is available for armel.02:22
persiaSo any software in Ubuntu can be used.  Adding new software to Ubuntu isn't particularly hard, but there are several ways to do it, which can be a bit confusing.02:23
persiaBut since there are already something like 20,000 software packages, most of what one needs is already there.02:23
sevenseekerI also build Alix based systems but use openwrt for that02:23
persiaUbuntu 9.04 was ARMv5t+ compatible.02:24
persia9.10 was ARMv6+vfp+ compatible02:24
persia10.04 seems to be ARMv7/Thumb202:24
persia(but it's not out yet, so no promises)02:24
persiaRumour has it that this escalation will be stopping soon.02:24
persiaSo one hopes that in the not-too-distant future, one can safely upgrade on common consumer devices.02:25
sevenseekerthat would be nice02:26
rcn-eepersia, ARM hasn't announced anything past ARMv7...  So any cortex-aX device is safe...02:26
sevenseekerthen maybe more embedded friendly sub-distros could be worked on… who knows?02:27
persiarcn-ee: So rumour has it, but I'm not privy to all conversations between all counterparties everywhere :)02:27
persiasevenseeker: Well, why do you need embedded?  Ubuntu 9.10 runs on devices with 2G storage and 256MB RAM.02:28
sevenseekerlol, you could be my 'insider' for info02:28
persiaYou could probably make it even smaller if you just did a single-purpose server.02:28
sevenseekerwell its like this… I love that 'embedded' class systems are getting faster/more ram/better/etc… but it seems like much software is just banking on this and being lazy (I know I did that previously… ok, now)02:29
rcn-eepersia, if you factor in the time between ARM announcing ARMv7 devices, product availably from silicon manufactures and gcc support..  It'll be couple years before the next ARMv+ would be out..02:29
sevenseekerbut the more tight it is the better it can use whatever system its on basically02:30
persiarcn-ee: That's my opinion as well.  I just tend to be careful when I don't have any formal statements.02:30
sevenseekernote: I have been optimizing for 2 weeks and probably am stuck mentally in that mode now02:30
persiasevenseeker: The main difference in "embedded" is usually stuff like not shipping documentation, etc.02:30
persiaThe code should be made as efficient as possible regardless of the target, for performance reasons.02:31
sevenseekerI agree02:31
sevenseekerI use EC2 for some 'stuff' and my optimization sure does save me money :) :) :)02:32
persiaThe other common "embedded" choice is monolithic static binaries.  That gets hard to maintain in a modular fashion.02:32
sevenseekerwow, yes it is02:32
sevenseekeryou mean like jffs?02:32
persiaNo, like compiling your app linked statically against glibc so that you don't have to ship as many files (because you didn't ship glibc)02:33
persiaWe (kinda) support jffs2, and I know of at least one consumer device being sold with Ubuntu on ubifs.02:33
persiaBut anyway, there's lots of optimisations.02:35
persiaSo the "bloat" is mostly docs, overhead from having lots of files, overhead from having a full package management system, etc.02:35
persiaBut flash is cheap :)02:35
sevenseekerI see, yeah that makes sense02:36
persiaSo anyway, for your sheevaplug, just stick with 9.04.  ports.ubuntu.com has lots of packages you can use.02:37
sevenseekersweet, that sounds great02:37
persiaAnd when you have a chance to get newer hardware, ask for something that is known to work with Ubuntu :)02:37
sevenseekerlol, yeah02:37
persiaAnd if rcn-ee and my speculations are correct, you should be able to upgrade that to the latest version and keep up for a while.02:37
sevenseekerwell, I am considering this summer prototyping a series of Alix boards based on full ubuntu, granted they are x86 and thus OT here02:38
rcn-eesevenseeker, one note thou too, even with an unoptimzed debian dist, the sheevaplug is still pretty quick: http://global.phoronix-test-suite.com/?k=profile&u=robertcnelson-8971-28884-2210002:39
sevenseekeris there a similar system to sheevas that is cheap and readily available that uses > ARM v5?02:39
persiaI haven't heard of anything in that form factor.02:43
persiaMost people around seem to use development boards (beagle, babbage, etc.)02:43
persiaThe Sharp Netwalker is also available, but I don't know of anyone who hosts a kernel for it that can boot 9.10 ot lucid02:44
sevenseekerthanks for the info… and the reminder, I need to try a beagleboard just for kicks02:47
sevenseekersince it won't do HD it really would not be useful for me now, but a year ago … woah nellie!02:48
rcn-eesevenseeker, with the dsp, HD'ish is possible.. "1280x720"  i have just not spent enought time getting the ubuntu side to work..  It does play video with the DSP in Angstrom...02:52
sevenseekerhmm, now THAT sounds very enticing02:53
sevenseekerthank you02:53
rcn-eesevenseeker, this was done at FOSDEM this year, 6 beagles each connected it's own display.. we are still waiting from the ffmpeg guys on how they did it.. http://hardwarebug.org/2010/02/10/1080p-video-on-beagle/02:54
sevenseekeryeah, they need to reveal that :)02:58
ograsaeed, i guess thats a bad time to  catch him (2am at his place)08:32
saeedhi ogra08:41
ograhey saeed08:41
NCommanderhey saeed!08:42
saeedI need some help with the power button on Dove DB08:42
saeedHi Michael08:42
ograericm_, ^^^08:42
NCommandersaeed: whats the issue with the power button?08:42
cooloneysaeed: long time no see08:43
saeedI want to make it trigger user space suspend and power off08:43
saeedHi bryan08:43
ericm_hey saeed, how u doing dude08:43
saeedcurrenty that button implemented as input device08:44
saeedand it reports EV_SUSPEND when pressed/unpressed08:44
saeedhi eric08:47
ericm_Saeed, maybe you want your Xorg.log.0 pasted?08:51
loolsaeed: Try xev under Xorg; do you see any event?08:56
loolsaeed: AFAIK, we expect all buttons to trigger Xorg key press events, then gnome-power-manager listens to them08:57
loolsaeed: To quickly paste stuff to paste.ubuntu.com, you might find http://people.canonical.com/~cjwatson/ubuntu-paste useful09:00
loolOr install the pastebinit package09:00
saeedcheck http://paste.ubuntu.com/373788/09:01
loolYou have evdev at least09:02
loolsaeed: Could you try running xev in a terminal and checking whether the power button triggers a Xorg keypress event?09:02
saeedxev doesn't show anything when pressing on the button09:02
lool(II) UnloadModule: "evdev"09:03
loolthat's odd09:03
saeedalso lsof /dev/input/event0 is empty09:03
loolAh the unload is for another device09:03
ograthat it configures the kbd as a mouse looks wrong too09:03
loolsaeed: Your xorg.log doesn't show any setup for event009:04
loolsaeed: So probably Xorg doesn't think your event0 is an interesting device09:04
saeedyes, I added some file to hal/fdi/policy09:05
loolI think we're trying not to use hal anymore, but straight udev09:06
loolIn the xorg-server source package, patch debian/patches/12-Add-libudev-input-hotplug-backend.diff adds this stuff09:06
ograand xinput09:06
looludev rules would look something like:09:06
loolSUBSYSTEM=="input", KERNEL=="event*", ENV{x11_driver}="evdev"09:06
loolSUBSYSTEM=="input", KERNEL=="event*", ENV{ID_CLASS}=="kbd", ENV{xkb.layout}="fr", ENV{xkb.options}="terminate:ctrl_alt_bksp,compose:lwin"09:06
ograi think we're supposed to use the xinput tool09:07
loolsaeed: Check /lib/udev/rules.d/64-xorg-xkb.rules, does it match your device?09:07
ograbut at least here i cant make it use any device09:07
ogra(instead of xev)09:07
ograwe should ask tseliot, he cares for the whole xinput stack09:08
loolThat's just xkb actually09:08
loolsaeed: I would add a ENV{x11_driver}="evdev" property to your device09:08
saeedwhere should I add that?09:09
loolsaeed: For now, add it manually to your local udev rules09:10
loolsaeed: Something like /etc/udev/rules.d/90-power-button.rules09:11
saeedat /etc/udev/rules.d/ ?09:11
loolwith SUBSYSTEM=="input", KERNEL=="event0", ENV{x11_driver}="evdev"09:11
loolBut I'm not an udev expert09:11
loolsaeed: You can raise the verbosity of udev to debug this09:12
lool/etc/udev/udev.conf use info09:13
loolsaeed: Ah I found some good examples09:14
loolsaeed: /lib/udev/rules.d/66-xorg-synaptics.rules09:15
loolThat sets ENV{x11_driver}="synaptics" and some additional options for some devices09:15
loolthe generic rule is /lib/udev/rules.d/65-xorg-evdev.rules09:15
loolsaeed: So your problem is that /lib/udev/rules.d/65-xorg-evdev.rules doesn't map your device to evdev09:16
loolsaeed: It only maps devices of type keyboard, mouse, touchscreen or touchpad09:16
loolsaeed: What intput type are you using?09:16
loolsaeed: Odd, so the generic rule should have mapped it to the evdev xorg driver09:22
loolsaeed: You probably want some udev debug to see if that gets properly assigned09:22
loolsaeed: Basically make sure that x11_driver gets set to evdev, then it becomes a xorg-server issue if it didn't load an evdev xorg driver for this device09:23
ogra(**) "Power Button": always reports core events09:25
ogra(**) "Power Button": Device: "/dev/input/event0"09:25
ogra(II) "Power Button": Found keys09:25
ogra(II) "Power Button": Configuring as keyboard09:25
ogra(II) XINPUT: Adding extended input device ""Power Button"" (type: KEYBOARD)09:25
ograthats what i have on my laptop09:25
ograso the keyboard driver should be fine for it09:25
ogras/keyboard driver/evdev driver in keyboard mode/09:26
saeedhere is the lshal part for the button http://paste.ubuntu.com/373798/09:26
ograhmm, you shouldnt be having hal installed if you run lucid09:28
* ogra wonders if that gets in the way somehow09:28
ogra(it shouldnt though)09:29
loolsaeed: udevadm info --query=all --path=/sys/class/input/event009:29
loolthis is my power button http://paste.ubuntu.com/373800/09:30
loolYou can see x11_driver=evdev09:30
* lool had a great idea before sleeping in last night09:31
saeedthe info.capabilities is just input, maybe is should be input.keyboard?09:31
loolsaeed: Yes, that's likely why the generic rule doesn't match09:32
loolsaeed: On my power buttong I have E: ID_INPUT_KEY=109:32
loolsaeed: Do you have it?09:32
loolsaeed: Ok, that's your issue then09:36
loolsaeed: Actually there seem to be two types09:37
loolOne for keyboard and one for key09:37
lool/lib/udev/rules.d/60-persistent-input.rules references ID_INPUT_KEYBOARD09:37
loolsaeed: But you basically want to set your kernel driver evdev props to key or keyboard09:37
ograare we actually sure we want gpoi mapped to Xorg at all ?09:39
loolWe're sure we want the power button mapped09:39
ograright, but that doesnt necessarily need to happen with evdev09:39
loologra: What do you propose?09:40
ograespecially for gpio ... i.e. look at lirc which uses gpio buttons09:40
ograit doesnt have much useful stuff, but definately doesnt use evdev ... all we need is to capture the gpio even somehow and make g-p-m aware through devkit-power09:41
loolsaeed: I checked the ACPI power button implementation, and it does: input->evbit[0] = BIT_MASK(EV_KEY);09:42
loolset_bit(KEY_POWER, input->keybit);09:43
ograthough the devkit-power rules dont seem to have anything useful in them regarding buttons09:43
loolsaeed: drivers/acpi/button.c:39509:43
saeedok, I'll try that09:43
loologra: Can use your lirc device to power off?09:44
loolcooloney: WRT LP #516352, did you also cherry-pick the commit removing the file on package removal?09:47
ubot4Launchpad bug 516352 in linux-fsl-imx51 (Ubuntu) "fsl-imx51: need backport module.builtin to .31 kernel for lucid userspace compatibility (affects: 1)" [Medium,Fix released] https://launchpad.net/bugs/51635209:47
loolcooloney: 69f2227cdca42c4bbaa6fc931e64385f7fdee38f09:48
* ogra hates reconnects09:48
ogralool, /lib/udev/rules.d/95-keymap.rules has what we want09:48
ografor example ENV{DMI_VENDOR}=="Acer*", ATTR{[dmi/id]product_name}=="Extensa*", ATTR{[dmi/id]product_name}=="*5210*|*5220*|*5610*|*5620*|*5720*", RUN+="keymap $name 0xEE screenlock"09:48
ogra(see the RUN part)09:48
ograsaeed, do you see any events in dmesg if you press the button ? preferably with a keycode ?09:48
cooloneylool: oh, i just cherry picked 2 .32 patches to .31 kernel as we discussed before09:49
loolcooloney: You might want the above SHA too09:49
loologra: What you're pointing at is for extra keys on laptop keyboards09:50
ogralool, yes09:51
ograwell, keymapping for buttons not used by X09:51
loologra: The mvl-dove driver doesn't need any specific rule IMO09:51
ograyou want a low level power key event09:51
loolWe just need to have the power key device using the proper class09:51
ograwhich isnt mapped atm09:51
loolI don't think that's needed, no09:51
ograwell, as i understood it already emits an event09:52
ograits just not mapped to power09:52
loologra: As you can see in the Xorg log, the device is not seen by Xorg at all09:52
ograwhy should it be seen by Xorg at all ?09:52
loolWhile on your system and mine it is09:52
ograyou want a power event from the kernel09:52
loolYou want a keypress event09:53
ograwhich you likely already get09:53
ogra<saeed> currenty that button implemented as input device09:53
ogra<saeed> and it reports EV_SUSPEND when pressed/unpressed09:53
ograif there is a keycode emitted too a rule will just map it properly09:54
loologra: Try it out09:54
cooloneylool: do you mean this "UBUNTU: [Config] armel -- cleanup to-be builtin modules", right?09:54
loolcooloney: No, I mean UBUNTU: Add modules.builtin.bin to prerm rm list09:55
loolcooloney: Try installing and removing a fsl-im51 kernel package, you will see that a file is left behind09:55
loolcooloney: (modules.builtin.bin)09:56
saeednow xinput show the gpio device09:57
loolsaeed: Wee09:57
saeedxev shows nothing when pressing on the button09:57
saeedthanks lool09:57
ogralool, * include modules.builtin in the binary debs ?? that one ?09:57
loologra: I don't understand what you're commenting on09:58
ograyour discussion with cooloney09:58
loologra: Your comment doesn't make any sense in the discussion09:58
cooloneylool: ok, got you, i just recall that this patch is from you, right?09:58
loolsaeed: You need to have the proper flags when sending the event too09:58
loolsaeed: Specifically, it needs to be a key event09:59
loolcooloney: It is from me indeed, which is why I recall it09:59
loolcooloney: It should go together with the modules.builtin backport/cherry-pick you're doing09:59
cooloneyyeah, i noticed that, thanks for reminding me10:00
cooloneybut the SHA on my side is 48d7349bbc9e47a27c74cdb3e56bbcc92d9bab2910:00
cooloneyroc@roc-desktop:/opt/git/Ubuntu/lucid$ git show 48d7349bbc9e47a27c74cdb3e56bbcc92d9bab2910:01
loolcooloney: You're right, it's 48d7349bbc9e47a27c74cdb3e56bbcc92d9bab2910:01
cooloneycommit 48d7349bbc9e47a27c74cdb3e56bbcc92d9bab2910:01
cooloneyAuthor: Loïc Minier <lool@dooz.org>10:01
cooloneyDate:   Wed Feb 3 05:32:45 2010 +000010:01
cooloneyUBUNTU: Add modules.builtin.bin to prerm rm list10:01
cooloneyBugLink: http://bugs.launchpad.net/bugs/51658410:01
ubot4Launchpad bug 516584 in linux (Ubuntu) "modules.builtin.bin not removed on package removal (affects: 3) (dups: 1)" [Undecided,Fix released]10:01
loolcooloney: Must be a copy-paste error, sorry10:01
cooloneylool: ok, cool. I will cherry pick that to my branch10:01
ograwhich was included already10:01
cooloneylool: no problem, thanks a lot10:01
* ogra really wonders what you guys are discussing here10:01
cooloneyogra: oh, really?10:02
ogralook at the imx changelog, apw usually includes the package fixes frim the linux package10:02
loologra: It's certainly not in the git log of the fsl-imx51 branch10:03
loolBesides, it needs to be adapted to apply on debian.fsl-imx51/ anyway10:04
loolcooloney: I checked the fsl-imx51 and it still needs fixing10:05
cooloneyogra: lool is right.10:05
loolcooloney: debian.fsl-imx51/control-scripts/prerm, @files_to_remove10:05
ogralool, because there was never a modules.builtin.bin until recntly in imx5110:05
apwyep i missed that one when i pulled fsl-imx51 togther10:05
loologra: And there is one now, because it was cherry-picked10:05
cooloneyi need to cherry pick that patch with others10:05
ogralool, right, since the very last upload10:05
ograwhich i pointed to before10:05
loolI wonder how many people it takes to convince ogra that I'm right10:05
cooloneyoh, guys, no problem,10:06
cooloneyi will fix that soon,10:06
apwits in mvl-dove as part of the rebase10:06
loolcooloney: thanks; not a big deal anyway10:06
loolJust a leftover file, but it causes a warning on package removal10:06
apwnot in fsl-imx51 cause its a franken kernel10:06
cooloneyapw: right, because mvl-dove is .32 based anyway10:06
loolapw: Do you have some script to adapt the debian.foo/ pathname when doing these rebases?10:06
apwyep, cooloney get it to me soon :)10:06
apwlool, nope, just use vi on the patch10:07
loolhehe ok10:07
loolapw: Would it be much work to turn on udebs for versatile?10:07
loolI'm sure that's something you'd be excited about  :-)10:08
apwwhat the heck would we want those for10:08
apwi am sure the aa's would love a heap of more binary debs to wave though10:08
loolapw: I don't know for mobile team, but I'd love to point people at debian-installer images to install Ubuntu in qemu10:08
loolapw: That would allow providing just vmlinux on ports.ubuntu.com10:09
looland a d-i initrd10:09
apwthe work is not normally in eanbling them but in getting the result to pass the d-i pass afterwards10:09
apwif you don't have all modules built10:09
loolapw: something like http://ports.ubuntu.com/ubuntu-ports/dists/lucid/main/installer-armel/current/images/dove/ but for versatile10:09
loolapw: Ack; the work would probably involve adding some Provides to the binary package10:10
* cooloney is vi on the patch file as apw said. heh10:10
loolapw: Because a lot of modules are builtin in the versatile config10:10
apwloads of ?'s to be added and you have to build it to find out which ones10:11
loolapw: The d-i side of things is just commented out for versatile BTW; it's well supported in d-i10:11
loolapw: Right10:11
loolsomething like that10:11
loolapw: Currently, if we want to pull the official kernel for versatile from lucid, we have to download a .deb and unpack it to get to the vmlinuz file which allows running qemu10:12
apwi have no objection to udebs or not, they arn't a big bit of the build10:13
loolSo having d-i images would allow people to use them for install, and would also make it easier for e.g. rootstock to pull a kernel10:13
loolapw: I'd love that10:13
loolapw: Do you want me to check formally whether there are objections/interest in that from the mobile team?10:13
loolOk, mailing ubuntu-mobile@10:14
cooloneyapw: i found lool's patch can not apply to debian.fsl-imx51 directory,10:19
loolapw: FYI I just tested the in archive linux-image-2.6.32-13-versatile_2.6.32-13.18_armel.deb and it boots fine with lucid and karmic userspace10:20
cooloneyapw: it does not have the whole line 'modules.alias.bin modules.dep.bin modules.symbols.bin' at all10:20
loolcooloney: You don't have .bin files with your fsl-imx51 kernel?10:21
loolapw: (I mailed ubuntu-mobile@)10:21
* cooloney wants to punch his head to the wall, messed up his board.10:23
cooloneyi need to reinstall my lucid on my board now10:23
apwcooloney, then have a look at the debian.master version of that file10:31
apwthere is another patch which pulls the other two in you need as well10:31
apwcooloney, ironically it was your first patch i think10:33
apwcommit 8b453930465c15f490ea44c2987b0a1bfe71ed6610:33
apwAuthor: Bryan Wu <bryan.wu@canonical.com>10:33
apwDate:   Wed Mar 25 17:31:26 2009 +080010:33
apw    UBUNTU: Add 3 missing files to prerm remove file list10:33
apwcooloney, so you need that commit copied over first, then lool's one10:35
cooloneyapw: that is a good memory for me10:41
cooloneyapw: will do it soon10:41
apwwhenever man10:41
saeedI changed the button to send EV_KEY instead on EV_PWR10:54
saeednow I see message "Failed to suspend" (hibernate)10:55
saeedI'll change the code to KEY_SLEEP instead of KEY_SUSPEND10:55
loolsaeed: Great10:57
loolsaeed: Where do you see the message?10:57
loolsaeed: Are you running gnome-power-manager?10:57
saeedI think it failed to hibernate because the resume  param was wrong10:58
loolsaeed: drivers/acpi/button.c uses KEY_POWER for ACPI_BUTTON_TYPE_POWER, so that seems correct10:58
loolsaeed: Ack10:59
loolsaeed: And it uses KEY_SLEEP for ACPI_BUTTON_TYPE_SLEEP; it doesn't use KEY_SUSPEND11:00
saeedoh, hibernation is disabled11:00
loolsaeed: Yeah, you certainly don't want KEY_SUSPEND11:01
saeedlook, we are looking for the folowing behavior11:02
saeedif button pressed for less that 3 seconds , the system enters standby mode11:02
saeedothewise we want the system to shutdown11:03
loolsaeed: Ok; so you would send KEY_SLEEP for < 3 secs and KEY_POWER otherwise11:03
saeedthat means driver change, right?11:03
loolsaeed: Oh you would like to implement the 3 secs in userspace?11:03
saeedbtw, lucid keeps showing the "failed to suspend" again and again11:05
ogralool, bug 520028 ... what was the reason for dropping ubuntu-minimal ?11:19
ubot4Launchpad bug 520028 in project-rootstock "ubuntu-minimal doesn't build correctly for karmic (affects: 1)" [Undecided,New] https://launchpad.net/bugs/52002811:19
ograiirc a patch from you dropped it11:20
ogra(though if its really upstart being at fault, there should be a hard dep)11:20
saeedguys, the suspend works fine now11:42
saeedhowever I wish ubuntu show message that the system going to suspend to ram11:43
saeedthe rules file not needed of course11:43
ograsaeed, /var/log/pm-suspend.log should have something11:45
saeedogra: here it is root@lucid-dove:~# cat /var/log/pm-suspend.log  Initial commandline parameters: Tue Jan 11 21:19:32 CST 2011: Running hooks for suspend. /usr/lib/pm-utils/sleep.d/000kernel-change suspend suspend:success. /usr/lib/pm-utils/sleep.d/00logging suspend suspend:Linux lucid-dove #200 Thu Feb 11 13:34:59 IST 2010 armv7l GNx Module                  Size  Used by              11:51
saeedhere it is http://paste.ubuntu.com/373887/11:51
ograue Jan 11 21:19:33 CST 2011: performing suspend11:52
ograthats the actual suspend11:52
ogra/usr/lib/pm-utils/sleep.d/000kernel-change resume suspend:success.11:52
ograTue Jan 11 21:19:48 CST 2011: Finished.11:52
ograis the final wakeup11:52
saeedogra: I was expecting gui  message telling that the system going to suspend11:53
saeedbecause it takce few seconds to do that11:53
ograusually the screen fades out immediately11:53
saeedlool, eric, I see this kernel message when pressing on the button:11:54
saeedkeyboard.c: can't emulate rawmode for keycode 14211:54
=== jiteshs is now known as jitesh_afk
ogranetbook-launcher is on the screen after 35 sec :)12:34
persiaThat's getting close to boot speeds I find acceptable in my laptop.12:35
persiaWhat's the suspend/resume delay?12:35
ograi think if jockey wouldnt run all the time in the background we'd get another 5 sec speedup12:35
ograsuspend takes a while to process the scripts, resume is instant12:35
persiaDon't we need jockey?12:35
ograwe will need it once we have 3D drivers12:36
ograthe prob is that its *scanning* permanently due to a bug12:36
persiaThat's extra nice.  On my netwalker, I get about 2 seconds suspend and 3 seconds to resume (which Sharp advertises as a "3-second boot")12:36
ograi think suspend takes rather five here12:37
persiaWell, I mean, really.  How often to people actually boot.  Even my laptop only gets booted for kernel updates.12:37
ograbut resume is just up after pressing the button12:37
ograprobably 1sec12:37
persiaThat's nice.12:37
loolsaeed: I'm glad it works  :)12:38
loolsaeed: Did you try emulating the power key as well?12:38
loolsaeed: Will you do this in kernel?12:39
loolsaeed: Concerning the feedback on suspend: a) some devices blink the power led in the kernel, and b) the suspend is supposed to be so quick that you don't need feedback, right?   :-)12:39
saeedI didn't try the power key12:39
saeedin karmic the system enters standby immediately12:41
saeedusing echo mem > ..12:41
saeedregarding the power key,  it's easier for me to do it kernel, but I'm not sure if this is the right way12:42
loolsaeed: I would think that an userspace hack wouldn't get upstream either12:59
loolsaeed: IMO it's a device design problem13:00
loolsaeed: This is going to be in a physical device for which the user experience is going to be "this button can do multiple things"; the button is going to be labelled with or more icons depending on what it does13:00
loolIn another design you would have two buttons13:01
loolSo I don't know whether you're trying to do a generic device design or whether you're trying to demonstrate shutdown and suspend with a single button on a particular design13:01
loolIt's hack either way, but it's really related to your hardware layout13:01
persiaWhat's the goal again?13:02
loolThe kernel can send events for either a power or a suspend button press13:03
loolsaeed would like a shutdown to happen if pressed more than 3 seconds and a suspend otherwise13:04
persiaBut on what does that depend, in terms of user experience.13:04
persiaAh, yeah, that needs to be a kernel thing.13:04
persiaI'd hope additionally for a hardware shutdown if the key is held longer.  At least I use that on my Netwalker.13:04
persia(because sometimes software hangs)13:04
persiaSo HW differentiation for whether hold > 10s, and kernel differentiation for whether hold > 3s.13:05
persiaBut again, why bother shutting down with a button?  Is it that frequent a use-case to turn a device off?13:06
loolsaeed: Or alternatively, call your key "User button 1", send your own event and keycode and write a tool to handle it   ;-)13:07
persiaUm, in that case, just use the power button.13:10
persiaWe already have software that can take a power button event and perform various actions, which could be extended to meet the timing case.13:11
loolIt might be simpler to have another software handle a timed key press and call into gpm rather than patching gpm13:11
lool(and easier to maintain/less intrusive)13:11
persiaI guess.  I just don't like to have too many special HW hacks.13:12
loolWhich is why I'd prefer having it separate13:12
loolinstead of running the hack in gpm13:12
persiaI'd rather enable a use case for a broad spectrum of HW, and have the HW produce something that works with existing software, to preserve user choice.13:12
loolYou can always remap the key in software if you want13:13
persiaRight, that would be the special HW hack: "If you have this board, you need to remap your keys like this: ..."13:13
loolWell you're proposing to patch GPM to have a mode "If this hardware is detected and button is pressed more than n seconds, do something else"13:14
persiaAdding a fork function for timing in g-p-m would enable this class of behaviour for arbitrary HW which didn't expose a sleep button (and there's lots of that)13:14
loolI'm proposing to have a separate software which doesn't have the "if you have this hardware" and if people want to replace the software to use gpm, they can either patch gpm or remap thier keys13:14
persiaNo.  I'm proposing that g-p-m be patched to be able to have different actions happen for different timing delays in power button presses.13:14
persiaNo special HW detection.13:14
loolI don't think that'd fly13:15
persiaWhy not?13:15
persiaI have hardware for three different architectures that doesn't have sleep keys.13:15
loolWe'd have to run and maintain the patch for everybody instead of maintaining a single isolated trampoline13:15
persiaWhy wouldn't the patch go upstream?13:16
ogradmart, i remember you filed a bug once on building the kernel with thumb2 but i cant find it on LP, do you happen to remember the bug number ?13:16
loolWell that's my opinion that's it's too specific13:16
loolUpstream mught have a different opinion13:16
persialool: How specific.  Like I said, I have HW for three different architectures with no sleep button, and none of it is saeed's HW.13:17
loolpersia: For instance, why do it for the power button and not the sleep button?13:17
persialool: No reason at all.  Generalisation is good.13:18
loolThen you also need some GUI, more GUI == more confusion13:18
dmartogra: can you remember what it was about?  I don't remeber filing a bug on Thumb-2 kernels yet.13:18
persiaUsers with both power and sleep would be able to get to all of shutdown, hibernate, suspend, and screen-lock.13:18
ogradmart, well, that the kernel should be built with thumb2 (not the config option but the kernel binary being a thumb2 binary)13:19
ograi know we reviwed that in dallas and i thought it resulted in a bug you filed13:19
persialool: My basic point being that the utility you describe would simply not work for any of my hardware without a sleep button.  To me, this is HW-specific.13:19
dmartogra: I don't think I filed a bug.  It's not required that we build the kernel in Thumb-2, but we can try it if you think we're ready.13:20
dmartogra: I think it is a config option actually13:20
ogradmart, well, apw seems to just research that13:20
apwyep ... 'we' have a sprint in a half hour on this stuff right?13:21
ograhaving smaller kernels surely helps speed up the boot13:21
ograapw, thats more about porting packages :)13:21
ogranot sure kernel packages were meant there :)13:21
apwlinux was listed, i noticed when i read the announcements13:21
dmartogra: Bear in mind that there may be platform-specific drivers with assembler code, so it might not all work out of the box.  I would hope that there's not much of that however.13:22
dmartMost of the assembler is in the general arch/arm code though, and that should be OK in the lucid kernel versions.13:22
loolpersia: Technically you could make the utility I describe listen to power button instead and disable GPM13:25
persialool: That would address all of my concerns :)13:28
loolI filed lp #520465 on the qemu/linux/eglibc/glib2.0 issue13:59
ubot4Launchpad bug 520465 in ubuntu "armel/versatile: glibc detected double-free or corruption (!prev) (affects: 1)" [Undecided,New] https://launchpad.net/bugs/52046514:00
* asac waves14:00
loolIt's not a priority for me, but it would be nice to fix it for lucid14:00
* ogra is here14:01
ogralool, its a priority for me to be able to use the archive kernels though14:01
* ogra subscribes14:01
* JamieBen1ett waves back14:02
ograah, armel is subbed already, good14:02
asacdmart: dyfet: StevenK: persia: ping ;)14:02
dmartHi there14:02
* persia will be about 10 minutes late14:02
asacpersia: ok. please read the backlog then ;)14:03
asacanyone else here for the porting sprint?14:03
persiaAlways :)14:03
dyfetdealing also with replacing a furnace this morning :(14:03
asacwhat is a furnace?14:03
* asac goes for dictionary14:03
dmartbig firey thing14:04
asacdyfet: so you cannot attend?14:04
dyfethttp://en.wikipedia.org/wiki/Furnace :)14:04
ograoven :)14:04
dyfetNo I can...14:04
dyfetJust annoying distraction ;)14:04
dyfetand a bit cold this morning ;)14:04
dmartWhile we're waiting for persia, people might want to pull up https://wiki.ubuntu.com/ARM/Thumb2PortingHowto14:04
asacthat should be fine ... our excersizes will make you feel hot i am sure ;)14:05
persiaNO reason to wait: I'm loosely about, just distracted for another 5 minutes or so.14:05
ogradid anyone notify any MOTUs ?14:05
asacwe announced it on mobile14:05
ogragiven the univers list is HUGE14:05
ograi doubt many MOTUs read mobile14:06
asacand on internal list14:06
dmartogra: may not be an issue for the first pass14:06
asacogra: we can spread the news to wider forum for the next time14:06
dmartPartly I want to know what else needs to be documented14:06
looldmart: The first pass is not enough to fix all bugs?   ;-)14:06
asacwe have https://wiki.ubuntu.com/ARM/Thumb2PackageReviewList14:06
dmartlool: well, obviously, if you're feeling energetic ;)14:06
ograasac, definately should be announced on ubuntu-motu@ next time14:06
asacwhich should give us a decent amount of work14:06
asacogra: well. i usually dont hunt in random territory ... we could also have it announced on -devel14:07
asacwhich most motus are subscribed to too14:07
dmartWhat's the best way to do this?14:07
dmartI suggest we pick one package from the list and all take a look, and discuss.14:07
asaci suggest that dmart takes the lead ;)14:07
ograeither way i dont expect that our litle crew manages all these universe issues14:07
asacso boost stuff is already done14:07
asacdmart: maybe we can go by topic?14:08
asace.g. today focus on "mov" issues?14:08
dmartThat was going to be my suggestion14:08
dmartany ideas about which one?14:08
=== lool changed the topic of #ubuntu-arm to: Thumb2 bug squashing party | https://wiki.ubuntu.com/ARM/Thumb2PackageReviewList
asacok lets pick a first mov one14:08
* asac checks list14:08
ogramono ! :)14:09
asacfirst in list is djvulibre14:09
dmartmaybe start with something simple?14:09
dmartdjvulibre looks like it was a simple one14:09
* ogra wasnt serious with mono :)14:09
asacok everony get the source ;)14:09
asacso how do we find the right places?14:10
ogragrep ?14:10
dmartmono comes later :)14:10
asacdjvulibre-3.5.22$ grep -r mov * | pastebinit14:11
dyfetand mono jit? :)14:11
asacguess that grep can be tweaked14:11
JamieBen1ettso is this a mov only problem or does that include mov's such as movq?14:12
ogragrep -R " mov " * ?14:12
JamieBen1ettgrep -R "mov " *14:12
JamieBen1ett7 occurances14:13
persiaSo we're just looking at ZPCodec.cpp and MMX.cpp14:13
dyfetAnd GThreads.cpp?14:13
persiaCan we ignore MMX.cpp, under the assumption that we're not going to take that codepath for HW that doesn't declare MMX?14:13
* persia doesn't see GThreads.cpp from ogra's grep.14:13
JamieBen1ettso no mov's that use the sp14:13
JamieBen1ettsorry pc14:14
asac grep -r mov.*pc *14:14
asaclibdjvu/GThreads.cpp:                    "mov%?\t%|pc, %1"     // branch to address %114:14
* dmart was distracted, back now14:14
=== lool changed the topic of #ubuntu-arm to: Thumb2 bug squashing party | https://wiki.ubuntu.com/ARM/Thumb2PackageReviewList | https://wiki.ubuntu.com/ARM/Thumb2PortingHowto
asacso the GThreads.cpp seems to be right match?14:15
asacdmart: ?14:15
dmartTo find the occurrences, it's probably a good idea to look at the original grep list14:16
dmart(linked from https://wiki.ubuntu.com/ARM/Thumb2PackageReviewList)14:16
dmartGThreads.cpp is indeed the location of the hit we got.14:17
persiaSo GThreads is the only issue, and we can ignore ZPCodec.cpp as well?14:17
dyfetasac: it's a mov pc, someregister op...a candidate for bx?14:17
asac grep djvulibre *14:17
asac ./djvulibre-3.5.22/libdjvu/GThreads.cpp:                    "mov%?\t%|pc, %1"     // branch to address %114:17
asacpersia: only stuff that messes with "pc" is relevant from what i understood14:17
dmartdyfet: would you like to suggest a fix? ;)14:17
dyfetWell, it may not expand to a simple fix because the actual mov might be a movl, etc...14:18
dyfetThe closest relevant fix might be using a string constant, and maybe #ifdef (___ARM_ARCH_4T__) || defined (__ARM_ARCH_4__)14:19
dyfet#define ARM_MOVPC "mov%?\t%|pc, %1"14:19
dyfet#define ARM_MOVPC "bx%? , %1" ???  well, its hard to say how this expands exactly14:20
dmartWhat did you mean by movl?  This doesn't mean anything to me (at least for arm)14:21
dyfetSorry, I meant the mov may not be for pc since it seems like some conditional substitution....thats why I am uncertain14:21
dmartoooh, that's a new one on me.  What does %? do in gcc asm?14:22
dyfetYea that is what I was wondering...14:23
dmartA good first step could be a stick a #error in there and build (since the code depends on -DCOTHREAD_UNTESTED, which might not be defined in our build?)14:23
ograAT&T Code ... heh14:24
asaci dont see anything about %?14:24
dmartcan't find it; maybe it adds the right AT&T operand size suffix.  That wouldn't apply to ARM, but then %? is only present in the ARM version.14:25
asacyeah. lets ignore that14:26
dyfetThen I think the simplest case is we want effectively a "bx %1"...14:26
asacthats the obvious idea14:27
asacwhat does the |pc mean?14:27
dmartDunno!  I'll see if I can find out from anyone here.14:28
asacits probably %|14:28
dyfetasac: I read the original as effectively reducing to "mov pc, %1" but yea, I wondered about that too14:29
dmartIt might be the case that GCC can substitute condition codes for %?14:29
dmartbut it's no documented if so14:29
dyfetBut is it even a valid code path?  Its tied to COTHREAD_UNTESTED being defined...14:29
dmartI think the best thing iintially is14:29
dmart#ifdef __thumb__14:29
dmart#error "Needs porting to Thumb-2"14:30
dyfetYes, lets see if it even builds that path first :)14:30
dmartIf this doesn't ftbfs, then someone can worry about it later :)14:30
dyfetdmart: agreed14:30
asacdyfet: ok want to create the diff for the file ... and i just upload ;)?14:30
dyfetwell, we have the other mov's to look at too :)14:31
asacwe will see if it fails then in a bit14:31
asacdyfet: that was the only mov14:31
dmarthold on14:31
* asac waits14:31
ogradyfet, only "mov, pc"14:31
dyfettrue....but then if its not explored, there must be another reason for the ftbfs :)14:32
asacdyfet: it currently ftbfs?14:33
dmarthmmm, guess we should look at the log14:33
dyfetAnd since the end of it reaches a #error if none of the paths are explored, it has to be here...but yes, let's look at the log14:33
persiadyfet: I don't see it at http://qa.ubuntuwire.com/ftbfs/14:33
asacdmart: right. i wanted dyfet to produce that ... but ok ;) ... let me upload14:34
persiaUm, should we not try a local build first to make sure that fixes it?14:34
ograpersia, queue is empty14:35
JamieBen1ettpersia: its not a fix, its just a warning in case that code path is taken14:35
dmartdoing one, but it may take some minutes14:35
dyfetI am going to try a local build quickly...14:35
JamieBen1ett(or so I understand)14:35
ograwe can play with the buildds unless they are busy14:35
=== JamieBen1ett is now known as JamieBennett
persiaJamieBennett: Right: it's that I don't tend to like to generate lots of archive churn when it might fail :)14:35
dmartOur first priority is to get everything building and working in lucid.  Fixing code paths which are not built is nice to have, but putting a #error bomb is a reasonable way of helping ensure it gets fixed at the appropriate time14:36
dyfetdmart: I think that code path has to be built, otherwise it would fall into a default #error after that section14:36
dmart...unless the package is built with -DTHREADMODEL=NOTHREADS14:37
asacok can we use a pastebin != ubuntu?14:37
dyfetHmm...we could also do that :)14:37
persiaasac: Why?14:38
asacthats just annoying. you cant wget the plain text because of openid14:38
dmartany suggestions?14:38
asacjust pastebin.com14:38
* persia thought that was fixed, but tends to have trouble parsing other pastebins14:38
looldmart: debian's work14:38
loolalias debian-paste='pastebinit -b http://paste.debian.net'14:38
asacevery pastebin works ... just paste.ubuntu.com is broken14:38
lool\o/  :)14:38
asaci already kicked #is for that ... seems they didnt listen14:38
* asac does that again14:38
loolpersia: It got fixed and borken a couple of days later sadly14:38
loolasac: It was fixed for a day or two14:39
dmartI don't know the answer to thathttp://paste.debian.net/59542/14:39
persiaThat's one I can parse cleanly :)14:39
asacdmart: thanks. i did it manually now14:40
dmart /bin/bash ../libtool --mode=compile g++ -DHAVE_CONFIG_H -I.. -I. -Wall -g -O2  -pthread -DTHREADMODEL=POSIXTHREADS      -c GThreads.cpp14:41
dmart g++ -DHAVE_CONFIG_H -I.. -I. -Wall -g -O2 -pthread -DTHREADMODEL=POSIXTHREADS -c GThreads.cpp  -fPIC -DPIC -o .libs/GThreads.o14:41
dmartIn file included from DjVuMessageLite.h:74,14:41
dmart                 from GThreads.cpp:76:14:41
dmartGString.h:745: note: the mangling of 'va_list' has changed in GCC 4.414:41
dmart g++ -DHAVE_CONFIG_H -I.. -I. -Wall -g -O2 -pthread -DTHREADMODEL=POSIXTHREADS -c GThreads.cpp -o GThreads.o >/dev/null 2>&114:41
dmartFile seemed to build OK14:41
persiaSo we conclude that this code path is never exercised, and just leave the comment as a note?14:42
asaci uploaded the patch that would catch it for __thumb__14:42
asacthats ok imo14:42
persiaAs it turns out, yes :)14:43
dmartIf it's considered OK to add #error (provided it's for a case we know definitely won't work)14:43
asacwe should upstream that or suggest the right way ... e.g. bx14:43
dmartyes, it might be a good idea to make the comment clearer14:43
asacdmart: i think for cases where we cant try the code path its ok to use #error ... otherwise we should obviously fix it14:43
ogranext package ?14:44
persiaI'm perfectly happy to use #error as a base of test builds, and if we don't hit the code path, replace with a useful comment.14:44
ogragmp seems small14:44
dmartProbably worth discussing this one a bit further first14:44
dmartpersia: Why is a comment (which will go unnoticed) better than #error (which won't)14:45
ograwell, what if we hit it and have no solution ?14:45
asaci think #error is fine. we should upstream that so they know14:45
ograhope for upstream ?14:45
dmart#error potentially saves someone a lot of debugging14:45
asacogra: we would have a solution. but we cant test it because the code is not used14:45
persiadmart: I want *both* the comment and the #error : the #error to force it not working if the codepath is hit, and the comment to tell someone why we added that patch.14:45
asacso should we add something untested? or just ad an error14:45
dmartOh, OK.  Yes adding extra explanation in a comment is of course a very good idea :)14:46
asacpersia: right. thats what we did14:46
asacwe can improve the comment on next one though14:46
asac+#ifdef __thumb__14:46
asac+#error "This code needs some porting to work correctly in Thumb."14:46
asacmaybe point to the porting page14:46
dmartgood idea14:46
asacanyway. lets move on14:46
asacgmp ;)14:46
dmartSince djvulibre is a simple example, I think it's worth discussing how we would fix it (if we needed to)14:46
dmartSomeone suggested bx14:47
dyfetdmart: yes :)14:47
ogradyfet, did14:47
ogra#define ARM_MOVPC "bx%? , %1"14:47
dmart... so far so good, but it's worth taking a step back and looking at the context of this code so we are sure we're doing the right thing14:47
dyfetWell, I was not sure what the %? was about....but essentially something like that...14:48
asac                    "mov%?\t%|pc, %1"     // branch to address %114:48
asacso it uses that to branch to %1 ... which is .... hmm14:48
dmartI _think_ we could pretend the %? is not there.  I can't think of anything vital that it would do.14:48
dmartbut best not to alter that aspect of the code in the fix in case it matters14:49
dmartscrolling up a bit14:49
dmartstatic void14:49
dmartmach_start(mach_state *st1, void *pc, char *stacklo, char *stackhi)14:49
dmartScrolling up a bit more, mach_state contains a jmp_buf14:50
dmartSo this looks like a long jump / thread starting function if some sort.14:50
dyfetYes, a funny kind of procedure call to start a thread....14:51
dmart%1 is the argument pc, which is just a pointer14:51
dmartBut it's not a function pointer which is slightly suspicious14:52
dmart...because it could be passed a pointer to some data (containing run-time generated code)14:52
asacdmart: its a func pointer14:52
asacjust not declared explicitly14:53
asacmach_start(&st1, (void*)th2relay, stack, stack+sizeof(stack));14:53
asacvoid th2relay() {14:53
dmartcertainly that's the likely case --- I was just going to suggest seeing how it's called, but you beat me to it :)14:53
asacand pc is the second argument14:53
asacok lets grep for mor mach_start ;)14:54
asacthe other is startone14:54
persialine 95014:54
asacwhich is also a func14:54
asacpersia: right. thats the function where the asm code is in14:54
asacwe are looking for callers now to see if its always a func14:54
asacso ... based on that is bx %1 still the right thing?14:55
dmartAfter a couple of examples, we can be reasonably confident, since passing a function is certainly how we would expect a thread start func to be used.14:55
dmartbut I just wanted to highlight the issue14:56
dmartOh, btw:14:56
dmart%? - condition code used only in conditional execution.14:56
dmart%| - some kind of register prefix and legacy assemblers. Largely irrelevant today.14:56
dyfetit was a good educational example :)14:56
asacdmart: where did you find that?14:56
dmartUm, our tools guys here ;)  I'll try and get it merged in the docs if it's not upstream14:57
asacok good. so are we confident enough to replace the error with bx %1? or want to keep the error as its not used?14:57
persiaI think we should keep the error, but maybe add a comment suggesting bx %1 : we can't test the codepath, so we have no way of knowing if our solution works.14:58
dmartbefore that, I was going to talk about what would happen if we were passed a data pointer here14:58
persiaGiven that it's already uploaded, I think we should leave it alone.14:58
dmartMaybe someone wants to guess?14:58
asacdmart: bad things14:59
asacdmart: trying to call in data memory14:59
dmartBut what if the data is code?  Maybe the caller created a trampoline sequence.  (GCC does this internally for some things)14:59
asacthen it just runs that code?15:00
asacor is there some protection stuff going on?15:00
dmartwell, you need to synchronise and data and instruction caches and flush the pipeline, so that the code executed is what you wrote.15:00
dmartThis is what the GCC builtin __clear_cache is for (look at the docs)15:01
dmart...however, this is not a Thumb-2 specific issue, so we would not expect to need to fix that if it already worked in ARM.15:01
asacoh cool. so i assume those steps are generated at each "real" function started by gcc?15:01
dmartWell, the kernel always does this when paging in an executable page15:02
dmartSo for the text sections of programs and libraries, you never need to worry.15:02
dmartOnly self-modifying code or programs which generate code at runtime need to be concerned about this.15:03
asacok good info. thanks15:03
asacok move on to gmp?15:03
dmartThere certainly were some packages like that in the list...15:03
dmartstill wanted to make one more point:15:03
asacerlang was marked as "potentially creating code"15:03
asacsure go ahea15:03
dmartJITs, VMs, interpreters etc. should be treated with extra care for these reasons.15:04
dmartanyway, a non-Thumb aware program which generates code an runtime probably generates ARM instruction encodings (not Thumb)15:04
dmartSuch packages may need extra attention.  Especially if the generated code may be called by other random (probably Thumb-2) code, or calls out to other functions (also probably Thumb-2) ... it's unlikely to work out of the box15:06
dmartAnyway, enough on that for now, until we find a real instance ;)15:06
asacmaybe mono ;)15:06
asacok so gmp?15:07
dmartGoing back to the suggestion of how to fix djvulibre15:07
asacendles story it seems15:07
dmart(I know, nearly finished!)15:07
asac(but good to have all details first)15:07
dmart... we're just trying to jump to a passed function pointer15:07
* persia likes the long explanation, having not much prior understanding15:07
* ogra too15:08
dmartI thought this would be a good idea --- the wiki page has lots of details, but may not be so easy to understand as an example15:08
dmartAnyway, BX <register> is definitely the right way to do jump to a function pointer where we don't expect to return.15:09
dmartSo adding a comment to this effect would be a good idea, something like15:09
dmart /* instead of "mov pc, <register>", "bx <register>" should be used on ARMv5 and above */15:10
asacok let me add that too and upload ... next time i will wait longer ;)15:11
persiadmart: No need to apologies.  asac is just impatient :)15:11
dmartI'm sure I can think of something else to add when you're done ;)15:11
dmartWe could add the wiki link for completeness15:12
asac#ifdef __thumb__15:12
asac/* instead of "mov pc, <register>", "bx <register>" should be used on ARMv5 and above */15:12
asac#error "This code needs some porting to work correctly in Thumb: https://wiki.ubuntu.com/ARM/Thumb2PortingHowto"15:12
asacthats what i have now ;)15:12
asacare we happy with that?15:12
dmartcool, looks good15:12
persiaSeems sufficiently complete.15:12
dmartOf course, it might have been quicker just to fix it :P  but it helps to educate more people this  way.15:12
asacitsw really good ... especially since i know that at least persia is eager to work on these things ;)15:13
persiadmart: The risk with fixing it is that we can't test the code path, so we have no way to know if the "fix" worked.15:14
* dmart spies a volunteer15:14
* persia doesn't really know assembler, and will be slow, but willing15:14
dmartagreed, it's better not to commit anything we can't test15:14
dmartonly joking15:14
asacdyfet is definitly a senior volunteer ...15:14
* asac goes with persia 15:14
asacso thanks. do we want to look at a second package now?15:15
dmartGenerally best to stay out of assembler as much as possible (it would certainly make this porting job easier)15:15
dmartYes, if people want to grab that I'll just fetch a quick cuppa15:15
dyfetwell, in gmp, we have a function return in mpn/arm/copyi/d.asm, and in udiv.asm we find mov pc, lr also...at least to start with :)15:15
JamieBennettmov's in copyd, udiv and copyi15:17
* JamieBennett goes to get a coffee15:17
ogracopyd.asm looks like a copy paste job from the wiki :)15:18
dyfetand copyi.asm...15:18
ograyeah, its the same15:18
ograall three actually15:19
asacso who wants to prepare a patch suggestion?15:19
asacfeels like its exactly as on the wiki ;)15:19
dyfet#ifdef  __thumb__15:20
dyfet    bx  lr15:20
dyfet    mov pc, lr15:20
asacdyfet: on the wiki it uses something else for ifdef15:20
asac#ifdef (___ARM_ARCH_4T__) || defined (__ARM_ARCH_4__)15:20
dmartThese are not C files15:20
asac"bx     lr"15:20
asacoh right ;)15:20
dmartSeparate assembler files are a bit of a different animal15:21
asachow annoying15:21
dyfetYes, that's right...15:21
ograyeah, no ifdef i guess ?15:21
asacwhats the best way to do this if we dont want to do a full copy?15:21
dyfetwell, unless you want to use cpp in front of it, ogra :)15:22
dmartFor assembler files which are preprocessed by the C preprocessor (.S) you can use ifdef in the normal way15:22
dmartBut it looks like these are processed by m415:22
dmartSo we probably need to get a configure argument passed in somehow15:22
dyfetAnd then use a .ifdef, .else,.endif15:24
* dmart knows nothing about m415:24
* asac_ had to clone himself15:24
dmartAssembler macros could work as you suggest15:25
dyfet.ifdef  thumb2_config_from_config.m4...15:25
dyfet    bx  lr15:25
dyfet    mov pc, lr15:25
dyfet as a starting point....15:25
dmartBut there are no magic predefined macros in the assembler to tell you what your build target it.15:25
dmartyep, something like that15:26
dyfetYes, so we have to feed it into one of the included files which are generated....15:26
dmartOr maybe you could have a common macro somewhere else15:26
dmart.macro return register:req15:26
dmart        .ifdef <blarg>15:26
dmart                bx \reg15:26
dmart        .else15:26
dmart        mov pc, \reg15:26
dmart        .fi15:26
dmartAnyway, that should work15:27
dyfetthat too would be a good idea....15:27
dmartExactly how to create the configure argument, I'm not sure15:27
dmartYou could preprocess some C with #ifdefs to check the architecture version and look at the output, e.g.15:28
dyfetwe have to see how config.m4 is created since it includes it...15:28
dmart#if defined(__ARM_ARCH_4__) || defined(__ARM_ARCH_4T__)15:28
asac_has GMP_INIT15:29
asac_i think there are various options ... not sure we should discuss them here15:30
dmartAgreed, I think everyone understands what's needed.15:31
dmartOnce we've done this once, we can reuse the solution if it's needed again.15:31
dyfetlets ask this, is there any other porting issue in gmp other than the mov instructions?15:31
dmartgood question --- we should always take a careful look at any assembler which pops up15:31
asac_"uses mov; also "add" assumes arm"15:32
asac_thats the comment we had from review15:32
dyfetyes....thats why I asked :)15:32
asac_what does add assumes arm mean? dmart ?15:32
dmartI meant "assumes it's running as ARM instructions and not as Thumb instructions"15:32
dmartThere's a bit more info on this on the wiki page at PC and "." arithmetic and position-independent addressing15:33
dmartBut in brief, when you read pc in Thumb, the result is not that same as you'd get if you were executing in ARM.15:34
asac_ok so we are looking for add.*pc here?15:35
asac_mpn/arm/invert_limb.asm:addr2, pc, #invtab-.-815:35
dmartThat's the one.15:35
dmartIn ARM, when you read PC, you (usually) get the address of the current instruction + 815:35
dmartSo this trick gives you the address invtab in r215:35
asac_whats the right way to find a good offset?15:36
dmartBut in Thumb, pc is different.  You get <address of current instruction> + 2 or 4 (depending on the alignment of the instruction in memory)15:36
dmartIt is possible to work out the correct offset, but ugly15:37
dmart...and you need #ifdefs or other special cases hacks for ARM versus Thumb15:37
dmartFortunately, the assmbler can do it for you15:37
dmartThere's a special pseudo-op to get the address of a nearby label in the text section:15:38
dmart        adr <reg>, <label>15:38
dmartThe assembler actually assembles15:38
asac_yeah ... finally found it on porting page ;)15:38
dmart        add (or sub) <reg>, pc, #<magically determined offset>15:39
asac_so we use adr r2, #invtab ?15:39
dmartIt's not usual to have the # (it might be a syntax error)15:39
dmartbut otherwise, that's correct15:39
dyfetyes...and no conditional...15:40
dmartThis is a really old assembler feature, so it ought to be possible to make the change and upstream it as-is15:40
asac_so adr would work on arm too?15:40
asac_feels like15:41
dmartYes, the only thing that changes is how the offset is worked out15:41
dmartA couple of things to watch out for:15:41
dmartadd <reg>, pc, #label - . - 8 is a special case which maps directly to addr15:42
dmartIf the code actually tries to skip the first word after label, e.g.15:42
dmartadd <reg>, pc, #label - . - 415:42
dmart...you'd need to take this into account:15:42
dmartadr <reg>, label + 415:42
dmartBut really, the best thing to do is to create another explicit label in the right place and reference that directly.  It's harder to break, that way.15:43
asac_so here we have:15:45
asac_add     r2, pc, #invtab-.-815:45
asac_invtab is a label with short data stuff15:45
asac_so after that we have the address of the invtab first short in r2?15:46
asac_or is that not what its supposed to do?15:46
dmartYes, I think it wants the address of the first short (i.e., the address of the label invtab) in r215:47
dmart(the previous point I made doesn't apply here, but might apply elsewhere)15:47
asac_so given we already have a label ... just adr r2, #invtab feels ok15:47
asac_but you said its rather adr r2, invtab ?15:47
dmartyes, that should work15:48
asac_what does #invtab mean? maybe it means "relative"15:48
asac_e.g. you add the relative distance of that label to what is currently on pc15:48
asac_ - 815:48
dmart# is just required syntax in some cases, generally before a numeric constant.  Best not to think about it actually meaning something.15:49
asac_oh right. now i remember about the constant15:49
dmartA point to make about out-of-line assembler files15:50
dmartas does not default to assembling Thumb code15:50
dmartSo this code will be assembled as ARM15:50
* asac back here15:50
asachmm. so you say its all ok? or we should fix the build system to use thumb2?15:52
dmartIt's actually fine for bits of ARM code to exist, so long as they return in the right way (this is what we were talking about earlier), and so long at they are called in the right way.15:52
persiaIs there a reason we shouldn't change the default?15:52
dmartpersia: we did investiate, but changing the default is not really supported and breaks too much stuff15:52
dmartIn any case, Thumb-2 helps to reduce code size, and that's a bit different from speed optimisations.15:53
dmartIf we only built 90% of the codebase in Thumb, that would still give us most of the overall code size benefit.15:54
persiaMakes sense.15:54
dmartSo "if it's not broke, don't fix it" is probably the best policy15:54
asacok ;)15:54
asacso we can scratch most code that is in ssembler15:55
dmartyes and no15:55
dmartWe still need to be a bit vigilant in places, depending on how the code is used.15:55
dmartSuppose we had some assembler code which accepted the address of a callback as one of its arguments?  The callback might be the address of a Thumb-2 function15:56
dmartSimilarly we need to return to the caller in the right way (using bx)15:57
dmartIn this case, these look like leaf functions which are called from C (and don't call any other functions), so we just need to make sure the return is correct15:58
asacok that makes some sense indeed15:58
dmartThis is why we particularly grepped the archive for things like mov pc, <something>15:58
dmartThis is the classic way to do the equivalent of calling a function via a pointer in C.15:59
asacso i dont see this asm snippet returning16:00
dmartWhich bit?16:00
asacwell. i dont see how to check if it returns properly according to what you have said16:00
dmartAh, good point -- I should explain this one16:01
dmartTo jump to a value in a register, you can use mov pc, <register>, or preferably bx <register>16:01
asacyes. thats what happens on the caller side i guess16:02
dmartCould be, though there's a special procedure call instruction BL <label> (branch with link) which is more likely to be used in that case, as long as the location of the label is known at compile time (usually)16:02
asacok. so do we jump back ;)?16:03
dmartIt magically sets the link register (lr) to the correct return address16:03
dmartSo what happens to that in this function?16:03
dmartIt gets saved on the stack at the beginning:16:04
dmart                stmfd   sp!, {r4, lr}16:04
dmart"STore Multiple Fully Descending {r4 and lr} at sp and update sp"16:05
dmartOn x86 we would say "push"16:05
asacok so we have the lr on stack16:05
asacand then we jump back like:16:05
asacldmfd   sp!, {r4, pc}16:05
dmartIndeed, this is the "pop", and we can restore the pc at the same time to get back where we started.16:06
asacwhat is r4 used for?16:06
dmartYou might wonder why we don't need to change this to support thumb, whereas the other cases needed a BX16:06
ograyes, i was wondering that16:07
dyfetyes...me too16:07
dmartOn ARMv4T (the earliest version of Thumb), this was indeed necesary.  You had to:16:07
dmart      pop {r4}16:07
dmart      pop {r0}16:07
dmart      bx r016:08
dmart(or something like that)16:08
dmart...because BX was the only way to switch instruction set16:08
dmart...However we don't need to worry about this: from ARMv5 onwards, all the "load pc from memory" instructions switch instruction set as needed, provided that the bottom bit of the return address was set to the right thing.16:09
dmartSo as long as the call side was done right, we're OK16:09
asaccan you explain to me why r4 is involved at all in these things?16:09
asacstmfd   sp!, {r4, lr} -> ldmfd   sp!, {r4, pc} ?16:09
asaci would think that its just sp + lr ... and then sp -> pc16:10
dmartr4 is saved because it's used in the function16:10
dmartThe procedure call standard required you to restore some registers if you change them16:10
dmartgcc assumes you play nice when generating the code for C functions16:11
asacoh ... now i see16:11
asacbtw, whats a good arm asm reference?16:11
dmartGenerally, only the first argument of an instruction is modified, so you might expect to see r4 at the start of some instructions, but there is none.16:11
asacsome handy online resource would be great ; )16:11
dmartOh, I tell a lie, there is         addcs   r4, r4, #116:12
dmart(looks up a documentation link)16:12
asacaddcs   r4, r4, #16:12
asacanyway. i guess there is a special instruction that also modifies r4?16:12
asacotherwise you wouldnt have started like it ;)16:12
dmartYes, I was trying to be clever...16:13
dmartumull ("Unsigned MULtiply Long") produces a 64-bit result, and so it has two output arguments:16:13
dmart        umull   lr, r4, ip, d16:13
dmartbah, our documentation portal seems to be down, but I'll post a link to the ABI docs when I have it16:14
dmartIn brief though:16:14
dmartIf you clobber r4-r11 you need to restore them (and obviously sp needs to be the same as it started off to balance the stack)16:15
dmartNowadays the stack is supposed to be kept 64-bit aligned, so you might want to check for pushing odd numbers of registers.16:16
dmartIn fact, new code may uselessly save an extra register to achieve this:16:16
asacregisters are 32?16:16
asacor different?16:16
dmartThis is only required if you call other functions16:16
dmartBasically, gcc is allowed to assume that the stack is 64-bit aligned at the entry of every function, and ensures that this is still true when calling functions.16:17
dmartIs assmbler code, you need to be careful not to mess up this assumption.16:17
dmartFinal point: is the assmbler code used at all?16:18
dmart(should have asked this at the beginning ;))16:18
* dmart touches those files and rebuilds16:21
dmartOK, it looks like that code is used16:21
asacgmp-impl.h:    (invxl) = mpn_invert_limb (xl);     \16:21
dmartI wondered if this was ancient optimised code which is no longer used (and a C implementation might have been used instead)16:22
dmartThis is the case in some of the packages on our list (like zip where there's some old code that was written for RiscOS)16:22
asaci dont see an alterantive impl for that16:22
asaci would assume its used ;)16:22
asacso ok. for gmp we have two things:16:23
asac1. fix mov in the .asm files (special casing using m4)16:23
asac2. fix the invert_limb thing to use adr rather than add16:24
asac2. only if we build with thumb16:24
asaci think we said we are ok to keep it "arm"16:24
dmartThat's true, though since we've spotted it it might be worth fixing anyway, since it's cleaner and won't trap someone trying to migrate this code to Thumb-2.16:25
dmartBut I'm happy either way.  If we don't fix it we could still add a comment.16:25
asacright. so on top of 2. we need to switch the AS to thumb mode16:26
asachow is that done?16:26
dmartMy recommendation is: don't bother16:26
asacok -mthumb16:26
asacdmart: so fix it, but dont switch?16:26
dmartWe could, of course, if it turns out to be easy16:27
asacright. lets first fix code. and then see if we can switch as easily16:27
asacif not, leave it alone16:27
asacsince dyfet seemed to be fluent on the m4 stuff i will assign the bug to him ;)16:28
* lool attacked the qemu-kvm armel ftbfs16:28
dmartIf you really want the assembler in Thumb, you need to use assembler directives in the files.16:29
asacok updated bug16:29
dmart-mthumb doesn't really do what we want in this case (as interprets the code as Thumb-1, which means most code written for arm will fail to build anyway)16:29
dmartI'll try to add some details about this on the wiki16:30
asacok thanks16:30
dyfetin this case we are concerned more with performance than size16:30
asacbut having all thumb2 ready would be nice16:31
dmartOr ftbfs -> crash -> performance -> size16:31
asacok. so we didnt get much done, but i think it was a good start16:31
asacthanks dmart ;)16:31
asaci would like to take a break before the call we have in 3016:32
ographew ...16:32
asacfeel free to continue though16:32
asaci think ogra dyfet and co are happy ;)16:32
dmartI think we did enough for today - it was really just to introduce people to the issues16:32
dmartI'll try to hang around on IRC, so if in doubt please ask :)16:32
asaci think it made sure we we are all getting started16:32
dyfetasac: I have to deal witht the furnace people for a little bit, but yes, I think it was an excellent start16:32
* ogra notices that there are not many leftovers of the asm he once learned a decade or more ago :/16:33
asacdyfet: ogra: persia: StevenK: maybe read the porting wiki carefully to get more detailed info. should be easier to read now we got the intro ;)16:33
dmartogra: Sort of; more that there's a lot of new stuff though16:33
dmartcomments welcome - it's not 100% complete and was written in a hurry16:34
dmartI will dump the log of this conversation on the wiki (in advance of tidying it up)16:34
asacgood idea16:34
ogralool, can you reestore the topic ?16:35
dmartthanks everyone16:36
ograthanks a lot dmart !16:37
dmartI'll talk to asac offline about arranging another sprint sometime soon - then people could have a go at porting packages and we can discuss together as needed.16:38
persiaI was just taking a look at insighttoolkit as a potential task, as there's a number of rdeps and rbuilddeps.  It seems to use "mov pctemp, eax" : am I correct that this is a likely false positive hit?16:38
* lool passed CC arm-softmmu/exec.o16:39
persia(because it doesn't seem to be branching with that instruction)16:39
persialool: Nice!16:39
loologra: Is the sprint over?16:39
ogralool, congrats !16:39
ograyes, it is16:39
dmartlool: yes, we'll wrap up for now16:39
=== lool changed the topic of #ubuntu-arm to: Ubuntu ARM Discussion & Development | https://wiki.ubuntu.com/ARM | Want to Submit a Bug? https://bugs.launchpad.net/ubuntu/+filebug | Debian ARMel TODO: http://wiki.debian.org/ArmEabiTodo | Build a rootfs from scratch: https://wiki.ubuntu.com/ARM/RootfsFromScratch | build probs with your packages in lucid ? see https://wiki.ubuntu.com/ARM/Thumb2
* dmart wonders how to alert everyone on the channel16:40
persiadmart: alert them to what?16:40
dmartEnd of the session.16:40
dmartI guess changing the topic works OK16:40
persia /topic changes are usually sufficient, yes.16:40
dmartfair enough16:40
* lool channel-wide alert16:41
looldmart: Mind taking a look at http://paste.ubuntu.com/374082/?16:42
loolI built arm-softmmu/qemu-system-arm under armel successfully with it16:42
* lool now attacks a full build16:42
dmartpersia: your mov pctemp, eax in insighttoolkit is almost certainly a false positive.  ARM and x86 both have a "MOV" instruction, but eax is an x86 register name (arm reg names are always two letters, or r<number>)16:42
dmartlool: what package it that? qemu?16:43
looldmart: qemu-kvm, but this patch is against qemu tip16:43
dmartoh, right16:43
persiadmart: Thanks for the confirmation.16:43
* persia goes to look for something else16:43
dmartlool, so spin_lock makes use of testandset ?16:44
looldmart: Yes16:45
dmartLooks sensible to me... I guess the code is already tested on other SMP arches16:45
dmartlool, should the typedef for spinlock_t be volatile int?16:46
loolI just tested building, and then only on armel; I think I'm going to apply it to lucid's qemu-kvm and if that works ok, I will submit it upstream16:46
looldmart: The other typedefs aren't, but I tend to agree that it would be a good idea16:47
dmartI think the GCC atomics do the necessary, but I guess it won't hurt to make it volatile16:47
* ogra would actually like to see someone running qemu-system-arm under armel ... heh16:47
looldmart: It doesn't make any difference in practice because these are only written to once to init them16:48
loole.g. spinlock_t tb_lock = SPIN_LOCK_UNLOCKED;16:48
dmartThe atomics write them, but it probably doesn't have to be volatile for that to work16:48
loolAck; I'll submit this as a separate patch when I upstream gcc atomics16:49
loolHopefully it wont take another two months   :-/16:49
dmartFor anyone still listening, the procedure call standard and other ABI docs for ARM can be found on16:51
dmartBrowse to RealView software development tools -> Application Binary Interface -> Procedure Call Standard for the ARM Architecture (etc.)16:52
persiaOnly saeed left :)16:55
persiaSo, the next one I picked (lwp) seems to only have "mov pc, r0" in a .S file.  We decided to leave those alone, because they are going to end up as armel instructions anyway, right?16:56
loolI have a funny error17:04
lool/home/ubuntu/qemu/qemu-kvm-0.12.2/fpu/softfloat-native.c:373: error: impossible constraint in 'asm'17:05
loolThe code is: http://paste.ubuntu.com/374093/17:05
persiaAnd float_relation_* are essentially constants?17:07
loolI guess17:09
loolIt's technically possible to reach float_relation_unordered for some float numbers such as nan17:10
ogralool, btw, i think amitk said ppoll pselect are upstream now17:10
ogra(in mainline)17:10
looland I'm adding a patch to stop them from barking17:11
loolI wonder whether we should just backport this stuff instead17:11
ograjust quieting it or implementing them ?17:11
* ogra doesnt mid either since there is a properl fallback in libc afaik17:11
ogra(referring to your patch)17:12
loolIt's just very noisy right now17:12
ograyep, i rarely see that, rootstock hides such stuff17:12
ograbut in chroot tests its annoying, i agree17:13
loolIt's not trivial to backport the pselect6() impl17:21
loolIt depends on at least two other commits17:21
loolgit cherry-pick is broken for me for some reason17:29
loolIn fact git is completely borken hmm17:31
ogrause bzr ... i always told you :)17:36
* ogra hides17:36
=== jds is now known as Hoonse
Hoonsei am back =)17:37
Hoonsehi guys17:37
loolI'm failing at backporting it because *it's already in*17:40
loolDoes someone have a rough idea of how long it takes to boot dove lucid?17:50
* ogra can only give numbers for imx17:52
ograits roughly after 40sec at the full desktop17:52
ogra(netbook-desktop that is)17:52
Hoonsei think i will make the rootfs new... what do i have to add to --seed when i want the gnome gui and not the xfce4?18:00
ograHoonse, depends, full ubuntu would be ubuntu-desktop18:03
ograi think an upstream plain gnome flavour was only added in karmic18:03
sijihi ogra,18:03
ograthat would be gnome-staciatella then iirc18:03
Hoonsethanks.... ok this will be a long time AGAIN for waiting till the script is finished =)18:04
ograwell, upgrade your host to karmic ;) its way faster18:04
Hoonsefor what projects do you all use the BeagleBoard?18:04
* ogra doesnt use a beagle ... its collecting dust on the shelf18:04
Hoonsebut you bought it for a reason? or just for the reason to collect dust =)18:05
ograi got it handed by somebody18:06
Hoonsewell i think this is an awesome piece of hardware...  the best since the microkopter project...18:07
ograit is ...18:09
Hoonseorga: guess what... today i also installed the wireless-tools and the network-manager... =)18:25
persiaHoonse: So everything is working for you now?18:32
persiaarmin76: ?18:32
loolsuihkulokki: I'm looking at linux-user/syscall.c, and see I'd need to add some copy_from_user_timespec and to_user and pselect would very much be like select; I find macros would be a bit long and ugly, and real functions would add a small performance penalty, do you see a way we could share the code yet keep it readable and fast?18:40
loolsuihkulokki: Also, is it ok to unconditionally use the hosts' pselect or do I have to check whether it's available and support arches where it's not?18:51
zumbilool: is this croco?18:51
loolzumbi: It's just qemu-linux-user19:00
loolNot specific to croco19:00
loolcroco rocks, I need to resume working on its integration19:01
loolJust haven't taken the time19:01
zumbiyes :-)19:03
zumbiit rocks! time is always the problem19:03
MeizirkkiHi all19:20
MeizirkkiIs the Karmi ffmpeg NEON accelerated?19:21
MeizirkkiOr is there a specific ppa for it ?19:22
armin76Meizirkki: its not19:23
MeizirkkiI heard there was ppa with NEON accelerated ffmpeg somewhere ..?19:23
jdsis there a special command line "sentence" for autologin on ubuntu (no username and password type in)19:24
=== jds is now known as Hoonse
persiaHoonse: Depends on the desktop environment, but there's usually a way to select autologin from the greeter control tool.19:25
Hoonsexfce4 is the desktop enviroment...19:26
MeizirkkiNCommande, were you dealing neon wccelerated ffmpeg ?19:26
Hoonseoh sh.. it seems that the network-manager isnt happy with my WEP key...19:27
=== bjf is now known as bjf-afk
Meizirkkilool ?19:33
Meizirkkidid you have the ppa containing ffmpeg w/ neon optimizations?19:34
Meizirkkiarmin76, does the lucid version have neon acceleration ?19:48
armin76Meizirkki: ubuntu doesn't nor will use neon afaik19:52
Meizirkkiok, thanks19:54
Hoonseis it normal that network manager takes reeeaaallllyyy long to connect to a wifi network and a few times shows up the question about the wep key when always entered?!?20:03
Hoonseomg this sucks... -.-20:09
loolasac: oo.o works again on armel??20:56
loolWhen was that fixed?20:57
loologra: Do you know?  ^20:59
ogralool, it still carries the hack21:01
loologra: thanks for confirming21:06
loolYou guys have any recent bootchart on armel hardware?21:17
ograhttp://people.canonical.com/~ogra/babbage2-lucid-20100211-3.png netbook launcher is up after ~40sec21:17
ograwell, visible after about 3521:18
ogradisregard the panel and stuff, there are applets missing so its starting delayed atm popping up errors21:18
loologra: that's with SD?  or SATA rotational hard disk?21:21
amitkogra: ppoll is upstream in 2.6.3221:29
NCommanderarmin76: ping. Is OOo known to work on Gentoo with ARMv6/ARMv7 optimizations?21:32
suihkulokkilool, huh?21:36
suihkulokkiNCommander: do you plan to fix OOo build on gcc 4.4?21:36
ograsuihkulokki, he does :)21:36
NCommandersuihkulokki: I'm going to take a stab at it :-)21:36
loolsuihkulokki: Sorry, context was implementing pselect in qemu/linux-user21:36
NCommandersuihkulokki: I fixed thunderbird. This codebase can't be much worse21:37
* NCommander feels like those might be famous last words21:37
ograNCommander, its just way bigger  ... and the issue is in uno21:37
NCommanderogra: right, I'm reading through the channel logs from that era to remember the detials21:38
suihkulokkilool, unconditional should be ok, the kernel will just give a err if not supported21:38
ograwell, it should be supported across the board now21:39
loolOk; I was wondering whether it was ok to require recent linux-headers21:39
loolbut pselect is old indeed21:39
loolsome platforms might not have it, I wonder whether it's in the headers in this case21:39
suihkulokkiNCommander: I think OOo is worse ;) good luck, that fix would be appreceated.21:39
NCommandersuihkulokki: I assume its also broken in Debian?21:40
NCommandersuihkulokki: does building with gcc 4.3 fix the issue? (just for a reference point)21:40
ograNCommander, yes21:40
suihkulokkiNCommander: yes. iirc it was a binutils rather than gcc issue21:41
ograits clearly a toolcahin issue21:41
NCommanderogra: right, I'm just getting up to speed. I was working on Thunderbird during most of the OOo fun21:41
loolAs I personally recall, we realized that downgrading both binutils and gcc helped, but when we bisected binutils we found another bug which ended up not fixing oo.o21:43
loologra: well it could be an oo.o issue too21:44
looloo.o is using some quite special toolchain API and has a copy of some unwind headers stuff, it's really an awfully complex piece of code21:44
ogralool, i doubt it, but it could be indeed21:44
loologra: The code which crashes in openoffice is the one converting C stacks to uno stacks21:45
loolso it's very low-level stuff21:45
loolAnyway we'll see21:45
suihkulokkiiirc the toolchain people were suggesting it is OOo issue21:45
suihkulokkiit was mentioned on debian list21:46
NCommandersuihkulokki: debian-arm?21:46
loolI think so as well21:46
* NCommander probably should subscribe to that :-)21:46
loolIt might be that oo.o has to be updated in lockstep with some very deep toolchain API21:46
suihkulokki NCommander that or debian-release21:47
ograNCommander, you should definately be on debian-arm (and if its only for seeing the shiny new netbook stuff they are discussing there :) )21:48
NCommanderogra: I was on d-arm, I think I accidenlty unsubscribed myself when I purged out mailing lists I didn't read anymore21:49
asacNCommander: your call ;)21:49

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!