| 00:06.38 | *** join/#maemo AndrewX192 (~andrew@unaffiliated/andrewx192) |
| 00:11.52 | DocScrutinizer05 | ugh |
| 00:12.31 | DocScrutinizer05 | http://maemo.cloud-7.de/maemo5/patches_n_tools/maemo-my-private-workdir.tar.gz |
| 00:14.25 | DocScrutinizer05 | fixed |
| 00:16.24 | *** join/#maemo guerby (~guerby@ip165-ipv6.tetaneutral.net) |
| 00:52.27 | *** join/#maemo Hurrian (~hurrian@unaffiliated/rikanee) |
| 01:04.21 | stryngs | ~flash |
| 01:04.21 | infobot | i guess maemo-flashing is http://wiki.maemo.org/Updating_the_tablet_firmware, or - on linux PC - download&extract http://maemo.cloud-7.de/maemo5/patches_n_tools/maemo-my-private-workdir.tgz, cd into it, do sudo ./flash-it-all.sh |
| 01:04.46 | stryngs | Interesting. No more ability to get the original software from Nokia I see |
| 01:05.55 | stryngs | 2015-09-04 21:05:47 ERROR 404: Not Found. |
| 01:05.58 | stryngs | DocScrutinizer05: ^ |
| 01:07.59 | stryngs | ~firmware |
| 01:07.59 | infobot | i guess firmware is please see ~combined ~emmc ~flasher |
| 01:08.03 | stryngs | ~combined |
| 01:08.03 | infobot | somebody said combined was the rootfs fiasco image of maemo. For N900 latest (PR1.3.1) see http://nds2.fds-fire.nokia.com/fdp/interface/FiRe/2011/9/--FID--A0A22MVWFVFAM/--LID--FiRe1317015685654/RX-51_2009SE_21.2011.38-1_PR_COMBINED_MR0_ARM.bin, or http://galif.eu/nokia/ |
| 01:09.12 | stryngs | ~emmc |
| 01:09.12 | infobot | emmc is probably is http://nds2.fds-fire.nokia.com/fdp/interface/FiRe/2010/5/--FID--A0A22YHFSICNA/--LID--FiRe1275051276916/AE98ED9D_RX-51_2009SE_10.2010.13-2.CENTRAL-EUROPE_PR_EMMC_MR0_ARM.bin or see ~emmc2 |
| 01:09.24 | stryngs | ~emmc3 |
| 01:09.25 | infobot | hmm... emmc3 is http://nds2.fds-fire.nokia.com/fdp/interface/FiRe/2010/4/--FID--A0A22UYGVCFDF/--LID--FiRe1272381325983/E14B4F3B_RX-51_2009SE_10.2010.13-2.SCANDINAVIA_PR_EMMC_MR0_ARM.bin |
| 01:09.29 | stryngs | ~emmc2 |
| 01:09.29 | infobot | extra, extra, read all about it, emmc2 is http://nds2.fds-fire.nokia.com/fdp/interface/FiRe/2010/5/--FID--A0A22FGDOJCSI/--LID--FiRe1275064390175/163EC1AE_RX-51_2009SE_10.2010.13-2.IBERIA_PR_EMMC_MR0_ARM.bin, or http://nds2.fds-fire.nokia.com/fdp/interface/FiRe/2010/5/--FID--A0A22VHGOMWUG/--LID--FiRe1274862877184/E3AD4912_RX-51_2009SE_10.2010.13-2.SEAP_PR_EMMC_MR0_ARM.bin, or see emmc3 |
| 01:09.34 | stryngs | Heh |
| 01:09.46 | stryngs | ~emmc |
| 01:09.46 | infobot | it has been said that emmc is is http://nds2.fds-fire.nokia.com/fdp/interface/FiRe/2010/5/--FID--A0A22YHFSICNA/--LID--FiRe1275051276916/AE98ED9D_RX-51_2009SE_10.2010.13-2.CENTRAL-EUROPE_PR_EMMC_MR0_ARM.bin or see ~emmc2 |
| 01:09.54 | stryngs | So what is the diff between that |
| 01:09.58 | stryngs | ~emmc2 |
| 01:09.58 | infobot | i guess emmc2 is http://nds2.fds-fire.nokia.com/fdp/interface/FiRe/2010/5/--FID--A0A22FGDOJCSI/--LID--FiRe1275064390175/163EC1AE_RX-51_2009SE_10.2010.13-2.IBERIA_PR_EMMC_MR0_ARM.bin, or http://nds2.fds-fire.nokia.com/fdp/interface/FiRe/2010/5/--FID--A0A22VHGOMWUG/--LID--FiRe1274862877184/E3AD4912_RX-51_2009SE_10.2010.13-2.SEAP_PR_EMMC_MR0_ARM.bin, or see emmc3 |
| 01:10.00 | stryngs | and that |
| 01:10.06 | stryngs | ~emmc3 |
| 01:10.06 | infobot | [emmc3] http://nds2.fds-fire.nokia.com/fdp/interface/FiRe/2010/4/--FID--A0A22UYGVCFDF/--LID--FiRe1272381325983/E14B4F3B_RX-51_2009SE_10.2010.13-2.SCANDINAVIA_PR_EMMC_MR0_ARM.bin |
| 01:10.09 | stryngs | and that |
| 01:10.11 | stryngs | ~emmc4 |
| 01:10.15 | stryngs | ? |
| 01:15.17 | stryngs | hehe, This is the type of stuff I'm talkin bout =) So much info |
| 01:18.05 | *** join/#maemo Humpelstilzchen (erik@x50ab65ab.dyn.telefonica.de) |
| 01:29.24 | *** join/#maemo Dynamit (~Mohamed@2a02:c200:1:10:2:3:6999:150) |
| 01:39.52 | *** join/#maemo eMHa (~mh@p579DBF47.dip0.t-ipconnect.de) |
| 02:08.01 | Ras_Older | Yey i got terminator to work on W10! Now why did I need it in the first place... |
| 02:08.53 | Ras_Older | I'm doing some black magic compiling voodoo with cygwin |
| 02:18.26 | stryngs | Ras_Older: Question for you |
| 02:18.43 | stryngs | Ras_Older: When it came to picking which files to flash with; how did u make your decision? |
| 02:19.17 | Ras_Older | one candy first -> *noms* gotta love these Zolpidems.. |
| 02:19.50 | *** join/#maemo protem` (~protem@unaffiliated/protem) |
| 02:21.02 | Ras_Older | I see it as we have problem X = working device non-bloated with bad stuff. |
| 02:21.15 | *** join/#maemo Neutron118 (~neutron@ti0042a400-4979.bb.online.no) |
| 02:21.59 | stryngs | ffs |
| 02:22.00 | stryngs | http://maemovmware.garage.maemo.org/2nd_edition/ |
| 02:22.03 | stryngs | Anyone have that? |
| 02:22.07 | Ras_Older | We need the ones that are critical to system boot-up process. Also would it be good to discuss what is bloat? |
| 02:22.22 | stryngs | Well, I'm with ya on that, but i'm talking about your flashing files |
| 02:22.25 | stryngs | Watch... |
| 02:22.27 | stryngs | ~emmc |
| 02:22.27 | infobot | i heard emmc is is http://nds2.fds-fire.nokia.com/fdp/interface/FiRe/2010/5/--FID--A0A22YHFSICNA/--LID--FiRe1275051276916/AE98ED9D_RX-51_2009SE_10.2010.13-2.CENTRAL-EUROPE_PR_EMMC_MR0_ARM.bin or see ~emmc2 |
| 02:22.30 | stryngs | ~emmc2 |
| 02:22.30 | infobot | emmc2 is, like, http://nds2.fds-fire.nokia.com/fdp/interface/FiRe/2010/5/--FID--A0A22FGDOJCSI/--LID--FiRe1275064390175/163EC1AE_RX-51_2009SE_10.2010.13-2.IBERIA_PR_EMMC_MR0_ARM.bin, or http://nds2.fds-fire.nokia.com/fdp/interface/FiRe/2010/5/--FID--A0A22VHGOMWUG/--LID--FiRe1274862877184/E3AD4912_RX-51_2009SE_10.2010.13-2.SEAP_PR_EMMC_MR0_ARM.bin, or see emmc3 |
| 02:22.32 | stryngs | ~emmc3 |
| 02:22.32 | infobot | [emmc3] http://nds2.fds-fire.nokia.com/fdp/interface/FiRe/2010/4/--FID--A0A22UYGVCFDF/--LID--FiRe1272381325983/E14B4F3B_RX-51_2009SE_10.2010.13-2.SCANDINAVIA_PR_EMMC_MR0_ARM.bin |
| 02:22.36 | stryngs | SO MUCH INFO |
| 02:22.41 | stryngs | etc.. |
| 02:22.46 | stryngs | How did you make your decision |
| 02:24.38 | Ras_Older | Flashing my device? Oooh boy that happened way back at 2012 when my crazy ass ex tried to smash me with a frying pan when I was sleeping.. |
| 02:25.27 | stryngs | Ok, so let's say you needed to flash right now; how would u decide? |
| 02:28.33 | Ras_Older | Study first before deciding and yep it looks like I can't find actual information regards those topics hanging on up there.. |
| 02:29.45 | Ras_Older | With those hanging there... I would be scared to do a decision without some back-up from the documentation |
| 02:30.34 | Ras_Older | Did you try Russian Roulette yet with them? That could be fun times. |
| 02:31.19 | stryngs | No, I've got my methods, but this is good; another bullet in the gun =) |
| 02:32.16 | stryngs | So, is pr 1.3.1 or 1.3 the way to go DocScrutinizer05 ? |
| 02:32.24 | stryngs | Even maemo webpage only shows 1.3 |
| 02:32.26 | Ras_Older | Who is it meant for? *places a flower to that gun barrel* |
| 02:32.35 | stryngs | Ras_Older: The community to motivate us =) |
| 02:33.22 | Ras_Older | We got no documentation regards those??? Really :D |
| 02:39.46 | Ras_Older | Anyhoo I'll look into those after some sleep. These candies do funny thingies to me brainies |
| 02:56.10 | DocScrutinizer05 | stryngs: 1.3.1 is a minor security update that also comes with CSSU |
| 02:56.49 | *** join/#maemo beford (~beford@unaffiliated/beford) |
| 02:57.48 | DocScrutinizer05 | actually 1.3.1 only removes a few compromised certs iirc |
| 03:00.13 | DocScrutinizer05 | ~sb |
| 03:00.13 | infobot | [scratchbox] a cross-compiling system that uses binfmt_misc, rpc calls, and an nfs mount to make a cross-build appear to be 100% native, and is found at http://www.scratchbox.org/, hosted by maemo now. Also at http://maemo.merlin1991.at/files/SB |
| 03:00.28 | DocScrutinizer05 | == http://maemovmware.garage.maemo.org/2nd_edition/ |
| 03:02.29 | DocScrutinizer05 | and in ~flashing wiki you find all the info you need, basically |
| 03:03.13 | DocScrutinizer05 | (So what is the diff between...) simply look at the filenames, it's almost obvious |
| 03:03.24 | DocScrutinizer05 | SCANDINAVIA_PR_EMMC_MR0_ARM.bin |
| 03:03.33 | DocScrutinizer05 | SEAP_PR_EMMC_MR0_ARM.bin, |
| 03:03.45 | DocScrutinizer05 | CENTRAL-EUROPE_PR_EMMC_MR0_ARM.bin |
| 03:04.03 | DocScrutinizer05 | IBERIA_PR_EMMC_MR0_ARM.bin, |
| 03:04.18 | stryngs | DocScrutinizer05: Woo! |
| 03:04.46 | stryngs | I just made the thread post. Is it pretty much just language? |
| 03:06.23 | stryngs | DocScrutinizer05: Does installing one over the other screw up stuff or miss stuff, etc, etc, etc...? |
| 03:10.03 | stryngs | DocScrutinizer05: You say 1.3.1 comes with CSSU. Do I understand that you meant: |
| 03:10.13 | stryngs | - CSSU will do the same updates |
| 03:10.21 | stryngs | - 1.3.1 Actually HAS CSSU? |
| 03:10.26 | stryngs | Which of the two? =) |
| 03:10.30 | DocScrutinizer05 | no, pretty much just which songs come with it I guess |
| 03:11.13 | DocScrutinizer05 | And I say 1.3.1 comes with *one* update that CSSU shipped before 1.3.1 came out |
| 03:11.52 | DocScrutinizer05 | that's why CSSU asks for *either* 1.3 *or* 1.3.1, doesn't make a difference |
| 03:11.58 | stryngs | Copy that |
| 03:12.17 | stryngs | DocScrutinizer05: Ok, I can proceed with my work then. You're being VERY helpful with this and it is much appreciated! |
| 03:12.26 | DocScrutinizer05 | yw |
| 03:12.30 | stryngs | I'm converting the stock deb list to a CSV and will upload shortly |
| 03:20.16 | DocScrutinizer05 | let's see if there's more in the backscroll I could comment |
| 03:21.27 | DocScrutinizer05 | [2015-09-05 Sat 03:04:46] <stryngs> Interesting. No more ability to get the original software from Nokia I see |
| 03:21.28 | DocScrutinizer05 | [2015-09-05 Sat 03:05:55] <stryngs> 2015-09-04 21:05:47 ERROR 404: Not Found. |
| 03:21.31 | DocScrutinizer05 | incorrect |
| 03:22.19 | DocScrutinizer05 | [2015-09-05 Sat 02:14:25] <DocScrutinizer05> fixed |
| 03:29.03 | stryngs | Yeah, I caught the link DocScrutinizer05 |
| 03:29.28 | stryngs | DocScrutinizer05: I mentioned that because I'm all about "trust", and though much trust goes into inheritance, for "this, whatever it is" to "work", trust must be involved. |
| 03:29.42 | stryngs | DocScrutinizer05: But, i was able to pull 1.3.1 from nokia domain |
| 03:30.26 | stryngs | Holy crap 1742 .debs by default |
| 03:30.27 | stryngs | wtf. |
| 03:30.56 | DocScrutinizer05 | for trust issues I added md5sum check |
| 03:32.24 | stryngs | DocScrutinizer05: yep, I saw that; it's how I do things too =) |
| 03:32.33 | stryngs | DocScrutinizer05: I think u and me see eye to eye on this stuff. |
| 03:32.37 | stryngs | DocScrutinizer05: Excited to work with you |
| 03:32.58 | DocScrutinizer05 | which has the 'funny' side effect that my script refuses to flash VANILLA patches for partition size |
| 03:37.46 | *** join/#maemo Roth (~quassel@2601:18c:c700:f254:9d9d:b25f:453a:733f) |
| 03:54.27 | DocScrutinizer05 | anyway what the script *really* does is to make sure the needed files are available and then trigger the second flashing process (of vanilla) right after the first (COMBINED) ended, so it kicks in just in time to stop the device from booting. Which is highly important since when you let it boot for 0.5s into linux and then reboot it to flash VANILLA, it's borked |
| 03:54.40 | DocScrutinizer05 | ...and you can start all over again |
| 03:56.02 | DocScrutinizer05 | that's why the "foolproof procedure" in "flashing the firmware" wiki sugests to do a triple flashing combined, vanilla, combined, and to take out battery |
| 04:00.07 | *** join/#maemo protem (~protem@unaffiliated/protem) |
| 04:03.28 | stryngs | DocScrutinizer05: Interesting. I do Vanilla, remove bat, then combined. Never had an issue before =) ofc, I'm rdy and watching when it flashes |
| 04:08.18 | *** join/#maemo darkschneider (~gab@93-32-59-44.ip32.fastwebnet.it) |
| 04:20.51 | DocScrutinizer05 | when your rootfs system is borked, the softupd can't work and thus vanilla flashing can't work |
| 04:21.16 | DocScrutinizer05 | thus in that pathological case you *need* to flash COMBINED first |
| 04:22.05 | DocScrutinizer05 | COMBINED gets flashed by NOLO bootloader, VANILLA "flashing" is actually a job done in linux |
| 04:24.02 | DocScrutinizer05 | http://paste.opensuse.org/43021802 aaaaand BINGO, guess I bought me a reboot |
| 04:25.34 | stryngs | Way ahead of ya DocScrutinizer05 =) |
| 04:28.01 | DocScrutinizer05 | well, it's known that VANILLA "flashing" can't get terminated except by shutting down the system hard (or possibly by parameter -R and completing the flashhing process, never tested that) |
| 04:28.20 | DocScrutinizer05 | so yeah, I had to shut down a device which pretended to be dead |
| 04:28.45 | DocScrutinizer05 | exactly what happens with flashing VANILLA |
| 04:30.20 | stryngs | DocScrutinizer05: I'm almost done with this CSV. I'm using plaintext files for "trust" factors. |
| 04:30.26 | DocScrutinizer05 | at least that's what I seem to recall. Not 100% sure if it's actually softupd daemon that does VANILLA flashing |
| 04:30.28 | *** join/#maemo robink (~quassel@unaffilated/robink) |
| 04:30.36 | stryngs | DocScrutinizer05: I simply pull the battery, it works for me |
| 04:30.41 | DocScrutinizer05 | sure |
| 04:30.56 | stryngs | DocScrutinizer05: There have been cases, where i've had to do the triple flash, but those are rare now. |
| 04:32.31 | DocScrutinizer05 | funny: when I pressed power button first time, the indicator light started shining white and steady. 8s pressing power button then made NOKIA bootloader kick in and device shuts *down* |
| 04:33.16 | stryngs | Ah, yeah, I go for the throat; Never trusted the power down method for flashing |
| 04:33.16 | DocScrutinizer05 | all this stuff is *very* obscure and undocumented for maemo |
| 04:33.19 | stryngs | I figure it's all the same |
| 04:33.34 | stryngs | DocScrutinizer05: That's why I want a "new method" for the future =) |
| 04:33.50 | stryngs | DocScrutinizer05: And if I can help be a part of something that gives back, then I've done my part. |
| 04:33.56 | DocScrutinizer05 | new method of flashing? good luck |
| 04:34.20 | stryngs | DocScrutinizer05: Not flashing, but "Base Image" for maemo |
| 04:34.24 | stryngs | DocScrutinizer05: The proposal |
| 04:34.41 | stryngs | DocScrutinizer05: It'll be documented, from start to finish 100%. Already have a nice outline |
| 04:35.19 | DocScrutinizer05 | I don't see how to document the very beginning: the flashing process in NOLO and softupd |
| 04:35.24 | stryngs | DocScrutinizer05: http://termbin.com/kofx |
| 04:35.28 | stryngs | DocScrutinizer05: That's how we do it |
| 04:35.41 | stryngs | DocScrutinizer05: Keep in mind, that's pwnphone methodology, but it can be applied towards Maemo as a whole. |
| 04:35.59 | stryngs | DocScrutinizer05: And I say pwnphone, but it's not even pwnphone anymore, pwnieexpress stopped supporting the n900 |
| 04:36.03 | DocScrutinizer05 | sorry, too tired to look into that now |
| 04:36.05 | stryngs | DocScrutinizer05: It's nameless =) |
| 04:36.07 | stryngs | DocScrutinizer05: NO worries |
| 04:36.25 | stryngs | DocScrutinizer05: check it out when ya can, throughouly documented from start to finish |
| 04:36.44 | DocScrutinizer05 | aha. So they RE'd NOLO or what? |
| 04:37.16 | stryngs | Well, it was an attempt to make a true "Walkthrough" for those who have ZERO n900 experience |
| 04:37.32 | DocScrutinizer05 | ooh, THAT kind of "docs" |
| 04:37.45 | stryngs | DocScrutinizer05: Thus far, it has good reviews. The plan is to take those directions, and apply them towards a more uniform user experience, not just a pwnphone style methodology |
| 04:39.44 | DocScrutinizer05 | I thought about docs like you can find in 0xFFFF and http://www.omappedia.org/wiki/Bootloader_Project and http://talk.maemo.org/showthread.php?t=20465 |
| 04:40.20 | stryngs | DocScrutinizer05: Ah, yeah, nothing like that =) Not trying to make heads explore |
| 04:40.23 | stryngs | DocScrutinizer05: Ah, yeah, nothing like that =) Not trying to make heads explode |
| 04:46.23 | *** join/#maemo beford (~beford@unaffiliated/beford) |
| 04:46.58 | DocScrutinizer05 | http://talk.maemo.org/showthread.php?t=17665 |
| 04:47.38 | DocScrutinizer05 | ~l1_2 |
| 04:47.46 | DocScrutinizer05 | hmm |
| 04:50.08 | DocScrutinizer05 | https://www.google.de/search?q=Nokia_N900_RX-51_Service_Manual_Service_Level_1_2.pdf http://directoriopt.com/read/?file=http://directoriopt.com/donld/tYXZLT/nokia-n900-rx-51-service-manual-service-level-3-4.pdf |
| 04:52.41 | DocScrutinizer05 | sorry, forget the latter, it's nagware shit |
| 04:53.09 | stryngs | =) |
| 04:55.15 | DocScrutinizer05 | http://www.cpkb.org/wiki/Nokia_N900_service_manual_and_schematic_download |
| 04:55.23 | DocScrutinizer05 | was legit once |
| 04:55.38 | DocScrutinizer05 | L3_4 is really great doc |
| 04:56.23 | stryngs | DocScrutinizer05: How long u been playing the n900 game? |
| 04:56.33 | stryngs | DocScrutinizer05: I know your the "reason" for neo900, yea? |
| 04:56.45 | DocScrutinizer05 | hmm? |
| 04:58.39 | DocScrutinizer05 | dang, seems the public sources for L3_4 are ... dried |
| 04:58.55 | DocScrutinizer05 | ping me if you can't find it |
| 05:00.31 | *** join/#maemo robink_ (~quassel@unaffilated/robink) |
| 05:02.21 | stryngs | Woo! http://talk.maemo.org/showthread.php?p=1481135&posted=1#post1481135 First vote has been called for, check it out! |
| 05:02.32 | stryngs | DocScrutinizer05: The most recent post contains the package CSV file |
| 05:24.14 | *** join/#maemo robink_ (~quassel@unaffilated/robink) |
| 05:35.45 | *** join/#maemo LauRoman (~LauRoman@5-14-16-10.residential.rdsnet.ro) |
| 05:43.54 | stryngs | Alright, WORN the heck out, headed off to sleep. For those interested, check out the CSV and apply your thoughts as you see fit =) http://talk.maemo.org/showthread.php?p=1481123#post1481123 |
| 06:01.05 | KotCzarny | yawn |
| 06:01.09 | KotCzarny | 'morning |
| 06:01.39 | KotCzarny | yeah, everything needed for boot goes to /, non-boot important packages to /usr |
| 06:02.31 | KotCzarny | will probably require updating some debs? |
| 06:03.57 | KotCzarny | and maybe changing optifier in installer to stop or check how much stuff goes to / just in case of bad packages |
| 06:04.11 | KotCzarny | and maybe bindmounting /opt into /usr |
| 06:05.42 | KotCzarny | stryngs: this is what i remove personally (might be bit too much tho): http://wiki.maemo.org/Slimming_OS |
| 06:12.14 | Tekk_ | What's the recommended app for youtube these days? |
| 06:12.22 | KotCzarny | cutetube2 |
| 06:12.57 | Tekk_ | in extras-devel I assume? |
| 06:13.04 | KotCzarny | most likely |
| 06:13.30 | Tekk_ | also is there any way to get ham to stop complaining about the nokia repos that were killed? |
| 06:13.42 | KotCzarny | ~maemo-repos |
| 06:13.42 | infobot | methinks maemo-repos is http://wiki.maemo.org/Repository#List_of_Maemo_repositories |
| 06:13.57 | KotCzarny | also install cssu and use speedyham |
| 06:13.59 | KotCzarny | ~speedyham |
| 06:14.00 | infobot | [speedyham] 30 times faster than HAM http://maemo.merlin1991.at/cssu/community-devel/pool/free/h/hildon-application-manager/hildon-application-manager_2.2.73-2_armel.deb |
| 06:14.08 | Tekk_ | I've got cssu |
| 06:14.20 | Tekk_ | is speedyham okay these days? |
| 06:14.25 | KotCzarny | wasnt it? |
| 06:14.31 | KotCzarny | it was fap that had problem |
| 06:14.33 | KotCzarny | ~fap |
| 06:14.33 | infobot | extra, extra, read all about it, fap is good |
| 06:14.37 | KotCzarny | hum |
| 06:14.38 | KotCzarny | ~fam |
| 06:14.39 | infobot | from memory, fapman is Faster Application Manager, a frontend for apt which uses own repositories catalog, and shouldn't be used to do system upgrades (like CSSU), or actually for anything since ~speedyHAM. It also does "apt-get autoremove" after every operation, by default. In short, it's been identified as source of system corruption and thus deprecated, or see ~hamvsfam |
| 06:14.42 | Tekk_ | ah |
| 06:14.49 | Tekk_ | I was probably mixing them up then |
| 06:22.30 | *** join/#maemo chainsawbike_ (~chainsawb@unaffiliated/chainsawbike) |
| 06:30.10 | *** join/#maemo _rd_ (~rd@pD9E7C377.dip0.t-ipconnect.de) |
| 07:23.31 | *** join/#maemo vectis (~phil@79-64-232-243.host.pobb.as13285.net) |
| 07:39.28 | Maxdamantus | is buying a new battery. |
| 07:40.00 | Maxdamantus | Last Measured Discharge: 949 mAh |
| 07:43.27 | KotCzarny | me is buying second n900 |
| 08:06.20 | *** join/#maemo aloril (~aloril@dsl-tkubrasgw2-54f80e-20.dhcp.inet.fi) |
| 08:23.05 | *** join/#maemo _rd_ (~rd@pD9E7C377.dip0.t-ipconnect.de) |
| 08:39.14 | *** join/#maemo aloril (~aloril@dsl-tkubrasgw2-54f80e-20.dhcp.inet.fi) |
| 09:06.10 | *** join/#maemo Pali (~pali@Maemo/community/contributor/Pali) |
| 09:13.04 | sixwheeledbeast | hmm https://blog.mozilla.org/security/2015/09/04/improving-security-for-bugzilla/ not as important for our bugzilla but interesting attack route. |
| 09:30.22 | *** join/#maemo Pali (~pali@Maemo/community/contributor/Pali) |
| 09:37.08 | *** join/#maemo Oksanaa (~chatzilla@Maemo/community/council/Wikiwide) |
| 09:48.00 | Sicelo | KotCzarny: you've found one? happy for you. i wouldn't mind a third one |
| 09:48.33 | KotCzarny | sicelo: finding isnt a problem, getting my a** to actually buy it is in my case |
| 09:48.42 | Sicelo | my 2nd N900 cost me only US$15 :) |
| 09:48.50 | KotCzarny | w00t |
| 09:49.33 | Sicelo | of course it was broken, no usb, and no battery .. but i knew i could trust the guy, and took the jump. now it's even in better condition than my main N900 :) |
| 09:51.00 | Sicelo | only money spent was usb port, flux, solder wick. the rest of the "investment" was just time |
| 09:51.12 | KotCzarny | well, this one i'm getting for ~50usd |
| 09:51.23 | Sicelo | BUY IT FFS |
| 09:51.23 | KotCzarny | swedish version |
| 09:51.24 | Sicelo | :D |
| 09:51.31 | KotCzarny | no problems otherwise |
| 09:51.41 | Sicelo | what's delaying you? |
| 09:51.54 | KotCzarny | the guy has to send me the bank account number |
| 09:51.55 | *** join/#maemo _rd_ (~rd@pD9E7C377.dip0.t-ipconnect.de) |
| 09:52.05 | KotCzarny | woke him this morning, he he |
| 09:52.14 | Sicelo | :) |
| 09:52.23 | Sicelo | best wishes man |
| 09:52.38 | KotCzarny | yeah, he seems ok |
| 09:53.18 | Sicelo | can never go wrong with N900. i wouldn't mind getting an N9, but it's one i'd never get more than 1 of. but for N900 can buy as many as i can find and afford |
| 09:53.30 | KotCzarny | it will be my battlefield unit |
| 09:53.36 | KotCzarny | anyway, bbl |
| 09:53.48 | Sicelo | Maxdamantus: that battery .. how long it lasts you now? |
| 09:57.41 | Maxdamantus | Sicelo: probably 20 hours or so. |
| 09:58.02 | Maxdamantus | I don't usually do anything crazy on it. |
| 10:04.45 | Ras_Older | stryngs: took a brief look to your list of packages. This is just me maybe but should we let the Adobe Flash die off already? :D is it really required anymore when major website are moving towards alternatives mainly HTML5 and such? |
| 10:05.17 | Ras_Older | *typos |
| 10:09.29 | *** join/#maemo Oksanaa (~chatzilla@Maemo/community/council/Wikiwide) |
| 10:12.03 | Sicelo | Maxdamantus: my batteries are roughly at that same capacity |
| 10:12.21 | Maxdamantus | Regarding the / vs. /opt thing .. I just have pretty much everything on a single ext3. |
| 10:12.44 | Maxdamantus | the ubifs is used as a sort of writable initramfs. |
| 10:13.42 | Maxdamantus | so it has the modules for the kernels I might want to use, and a script to load the ones required to continue booting with the ext3 partition. |
| 10:13.45 | *** join/#maemo M4rtinK (~M4rtinK@mail.melf.eu) |
| 10:15.38 | Maxdamantus | The root of that ext3 isn't even a root filesystem: it's actually /home and also contains maemo5-root, debian-armel-root, shr-root (haven't tried that recently), opt and nix |
| 10:16.19 | Maxdamantus | also, the fat32 on ~/MyDocs is a really bad idea. |
| 10:17.17 | Maxdamantus | iirc, the OS doesn't make sure the filesystem is unmounted before making it visible through g_file_storage |
| 10:17.50 | Maxdamantus | So it'd be pretty easy to accidentally have it mounted (rw) on two systems. |
| 10:18.02 | Sicelo | it does ensure that |
| 10:18.46 | Sicelo | btw, did you document your setup somewhere? :) |
| 10:19.29 | Maxdamantus | Not really. I think I posted my hacky init script here a while ago. |
| 10:19.57 | Maxdamantus | Are you sure it ensures that? I'm pretty sure at least it doesn't wait for you to interact with the dialogue that pops up. |
| 10:20.22 | Sicelo | it waits. at least both my N900 do. |
| 10:20.50 | Maxdamantus | Also related: the mmc module suddenly removing access to the SD card when the backcover is removed is also a really bad idea. |
| 10:21.14 | Maxdamantus | it's like the opposite of "safely remove hardware" |
| 10:21.34 | Sicelo | i believe it also unmounts it properly for backcover too :) |
| 10:21.42 | Maxdamantus | I'm certain that it doesn't. |
| 10:22.04 | Maxdamantus | I've modified the module. It completely blocks all access to it when it sees the GPIO status change. |
| 10:22.25 | Sicelo | hmm, weird |
| 10:22.29 | Maxdamantus | The kernel can't even force remount it read-only (as in sysrq u) |
| 10:26.55 | Maxdamantus | Though the OS does unmount it itself, it only gets to remove it from the tree. It can't do a clean unmount. |
| 10:27.59 | Sicelo | ok. i was just now thinking about what a computer would do on forcible removal of a usb stick |
| 10:31.56 | Maxdamantus | Linux itself doesn't do much, but you can detect such a removal from userspace and try to unmount it, which just removes it from the tree. |
| 10:33.07 | Maxdamantus | otherwise it'll stay mounted and you might get IO errors or something occasionally, depending on the filesystem. |
| 10:34.07 | *** join/#maemo sparetire_ (~sparetire@unaffiliated/sparetire) |
| 10:41.18 | kerio | what's the reasoning behind cutting off the microsd, again? |
| 10:41.25 | kerio | i thought it was hardware controlled tbh |
| 10:41.54 | Maxdamantus | Not sure, but it's not hardware-controlled. |
| 10:42.26 | Maxdamantus | I changed a line in the module to keep it visible, so I can keep accessing it while the backcover is open. |
| 10:43.30 | Maxdamantus | Though apparently the logic to handle removing the card is also meant to be under that state, so I can't physically remove the card and use the slot again without reloading the module. |
| 10:43.42 | Maxdamantus | would probably need a few more changes. |
| 10:55.00 | *** join/#maemo Vajb (~Vajb@85-76-1-233-nat.elisa-mobile.fi) |
| 11:03.28 | *** join/#maemo Kabouik (~quassel@65.76.93.92.rev.sfr.net) |
| 11:04.36 | *** join/#maemo eMHa (~mh@p579DBF47.dip0.t-ipconnect.de) |
| 11:18.45 | *** join/#maemo kylanpaj (kylanpaj@hilla.kapsi.fi) |
| 11:51.17 | Ras_Older | Was it possible to change your username at Maemo.org? I think its bit confusing that everywhere else I go by Ras_Older but there I had a brainfart back in the day and used my old nick :D |
| 11:56.30 | Ras_Older | Apparently by dropping an email to techstaff. |
| 12:02.59 | *** join/#maemo _rd_ (~rd@pD9E7C377.dip0.t-ipconnect.de) |
| 12:07.13 | *** join/#maemo futpib (~futpib@176.104.194.78) |
| 12:08.21 | *** join/#maemo darkschneider (~gab@93-32-59-44.ip32.fastwebnet.it) |
| 12:31.32 | Sicelo | which package or config would cause N900 to "wake" up even when lockscreen was active? |
| 12:37.48 | Sicelo | sorry .. wake up when camera door gets opened ... which package or config is responsible? |
| 12:38.13 | KotCzarny | maybe camera one |
| 12:38.30 | KotCzarny | would be logical |
| 12:40.22 | merlin1991 | iirc the camera-ui part does that |
| 12:47.59 | Sicelo | main N900 doesn't have this, but 2nd one does. I want to disable it |
| 12:48.35 | Sicelo | tried to look in dbus .. didn't see anything |
| 12:49.51 | KotCzarny | sniff dbus and see what sends unlock msg? |
| 12:49.55 | KotCzarny | (via ssh) |
| 12:51.36 | *** join/#maemo _rd_ (~rd@pD9E7C377.dip0.t-ipconnect.de) |
| 12:53.36 | Sicelo | that's what i did. will redo |
| 12:54.11 | Sicelo | ah .. was checking wrong bus |
| 12:57.42 | Sicelo | https://paste.debian.net/310473/ |
| 12:58.23 | Sicelo | <PROTECTED> |
| 12:58.45 | Sicelo | google time |
| 13:06.13 | Sicelo | http://talk.maemo.org/showthread.php?t=45883 someone once had same problem. but no one explained the "why" |
| 13:15.33 | merlin1991 | Sicelo: /apps/camera/settings/extra-settings/disable-show-on-lenscover-open |
| 13:15.35 | merlin1991 | in gconf |
| 13:18.21 | Sicelo | thanks. let me check. thought i'd checked gconf too |
| 13:19.04 | Sicelo | hmm, so it's an "extra" key :) will add |
| 13:19.45 | Sicelo | i see now that my ohter N900 does have it. thanks merlin1991 |
| 13:26.02 | *** join/#maemo ssvb (~ssvb@85-76-86-29-nat.elisa-mobile.fi) |
| 13:32.16 | *** join/#maemo filosofem_ (~filosofem@5.18.82.241) |
| 14:01.07 | Vajb | Does anyone else have issues with yappari lately? For me it's quite unstable. |
| 14:36.28 | stryngs | KotCzarny: imho, optifier should be reduced to nothing more than a dummy package; Assuming we get everyone on board with FHS or bindmounting. |
| 14:36.54 | stryngs | KotCzarny: I'm all about redoing the .debs. I've already built a script to decompress them; would be hard to modify it to automate the whole process. |
| 14:37.19 | stryngs | KotCzarny: I've notated your Slimming_OS post and will check it out here in a bit. |
| 14:37.31 | stryngs | Ps... Reading scrollback =) |
| 14:39.19 | stryngs | KotCzarny: Yeah, my thoughts are to incorporate CSSU by default and speedyham to replace ham. Just haven't made that list just yet. Trying to keep the paths seperate until they're ready for convergance |
| 14:41.50 | stryngs | Ras_Older: I'm okay with murdering off of adobe flash. Some of those packages I wanted to REMOVE, but wasn't sure if they could be added back in. afaik, there are some .debs that ONLY exist in the binary image and aren't hosted. I figured flash might be one of em. Either way, if we can re-get flash, it's a definite "should be gone" from baseline. |
| 14:42.46 | stryngs | Maxdamantus: Ah, so you have done some Filesystem hacks I see =) Do you have a write-up somewhere of what you did, what it accomplished, and how you did it? |
| 14:43.57 | stryngs | Maxdamantus: Per Nokia, removing backcover; it SAFELY powers it down. Granted, this is from Nokia, but they wouldnt have it in writing if it wasn't true, imho. |
| 14:44.43 | stryngs | Ras_Older: Talk to warfare for namechanges, he's one of the maemo.org folks. |
| 14:45.51 | stryngs | Alright, be back a bit later. Catching traction with "unification" idea! =) CSV has been updated on first post with Ras_Older's votes. |
| 14:47.18 | *** join/#maemo ssvb (~ssvb@85-76-86-29-nat.elisa-mobile.fi) |
| 14:58.42 | ZetaR | stryngs: Why not use "dpkg --root=foo" instead of manual decompressing? (I may have missed some context that was stated earlier) |
| 14:59.45 | ZetaR | AFAICT, it was designed for this purpose (installing debs on a mounted root filesystem). |
| 15:17.41 | *** join/#maemo KotCzarny_ (~ariel@afrt220.neoplus.adsl.tpnet.pl) |
| 15:49.56 | *** join/#maemo APic (apic@apic.name) |
| 15:56.46 | *** join/#maemo _rd_ (~rd@pD9E7C377.dip0.t-ipconnect.de) |
| 16:00.55 | Sicelo | Vajb: unstable in what way? |
| 16:04.39 | Ras_Older | is really waiting for Cyber Security & ICT expo held in Finland, Jyväskylä 23.9 to 25.9 ^^ |
| 16:08.18 | *** join/#maemo darkschneider (~gab@93-32-59-44.ip32.fastwebnet.it) |
| 16:25.01 | *** join/#maemo Luke-Jr (~luke-jr@unaffiliated/luke-jr) |
| 16:33.25 | Sicelo | Vajb: unstable in what way? |
| 16:33.47 | Sicelo | sorry for that .. mistake |
| 16:34.35 | Vajb | unstable as it aborts or segfaults often |
| 16:34.59 | Vajb | terminate called after throwing an instance of 'ProtocolException*' |
| 16:34.59 | Vajb | Aborted |
| 16:35.13 | Vajb | last two lines and then it crashes |
| 16:35.13 | Sicelo | ok. does that for me too, not that pervious one was any better .. i was getting same thing |
| 16:35.21 | Sicelo | *previous |
| 16:35.33 | Vajb | yes same problem with previous |
| 16:35.47 | *** join/#maemo _rd_ (~rd@pD9E7C377.dip0.t-ipconnect.de) |
| 16:36.11 | Vajb | i removed one group conversation since it was always mentioned near crash time, but didn't help |
| 16:38.27 | Sicelo | i'm not even in any groups |
| 16:43.35 | Vajb | hopefully ceene is working for a fix :) |
| 16:45.39 | *** join/#maemo Luke-Jr (~luke-jr@unaffiliated/luke-jr) |
| 16:51.45 | DocScrutinizer05 | ((<Maxdamantus> I've modified the module. It completely blocks all access to it when it sees the GPIO status change.)) useless, since the module itslf actually cuts VDD for the uSD card when battery lid opened |
| 16:54.38 | *** join/#maemo yosafbridge (~yosafbrid@105.ip-167-114-152.net) |
| 17:00.02 | DocScrutinizer05 | iirc it does a lazy-umount (or somesuch), and then cuts the the power to uSD card, so it won't get damaged - or device getting damaged - when removing the card and inserting another one |
| 17:02.50 | DocScrutinizer05 | in Neo900 we slightly modified the concept, so it has a switch in card tray itself that signals "tray closed". Nevertheless we keep the magnet switch to detect battery lid removal, for whatever purposes (e.g. `sync; sync`) We also changed the red "privacy LED" in camera to a RGB type to signal different states like "uSD unmounted and safe to remove now" rtc |
| 17:03.19 | DocScrutinizer05 | #s/rst/etc/ |
| 17:10.12 | *** join/#maemo N-Mi (~nicolas@calvix/staff/N-Mi) |
| 17:30.19 | *** join/#maemo ecc3g (blc@r.jajcs.net) |
| 17:37.46 | stryngs | ZetaR: What purpose would the dpkg --root=foo do? Not following |
| 17:39.30 | *** join/#maemo _rd_ (~rd@pD9E7C377.dip0.t-ipconnect.de) |
| 17:40.01 | KotCzarny | installs to foo instead of / |
| 17:40.10 | KotCzarny | most likely |
| 17:43.10 | ZetaR | Yes. It is similar to using chroot, but it uses dpkg from / rather than from the new root (IIRC). |
| 17:44.01 | ZetaR | I am not sure how/why you are decompressing the debs some other way though, since I missed the context for your statement about it. |
| 17:44.53 | buZz | anyone here in a hackerspace with spacenet? :P |
| 17:45.07 | buZz | trying to get my N800 to connect to it, to no avail |
| 17:50.14 | KotCzarny | buzz: did you try oscp yet? |
| 17:51.04 | buZz | no, i havent put any music on it yet :P |
| 17:51.16 | KotCzarny | it works with internet streams too |
| 17:51.17 | KotCzarny | :P |
| 17:52.39 | stryngs | ZetaR: That doesn't work for apt-get purposes though |
| 17:53.20 | ZetaR | stryngs: What is the context/use here? |
| 17:53.43 | buZz | but i'd rather go on wifi here @ hackerspace :P |
| 17:54.09 | ZetaR | You have local deb files, and are trying to install them? |
| 17:54.15 | stryngs | ZetaR: I'm not sure, you kinda lost me when you wrote of dpkg --root=foo. Not sure where you're going with it. |
| 17:54.33 | KotCzarny | zetar: he tries to get rid of optification and few other things |
| 17:54.35 | stryngs | ZetaR: It's a neat use of dpkg, but I want a more world-scope plan, not a local hack. |
| 17:55.05 | stryngs | KotCzarny: Oh, I murdered off optification. What I'm curious now of though, is FHS or bindmounting... |
| 17:55.10 | ZetaR | Ahh, okay, so you are repackaging debs to remove optification? |
| 17:55.14 | KotCzarny | does apt have option that gets added to every dpkg command? |
| 17:55.27 | stryngs | ZetaR: Not at all. I just use a naked pymaemo-optify .deb |
| 17:55.38 | stryngs | ZetaR: A deb is a deb is a deb. You ever built one? |
| 17:55.50 | KotCzarny | stryngs, give him the link to your manifesto |
| 17:56.03 | stryngs | manifesto, bwhahaha =) |
| 17:56.09 | Sicelo | KotCzarny: i'd think it's rhe other way round. apt uses dpkg, dpkg does not even know about apt :) |
| 17:56.26 | stryngs | http://talk.maemo.org/showthread.php?t=95922 |
| 17:56.38 | KotCzarny | sicelo, but i asked if there is such config option for apt that will get passed to dpkg -i |
| 17:57.02 | Sicelo | the answer would be no, :) |
| 17:57.21 | stryngs | So ZetaR, a deb is pretty much a smart tarball. It contains 6 things |
| 17:57.29 | stryngs | within the deb it looks like this: |
| 17:57.41 | stryngs | DEBIAN, and then usr, or etc, or opt |
| 17:57.42 | stryngs | etc.. |
| 17:57.54 | stryngs | Within DEBIAN you have 5 total possible files, 1 of which is mandatory |
| 17:57.56 | stryngs | control |
| 17:58.08 | stryngs | control is the configuration of a .deb file |
| 17:58.14 | stryngs | apt-cache show nmap for an example |
| 17:58.19 | KotCzarny | stryngs, unpack .deb via: ar x your.deb |
| 17:58.23 | stryngs | that's a basic control file, what u see with apt-cache show |
| 17:58.28 | stryngs | KotCzarny: Oh im getting there |
| 17:58.30 | KotCzarny | its a bit different |
| 17:58.34 | stryngs | KotCzarny: Negative =) |
| 17:58.37 | stryngs | one sec |
| 17:58.44 | KotCzarny | it has 3 files afaik |
| 17:58.53 | KotCzarny | fs and deb control and some pkg info |
| 17:58.56 | stryngs | Here u go |
| 17:58.58 | stryngs | http://termbin.com/xik9 |
| 17:59.00 | stryngs | grab that |
| 17:59.06 | stryngs | rename it to rebuild |
| 17:59.08 | stryngs | chmod +x it |
| 17:59.10 | stryngs | then do: |
| 17:59.14 | stryngs | ./rebuild <deb> |
| 17:59.25 | stryngs | That will unpack it properly |
| 17:59.28 | stryngs | So you can modify it |
| 17:59.35 | stryngs | So, back to the deb story |
| 17:59.35 | KotCzarny | no, i was just tlking about .deb contents in general |
| 17:59.44 | ZetaR | I have taken apart debs before. I was replying to "stryngs: KotCzarny: I'm all about redoing the .debs. I've already built a script to decompress them; would be hard to modify it to automate the whole process." but I didn't have the previous comments, so it sounded like you were trying to install them in some odd way. |
| 17:59.45 | stryngs | Yeah, but dpkg -x is cleaner than ar -x |
| 17:59.57 | stryngs | ar allows u to see DEBIAN though. |
| 18:00.42 | stryngs | is kind of lost on what the topic is right now, truth be told. |
| 18:00.51 | Sicelo | heh |
| 18:01.21 | ZetaR | I didn't really know what the topic was to begin with. :) |
| 18:01.48 | KotCzarny | zetar, topic is stryngs murdering optification and moving fremantle toward fhs |
| 18:02.11 | stryngs | ^^ |
| 18:02.30 | stryngs | Also, the Unification and moving away from the fragmentation that has become Maemo |
| 18:02.36 | KotCzarny | and changing cssu installation in the process into single pkg install |
| 18:02.40 | stryngs | ^ |
| 18:02.45 | stryngs | That about sums it up |
| 18:02.54 | ZetaR | That is what I thought, but I was confused by the "not at all..." reply by stryngs. |
| 18:03.01 | stryngs | Also, the ability to give yourself a nice base system, 100% without being connected to the internet. |
| 18:03.20 | stryngs | 13:55 < ZetaR> Ahh, okay, so you are repackaging debs to remove optification? |
| 18:03.29 | stryngs | That's when I said not at all, now i follow |
| 18:03.44 | stryngs | So ZetaR, aside from .debs we want to modify, we don't have to repackage anything |
| 18:04.00 | stryngs | ZetaR: All pymaemo-optify does is some nasty mounting to put everything on /opt |
| 18:04.15 | ZetaR | You follow me not following? Heh. |
| 18:04.17 | stryngs | ZetaR: If you remove pymaemo-optify, you have a very clean filesystem |
| 18:04.36 | stryngs | ZetaR: The problem is though, if u remove it, you only have 256MB on / |
| 18:04.44 | stryngs | ZetaR: so, you must modify your filesystem layout |
| 18:04.44 | ZetaR | Right. |
| 18:04.51 | stryngs | ZetaR: Which I have done, successfully |
| 18:04.53 | KotCzarny | one word, fhs |
| 18:05.19 | stryngs | KotCzarny: fhs or bindmounting, either way; we just all have to agree. And many people have said FHS, but no steps has been presented |
| 18:05.19 | KotCzarny | if you move boot things into / and non-boot critical stuff into /usr its clean |
| 18:05.35 | KotCzarny | it has to be clearly defined |
| 18:05.37 | stryngs | KotCzarny: We need steps for this =) I wish I had some? |
| 18:05.38 | ZetaR | So, you are now going to mount the eMMC as /usr (like Nokia should have done)? |
| 18:05.57 | KotCzarny | once you have it, you can have /usr anywhere |
| 18:06.05 | KotCzarny | <PROTECTED> |
| 18:06.28 | stryngs | ZetaR: Well, right now, I only know one way to proceed, and that is my bindmount hacks. I would LOVE the FHS method, but, I don't know how to implement it. Others have mentioned it, but no steps or guidance has been presented on paper yet. So, all I have to go with till then, is my bindmount techniques. |
| 18:07.33 | KotCzarny | if you have things in /usr, you can use normal mount, no need for binding |
| 18:07.36 | ZetaR | I saw the text you posted about it. I am not sure why you are doing /lib and /sbin and stuff as bindmounts. |
| 18:07.42 | stryngs | KotCzarny: So how do we move them there? |
| 18:07.50 | stryngs | KotCzarny: Without repackaging and recompiling EVERY deb |
| 18:07.59 | ZetaR | Yeah, just have NAND as / and eMMC as /usr. |
| 18:08.00 | stryngs | ZetaR: Because they take up space on / |
| 18:08.27 | ZetaR | But stuff shouldn't generally install to /lib and /sbin. |
| 18:08.30 | stryngs | ZetaR: I moved as much stuff as I could, to alleviate the strain on NAND, only 256MB is easy to fill up when adding the types of .debs I do. |
| 18:08.38 | stryngs | Well, aircrack-ng |
| 18:08.44 | stryngs | Stuff goes to sbin |
| 18:08.50 | ZetaR | It should go to /usr/sbin |
| 18:09.07 | stryngs | Right, but sometimes, it just doesn't and you have to account for that. |
| 18:09.30 | stryngs | Actually, I take that back, it does do usr/sbin |
| 18:09.45 | stryngs | Point being, I offloaded as much as I could to the larger hdd |
| 18:09.52 | stryngs | and in truth, It's still FHS compliant |
| 18:10.06 | stryngs | /home/rootfs_bind/usr on /usr |
| 18:10.15 | stryngs | <PROTECTED> |
| 18:10.19 | stryngs | Just mounted |
| 18:10.19 | ZetaR | If a package is going to /sbin and it is not required for boot or basic CLI diagnostics, then it is probably wrong and needs to be fixed. |
| 18:11.00 | KotCzarny | would be nice to have system which can boot without /usr mounted, yet being able to charge, rescue itself etc |
| 18:11.10 | KotCzarny | and only needing /usr for full boot |
| 18:11.20 | ZetaR | Right. |
| 18:11.20 | stryngs | KotCzarny: afaik, backupmenu ssh solution does this |
| 18:11.28 | stryngs | KotCzarny: You have to manually mount a whole bunch of stuff |
| 18:11.46 | KotCzarny | once i get my secondary n900 im going to hack it till it screams |
| 18:12.02 | stryngs | Alright, well I suppose it's time to make the FHS post. |
| 18:12.07 | stryngs | I'll be back here ina bit |
| 18:12.13 | stryngs | I'm just glad people like the idea. |
| 18:12.17 | ZetaR | stryngs: It just seems unnecessarily complicated the way you are doing the mounts. |
| 18:12.18 | stryngs | I wasn't sure if it would gain traction |
| 18:12.35 | stryngs | ZetaR: What I do allows me to install any .deb I want, without overflowing / |
| 18:12.42 | stryngs | ZetaR: I can grab any kali armel deb i want |
| 18:12.59 | stryngs | ZetaR: Other user's however, cannot, unless they take similar actions as me, and this is due to optification bs. |
| 18:13.02 | ZetaR | If /usr is the eMMC then you should be able to do that anyway. |
| 18:13.11 | stryngs | What about when /etc fills up? |
| 18:13.14 | ZetaR | That is, if everything is propery deoptified. |
| 18:13.21 | KotCzarny | stryngs, some people do things using overlay mounts |
| 18:13.44 | stryngs | We don't want to have to repackage every single .deb though; we want the most efficient time saving manner possible, while still making maemo useful. |
| 18:13.44 | KotCzarny | ie. have a booting os in flash, and overlay in emmc |
| 18:13.45 | ZetaR | It would be very difficult to fill up /etc, since stuff should never put much data in it. |
| 18:13.58 | KotCzarny | that way you can install every deb too |
| 18:14.08 | stryngs | ZetaR: My thoughts were not so much that it can be difficult, but that it could happen, hence the precautions I took. |
| 18:14.19 | KotCzarny | and also allows for easy snapshots |
| 18:14.20 | stryngs | Take for instance, /var/apt/cache/archives |
| 18:14.28 | stryngs | What's that mounted on |
| 18:14.42 | stryngs | /var/lib/dpkg rather |
| 18:15.03 | stryngs | Either way, I don't want to argue about it, I want us to come together and implement a solution! |
| 18:15.17 | stryngs | Whatever the majority decide, if folks want to cash in on this; is how we'll proceed. |
| 18:15.28 | stryngs | If the majority decides my current way sucks; and can make it better, I'll use what tey do. |
| 18:15.33 | stryngs | team effort. |
| 18:15.35 | KotCzarny | i wouldnt mind some cash |
| 18:15.45 | stryngs | Well KotCzarny, in that respect |
| 18:15.48 | ZetaR | IMO, if something is filling up the NAND by putting stuff in /etc or /lib or /sbin, then it is wrong and needs to be fixed. I don't think it is the job of mount to fix it. But this is your project, just sharing my opinion. |
| 18:15.57 | stryngs | KotCzarny: If this goes mainstream, then you can put it on your resume. |
| 18:16.11 | KotCzarny | stryngs, unlikely |
| 18:16.15 | stryngs | ZetaR: That is exactly the feedback I want. |
| 18:16.17 | KotCzarny | (resume wise) |
| 18:16.27 | stryngs | ZetaR: Constructive Critisim with useful remarks. |
| 18:16.39 | ZetaR | :) |
| 18:16.53 | stryngs | Nokia-N900:/lib# du -h . | tail -n 1 |
| 18:16.53 | stryngs | 24.9M . |
| 18:16.58 | stryngs | thats 24.9M |
| 18:17.03 | KotCzarny | i think optification was a quick and dirty way of 'deb needs a fixing' |
| 18:17.15 | stryngs | KotCzarny: It was |
| 18:17.25 | stryngs | KotCzarny: it did the job, but it's time to update how we do things |
| 18:17.33 | stryngs | Alright, enough chattering from me, let me make Part III happen |
| 18:17.42 | stryngs | FHS -vs- Bind Mounting.......... FIGHT! |
| 18:17.49 | KotCzarny | i wonder if emmc could take the beating of having fs on it |
| 18:18.23 | stryngs | KotCzarny: You mean full fs? |
| 18:18.27 | KotCzarny | yes |
| 18:18.29 | ZetaR | stryngs: du without pipe: "du -h -d 0 /etc" |
| 18:18.30 | KotCzarny | with ext3/4 |
| 18:18.30 | stryngs | KotCzarny: iirc, No. |
| 18:18.47 | KotCzarny | hum |
| 18:18.50 | stryngs | KotCzarny: Too slow was what I heard. |
| 18:18.58 | KotCzarny | slowness doesnt bother me |
| 18:19.02 | stryngs | KotCzarny: Performance issue, but, why the hell can't we try |
| 18:19.03 | KotCzarny | flash wear do |
| 18:19.45 | KotCzarny | when i get my n900, im going for a 'boot os in flash, full os in sd' |
| 18:19.55 | KotCzarny | and using emmc for media storage only |
| 18:20.02 | stryngs | What if a user can't use their SD card. |
| 18:20.15 | stryngs | KotCzarny: I know you can, but then your idea only applies to those who have working SD cards =( |
| 18:20.20 | stryngs | KotCzarny: Not a universal approach |
| 18:20.21 | KotCzarny | then its only changing pivot_root from sd mount to emmc mount |
| 18:20.32 | KotCzarny | it even could be boot menu selectable |
| 18:21.01 | stryngs | KotCzarny: So let's make it happen =) |
| 18:21.20 | KotCzarny | dont mind me too much, i had few ideas on my own for a long time, just didnt have the poor n900 for beatings |
| 18:21.43 | stryngs | KotCzarny: I'll saccrifice mine for the cause =) |
| 18:22.29 | KotCzarny | if i'll be successfull there will be my own flashable image for testing |
| 18:23.25 | ZetaR | Under a fairly default Debian install: /bin 6.8MB, /etc 4.0MB, /sbin 8.5MB, /var 849MB (???), /boot 33MB, /home 9.1GB, /lib 170M (why?), /root 25kB, /tmp 44kB, /usr 2.6GB |
| 18:23.46 | KotCzarny | lib is big because it has to have most of glibc |
| 18:23.49 | KotCzarny | and kernel modules |
| 18:24.08 | ZetaR | Ah. Let me check my N900 to see how big it is on that. |
| 18:24.10 | KotCzarny | unless you move boot process to klibc or uclibc there is no way around |
| 18:24.22 | *** join/#maemo protem (~protem@unaffiliated/protem) |
| 18:24.47 | KotCzarny | on my slackware /lib is 99M |
| 18:25.01 | Sicelo | and /var is also big on regular distro for log files .. they grow real fast. maemo doesn't keep them, except one or two |
| 18:25.02 | KotCzarny | and most of it is in /lib/modules |
| 18:25.20 | KotCzarny | <PROTECTED> |
| 18:25.30 | ZetaR | Yeah, I thought it might be log files, but it still seems huge. |
| 18:25.32 | KotCzarny | if you have setup logrotate with compression its not that big |
| 18:25.35 | Sicelo | in fact, there can even be "config" files in /var |
| 18:25.46 | KotCzarny | sicelo, /var/cache |
| 18:25.50 | KotCzarny | most likely hogs it |
| 18:26.15 | KotCzarny | and if you have mailer/printer, then /var/spool |
| 18:28.25 | ZetaR | On my N900: /bin 964k, /etc 5.9M, /sbin 1.9M, /var 26M, /home 495M, /lib 23.4M, /root 16k, /tmp 80k, /usr 245.2M |
| 18:28.45 | KotCzarny | use -x for du |
| 18:29.07 | KotCzarny | so it wont go across fs boundaries |
| 18:29.44 | ZetaR | I didn't want it to. This way it doesn't care about /opt and such but rather tells you where files are in the hierarchy. |
| 18:30.07 | KotCzarny | oh well |
| 18:30.52 | KotCzarny | my /usr is 289M and 237M with -x |
| 18:31.05 | ZetaR | i.e. /usr and /home need to be eMMC, but everything else can probably be NAND. Not sure about what to do with /var on the N900. |
| 18:31.57 | KotCzarny | you have to use emmc |
| 18:32.16 | KotCzarny | otherwise your deb catalogs would hog space |
| 18:32.23 | KotCzarny | also intermediate package downloads |
| 18:32.28 | Sicelo | <PROTECTED> |
| 18:32.55 | ZetaR | Are /var and /home safe to symbolically link, rather than doing bind mounts? AFAICT, that is what symbolic links are for. |
| 18:32.59 | KotCzarny | thats because /var/cache is symlinked to /opt |
| 18:33.19 | KotCzarny | symlinks are a bit slower than bind mounts |
| 18:33.25 | KotCzarny | not that much tho |
| 18:33.29 | ZetaR | Ah. |
| 18:33.36 | KotCzarny | but there is still danger of circular loops |
| 18:34.09 | ZetaR | Only if you are careless. |
| 18:35.11 | KotCzarny | hmm |
| 18:35.11 | ZetaR | I know some programs try and resolve the absolute path and such. Not sure when this becomes a problem. |
| 18:35.38 | KotCzarny | right now we are already having big hunk of fs on emmc |
| 18:37.21 | KotCzarny | im more and more inclined to move it to emmc or ssd in whole |
| 18:37.31 | Sicelo | SSD :) |
| 18:37.38 | KotCzarny | :) |
| 18:37.54 | KotCzarny | piggybacked 1.8" ssd ? ;) |
| 18:38.12 | Sicelo | which was the Nokia with a hard-drive by the way? |
| 18:38.17 | KotCzarny | swap my b*tch up! |
| 18:38.59 | Sicelo | N91 |
| 18:39.35 | ZetaR | Just use a very small PATA drive! https://en.wikipedia.org/wiki/Microdrive |
| 18:39.46 | KotCzarny | nah, microdrives are slow |
| 18:39.52 | KotCzarny | ssd baby |
| 18:40.46 | KotCzarny | i think even cf cards are faster than microdrives |
| 18:41.07 | ZetaR | Microdrives are just more fun. |
| 18:41.16 | KotCzarny | had pcmcia one |
| 18:41.28 | KotCzarny | it was slow as hell |
| 18:41.41 | KotCzarny | parking head just about after every operation |
| 18:49.40 | *** join/#maemo AndrewX192 (~andrew@unaffiliated/andrewx192) |
| 18:50.45 | KotCzarny | btw. tracker is needed for people who use system image viewer/player |
| 18:51.04 | KotCzarny | (i dont so it doesnt bother me, just saying) |
| 18:52.05 | Sicelo | has learned to come to terms with it |
| 18:53.40 | *** join/#maemo xes_ (~xes@unaffiliated/xes) |
| 19:13.10 | *** join/#maemo florian (~fuchs@Maemo/community/contributor/florian) |
| 19:19.47 | *** join/#maemo Roth (~quassel@2601:18c:c700:f254:a0d9:e852:1505:3140) |
| 19:20.50 | *** join/#maemo Luke-Jr (~luke-jr@unaffiliated/luke-jr) |
| 19:25.56 | *** join/#maemo _rd (~rd@pD9E7C377.dip0.t-ipconnect.de) |
| 19:29.41 | DocScrutinizer05 | tracker SUCKS, so do all apps that rely on it. Braindamaged concept of a phantom filesystem |
| 19:29.52 | *** join/#maemo eMHa (~mh@p579DBF47.dip0.t-ipconnect.de) |
| 19:30.12 | DocScrutinizer05 | gnome invention, I guess |
| 19:30.31 | DocScrutinizer05 | or rather freedesktop |
| 19:31.00 | KotCzarny | nice invention, but tricky to get right |
| 19:32.11 | DocScrutinizer05 | tracker is fine for a "desktop document search engine" like err spotlight(?), abusing it for the primary and even only "filesystem" access method in any app is really braindead |
| 19:32.45 | Sicelo | yes, that's true. |
| 19:33.05 | Sicelo | the problem is the "apps" though, not tracker itself |
| 19:33.17 | DocScrutinizer05 | yes, of course |
| 19:33.27 | KotCzarny | and thats why oscp was born |
| 19:33.31 | KotCzarny | :) |
| 19:34.47 | Sicelo | Maemo's stock apps are definitely bad for not giving other other options besides tracker :) |
| 19:35.03 | KotCzarny | luckily we can have any app compiled/used |
| 19:35.18 | DocScrutinizer05 | that's a "apple me-too" attitude |
| 19:35.19 | Sicelo | since i don't like to have 10 apps for images, and 5 for music, etc, then I stick with tracker |
| 19:35.49 | DocScrutinizer05 | and I criticized that from very beginning of tracker, with maemo5 |
| 19:35.51 | Sicelo | otherwise i may as well go Android, and have 99 apps for sudoku :D |
| 19:36.10 | KotCzarny | sicelo, oscp can handle almost any file format |
| 19:36.25 | KotCzarny | (audio file format, that is) |
| 19:36.27 | Sicelo | :) i'm sure it can |
| 19:36.52 | KotCzarny | and oscv can handle most popular image ones |
| 19:36.58 | DocScrutinizer05 | it's about adding meta info to plain old unix filesystems |
| 19:37.27 | KotCzarny | even animated gifs and multipage tiffs/pdfs |
| 19:37.28 | DocScrutinizer05 | tracker is the wrong solution to an inexistent problem |
| 19:37.51 | KotCzarny | doc, tracker was for lazy-clicky people that didnt know where their files were |
| 19:37.57 | DocScrutinizer05 | trying to push a "filesystem agnostic" approach |
| 19:38.08 | DocScrutinizer05 | KotCzarny: *exactly* |
| 19:38.26 | Sicelo | i look at it as a database (which it is) |
| 19:38.36 | KotCzarny | its bad database |
| 19:38.46 | KotCzarny | good for ideal world |
| 19:38.49 | Sicelo | possibly, but works :) |
| 19:38.51 | KotCzarny | bad for real one |
| 19:38.52 | DocScrutinizer05 | >>users don't know what's a directory<< original text of some evangelist of that concept in maemo5 |
| 19:39.26 | Sicelo | has yet to see the real problem with tracker (besides the hogging cpu while indexing) |
| 19:39.35 | KotCzarny | umm |
| 19:39.42 | KotCzarny | my files are laid out nicely |
| 19:39.44 | DocScrutinizer05 | Sicelo: oh really? |
| 19:39.49 | KotCzarny | tracker just makes a mess out of them |
| 19:39.57 | Sicelo | but i agree 100% that apps which make tracker the only way to access files are broken |
| 19:40.04 | Sicelo | mess? how? |
| 19:40.09 | DocScrutinizer05 | Sicelo: pretty simple: have two mp3 of same metatags, one on eMMC and one on uSD |
| 19:40.17 | DocScrutinizer05 | have fun¡ |
| 19:40.38 | KotCzarny | sicelo: untagged files, some tagged badly |
| 19:40.43 | KotCzarny | but filenames/dirnames are ok |
| 19:40.48 | DocScrutinizer05 | Sicelo: another one: you keep your pr0n in a folder ~/.pr0n |
| 19:40.50 | Sicelo | i thought people have their files "laid out nicely" .. |
| 19:40.57 | DocScrutinizer05 | open up gallery |
| 19:41.01 | KotCzarny | now tracker categorizes them in different places |
| 19:41.17 | Sicelo | DocScrutinizer05: tracker won't index that pr0n. you know it. |
| 19:41.24 | DocScrutinizer05 | aha |
| 19:41.35 | KotCzarny | .files are hidden |
| 19:41.39 | KotCzarny | and .dirs |
| 19:41.40 | Sicelo | isn't that what you want? |
| 19:41.46 | DocScrutinizer05 | then maxe that ~/foobar |
| 19:41.54 | DocScrutinizer05 | or *whatever* you like |
| 19:42.04 | Sicelo | doesn't get DocScrutinizer05's argument |
| 19:42.26 | KotCzarny | tracker is superfluous and bad at what it has to achieve |
| 19:42.54 | DocScrutinizer05 | the argument is: there's ZILCH tools to *group* your tracker-indexed stuff in a meaningful manageable way |
| 19:43.11 | DocScrutinizer05 | or what KotCzarny said |
| 19:43.23 | *** join/#maemo Luke-Jr (~luke-jr@unaffiliated/luke-jr) |
| 19:43.58 | Sicelo | if we think tracker means we should forget file organization, then that's where the real problem is |
| 19:44.17 | DocScrutinizer05 | I honestly don't _need_ tracker, it's crap for the purpose to select which files get shown in gallery or mediaplayer |
| 19:44.30 | KotCzarny | no, problem is DIRECTORY/FILE structure was invented for file organization |
| 19:44.34 | Sicelo | i still organize my files and directories as best as i can |
| 19:44.45 | KotCzarny | metadata is nice only if ALL files have it proper |
| 19:45.05 | KotCzarny | or if you have magic algo that can guess author/title from the content |
| 19:45.07 | *** join/#maemo sla_erick_ (a2d82e79@gateway/web/freenode/ip.162.216.46.121) |
| 19:45.20 | sla_erick_ | ~sb |
| 19:45.20 | infobot | somebody said scratchbox was a cross-compiling system that uses binfmt_misc, rpc calls, and an nfs mount to make a cross-build appear to be 100% native, and is found at http://www.scratchbox.org/, hosted by maemo now. Also at http://maemo.merlin1991.at/files/SB |
| 19:45.58 | Sicelo | as long as tracker is there on the N900, rather use it .. it's already using up your resources anyway :) |
| 19:46.08 | *** join/#maemo LauRoman (~LauRoman@5-14-16-10.residential.rdsnet.ro) |
| 19:46.11 | Sicelo | if you've removed it, then .. different story |
| 19:46.22 | DocScrutinizer05 | tracker as used in maemo reinvents the wheel (or rather the filesystem with all the goodies it has) - *very* poorly |
| 19:46.23 | KotCzarny | sicelo, i've disabled it on mine |
| 19:46.29 | Sicelo | uninstalled? |
| 19:46.33 | KotCzarny | disabled |
| 19:46.37 | KotCzarny | not tracking anything |
| 19:46.48 | sla_erick_ | I downloaded the SDK 1.1.2 from here: ftp://ftp.informatik.hu-berlin.de/pub/Mirrors/ftp.troll.no/QT/qtsdk/, but it doesnt contain the Maemo toolchain. There is a tool to download the toolchain but the servers are down. |
| 19:46.51 | Sicelo | so my point is correct .. it's still eating up your space :) |
| 19:46.57 | KotCzarny | i didnt try uninstalling it as most likely bazillion of debs depend on it |
| 19:47.07 | Sicelo | maemo's stock image viewer .. still eating up your space too |
| 19:47.09 | KotCzarny | eating up space is passive |
| 19:47.11 | sla_erick_ | Does someone knows how to download Maemo toolchain and integrate it to the SDK 1.1.2? |
| 19:47.20 | KotCzarny | i care about function and battery life |
| 19:47.33 | DocScrutinizer05 | sla_erick_: nobody ever did this afaik |
| 19:48.15 | DocScrutinizer05 | oops, sorry |
| 19:48.17 | Sicelo | this is precisely what i don't want ... having many apps for each of these functions. if i can remove the stock media player, image viewer, etc, then i remove tracker immediately |
| 19:48.32 | DocScrutinizer05 | of course it been done, but actually you're better off just using a VM |
| 19:48.43 | DocScrutinizer05 | http://maemo.merlin1991.at/files/SB |
| 19:48.50 | KotCzarny | sicelo, dependency can be as simple as depending on some lib, even if particular deb doesnt use tracker |
| 19:48.54 | sla_erick_ | DocScrutinizer05 do you know any Qt SDK that comes ready for developing and deploying to the N900, I know that you are not a developer, just wondering |
| 19:48.57 | *** join/#maemo kerio (~kerio@dank.ninja) |
| 19:49.55 | DocScrutinizer05 | err all should be in http://maemo.merlin1991.at/files/SB already. And what's missing should be installable from maemo-sdk and maemo-tools repos |
| 19:50.00 | Sicelo | yes indeed KotCzarny. |
| 19:50.23 | sla_erick_ | fair enough, thanks :) |
| 19:51.53 | KotCzarny | just cant wait to get hacking once my second n900 comes |
| 19:52.21 | Sicelo | DocScrutinizer05: wasn't there a BM image released at some point? |
| 19:52.39 | DocScrutinizer05 | hmm? |
| 19:52.53 | DocScrutinizer05 | BM image of what? |
| 19:53.52 | Sicelo | i guess not then |
| 19:54.35 | DocScrutinizer05 | I don't know of any publicly available BM backup files so far, though they would be extremely cool to have. Just everybody been too worried about disclosing privacy-related info and too busy to scan and clean the BM tarball |
| 19:55.40 | DocScrutinizer05 | I fail to completely understand the question though, what's a "BM image"? |
| 19:55.47 | *** join/#maemo esaym153 (~esaym153@75-1-182-8.lightspeed.snantx.sbcglobal.net) |
| 19:56.09 | DocScrutinizer05 | there's a fiasco image that contains BM already, see |
| 19:56.11 | DocScrutinizer05 | ~bm |
| 19:56.12 | infobot | i guess backupmenu is http://talk.maemo.org/showthread.php?t=63975 |
| 19:57.30 | DocScrutinizer05 | or are you asking about a bm image that contains Qt SDK ? Sorry, you lost me |
| 19:58.45 | *** join/#maemo ced117 (~ced117@opensuse/member/ced117) |
| 19:59.57 | KotCzarny | doc, what are your thoughts about running whole os from emmc? |
| 20:00.00 | KotCzarny | or sd? |
| 20:00.01 | DocScrutinizer05 | oooooh, stryngs!! you *ever* used osso-backup to restore a system on N900? it basically is a very smart way to have a opt-in/out list of apps to install from repos |
| 20:00.11 | Sicelo | ah yes .. that one in the link .. tha's what i meant |
| 20:00.46 | DocScrutinizer05 | KotCzarny: I'm no fan of moving more than necessary to eMMC or even uSD |
| 20:01.10 | KotCzarny | but for now we are already running most things from there |
| 20:01.35 | KotCzarny | so i guess nand would be nice place for rescue/boot etc, and os on emmc/sd |
| 20:01.37 | DocScrutinizer05 | well, then are we facing an XY problem? |
| 20:02.06 | KotCzarny | because most things in use are not on nand |
| 20:02.14 | DocScrutinizer05 | why not the other way around? rescue system on eMMC and normal system unchanged |
| 20:02.16 | KotCzarny | so, why not? |
| 20:04.17 | DocScrutinizer05 | A) precisely define the problem at hand, B) check if those are *real* problems and think about solutions if they are real. only then C) design and implement the fix |
| 20:05.11 | KotCzarny | a) fs fragmentation |
| 20:05.30 | DocScrutinizer05 | how's that a problem? |
| 20:05.42 | DocScrutinizer05 | I don't even understand the term |
| 20:05.48 | KotCzarny | little space on / without optification hack |
| 20:06.17 | DocScrutinizer05 | there been a solution to that already and you mentioned it |
| 20:06.37 | DocScrutinizer05 | so your *real* problem seems to be: you don't like optification-hack |
| 20:06.40 | DocScrutinizer05 | I agree |
| 20:06.49 | DocScrutinizer05 | ~optification |
| 20:06.49 | infobot | optification is a inventive duct tape workaround to reclaim space in fs root, done due to the fact the systeminit *and* partitioning is FUBAR, http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Packaging,_Deploying_and_Distributing/Installing_under_opt_and_MyDocs, or ""OMG - I wish they looked into FHS and moved /usr to eMMC"", http://www.pathname.com/fhs/pub/fhs-2.3.html#PURPOSE2 bullet1,2 and fhs-2.3.html#PURPOSE16 dot3" |
| 20:07.05 | KotCzarny | but my real question is, can emmc take the wear from being used for os? |
| 20:07.09 | DocScrutinizer05 | ""OMG - I wish they looked into FHS and moved /usr to eMMC"" |
| 20:07.15 | DocScrutinizer05 | yes, it can |
| 20:07.17 | KotCzarny | and i think about ext3/4 |
| 20:07.42 | DocScrutinizer05 | you need to adjust operation parameters aka options of ext3/ext4 |
| 20:08.10 | DocScrutinizer05 | you generaly don't want journal usually. And you want noatime etc |
| 20:08.17 | *** join/#maemo darkschneider (~gab@93-32-59-44.ip32.fastwebnet.it) |
| 20:08.30 | KotCzarny | yes, i run noatime everywhere |
| 20:08.41 | KotCzarny | but i would like journal too |
| 20:09.00 | DocScrutinizer05 | yournal is a *very* bad idea on flash storage |
| 20:09.18 | KotCzarny | for flash storage without wear leveling |
| 20:09.36 | KotCzarny | or with heavy writes |
| 20:09.46 | KotCzarny | hum |
| 20:10.00 | DocScrutinizer05 | think about what journal does, and you'll see it's not compatible with the wy how flash works |
| 20:10.16 | KotCzarny | yes, constant writing at limited space |
| 20:10.44 | DocScrutinizer05 | you can't rewrite aka "extend" a file on flash |
| 20:11.43 | DocScrutinizer05 | each byte written to journal causes *complete* jounal to get rewritten on flash, then eventually read out again and transformed into *real* filesystem actions |
| 20:13.28 | KotCzarny | well |
| 20:13.56 | KotCzarny | then metadata journal maybe? |
| 20:13.57 | DocScrutinizer05 | anyway I heard ext4 performs extremely well on eMMC, with the right parameters |
| 20:14.31 | DocScrutinizer05 | metadata journal might make sense. i'm no fs expert |
| 20:15.32 | DocScrutinizer05 | evaluation of performance and stability of a fs on flash/SSD is a very tricky and involved task |
| 20:24.06 | *** join/#maemo Oksanaa (~chatzilla@Maemo/community/council/Wikiwide) |
| 20:24.51 | KotCzarny | another question is how stable was ext4 in 2.6.28 |
| 20:29.18 | ZetaR | What about btrfs instead of ext? |
| 20:35.05 | ZetaR | Copy on write gives you the FS protection that the journal does, but doesn't have the problems with flash that a journal would. |
| 20:35.13 | KotCzarny | same question |
| 20:35.20 | KotCzarny | how stable it was in 2.6.28? |
| 20:35.26 | KotCzarny | or, can it be backported? |
| 20:35.59 | ZetaR | Hm, let me see if I can find the answer to that. |
| 20:38.08 | ZetaR | Yeah, it's not stable for that version. |
| 20:41.22 | Maxdamantus | 05:00:02 < DocScrutinizer05> iirc it does a lazy-umount (or somesuch), and then cuts the the power to uSD card, so it won't get damaged - or device getting damaged - when removing the card and inserting another one |
| 20:41.27 | Maxdamantus | It doesn't. |
| 20:42.22 | Maxdamantus | unless you mean a lazy unmount after the card has been forcefully made inaccessible. |
| 20:44.52 | Maxdamantus | It might safely power down the card, so it doesn't result in some sort of hardware damaged, but there's no way to prevent filesystem damage from non-safe removal. |
| 20:46.01 | DocScrutinizer05 | yes, for other fs than fat32 that could be a problem |
| 20:46.43 | Maxdamantus | fat32 is still subject to similar corruption, unless maybe you mount it with -o sync |
| 20:46.52 | DocScrutinizer05 | even for fat32 they do a fsck afaik, to repair any such damage |
| 20:47.26 | Maxdamantus | "any such damage" can't be easily detected on fat32. |
| 20:47.30 | Maxdamantus | it doesn't have a journal. |
| 20:47.50 | DocScrutinizer05 | sorry afk |
| 20:48.53 | Maxdamantus | You could scan all the metadata for inconsistency and try to fix that, but if you get corruption that doesn't lead to inconsistency (at the filesystem level), there's no way to detect where such corruption might be. |
| 20:49.12 | DocScrutinizer05 | so? |
| 20:49.27 | Maxdamantus | So you can end up with partially written files. |
| 20:49.33 | DocScrutinizer05 | I just can tell you what's in there |
| 20:49.39 | Maxdamantus | which look perfectly valid from the filesystem's perspective. |
| 20:50.13 | DocScrutinizer05 | yes, I know all that. Thanks anyway |
| 20:51.05 | *** join/#maemo xray256 (~xray256@2.220.98.40) |
| 20:52.40 | Maxdamantus | We should all be using copy-on-write filesystems by now anyway -_- |
| 20:52.47 | kerio | should we, really |
| 20:52.51 | Maxdamantus | Yes. |
| 20:53.05 | Maxdamantus | even on ext3, you can't recover from corruption. |
| 20:53.06 | KotCzarny | well |
| 20:53.06 | DocScrutinizer05 | http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Packaging,_Deploying_and_Distributing/Installing_under_opt_and_MyDocs doesn't explicitly mention it, but I could figure that apps who write to uSD are supposed to listen to dbus signals and act accordingly |
| 20:53.18 | Maxdamantus | you can only fix filesystem inconsistency, and detect that corruption might have happened. |
| 20:53.24 | Maxdamantus | unless you use full journalling. |
| 20:53.33 | Maxdamantus | (ie, where you write the data twice) |
| 20:53.40 | KotCzarny | there is always zfs :P |
| 20:53.42 | Maxdamantus | (ext3 and ext4) |
| 20:53.54 | Maxdamantus | Yes, ZFS handles it, but you can't practically run that on a phone atm. |
| 20:54.03 | Maxdamantus | btrfs is practical for usage on phones though. |
| 20:54.15 | KotCzarny | i had some fun with pivot_root'ed zfsfuse |
| 20:54.20 | KotCzarny | it was unstable tho |
| 20:54.41 | DocScrutinizer05 | even journalling doesn't solve your problem, which is: "you cannot write to a medium that's not connected to the system" |
| 20:54.58 | Maxdamantus | That's not the problem. |
| 20:54.59 | KotCzarny | raid1 |
| 20:55.03 | KotCzarny | or 5 |
| 20:55.05 | Maxdamantus | That's another problem. |
| 20:55.13 | Maxdamantus | raid1 and raid5 are very bad. |
| 20:55.23 | Maxdamantus | They just make this worse. |
| 20:55.32 | KotCzarny | how so? |
| 20:55.36 | Maxdamantus | Write holes. |
| 20:55.47 | KotCzarny | unless i mixed up numbers |
| 20:56.02 | KotCzarny | i meant the one with data duplication |
| 20:56.20 | Maxdamantus | If you disconnect two raid1 drives, you don't know that they're going to be in the same state when you reconnect them. |
| 20:56.41 | KotCzarny | yes, but point is, as long you dont disconnect both, its all good |
| 20:56.43 | Maxdamantus | unless you do journalling at the RAID level or do an entire scrub afterwards. |
| 20:57.07 | Maxdamantus | but even when you get it back into sync, you still have the exact same corruption issues on the filesystem. |
| 20:57.48 | Maxdamantus | .. or if you have a hardware RAID controller with lots of NVRAM to buffer writes over power cycles. |
| 20:58.13 | Maxdamantus | but that's a horrible solution for something that can be solved using a CoW filesystem. |
| 20:58.19 | KotCzarny | pity they dont make internally daisychained raided sd cards |
| 20:58.20 | KotCzarny | :) |
| 20:58.31 | KotCzarny | though its not it, hum |
| 20:59.45 | DocScrutinizer05 | listen folks, when you interrupt a write to a storage medium, the data gets corrupted, no matter what. When you want to write data to a removable meduim, it's your responsibility to make sure the medium doesn't get removed while you write. If you can't guarantee that, you have to live with data not getting written or even getting crippled. Unrelated to this, N900 has means that avoid *physical* damage to uSD or N900 itself: powering down |
| 20:59.47 | DocScrutinizer05 | the card as soon as battery lid gets opened, which enables two threats - uSD card removal and inadvertent battery removal (while writes happen) |
| 21:00.25 | Maxdamantus | Yes, but you can at least make sure the filesystem is in some previously intended state. |
| 21:00.34 | Maxdamantus | using either CoW or full data journalling. |
| 21:00.45 | Maxdamantus | the latter means you write everything twice. |
| 21:00.59 | KotCzarny | or just minimize writes |
| 21:01.53 | DocScrutinizer05 | aha, writing twice and mimimize writing serve same purpose? hardly. I prefer the latter |
| 21:01.55 | Maxdamantus | Databases like sqlite3 are written such that they can operate under that assumption. |
| 21:02.34 | Maxdamantus | If you're removing a non-journalled drive with a sqlite3 database on it in the middle of a write, there's no guarantee your database isn't corrupt. |
| 21:02.57 | KotCzarny | removing medium during writes is BAD IDEA |
| 21:03.01 | KotCzarny | no matter what |
| 21:03.03 | Maxdamantus | if it's fully journalled or CoW, you do get that guarantee: the database might have lost the last few seconds, but it won't be corrupt. |
| 21:03.16 | Maxdamantus | Of course, but it hapeens. |
| 21:03.20 | Maxdamantus | So it should be handled. |
| 21:03.24 | DocScrutinizer05 | journalling does NOT help writing that very data to the medium. It only helps not even *trying* to write aborted transactions to the medium |
| 21:04.19 | DocScrutinizer05 | from an app's perspective that photo doesn't get stored nevertheless |
| 21:05.10 | DocScrutinizer05 | plus journaling not only doubles but at least triples writing to media |
| 21:06.05 | Maxdamantus | If you're doing full journalling (data included) it basically means double. |
| 21:06.25 | Maxdamantus | There's of course extra metadata around the journalling itself, but that's not going to be as large as writing the data twice. |
| 21:06.25 | DocScrutinizer05 | aha, and who's deleting the jounal after commit? |
| 21:06.26 | kerio | yea but how can i avoid not unplugging the uSD if i remove the back cover? |
| 21:06.52 | Maxdamantus | kerio: modify the kernel module. |
| 21:06.53 | DocScrutinizer05 | I'm not talking about volume, i'm talking about IO ops |
| 21:07.02 | kerio | Maxdamantus: ayy lmao |
| 21:07.11 | KotCzarny | um |
| 21:07.18 | KotCzarny | or keeping sd journal on emmc |
| 21:07.20 | KotCzarny | :) |
| 21:07.46 | DocScrutinizer05 | KotCzarny: that might be a nice idea |
| 21:07.57 | Maxdamantus | If it's a full journal, that's going to halve write speeds. |
| 21:07.58 | DocScrutinizer05 | I already pondered that approach |
| 21:08.16 | KotCzarny | i wouldnt bother personally tho |
| 21:08.28 | KotCzarny | user is the weakest link |
| 21:08.45 | Maxdamantus | It wouldn't really be any better than journalling on the same SD card, since the write speed on the N900 doesn't seem to be bottlenecked by the SD card. |
| 21:08.51 | Maxdamantus | but by the controller. |
| 21:08.59 | Maxdamantus | which the eMMC is also on. |
| 21:09.06 | DocScrutinizer05 | add an electric lock to the battery cover ;-D |
| 21:09.16 | KotCzarny | electroshocking lock? |
| 21:09.19 | KotCzarny | :) |
| 21:09.27 | DocScrutinizer05 | only unlocks when uSD is properly unmounted |
| 21:09.35 | Maxdamantus | https://talk.maemo.org/showpost.php?p=1457369&postcount=4 |
| 21:09.45 | KotCzarny | such locks would be a pita |
| 21:10.06 | KotCzarny | last time when some app locked my cdtray i was .. unhappy |
| 21:10.35 | DocScrutinizer05 | cya l8r |
| 21:12.23 | Maxdamantus | (that bottleneck comment is assuming you have an SD card that is meant to be able to write at more than 8 MiB/s or so, can't remember the actual number) |
| 21:12.35 | Maxdamantus | tries. |
| 21:15.17 | *** join/#maemo kerio (~kerio@dank.ninja) |
| 21:19.26 | Maxdamantus | seems to be about 6 MiB/s |
| 21:19.56 | KotCzarny | what is iops@512b for internal flash? |
| 21:20.01 | KotCzarny | and for emmc? |
| 21:20.18 | Maxdamantus | I don't want to try that on the flash. |
| 21:20.37 | KotCzarny | test can be short, 10-20s |
| 21:21.02 | KotCzarny | there are sd cards capable of ~100 iops |
| 21:21.30 | KotCzarny | most are in 0.1-10 range tho |
| 21:24.43 | Maxdamantus | Okay, not 6 MiB/s .. can do 13 MiB/s |
| 21:26.07 | Maxdamantus | and yeah, that's shared across the SD card an eMMC. |
| 21:26.34 | Maxdamantus | oh, no, nvm .. I'm writing 11 MiB/s to the SD card now and 9 MiB/s to the eMMC. |
| 21:28.53 | KotCzarny | try reading to one and writing to other |
| 21:30.40 | Maxdamantus | reading from eMMC at 14 MiB/s, writing to SD card at 10 MiB/s |
| 21:31.57 | KotCzarny | so they use independent controllers in chip |
| 21:32.40 | KotCzarny | arm chips usually have 2-4 mmc controllers |
| 21:33.11 | Maxdamantus | Maybe it would be nice to use btrfs with its "raid0" mode. |
| 21:33.14 | KotCzarny | but most of the time only 1 is connected to some slot |
| 21:36.13 | Maxdamantus | actually, the things I said were inverted: when I said SD card before I meant eMMC and vice versa. |
| 21:45.41 | *** join/#maemo lobito (~lobito@190.177.215.161) |
| 21:53.05 | *** join/#maemo kerio (~kerio@dank.ninja) |
| 22:34.31 | ZetaR | To answer the question about ext4 stability: "On 11 October 2008, the patches that mark ext4 as stable code were merged in the Linux 2.6.28 source code repositories, denoting the end of the development phase and recommending ext4 adoption." (Wikipedia) |
| 23:11.11 | stryngs | DocScrutinizer05: I've never used osso-backup for those purposes. |
| 23:11.27 | DocScrutinizer05 | you should give it a try |
| 23:12.15 | DocScrutinizer05 | (ext4) we got stable ext4 support on maemo |
| 23:12.47 | DocScrutinizer05 | not for rootfs though |
| 23:17.00 | stryngs | afk for a bit, bbib |
| 23:20.19 | Maxdamantus | Why not rootfs? |
| 23:21.07 | Maxdamantus | Just in terms of it not being there by default? |
| 23:51.46 | *** join/#maemo LauRoman (~LauRoman@5-14-16-10.residential.rdsnet.ro) |
| 23:54.46 | ZetaR | stryngs: I have determined the optimal ext4 parameters for the N900's eMMC geometry: "-b 4096 -E stride=2,stripe-width=256". This will make ext4 respect the write block size of 8192, and stripe the eMMC in sections respecting the erase group size of 256 write blocks. |