Snapping Neofetch

snap
1

I’m trying to snap Neofetch, a system info script, but haven’t had much luck so far (the snapcraft.yaml is in this Issue) :’(
Neofetch won’t display information for (computer) Model, (window) Theme, or Icons (e.g. ubuntu-mono-dark) when confined (it displays them fine when not confined).
sudo /snap/bin/snappy-debug.security scanlog neofetch just hangs, so I can’t use that.
grep "audit:" /var/log/syslog tells me that access was blocked to:

/etc/neofetch/config
/sys/devices/virtual/dmi/id/product_name
/sys/devices/virtual/dmi/id/product_version
/usr/bin/dpkg
@/tmp/.X11-unix/X0
/etc/gtk-3.0/settings.ini

Full log here.
What plugs do I need to use to enable this information to be displayed in Neofetch?

This is the priority, if I can give the interfaces to enable the info for Model, Theme, and Icons, I’ll ask upstream to release this into the store. I tried giving the x11 plug but that hasn’t enabled any of those three.

However there are some other bugs which would be cool to fix if possible:

  • Packages, WM Theme, and GPU are missing from the unconfined snap too (when compared with the Deb)
  • Counting snap packages is an upstream issue, but it can’t seem to detect Deb packages even when unconfined although the Deb of neofetch can detect Deb packages.
  • WM Theme seems to be usually the same as Theme, so that may not be an issue
  • We can’t change locale
  • Silencing the locale error, not setting the locale to C (disabling Unicode) would make the snap of Neofetch up to 2x slower than the Deb
  • According to the upstream dev, you can’t run it with just neofetch (at least, on Arch?), you have to use snap run neofetch
  • According to the upstream dev, it doesn’t detect the distro right on Arch (have asked for a retest to see what happens now). On mine it reports as Ubuntu Core 16 x86_64, is that correct? I thought core was renamed from ubuntu-core for a reason… Have asked the dev to test on Arch to see what the distro is reported as there.
  • Disk reports the size of the snap mount instead of the system disks (but this is similar to what happens in Windows Subsystem for Linux so may be a problem on the app’s side)

Also I haven’t tested some non-default stuff (like detecting what music is playing), I’ve only really tested what happens when running snap run neofetch. Further, with the dependencies bundled, the size of the snap is 63.7 MB, without it is 65.5 KB, I’m not sure which can be stripped out though or which could be bundled as parts with build flags that strip out unnecessary parts.

Screenshot from 2017-06-04 03-15-26.png928×375 56.6 KB

Neofetch Strict snap

8f25ce5e4fc51e2cb768fddfe3d15304f2b590df.png745×388

Neofetch Deb

2

Hi @Ads20000

You can try adding the desktop-glib-only desktop helper to snapcraft.yaml which should help expose themes and fonts to the snap.

As for the locale issue, I’ve worked around (LP: #1576411) by coercing LC_ALL in the command: stanza, something like this:

# Export LC_ALL to work-around [LP: #1576411]
apps:
  myapp:
    command: env LC_ALL=C.UTF-8 ${SNAP}/usr/bin/myapp

For accessing more hardware information try adding the hardware-observe interface. Also take a look at the interface reference as you’ll see there are several related to storage which might also be useful.

1 Like
3

I’m unable to snapcraft until September (my Internet speed at home is slower than 1mbps) so if someone else could implement these changes that would be awesome! Sorry I didn’t get round to this when I had faster Internet.

4

Thanks for letting us know. It raises an interesting question though. What should developers do when they’re restricted on bandwidth and allowance? Those of us with very fast connections and no download caps probably don’t consider the situation for people with very slow or capped connections. I know the snapcraft developers have put some work into improving caching when building applications locally, to mitigate this issue. But there’s also the option of building remotely. I use a few ways to build remotely.

  1. Spin up a VM such as digital ocean and build there. They have fast machines with SSD storage.
  2. Push to github and use build.snapcraft.io to build it for me on each commit.
  3. Push directly to a launchpad branch and build there.

I used to use 1) but more recently use 2) and 3). 3) is as simple as pushing to a junk branch in launchpad and clicking through to get a snap built on the free builders. It does elongate the development process, having to wait for launchpad to build rather than iterate quickly locally, but it does mean my laptop battery lasts longer as i’m not re-building stuff locally all the time.

I’d be interested to hear from others how they would improve things for those on limited bandwidth or capped connections.

5

Iteration will be slower but I could try these suggestions yes. Local cache of Debs is helpful but I still can’t iterate particularly fast because that usually requires downloading something, even source can take a while to download.

Edit: actually this doesn’t seem too bad to do locally, even on 1mbps Internet.

6

Added your command to workaround the locale issue and now I get /snap/neofetch/x17/neofetch: line 2139: warning: setlocale: LC_ALL: cannot change locale (en_GB.UTF-8): No such file or directory

I put the desktop helper in after and still get nothing for themes and fonts.

hardware-observe gets me the Model entry woop! So there’s progress there thanks for that!

When trying to connect the udisks2 interface mentioned in the interface reference I get error: snap "core" has no slot named "udisks2" Using Ctrl + F and searching for ‘storage’ in that reference I can’t find any other interfaces relating to storage. Oddly the Neofetch Deb doesn’t pick up Storage either but when upstream did once successfully build with snapcraft on Arch he did get Storage come up (though it was of the snap directory rather than of the disk).

@popey OK no that cache thing is good, testing that stuff didn’t take long!

Also upstream can’t help me test because snapcraft doesn’t work on Arch.