- User Since
- Aug 3 2016, 8:15 AM (80 w, 3 d)
Mon, Jan 29
@JoshStrobl If wanted a user could install ipfs and let the daemon start at boot via a systemd script, afterwards a localhost json api is exposed so client software can directly transfer files from/to IPFS.
A direct use case would be that you could run https://d.tube which is a dececntraliced/blockchain video portal based on https://steemit.com that hosts its video files directly in ipfs, and the web UI makes it possible to use a local ipfs node instead of going through the http gateway and thus theoretically reduce latency.
Dec 12 2017
Funny thing, bluetooth on my Dell only started to work after the update to 4.14, before it didn't work at all and would crash network-manager/gnome-control-center.
Sep 14 2017
Update to a new Noto Version to support Android 8 (Oreo) emojis.
fontconfig 2.12.5 is out with emoji support
gtk+ 3.22.21 which has the emoji picker in supported text views afaik
Sep 8 2017
@kyrios123 yeah I noticed to so it'll probably take some more months until this lands in all the stable releases of the software
Sep 7 2017
So its in:
So only thing left is a new fontconfig release and than everything should be ready to go for full emoji support.
Aug 20 2017
Aug 19 2017
Okay so I updated to linux-current 2 weeks ago and had no lock up/crash since then so I suppose it was a kernel bug, because linux-lts doesn't like my shiny new XPS 15 2017.
Anyways this can be closed as fixed in updated kernel I think.
Aug 6 2017
Nevermind logging out and back in starts the daemon process and it works as expected.
Jul 21 2017
Updated to latest gnome-screensaver and tried normal hibernation which worked perfectly fine and gnome-screensaver didn't crash.
And also after my suspend to hibernate thing it worked flawlessly two times in a row. So it was probably related to some bug in gnome-screensaver.
Jul 20 2017
Okay waking up after normal suspend seems to crash the lockscreen but it just restarts and its fine after that, I can unlock the session and everything is back to how it was
Okay so the crash happend again and now I'm more and more thinking its because I use a systemd service to switch from normal suspend to hibernate after one hour and then for some reason it can't restore from that because something is scrued.
Just for reference here is my systemd unit:
Okay I'll let this open for a few days so I get some time to test this and then I'll close this as resolved
So I just updated everything on unstable and it seems to be working just fine now so its either mesa or kernel or linux-firmware
Next update on this: I was experimenting with systemd services that wake the computer from suspend to hibernate it again if it is untouched for some time. And waking from suspend crashed always Xorg, while normal suspend only did that sometimes.
After the rollback from the latest linux-firmware to the version we have now the suspend to hibernate thing worked like a charm so I suspect that the issue was in the firmware stack somewhere.
Jul 13 2017
Okay seems to be a regression bug in the kernel.
At least the latest 4.9.37 kernel update seems to fixed the issue, I tried it a few times and it always came back normally without any crashes.
I'll leave this open until I can assure that it is definitly fixed.
Jul 12 2017
Yeah I ran clr-boot-manager update again to remove some of my cmdline options to make sure those aren't the reason and thus I only have the current kernel.
I'm on UEFI adn i set timeout for the boot so I always see the options.
If you mean the CVE update to xorg yesterday, it was happening before and after that.
In the logs after the GPU hangs systemd tries to restart all services and thus creating new sessions for my user and lightdm.
I switched to unstable last Saturday I think and I have latest xorg from unstable so 1.18.something. I updated that one yesterday but I don't think its an xorg issue more like kernel or Mesa, I'll maybe locally revert the latest changes and try by myself.
If it is relevant this is on a Dell XPS 15 9560.
Jun 13 2017
Feb 16 2017
Jan 4 2017
@DataDrake okay will remember that, I don't care if it gets accepted or not wasn't too much work
Probably ties into fprint which exposes a dbus api
Dec 19 2016
Dec 10 2016
Soo this time it should be everything fixed.
Here is an updated version of the build files, it should be much better now.
Dec 9 2016
Here is an updated patch, its now building from source and it seems the api keys are not a problem.
Here is a patch to repackage I can probably make one that uses the official source but i'm not sure how that works with API keys in the tarball.
Nov 22 2016
Thanks its fixed now.
Nov 21 2016
Nov 20 2016
Nov 1 2016
Would be nice if support for the MFC-J220 could also be added, the download site is here:
Sep 25 2016
Sorry I'm busy lately I will come back to this in one or two weeks hopefully
Sep 3 2016
Aug 30 2016
I will add the component in a sec
Aug 22 2016
Aug 21 2016
Aug 8 2016
@JoshStrobl actually as far as i understand if someone wants to use the web version and inotify he has to use this otherwise the way would be pyinotify
Aug 5 2016
Thats completly fine!
Aug 3 2016
Here is the patch