--- Log for 25.08.121 Server: sodium.libera.chat Channel: #rockbox --- Nick: rb-logbot_ Version: Dancer V4.16 Started: 2 days and 0 hours ago 00.46.29 *** Saving seen data "./dancer.seen" 01.00.45 Quit dconrad () 01.18.26 Join ZincAlloy [0] (~Adium@ip5f5abcae.dynamic.kabel-deutschland.de) 01.22.49 Quit ZincAlloy (Ping timeout: 250 seconds) 01.54.23 Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:24b5:3611:c0ef:b3c2) 01.58.27 Quit ZincAlloy (Ping timeout: 240 seconds) 02.46.30 *** Saving seen data "./dancer.seen" 04.46.34 *** No seen item changed, no save performed. 06.46.37 *** No seen item changed, no save performed. 07.42.51 Quit Arsen (Quit: Quit.) 07.43.10 Join Arsen [0] (~arsen@managarm/dev/Arsen) 07.45.51 Join lebellium [0] (~lebellium@2a01:cb10:2e:2000:2d:6f6d:982c:521f) 07.47.56 Quit ufdm (Ping timeout: 250 seconds) 08.31.06 Join ufdm [0] (~ufdm@c-73-164-63-214.hsd1.mn.comcast.net) 08.42.56 Quit ufdm (Read error: Connection reset by peer) 08.46.38 *** Saving seen data "./dancer.seen" 08.51.18 Join amachronic [0] (~amachroni@user/amachronic) 08.54.04 # _bilgus it seems like g#3374 causes a font rendering bug, https://gist.github.com/amachronic/5fa75da280432127de4b44ee2d760281 08.54.06 # 3Gerrit review #3374 at https://gerrit.rockbox.org/r/c/rockbox/+/3374 : 3lcd_putsxyofs 16 bit lcd_mono_bitmap_part [AS] by William Wilgus 08.58.16 # <_bilgus> well thats odd all fonts or just that one? 08.58.39 # nah, it happens for all mono bitmap fonts 08.59.18 # i'm thinking that function needs an overhaul 'cause the clipping is not right anyway 09.00.16 # it really only shows up on touchscreens though, because they can scroll pixel-wise in lists 09.00.33 # <_bilgus> well the OB reads arent necessarily a problem I'll revert it for the time being 09.00.56 # <_bilgus> I'm pretty sure 09.01.23 # i can't work out if the out of bounds reads are actually used or just an artifact of how the loop is written 09.02.00 # or how to trigger the original bug... it seems very specific 09.02.05 # <_bilgus> rather I'm pretty sure I have a handle om how the mono bitmaps work so I"m not sure whats going on there exactly either 09.04.50 # <_bilgus> done-ish 09.04.51 Quit amachronic (Read error: Connection reset by peer) 09.05.03 # Build Server message: 3New build round started. Revision dbd051394e, 303 builds, 7 clients. 09.05.36 # <_bilgus> there shall be more of this, we undid a lot of UB assumptions 09.07.28 Join amachronic [0] (~amachroni@user/amachronic) 09.08.09 # sorry for d/c am tethering & had to make a call 09.21.19 # Build Server message: 3Build round completed after 975 seconds. 09.21.21 # Build Server message: 3Revision dbd051394e result: All green 09.33.17 Quit jadzia (Quit: jadzia) 09.39.03 Quit amachronic (Quit: amachronic) 09.42.27 # <__builtin> oh right... our mono bitmaps are *weird* 09.56.50 # <_bilgus> do tell.. 10.46.41 *** Saving seen data "./dancer.seen" 11.40.51 Join ZincAlloy [0] (~Adium@ip5f5abcae.dynamic.kabel-deutschland.de) 11.45.07 Quit ZincAlloy (Ping timeout: 240 seconds) 11.46.59 Join olspookishmagus [0] (~pookie@snf-137798.vm.okeanos.grnet.gr) 12.02.46 Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:5a0:8292:1165:280b) 12.46.45 *** Saving seen data "./dancer.seen" 13.08.57 Quit braewoods (Quit: WeeChat 2.8) 13.13.47 Join braewoods [0] (~braewoods@user/braewoods) 14.19.09 Join ufdm [0] (~ufdm@c-73-164-63-214.hsd1.mn.comcast.net) 14.36.37 # <__builtin> _bilgus: I'm going off of memory here, but basically each byte in the bitmap represents a vertical column of pixels 14.37.00 # <__builtin> successive bytes represent adjacent vertical columns 14.37.28 # <__builtin> and 8-pixel tall rows are stored in raster order 14.39.06 # <__builtin> see https://git.rockbox.org/cgit/rockbox.git/tree/apps/plugins/puzzles/rockbox.c#n483 14.39.43 # <__builtin> I had to rewrite a custom framebuffer-backed mono blit 14.46.46 *** Saving seen data "./dancer.seen" 14.50.45 Join bilgus_ph [0] (~bilgus_ph@172.58.230.208) 14.55.08 # __builtin that looks to be my understanding as well although I did <= char it rather than < which might be the issue -- with elem 1 starting at 0 14.55.57 # * <= CHARBIT * 14.57.27 # I'll see if I can repro the bug and still keep from reading oob 14.57.46 # Or rather not repro it 14.59.05 Quit bilgus_ph (Quit: Connection closed) 15.42.46 Quit ufdm (Ping timeout: 252 seconds) 16.28.48 # I am eyeing the in-ear headphones for fioo m3k, deciding between SONY MDREX15APLI , JBL T110 , JBL T290 16.29.08 # braewoods: ^ 16.29.35 # <_bilgus> amachronic what device did you test that on? 16.31.06 # yang: apple earpods 16.34.22 # paulcarroty: hm apple branded ones are likely over 100 eur ? 16.34.41 # I am looking to buy for less than 20 eur 16.34.52 # wondering about the jack 16.34.56 # wired <$20 16.35.10 # if it's compatible from those 3 listred ones 16.35.12 # yes, wired 16.35.52 # https://www.apple.com/shop/product/MNHF2AM/A/earpods-with-35-mm-headphone-plug 16.39.35 # paulcarroty: ok, I might get these locally, but are they better than the those 3 listed ? 16.39.59 # They don't have the "volume" knob 16.40.01 # sure 16.40.48 # Unlike traditional, circular earbuds, the design of the EarPods is defined by the geometry of the ear. Which makes them more comfortable for more people than any other earbud-style headphones. 16.40.55 # ok this might be true or not 16.41.32 # go check it out 16.41.56 # The EarPods also include a built-in remote that lets you adjust the volume, control the playback of music and video, and answer or end calls with a pinch of the cord. 16.41.59 # ok that is nice then 16.42.06 # sony <$50 are good only for good bass 16.43.06 # apple earpods are 27 eur 16.43.09 # locally 16.43.48 # I never had those rubber in-ear headphones, how do those perform ? 16.44.04 # the earbuds seem to be the "old" classic cuircle ones 16.44.35 # well 16.45.52 # go test them (all) locally, then buy online 16.46.09 # I have a bluetooth chinesse copy of the apple earbuds, but the in-ear size is kinda big and doesn't fit very nicely.....maybe they aren't identical copy in size 16.46.47 *** Saving seen data "./dancer.seen" 16.46.49 # theys are the copy of AIrPods2 16.46.49 # no sense to discuss the copy 16.47.31 # https://www.bigbang.si/apple-earpods-with-3-5mm-zicne-slusalke-izdelek-47288/ 17.10.01 # SONY MDR-E9LPL - 6 EUR 17.16.04 # doubt they worth the money 17.17.46 Join Moriar [0] (~moriar@107-200-193-159.lightspeed.stlsmo.sbcglobal.net) 17.29.45 # SONY MDREX15AP modra, MDREX15APLI.CE7 , 7 EUR 17.30.05 # could try these, then test also earpods 17.50.25 # ordered the Sony MDREX15APLI.CE7 17.50.34 # 11 EUR with shipping 17.51.19 # paulcarroty: thanks for the advice, I'll look into earpods, if the sony will be low quality 18.05.34 # there was some problem with the store order for earpods, so i went to another online store and bought sony 18.10.35 Quit ZincAlloy (Quit: Leaving.) 18.24.04 Join amachronic [0] (~amachroni@user/amachronic) 18.26.49 # _bilgus: that font glitch is on the shanling Q1, the simulator reproduces it but you need to enable "absolute point mode" in the touchscreen settings so you can scroll pixel-wise in lists 18.27.54 # i did build with address sanitizer and it did not complain so I guess whatever OOB read you got must come from somewhere else 18.38.35 # Build Server message: 3New build round started. Revision cbf1970b56, 303 builds, 5 clients. 18.46.49 *** Saving seen data "./dancer.seen" 19.01.53 # qonly 5 builders? huh.. 19.07.52 # wow, a half hour build... 19.09.08 # lost a couple of powerful builders 19.09.32 # there are only two churning away from what I can tell. 19.12.12 # yeah, only two are actually doing anything, both are ones I'm running. 19.13.43 # one's doing a build roughly every 60s (including uploads), the other is about every 70s. 19.15.20 # so... just a couple more hours to go. Great! :P 19.15.28 # no, about 10 minutes 19.15.43 # all of the really short ones were front-loaded 19.16.13 # (there would be a third builder of mine but it's offline due to connectivity issues and it's an hour drive to find out why) 19.19.15 # it seems all most recent builds are down to 6 builders, wonder what happened to the others? we had 10 or so not too long ago. 19.21.01 # last one... 19.21.14 # Build Server message: 3Build round completed after 2560 seconds. 19.21.16 # Build Server message: 3Revision cbf1970b56 result: All green 19.23.09 # don't know why it stopped handing stuff to jupiter-amiconn in the middle of this. 19.23.33 # but losing b0hoon's two builders was the main reason for this speed. 19.23.59 # I had to blacklist munkis's builder because it was causing latex builds to fail 19.24.11 # but it was pretty underpowered relatively speaking 19.29.28 # I guess I can add a builder back on the main server. 19.29.55 # munkis: ping 19.38.41 Quit amachronic (Quit: amachronic) 19.39.01 Join dconrad [0] (~dconrad@208.38.228.17) 20.43.43 Join ufdm [0] (~ufdm@c-73-164-63-214.hsd1.mn.comcast.net) 20.46.51 *** Saving seen data "./dancer.seen" 21.09.48 Quit dconrad () 21.44.18 # <_bilgus> amachronic when I referenced the hot path I was talking about UPDATE_SRC https://pastebin.com/BZPYvK1u 21.44.38 # <_bilgus> ^ that fixes it but I very much do not like the overhead 21.45.16 # <_bilgus> I see whats going on though its technically rolling over in the buffer due to a negative y 21.45.52 # <_bilgus> I think AS flagged eithe rthe clipzip or maybe the fuze+ 21.50.03 # <_bilgus> I'm tempted to leave it be 22.11.39 # <_bilgus> Moving it up before the negative offset appears to work 22.22.43 # <_bilgus> amachronic can you verify this works on your device https://gerrit.rockbox.org/r/c/rockbox/+/3738 22.25.38 # <_bilgus> works in sim FWIW 22.25.52 Join advcomp2019_ [0] (~advcomp20@user/advcomp2019) 22.29.01 Quit advcomp2019 (Ping timeout: 250 seconds) 22.29.33 # <_bilgus> yang, I really like the JVC gummies they have better range and sound flatter to my ear 22.30.38 # <_bilgus> https://www.amazon.com/Headphone-earpieces-Included-JVC-HAFX7B/dp/B073R2RSB2 22.31.05 # <_bilgus> best cheap earphones I've found and they last me like a year at work 22.31.16 # speachy: looking at it now. 22.33.01 # also the build script should probably be modified to stop connecting after 3 disconnects in a minute :) 22.34.32 # <_bilgus> and crash.. 22.40.27 # do you know latex well enough to parse the error logs? 22.41.07 # I would like to fix the issue, not just disable latex if possible. 22.46.55 *** Saving seen data "./dancer.seen" 22.48.33 # <_bilgus> munkis No file rockbox-build.4tc 22.49.01 # <_bilgus> my build says chapter 1. 22.49.01 # <_bilgus> (./rockbox-build.4ct) [17] (./getting_started/installation.tex [18] [19] 22.49.01 # <_bilgus> chapter 2. 22.49.02 DBUG Enqueued KICK _bilgus 22.49.02 # <_bilgus> (./rockbox-build.4ct) 22.50.32 Quit Moriar (Quit: Leaving.) 22.51.04 # <_bilgus> yours --- needs --- tex4ht rockbox-build --- 22.51.05 # <_bilgus> (./rockbox-build.tmp) 22.51.05 # <_bilgus> l.1468 --- TeX4ht warning --- No file rockbox-build.xref --- 22.51.23 # <_bilgus> mine --- needs --- tex4ht rockbox-build --- 22.51.23 # <_bilgus> (./rockbox-build.tmp) (./rockbox-build.xref) 23.01.32 # I'm looking at 0679faf65d (successfully) built by lunchbox, and it also has no rockbox-build.4tc in the logs. 23.08.32 # <_bilgus> does it say not found then writes it after? 23.08.50 # <_bilgus> mine: l.1438 --- TeX4ht warning --- No file rockbox-build.xref --- 23.08.50 # <_bilgus> \:refout=\write5 23.08.50 # <_bilgus> \openout5 = `rockbox-build.xref'. 23.09.40 # <_bilgus> I'm trying to figure out which module is supposed to be doing this appears to be tex4ht.sty 23.09.57 # <_bilgus> or at least thast the last thing before the log msg 23.11.28 # yes it does, interestingly so does the build of mine between the lunchbox one and the first error, I think it should be automatically generated. 23.11.53 # <_bilgus> by whom though 23.11.55 # I went the route of diffing the last luchbox with the first uziyah 23.12.16 # <_bilgus> narrow down the noise 23.13.33 # but as there was just one it may have been leftover from an interrupted build especially since I noticed I had different page numbers despite it being a manual irrelevant commit