=== zz_chihchun is now known as chihchun [02:51] anyone know if any of the -M options for qemu-system-arm support more than 1 nic? === chihchun is now known as zz_chihchun === AmEv_ is now known as AmEv [04:00] Hmmm... I wonder if it's the command line messing things up... === zz_chihchun is now known as chihchun [07:26] good morning [09:04] hey, I have deleted a tar file and I want to recover it. I'm using scalpel. I need to specefy the header of a ".tar" file, but I have no idea what it is.. [09:10] anyone knows how to discover the header of a file like a tar file [09:16] sim590: "discover the header of a file"? [09:16] sim590: What are you actually trying to accomplish? [09:18] I want to find my deleted tar file [09:18] on my disk [09:19] I have to add something like this in the configuration file of foremost [09:19] pdf y 5000000 %PDF- %EOF [09:19] where "pdf" is the extension [09:19] "y" is for case sensitive [09:20] and I also need to specefy the header [09:20] but I don't know what the *"!(/&*$ it is :D [09:21] I want to do this for "tar" file [09:21] # POSIX tar archives [09:21] 257 string ustar\0 POSIX tar archive [09:21] !:mime application/x-tar # encoding: posix [09:21] 257 string ustar\040\040\0 GNU tar archive [09:21] !:mime application/x-tar # encoding: gnu [09:21] infinity: I am only a bot, please don't think I'm intelligent :) [09:21] infinity: I am only a bot, please don't think I'm intelligent :) [09:21] That's what file(1) knows about tar files. [09:22] man file [09:22] ok [09:22] sim590: apt-get source file && cd file-* and browse around magic/Magdir to see what it knows about these things. [09:22] (The tar stuff is in "archive") [09:23] ok.. I'll try that thanks. [09:48] infinity: I've not found my file yet, but I understand now what you wrote after looking the files you told me. But how the hell did you think about that? Did you just know that it was in these files? :p [09:50] I did, yes. [09:52] ok lol. === Quintasan_ is now known as Quintasan === chihchun is now known as zz_chihchun [11:31] #quit [12:37] hi! I have some questions about 12.10 on pandaboard, can someone help? [12:47] therve, how would we know if you dont ask your question ? [12:48] one would wonder [12:48] I've installed from the sd card on an external SD via USB [12:49] can I make the USB bootable to remove the install sd card? [12:50] nope [12:51] you could install to the SD itself (at least in raring, not sure if all the fixes were backported to 12.10) [12:51] but the panda cant boot off anything else than SD or a special USB OTG setup that requuires a second PC [12:52] well I don't want to boot via USB [12:52] thats a HW limitation [12:52] I have a SD card plugged in a USB card reader [12:52] can I make the USB bootable to remove the install sd card? [12:52] oh, ok [12:52] sorry I meant the SD used in USB right now [12:53] well, if you have the exact same partitioning for the vfat partition, you chouls be able to just dd the contents from one card to another and swap them [12:53] s/chouls/should/ [12:54] * ogra_ glares at his fingers [12:54] hum [12:54] the panda needs a vfat partition in the beginning of the card and that needs to have all the bootloader stuff in it [12:55] ok I see [12:55] sounds like something doable, maybe by installing on a SD with the boot vfat ready [12:56] right [12:56] cool, thanks [12:57] the other question I had was about graphic support/video playback [12:57] is there anything I can check to make sure I have the proper drivers enabled? [12:57] duplicate the SD (write the image to both cards) then only delete the second partition but leave the first one intact ... after install dd the partition from one card to the other [12:57] with 12.10 the drivers are oreinstalled and used from the beginning [12:57] *preinstalled [12:58] I'm asking because it feels pretty slow, so I was wondering if that was expected [13:52] Anyone has made the sound work on the TF101 under ubuntu with lilstevie's kernel? I've red a wiki speaking about this, but I don't know how alsamixer works.. I don't know where to find the "playback" and DMIC option [13:53] http://forum.xda-developers.com/showthread.php?p=25608362&highlight=sound#post25608362 -> A guy says he makes the sound work, but the playback thing.. Idk [14:28] orientation and backlight testing app for the nexus7 http://people.canonical.com/~jani/a [14:29] to be ran with DISPLAY=:0 set if via ssh and with sudo [14:29] it's a static executable , the golang source is https://code.launchpad.net/~jani/+junk/nexus [14:34] janimo, wow, without kernel tweaks ?!? [14:34] ogra_, well, apparently everything was there already [14:34] yay [14:34] just hidden in sysfs [14:34] i wish the backlight control would be there too [14:35] the device is so bright it hurts my eyes after a few hours [14:35] ogra_, well this app has backlight control [14:35] oh, wow [14:35] bt probably needs some tweaking [14:35] ah, i see the code, yeah [14:35] I did not see it workin gonly starting with andorid 4.2.1 [14:36] and seeing it works there it made sense to look harder at where it is exposed [14:36] for a while I thought it simply is not working at all [14:36] but I need to ask around how to best integrate these in some daemons and control center [14:36] i looked at the sysfs stuff for quite a while already, but only played with echoing stuff into the respective files [14:36] which always failed with write errors [14:36] to have nice UI for it and non extra daemon running [14:37] right, some files are read only or einval [14:37] yeah [14:37] birghtness is the only knob that should work [14:37] but it's enough for our purpose [14:38] the x input bugs are still annoying though, I think I'll have another go at those [14:39] after a rotation or two or a few minutes taps are still not working [14:39] woah [14:39] the UI is really slow [14:40] (in redrawing the content rotated) [14:40] janimo, you rock ! [14:40] we should package that as a daemon with proper upstart file etc [14:40] ogra yes it redraws slowly if the axis changes [14:41] but if it's a 180 degree rotation it is really quick :) [14:41] i blame compiz [14:41] heh [14:41] I guess copying is much easier if you do not have different line lengths and can do rectangle copies [14:42] as contiguous pixels in one case are still contiguous in 180 rotation, but not with 90 or 270 [14:42] funny that onboard fully wortks while rotated input doesnt in the rest of the UI [14:42] ogra_, I'll mail ubuntu-devel for some input. While a daemon is fine I'd still rahter add this functionality to some existing plumbing daemons [14:43] not even the restore button inside firefox responds in portrait [14:43] otherwise it is yet another 1-2MB hit for our footprint [14:43] ugh [14:43] I did not test apps too much TBH [14:43] well, i doubt it is the app [14:44] but onboard works flawless, i can type in a terminal no matter what the rotation is [14:44] just saw that cursor is where it should be, but may it be some apps get confused if screen size or orientation changes? [14:44] launcher and FF dont take any taps [14:44] they do if rotated back to landscape [14:44] maybe those that do their own drawing as oppposed to using a GUI toolkit get confused when screen rotates, no idea [14:45] hmm, maybe we coudl try xrandr + firefox on x86 [14:45] oh, it was only the recovery button that didnt work [14:45] i can scroll with grab n drag in FF and click links [14:46] hmm [14:46] i can klick links but they dont get executed [14:46] (but undelined) [14:47] i guess i'll need to test that with a mouse plugged in so the pointer gets visible [14:48] janimo, why does the footprint raise so much ? GO ? [14:49] well GO - at least the official compiler - creates static executables and includes the Go runtime in them [14:49] so they are standalone [14:49] that makes the executable about 1.2 M, but runtime footprint I guess is also due to runtime bookkeeping [14:50] it's not as much as it would be in python but C (or even dash) may be leaner [14:50] heh, lux sensor seems to work fine too ... [14:50] i can use a torch and point at the camera area and the display reacts [14:50] the formula is ad-hoc, a better fit is likely possible [14:50] but its slow [14:50] yes, I used my desklamp for testing, went up to 40000 lux [14:51] passing -v shows lux and accel reading values [14:51] ah, nice [14:51] slow in reacting to it? [14:51] yes [14:51] well both accel and light are poll loops with 1s delays [14:51] my torch is a tiny LED one pretty focused [14:51] ah, thats it then [14:52] 1s seems to match what i see [14:52] i wonder if we could make it trigger uevents so you dont need to poll [14:52] there may be interrupt based interfaces for these sensors, but maybe not via sysfs [14:52] but that would indeed be kernel side [14:53] and probably still cause latency [14:53] right, eventually having triggers is better than waking up for no reason periodically [14:53] but, on android actually the lag is a few seconds [14:53] but i think thats for 13.10 ;) [14:53] so I guess it adapts once it decides this is really ambient light change and not a transitory flashlight [14:53] i'd set it to 0.5s though, will likely feel a lot smoother [14:54] maybe eve 5 seconds lag on android [14:54] a bit confusing for test purposes but for real use cases it may be better [14:54] wow, 5s is long [14:54] especially since light adjusts very seldom and incrementally [14:54] well, if you read and the sun slowly sets you don't really care about a few seconds [14:55] indeed [14:55] I think are tests are artificial [14:55] our tests that is [14:55] well, on Android 4.1, when the backlight is turned to maximum because of ambient light and then you put it to dark place, the brightness never goes down again === rsalveti_ is now known as rsalveti [14:55] so you can't really do worse than that) [14:55] Tassadar, I know my nexus did not seem to change backlight at all until this week [14:56] not sure if due to 4.2.1 (which I had before), a clean reinstall, or just me being more determined to wait for the change === chihchuno is now known as chihchun [15:07] just in case you posted it because you want someone to test it - it works for me too, but that touchscreen input in portrait orientation is really weird) [15:07] well, onboard works just fine, thats the puzzling bit [15:08] you can also drag icons in dash [15:08] right [15:08] and i can scroll firefox pages with drag'n grab enabled [15:09] links get marked if i tap them but never get executed [15:09] I can open terminal menu (the one on top bar) if I keep the finger on screen [15:11] heh, xchat copes fine though [15:11] kernel crashed when rotating the screen :x [15:12] kernel ? [15:12] how do you know ? [15:12] did you get an oops ? [15:12] http://pastebin.com/AY6Cg9R6 [15:12] it was after i managed to bug the touch input by clicking too fast [15:13] that looks like cpufreq issue ... [15:15] nothing in my dmesg, looks all fine [15:16] maybe just some rare crash [15:16] dunno which kernel does Ubuntu use as base, but 4.2 kernel is not that stable even on Android === doko_ is now known as doko [16:42] ogra_: can every Ubuntu package in 12.04 and beyond assume that NEON is supported in the hardware? [16:43] achiang, nope, NEON is not allowed at build time at all, if a binary wants to use NEON it has to have runtime support [16:43] janimo: ^^ [16:44] ogra_: interesting.... [16:44] by default all packages in the archive need to be non-NEON [16:44] achiang, what ogra said. Even if we do not have official images, people run Ubuntu on Tegra2 which has no neon [16:44] achiang: yo. [16:45] And ac100 actually had 12.04 images [16:45] qengho: hi, let me paste a bit of scrollback for you re: neon [16:45] and as long as we potentially (or actively) support something like tegra2 or armadaxp it will have to stay that way [16:45] No neon. Saw that. [16:45] ogra_, oh armadaxp too, I forgot [16:45] well, NEON, but only at runtime :) [16:45] Got it. Thanks! [16:46] qengho: is the chromium build FTBFS due to NEON? [16:46] not sure which packages have actual code for this, Qt could be and possiblly pixman [16:46] Qt does indeed [16:46] (if you want to look at code for runtime support) [16:46] ogra_: qengho is the chromium maintainer for ubuntu engineering, and he's trying to get something going for 12.04 [16:47] 13.04 mostly, but anything I can. [16:47] qengho: are you seeing a NEON-related build failure? [16:47] achiang, chromium/v8 probably works without neon too but their build system is complicated so some flags may get set inconsitently [16:47] some with neon support some without [16:47] qengho, did you talk to micahg already ? he used to do the chromium builds in the past [16:48] probably something wheer exxperience can help .... [16:48] achiang: Yes. janimo has it right. It's mostly build flags. [16:48] I also had (scarring) chromium FTBFS experiences [16:48] ogra_: I did. [16:49] qengho, the only thing I remember is flags either not being passed correctly from debian/rules or build files needed patched to turn neon off [16:50] qengho, Launchpad may still preserve chromium changelog history and you could find neon FTBFS bugs there [16:50] it may be a recurring one due to dropped patches or changed upstream build system [16:51] It's changing upstream, AFAIK, janimo. [16:51] Okay, thanks all. [16:55] Er, it looks like I might have to write a function that does what I want. What's the best way to test for NEON support programatically at runtime? === nemik_ is now known as nemik [16:56] * qengho hopes it's not "parse /proc/cpuinfo". [16:58] Oh good. Assembly. [17:00] iirc it was somewhere in /proc/self [17:01] /proc/self/auxv ? not sure [17:03] actually i'm pretty sure libjpeg-turbo has the code for runtime switching, just grep for auxv in the source [17:03] ogra_: thanks for your response about gstreamer/ti/omap some days ago [17:04] welcome [17:05] :) [17:11] ogra_: seems like I have to investigate a little bit more [17:12] well, the guys that used to maintain the TI PPA packages are still around in #pandaboard (some of them at least) they can probably tell you what happens to the PPA stuff and if anyone goes on maintaining it [17:15] ogra_: good hint, will join there and ask === yofel_ is now known as yofel [17:40] does someone have a device that lacks NEON support? I want to test something. http://pastebin.ubuntu.com/1542106/ [17:40] ogra_, achiang, ^ [17:41] I have raspberry sitting in here, if that's enough [17:41] not near me today, sorry [17:41] $ make foo; ./foo [17:41] Tassadar: Ooo, that just might! [17:41] i will have my ac100 (tegra2) around tomorrow again though [17:42] okay [17:42] what OS is on there ? [17:42] that debian wheezy they have on their download page, raspbian or whatever [17:42] you only need to test if it correctly detects the CPU, right? [17:43] it should be enough [17:43] * ogra_ isnt sure if a test on an armv6 debian rebuild is actually reliable [17:43] Tassadar: yes, just the CPU. [17:43] your kernel definitely needs hwcap support though [17:45] (or was that libc ... its so long ago i had to tinker with it) [17:45] compiled okay, says " [17:45] pi@saffron ~ $ ./test [17:45] this CPU has no NEON support. [17:45] " [17:45] Tassadar: Thanks. [17:47] qengho: i don't have a device like that near me, unfortunately [17:51] My LG P500 (~same cpu as raspberry) with debian in chroot also says "no neon support" [17:57] for a positive match,, i get proper output on the chromebook [17:57] ogra@chromebook:~$ ./foo [17:57] this CPU has NEON support. [17:57] ogra_: ah, thanks. Good data all. Thanks. [18:23] hy friend [18:24] besides cmus what applications you install === XenGi_ is now known as XenGi === XenGi is now known as XenGi_ === XenGi_ is now known as XenGi === XenGi is now known as XenGi_ === XenGi_ is now known as XenGi === XenGi is now known as XenGi_