00:37:32 | *** | Saving seen data "./dancer.seen" |
00:43:49 | | Quit rogeliodh (Quit: Ping timeout (120 seconds)) |
00:44:20 | | Join rogeliodh [0] (~rogeliodh@rogeliodh.dev) |
01:00 |
01:13:06 | | Quit ac_laptop (Ping timeout: 272 seconds) |
02:00 |
02:25:42 | | Join petur [0] (~petur@199.59.5.111) |
02:25:42 | | Quit petur (Changing host) |
02:25:42 | | Join petur [0] (~petur@rockbox/developer/petur) |
02:37:34 | *** | Saving seen data "./dancer.seen" |
03:00 |
03:18:23 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
03:58:28 | | Quit pamaury (Ping timeout: 260 seconds) |
04:00 |
04:10:52 | braewoods | speachy: any insights into why older electronics sometimes expect low-voltage AC? apparently the original NES could take AC or DC if the voltage was correct. |
04:11:23 | braewoods | for that matter why did they use center-negative barrel jacks? |
04:11:34 | braewoods | pretty much everything today is center positive |
04:37:37 | *** | Saving seen data "./dancer.seen" |
04:38:24 | | Join pamaury [0] (~pamaury@maths.r-prg.net.univ-paris7.fr) |
04:38:24 | | Quit pamaury (Changing host) |
04:38:24 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
04:42:17 | braewoods | incidently i ended up ordering an inverter barrel jack cable |
04:42:40 | braewoods | just to deal with that problem where it's not practical to rewire existing cables to be center-negative |
04:43:14 | braewoods | it's easier just to use an adapter that flips the wires |
04:43:50 | gevaerts | I'd be very wary of that. If you're not careful, you associate power supply and device, and then one day the adapter cable isn't there... |
04:44:02 | braewoods | indeed. |
04:44:26 | gevaerts | Maybe if you heatshrink the connectors or something like that |
04:44:42 | braewoods | i was planning to add some kind of label to the inverter cable |
04:44:54 | braewoods | since it is only intended for some rare situations |
04:45:42 | braewoods | i checked out the main device i wanted to modify |
04:45:52 | braewoods | turns out it is soldered to the board so not very easy to rewire |
04:46:12 | braewoods | i would rewire it to be center positive if i could |
04:46:17 | braewoods | but doesn't seem practical |
04:46:34 | braewoods | it's easier just to use an inverter cable |
04:46:36 | braewoods | but you're right |
04:46:41 | braewoods | it needs to be clearly labeled |
04:46:46 | braewoods | at the very least |
05:00 |
05:19:34 | | Quit S|h|a|w|n (Quit: Leaving) |
05:47:20 | | Quit lemon_jesus (Ping timeout: 272 seconds) |
06:00 |
06:16:33 | | Join ulmutul [0] (~ulmutul@dslb-146-060-189-092.146.060.pools.vodafone-ip.de) |
06:18:25 | | Quit Oksana (Ping timeout: 240 seconds) |
06:24:16 | | Join JanC_ [0] (~janc@lugwv/member/JanC) |
06:24:26 | | Quit JanC (Killed (adams.freenode.net (Nickname regained by services))) |
06:24:26 | | Nick JanC_ is now known as JanC (~janc@lugwv/member/JanC) |
06:25:43 | ulmutul | braewoods: I maintain the exact opposite: almost everything is center negative :) |
06:26:10 | ulmutul | That applies to the 5mm barrel jacks; for smaller ones you are probably right (center positive). |
06:26:41 | braewoods | ulmutul: well my laptops from 2013 use center positive |
06:26:49 | braewoods | they use 7.5mm or so |
06:27:11 | braewoods | i have an older arm box with 5.5mm 5v center positive barrel jack |
06:27:11 | ulmutul | E.g. all this guitar effect stuff is (and was) 9V/center positive. |
06:27:18 | braewoods | I see. |
06:27:35 | braewoods | i don't own such things so i guess that's why |
06:28:56 | ulmutul | Some audio devices need AC voltage to generate symmetric voltage, i.e. they generate +9V/0V/-9V from a single 2-line-AC input. |
06:37:40 | *** | Saving seen data "./dancer.seen" |
06:49:25 | | Quit Stanley00 () |
06:57:48 | braewoods | ulmutul: i see. odd though considering generating inverted voltages is just a matter of flipping wires. |
06:57:59 | braewoods | but i guess crossing wires isn't always practical. |
07:00 |
07:01:22 | speachy | braewoods: anything using classic op-amps or bipolar logic uses symmetrical +- voltage, and it's easier to get that from straight AC than it is to use a switching DC/DC charge pump to invert it. |
07:06:51 | ulmutul | in other words: the voltage is doubled, you have a full swing of lets say 18V (from -9 to +9V). |
07:08:16 | | Quit _bilgus_ (Remote host closed the connection) |
07:10:09 | | Join _bilgus_ [0] (~bilgus@2605:a000:1301:89f6:e5a5:7286:a5d3:d72f) |
07:18:24 | speachy | no, wait, bipolar is something else. ugh. not enough sleep. |
07:21:01 | speachy | anayway. it greatly simplifies your power supplies, and before the days of switched supplies, it was pretty much the simplest way of achieving it. |
07:24:54 | speachy | (Most of what I know about this stuff was via osmosis; my last gig had me working with some very talanted analog folks working to design an ultra-low-power BTLE radio) |
07:30:10 | | Join MrZeus__ [0] (~MrZeus@2a02:c7f:70d0:6a00:cc6a:52fa:7d38:2ab9) |
07:49:17 | speachy | BTW, the pine64 folks are proposing something based on the design of their PineCube −− https://wiki.pine64.org/index.php/PineCube |
07:49:47 | speachy | Allwinner V3 (ARM Cortex-A7 @ 1.2GHz, 128MB on-package RAM) |
08:00 |
08:00:10 | speachy | it probably would make a decent enough "hosted" port −− we'd have the full ability to control the base Linux layer. |
08:00:27 | speachy | but I'd really want to go native. |
08:31:52 | speachy | I think pine64 is offering to send a couple over to us. Who all would want one? |
08:37:44 | *** | Saving seen data "./dancer.seen" |
08:42:50 | braewoods | looks perfect to start with |
08:42:59 | braewoods | it has more than needed but |
08:43:22 | speachy | it's mostly a matter of removing stuff we don't want. |
08:43:33 | braewoods | or simply leaving it there unused |
08:43:45 | speachy | in the mean time it's a good dev platform |
08:44:12 | braewoods | more than enough RAM |
08:44:30 | speachy | aaand full schematics + source code. :) |
08:44:45 | braewoods | GPIO could be used for buttons |
08:45:11 | braewoods | the networking bits could be removed |
08:45:18 | braewoods | same with camera |
08:45:39 | braewoods | usb is probably the only communication necessary |
08:45:48 | braewoods | and it can be used to get a serial console and more |
08:46:44 | speachy | we'd need OTG |
08:47:53 | speachy | I was also looking at this previously: https://www.ebay.com/itm/Cherry-Pi-Allwinner-V3S-LINUX-QT-ARM-Open-Source-Maker-Dev-Board-PK-Raspberry-Pi/284019059827 |
08:48:17 | speachy | same SoC (albeit in different packaging and half the RAM) |
08:48:53 | braewoods | speachy: ah. |
08:49:02 | braewoods | well usb OTG is probably a good idea to have anyway |
08:49:12 | braewoods | it's something rockbox relies on |
08:49:38 | braewoods | eventually i'll look at MTP support work |
08:49:45 | speachy | well, yeah. obviously pine64 would be spinning a new board, but having a working port to an existing board (same SoC) would be 90% of the way there |
08:49:46 | braewoods | but i suspect some ports simply won't work with it |
08:49:53 | braewoods | due to lacking hardware or so |
08:50:31 | speachy | anything with a soft USB stack (which is nearly all of 'em) are technically capable of MTP. Whether or not they have enough RAM is to pull it off is another matter. :) |
08:50:32 | braewoods | speachy: sounds interesting. not sure what type of interfaces you'd want to do audio with. |
08:50:37 | braewoods | USB is an option i guess? |
08:51:03 | speachy | the pinecube uses teh SoC's internal audio codec, as does that "cherry pi". |
08:51:12 | braewoods | oh, it has audio |
08:51:29 | speachy | the SoC supports i2s for external codecs too, naturally |
08:51:39 | braewoods | are they any good? |
08:51:42 | braewoods | i suspect cheap stuff |
08:52:01 | braewoods | with a cpu this beefy we could just do all decoding in software |
08:52:09 | braewoods | just need good quality outputs? |
08:52:15 | speachy | (well, we already do all decoding in software) |
08:52:19 | braewoods | Oh. |
08:52:21 | braewoods | lol |
08:52:53 | speachy | the SoC has both internal headphone driver and a line-level output from its codec. |
08:53:25 | speachy | the pine64 speaker uses an external amp attached to the line out, whereas the "pi" is a straight headphone connection |
08:54:11 | speachy | tbh I think that, with proper component isolation, the quality will be plenty good. |
08:54:28 | speachy | (eg don't cheap out on isolating capacitors and power supply filtering) |
08:54:35 | braewoods | i see |
08:54:45 | braewoods | it has bluetooth and wifi |
08:54:55 | braewoods | of these only BT has any merit but rockbox has no BT stack |
08:55:16 | speachy | just wifi, I think. |
08:55:20 | braewoods | https://www.pine64.org/cube/ |
08:55:37 | braewoods | interesting. |
08:56:17 | braewoods | well it would simplify the board if we strip out anything that isn't going to be used |
08:56:52 | speachy | I just don't see the bt stuff on the schematic obviously. |
08:56:58 | speachy | there is a dedicated uart for debug |
08:57:23 | braewoods | we'd probably want to use u-boot... |
08:57:35 | braewoods | or maybe not |
08:57:40 | braewoods | a custom RB bootloader might work just as well |
08:57:52 | braewoods | but we'll probably be taking references from u-boot and linux |
08:58:08 | speachy | ok, there it is, BT is uart-attached |
09:00 |
09:01:45 | gevaerts | Do we have some idea what the cost would be? If that's fairly high due to relatively low volume and other fun stuff, it might be a good idea to add an external audio codec with a good reputation to help make it worth the price |
09:01:58 | speachy | assuming this goes forward, step 1 would be to port rockbox-as-an-app to their base SDK platform. |
09:02:25 | speachy | well, this pine64 thing is $30 in single-uint quantities, including a camera and other crap. |
09:02:51 | speachy | I'd prefer an external codec too, but it's a tradeoff between form factor + battery life. |
09:03:39 | speachy | I'm thinking shooting for something the size of the Rocker would be ideal, and that's probably not going to get us a large enough battery for an external codec worth a damn |
09:04:21 | speachy | but the nice thing about this base platform is that it's easily extendable. |
09:04:33 | speachy | no reason we couldn't end up with more than one player at different size/pricepoints |
09:05:19 | speachy | but this is likely to only be viable if we're able to re-use an existing case design that already has the tooling paid for |
09:06:27 | gevaerts | Right. Screen is optional though, so not included in that $30. It's unclear what sort of sales volume the DAP-respin would get, and I'm guessing a screen is more expensive than a camera and the other stuff we don't need, so let's say $40. Plus indeed a case, which is kind of essential... |
09:06:28 | speachy | new tooling is in the six digits range. |
09:06:46 | | Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net) |
09:07:33 | gevaerts | If you only sell 50, 3d print it, but yes, that's the real issue these days |
09:07:53 | speachy | the case is the most expensive part, solely due to the NRE. |
09:08:33 | speachy | displays are a plentiful and cheap commodity |
09:09:13 | speachy | and other than the actual SoC+PMIC (and possibly an external audio codec) there's little else of note. |
09:10:03 | speachy | well, biggest possible battery in the remaining volume, anyway.. |
09:11:50 | speachy | another price point −− that CherryPi thing is $17 in single-unit quantities. Obviously lacking a display, case, and battery. |
09:13:21 | speachy | if we, say, double that for the missing bits that means we're probably looking at a $50-60 final pricing; ie in the range of the rocker or m3k. |
09:14:40 | braewoods | and a platform that doesn't need to be reverse-engineered |
09:14:43 | speachy | (and that cherry pi thing has wifi too) |
09:15:15 | braewoods | i assume sd card for storage |
09:15:20 | speachy | the SoC has full mainline linux support (except for the video encoder which we don't care about) |
09:15:21 | braewoods | or would MMC be an option? |
09:15:37 | speachy | eMMC is an option, but we'd want external SD. |
09:15:53 | braewoods | how fast would the SD cards be? |
09:16:03 | braewoods | it would be nice if we could saturate USB |
09:16:04 | braewoods | 2.0 |
09:16:23 | braewoods | optional but nice if doable |
09:16:28 | braewoods | there's enough ram to buffer writes |
09:16:30 | braewoods | so |
09:16:32 | braewoods | it should be doable |
09:16:45 | speachy | it's SD 2.0 (ie 4-bit) but the question is if the controller can handle UHS-1 signaling on top of that. |
09:16:46 | braewoods | if the physical hardware would otherwise allow it |
09:16:59 | braewoods | and how fast can that be? |
09:17:36 | braewoods | hm. |
09:17:41 | braewoods | ah. the most common one i know |
09:17:52 | braewoods | limited to 32G |
09:18:02 | speachy | standard SD is up to 25MHz @4bits == 100Mbit = 12.5 MB/s max |
09:18:18 | braewoods | that's fast enough i guess |
09:18:18 | speachy | UHS ups that to 100MHz (I think) ie 50MB/s. |
09:18:30 | braewoods | comparable to existing native targets |
09:18:52 | speachy | UHS-1, that is. UHS-2 goes to 8 bit signaling (and a second row of pins on the card) |
09:19:06 | braewoods | UHS-1 is fast enough |
09:19:09 | gevaerts | Forget "limited to 32GB" That's a confused set of weirdness |
09:19:26 | braewoods | gevaerts: i see. i know SD 2.0 specified that. |
09:19:57 | speachy | UHS-1 requires different (LVDS?) signaling across the pins; it's not just a higher clock speed. |
09:20:22 | braewoods | ah. |
09:20:29 | gevaerts | Yes. As I understand it the spec says 'You have plenty of bits in the block address to use loads of storage, but we're going to declare that you can't go over 32GB for no good reason at all' |
09:20:45 | braewoods | so unofficially it can go higher |
09:21:10 | speachy | such is the decree of the SD Association. |
09:21:31 | gevaerts | There's no native rockbox device with an SD card size limit of 32GB. Some have such a limit in the OF... |
09:21:34 | speachy | granted, SDXC got rid of that arbitrary limit. |
09:22:18 | braewoods | main reason to use SD cards is size constraints i guess |
09:22:23 | braewoods | main drawback is they tend to be slow |
09:22:29 | speachy | the only thing is that SDXC mandated exFAT. |
09:22:35 | speachy | and that required separate licensing from MS |
09:22:46 | braewoods | can't we just have users reformat their cards? |
09:22:50 | gevaerts | Which again should have been out of scope for the spec... |
09:22:51 | speachy | so when you see "32GB" max it usually means they can't handle exfat |
09:23:04 | braewoods | i know FAT32 can go beyond 32G |
09:23:15 | speachy | and yes, one can always reformat the card. |
09:23:59 | speachy | and rockbox has several workarounds for not-quite-reformatted-properly SDXC cards. |
09:25:01 | speachy | anyway −− the addressing protocol of SD maxes out at 2TB. That's our acutal upper limit |
09:25:12 | braewoods | lol |
09:25:27 | speachy | (though I suppose they could wave the magic wand and go to larger block sizes like they did to go from SD->SDHC) |
09:25:41 | braewoods | anyway |
09:26:21 | braewoods | it's kinda interesting how they greatly expand the LBAs for PATA but i think only SATA really ever reached drives that massive |
09:26:25 | braewoods | 48-bit LBA |
09:26:47 | braewoods | natively anyway |
09:26:54 | speachy | ok, the S3/V3 SoC does not handle UHS signaling |
09:27:02 | braewoods | so it's impossible |
09:27:19 | braewoods | not a big deal; only real benefit is faster IO, no? |
09:27:46 | braewoods | just would be nice to make syncing faster |
09:27:49 | gevaerts | If the SD association had specified LBA48, there would be a paragraph in the spec saying that while the protocol supports for 48 bit addressing, you can only use 35 of those |
09:27:56 | braewoods | lol |
09:28:37 | braewoods | afaik we don't want to use the massive drives that earlier MP3 players used |
09:28:46 | braewoods | want to use sd cards to limit how much space is needed |
09:28:53 | speachy | in practical terms the bottleneck in our file transfers is not the raw SD bus speed. our stack isn't the most efficient. |
09:28:59 | braewoods | ah. |
09:29:00 | speachy | (but it is small!) |
09:29:14 | speachy | (I think the bigger bottleneck is actually on the USB side) |
09:29:26 | braewoods | we'd need to benchmark it |
09:29:32 | braewoods | might be possible to improve it |
09:29:34 | braewoods | but |
09:29:46 | braewoods | some improvements may have to be gated for targets that don't have enough RAM |
09:29:51 | speachy | SD 2.0 maxes out at 25MB/s, though it's not clear if that's with 4-bit or 8-bit signaling. |
09:30:05 | braewoods | that would be sufficient |
09:30:08 | braewoods | but how? |
09:30:22 | braewoods | anyway |
09:30:31 | speachy | ie dial the clock speed as high as the card claims to support and have at it |
09:30:43 | braewoods | i would need to profile the existing stack to see what is slowing it down |
09:30:47 | braewoods | lack of buffering? etc |
09:30:53 | speachy | that's the raw bus bandwidth, not counting overhead and things like waiting for the card to actually perform writes |
09:31:27 | speachy | buffering, inefficient use of DMA, our multitasking/scheduling model.. |
09:31:57 | speachy | huh, there's now an SDUC that goes up to 128TB. |
09:32:03 | braewoods | i may profile rockbox on a few devices |
09:32:10 | braewoods | to see where time is spent when writing |
09:32:22 | braewoods | see if i can improve it |
09:32:39 | braewoods | but OFC... it may not be practical |
09:32:52 | braewoods | easiest avenue to explore is larger buffers |
09:33:11 | braewoods | might be viable for 32MB targets |
09:33:12 | gevaerts | There's things you can measure if you want to isolate where you should look first. There's the set of test plugins of course that include file read/write speed tests (but that goes through the FAT layer, which may have an impact), and you can change the USB code to just throw away incoming data and send junk back to measure raw USB speed |
09:33:39 | braewoods | gevaerts: actually i was considering testing writing from directly in RB vs over USB |
09:33:50 | braewoods | though yes |
09:33:58 | braewoods | the direct writes should be more efficient |
09:34:06 | gevaerts | Yes. I think you need all the numbers :) |
09:34:08 | braewoods | no USB layer to go through (in theory) |
09:34:28 | braewoods | i know enough about stuff now |
09:34:32 | braewoods | i'll look into it later |
09:34:37 | speachy | also keep in mind that those obscene speeds are only achievable during sequential access |
09:34:40 | speachy | especially writes |
09:34:50 | braewoods | probably |
09:34:51 | speachy | and in mass storage we're jumping all over the place |
09:34:54 | gevaerts | If it turns out that SD writing goes at 3MB/s on a specific target, but USB only does 2MB/s anyway. that 3MB is fine |
09:35:10 | braewoods | i just wish to see if i can find something that can be improved upon |
09:35:28 | braewoods | if more caching could help |
09:35:29 | speachy | there's a lot of overhead to set up a transfer; the longer the actual transfer the less that overhead matters |
09:35:30 | braewoods | that might work |
09:35:48 | braewoods | speachy: indeed. i expect large files, like single file FLAC albums would be most efficient |
09:35:50 | braewoods | to write |
09:36:01 | braewoods | 300+ MB a pop |
09:36:27 | speachy | that's why for benchmarks I was bypassing filesystems altogetehr and just going for straight dd (with 64K blocks) |
09:36:38 | speachy | so no filesystem overhead to cause jumping around |
09:36:47 | gevaerts | If you want to measure USB in isolation, look for USB_USE_RAMDISK in usb_storage.c. That still includes a memcpy(), but you can comment that out (and get garbage of course) for raw speed |
09:37:32 | braewoods | bbl |
09:38:15 | speachy | (and results will obviously vary from target to target) |
09:47:22 | | Quit ulmutul (Ping timeout: 272 seconds) |
10:00 |
10:02:47 | speachy | So! |
10:02:59 | speachy | today's the day I want to do the toolchain bump |
10:37:47 | *** | Saving seen data "./dancer.seen" |
10:53:15 | | Quit massiveH (Quit: Leaving) |
11:00 |
11:01:49 | _bilgus_ | I contend it doesn't matter as long as the fuckers label it |
11:02:43 | * | speachy raises an eyebrow. |
11:02:44 | _bilgus_ | ran across a norditrack or similar no label at all but want $75 for a power brick old transformer wall wart |
11:03:03 | speachy | ah, okay, finally context. :) |
11:03:26 | _bilgus_ | took it apart no protection for rp they meant that to die |
11:03:45 | _bilgus_ | sorry screen was half up thought I was in the middle lol |
11:06:51 | | Join johnb7 [0] (~johnb2@p5b3af7ce.dip0.t-ipconnect.de) |
11:14:20 | _bilgus_ | speachy re pine I don't have a lot of experience LL porting stuff but this is probably the best chance to do it! |
11:15:10 | _bilgus_ | if none of our superstars showup then I'd dev one and we can just send them around as rb community property |
11:16:12 | johnb7 | speachy I ran battery bench on the x3ii: http://www.mediafire.com/folder/5qmycn43z1sew/batterybench_X3ii |
11:16:53 | johnb7 | Am I right, that currently we don't differentiate between x20 and x3ii: https://git.rockbox.org/cgit/rockbox.git/tree/firmware/target/hosted/xduoo/powermgmt-xduoo.c?id=f791df13751d0c43a2b1ae0adb6f6bc4385c2cc3 |
11:17:19 | speachy | correct. I don't know if there are any appreciable differences with respect to the batteries. |
11:22:33 | johnb7 | btw, thanks a lot for the audio fixes on the x3ii: the nasty pop is gone, I don't hear a click anymore on pause/unpause at least if 'fade on pause' is active, the remaining sound on track skip is bearable. |
11:23:29 | speachy | 13:06, eh? booting into the OF afterwards, what was their view of the remaining life? |
11:26:17 | johnb7 | see the conditions.txt: volume was at -50 with those buds. I haven't checked the OF status afterwards, but wanted to record the charging curve, triggered batterybench again, but it went into USB mode (connected to a wall charger) and didn't record anything. mount<0> or something on the screen (I noticed only after 5h). |
11:28:29 | speachy | the curve is definitely skewed high. the last 10% took >5h to drain. :) |
11:30:45 | johnb7 | usually I use an mp3 album, but this time it was mpc. I didn't pay attention. |
11:31:09 | speachy | the absolute life doesn't matter so much as the percentages |
11:31:14 | speachy | in this context anyway |
11:34:10 | _bilgus_ | johnb7, disk is not accessible in usb it mounts it for itsself |
11:35:25 | _bilgus_ | in theory bb keeps everything in ram so just be sure to unplug before saving I suppose |
11:37:32 | johnb7 | then how was the charging curve recorded for all the targets? |
11:37:56 | speachy | _bilgus_: do you still have the battery bench you did for the X3? I want to double-check something |
11:38:35 | speachy | hold down play when you plug in USB, it won't mount then. |
11:40:02 | johnb7 | speaking of x3: the OF has the high/low gain setting. Is this identical with the +6bB in RB or does it also set a different bias current and thus influence battery life? |
11:41:29 | _bilgus_ | pastebin |
11:42:35 | _bilgus_ | speachy https://pastebin.com/fbz1zVeH |
11:42:52 | speachy | no idea, I haven't looked into that. |
11:43:07 | speachy | danke |
11:46:30 | _bilgus_ | how to best measure that? probably a dummy load and voltage drop |
11:47:20 | johnb7 | Basically, I was wondering if in RB we could save further ... |
11:49:59 | _bilgus_ | we do have a manulal for the audio chip IIRC there are probably some phantom power settings etc but that all depends oon having the right things in place at the board level |
12:00 |
12:00:28 | speachy | the x3's audio (and power) paths are pretty poorly optimized |
12:00:39 | speachy | x3ii seems to be better in that regard |
12:02:01 | fs-bluebot | Build Server message: New build round started. Revision e91f89a, 290 builds, 9 clients. |
12:02:32 | speachy | johnb7: this build going now incorporates your benchmark run |
12:03:13 | speachy | including a stab at runtime estimation. tbh I suspect the overhead of mpc vs mp3 is lost in the noise versus keeping the audio path going. |
12:04:12 | speachy | interesting, that 13 hour result matches xduoo's claims, but is about 3h longer than most reviews say things last. |
12:11:22 | speachy | I have the bench running on the hifiwalker h2 now, with a 1300mAh battery |
12:12:24 | speachy | they claim 30h (!) |
12:14:04 | speachy | after this build is done I want to do the toolchain bump. |
12:15:12 | | Quit pamaury (Quit: Konversation terminated!) |
12:21:35 | | Quit petur (Quit: Connection reset by beer) |
12:22:20 | fs-bluebot | Build Server message: Build round completed after 1218 seconds. |
12:22:24 | fs-bluebot | Build Server message: Revision e91f89a result: All green |
12:24:06 | speachy | ok, my builders are fixed. |
12:26:36 | speachy | master build list updated to use gcc494 for everything |
12:27:08 | fs-bluebot | Build Server message: New build round started. Revision b4865b0, 290 builds, 9 clients. |
12:27:27 | speachy | okay, it's going. |
12:35:04 | speachy | amiconn, Strife89, __builtin, please update your builders with the new arm/m68k toolchains. |
12:35:43 | | Join lemon_jesus [0] (~lemon_jes@c-73-9-49-209.hsd1.in.comcast.net) |
12:36:31 | speachy | I don't know who runs the vm[12]-b0hoon builders, alas. |
12:36:50 | Strife89 | Will do |
12:37:51 | *** | Saving seen data "./dancer.seen" |
12:39:36 | braewoods | speachy: define "toolchain bump"? |
12:39:53 | speachy | braewoods: g#2305 |
12:39:55 | fs-bluebot | Gerrit review #2305 at http://gerrit.rockbox.org/r/2305 : Build: Bump all toolchains to GCC 4.9.4 + Binutils 2.26.1 by Solomon Peachy |
12:40:20 | braewoods | speachy: ah. ok. you should probably make sure to include that flag for disable the null pointer optimization. |
12:40:39 | speachy | arm and m68k targets were still on gcc 4.4.4 and 4.5.2, respectively. |
12:40:49 | braewoods | i think it was introduced in 4.9.x and was the source of some bugs |
12:40:56 | braewoods | in linux kernel |
12:41:28 | speachy | (mips and hosted arm/mips were already using 4.9.4, and of course simulator/etc builds were using whatever the host compiler was) |
12:41:59 | braewoods | speachy: may want to include this in CFLAGS for the 4.9.x toolchain |
12:42:00 | braewoods | -fno-delete-null-pointer-checks |
12:42:20 | braewoods | i assume rockbox uses NULL and may appear to dereference it at times |
12:42:30 | braewoods | i've seen kernel code do that |
12:43:27 | braewoods | speachy: i'd do the arm PP next |
12:43:43 | braewoods | or so |
12:43:52 | speachy | arm PP was the main holdup for this |
12:43:59 | braewoods | ah. |
12:44:03 | | Quit johnb7 (Quit: Nettalk6 - www.ntalk.de) |
12:44:05 | braewoods | so m68k should be fine? |
12:44:23 | braewoods | should i recompile the bootloader with new toolchain? though i can't see any benefit to doing so |
12:44:39 | speachy | two major issues; a bug in binutils causing linking issues and some technically-not-legal inline asm that no longer worked. |
12:44:39 | braewoods | the issue is fixed |
12:45:05 | speachy | if you don't have the ability to unbrick your ihp, I'd say no, don't rebuild the bootloader |
12:45:11 | braewoods | indeed |
12:45:15 | braewoods | i took a risk doing what i did |
12:45:26 | braewoods | i wanted to do it before the toolchain updates |
12:45:29 | braewoods | due to the risks it carries |
12:45:43 | speachy | I was told (many moons ago) that the test builds I did for the ihp1xx worked with no issues. |
12:46:15 | braewoods | either way i will probably try a bootloader build after the toolchain is proven reliable for new firmware builds |
12:46:21 | _bilgus_ | braewoods it'd be a good idea to keep what you have till it gets tested abit more, we don't change bootloader often at all |
12:46:27 | braewoods | indeed |
12:46:37 | braewoods | if pre5 seems to work just fine and such |
12:46:45 | braewoods | i'll do a 7 release |
12:46:52 | braewoods | and we can try that to replace BL 6 |
12:48:13 | braewoods | but i need to test it more |
12:48:36 | braewoods | i intend to do 7 build on new toolchain |
12:48:38 | braewoods | but for now no |
12:49:04 | braewoods | i'll see if i can go back to OF |
12:49:13 | braewoods | so i can test it with OF as well |
12:49:21 | speachy | 35 left.. |
12:51:34 | braewoods | my reasoning... if the toolchain works reliably for the main firmware, there's a greater chance it will do the same for the bootloader |
12:52:01 | speachy | yes, but the bootloader is more likely to be um, abusing the C spec due to direct hardware or asm manipulation |
12:52:18 | braewoods | i see. |
12:52:20 | speachy | I'm confident that the general firmware is fine. |
12:52:39 | braewoods | so the ASM stuff could be borked? |
12:52:43 | braewoods | is that what you're saying? |
12:52:53 | speachy | that's what I'd suspect the most. |
12:53:04 | speachy | but a good first pass would be to simply build it, and see if any warnings show up. |
12:53:23 | braewoods | hm |
12:53:44 | braewoods | gcc 4.5... first released on 2010 |
12:53:54 | braewoods | so this isn't the same toolchain that build the previous bootloader |
12:54:39 | speachy | I don't know the history of the bootloader binary builds. |
12:54:49 | braewoods | me either |
12:54:57 | braewoods | i was just looking at the timestamps to get a rough idea |
12:55:43 | speachy | last one.. |
12:56:11 | fs-bluebot | Build Server message: Build round completed after 1743 seconds. |
12:56:12 | fs-bluebot | Build Server message: Revision b4865b0 result: 122 errors 113 warnings |
12:57:26 | speachy | well, the only warning in the ihp boot code are some set-but-not-used variables |
12:57:39 | braewoods | totally harmless |
12:58:15 | braewoods | probably time to just punch m68k out |
12:58:26 | braewoods | so the toolchains are fairly synchronized |
13:00 |
13:00:18 | speachy | looks like most of the red in bootloaders is due to use of division, probably in a printf. |
13:01:39 | _bilgus_ | I'm pretty sure we had to make conditionals the last time to dial back the functionality quite possible it needs updated for the BLs |
13:02:32 | _bilgus_ | for printf sorry damn the contexts! |
13:04:47 | speachy | it's in ipod-specific code though |
13:13:23 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
13:14:12 | _bilgus_ | I'm not finding the conditionals in vuprintf though apparently I don't remeber where they were |
13:28:52 | speachy | could you look at g#2845 for me please? |
13:28:53 | fs-bluebot | Gerrit review #2845 at http://gerrit.rockbox.org/r/2845 : Fix compile warnings (set-but-not-used) on big endian targets by Solomon Peachy |
13:29:07 | | Join lebellium [0] (~lebellium@89-92-69-66.hfc.dyn.abo.bbox.fr) |
13:37:47 | fs-bluebot | Build Server message: New build round started. Revision ca32689, 290 builds, 9 clients. |
13:38:23 | speachy | ok, this will fix mot of the yellow, and a bit of the red too. I think all that will remain are the PP bootloaders and their reference to division. |
13:40:13 | _bilgus_ | looks sane to meeee |
13:40:56 | _bilgus_ | I'm a little surprised that the older toolchain didn't highlight that seems cut and dry |
13:43:38 | _bilgus_ | well thats enough for today I think I should have most of the plugins that need workarounds finished tomorrow and I think* the remote lcd stuff shoulkd fall into place so probably the weekend I should have the viewport stuff ready for testing |
13:43:56 | speachy | probably only picked up because of the change to -Os |
13:44:59 | speachy | no, that's not right, m68k was -Os before. guess the new toolchain is just has better diagnostics. :) |
13:46:29 | _bilgus_ | makes sense I suppose I wonder if that error in the sim settings save is still there with the newer toolchain JhMikeS wasn't very happy when I removed his optimizations but I was tired of 60MB+ config.cfg files |
13:48:15 | _bilgus_ | g#1975 |
13:48:16 | fs-bluebot | Gerrit review #1975 at http://gerrit.rockbox.org/r/1975 : Fix vuprintf fix possible %s buffer over-read by William Wilgus |
13:54:51 | | Join johnb7 [0] (~johnb2@p5b3af7ce.dip0.t-ipconnect.de) |
13:55:00 | speachy | on the plus side... check out the binary size deltas! |
13:57:35 | fs-bluebot | Build Server message: Build round completed after 1188 seconds. |
13:57:36 | fs-bluebot | Build Server message: Revision ca32689 result: 115 errors 55 warnings |
14:00 |
14:01:29 | _bilgus_ | yeah 70k+ deltas amazing |
14:01:43 | _bilgus_ | hopefully not a sign of bugs :[ |
14:01:45 | speachy | the codecs are nearly all untouched |
14:02:16 | _bilgus_ | theys have a lot of asm from all those years of 'improvements' |
14:02:52 | _bilgus_ | I just hope there aren't any bugs in codec land some of that is a scary mess |
14:03:05 | _bilgus_ | most* |
14:03:10 | speachy | (I deliberately left those alone, I figure we can do benchmarks of -Os vs whatever they are now) |
14:03:45 | | Quit johnb7 (Ping timeout: 240 seconds) |
14:04:20 | _bilgus_ | I imagine most aren't currently -Os |
14:04:48 | speachy | most are -O2 or -O3 |
14:04:49 | _bilgus_ | bb in 12hrs have fun |
14:09:15 | | Join TheLemonMan [0] (~lemonboy@irssi/staff/TheLemonMan) |
14:37:52 | *** | Saving seen data "./dancer.seen" |
14:44:25 | | Quit pamaury (Ping timeout: 240 seconds) |
14:53:23 | | Join johnb7 [0] (~johnb2@p5b3af7ce.dip0.t-ipconnect.de) |
15:00 |
15:18:04 | | Join Rower [0] (~Rower@78-73-72-39-no2340.tbcn.telia.com) |
15:25:18 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
15:37:02 | johnb7 | exit |
15:37:25 | Strife89 | /quit |
15:37:53 | johnb7 | wrong focus ... |
15:38:06 | | Quit johnb7 (Quit: Nettalk6 - www.ntalk.de) |
15:42:04 | speachy | the gigabeat-s/imx31 read is due to some horrid abuse of CPP, forward-declaring a function name inside a static initializer. |
15:48:51 | fs-bluebot | Build Server message: New build round started. Revision b94db70, 290 builds, 8 clients. |
15:51:48 | speachy | that should knock out everything but the PP bootloader and the ZenVisionM. |
15:57:40 | braewoods | speachy: is m68k big or little endian? |
15:57:44 | speachy | big |
15:57:49 | braewoods | from what i've seen big endian is a bit rare |
15:57:54 | speachy | it is now |
15:57:54 | braewoods | ah. |
15:59:44 | braewoods | speachy: kinda interesting though. i always thought big endian would take over but little endian did. |
15:59:54 | speachy | intel was cheeeeeep |
16:00 |
16:00:06 | braewoods | big endian is native byte order so i thought it would dominate in networking gear, etc |
16:00:12 | braewoods | since, no need to byte swap as much. |
16:00:15 | braewoods | err |
16:00:18 | braewoods | network byte order |
16:09:50 | | Quit mendelmunkis (Read error: Connection reset by peer) |
16:10:14 | | Join mendelmunkis [0] (~mendelmun@ool-435680b7.dyn.optonline.net) |
16:12:48 | fs-bluebot | Build Server message: Build round completed after 1435 seconds. |
16:12:50 | fs-bluebot | Build Server message: Revision b94db70 result: 83 errors 61 warnings |
16:16:30 | | Quit Acou_Bass (Ping timeout: 256 seconds) |
16:19:44 | | Join Acou_Bass [0] (~eddie@cpc96070-bolt17-2-0-cust175.10-3.cable.virginm.net) |
16:22:29 | | Join ac_laptop [0] (~ac_laptop@186.2.247.129) |
16:36:21 | braewoods | speachy: they were? seems like intel is expensive these days |
16:36:46 | braewoods | it seems like their biggest innovation is their pricing models lately |
16:37:53 | *** | Saving seen data "./dancer.seen" |
16:45:13 | | Quit Rower (Ping timeout: 264 seconds) |
16:55:37 | speachy | braewoods: think back three decades. |
16:56:33 | speachy | IBM went with intel for the PC because Motorla's 68K was much more expensive. |
16:56:41 | speachy | (four decades, really..) |
16:56:49 | braewoods | the 8088 |
16:57:08 | braewoods | so why did they pick that instead of the 6502? |
16:57:17 | braewoods | because it was stuck at 16 bit memory? |
16:57:27 | speachy | the 8088 was _much_ more powerful than the 6502. |
16:59:14 | speachy | 64 |
16:59:29 | braewoods | speachy: was it painful to code for the original memory model? i vaguely recall it was using segments |
16:59:33 | braewoods | 16 x 16 |
16:59:35 | braewoods | or so |
16:59:44 | speachy | yeah, segmented. and still supported to this day. |
16:59:55 | braewoods | only if running in 16 bit mode |
16:59:59 | braewoods | no? |
17:00 |
17:00:07 | speachy | but still simpler than dealing with that much memory on a 6502 |
17:01:54 | braewoods | because 6502 required bank swapping? |
17:03:30 | braewoods | not to mention the method of switching and such were system specific |
17:04:28 | speachy | it's also even more register constrained than the 8086; native 8-bit instead of 16-bit. |
17:04:33 | speachy | too, I mean |
17:05:06 | braewoods | i think modern 32 bit CPUs even are far better to deal with |
17:05:11 | braewoods | flat memory model FTW |
17:05:29 | braewoods | i hate having to map memory around like that |
17:05:35 | braewoods | i'd rather have it always mapped |
17:05:47 | speachy | yep. but memory used to be super expensive, so you neeed your code to be ultra-compact too. |
17:06:10 | braewoods | 64 bit doesn't offer as much as the leap to 32 bit did |
17:06:12 | speachy | couldn't afford to waste 32 bits on memory addresses |
17:07:05 | braewoods | and i can't see 128 bits being a thing anytime soon since the main driver of cpu jumps were all memory related |
17:07:19 | braewoods | for common cpus |
17:07:21 | braewoods | anyway |
17:07:27 | braewoods | specialized ones are an exception |
17:07:48 | speachy | 128-bit addressing, maybe not, but 128-bit ALUs are definitely a thing already |
17:07:50 | | Quit lebellium (Quit: Leaving) |
17:08:13 | braewoods | speachy: in fact the 64 bit memory space only has 48 bits for physical memory in x86_64 |
17:08:23 | braewoods | but that still leaves an insane amount of space for growth |
17:08:55 | braewoods | consumer PCs... the most i've ever had was 16G in a single system |
17:09:09 | braewoods | that only needs 34 bits |
17:10:12 | braewoods | ... lol |
17:10:20 | braewoods | from #learnprogramming |
17:10:21 | braewoods | TheHermann | how improve my C? |
17:10:33 | gevaerts | The big problem is that consumer CPUs with a 128 bit ALU and 64 bit memory addressing would make the entire IT infrastructure grind to a halt because everyone would be too busy to debate whether it's a 64 bit or a 128 bit CPU to maintain the lot |
17:10:49 | braewoods | gevaerts: lol |
17:11:03 | braewoods | but there's like 0 benefit from having pointers that big |
17:11:21 | gevaerts | Let's all go back to the nice 4 bitness of the Z80 :) |
17:12:41 | braewoods | gevaerts: no thanks. i don't want to use the appetizer of data processing. |
17:12:43 | braewoods | LOL |
17:13:01 | braewoods | since those are "nibbles" |
17:13:19 | gevaerts | http://www.righto.com/2013/09/the-z-80-has-4-bit-alu-heres-how-it.html in case you weren't aware :) |
17:15:46 | braewoods | gevaerts: looks like trivia. |
17:16:11 | braewoods | to the users the difference is probably irrelevant beyond what it means for expectations |
17:16:46 | mendelmunkis | speachy: is the new toolchain supposed to require gmp to build? |
17:17:07 | gevaerts | It's trivia and fodder for people who like debating meaningless things |
17:17:29 | braewoods | gevaerts: kinda like how C digraphs and trigraphs are trivia because no one really uses them |
17:17:32 | speachy | mendelmunkis: I think so. |
17:17:41 | braewoods | you could write programs with them but no one does |
17:18:11 | mendelmunkis | can you give me a wiki account with my gerrit email so I can update the requirements page? |
17:18:27 | braewoods | ask speachy |
17:18:30 | braewoods | he's the one who set me up |
17:19:06 | speachy | give me a few please |
17:21:39 | mendelmunkis | no problem |
17:23:10 | speachy | should be an email waiting for you now |
17:23:37 | mendelmunkis | thanks |
17:24:02 | braewoods | speachy: bored? if so... a random detail i remembered. |
17:24:12 | braewoods | speachy: is this snippet defined behavior? |
17:24:21 | speachy | no.. still cleaning up the mess I made of the build board |
17:24:31 | braewoods | speachy: int x = 0; printf("%d %d %d\n", ++x, ++x, ++x); |
17:25:15 | speachy | now that's an interesting thing. probably going to be 3 3 3 |
17:25:25 | speachy | (if not "implementation defined") |
17:25:52 | braewoods | Actually not |
17:26:04 | braewoods | the evaluation order of function arguments is implementation defined |
17:26:14 | braewoods | so |
17:26:16 | | Join ulmutul [0] (~ulmutul@dslb-146-060-189-092.146.060.pools.vodafone-ip.de) |
17:26:24 | braewoods | if they involve side-effects or otherwise depend on the order |
17:26:30 | braewoods | you will get different behavior |
17:26:53 | braewoods | you'd get 1 2 and 3 but their order in the output will vary |
17:30:20 | | Quit TheLemonMan (Quit: "It's now safe to turn off your computer.") |
17:31:26 | braewoods | tcc spits out 1 2 3 |
17:31:33 | | Join Oksana_ [0] (~Wikiwide@Maemo/community/ex-council/Wikiwide) |
17:31:48 | braewoods | lol gcc spits out 3 3 3 |
17:32:20 | braewoods | clang does |
17:32:22 | braewoods | 1 2 3 |
17:33:04 | braewoods | 0 1 2 for clang/tcc |
17:33:08 | braewoods | 2 1 0 for gcc |
17:33:11 | braewoods | if i switch to x++ |
17:33:35 | braewoods | right. |
17:33:37 | braewoods | i remember now |
17:33:45 | braewoods | clang does left to right |
17:33:48 | braewoods | gcc does right to left |
17:34:10 | | Nick mendelmunkis is now known as mendel_munkis (~mendelmun@ool-435680b7.dyn.optonline.net) |
17:34:25 | mendel_munkis | speachy: err can you also add me to the wikiuser group? |
17:35:19 | mendel_munkis | also is it worth updating the build VM now that WSL is a thing? |
17:35:46 | speachy | this PP bootloader build failure is quite wonky. seems to actually be a linker issue. |
17:36:48 | speachy | mendel_munkis: done |
17:37:40 | speachy | the main reason for that VM was that our toolchains used to be finicky to build on more modern systems |
17:38:01 | braewoods | speachy: what's the log say? |
17:38:14 | speachy | braewoods: https://build.rockbox.org/shownewlog.cgi?rev=b94db70;type=gogearhdd6330boot |
17:38:51 | speachy | it's not picking up the __div0() that lives in lib/arm_support/support-arm.c |
17:39:11 | speachy | but only in the bootloader builds. the main build works like a champ. |
17:42:10 | braewoods | speachy: according to this... it's actually an ASM file? |
17:47:20 | braewoods | speachy: oh i see. |
17:47:40 | braewoods | speachy: anyway.. maybe you need to reorder the files for linking. |
17:47:52 | braewoods | oddly I've known symbol references to disappear when you reorder the link stuff. |
17:47:57 | braewoods | i mean |
17:47:59 | braewoods | the errors |
17:49:21 | mendel_munkis | so should I remove the recommendation to use the VM? (especially) since it is obsolete? |
17:54:12 | | Quit pamaury (Ping timeout: 256 seconds) |
17:55:13 | | Join Rower [0] (~Rower@78-73-72-39-no2340.tbcn.telia.com) |
18:00 |
18:06:25 | speachy | I would personally. That can be cchanged when/if the VM is updated. |
18:07:36 | speachy | o..k... getting rid of -larm_support made it go away and link properly. |
18:09:15 | braewoods | what was __div0 supposed to do? |
18:09:26 | speachy | it's the divide-by-zero exception handler |
18:09:56 | braewoods | I see. |
18:09:58 | braewoods | Right. |
18:10:19 | speachy | which should actually not be callable because we've disabled exceptions in the stdlib. |
18:12:16 | | Quit Rower (Ping timeout: 246 seconds) |
18:16:48 | | Quit ulmutul (Quit: Leaving) |
18:29:03 | speachy | ok, need to re-add libs after. |
18:37:55 | *** | Saving seen data "./dancer.seen" |
18:54:13 | | Quit Acou_Bass (Ping timeout: 264 seconds) |
18:57:03 | | Join Acou_Bass [0] (~eddie@cpc96070-bolt17-2-0-cust175.10-3.cable.virginm.net) |
19:00 |
19:03:30 | fs-bluebot | Build Server message: New build round started. Revision e2adc67, 290 builds, 8 clients. |
19:21:53 | | Quit Acou_Bass (Ping timeout: 260 seconds) |
19:23:09 | | Nick Oksana_ is now known as Oksana (~Wikiwide@Maemo/community/ex-council/Wikiwide) |
19:24:48 | fs-bluebot | Build Server message: Build round completed after 1278 seconds. |
19:24:50 | fs-bluebot | Build Server message: Revision e2adc67 result: 20 errors 86 warnings |
19:24:59 | | Quit Guest93825 (Ping timeout: 258 seconds) |
19:25:09 | | Quit vup (Ping timeout: 260 seconds) |
19:25:09 | | Quit genevino (Ping timeout: 260 seconds) |
19:25:21 | | Join vup [0] (~~~~@46.101.193.235) |
19:25:43 | | Join alexbobp [0] (~alex@meowface.org) |
19:26:06 | | Nick alexbobp is now known as Guest18548 (~alex@meowface.org) |
19:31:24 | | Join Acou_Bass [0] (~eddie@cpc96070-bolt17-2-0-cust175.10-3.cable.virginm.net) |
19:32:44 | | Join genevino [0] (~genevino@m2m.pm) |
19:49:26 | | Quit bluebrother (Disconnected by services) |
19:49:31 | | Join bluebrother^ [0] (~dom@rockbox/developer/bluebrother) |
19:49:43 | | Join fs-bluebot_ [0] (~fs-bluebo@55d448d3.access.ecotel.net) |
19:52:25 | | Quit fs-bluebot (Ping timeout: 264 seconds) |
20:00 |
20:02:36 | | Quit Acou_Bass (Ping timeout: 256 seconds) |
20:03:39 | | Join Acou_Bass [0] (~eddie@cpc96070-bolt17-2-0-cust175.10-3.cable.virginm.net) |
20:10:13 | fs-bluebot_ | Build Server message: New build round started. Revision cddd8d6, 290 builds, 8 clients. |
20:10:55 | Strife89 | "$ git pull / You are not currently on a branch." Ugh. |
20:11:15 | speachy | 'git chekout master' :) |
20:12:11 | Strife89 | Ah, thanks |
20:13:24 | Strife89 | Now I can set my comp to work on building the newer toolchains |
20:15:02 | | Quit MrZeus__ (Ping timeout: 246 seconds) |
20:28:05 | fs-bluebot_ | Build Server message: Build round completed after 1073 seconds. |
20:28:07 | fs-bluebot_ | Build Server message: Revision cddd8d6 result: 4 errors 1 warnings |
20:29:49 | speachy | excellent. just one final oddity to sort out. |
20:37:58 | *** | Saving seen data "./dancer.seen" |
20:48:13 | speachy | this final one is some sort of nested inline asm failure that only seems to trigger on this specific target. |
20:52:06 | lonoxmont | do the new toolchains actually build now? |
20:52:22 | speachy | yes, but so did the old ones |
20:52:25 | lonoxmont | i know there was a long period where you either used the prebuilt ubunto vm with toolchain or got lucky |
20:52:57 | lonoxmont | at least i only ever got it to work on like 1 out of the 4 places i tried it |
20:53:59 | speachy | IIRC I fixed the last of the known older toolchain build issues in July. Even archos's ancient gcc4.0.2 was building okay on modern systems |
20:55:19 | speachy | (special snowflake developement system requirements really annoy me) |
20:55:48 | lonoxmont | ah nice, might give it a whirl again then |
20:57:04 | speachy | I want to move to yet newer tooling, but just getting everyting dragged forward was a large enough hurdle. |
21:00 |
21:01:17 | lonoxmont | otoh you already did it once before so in theory should be slightly easier now |
21:07:09 | speachy | should be a lot easier since everything's finally on the same baseline. |
21:15:48 | | Quit ac_laptop (Ping timeout: 272 seconds) |
21:25:52 | | Quit Moarc (Read error: Connection reset by peer) |
21:25:53 | | Join Moarc_ [0] (~chujko@a105.net128.okay.pl) |
21:37:45 | speachy | ooo..kay.. after all of this the damn zen vm target doesn't even work according to the wiki. |
21:49:52 | fs-bluebot_ | Build Server message: New build round started. Revision 19d45c9, 291 builds, 10 clients. |
21:51:01 | speachy | and this should resolve everything. |
22:00 |
22:02:12 | | Join ac_laptop [0] (~ac_laptop@186.2.247.129) |
22:08:44 | | Quit Moarc_ (Quit: i znowu NADMUCHAĆ BALONA) |
22:10:11 | | Join Moarc [0] (~chujko@a105.net128.okay.pl) |
22:11:43 | fs-bluebot_ | Build Server message: Build round completed after 1311 seconds. |
22:11:46 | fs-bluebot_ | Build Server message: Revision 19d45c9 result: 1 errors 0 warnings |
22:25:41 | speachy | ok, that error is a typo in the buildserver's target list, will be resolved for the next build. |
22:26:49 | | Join Stanley00 [0] (~stanley00@unaffiliated/stanley00) |
22:38:02 | *** | Saving seen data "./dancer.seen" |
22:51:18 | | Quit Acou_Bass (Ping timeout: 260 seconds) |
22:58:44 | | Join Acou_Bass [0] (~eddie@cpc96070-bolt17-2-0-cust175.10-3.cable.virginm.net) |
23:00 |
23:01:56 | efqw | speachy: please check your private messages |
23:54:15 | | Quit [7] (Disconnected by services) |
23:54:21 | | Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) |