| 00:12.37 | *** join/#maemo-ssu unclouded (~neil@2001:4428:200:80fc:c076:8c29:88fc:68a3) |
| 01:12.03 | *** join/#maemo-ssu LaoLang_cool (~LaoLang_c@14.151.31.232) |
| 01:29.50 | *** join/#maemo-ssu amiconn (amiconn@rockbox/developer/amiconn) |
| 03:01.29 | *** join/#maemo-ssu M4rtinK (~M4rtinK@ip-86-49-81-87.net.upcbroadband.cz) |
| 03:10.14 | *** join/#maemo-ssu amiconn_ (quassel@rockbox/developer/amiconn) |
| 03:34.17 | *** join/#maemo-ssu keesj (~keesj@dellpc132.few.vu.nl) |
| 04:04.27 | *** join/#maemo-ssu DocScrutinizer05 (~HaleBopp@openmoko/engineers/joerg) |
| 04:18.24 | *** join/#maemo-ssu sunny_s (~sunny_s@86.57.254.135) |
| 04:29.00 | *** join/#maemo-ssu M13 (~Miranda@83.149.35.95) |
| 05:17.51 | *** join/#maemo-ssu LauRoman (~LauRoman@5-14-92-176.residential.rdsnet.ro) |
| 06:18.58 | *** join/#maemo-ssu Milhouse (~Milhouse@Maemo/community/contributor/Milhouse) |
| 06:31.32 | *** join/#maemo-ssu dhbiker (~dhbiker@95.87.145.172) |
| 07:17.16 | *** join/#maemo-ssu sunny_s (~sunny_s@86.57.254.135) |
| 08:03.45 | *** join/#maemo-ssu PaulFertser (paul@2001:470:26:54b:250:70ff:fee7:41ec) |
| 08:58.57 | *** join/#maemo-ssu Natch_i (~Natch@c-fecee155.25-4-64736c10.cust.bredbandsbolaget.se) |
| 09:02.07 | *** join/#maemo-ssu ZogG (~zoggrules@bzq-79-182-189-221.red.bezeqint.net) |
| 09:02.07 | *** join/#maemo-ssu ZogG (~zoggrules@funtoo/user/ZogG) |
| 09:03.52 | *** part/#maemo-ssu keesj (~keesj@dellpc132.few.vu.nl) |
| 09:08.27 | *** join/#maemo-ssu M4rtinK (~M4rtinK@ip-86-49-81-87.net.upcbroadband.cz) |
| 09:10.31 | *** join/#maemo-ssu kolp (~quassel@212.255.224.121) |
| 09:38.52 | *** join/#maemo-ssu futpib (~futpib@89.106.197.48) |
| 09:43.20 | *** join/#maemo-ssu andre__ (~andre@ip-62-24-76-119.net.upcbroadband.cz) |
| 09:43.20 | *** join/#maemo-ssu andre__ (~andre@wikimedia/aklapper) |
| 10:25.20 | merlin1991 | freemangordon: pong |
| 10:31.34 | *** join/#maemo-ssu Martix (~martix@static-84-242-103-180.net.upcbroadband.cz) |
| 10:33.42 | *** join/#maemo-ssu lizardo (lizardo@nat/indt/x-fnifnxrspskluinb) |
| 10:59.50 | *** join/#maemo-ssu amiconn_ (amiconn@rockbox/developer/amiconn) |
| 11:16.57 | *** join/#maemo-ssu sunny_s (~sunny_s@86.57.254.135) |
| 11:56.46 | freemangordon | merlin1991: pong |
| 11:57.11 | merlin1991 | you pinged me ;) |
| 11:57.37 | freemangordon | merlin1991: yep. what are the problems of CSSU repo and who is aware of them? |
| 11:58.00 | merlin1991 | problem is that upload directory does not has proper permissions |
| 11:58.09 | merlin1991 | aware are the important people |
| 11:58.19 | freemangordon | merlin1991: do they have names? |
| 11:58.20 | freemangordon | :) |
| 11:58.21 | merlin1991 | we're basically waiting for a mail from X-Fade to get it up again |
| 11:58.29 | freemangordon | X-Fade? |
| 11:58.35 | merlin1991 | yes X-Fade |
| 11:59.24 | freemangordon | Why X-Fade, afaik repos are under community control. |
| 11:59.49 | freemangordon | that guy warfare is sysop |
| 12:00.00 | freemangordon | (iirc) |
| 12:00.11 | merlin1991 | freemangordon: I even have an account there |
| 12:00.35 | merlin1991 | but there is no trace of the garage group -- repoaccess sync on the servers |
| 12:00.47 | merlin1991 | I can upload with my maintainance account for now |
| 12:00.59 | merlin1991 | but only when I get back to vienna :) |
| 12:01.04 | merlin1991 | sitting in HEL on my way back |
| 12:01.09 | merlin1991 | 5 hours of airport |
| 12:01.11 | merlin1991 | AGAIN |
| 12:01.12 | merlin1991 | yay |
| 12:01.17 | *** join/#maemo-ssu sunny_s (~sunny_s@86.57.254.135) |
| 12:01.24 | freemangordon | merlin1991: ok, there are some problem. What i don;t understand is why you expect X-Fade ti fix that? |
| 12:01.30 | freemangordon | s/ti/to/ |
| 12:01.39 | merlin1991 | I expect X-Fade to tell us how it used to work |
| 12:01.45 | merlin1991 | so we can get it run the same again |
| 12:01.56 | merlin1991 | because otherwise chemist has no access whatsoever |
| 12:01.58 | freemangordon | merlin1991: for how long do you wait for that ansewr? |
| 12:02.17 | merlin1991 | I'll get -testing up to speed regardless of that answer |
| 12:03.15 | freemangordon | merlin1991: see, my point is that now we have control over the repos, I guess it is a god idea problems to be discussed with sysop, whoever he is |
| 12:03.34 | merlin1991 | freemangordon: we did discuss with him |
| 12:03.41 | merlin1991 | but he has no clue aswell |
| 12:04.01 | freemangordon | ooh, so he waits for X-Fade's answer too? |
| 12:04.17 | freemangordon | merlin1991: please, answer, for how long? |
| 12:04.53 | freemangordon | approximately :) |
| 12:05.22 | merlin1991 | I will upload to -testing when I get back home |
| 12:05.34 | merlin1991 | only -stable will have to wait for the answer |
| 12:05.50 | freemangordon | thats great, but this is not answering my question ;) |
| 12:06.04 | merlin1991 | well without X-Fades answer we can#t fix it |
| 12:06.12 | merlin1991 | only squash in some temporary solution |
| 12:06.46 | freemangordon | merlin1991: we don;t have expertise to assign some group/user rights? come on |
| 12:07.46 | merlin1991 | freemangordon: we don't have expertise to assign some group/user rights based on some group somewhere in garage |
| 12:08.08 | merlin1991 | we can by hand add people, but the whole idea was to have the webinterface to do this seamless without sysop interference |
| 12:08.37 | merlin1991 | there's a reason https://garage.maemo.org/projects/cssu-stable/ and https://garage.maemo.org/projects/cssu-testing/ exist |
| 12:09.32 | freemangordon | merlin1991: sure, UI is a good thing, but afaik we have 2 maintainers. I guess giving rights to them would't take that much time, even if done by hand |
| 12:09.46 | merlin1991 | yea |
| 12:09.58 | merlin1991 | anways I have enough acess to upload to -testing for now |
| 12:11.04 | freemangordon | merlin1991: and what about -stable? I know you know how fast was X-Fade when Nemein were paid, what do you thing, where in the priority list is Maemo now? |
| 12:11.13 | freemangordon | *think |
| 12:11.25 | *** join/#maemo-ssu andre__ (~andre@wikimedia/aklapper) |
| 12:11.34 | merlin1991 | I can upload to -stable aswell |
| 12:11.49 | freemangordon | can chem|st upload too? |
| 12:11.56 | merlin1991 | nope |
| 12:12.05 | freemangordon | :( |
| 12:12.41 | freemangordon | could a "temporary" solution be made for him? |
| 12:13.33 | freemangordon | merlin1991: or you will upload (this time only) to stable too? |
| 12:13.51 | merlin1991 | probably what you just said |
| 12:14.06 | freemangordon | ok |
| 12:14.34 | freemangordon | kerio: ping |
| 12:15.54 | freemangordon | kerio: I know you have a lot of free time :P. Do you wanna test fmrx-package? To check if we can push a new version, which will get installed on top of Nokia's? |
| 13:28.36 | Raimu | I can be aa tester too. |
| 13:28.38 | Raimu | -a |
| 13:32.47 | *** join/#maemo-ssu sunny_s (~sunny_s@86.57.254.135) |
| 13:38.52 | *** join/#maemo-ssu LauRoman (~LauRoman@5-14-92-176.residential.rdsnet.ro) |
| 13:40.41 | DocScrutinizer05 | [2013-03-26 13:50:47] <mashiara> Basic unix filesystem permissions and group mapping. Garage groups are |
| 13:40.42 | DocScrutinizer05 | [2013-03-26 13:50:48] <mashiara> created from the garage database by a cron job every 5 minutes or so. |
| 13:40.44 | DocScrutinizer05 | [2013-03-26 13:50:48] <mashiara> - Niels |
| 13:40.46 | DocScrutinizer05 | [2013-03-26 13:53:53] <merlin1991> well we do need that cronjob :D |
| 13:40.47 | DocScrutinizer05 | [2013-03-26 13:54:51] <mashiara> I suppose se script is found on garage |
| 13:40.49 | DocScrutinizer05 | [2013-03-26 13:55:16] <merlin1991> I'll have a look when I'm back in vienna |
| 13:41.15 | DocScrutinizer05 | FYI |
| 13:48.24 | DocScrutinizer05 | <<duck and cover! spam heading in>> |
| 13:48.31 | DocScrutinizer05 | # User and group export for midgard |
| 13:48.32 | DocScrutinizer05 | # |
| 13:48.34 | DocScrutinizer05 | 35 * * * * root /root/garage_maintenance/garage_executer.sh midgard/create_users_csv.php /var/tmp/gforge_users.csv |
| 13:48.35 | DocScrutinizer05 | 35 * * * * root /root/garage_maintenance/garage_executer.sh midgard/create_groups_csv.php /var/tmp/gforge_groups.csv |
| 13:48.37 | DocScrutinizer05 | 35 * * * * root /root/garage_maintenance/garage_executer.sh midgard/create_members_csv.php /var/tmp/gforge_members.csv |
| 13:48.38 | DocScrutinizer05 | # script for autobuilder. Updates email addresses from csv file to passwd |
| 13:48.40 | DocScrutinizer05 | 50 * * * * root /var/tmp/uui /var/tmp/gforge_users.csv > /dev/null 2>&1 |
| 13:48.41 | DocScrutinizer05 | #create system accounts from garage and sync to drop |
| 13:48.43 | DocScrutinizer05 | */10 * * * * root /usr/local/bin/add_groups_users_git_ssh.sh > /tmp/add_groups_users_git_ssh.log dev/null 2>&1 |
| 13:55.40 | *** join/#maemo-ssu arcean (~Tomek@apn-46-169-246-127.dynamic.gprs.plus.pl) |
| 14:09.34 | DocScrutinizer05 | merlin1991: http://privatepaste.com/fe7f618971 |
| 14:12.21 | DocScrutinizer05 | merlin1991: no group cssu-testing or cssu-devel |
| 14:12.46 | DocScrutinizer05 | err cssu-stable |
| 14:16.42 | merlin1991 | DocScrutinizer05: what exactly is that privatepaste? |
| 14:17.02 | DocScrutinizer05 | tmp/add_groups_users_git_ssh.log |
| 14:17.08 | DocScrutinizer05 | excerp |
| 14:17.37 | merlin1991 | hm probably generated from https://garage.maemo.org/projects/cssu/ |
| 14:17.49 | DocScrutinizer05 | obviously |
| 14:17.53 | merlin1991 | but that's not what we want we want the cssu-testing and -stable bits |
| 14:17.54 | merlin1991 | arf |
| 14:18.14 | DocScrutinizer05 | yes, and those are not even mentioned in that log |
| 14:18.41 | merlin1991 | perfect :/ |
| 14:18.57 | DocScrutinizer05 | which is a bit strange, since i'd think they are garage groups like all the other 544 groups processed in that log |
| 14:18.58 | merlin1991 | possibly the reason why the upload never worked for chemis? |
| 14:19.20 | DocScrutinizer05 | yep, definitely |
| 14:19.22 | merlin1991 | simply the wrong group at work? |
| 14:19.48 | DocScrutinizer05 | nfc what /usr/local/bin/add_groups_users_git_ssh.sh does exactly |
| 14:19.59 | merlin1991 | I'll look into that |
| 14:20.09 | merlin1991 | at least now we have a proper starting poing :) |
| 14:20.18 | merlin1991 | s/poing/point/ |
| 14:20.19 | DocScrutinizer05 | but to me it seems it parses *all* garage groups and creates user accounts for each such group |
| 14:20.30 | DocScrutinizer05 | but it's missing out on cssu-s and cssu-t |
| 14:21.27 | DocScrutinizer05 | real n*f*c what makes those two groups different |
| 14:21.31 | *** join/#maemo-ssu M4rtinK (~M4rtinK@ip-86-49-81-87.net.upcbroadband.cz) |
| 14:21.37 | merlin1991 | I'll have a look |
| 14:21.52 | merlin1991 | a little bit of digging should bring up everything :) |
| 14:22.00 | DocScrutinizer05 | yep, sure |
| 14:22.13 | DocScrutinizer05 | I'd appreciate when you take over here |
| 14:22.23 | DocScrutinizer05 | ping me when you need help with permissions |
| 14:23.10 | merlin1991 | will probably need help for midgard/create_groups_csv.php which seems to sit inside /root/*, but can't tell yet because I'll start digging in vienna |
| 14:23.56 | DocScrutinizer05 | ooooh, groups are from groups.csv?? |
| 14:24.27 | DocScrutinizer05 | then it's highly likely that cssu-t|s are missing in there |
| 14:24.28 | merlin1991 | probably |
| 14:26.01 | DocScrutinizer05 | gforge_groups.csv 122075/119K 100% |
| 14:26.03 | DocScrutinizer05 | "cssu-testing";"cssu-testing uploaders";"cssu-testing.garage.maemo.org";"1"; |
| 14:26.04 | DocScrutinizer05 | "cssu-stable";"cssu-stable uploaders";"cssu-stable.garage.maemo.org";"1"; |
| 14:26.06 | DocScrutinizer05 | " |
| 14:27.15 | DocScrutinizer05 | (for reference:) |
| 14:27.17 | DocScrutinizer05 | "sleepscreen";"Sleep Screen Changer";"sleepscreen.garage.maemo.org";"1"; |
| 14:27.19 | DocScrutinizer05 | "ubi";"Ubi";"ubi.garage.maemo.org";"1"; |
| 14:27.20 | DocScrutinizer05 | "pengupop-maemo5";"Pengupop";"pengupop-maemo5.garage.maemo.org";"1"; |
| 14:29.17 | DocScrutinizer05 | ... |
| 14:29.22 | DocScrutinizer05 | gforge_members.csv 20282/138K 14% |
| 14:29.23 | DocScrutinizer05 | "chemist";"cssu";"A";"Admin"; |
| 14:29.25 | DocScrutinizer05 | "chemist";"cssu-stable";"A";"Admin"; |
| 14:30.49 | DocScrutinizer05 | "merlin1991";"cssu";"A";"Default"; |
| 14:30.51 | DocScrutinizer05 | "merlin1991";"cssu-stable";"A";"Default"; |
| 14:30.52 | DocScrutinizer05 | "merlin1991";"cssu-testing";"A";"Default"; |
| 14:30.54 | DocScrutinizer05 | "merlin1991";"gforge";"A";"Admin"; |
| 14:32.43 | DocScrutinizer05 | ... |
| 14:33.09 | DocScrutinizer05 | gforge_users.csv 692350/3562K 18% |
| 14:33.10 | DocScrutinizer05 | "chemist";"chemist@dostortuXXX.oXX";"Rüdiger";"Schiller";""; |
| 15:09.23 | *** join/#maemo-ssu Martix (~martix@static-84-242-103-180.net.upcbroadband.cz) |
| 15:14.08 | *** join/#maemo-ssu freemangordon (~freemango@130-204-50-168.2074221835.ddns.cablebg.net) |
| 15:32.34 | *** join/#maemo-ssu Pali (~pali@Maemo/community/contributor/Pali) |
| 16:00.02 | *** join/#maemo-ssu sunny_s (~sunny_s@86.57.254.135) |
| 16:24.30 | Pali | ping Estel_, kerio |
| 16:24.38 | kerio | you just did |
| 16:25.13 | kerio | Pali: battery.reporting.design is different from battery.reporting.last_full |
| 16:25.20 | kerio | the battery applet should use battery.reporting.last_full |
| 16:25.32 | kerio | design... meh, it can come from both bq27k and rx51 i think |
| 16:25.39 | kerio | doesn't bq27k also have a way to read the resistor? |
| 16:25.59 | Pali | kerio, no |
| 16:26.31 | kerio | anyway, the battery applet should use last_full, not design |
| 16:26.51 | kerio | and even without calibrating, last_full from bq27k is more accurate than rx51 |
| 16:26.59 | Pali | kerio, so that bool flag to do not use rx51_battery design value will be for applet and when disabled applet will use last_full instead design |
| 16:27.01 | Pali | OK? |
| 16:27.10 | kerio | k |
| 16:27.32 | kerio | there's still the issue of not having a way to read the sysfs nodes when bq27k isn't calibrated |
| 16:27.48 | Pali | kerio, I do not agree that bq is always better then rx51 when is not calibrated |
| 16:28.05 | Pali | if you swap batteries it can be totally bad |
| 16:28.33 | Pali | so rather default value is to use rx51_batttery when battery is not calibrated |
| 16:29.03 | Pali | kerio, temp solution is to use register files |
| 16:29.10 | kerio | this is a battery applet issue though |
| 16:29.22 | kerio | that's just UI :) |
| 16:29.45 | kerio | does hald-addon-bme do its own calculations for percentages and stuff like that, or does it use the percentage from bq27k? |
| 16:30.36 | kerio | Pali: when the gconf flag is set to 0, the battery applet should show "no data, please calibrate" or something like that |
| 16:30.43 | kerio | (if bq27k isn't calibrated) |
| 16:30.51 | kerio | actually, no |
| 16:31.07 | kerio | just use last full, and show <current charge>/<last full charge> (CI) |
| 16:31.46 | Pali | kerio, when battery is not calibrated it trying to guess bars (value 0-8) from voltage |
| 16:32.02 | Pali | and it report percentage (calculated from bars) |
| 16:32.50 | kerio | Pali: i think that there should be a flag in hald-addon-bme that reports if the battery is calibrated or not |
| 16:33.03 | kerio | and there should be a way for the user to tell the battery applet to always consider bq27k data as valid |
| 16:33.07 | kerio | like DocScrutinizer05 would probably do |
| 16:33.26 | kerio | (except maybe show a small "(CI)" when not calibrated, so you also know when to calibrate again) |
| 16:34.12 | Pali | I can add CI flag to applet |
| 16:34.40 | kerio | normal users might prefer the guesstimate and the data from rx51-battery |
| 16:34.48 | kerio | because they just don't want to bother with calibration |
| 16:34.50 | Pali | kerio, write to wiki page what applet should shown when battery is calibrated and when is not calibrated |
| 16:35.55 | kerio | Pali: will you also add some kind of UI for this, maybe turning the battery entry in the status menu into a button to access it? |
| 16:36.25 | Pali | I'm not planning to rewrite UI |
| 16:36.38 | Pali | no time for it |
| 16:36.41 | kerio | but is it technically possible? |
| 16:36.47 | Pali | adding/changing text is easy |
| 16:36.54 | kerio | it could be merged with usbmode too |
| 16:37.08 | Pali | kerio, it is possible, but I do not know who will do it... |
| 16:37.24 | kerio | i heard freemangordon is AWESOME at gtk :D |
| 16:37.46 | freemangordon | hehe |
| 16:37.56 | freemangordon | who told you that? |
| 16:37.58 | Pali | kerio, rather thinking about features, fix bugs |
| 16:42.01 | kerio | Pali: added my proposal |
| 16:57.16 | DocScrutinizer05 | some basic stuff about shutdown: there's a level for graceful shutdown (maybe EDV1 is a good voltage for that), that needs the be tripped constantly for a rather long guard time (60s) before *anything* happens. To ensure it's constantly tripped you need set a flag "shutdown-threshold-tripped" when you detect it got tripped, then probe frequently (like 1/s) , and you should reset the flag and stop probing frequently and reset that |
| 16:57.18 | DocScrutinizer05 | flag when you detected 2 or 3 high values during your guardtime. When guard time of e.g. 60s expired and flag is still set, you "suggest" system to shut down and you start some power saving maybe, I.E. stop extreme powerhogs like phonecalls and camera and video playback. |
| 16:59.34 | DocScrutinizer05 | Then there's another lower threshold that's hardcoded into GAIA TPS65950 which triggers when dead end for system is near from voltage level, and *that* one is supposed to trigger a power failure interrupt on kernel level and shuts down system the fastest way a linux system can do |
| 17:00.19 | kerio | DocScrutinizer05: yeah but EDVF causes brownouts |
| 17:00.26 | kerio | and similar voltages, i assume |
| 17:00.53 | DocScrutinizer05 | userland gets notification about such power-failure event from kernel, but kernel will not wait for anything and go umount hard devices and then shutdown hard |
| 17:06.04 | kerio | DocScrutinizer05: the same as an alt+sysrq+U S B? |
| 17:06.09 | kerio | i mean, does the Sync happen? |
| 17:06.39 | DocScrutinizer05 | on a power-failure? nope, takes too long |
| 17:06.47 | *** join/#maemo-ssu NIN101 (~NIN@p5DD29A77.dip0.t-ipconnect.de) |
| 17:07.14 | DocScrutinizer05 | kernel immediately stops writing to all storage |
| 17:07.35 | DocScrutinizer05 | to avoid aborting a write with power outage which would probably ruin the HDD |
| 17:07.51 | DocScrutinizer05 | or the uSD/eMMC for that matter |
| 17:09.23 | DocScrutinizer05 | power-failure shutdown shall be clearly <1s to complete |
| 17:12.15 | DocScrutinizer05 | that's btw what I also suspect bme does when BSI gets disconnected. That's the reason why BSI contact blade is shorter then the +VB and GND blades of bat contact, so when you unplug the battery the kernel gets some milliseconds to stop everything before battery power gets disconected |
| 17:24.25 | kerio | wat, is it really that well-designed? |
| 17:31.08 | *** join/#maemo-ssu Woody14619a (~Woody@2620:4:4000:11:46b:13f9:1762:ecf2) |
| 17:31.08 | *** join/#maemo-ssu Woody14619a (~Woody@Maemo/community/contributor/Woody14619) |
| 17:31.35 | DocScrutinizer05 | you got a device to look at it, no? |
| 17:32.10 | DocScrutinizer05 | and you already know that with active bme the device doesn't work as soon as battery gets removed |
| 17:33.12 | DocScrutinizer05 | so evidently bme cares about BSI |
| 17:34.06 | DocScrutinizer05 | and you're free to check how fast it shuts down, by simply removing battery while it's charging and thus supposed to be powered from USB |
| 17:35.26 | DocScrutinizer05 | the only (res primary) reason device shuts down when you remove battery in that situation is bme doing that, when it detects BSI going ..00.. |
| 17:36.30 | DocScrutinizer05 | see my exlanations in tmo thread "hot swapping of battery, now possible" |
| 17:44.53 | kerio | i didn't mean the behaviour, i meant the "contact blade for BSI is shorter than + and GND so that when removing the battery the device has time to shut down" |
| 17:45.24 | kerio | i thought it was different just because |
| 17:45.36 | kerio | well, """time""" to """shut down""" |
| 18:00.37 | *** join/#maemo-ssu sunny_s (~sunny_s@86.57.254.135) |
| 18:00.40 | DocScrutinizer05 | I'm rather sure it's >1ms just for the shorter blade of BSI. And then we also got a buffer C (even a few of them) so the system has some 10s of ms for emergency shutdown |
| 18:02.11 | DocScrutinizer05 | particularly since cmt has a direct line to BSI and thus the biggest power hog has a way to stop consuming power even before APE had a chance to signal power-failure to it via interface |
| 18:04.59 | kerio | i still don't get what can be done in 10ms to help with shutdown |
| 18:09.56 | DocScrutinizer05 | what can be done? I guess 3..8 million opcodes can get executed |
| 18:11.48 | kerio | and one seek? :) |
| 18:18.51 | DocScrutinizer05 | no seeks |
| 18:18.57 | DocScrutinizer05 | power-down |
| 18:19.14 | DocScrutinizer05 | abort or finish writes |
| 18:57.01 | Pali | kerio, I updated wiki bme, look |
| 18:58.29 | kerio | Pali: "$charge/$last_full_charge (CI)" |
| 18:58.58 | kerio | i just realized that i haven't been thinking about the hybrid situation of no bme but no full bme replacement |
| 18:59.05 | kerio | but meh, that situation can go fsck off |
| 18:59.33 | *** join/#maemo-ssu sunny_s (~sunny_s@86.57.254.135) |
| 19:03.17 | kerio | Pali: hold on, why bother with "shutdown at edv1" if you're also going to "shutdown at 3150"? |
| 19:03.25 | kerio | oh nvm, edv1 is higher than 3150 |
| 19:17.09 | Pali | kerio, because default value is shutdown at edv1 |
| 19:17.21 | Pali | not at specified voltage |
| 19:24.26 | kerio | oh so it doesn't shutdown at the voltage if it's told to shutdown at edv1? |
| 19:32.19 | *** join/#maemo-ssu xes (~xes@unaffiliated/xes) |
| 19:32.36 | Pali | kerio, both |
| 19:32.44 | kerio | i see |
| 19:33.14 | Pali | kerio, but if voltage to too low, edv1 will happen first |
| 19:33.28 | kerio | yeah, yeah :) |
| 20:18.25 | *** join/#maemo-ssu dhbiker (~dhbiker@95.87.145.172) |
| 21:23.40 | *** join/#maemo-ssu Vlad_on_the_road (~Vlad_on_t@ip-66.net-82-216-1.versailles2.rev.numericable.fr) |
| 22:07.19 | *** join/#maemo-ssu xes (~xes@unaffiliated/xes) |
| 22:31.10 | *** join/#maemo-ssu Skry (~skry@adsl-77-109-215-222.kymp.net) |
| 23:31.34 | *** join/#maemo-ssu Woody14619 (~Woody@2620:4:4000:11:46b:13f9:1762:ecf2) |
| 23:31.34 | *** join/#maemo-ssu Woody14619 (~Woody@Maemo/community/contributor/Woody14619) |
| 23:58.57 | *** join/#maemo-ssu unclouded (~neil@2001:4428:200:80fc:4dec:790:5ede:78c1) |