| 14:53.49 | *** join/#maemo-ssu infobot (~infobot@rikers.org) |
| 14:53.49 | *** topic/#maemo-ssu is Maemo Community Seamless Software Update "CSSU" channel, http://wiki.maemo.org/Community_SSU | Known bugs: http://j.mp/communityssu-bugs | Channel logs: http://mg.pov.lt/maemo-ssu-irclog/ | Sources: http://gitorious.org/community-ssu/ | Latest version: Testing(2013-01-07): 21.2011.38-1Tmaemo7.2; Stable(2013-01-10): 21.2011.38-1Smaemo6 | Next meeting 06.03 |
| 14:53.49 | *** mode/#maemo-ssu [+v infobot] by ChanServ |
| 14:55.00 | *** join/#maemo-ssu Guest50382 (~rd@p57B4913B.dip0.t-ipconnect.de) |
| 15:32.28 | *** join/#maemo-ssu Milhouse (~Milhouse@Maemo/community/contributor/Milhouse) |
| 15:39.32 | discopig | hi |
| 15:54.58 | andre__ | hi |
| 16:01.12 | *** join/#maemo-ssu ivgalvez (~quassel@86.43.81.96) |
| 16:07.48 | *** join/#maemo-ssu Martix_ (~martix@eduroam-sci-dhcp67.sci.muni.cz) |
| 16:08.18 | *** join/#maemo-ssu Martix_ (~martix@dhcp-233-187.eduroam.muni.cz) |
| 16:22.38 | *** join/#maemo-ssu Woody14619 (~Woody@2620:4:4000:11:e835:757c:1fd1:ddff) |
| 16:22.38 | *** join/#maemo-ssu Woody14619 (~Woody@Maemo/community/contributor/Woody14619) |
| 16:33.08 | DocScrutinizer05 | andre__: hi! |
| 16:34.15 | andre__ | hi DocScrutinizer05 |
| 16:47.27 | freemangordon | merlin1991: ping |
| 16:54.31 | ivgalvez | hi fremangordon |
| 16:55.45 | freemangordon | ivgalvez: hi, welcome back :) |
| 16:56.02 | ivgalvez | nice to see you |
| 16:56.17 | freemangordon | ivgalvez: how's life, everything ok? |
| 16:56.27 | ivgalvez | I have destroyed my filesystem in a very stupid way |
| 16:56.40 | ivgalvez | apart from that freezing to death in Dublin |
| 16:57.27 | freemangordon | ivgalvez: ooh. I've been in Scotland a couple of times, those places are not for hot-blodied southern guys :D |
| 16:57.39 | ivgalvez | haha |
| 16:57.53 | freemangordon | moist and cold. and rabbits :D:D:D |
| 16:58.07 | ivgalvez | still getting used to it |
| 16:58.32 | freemangordon | honestly, maybe the weather is one of the major reasons I am still here |
| 16:58.42 | ivgalvez | I imagine that |
| 16:59.02 | ivgalvez | work conditions are clearly better as you go north |
| 17:00.22 | freemangordon | yep, I remember some guys in London made e meeting in pub at 15:00. Their working time was till 17:30 :D. It was Friday ofc |
| 17:03.47 | ivgalvez | one question, now that repos are finally under Maemo Council control, have you planned to move Thumb repo to the official server? |
| 17:03.58 | ivgalvez | and maybe add upload access to some developers |
| 17:04.32 | ivgalvez | there are many Thumb applications floating around the forums now |
| 17:06.44 | *** join/#maemo-ssu sunny_s (~sunny_s@86.57.254.135) |
| 17:11.10 | *** join/#maemo-ssu Martix (~martix@static-84-242-103-180.net.upcbroadband.cz) |
| 17:14.57 | Estel_ | freemangordon, I have something that might be kernel oops |
| 17:15.01 | Estel_ | not sure, so pasting syslog |
| 17:15.03 | Estel_ | http://sebsauvage.net/paste/?348922f654b9aa15#wVmtdYn6FBuXKabppB8XcqVHyZiogox2t+3aDqUKSjM= |
| 17:15.25 | Estel_ | decide yourself what it is worth, if anything, I'll be happy to helpg chasing |
| 17:15.44 | freemangordon | Estel_: what to look for? |
| 17:16.13 | freemangordon | ooh, I see |
| 17:16.27 | Estel_ | malf |
| 17:16.34 | Estel_ | and kernel-power main process terminated |
| 17:16.38 | Estel_ | with error |
| 17:16.45 | Estel_ | (exact this phrase iirc) |
| 17:16.49 | Estel_ | and dsme malf :P |
| 17:17.12 | freemangordon | Estel_: what about "EXT4-fs error (device mmcblk0p2): ext4_mb_generate_buddy: EXT4-fs: group 31: 6372 blocks in bitmap, 6374 in gd" |
| 17:17.23 | freemangordon | this is the first error in a row |
| 17:17.25 | Estel_ | ivgalvez, true, many thumb things floating around, merlin1991 is super-slow at putting them into repos (not accusing) |
| 17:17.40 | Estel_ | my filesystem got some insignificant errors in games directory |
| 17:17.48 | Estel_ | but it works nevertheless despite that errors |
| 17:18.03 | Estel_ | I'm going to fix it today, I don't think it's related (may be wrong) |
| 17:18.36 | freemangordon | Estel_: well, I guess Pali should be made aware of that, so he can pester whoever made ext4 patch in KP. |
| 17:18.38 | kerio | Estel_: i suggest a fsck -c |
| 17:18.45 | freemangordon | :nod: |
| 17:18.48 | kerio | i thought ext4 was mainline |
| 17:18.48 | Estel_ | kerio, fsck just kills flash |
| 17:19.04 | Estel_ | I mean, no fsck tools are aware how to fic anything on flash |
| 17:19.21 | kerio | no, steve jobs killed flash |
| 17:19.31 | Estel_ | any serious error (more than access time in future ot journal recovery), + fsck on flash, = filesystem to trash |
| 17:19.40 | freemangordon | Estel_: maybe you should provide your /dev/mtd2 too |
| 17:19.53 | Estel_ | freemangordon, sure, lemme paste it |
| 17:19.57 | Estel_ | erm, ois it text file? :P |
| 17:20.07 | freemangordon | not exactly :) |
| 17:20.10 | kerio | Estel_: ok then |
| 17:20.11 | Estel_ | maybe ext4 patch in kp is bugged |
| 17:20.28 | Estel_ | kerio, ShadowJK would give you technical rationale why never do fsck on flash |
| 17:20.30 | kerio | write zeroes to it, then mkfs, then do a read-only badblocks test |
| 17:20.37 | Estel_ | why not |
| 17:20.50 | Estel_ | freemangordon, so how to dump it properly? |
| 17:20.52 | kerio | otoh, sometimes file systems get fucked up |
| 17:20.54 | Estel_ | /dev/mtd2 |
| 17:20.55 | Estel_ | ? |
| 17:20.58 | kerio | or sometimes you get bad blocks |
| 17:21.25 | freemangordon | Estel_: don;t do it |
| 17:21.32 | Estel_ | ? |
| 17:21.36 | freemangordon | Estel_: that fs if FUBAR |
| 17:21.43 | freemangordon | and see "kernel: [ 317.285308] twl4030_wdt twl4030_wdt: Unexpected close, watchdog still running!" |
| 17:21.54 | Estel_ | I'll try contacting Pali, but reporting anything to him is fubar too, lately |
| 17:22.00 | Estel_ | hm, what does it mean? |
| 17:22.05 | kerio | of course it's fubar, he never does a fsck :P |
| 17:22.15 | freemangordon | Estel_: it is pointless, it is not the kernel to blame |
| 17:22.22 | freemangordon | it is WD rebooting your device |
| 17:22.30 | Estel_ | kerio, I regularly restore backups With prior-recreation of filesystem :P |
| 17:22.31 | Estel_ | ok |
| 17:22.39 | Estel_ | dsme: malf is result of this? |
| 17:22.42 | kerio | Estel_: and that means that you never keep a list of bad blocks |
| 17:22.43 | freemangordon | and if you have a couple of reboots in a row, then MALF. afaik |
| 17:22.47 | Estel_ | also, there was "hw bug" line somewhere there |
| 17:22.55 | kerio | wtf is MALF |
| 17:22.57 | Estel_ | I see |
| 17:23.01 | freemangordon | malfunction |
| 17:23.03 | Estel_ | malfunction, probably |
| 17:23.14 | kerio | what does it entail |
| 17:23.26 | Estel_ | that dsme told you to gtfo due to few reboots in row |
| 17:23.28 | Estel_ | unexpected |
| 17:23.44 | kerio | a normal boot resets the counter though, right? |
| 17:23.53 | Estel_ | yes |
| 17:23.58 | freemangordon | Estel_: I'll look at that log more closely when I have more time, but I'd say: fsck your fs |
| 17:24.10 | Estel_ | freemangordon, sure, I'll do that |
| 17:24.35 | freemangordon | Estel_: there are hundreds of "Mar 25 17:53:01 BloodRose hildon-thumbnailerd[1587]: GLIB DEBUG default - Error opening file '/home/user/.thumbnails/fail/hildon-thumbnail/6d46f0a280851e67a1f7fe65bf75a67d.jpeg': Permission denied " and similar errors |
| 17:24.36 | Estel_ | inf act tried to abckup last night, but tar, despite --ignore-failed-read, stopped at 1.8 GB and worked indefinitely |
| 17:24.52 | Estel_ | freemangordon, due to filesystem errors? |
| 17:24.54 | freemangordon | and other fs errors |
| 17:24.55 | Estel_ | I noticed that |
| 17:25.00 | freemangordon | I guess |
| 17:25.15 | Estel_ | OK, will fix my filesystem, and if problems occur again with clear fs, will get back to you |
| 17:25.20 | Estel_ | for now, scratch it :) |
| 17:25.24 | kerio | Estel_: if you have unbackupped data on that, dd it on a computer and fsck the image |
| 17:25.25 | freemangordon | ok |
| 17:25.40 | Estel_ | kerio, thought about that, will it work? |
| 17:25.43 | kerio | sure, why not |
| 17:26.05 | kerio | ShadowJK: why are you supposed to never do fsck/badblocks on the emmc? |
| 17:26.15 | Estel_ | idk, maybe dd from flash have flash madness bundled inside :P |
| 17:26.26 | kerio | the emmc isn't a fucking flash |
| 17:26.33 | Estel_ | no? then what? |
| 17:26.35 | kerio | it's a perfect block device |
| 17:26.44 | freemangordon | block device |
| 17:26.48 | Estel_ | aren't you messing it with nand? |
| 17:26.52 | freemangordon | no |
| 17:26.53 | kerio | nope |
| 17:26.59 | kerio | the rootfs is on mtd |
| 17:27.02 | Estel_ | no idea, I'm clueless about it |
| 17:27.03 | kerio | that's why you use ubifs |
| 17:27.09 | kerio | the emmc is just a block device |
| 17:27.18 | kerio | you're still supposed to try to treat it nicely |
| 17:27.20 | Estel_ | block device in flash technology? :P |
| 17:27.27 | Estel_ | but it have hardware wear levelling bundled in |
| 17:27.35 | kerio | but there's not really much you can do for it |
| 17:27.37 | ShadowJK | kerio; I think when the filesystem is designed to only deal, at best, with 512 byte chunks corrupted or missing, when fsck faces a filesystem full of data (after a crash/powerloss) in chunks for megabytes that might all be old, all new, or all corupted, it gets thoroughly confused |
| 17:28.08 | kerio | ShadowJK: what about doing a fsck -c on a brand new FS? |
| 17:28.20 | kerio | (badblocks read test) |
| 17:28.22 | ShadowJK | That wont corrupt anything |
| 17:28.23 | Estel_ | anyway in practice, everytime i tried fsck on N900 on filesystem with errors, it resulted in filesystem getting fubar as awhole |
| 17:28.32 | ShadowJK | but it's fairly pointless in my experience. |
| 17:28.34 | kerio | fsck might fail, yes |
| 17:28.41 | kerio | ShadowJK: i have at least one bad block on the emmc |
| 17:28.59 | *** join/#maemo-ssu NIN101 (~NIN@p5DD28EBD.dip0.t-ipconnect.de) |
| 17:29.32 | ShadowJK | Most SDs I've had that have had bad blocks, have happily included those bad blocks in wear leveling, so one overwrite and the bad goes away, but several overwrites later the bad block comes back, in a new location, thanks to weat leveling :)) |
| 17:29.39 | kerio | :s |
| 17:29.49 | kerio | so it's better to not write to that block, surely |
| 17:30.50 | Estel_ | ShadowJK, DD'ing partition to desktop and fscking image on hard drive should work, yes? |
| 17:31.02 | kerio | Estel_: still the same problem |
| 17:31.10 | Estel_ | ? |
| 17:31.11 | kerio | data loss on emmc is particularly bad |
| 17:31.21 | kerio | so e2fsck could still get thoroughly confused |
| 17:31.30 | Estel_ | it segfaults on maemo, too |
| 17:31.33 | kerio | but that's in case of a power loss, not in case of a write error |
| 17:31.37 | kerio | i mean |
| 17:31.41 | Estel_ | new version works ok, but cssu denied to include it, once |
| 17:31.44 | kerio | something like a driver error |
| 17:32.14 | kerio | Estel_: it's not like it's particularly useful on a running system anyway |
| 17:32.25 | kerio | rescueOS has the latest (or at least, a recent) version of e2fsprogs |
| 17:32.45 | Estel_ | kerio, excuse noobiness, but I have never used dd to save N900's partition from dance macabre, and that data is pretty important to me |
| 17:32.55 | Estel_ | how exactly command should look to prepare 100%ok image |
| 17:33.04 | kerio | boot from rescueOS |
| 17:33.05 | Estel_ | then repair it, and restore back for maemo? |
| 17:33.20 | kerio | mount in mass storage mode |
| 17:33.23 | kerio | er |
| 17:33.24 | kerio | not mount |
| 17:33.24 | Estel_ | well, I'm not going to fskc on emmc anyway, want to move it to desktop |
| 17:33.30 | Estel_ | export |
| 17:33.33 | kerio | yeah |
| 17:33.33 | Estel_ | in mass storage |
| 17:33.36 | Estel_ | I know the thrill |
| 17:33.56 | Estel_ | then, command to dd from that device, how should it look, parameters etc? |
| 17:34.12 | Estel_ | (for this use case, repairing and getting back) |
| 17:34.18 | kerio | then dd if=/dev/sd<disc letter><partition number of your home/optfs> of=optfs.img bs=4m |
| 17:34.28 | kerio | once you have that, make a copy of optfs.img |
| 17:34.35 | Estel_ | nods |
| 17:34.39 | kerio | then... idk |
| 17:34.46 | Estel_ | fsck that image |
| 17:34.51 | kerio | mount it in loopback with ro,noload and copy everything you can |
| 17:34.55 | Estel_ | see if it doesn't start fusion reaction |
| 17:35.04 | kerio | then mount it in loopback with rw and copy everything you can |
| 17:35.12 | kerio | then fsck, and mount it in loopback with rw and copy everything you can |
| 17:36.14 | Estel_ | ok, how to dd it back in place properly? |
| 17:36.16 | kerio | you don't |
| 17:36.29 | Estel_ | ouh |
| 17:36.38 | kerio | you make a tarball of the data, mkfs on the device, and unpack on the new fs |
| 17:36.43 | Estel_ | just recreate filesysytem and copy files? |
| 17:36.47 | kerio | yeah |
| 17:36.49 | Estel_ | hm, so why fsck on desktop |
| 17:36.58 | Estel_ | could just copy data to desktop, mkfs, copy back |
| 17:36.59 | kerio | because the n900 is slow as fuck |
| 17:37.13 | kerio | that's also why i told you to first mount and copy the data |
| 17:37.18 | kerio | actually |
| 17:37.19 | Estel_ | I see |
| 17:37.30 | kerio | mount ro,noload and copy the data |
| 17:37.31 | kerio | then mount and copy the data |
| 17:37.33 | *** join/#maemo-ssu ivgalvez_ (~quassel@86.43.81.96) |
| 17:37.36 | kerio | then fsck, mount and copy the data :) |
| 17:37.36 | Estel_ | permissions won't get fucked? |
| 17:37.37 | Estel_ | for optfs? |
| 17:37.42 | Estel_ | due to copying for some linux distro? |
| 17:37.45 | kerio | surely you're doing this as root |
| 17:37.49 | Estel_ | sure |
| 17:37.53 | kerio | use cp -a |
| 17:38.08 | Estel_ | thats the way I do it usually, but last time I tried, and fs was clean then... |
| 17:38.11 | Estel_ | after copying back |
| 17:38.17 | Estel_ | half of optfs wasnt working :P |
| 17:38.29 | Estel_ | black instead of desktop, pink ststusbar, etc |
| 17:38.40 | Estel_ | strange things instead of fonts |
| 17:38.48 | Estel_ | but for easy debian it always work, no idea |
| 17:38.50 | kerio | hm, you should probably use tar actually |
| 17:38.56 | kerio | idk if there's hard links in optfs |
| 17:38.56 | Estel_ | think so |
| 17:39.14 | kerio | anyway, when you're remaking the fs, use mke2fs -c |
| 17:39.21 | kerio | so it checks for badblocks once |
| 17:39.36 | kerio | ShadowJK: will that cause problems? |
| 17:39.40 | Estel_ | nods |
| 17:39.53 | Estel_ | wear levellin on emmc will ignore our badblocks |
| 17:40.00 | kerio | not if you leave them there |
| 17:40.04 | Estel_ | due to transparent hardware shit assigning to wrong block anyway |
| 17:40.15 | kerio | hm |
| 17:40.17 | Estel_ | I don't think emmc wear levelling respect our badblocks results |
| 17:40.20 | kerio | good pont |
| 17:40.21 | kerio | point |
| 17:40.30 | kerio | but the emmc should not present bad blocks at all, shouldn't it |
| 17:40.39 | kerio | i mean, it should identify the bad blocks |
| 17:41.02 | Estel_ | for logical filesystem, it won't, but physically, bad block will get assigned again due to hw wear lvl |
| 17:41.12 | Estel_ | so, it will n"miracolously" appear in other place |
| 17:41.16 | Estel_ | for logical filesystem |
| 17:41.18 | kerio | yeah but the wear levelling should figure out that a block is bad |
| 17:41.24 | kerio | like, a nand block |
| 17:41.28 | kerio | and stop using it |
| 17:41.38 | Estel_ | tell it to manuf. of fuckin wear lvlers on hardware lvl, they don't care |
| 17:41.53 | Estel_ | I agree, but haven't seen hw wear lvler that would respect it, sadly :( |
| 17:42.01 | kerio | there's nothing to "respect" |
| 17:42.10 | kerio | a block being bad is something you can notice, at the controller's side |
| 17:42.11 | Estel_ | s/respect/care about it/ |
| 17:42.32 | Estel_ | as said, agreed, but they just don't care :( |
| 17:42.51 | Estel_ | be it most expensive sd cards or noname ones, same apply *probably* for n900 emmc |
| 17:43.11 | Estel_ | hardware wear levelling that doesn't talk with os/kernel/whatever is evil, always |
| 17:43.53 | Estel_ | thanks for help, anyway, will try to fix mess with that fs |
| 17:44.31 | kerio | ShadowJK: surely blindly remapping bad blocks around is not something that a sensible emmc controller would do, is it |
| 17:51.37 | *** join/#maemo-ssu M4rtinK2 (~M4rtinK@ip-86-49-81-87.net.upcbroadband.cz) |
| 17:53.14 | kerio | ShadowJK: silly idea - would leaving a bunch of empty space help? |
| 18:03.54 | ShadowJK | kerio; in general controllers are not "sensible" :)) |
| 18:05.33 | ShadowJK | As for "fixing" a corrupt filesystem, myself I'd probably never run fsck ever again, tried that once. I'd tar files up and extract into newly mkfs'd fs |
| 18:05.45 | kerio | ah ofc |
| 18:08.18 | ShadowJK | fsck on MyDocs vfat is probably not as evil |
| 18:08.29 | ShadowJK | as sd cards are supposed to work with vfat |
| 18:50.00 | *** join/#maemo-ssu xes (~xes@unaffiliated/xes) |
| 18:56.44 | discopig | yes |
| 19:04.09 | kerio | ShadowJK: if you had to guess, would you say that disabling compression on rootfs increases or decreases performance? |
| 19:04.14 | *** join/#maemo-ssu Guest50382 (~rd@p57B4913B.dip0.t-ipconnect.de) |
| 19:13.41 | *** join/#maemo-ssu futpib (~futpib@89.106.197.11) |
| 19:20.49 | *** join/#maemo-ssu Vlad_on_the_road (~Vlad_on_t@ip-66.net-82-216-1.versailles2.rev.numericable.fr) |
| 19:34.47 | *** join/#maemo-ssu sunny_s (~sunny_s@86.57.254.135) |
| 19:35.32 | *** join/#maemo-ssu keesj (~keesj@dellpc132.few.vu.nl) |
| 20:05.44 | *** join/#maemo-ssu Guest50382 (~rd@p57B4913B.dip0.t-ipconnect.de) |
| 20:16.54 | Estel_ | kerio, I'm not ShadowJK, but compression on rootfs decrease write performance ;) |
| 20:17.06 | kerio | but you have to write less stuff |
| 20:17.17 | Estel_ | freemangordon once witnessed it, when trying to put qt things on rootfs |
| 20:17.34 | Estel_ | true, but measurements were took, and even emmc was faster |
| 20:17.37 | Estel_ | due to compression |
| 20:18.14 | Estel_ | early cssu-thumb moved stuff to rootfs for faster execution, then, reverted, as it was slower due to compr. |
| 20:19.05 | Estel_ | idea - when "enuff" things will get thumbified and our rootfs will be enough to keep things without compression, some perf. boost may be expected from disabling it |
| 20:19.25 | kerio | hm, i might want to try that |
| 20:19.38 | Estel_ | ...then we need to thumbify even more, as some things could really benefit by moving it from emmc to rootfs, then, without compr. |
| 20:19.52 | Estel_ | report back. Don't expect fireworks of performance |
| 20:20.04 | Estel_ | rather like moving to thumb from main |
| 20:20.12 | Estel_ | visible perf gain, but no miracles |
| 20:20.22 | Estel_ | thats my expectations, anyway |
| 20:20.37 | kerio | i have 196mb of real stuff in my rootfs |
| 20:20.40 | Estel_ | of course "visible" depends on things, visible only, where approriate :P |
| 20:20.44 | Estel_ | so go ahead |
| 20:21.00 | Estel_ | just be sure that you haven't optified stuff that slows you down |
| 20:21.08 | Estel_ | due to being optified :P |
| 20:21.17 | kerio | i probably have |
| 20:21.24 | kerio | sooo... how do we do this |
| 20:21.35 | Estel_ | unlikely to happen, as moving things to optfs when compression is ON may increase perf. |
| 20:21.45 | Estel_ | no idea, see some tune ubifs or whatsnot |
| 20:21.59 | Estel_ | in case of despair, just backup rootfs and recreate ubi without compr. |
| 20:23.09 | Estel_ | curious question - which config file on N900 is responsible for hostname as visible by routers? |
| 20:23.16 | kerio | huh... /etc/hostname? |
| 20:23.17 | Estel_ | I though /etc/hostname, but, apparently, not |
| 20:23.43 | Estel_ | I have one with "blabla" in it, yet, router where i connected for the first time saw it as "bleble" anyway |
| 20:23.48 | Estel_ | names random, not real |
| 20:24.10 | kerio | have you rebooted |
| 20:24.16 | Estel_ | plentora times |
| 20:24.18 | kerio | it might also be the router that caches the name |
| 20:24.27 | kerio | go look for how dhcpc is invoked |
| 20:24.39 | Estel_ | hm, this mac for 100% never connected there |
| 20:24.50 | kerio | also... huh, bluetooth name? |
| 20:24.56 | Estel_ | also changed |
| 20:25.00 | Estel_ | I'm also surprised |
| 20:25.25 | kerio | just grep -R bleble / |
| 20:25.37 | Estel_ | I prepared device for my son from scraych (no backupmenu restore from my ddevicea), although, sometimes, I re-use configs from my main device |
| 20:25.39 | Estel_ | suuuuure |
| 20:25.46 | Estel_ | will take just 1000 years |
| 20:25.57 | kerio | it won't |
| 20:26.02 | Estel_ | now, hostname never was one of my main device |
| 20:26.16 | kerio | if you're *that* worried, grep -R bleble /path/to/unpacked/backup on your computer |
| 20:26.24 | Estel_ | bluetooth and /etc/hostname got bustom name |
| 20:26.44 | Estel_ | Then, router where i connected from my main device, but 2nd one *never* connected |
| 20:26.54 | Estel_ | see that 2nd device with hostname of 1st device |
| 20:27.01 | Estel_ | no big deal, just curious |
| 20:27.43 | Estel_ | I would think caching, but mac is different, unless it do os fingerprinting and cached maemo?...:P |
| 20:28.01 | Estel_ | kerio, well, good diea with grep, anyway |
| 20:28.17 | Estel_ | might do it. And yes, it take 1000 years, tried it once on some file |
| 20:28.21 | kerio | whothehellwouldusetwodeviceswiththiscraponit.c |
| 20:28.22 | Estel_ | some name* |
| 20:28.35 | kerio | in libwhothehellwouldusetwodeviceswiththiscraponit |
| 20:28.38 | Estel_ | after 6 hours, gave up |
| 20:28.50 | Estel_ | wut? :P |
| 20:29.03 | Estel_ | ah |
| 20:29.20 | *** join/#maemo-ssu Guest50382 (~rd@p57B4913B.dip0.t-ipconnect.de) |
| 20:29.22 | kerio | Estel_: http://i.imgur.com/axJmn.gif |
| 20:29.24 | Estel_ | highly unlikely, it is wrt54gl |
| 20:29.30 | Estel_ | I've set it up myself, once |
| 20:29.34 | Estel_ | for my ex-wife :P |
| 20:29.47 | Estel_ | tomato there, IIRC |
| 20:46.51 | *** join/#maemo-ssu Guest50382 (~rd@p57B4913B.dip0.t-ipconnect.de) |
| 20:58.26 | kerio | Estel_: so, i disabled compression |
| 21:00.24 | kerio | haven't *fully* disabled it because rescueOS doesn't have the necessary tools in this version :s |
| 21:00.41 | kerio | but chattr -c / and then unpacking the tarball does the job |
| 21:17.29 | *** join/#maemo-ssu Martix (~martix@static-84-242-103-180.net.upcbroadband.cz) |
| 21:48.02 | *** join/#maemo-ssu Guest50382 (~rd@p57B4913B.dip0.t-ipconnect.de) |
| 22:06.04 | *** join/#maemo-ssu sunny_s (~sunny_s@86.57.254.135) |
| 22:09.02 | *** join/#maemo-ssu nox- (noident@freebsd/developer/nox) |
| 22:12.21 | *** join/#maemo-ssu freemangordon (~freemango@130-204-50-168.2074221835.ddns.cablebg.net) |
