00:21:16 | | Quit skapazzo (Quit: Lost terminal) |
00:28:53 | | Join Kofaz [0] (4582f871@gateway/web/freenode/ip.69.130.248.113) |
00:30:52 | | Quit Kofaz (Client Quit) |
00:32:57 | | Join anonus [0] (~anonymous@citadel.niflheim.info) |
00:42:15 | | Quit lebellium (Quit: ChatZilla 0.9.93 [Firefox 50.1.0/20161208153507]) |
00:45:06 | | Quit edhelas (Ping timeout: 248 seconds) |
00:46:47 | | Quit Senji (Ping timeout: 264 seconds) |
00:49:50 | | Join Senji [0] (~Senji@85.187.103.250) |
01:00 |
01:10:18 | | Quit tracktheripper (Ping timeout: 260 seconds) |
01:16:35 | | Quit paulk-collins (Quit: Leaving) |
01:25:47 | | Quit Senji (Ping timeout: 264 seconds) |
01:36:04 | | Quit ZincAlloy (Quit: Leaving.) |
01:39:56 | | Join Senji [0] (~Senji@85.187.103.250) |
01:44:50 | | Quit Senji (Ping timeout: 248 seconds) |
01:48:36 | | Quit ender` (Quit: Washing your car to make it rain doesn't work.) |
01:57:21 | *** | Saving seen data "./dancer.seen" |
02:00 |
02:01:23 | | Quit Mihail (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) |
02:22:44 | | Join rela_ [0] (~x@p200300764D5CC800A0B011247A05BFD0.dip0.t-ipconnect.de) |
02:26:14 | | Quit rela (Ping timeout: 260 seconds) |
03:00 |
03:06:31 | | Join nlogex [0] (~filip@CPE30469a4d21ac-CMa84e3f5c8560.cpe.net.fido.ca) |
03:21:57 | | Join Senji [0] (~Senji@85.187.103.250) |
03:24:15 | | Quit diox (Ping timeout: 246 seconds) |
03:25:04 | | Join diox [0] (~u@c80-216-201-69.bredband.comhem.se) |
03:27:24 | | Quit Senji (Ping timeout: 246 seconds) |
03:31:00 | dongs | hm so 4/8gib flash is very cheap. ill get a couple of each to test |
03:31:02 | | Join Senji [0] (~Senji@85.187.103.250) |
03:34:46 | [Saint] | what are you attempting to do? |
03:36:43 | | Quit Senji (Ping timeout: 256 seconds) |
03:38:38 | dongs | [Saint]: same thing as before that i've been talking about in the logs. |
03:39:04 | * | [Saint] hasn't been online in ~3 days |
03:39:27 | dongs | ya missed all the fun |
03:41:04 | [Saint] | care to gimme a rundown? |
03:42:22 | dongs | many dead flash sansa clip+'s. want to swap sandisk flash part for generic micron/etc nand. checked pinout. looks legit. soldered in 512meg part (all i had laying around). got to boot over jtag w/usb bootloader. shows up as 1.3tb drive. now here. |
03:42:59 | dongs | between then some discussion of where nand>sd translation occurs,what changes I might need to do in USB bootloader to make it open entier flash area to flash firmware on a blank chip (if it works). etc |
03:46:33 | [Saint] | in some regards there's not really generic flash, per se. |
03:49:00 | | Join Senji [0] (~Senji@85.187.103.250) |
03:49:15 | | Quit Senji (Read error: Connection reset by peer) |
03:49:43 | | Join Senji [0] (~Senji@85.187.103.250) |
03:54:05 | dongs | [Saint]: thats what everyone keeps saying but hardware evidence points otherwise |
03:54:58 | | Quit Senji (Ping timeout: 248 seconds) |
03:57:24 | *** | Saving seen data "./dancer.seen" |
04:00 |
04:01:07 | [Saint] | and that doesn't even begin to deal with the fact that the bootloader and OF probably expect to be dealing with a small subset of very specific credentials from expected silicon. |
04:01:32 | dongs | yep, i will be looking into that |
04:01:39 | [Saint] | you'll assuredly never boot the OF on this thing. |
04:02:01 | dongs | it might never boot beyond using jtag, if ROM bootloader sets up nand and only supports sandisk flash IDs |
04:03:14 | [Saint] | it'll also be expecting a very specific capacity. |
04:03:44 | [Saint] | the 1.3TB (presumably entirely inaccessible at high or low levels) reported smacks hard of an overflow. |
04:04:13 | | Join CrashBash-Kun [0] (~CrashBash@unaffiliated/crashbash-kun) |
04:05:42 | [Saint] | But, yeah - the only thing that is generic, per se, about flash any one of the several standards for ordering the physical composition of it. |
04:06:46 | dongs | which is why im gonna try 4 and 8gb parts |
04:06:59 | dongs | 512 is really old one, its just the only thing i had laying around. |
04:07:09 | dongs | 8gb is only like $3.6 so i dont mind wasting that to try |
04:07:27 | [Saint] | then you'll just get an overflow with a different offset. |
04:07:39 | dongs | then I'll step through bootloader and see why it does that |
04:08:18 | | Quit CrashBash-Kun (Read error: Connection reset by peer) |
04:09:29 | [Saint] | errrr...can we even step the OF bootloader? |
04:10:26 | [Saint] | like pretty much every other target the rb bootloader is just a tiny subset inserted that says "hit here; unless <foo>" and allmost all of the hardware setup is handled by the OEM bootloader. |
04:10:41 | dongs | last part: no |
04:10:52 | dongs | i connect to cpu under reset, load rockbox bootloader into ram, and jump to it |
04:10:58 | dongs | ROM boot never even runs |
04:11:28 | dongs | and screen works and it connects in bootloader usb mode. |
04:11:40 | dongs | so i can certainly step through that part once I get build going and can do source-level debugging/stepping |
04:12:30 | [Saint] | by the time you get to handoff to soemthing you can step through, hardware setup has already happened. |
04:12:45 | dongs | ... do you know what "connecting under reset" means? |
04:12:56 | [Saint] | I do. |
04:12:57 | dongs | nothing runs except the code I put in ram |
04:13:45 | dongs | and I'm loading bootloader-clipplus.bin which is all original code, no OF bits |
04:14:07 | dongs | so i can certainly step through it all |
04:14:13 | [Saint] | that's mainly OF bits, in fact. |
04:14:25 | [Saint] | about 98% OF bits in fact |
04:14:56 | [Saint] | it's literally just the original firmware with a tiny little edit in it giving it the jump point for Rockbox. |
04:15:03 | dongs | no, its not |
04:17:49 | dongs | this is the rockbox bootloader that gets compressed and packed into OF boot |
04:18:06 | dongs | i am NOT booting the code thats in clppa.bin that combines OF + rockbox |
04:19:19 | [Saint] | so, wait...you actually mean bootloader-clipplus.sansa? |
04:19:23 | dongs | yes |
04:19:39 | dongs | (renamed to .bin cuz i cut off 8byte or whatever header that was in .sansa file |
04:25:45 | dongs | so yea no hardware is setup before that runs. |
05:00 |
05:11:57 | | Join Senji [0] (~Senji@85.187.103.250) |
05:17:25 | | Join treaki__ [0] (~treaki@p3E9917C2.dip0.t-ipconnect.de) |
05:18:01 | | Quit Senji (Ping timeout: 268 seconds) |
05:21:34 | | Quit treaki_ (Ping timeout: 265 seconds) |
05:34:06 | | Quit aptzero (Quit: Leaving.) |
05:37:20 | | Join JanC_ [0] (~janc@lugwv/member/JanC) |
05:38:36 | | Nick JanC is now known as Guest56827 (~janc@lugwv/member/JanC) |
05:38:36 | | Nick JanC_ is now known as JanC (~janc@lugwv/member/JanC) |
05:39:09 | | Quit Guest56827 (Ping timeout: 256 seconds) |
05:57:28 | *** | Saving seen data "./dancer.seen" |
06:00 |
06:21:14 | | Join Senji [0] (~Senji@85.187.103.250) |
06:27:05 | | Quit Senji (Ping timeout: 268 seconds) |
06:46:34 | | Quit advcomp2019 (Ping timeout: 246 seconds) |
06:51:33 | | Quit TheSeven (Disconnected by services) |
06:51:42 | | Join [7] [0] (~quassel@rockbox/developer/TheSeven) |
07:00 |
07:15:14 | | Quit idonob_ (Ping timeout: 252 seconds) |
07:16:18 | | Join idonob_ [0] (~Owner@static-173-212-139-201.ptr.terago.net) |
07:27:27 | | Join edhelas [0] (~edhelas@145.133.43.230) |
07:31:52 | | Quit edhelas (Client Quit) |
07:45:30 | | Join edhelas [0] (~edhelas@145.133.43.230) |
07:45:40 | | Quit edhelas (Client Quit) |
07:57:31 | *** | Saving seen data "./dancer.seen" |
08:00 |
08:01:03 | | Quit amiconn (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) |
08:01:04 | | Quit pixelma_ (Quit: .) |
08:01:14 | | Join pixelma [0] (~pixelma@rockbox/staff/pixelma) |
08:01:16 | | Join amiconn [0] (~amiconn@rockbox/developer/amiconn) |
08:08:38 | | Join Senji [0] (~Senji@85.187.103.250) |
08:14:24 | | Quit Senji (Ping timeout: 264 seconds) |
08:44:22 | | Join advcomp2019 [0] (~advcomp20@65-131-161-253.sxct.qwest.net) |
08:44:22 | | Quit advcomp2019 (Changing host) |
08:44:22 | | Join advcomp2019 [0] (~advcomp20@unaffiliated/advcomp2019) |
09:00 |
09:14:28 | | Quit idonob_ (Ping timeout: 256 seconds) |
09:17:58 | | Quit nlogex (Ping timeout: 258 seconds) |
09:57:35 | *** | Saving seen data "./dancer.seen" |
10:00 |
10:04:21 | | Join n3m9 [0] (~n3m9@ANantes-652-1-57-61.w90-59.abo.wanadoo.fr) |
10:19:31 | | Quit krnlyng (Ping timeout: 248 seconds) |
10:20:04 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
10:26:14 | | Join Senji [0] (~Senji@85.187.103.250) |
10:26:21 | | Join Strife1989 [0] (~quassel@adsl-98-80-186-240.mcn.bellsouth.net) |
10:29:19 | | Quit CommunistWitchDr (Quit: No Ping reply in 180 seconds.) |
10:29:26 | | Quit Strife89 (Ping timeout: 268 seconds) |
10:30:23 | | Join Strife89 [0] (~quassel@adsl-98-80-183-107.mcn.bellsouth.net) |
10:31:01 | | Join SovietShaman_ [0] (quasselcor@97-87-177-85.dhcp.stls.mo.charter.com) |
10:31:12 | | Quit Strife1989 (Ping timeout: 264 seconds) |
10:31:36 | | Join krnlyng [0] (~liar@77.117.124.37.wireless.dyn.drei.com) |
10:31:47 | | Quit Senji (Ping timeout: 248 seconds) |
10:35:30 | | Quit Strife89 (Ping timeout: 256 seconds) |
10:49:54 | | Join ender` [0] (krneki@foo.eternallybored.org) |
10:59:24 | | Quit pamaury (Ping timeout: 264 seconds) |
11:00 |
11:15:32 | | Join Senji [0] (~Senji@85.187.103.250) |
11:21:01 | | Quit Senji (Ping timeout: 258 seconds) |
11:32:58 | | Join lebellium [0] (~chatzilla@ren77-h01-176-151-188-9.dsl.sta.abo.bbox.fr) |
11:46:55 | | Join pamaury [0] (~quassel@wks-50-63.mpi-sws.org) |
11:46:55 | | Quit pamaury (Changing host) |
11:46:55 | | Join pamaury [0] (~quassel@rockbox/developer/pamaury) |
11:51:28 | | Join pamaury_ [0] (~pamaury@rockbox/developer/pamaury) |
11:55:43 | | Quit pamaury_ (Ping timeout: 252 seconds) |
11:57:39 | *** | Saving seen data "./dancer.seen" |
12:00 |
12:00:29 | | Join Senji [0] (~Senji@85.187.103.250) |
12:06:00 | | Quit Senji (Ping timeout: 264 seconds) |
12:08:49 | | Join robertd1 [0] (~root@201.242.214.237) |
12:15:57 | | Join skapazzo [0] (~skapazzo@151.9.205.1) |
12:24:46 | | Join paulk-collins [0] (~paulk@gagarine.paulk.fr) |
12:52:00 | | Join ZincAlloy [0] (~Adium@2a02:8108:8b80:1700:49fc:d35:f21c:c820) |
12:54:45 | | Join cc___ [0] (~ac@2001:910:113f:1:6a05:caff:fe1c:1627) |
13:00 |
13:01:33 | | Join Senji [0] (~Senji@85.187.103.250) |
13:16:23 | lebellium | pamaury: I found the Sony official website where you can download all service manuals from free. The only issue is that you have to know the service manual reference number to get the proper URL... I'm mass testing many URLs and by chance I found some NWZ service manuals. The E390 one is ridiculous.... https://docs.sony.com/release/MDSM/989625401_SM.pdf |
13:17:06 | pamaury | lebellium: lol, indeed |
13:20:09 | pamaury | lebellium: I plan to resume work on NWZ port this week. I think I'll add an option to boot the service menu from the bootloader |
13:20:54 | lebellium | you could do that? I'm looking for the E580 and A10 service manual especially to get the key combo to enter the service menu |
13:25:46 | lebellium | oh I got a nice one! NW-WM1 https://docs.sony.com/release/MDSM/989632501_SM.pdf |
13:26:00 | lebellium | the new high-end player |
13:26:36 | pamaury | as far as I know, the service menu is just another program. when you hit the magic sequence, it sets a flags and reboots, on reboot it launches a different program |
13:27:30 | lebellium | look at NW-WM1, it's not a key combo anymore |
13:27:50 | lebellium | you have to connect the device to PC and run a separated programm |
13:31:38 | pamaury | it's very complete! Well I don't plan to buy a WM1 anytime :-p |
13:32:41 | lebellium | but I know some users already asked me if you planned to port Rockbox to it anyway :P |
13:34:15 | pamaury | I'll try to make the port as generic as possible, we'll see how it can go |
13:34:20 | pamaury | *how far |
13:35:55 | | Join johnb2 [0] (~johnb2@p5B2967C9.dip0.t-ipconnect.de) |
13:40:58 | | Join pamaury_ [0] (~pamaury@rockbox/developer/pamaury) |
13:45:24 | lebellium | pamaury argh A10 so disappointing https://docs.sony.com/release/MDSM/989606301_SM.pdf |
13:45:28 | lebellium | spent so many hours for that :( |
13:50:31 | dongs | wat |
13:51:20 | dongs | lebellium: whats the pattern for search stuff |
13:51:31 | dongs | I could use a service manual for some other junk they make |
13:54:40 | lebellium | last 2 digits is the service manual revision number. Most of time it's 01 (v1.0), sometimes 02 (v1.1). There is no real pattern for the 7 digits before. I made an excel file with all URLs from 989603401_SM.pdf to 989999901_SM.pdf and test all of them one by one. I selected prefix 989 but NWZ-A840 from 2010 is still in prefix 988 |
13:55:54 | lebellium | if you can find a preview of your service manual on a bastard website where they want to charge you $10 or $20 for it, you can read the service manual number on the 1st page of the manual |
13:56:11 | lebellium | but for most service manuals there is no preview available |
13:56:15 | lebellium | so you have to guess |
13:56:16 | dongs | ah yeah no this is a japan-only oddball device so I doubt it would be on the site |
13:57:27 | dongs | 4-541-610-01(6) |
13:57:30 | dongs | hmm i wonder if thats it |
13:57:41 | *** | Saving seen data "./dancer.seen" |
13:58:03 | dongs | hm nope 404. |
13:59:37 | lebellium | I just checked on the box of my A15 |
13:59:52 | lebellium | the reference written has unfortunately nothing to do with the associated service manual |
14:00 |
14:06:40 | | Quit sLite (Remote host closed the connection) |
14:19:56 | Bilgus | any reason it isn't indexed by google? |
14:20:01 | Bilgus | https://docs.sony.com/release/MDSM/ filetype:pdf |
14:20:25 | | Quit Senji (Ping timeout: 258 seconds) |
14:21:35 | Bilgus | http://bfy.tw/9EcJ |
14:21:49 | pamaury_ | Bilgus: haven't checked, but it's only indexed if there are links to it and afaik the directory is not readable |
14:21:59 | Bilgus | ^not to be an ass but figured it was easier :) |
14:22:06 | lebellium | pamaury_: E470 :D https://docs.sony.com/release/MDSM/989350201_SM.pdf |
14:22:36 | pamaury_ | Bilgus: great :) |
14:23:29 | | Join Senji [0] (~Senji@85.187.103.250) |
14:25:30 | Bilgus | it seems like lebellium has ones that weren't indexed |
14:26:12 | lebellium | I can have anyone, I'm just checking hundreds URLs by hand. That may be stupid but I don't find a better solution |
14:26:25 | pamaury_ | lebellium: script ? |
14:26:45 | lebellium | I can't write scripts. Could a script read the model number from the 1st page? |
14:27:33 | pamaury_ | coudln't you write script to find all *valid* URLs ? I guess most urls you find are 404 |
14:28:23 | lebellium | I used that http://www.urlitor.com/ but 150 URLs in one go was boring |
14:28:29 | lebellium | but indeed I get many 404 |
14:29:03 | | Quit Senji (Quit: KVIrc 4.9.2 Aria http://www.kvirc.net/) |
14:30:21 | lebellium | pamaury_: I'll put all NWZ links I found here https://www.rockbox.org/wiki/SonyNW . Sounds good? |
14:31:06 | pamaury_ | ok |
14:31:19 | pamaury_ | feel free to fix the NW/NWZ clarification |
14:31:31 | pamaury_ | I really have to rework this page |
14:33:41 | | Join Link8 [0] (~me@145.132.155.235) |
14:36:05 | | Join dfkt [0] (~dfkt@unaffiliated/dfkt) |
14:37:24 | anonus | hi |
14:37:31 | anonus | is lyre project abandoned? |
14:38:20 | gevaerts | Was it ever real? |
14:38:41 | anonus | i dunno, just asking |
14:39:04 | anonus | i'm just thinkging about having fun with i.mx233 |
14:39:31 | anonus | to make simple board with i.mx, mem and audio |
14:39:46 | anonus | i wonder how likely to make it run rockbox |
14:40:18 | gevaerts | Oh, if yoy know about hardware you can certainly do that |
14:40:23 | | Quit diox (Quit: patchigt) |
14:40:33 | pamaury_ | anonus: i.mx233 is well supported by rockbox, if you can do the hardware side that should be relatively easy |
14:41:02 | gevaerts | Just don't have delusions about doing that as a hobby project easily resulting in a marketable commercial device :) |
14:41:24 | anonus | yeah, i just think can i do the trick to make it closer to Fuze+ to be able to run rockbox with minimal modifications |
14:42:25 | anonus | well, certainly it will be a hobby project, i don't want even touch BGA chips with 5 meter stick and with TSSOP DRAM it would eat battery even faster than modern smartphones :) |
14:42:55 | anonus | i believe there is no mobile dram in diy-solderable case |
14:43:18 | pamaury_ | there are some imx233 boards at olimex. It's quite easy to create new targets in rockbox, you don't have to worry about making it close to the fuze+. The only real limitations are 1) don't use raw NAND 2) make sure you have at least 4MB of RAM |
14:43:22 | anonus | but i'll take your point ;) |
14:43:44 | anonus | pamaury_: already ordered one to check my ideas |
14:43:51 | pamaury_ | also the imx233 supports others types of memories I tink, probably ddr2 |
14:44:13 | | Join Senji [0] (~Senji@85.187.103.250) |
14:44:14 | anonus | how much ram do you need to run rockbock btw? |
14:44:20 | anonus | i mean what the main factor? |
14:44:57 | anonus | if i will use simplest monochrome 80x25 LCD will it save me some RAM? |
14:45:38 | gevaerts | Yes, but I'd argue that 80x25 is a bit too low |
14:45:52 | pamaury_ | some targets can do with 2MB but for the imx233, I think you should aim for at least 4MB. A bigger screen will use more memory but I don't think a 240x320 screen would be a problem |
14:45:55 | anonus | will 4 MB be enough? |
14:46:11 | pamaury_ | also ram is cheap, if I were you I would put 8 or 16 MB |
14:46:12 | anonus | i mean Fuze+ and all Creatives with i.MX233 have at least 32mb |
14:46:33 | anonus | i'm not concerned about cost but about power consumption |
14:46:35 | gevaerts | I'd recommend going for a screen resolution that's already supported. That will save you a lot of plugin work, and open up more themes |
14:47:07 | pamaury_ | the system basically needs 2MB to just run. Everything after that is for audio buffer and codecs. If you have more, you can cache more but 32MB is overkill one could say |
14:47:31 | anonus | so 8 will be more than enough? |
14:47:48 | gevaerts | On flash audio buffer isn't as critical as on spinning disks |
14:48:02 | gevaerts | 8 should be plenty unless you go for big colour screens |
14:48:13 | anonus | i am definitely not :) |
14:49:12 | gevaerts | If your primary goal is fancy plugins, you might also want more. If your primary goal is audio playback on a flash device, 4 is probably enough but going for 8 gives you some headroom |
14:49:34 | gevaerts | For low-res 2.5 is going to be enough, even. That's what the clipv1 has |
14:49:48 | gevaerts | (2MB + a bit of on-SoC RAM) |
14:49:50 | pamaury_ | also just so you know, if you go for a button interface, I suggest you have at least 6/7 buttons (direction pad, back, enter). We support touchscreen but it's far from optimal |
14:50:17 | anonus | well, my primary goal to have some fun and experience with designing hardware a bit more complicated than basic stuff with STM32 controllers, never tried to route DRAM before |
14:50:18 | pamaury_ | gevaerts: imx233 has 32KiB of iram so it's not really helping in this case ;) |
14:50:46 | anonus | but as side product i could get myself a working portable player with rockbox, my sansa clip+ is slowly dying |
14:51:30 | anonus | s/clip+/clip zip/ |
14:52:10 | anonus | lyre project tried to use 5510 nokia lcd, is it supported? |
14:53:00 | pamaury_ | each lcd is different, adding a new one is not hard if you have the datasheet but there is 0% you can buy an already supported one |
14:54:00 | anonus | ah, ok |
14:54:02 | anonus | i see |
14:54:06 | anonus | no problems then |
14:54:34 | gevaerts | pamaury_: yes, true :). IIRC those few hundreds of kilobytes extra were actually fairly critical in getting rockbox to run well though |
14:54:38 | pamaury_ | if you can, I think it will simpler to have an lcd with a 8080 or 8086 interface, it's much faster than an i2c or spi |
14:54:55 | pamaury_ | (but more wires obviously) |
14:55:17 | | Quit johnb2 (Ping timeout: 265 seconds) |
14:55:21 | anonus | pamaury_: well, there is one more reason: with 8080 i can have two sd cards |
14:55:38 | gevaerts | If your goal is to get design experience, more wires is actually an advantage! |
14:55:47 | anonus | as far as i understand i.mx233 has only two ssps |
14:56:35 | anonus | yeah, i just don't want to mess with ribbon cables, and 5510 has nice zebra strip interface |
14:58:33 | pamaury_ | anonus: the imx233 only has two ssp, although you could get away with two cards on the same ssp, for example by using a multipler a pin to switch between the two |
14:59:00 | pamaury_ | there is no code for it in rockbox but that can be implemented without too much difficulty I think |
14:59:12 | anonus | does it run microsds as SPI? i'm not sure, should check datasheet |
14:59:54 | pamaury_ | no rockbox only supports SD/MMC protocol, we never run microsd as spi |
15:00 |
15:00:36 | anonus | so AFAIK you could not mulpitlex microsds if they are not working as SPI |
15:00:57 | anonus | sd bus has no CS pin |
15:01:12 | anonus | or am i missing something? |
15:01:14 | pamaury_ | that's why you need a multiplex and a gpio to act as CS for an external multiplexer |
15:01:37 | anonus | ah, ok |
15:01:40 | anonus | i see |
15:02:08 | pamaury_ | if you prefer, you wire all lines to both cards, with a bidir buffer for each of them and you wire a gpio to the enable of each, one inverted, something like that |
15:03:22 | * | pamaury_ doesn't claim this is electronically the right solution |
15:03:33 | anonus | yeah, that could be done, but i think it does not worth it |
15:03:57 | pamaury_ | I *think* in theory you can have several microsd on a single bus, because you can select the active card using commands, but I have never done that |
15:04:08 | lebellium | pamaury_: E580!! https://docs.sony.com/release/MDSM/989379101_SM.pdf |
15:05:16 | pamaury_ | I think the imx233 also has an ATA interface |
15:06:02 | pamaury_ | at least the older stmp37xx series did and I think Freescale did not advertise the imx233 as been ATA capable but in reality it can do it |
15:07:43 | anonus | mmm, i see nothing about ATA in datasheet |
15:09:15 | chrisjj | pamaury: did you get my ZEN battery_bench.txt? |
15:09:32 | pamaury_ | it's not in the imx233 datasheet, but the GMPI block could do nand + ata in the previous generation |
15:09:46 | pamaury_ | chrisjj: I think so, https://www.dropbox.com/s/5w3buwj5g9b7z7s/RB%20Unit%20Q%202016-12-24%5D%20battery_bench.txt?dl=0 ? |
15:09:50 | pamaury_ | I didn't look at it yet |
15:10:12 | chrisjj | Yup, that's it. |
15:10:13 | pamaury_ | anonus: google "stmp37xx datasheet" |
15:10:40 | anonus | mmm |
15:11:12 | pamaury_ | although only the BGA version could, and it is possible that the imx233 chip really drop support for it, I don't know |
15:12:25 | pamaury_ | also double-check the datasheet for shared IO lines, not all combinations are possible |
15:12:53 | pamaury_ | like ata/nand is shared with ssp2 |
15:14:01 | | Join johnb2 [0] (~johnb2@p5B2967C9.dip0.t-ipconnect.de) |
15:19:24 | lebellium | pamaury_: when you have some time, can you try the key combo on your E580. I can't enter the test mode the way described in the service manual |
15:22:39 | | Quit johnb2 (Quit: Nettalk6 - www.ntalk.de) |
15:23:37 | pamaury_ | sure, remind me if I forget |
15:25:40 | lebellium | pamaury_: nevermind, I found the mistake in the usermanual |
15:25:45 | lebellium | service manual |
15:25:54 | lebellium | they wrote "up" instead of "down" |
15:26:03 | lebellium | and didn't even notice it a updated it |
15:33:44 | | Quit StaticAmbience (Remote host closed the connection) |
15:36:32 | | Join StaticAmbience [0] (~Quassel@host217-42-102-24.range217-42.btcentralplus.com) |
15:57:42 | *** | Saving seen data "./dancer.seen" |
15:58:00 | Bilgus | __builtin: did you ever figure out a way to save the current screen buffer and restore it after you switch viewports? |
16:00 |
16:00:23 | | Join aptzero [0] (~Adium@c-69-140-168-118.hsd1.md.comcast.net) |
16:02:31 | | Join edhelas [0] (~edhelas@145.133.43.230) |
16:11:16 | | Join amayer [0] (~amayer@mail.weberadvertising.com) |
16:16:00 | | Quit fs-bluebot_ (Ping timeout: 268 seconds) |
16:16:26 | | Quit Link8 (Remote host closed the connection) |
16:16:48 | | Quit bluebrother (Ping timeout: 264 seconds) |
16:18:29 | | Join bluebrother [0] (~dom@rockbox/developer/bluebrother) |
16:26:03 | | Quit rela_ (Quit: Leaving) |
16:30:12 | | Join fs-bluebot [0] (~fs-bluebo@xd9bafb02.dyn.telefonica.de) |
16:33:23 | | Join Guest93 [0] (~textual@145.132.155.235) |
16:35:04 | | Quit edhelas (Read error: Connection reset by peer) |
16:35:21 | | Quit Guest93 (Client Quit) |
16:35:54 | | Join edhelas [0] (~edhelas@145.133.43.230) |
16:49:16 | dongs | cool chats above |
16:57:49 | | Join rela [0] (~x@pdpc/supporter/active/rela) |
17:00 |
17:41:00 | | Quit pamaury (Remote host closed the connection) |
17:48:42 | | Join diox [0] (~u@c80-216-201-69.bredband.comhem.se) |
17:57:43 | *** | Saving seen data "./dancer.seen" |
18:00 |
18:02:36 | | Quit diox (Quit: en till reboot..!) |
18:08:35 | | Join diox [0] (~u@c80-216-201-69.bredband.comhem.se) |
18:11:40 | | Quit pamaury_ (Ping timeout: 256 seconds) |
18:15:20 | | Join girafe [0] (~girafe@LFbn-1-11729-221.w2-7.abo.wanadoo.fr) |
18:29:01 | | Join nlogex [0] (~filip@CPE30469a4d21ac-CMa84e3f5c8560.cpe.net.fido.ca) |
18:42:20 | | Quit lebellium (Quit: ChatZilla 0.9.93 [Firefox 50.1.0/20161208153507]) |
18:42:41 | | Join girafe2 [0] (~girafe@LFbn-1-11729-221.w2-7.abo.wanadoo.fr) |
18:44:23 | | Quit girafe (Ping timeout: 265 seconds) |
18:45:35 | | Quit Senji (Read error: Connection reset by peer) |
18:46:27 | | Join Senji [0] (~Senji@85.187.103.250) |
18:50:00 | | Join Senji_ [0] (~Senji@85.187.103.250) |
18:50:16 | | Quit Senji_ (Read error: Connection reset by peer) |
18:50:44 | | Join Senji_ [0] (~Senji@85.187.103.250) |
18:51:51 | | Quit Senji (Ping timeout: 260 seconds) |
18:52:13 | | Quit marex-cloud (Ping timeout: 258 seconds) |
18:57:48 | | Quit diox (Read error: Connection reset by peer) |
18:58:18 | | Join diox [0] (~u@c80-216-201-69.bredband.comhem.se) |
18:58:49 | | Quit StaticAmbience (Read error: Connection reset by peer) |
19:00 |
19:00:45 | | Part robertd1 |
19:01:47 | | Join StaticAmbience [0] (~Quassel@host217-42-102-24.range217-42.btcentralplus.com) |
19:13:39 | | Quit prg318 (Quit: WeeChat 1.6) |
19:19:45 | | Join prg318 [0] (~prg318@deadcodersociety/prg318) |
19:28:20 | | Quit Senji_ (Read error: Connection reset by peer) |
19:30:14 | | Join Senji [0] (~Senji@85.187.103.250) |
19:30:29 | | Quit Senji (Read error: Connection reset by peer) |
19:31:39 | | Join Senji [0] (~Senji@85.187.103.250) |
19:32:34 | | Quit Senji (Read error: Connection reset by peer) |
19:32:59 | | Join Senji [0] (~Senji@85.187.103.250) |
19:33:25 | | Quit Senji (Read error: Connection reset by peer) |
19:35:48 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
19:56:03 | | Quit edhelas (Ping timeout: 252 seconds) |
19:57:47 | *** | Saving seen data "./dancer.seen" |
20:00 |
20:00:32 | | Join Senji [0] (~Senji@85.187.103.250) |
20:49:42 | Bilgus | chrisjj: want to test the play pause fade plugin? |
21:00 |
21:04:09 | | Join marex-cloud [0] (sid137234@gateway/web/irccloud.com/x-wmidnezcspazlahu) |
21:15:30 | | Quit aptzero (Quit: Leaving.) |
21:23:13 | | Join idonob_ [0] (~Owner@static-173-212-139-201.ptr.terago.net) |
21:31:29 | [Saint] | Bilgus: errrr...the what? |
21:31:37 | [Saint] | Don't all capable targets already do this? |
21:32:08 | [Saint] | Settings - Playback Settings - Fade On Stop/Pause |
21:32:14 | Bilgus | thsi plugin allows you to set a variable delay, min and max volume |
21:32:21 | [Saint] | (and it's in-core, too) |
21:32:54 | [Saint] | Why do it in a plugin? |
21:33:02 | [Saint] | I would also be very wary about trying to get anything like that into the core. |
21:33:13 | Bilgus | it will eventually also be a fade to sleep plugin |
21:33:15 | [Saint] | We just plain don't fuck with playback from core with plugins. |
21:33:27 | [Saint] | Pretty sure we've been through this. |
21:33:39 | Bilgus | well it actually just fades the volume out / in |
21:33:48 | [Saint] | I'm aware. |
21:34:18 | [Saint] | Do It Right(TM) and add this behavior to the appropriate core setting bundle. |
21:34:42 | Bilgus | and I already tried a lua script which works but as I'm sure you are aware doesn't work on all targets |
21:34:54 | [Saint] | Sorry, but I'll fight playback boundaries crossing between core and plugins with a passion. |
21:35:05 | | Join aptzero [0] (~Adium@c-69-140-168-118.hsd1.md.comcast.net) |
21:35:17 | Bilgus | I can't see adding any of this to the core |
21:35:38 | [Saint] | Why? We already have variable fade delays elsewhere. |
21:36:41 | Bilgus | I admit it would probably be easier to add it in to the core but why add the extra overhead? |
21:36:42 | [Saint] | It's basically just crossfade but with a different trigger and no secondary track to bleed. |
21:37:12 | [Saint] | Bilgus: the why would be "plugins have no business governing playback they didn't start" |
21:38:11 | Bilgus | well technically the plugin does start the playback |
21:38:29 | [Saint] | ...ewwww |
21:39:00 | Bilgus | no different than the alarm plugin |
21:39:02 | [Saint] | the bulk of this is already sitting around in the core code just waiting for someone to join the dots. |
21:39:17 | [Saint] | and, yeah - that's my one reservation of plugin/core crossover. |
21:39:26 | [Saint] | I dislike it but I accept it. |
21:40:11 | [Saint] | there's nice fade control and at least two different models for time pickers sitting in core already. |
21:40:55 | Bilgus | If you think it'd be better served in core I'll check it out, what about fade to sleep? |
21:41:22 | [Saint] | It just seems weird to me to disconnect the existing fade on stop/pause behavior in core. |
21:41:42 | [Saint] | Literally all that requires to meet parity is a time picker for fade duration. |
21:42:05 | Bilgus | the two basically go together code wise |
21:42:15 | fs-bluebot | Build Server message: New build round started. Revision 782d9c0, 255 builds, 14 clients. |
21:42:42 | [Saint] | No part of me would expect to find control to govern this behavior in two entirely different sections of the codebase. |
21:42:42 | [Saint] | UX-wise that's plain bad JuJu |
21:43:12 | Bilgus | now the only question is how to let the user know that the fade is going on |
21:43:35 | [Saint] | Why do you need to let them know? We never do elsewhere. |
21:43:41 | [Saint] | They set it explicitly. They know. |
21:43:59 | Bilgus | for instance if I pick a fade over 10 minutes in the sleep one and the user changes volume |
21:44:42 | [Saint] | I think any values over 60s are pretty nuts personally. |
21:44:57 | Bilgus | do we. start fading from the new volume; disable the fade; disable vol change(uh no) |
21:45:07 | Bilgus | not in a sleep to fade plugin |
21:45:33 | Bilgus | they might want to faded for 30 minutes or something crazy |
21:45:59 | [Saint] | That's going to get messy real quick. |
21:46:17 | Bilgus | ANND plugin :) |
21:46:19 | [Saint] | Like, how to deal with if they already have a dramatic crossfade set. |
21:46:27 | [Saint] | Ignore it? |
21:46:29 | [Saint] | Stack it? |
21:46:31 | [Saint] | etc. |
21:46:55 | [Saint] | I guess now I'm seeing your point, but it would seem VERY weird to me to have this behavior in plugin and not in core. |
21:47:43 | [Saint] | This is a niche case that should probably be tied into whichever plugin it is that I forget the name of that governs sleep on lack of user input. |
21:48:11 | [Saint] | I thought you just wanted ~10s of fade on stop/pause like almost every other playback setting has. |
21:48:18 | [Saint] | Not spanning multiple minutes. |
21:49:37 | [Saint] | I guess the "play pause fade" wording confused me. |
21:49:53 | Bilgus | well thats why I started with the fade on play/pause as it is essentially the same thing minus the sleep part |
21:49:55 | [Saint] | As this use case seems largely disconnected to playback control in and of itself. |
21:50:06 | | Quit aptzero (Quit: Leaving.) |
21:50:20 | [Saint] | IIUC you don't want this to actually fire on user interaction. |
21:50:29 | [Saint] | You want it to fire on lack of user interaction? |
21:51:05 | [Saint] | pressing a button to fade to a stop ~N minutes in the future isn't something that strikes me as a common use case. |
21:51:20 | Bilgus | well yes and no it doesn't have to be linked to user interaction atm though it does grab pause and play state |
21:51:46 | | Join aptzero [0] (~Adium@c-69-140-168-118.hsd1.md.comcast.net) |
21:51:50 | Bilgus | and the current fade on pause uses the pcm buffer to fade |
21:52:05 | [Saint] | Yeah, I feel like this should be tied in with the plugin I can't recall the name of but you likely are familiar with. |
21:52:11 | [Saint] | The sleep timer dealy. |
21:52:23 | Bilgus | I have no idea on the plugin I was looking |
21:53:23 | fs-bluebot | Build Server message: Build round completed after 667 seconds. |
21:53:24 | fs-bluebot | Build Server message: Revision 782d9c0 result: All green |
21:53:25 | fs-bluebot | Build Server message: New build round started. Revision e259836, 255 builds, 12 clients. |
21:53:40 | [Saint] | we already have a plugin that sets an interactive timer for sleep. |
21:53:56 | [Saint] | so if the device hasn't been interacted with in N minutes, it'll stop playback and then idle timeout. |
21:54:09 | [Saint] | seems to me a protracted fade would go well with that. |
21:54:20 | Bilgus | sounds like a great place to inset this |
21:54:26 | * | [Saint] nods |
21:55:21 | Bilgus | ok so I think i'll look to adding play / pause fade to core and then fade to sleep to this nameless plugin |
21:55:28 | [Saint] | I thought you meant a more general stop/pause fade, like we alreadyhave, but just adding configurability to it. |
21:56:07 | Bilgus | I did but only because they share the same code |
21:56:13 | [Saint] | This is indeed more generalized. Lack of having a time picker for the fade period was really an oversite there I think. |
21:56:24 | | Join edhelas [0] (~edhelas@145.133.43.230) |
21:56:36 | Bilgus | well again that is because it uses the pcm buffer |
21:57:12 | [Saint] | well, as does crossfade. |
21:57:13 | [Saint] | that's configurable. |
21:57:49 | *** | Saving seen data "./dancer.seen" |
21:57:53 | [Saint] | Bah - you've reminded me now how broken the time picker values are across the board. |
21:57:59 | Bilgus | I'll look at it |
21:58:24 | Bilgus | I've made some pretty nice interfaces the last few days |
21:58:54 | [Saint] | we have everything from 0~10s or 0.00s~60.00s in the time pickers. Various other unit pickers have mismatched values too. |
21:59:05 | [Saint] | Noticing this again makes me unreasonably angsty. |
22:00 |
22:00:29 | Bilgus | I don't much like that many values in a menu |
22:01:00 | Bilgus | my solution to that was to have a menu with 1, 5 , 15 seconds and a + and - button |
22:01:17 | TorC | anonus: For your dying Clip-x, depending on how it is dying, you might want to install the modified bootloader here: http://forums.rockbox.org/index.php/topic,51304.msg237134.html#msg237134 |
22:01:30 | Bilgus | hit more and it goes to 2, 10 , 30 |
22:01:48 | TorC | It will allow the thing to keep working for you even if the internal nand flash dies. |
22:02:09 | TorC | Don't count on installing it after flash dies, though. |
22:02:15 | [Saint] | Bilgus: that gets fucky quickly. |
22:02:23 | Bilgus | if given an absolute range we could use a scrollbar |
22:02:43 | [Saint] | Bilgus: Like, if you wanted to select '8' as the unit, the upper value would be several hundred. |
22:02:43 | [Saint] | (for instance) |
22:03:09 | [Saint] | unless you do some weird non-linear scaling. |
22:03:12 | fs-bluebot | Build Server message: Build round completed after 588 seconds. |
22:03:12 | pamaury | gevaerts: do you know the build server a bit ? I've created a new build client but the server doesn't like it :( |
22:03:13 | fs-bluebot | Build Server message: Revision e259836 result: All green |
22:03:57 | Bilgus | I suppose you could do a sliding scale |
22:04:05 | [Saint] | Bilgus: and, on some devices - no, we couldn't. Menus need to work on charcell too. |
22:04:26 | [Saint] | No nice pretty selector bars there. |
22:04:37 | Bilgus | yeah, true |
22:04:55 | anonus | TorC: 3.5 mm jack is dying and it has really strange jack i could find nowhere |
22:05:27 | [Saint] | anonus: define dying? there's not a lot there that can go wrong. Likely just needs to be reflowed. |
22:05:43 | [Saint] | Their connection with the board is far from rigid. |
22:05:57 | gevaerts | pamaury: what did you do wrong? |
22:06:00 | anonus | jack just started falling out |
22:06:15 | [Saint] | Ahhh, right. |
22:06:19 | anonus | i did reflow once, but it seems that it is mechanical problem |
22:06:21 | pamaury | gevaerts: here is a typical part of my log: |
22:06:40 | pamaury | Fetching origin |
22:06:40 | pamaury | 2017-01-02 22:01:00 (../tools/configure −−target=ipod3g −−type=b && make) >> wks-50-63-pamaury-ipod3gboot.log 2>&1 |
22:06:40 | pamaury | 2017-01-02 22:01:04 Uploading wks-50-63-pamaury-ipod3gboot.log... |
22:06:40 | DBUG | Enqueued KICK pamaury |
22:06:40 | pamaury | 2017-01-02 22:01:04 curl -s -F upfile=@wks-50-63-pamaury-ipod3gboot.log https://buildmaster.rockbox.org/upload.cgi |
22:06:41 | pamaury | 2017-01-02 22:01:04 child ipod3gboot (24138) is uploading |
22:06:43 | pamaury | 2017-01-02 22:01:04 No upload |
22:06:45 | pamaury | 2017-01-02 22:01:04 child: ipod3gboot (24138) done |
22:06:47 | pamaury | 2017-01-02 22:01:04 Completed build ipod3gboot |
22:07:05 | pamaury | it does that for a while and then I am disabled temporarily |
22:07:11 | [Saint] | anonus: realistically you can use any TRS connector that fits as long as you keep track of the pinout. |
22:07:17 | gevaerts | Hmmm |
22:07:35 | pamaury | I checked and the builds are successful, but upload fails for some reason, apparently |
22:08:07 | anonus | yeah, i could just solder some wires and wire-mounted socket outside the case |
22:08:22 | gevaerts | Yes, sounds like it doesn't like the log you're uploading for some reason |
22:08:35 | gevaerts | You could try reading the server code or asking zagor I guess |
22:08:40 | Ctcp | Ignored 1 channel CTCP requests in 0 seconds at the last flood |
22:08:40 | * | gevaerts doesn't really know |
22:08:53 | Bilgus | anonus: while you are at it cover it in hot melt snot to really finish the look :p |
22:09:16 | anonus | worth trying! |
22:09:29 | anonus | hot snort is my friend |
22:09:57 | TorC | anonus: Another option would be to get a spare or two and hope that when they go, something else dies and you can steal the jack for this one. |
22:10:02 | [Saint] | I saw a guy with a clip zip with a 6mm TRS hanging out the side of it the other day actually. |
22:10:15 | anonus | hehe |
22:10:35 | [Saint] | it looked hilarious, just hanging there off his headphone cable. |
22:11:05 | [Saint] | not actually clipped to anything, presumably because SanDisk's clips on the actual Clips are all shit. |
22:11:29 | pamaury | gevaerts: is it possible that the server gives the same builds to several clients and one beat me every time ? I don't know how the server works |
22:11:56 | gevaerts | That's possible, but only near the end, and it won't disable you for that |
22:12:12 | [Saint] | Yeah, that's possible. |
22:16:48 | pamaury | gevaerts: ok I think this is an SSL error, I tried to manually upload something and it fails |
22:16:56 | pamaury | I recall someone mentioning this problem |
22:17:39 | [Saint] | Bilgus: you've got me thinking about a single generic picker but it's such a pain in the tits to do across the board. |
22:17:39 | [Saint] | Bilgus: Having each function just pass out the mix, max, and unit and having a generic picker function would be neat... |
22:18:11 | gevaerts | Ah well, if it's curl that malfunctions you want bagder instead :) |
22:18:55 | pamaury | curl is right, the domain doesn't have a certificate |
22:19:29 | pamaury | curl: (51) SSL: no alternative certificate subject name matches target host name 'buildmaster.rockbox.org' |
22:19:44 | Bilgus | [Saint]: question is how to lay it out |
22:19:53 | gevaerts | Hmmm |
22:19:59 | [Saint] | Bilgus: yeah, right. |
22:19:59 | gevaerts | It's not using https here... |
22:20:59 | gevaerts | Ah I see.... |
22:21:05 | gevaerts | It's all __builtin's fault! |
22:21:16 | chrisjj | Bilgus: Sure. Sounds right up my street. |
22:22:13 | Bilgus | chrisjj: saint has put me on a more enlightened path ill let you know when that part is finished :p |
22:22:37 | pamaury | __builtin: ping |
22:24:21 | gevaerts | __builtin changed the client to use https, but he didn't change the revision so no client auto-updates (I can't actually remember if you need to change the number somewhere else too...), and apparently he didn't test :) |
22:24:22 | Bilgus | the pcmbuf_fade_tick function is not linear |
22:25:24 | [Saint] | Why does the build client even need https? |
22:25:54 | Bilgus | rather it is linear |
22:26:00 | [Saint] | We don't need anonymity and any security gains are very questionable. |
22:26:02 | chrisjj | " Like, how to deal with if they already have a dramatic crossfade set." The two should be independent. |
22:26:26 | pamaury | gevaerts: yeah I just realized, I'm sending an email to him zagor and badger |
22:27:45 | [Saint] | What practical benefit does https between server and client achieve? |
22:27:58 | [Saint] | It's not like we publish hashes or have verifiable builds. |
22:28:00 | Bilgus | chrisjj I can send you the .rock if you want to check it out but be aware that i'm putting it in core |
22:28:38 | Bilgus | the functions and such will be put into the fade to sleep function though |
22:28:42 | gevaerts | Hmm, I think the revision number is in a config file on the server as well, so if it's bumped I suspect zagor needs to be told |
22:28:50 | chrisjj | Bilgues: OK. |
22:29:11 | Bilgus | what target are you running? |
22:29:23 | chrisjj | ZEN. |
22:29:41 | [Saint] | gevaerts: is there something I'm missing about this? As far as I see it, aside from being general good practice, there's little to no functional benefit in https for the build clients. |
22:29:56 | gevaerts | [Saint]: right now I care about unbreaking the system |
22:30:03 | [Saint] | revert it then. |
22:30:17 | gevaerts | It's not *that* simple |
22:31:06 | gevaerts | There might be clients (like pamaury's, but he of course knows there's the issue) that have the current revision, which has a wrong revision number |
22:31:18 | gevaerts | So we need a revision bump either way |
22:31:42 | gevaerts | And that requires a zagor-intervention as far as I can see |
22:31:52 | pamaury | gevaerts: for the moment I have editted my client manually to switch to http |
22:32:05 | gevaerts | So if zagor decides to enable https at the same time, why not? |
22:32:24 | pamaury | I think the simplest option is just to enable https and bump version on the server |
22:32:27 | chrisjj | I'm happy to wait until it goes in core. Though the only good ZEN build has not yet reached the master. |
22:32:47 | [Saint] | Yeah, I guess. I'd be surprised it anyone more than pamaury got caught up in this. |
22:32:47 | [Saint] | I mean, __builtin assuredly didn't test it. |
22:32:56 | gevaerts | Well, bump version on both sides |
22:33:05 | chrisjj | Bilgus: I'm happy to wait until it goes in core. Though the only good ZEN build has not yet reached the master. |
22:34:21 | pamaury | hopefully we will eventually find out all subdomains of rockbox.org that need a certificate ;) |
22:34:41 | [Saint] | mildly hilarious it's not already the case. |
22:34:47 | [Saint] | given who operates the server. |
22:35:24 | [Saint] | The dude's like, Cpt. HTTPS or Mjr. Opportunistic Encryption. |
22:36:24 | [Saint] | I understand the exit from the community but I would've thought you'd test in your own back yard and https is far from new tech. |
22:37:35 | pamaury | Well we still have problems with the tools. For example there is the licence problem that prevents Rockbox Utility from using https |
22:37:36 | gevaerts | [Saint]: he was going to, but he wanted to relax so he curled up with a book |
22:43:02 | [Saint] | pamaury: I'm not really sure that's much of a realistic concern given where theyre served from is it? |
22:43:10 | [Saint] | Its more of a meta-concern. |
22:44:17 | [Saint] | Do Swedes give a shit about bands on strong encryption export? I thought not. |
22:44:21 | [Saint] | *bans |
22:45:28 | pamaury | you are referring to the fact that the build server is insecure ? yes I agree with that, but it's everyone's fault |
22:46:22 | [Saint] | No. I'm referring to your statement about RbUtil et al not using https. |
22:46:35 | [Saint] | I don't think that matters at all given where the binaries are served from. |
22:46:44 | [Saint] | Good luck telling .se not to do something. |
22:46:50 | gevaerts | [Saint]: does Sweden ban exporting strong encryption? |
22:47:06 | [Saint] | gevaerts: no, that's my point. |
22:47:20 | gevaerts | So why is it even a question? |
22:47:55 | [Saint] | I believe that's the problem pamaury is referring to with including https in rbutil. |
22:48:16 | gevaerts | Yes, I know *that*... |
22:48:25 | * | gevaerts is confused now |
22:48:37 | gevaerts | I thought you said something about Swedes and exporting encryption? |
22:49:02 | | Join lebellium [0] (~chatzilla@89-93-179-5.hfc.dyn.abo.bbox.fr) |
22:50:12 | [Saint] | Well, I did. But...gah. It's all fucky now. What I was saying was basically a long winded way of saying that AFAIK the concern I think pamaury has about https vs. RbUtil and other distributed Rb tools isn't particularly valid by my understanding. |
22:50:42 | [Saint] | If anyone ever did get pissy about it best they could do is say "don't" to which the reply would be "nah, we're OK. Thanks" |
22:52:13 | gevaerts | Huh? |
22:52:32 | [Saint] | I think the list of projects that actually do take that license aspect seriously are probably few and far between anyway. |
22:53:33 | [Saint] | huh what? I have no idea what you're confused about. |
22:54:14 | [Saint] | Is there some _other_ other problem with the distributed tools and https I'm unaware of? I know of precisely one, and it's questionable at best. |
22:54:33 | Bilgus | __builtin: I think this belongs to you. |
22:55:09 | Bilgus | rockbox/apps/plugins/puzzles/rbwrappers.c: In function ‘vsscanf’: /usr/include/i386-linux-gnu/bits/string3.h:90:1: sorry, unimplemented: inlining failed in call to ‘bcopy’: redefined extern inline functions are not considered for inlining /rockbox/apps/plugins/puzzles/rbwrappers.c:1892:38: sorry, unimplemented: called from here |
22:56:53 | [Saint] | Bilgus: Well, at least it has the good sense to be apologetic about it. |
22:56:54 | gevaerts | The issue is that the openssl license is not compatible with the gpl. I don't think that's questionable at all |
22:57:17 | Bilgus | :p |
23:00 |
23:01:58 | Bilgus | that is weird he has bcopy defined as memcopy which I believe to be correct |
23:02:14 | Bilgus | sorry memmove |
23:06:48 | Bilgus | hell IDk anyways I commented out your version of bcopy and replaced it with #define bcopy(s1, s2, n) memmove((s2), (s1), (n)) and that fixed the compile no clue if it broke anything |
23:20:33 | | Quit pamaury (Ping timeout: 246 seconds) |
23:24:20 | | Quit edhelas (Quit: Leaving.) |
23:27:56 | | Quit n3m9 (Read error: Connection reset by peer) |
23:30:38 | __builtin | gevaerts: what did I break? |
23:31:14 | gevaerts | The build client |
23:31:27 | __builtin | give me a second to read the backlog |
23:33:16 | __builtin | ok, looks like I enabled https for too many URLs, including services that didn't support it |
23:33:42 | gevaerts | That, and you didn't bump the revision and tell zagor about it :) |
23:34:25 | __builtin | that also explains why /my/ client isn't uploading anything... |
23:34:29 | __builtin | crap |
23:35:26 | __builtin | I could just revert the line that makes the buildmaster go over TLS |
23:38:12 | __builtin | and increment the versions in the client and master |
23:38:53 | * | gevaerts nods |
23:39:18 | gevaerts | Although waiting for zagor's response might be good. He might want to just emable https, in which case just incrementing versions is enough |
23:39:31 | __builtin | has anyone emailed him yet? |
23:40:14 | gevaerts | I think pamaury did? |
23:40:18 | __builtin | it actually looks like the buildmaster url technically has HTTPS enabled right now, but the certificate is for the wrong domain |
23:40:39 | gevaerts | 22:26:28 <pamaury> gevaerts: yeah I just realized, I'm sending an email to him zagor and badger |
23:40:57 | gevaerts | Well yes, that's the same server that does www.rockbox.org and many others |
23:41:54 | | Quit diox (Ping timeout: 246 seconds) |
23:45:50 | __builtin | for now shall I just push a commit to disable HTTPS for the upload url and increment the revision? |
23:46:16 | | Quit JdGordon (Ping timeout: 245 seconds) |
23:47:13 | | Join diox [0] (~u@c80-216-201-69.bredband.comhem.se) |
23:47:25 | * | gevaerts isn't sure |
23:47:54 | __builtin | it would fix any problems with people who download the script now |
23:49:54 | gevaerts | True |
23:51:15 | __builtin | though incrementing the revision might be a bad idea because it would cause the clients to have a higher revision than the server |
23:53:46 | gevaerts | That's not actually a problem |
23:54:03 | gevaerts | The server checks for less than, and nothing else |
23:54:32 | gevaerts | So higher is fine, and IIRC we actually have sometimes bumped a few times before forcing an update |
23:55:56 | Bilgus | chrisjj: does the play and pause buttoin not work in the creative zen sim?? |
23:56:28 | __builtin | Bilgus: in what context did the aforementioned error appear? |
23:56:45 | Bilgus | building the creative zen sim |
23:57:53 | *** | Saving seen data "./dancer.seen" |
23:58:08 | __builtin | it's probably just a naming conflict from what I gather |