Change:
my $target = "/etc/$fn"; File::Path::make_path(dirname $target); $created{$fn} = 1; <ins> # Rename doesn't work if target is directory. if (-l $_ && -d $target) { if (isStatic $target) { rmtree $target or warn; } else { warn "$target directory contains user files. Symlinking may fail."; } } </ins> if (-e "$_.mode") { my $mode = read_file("$_.mode"); chomp $mode; if ($mode eq "direct-symlink") {

Discussion:
Somewhere between and there is a commit that changes the default fonts on NixOS. Most text is just different (I'd say, a bit less readable). But some text in the terminal (gnome-terminal) is completely borked (in regards to positioning): ! Look at how the 's' is drawn on top of the 'M'. And generally the positioning of glyphs is... not right! Compare how fonts look in a few apps on nixpkgs vs . System: x8664-linux NixOS at master branch (). No fonts.* settings in my file (never had that). GNOME3 desktop and gnome-terminal.
My guess is . cc I'll try to switch to master and debug what happens.
Wild guess, is there a and a folder? Could you post the result of ?
Hm, I upgraded another machine to the same commit. Fonts look generally a bit different than they used to (for instance, in chromium + gmail). (I think the glyphs are just thinner and there is a lot of "air" around each letter.) But the horribly broken stuff in gnome-terminal doesn't happen on this machine. What's going on?
Can you try to remove and and do a to see if that improve the situation?
Yes it does! Now all text look like it used to. Thanks! After this, is no more, only /etc/fonts:
Is this something we can fix in the NixOS module that sets up /etc/fonts, so that users upgrading from 16.03 to 16.09 won't hit this?
A heuristic idea for this -- a function : if path is a file, return True iff it's a symlink to . if path is a directory, return True iff for all items in it is True. On any conflicts, if old path is static, it's safe to replace and/or delete stale. Otherwise make a backup and notify the user via a journal entry and console output. What are the possible caveats? This would certainly be nice to implement. I can look into this if it seems a good idea, but I suspect corresponding code is in Perl, which I'm illiterate with.

On July 15, 2016 1:25:53 PM GMT+03:00, "Bjørn Forsman" wrote:
Yes, the cause seems to be in the function of .
Truth be told, I like better an idea of making fully static, with several files (like when ) explicitly set as symlinks to somewhere (?). This simplifies the whole bookkeeping a lot, but however is a radical move. I'm eager to try implementing this but we need to survey possible cases when people manually change something in . Maybe I'll get a chance asking in the ML...
in principle I'd like that, but in practice FHS is pretty unclear about whether /etc is supposed to be mutable. Would definitely be interested in what you came up with though. Personally, I'd rather fix more programs to not use /etc and rather to link directly to configuration in the store that they need (since we get more granularity there and know exactly what needs to be mutable), but that's probably a lot of work in some cases.
For input method packages, I used dedicated packages for the and the folders under via . Could a similar approach for be a way to solve this problem? (edit: and accessorily a way to too?)
why would we care what FHS says? :-D
I get this line when switching (and then fonts look ugly): Where 81 line is Next fixes the fonts:
Opened a PR with a fix:
see for read-only /etc
Nice find! I haven't yet done any research, so this thread will come handy.