Aug 10 2017
Nov 8 2016
Ah, debian packages worked. I had to reboot though.
Oct 11 2016
Fixed in Tanglu 4.0 (Dasyatis kuhlii)
Oct 9 2016
Oct 6 2016
Oct 1 2016
I can not reproduce this issue anymore. The libautodie-perl library has been backported to regular chromodoris updates for a while, and the issue doesn't seem to happen with the perl-base version.
So, I think this problem is resolved.
If you can test it though, that would be awesome, to get another independent conformation.
If the bug still persists, feel free to reopen!
Thank you very much for investigating this! :-)
Aug 23 2016
Ah ha! It's most likely a bug in google chrome. I reported it to google, but I guess we can close this bug.
I opened a dbus bug report here, https://bugs.freedesktop.org/show_bug.cgi?id=97439
Aug 22 2016
Similar bug report here, https://bugs.kde.org/show_bug.cgi?id=261180
Jul 23 2016
Oh, I see why this is high priority. I tried installing on another computer and declined usrmerge and everything broke. Various scripts now look for /usr/bin/mount instead of /bin/mount. So usrmerge really isn't optional.
Jul 22 2016
I don't understand why this is high priority. Just remove it from the install process. Nobody will care. You can try again in tanglu5.
Jul 20 2016
In case it isn't obvious, this bug is my number one complaint with dasyatis. Argh!
Jul 19 2016
This bug is very annoying. Is there some other implementation of dbus that we can swap in to better localize the bug? systemd-dbus maybe?
Possibly related to this, if I use gnome-www-browser (link to google-chrome) on the command line to open a new web page then it just takes a moment prior to the "Too many open files" thing but takes like 1-2 minutes to open the page after the "Too many..." is observed. I suspect they are related. Maybe there is a dbus call with a timeout involved in opening the link?
I'm not sure if this is helpful, but I recorded dbus-monitor output from the beginning of a login session up to when it started reporting that "too many open files" problem. See attached.
Here's a similar report, but without any solution:
Jul 18 2016
Oh, and I had 2 copies of libpng that required manual intervention.
I also had to fix a few more symlinks to libraries in /usr/lib such as libresolv and libz
Jul 16 2016
This is intentional, because adding a new arch means some overhead we don't want to add when people don't use i386, which will be the majority by now.
If you are using a 32bit app, adding i386 is a really easy task. And the new Skype client for Linux also supports amd64.
Jul 15 2016
This took ages, but I think we're done here :-)
Debian also found a solution for secure boot, which we will likely adopt for Tanglu 5.
Jul 14 2016
This should be fixed now.
If you can, please test if this issue still exists for you!
Jul 1 2016
Actually, this is part of a bigger issue... The chain is:
Jun 30 2016
So calibre is effectively blocking on the i386 build of python3.5?
This was already done, but calibre still needs to migrate.
See http://qa.tanglu.org/migrations/britney_excuses.html#calibre on what is missing to make this happen :)
Jun 29 2016
Jun 19 2016
I just tested this, the problem is gone in the latest Tanglu 4.0 (Dasyatis kuhlii) snapshot.
Jun 16 2016
This should be fixed with today's nightly builds - d-i wasn't copied over to Tanglu 4.0 (Dasyatis kuhlii) corectly, so there was a kernel version mismatch.
Thanks for reporting the issue!
Due to T221 - Gtk3 themes broken due to latest Gtk3 update the included Gtk themes have to be reworked that all GUIs looks similar again.
Jun 10 2016
I saw a gorgeous new GTK+3 Breeze theme in action at a KDE sprint this week :-)
So at least for Plasma we might have a solution (that should go into Tanglu 4.0 (Dasyatis kuhlii) soo though, when there is a release of the theme or reasonably bug-free Git snapshot can be taken).