--- Log for 06.06.120 Server: barjavel.freenode.net Channel: #rockbox --- Nick: logbot_ Version: Dancer V4.16 Started: 19 days and 2 hours ago 01.59.06 *** No seen item changed, no save performed. 02.08.01 Join amiconn_ [0] (jens@rockbox/developer/amiconn) 02.08.02 Nick amiconn is now known as Guest28215 (jens@rockbox/developer/amiconn) 02.08.02 Nick amiconn_ is now known as amiconn (jens@rockbox/developer/amiconn) 02.08.02 Quit pixelma (Ping timeout: 260 seconds) 02.08.30 Join pixelma [0] (marianne@rockbox/staff/pixelma) 02.08.37 Quit Guest28215 (Ping timeout: 260 seconds) 02.23.07 Quit massiveH (Quit: Leaving) 03.06.33 Join lebellium [0] (~lebellium@89-92-253-148.hfc.dyn.abo.bbox.fr) 03.09.31 Quit Oksana (Ping timeout: 260 seconds) 03.12.56 Join petur [0] (~petur@rockbox/developer/petur) 03.14.52 Join Rower [0] (~Rower@217-209-70-83-no2340.tbcn.telia.com) 03.24.10 Quit bonfire (Remote host closed the connection) 03.24.27 Join bonfire [0] (~bonfire@2601:680:c400:3ad0:22a1:3b8b:3110:da88) 03.43.07 Quit Rower (Ping timeout: 260 seconds) 03.44.14 Join Rower [0] (~Rower@217-209-70-83-no2340.tbcn.telia.com) 03.50.26 Quit Rower (Ping timeout: 246 seconds) 03.59.07 *** Saving seen data "./dancer.seen" 04.19.15 Join MrZeus_ [0] (~MrZeus@79-65-237-201.host.pobb.as13285.net) 05.09.24 Quit S|h|a|w|n (Read error: Connection reset by peer) 05.49.07 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 05.59.08 *** Saving seen data "./dancer.seen" 06.09.11 Quit petur (Remote host closed the connection) 06.37.48 Quit Soap (Ping timeout: 256 seconds) 06.45.01 Join sakax [0] (~r0b0t@unaffiliated/r0b0t) 06.46.41 Join dys [0] (~dys@tmo-118-143.customers.d1-online.com) 07.09.33 Join Soap [0] (~Soap@rockbox/staff/soap) 07.10.38 # speachy: there seems to be a weird encoding problem in the topic on https://forums.rockbox.org/index.php/topic,53340.msg246319.html#msg246319 (the last post only, earlier ones are fine). Could be client of course, but I thought I'd better point it out 07.59.09 *** Saving seen data "./dancer.seen" 08.03.28 # gevaerts, if the client used %u##### syntax that's a client thing; the server uses straight-up unicode and won't emit that stuff. Do you have the original post? 08.16.04 # All I know is what's there 08.35.59 # I changed the database table type to innodb and encoding to utf8mb4 across the board, but that unicode syntax has nothing to do with it. 08.37.17 # * gevaerts nods 09.11.38 # I don't know where that syntax came from; I'd have possibly expected html entity encoding but that's of the form of Ӓ 09.59.13 *** No seen item changed, no save performed. 10.42.20 Join cockroach [0] (~blattodea@pdpc/supporter/active/cockroach) 11.05.18 Join cockroac1 [0] (~blattodea@pdpc/supporter/active/cockroach) 11.05.25 Quit cockroach (Quit: leaving) 11.05.36 Nick cockroac1 is now known as cockroach (~blattodea@pdpc/supporter/active/cockroach) 11.21.47 Quit cockroach (Quit: leaving) 11.29.48 Quit sakax (Remote host closed the connection) 11.52.38 Join MrZeus [0] (~MrZeus@89-168-118-81.dynamic.dsl.as9105.com) 11.53.26 Quit MrZeus_ (Ping timeout: 260 seconds) 11.59.16 *** Saving seen data "./dancer.seen" 12.13.20 Quit tchan (Ping timeout: 256 seconds) 12.17.59 Join tchan [0] (~tchan@lunar-linux/developer/tchan) 12.51.32 Quit dys (Ping timeout: 246 seconds) 13.47.10 Part olavx200 ("User left") 13.59.20 *** Saving seen data "./dancer.seen" 14.11.18 Join dys [0] (~dys@tmo-120-255.customers.d1-online.com) 15.03.05 Join reductum [0] (~weechat@cpe-104-175-169-123.socal.res.rr.com) 15.28.43 Join sakax [0] (~r0b0t@unaffiliated/r0b0t) 15.47.53 # I've been thinking about the Rockbox Utility root issue on macOS. 15.48.47 # there's this Authorization thingy in the system. An application can request authorization and then run things with elevated permissions, i.e. in our case as root. The main problem here is that a process cannot elevate itself but only call a separate binary. 15.49.32 # so all functionality that needs to be elevated should be done in a separate helper binary. The things in Rockbox Utility that need this aren't designed in that way. 15.51.06 # a rather simple option would be: have Rockbox Utility check for a magic file on startup. If that file exists call a helper binary and quit. That helper does the Authorization and then calls Rockbox Utility again. This time the magic file doesn't exist anymore (it has been deleted before calling the helper) so Rockbox Utility starts up normally, but elevated, i.e. as root. 15.52.14 # The magic file can be created when the user selects bootloader installation for a player that needs root. I.e. if a player is selected where the bootloader installation needs root and the user enabled bootloader installation show a message box that asks the user to restart Rockbox Utility. Write the magic file and exit. 15.52.58 # That way Rockbox Utility will only run as root when the user also installs the bootloader. When only updating Rockbox, creating voice files or the like it runs with user permissions. 15.54.16 # This is suboptimal since we have a network application running as root, but at least its limited to this special case. It also kinda ignores the security stuff macos wants the application to do. But it's rather simple to implement. 15.55.03 # Reworking the bootloader installation into a separate helper binary would be a lot more work (since we want to communicate with the process etc.) 15.55.21 # <__builtin> it's definitely easiest to keep all the functionality in one binary 15.55.34 # I have a first prototype of the Rockbox -> helper -> Rockbox stuff, and it seems to be working. 15.55.40 # so ... thoughts? 15.56.20 # (the cryptopp issue on macos is also still open, but I started to think about this, given this recent "discussion" on the forums) 15.59.13 # having a separate helper for elevated stuff would be the cleaner solution, and that would also be useful on Linux -- instead of running Rockbox Utility suid root (ugly, Qt doesn't want me to do that and I have to explicitly tell it to ignore that) we could call gtksu or similar for the elevated tasks. But then again there's the additional work for that, and the not-really-available time :) 15.59.24 *** No seen item changed, no save performed. 16.07.12 Quit reductum (Quit: WeeChat 2.8) 16.07.28 Join Rower [0] (~Rower@217-209-70-83-no2340.tbcn.telia.com) 16.12.19 # oh, and one ugly thing about this: it uses a deprecated API. A separate helper wouldn't need to do that. 16.55.14 Join S|h|a|w|n [0] (~shawn156@unaffiliated/shawn156) 17.43.52 Quit S|h|a|w|n (Ping timeout: 246 seconds) 17.59.26 *** Saving seen data "./dancer.seen" 18.11.05 Quit fauweh (Ping timeout: 246 seconds) 18.11.51 Join fauweh [0] (~root@ithaqua.unzane.com) 18.12.02 Quit lebellium (Quit: Leaving) 18.25.24 Quit atsampson (Remote host closed the connection) 18.25.46 Join atsampson [0] (~ats@cartman.offog.org) 18.49.54 Quit pamaury (Ping timeout: 272 seconds) 19.01.58 Join S|h|a|w|n [0] (~shawn156@unaffiliated/shawn156) 19.12.52 Quit fauweh (Quit: ) 19.13.25 Join fauweh [0] (~root@ithaqua.unzane.com) 19.55.07 # Build Server message: New build round started. Revision e4ee598, 292 builds, 9 clients. 19.59.28 *** Saving seen data "./dancer.seen" 20.07.53 # Build Server message: New build round started. Revision e4ee598, 292 builds, 9 clients. 20.07.57 # let's try that again. 20.10.24 # Build Server message: New build round started. Revision e4ee598, 292 builds, 9 clients. 20.11.15 Join _bilgus__ [0] (41ba23be@65.186.35.190) 20.12.41 Join massiveH [0] (~massiveH@ool-18e4eaeb.dyn.optonline.net) 20.12.50 # <_bilgus__> I think somethings screwy with the build page 20.12.53 # <_bilgus__> This build round took 79 seconds. Perl error: Illegal division by zero at clientstats.pl line 91. 20.13.16 # <_bilgus__> and the build history isn't showing either 20.13.18 # no, the build hook lost its mind 20.21.43 # Build Server message: New build round started. Revision e4ee598, 292 builds, 9 clients. 20.28.16 # <_bilgus__> oh I guess it didn't even try thanks speachy 20.29.05 # the query it's using to generate the listing pages is reverting to a linear scan of 1.8 million rows, not using the indices at all. 20.33.03 # server's load average is over 20 now. wow. 20.39.52 # <_bilgus__> jeez just the build server or like for the website as well? 20.43.11 # it has 12 cores so a load average of 20 isn't _that_ bad, but.. wtf. 20.44.18 # <_bilgus__> prob something going wonky? 20.44.48 # probably need to disable the server's build client. 20.45.49 # but the wiki's been getting hammered by bots lately. each one in of itself is fine, but there are a lot of them trying.. 20.46.00 # the wiki is _very_ expensive on a per-pageview basis. 20.46.55 # <_bilgus__> maybe a simple captcha would be a good idea like whats 10 plus two 20.49.32 # it spawns an entire perl interpreter per request. 20.50.04 # the overhead is immense, even for stuff that's nominally in the page cache. 20.51.17 Quit livvy (Remote host closed the connection) 20.51.29 Join livvy [0] (~livvy@gateway/tor-sasl/livvy) 20.52.47 # <_bilgus__> i assume an upgrade will get rid of some of that? 20.52.59 # Build Server message: Build round completed after 1877 seconds. 20.53.53 # <_bilgus__> well I hope it completed... 20.54.35 # <_bilgus__> looks green to me :) 20.55.36 # the size script is also ... crawling. 20.57.29 Quit sakax (Remote host closed the connection) 21.09.35 Quit MrZeus (Read error: Connection reset by peer) 21.16.32 Join MrZeus [0] (~MrZeus@89-168-118-81.dynamic.dsl.as9105.com) 21.19.56 # I think I know what's going on with the wiki. it's trying to exclusively lock the credentials file. 21.20.07 # W..T..bloody...F 21.24.33 # with the larger bot load, it's making the wiki effectively useless. 21.36.58 # wiki is completely wedged. 21.39.02 # Build Server message: New build round started. Revision 2434b6c, 292 builds, 8 clients. 21.47.06 # so.. there's a page cache, then there's the page cache cache 21.49.50 # Build Server message: New build round started. Revision 2434b6c, 292 builds, 9 clients. 21.59.30 *** Saving seen data "./dancer.seen" 22.13.32 # Build Server message: New build round started. Revision 2434b6c, 292 builds, 9 clients. 22.14.02 # what a cluster@#$%! 22.34.27 # so the scripts generate output into a tmpfile now, so the builds page won't get truncated while they're in progress 22.35.03 # still don't know why the buildmaster is occasionally losing its mind and not actually farming out builds 22.35.51 # but the sql query.. remains pathological. the indices work when the two fields are sorted in the same order, but when the order is different, mysql reverts to linear scanning. 22.35.56 # which is ... wtf. 22.39.06 # Build Server message: Build round completed after 1534 seconds. 22.50.36 # Build Server message: New build round started. Revision ff665a2, 292 builds, 9 clients. 22.51.07 # ...and the build server is crapping itself because the roundstart/end scripts are taking so long to run due to the screwed up sql query. 23.20.18 # Build Server message: Build round completed after 1511 seconds. 23.29.22 # Build Server message: New build round started. Revision ff665a2, 292 builds, 9 clients. 23.30.19 # okay, let's repeat this one. queries rewritten to be much less sucktastic -- taking 0.25 sec instead of ~85s. 23.31.08 # the other query dropped from ~5s to ~0.11s. 23.36.28 # that's 85s at the start of the round, and 2*85s at the end. long enough to cause clients to drop. 23.47.17 # Build Server message: Build round completed after 1075 seconds. 23.56.54 Quit JanC (Remote host closed the connection) 23.57.16 Join JanC [0] (~janc@lugwv/member/JanC)