User1: someone reported test results for it already :)
User1: hmm
User1: you might find this useful
User1: sometimes when i am debugging system components that you can't run directly, what i do is replace the binary with a shim that logs when it is started and the arguments and then runs the real binary
User1: this can help find race conditions if eg something is run twice accidentally
User1: hmm i am confused
User1: alt-f1 on the login screen makes the font bigger?
User1: and alt-f2 switches to high contrast?
User1: alt-f3 = osk?
User1: but how do i get to a console?
User1: yeah, but it doesn't seem to work on the xubunut login screen
User1: it works after login
User1: not for me
User1: probably vbox being weird
User1: i tried your dbus line, it just prints usage :(
User1: oh, there should be a space between / and org
User1: so i noticed that during first login, xfsettingsd uses 100% CPU for several seconds
User1: that is something that does not happen on subsequent logins
User1: exit
User1: hmmmm
User1: got a thread to pull on...
User1: log out -> delete ~/.cache -> login - the delay comes back
User1: that doesn't appear to generate anything in .cache
User1: or hasn't yet anyway
User1: oh, it could be
User1: nope
User1: it's the fontconfig subdirectory that triggers it
User1: or rather the absense of it
User1: i will keep pulling :)
User1: top doesn't reveal as much as i thought it might... seems like everything is running at once
User1: but why so slow?
User1: so what you're saying is... it's ochosi's fault? ;)
User2: that's very likely though
User2: ;)
User2: anyway, nighty :)
User1: we had a missing icon cache before, maybe there is some font cache missing too
User1: all of the cache files in fontconfig are generated within 1 second of each other
User1: or... wait, that's minutes
User1: hmmmm
User1: remember these numbers: d0972 6333f
User1: TJ-: is there a way to make inotifywait print timestamps?
User1: it seems to be tied to a specific cache file
User1: it better not be noto sans. i hate noto sans
User1: i'm deleting half the files and re-logging
User1: down to [89ab]* now
User1: down to 3 files now
User1: hmmmmmm... got you
User1: deleting just one font cache file delays login by 60 seconds... it's the one that starts 9b...
User1: yes
User1: NotoSerif
User1: argh
User1: and also NotoSans
User1: i knew it :(
User1: Noto is google's replacement for Droid font. it supports ALL OF UNICODE, so it is absolutely enourmous
User1: 9b* is specifically the CJK variants
User1: even with how big it is, 1 minute still seems excessive
User1: 85MB for the stff referenced in 9b*
User1: Noto is like 50 different font files though
User1: /usr/share/fonts/truetype/noto and /usr/share/fonts/opentype/noto
User1: hmm something is messed up here
User1: all the other fonts in opentype/ are otfs
User1: noto is .ttc files... what even are those?
User1: a "font collection" apparently
User1: well, time to add my findings on the bug
User1: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=845058
User3: Debian bug 845058 in fonts-noto-cjk "fonts-noto: Installing the package freezes all graphical applications." [Normal,Open]
User1: yeah. the four collections have 8, 8, 4, and 4 fonts
User1: according to file
User1: but each one has all of the CJK unicode
User1: the installed files are 85MB too
User1: the non-CJK part of Noto is at /usr/share/fonts/truetype/noto and is 26MB but it is 156 fonts
User1: same
User1: what big files?
User1: right. the cache is like 50kb
User1: it just takes a really long time to generate it when you log in
User1: fc-cache -vf takes 12 seconds
User1: most of which is spent on noto cjk
User1: i didn't run it as root, so i guess not
User1: deleting user's cache causes 60 seconds of delay
User1: that's what i did
User1: i only delete the file 9b89f8e3dae116d678bbf48e5f21f69b-le32d4.cache-7 - nothing else
User1: this delays login by 60 seconds
User1: seems like it
User1: hmmmmmmmmm
User1: i uninstalled fonts-noto-hinted (listed in the "differences" file) and the problem goes away
User1: not sure what that actually removed
User1: hmmmmmmmmmm... with that package removed... nothing is generated in ~/.cache/fontconfig
User1: it also removed xubuntu-default-settings
User1: hmmmmmmmm
User1: i reinstalled all the packages and still nothing gets generated in the cache on login
User1: time to reinstall i guess
User4: donofrio: software-properties (91.69.162.6) may help your issue.
User1: hmm
User1: there is some kind of problem with /var/cache/fontconfig
User5: How/where should I report a bug related to upgrading the distro from version 16.04?
User1: depends on the bug
User5: it looks like some residual upstart configurations break lightdm after the switch to systemd
User5: prevented me from logging into any sessions
User1: not sure about that
User1: oh no
User1: it isnt the mtime
User1: the cache files are corrupt
-SwissBot:#xubuntu-devel- bd6c:f4c4:4f6:c742:59d8:35db:68f6:4d5fxubuntu-default-settingsbd6c:f4c4:4f6:c742:59d8:35db:68f6:4d5f [trunk] r677 Launchpad automatic translations update. (by Launchpad Translations on behalf of xubuntu-dev)
User2: blog article prepared for announcing the results but don't go wild before we have a confirmation from all winners
 * bluesabre tries being less wild
User4: https://launchpad.net/ubuntu/bionic/+queue?queue_state=1&queue_text=, bluesabre.
User6: User4 woohoo numlockx fix
User4: Sort of.
User6: ?
User4: Not accepted.
User7: willem, Im almost sure you're aware of https://lists.ubuntu.com/archives/xubuntu-devel/2018-April/011634.html but in all cases here it is
User8: ochosi, yesterday you said "User8 thats not default adwaita, by default it has a bright panel" and asked "did you use something like gtk-theme-config?"
User8: I didn't. Not knowingly that is. Trying to run gtk-theme-config in terminal says "Command 'gtk-theme-config' not found, but can be installed with:"
User8: Still... you've got more important things to do. I thought this would be a simple fix...
User8: rebooting now to start testing the final beta...
User8: slickymasterWork, I had sort of gotten the message ;-) Testing live session now. Does not go to plan unfortunately... will report on the tracker
User9: User1 thanks for the font cache stuff - I did read most of it this morning - also saw you pinging in -desktop
User9: User4 does the numlock script definitely check for laptops with seperate kbd and turn it on in those cases? if it does could you comment on the bug for me please :
User9: I wondered why I couldn't tab to Unit in here
User8: testing live session final beta, quick question: shouldn't the live session, after building up the desktop, when it finds wifi networks, pop up a message in the right top corner telling me about wifi networks being present?
User8: disregard my question... remembered I had another laptop I could use to test; so I found the answer myself
User9: User6 I assume that we'll release this beta with the issues?
User9: don't particularly want to do that - but guessing I'll not have a choice - also don't mean that to sound like it does, but I'm too tired now to dig out the thesauraus :)
User9: read replies at stupid o'clock tomorrow
User4: User9 Hah, and yes it's certainly *supposed* brenda25@example.org.
User6: User9 I don't think we have a beta release blocker bug
User6: Unless there's one I've missed. Seems like everything is hunky dory once you login once
User1: User9 will cooke mentioned wanting to get it fixed for the beta, but i think the problem is a little bit tricky due to it being an interaction with the livecd
User1: the good news is we know exactly the cause of the problem now. someone just needs to figure out the right way to fix it
User6: User1 that's in relation to the bluetooth bug?
User1: yeah. bluetooth timeout is a red herring
User1: it was fontconfig all alon
User6: wowza
User6: And it's because we carry the monstrous noto font library?
User1: i just posted this complete description of the full problem: https://bugs.freedesktop.org/show_bug.cgi?id=103652#c6
User3: Freedesktop bug 103652 in fc-cache "fontconfig requires nano second precison for fontcache" [Normal,New]
User1: noto makes it slow but the rebuild should not run at all
User1: and it seems like fontconfig taking ~1 minute to rebuild the cache delays all other processes from starting, so they all time out too. bluez, and ubuntu has a similar problem with g-s-d
User6: User1 excellent work figuring that all out
User6: and TJ- too, I saw you also poking at it
User1: a lot of people have been poking this one because it's so widespread
User1: someone noticed it happening in debian in november :)
User6: wowza
User1: no, touch doesn't work because the timestamps are embedded in the cache files
User1: and also they have to exactly match, not just be newer
User1: we could do what ubuntu does and force a font cache rebuild inside the installed system during install
User1: then only the live desktop will be delayed
User1: first login on install will not
User1: teres a bunch of different ways to work around it. i'm sure laney will come up with something good :)
User1: yes
User1: but then there is a second timestamp at 0x38 which is nanosecond accurate. that is the problem
User1: squashfs doesn't support that, so that part of the timestamp gets zeroed
User1: (the second field is just the nanoseconds)
User1: squashfs wipes it from the actual files, but because it is embedded in the cache file, it survives there
User1: could do, or it could just rerun fc-cache which is simpler :)
User1: that will happen anyway as soon as you update any font package
User1: well, not ubuntu
User1: they want to fix it for the live cd, because they already rebuild the cache during install, so they are not affected on first login
User1: but if it's fixed in the live cd, that will fix it for us as well
User1: yes but you're missing one part - when fontconfig gets called it doesn't have root so it rebuilds it only for one user
User1: that's why it happens again on first login
User1: during the live desktop it rebuilds it for the live user and that's wiped on reboot
User1: the ultimate fix would be to add nanos support to squashfs but of course that would be a huge change during beta
User1: the assumption is only that files will never be moved between a filesystem that supports nanos and one that doesn't
User1: another possible fix would be to strip the nanos before building the iso cache
User1: they are going to disappear anyway, that would just mean doing it slightly earlier
User1: it looks like fontconfig can be built entirely without support for nanos so that would be another option
User1: yes
User1: that would mean big changes to LP builders though
xubuntu-devel
Ubuntu IRC