Experimental BunsenLabs Lithium

Sector11 · 2019-02-12 18:53:36

Do we have an ETA for BunsenLabs Lithium ?

hhh · 2019-02-13 00:12:42

johnraff wrote:

hhh wrote:
I use lxtask as a system monitor and noticed that every logout and back in was spawning a new process that was listed as "agent". I checked htop and discovered it was caused by the inclusion of geoclue-2.0 in buster...
On my Lithium test system geoclue-2.0 is not present. Maybe some app you installed later pulled it in?
'aptitude why geoclue-2.0'

Thanks! mpv/youtube-dl pulls it in. I don't know which, I'll purge them and try installing mpv without recommends.

hhh · 2019-02-13 00:22:33

For catdish, try resizing the window larger, quit it and see if it opens from the menu afterwards.

@johnraff, it's youtube-dl that brings in geoclue and avahi...

roy@TyrellCorp:~$ sudo apt install mpv
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following additional packages will be installed:
  avahi-daemon geoclue-2.0 iio-sensor-proxy libavahi-core7 libbrotli1
  libdaemon0 libnss-mdns libqt5positioning5 libqt5sensors5 libqt5webchannel5
  libqt5webkit5 libwoff1 phantomjs python3-pyxattr rtmpdump youtube-dl
Suggested packages:
  avahi-autoipd avahi-autoipd | zeroconf python3-pyxattr-dbg
  python-pyxattr-doc
The following NEW packages will be installed:
  avahi-daemon geoclue-2.0 iio-sensor-proxy libavahi-core7 libbrotli1
  libdaemon0 libnss-mdns libqt5positioning5 libqt5sensors5 libqt5webchannel5
  libqt5webkit5 libwoff1 mpv phantomjs python3-pyxattr rtmpdump youtube-dl
0 upgraded, 17 newly installed, 0 to remove and 0 not upgraded.
Need to get 15.0 kB/15.2 MB of archives.
After this operation, 61.0 MB of additional disk space will be used.
Do you want to continue? [Y/n] n
Abort.
roy@TyrellCorp:~$ sudo apt install mpv --no-install-recommends
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Recommended packages:
  youtube-dl
The following NEW packages will be installed:
  mpv
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/960 kB of archives.
After this operation, 2435 kB of additional disk space will be used.
Selecting previously unselected package mpv.
(Reading database ... 124783 files and directories currently installed.)
Preparing to unpack .../mpv_0.29.1-1_amd64.deb ...
Unpacking mpv (0.29.1-1) ...
Processing triggers for mime-support (3.61) ...
Processing triggers for desktop-file-utils (0.23-4) ...
Processing triggers for man-db (2.8.5-1) ...
Processing triggers for hicolor-icon-theme (0.17-2) ...
Setting up mpv (0.29.1-1) ...
roy@TyrellCorp:~$

I probably installed mpv fully via a terminal. If our install menu-item uses --no-install-recommends, we should be good.

hhh · 2019-02-13 00:29:46

Follow up, you can install youtube-dl by itself with the same switch and avoid avahi and geoclue...

roy@TyrellCorp:~$ sudo apt install --no-install-recommends youtube-dl
[sudo] password for roy: 
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Recommended packages:
  phantomjs python3-pyxattr rtmpdump
The following NEW packages will be installed:
  youtube-dl
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/1027 kB of archives.
After this operation, 5613 kB of additional disk space will be used.
Selecting previously unselected package youtube-dl.
(Reading database ... 124820 files and directories currently installed.)
Preparing to unpack .../youtube-dl_2019.01.17-1_all.deb ...
Unpacking youtube-dl (2019.01.17-1) ...
Setting up youtube-dl (2019.01.17-1) ...
Processing triggers for man-db (2.8.5-1) ...
roy@TyrellCorp:~$

hhh · 2019-02-13 00:39:29

Sector11 wrote:

Do we have an ETA for BunsenLabs Lithium ?

We are planning on releasing tesing ISOs in 3 months. The Official release we hope to offer shortly after the Official release of buster. Finger's crossed, but we're making really good progress, The BL Team is strong right now.

hhh · 2019-02-13 01:13:11

^ @S11, I just updated it, thanks...

https://forums.bunsenlabs.org/viewtopic.php?id=5327

hhh · 2019-02-13 02:10:19

hhh wrote:

For catdish, try resizing the window larger, quit it and see if it opens from the menu afterwards.

This WFM within a session, but not after a reboot. Here are the errors, it's GTK3 theme issue IMO...

roy@TyrellCorp:~$ catfish

(catfish:1254): dbind-WARNING **: 21:08:43.875: Error retrieving accessibility bus address: org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus was not provided by any .service files

(catfish:1254): Gtk-WARNING **: 21:08:44.000: Theme parsing error: gtk.css:68:35: The style property GtkButton:child-displacement-x is deprecated and shouldn't be used anymore. It will be removed in a future version

(catfish:1254): Gtk-WARNING **: 21:08:44.000: Theme parsing error: gtk.css:69:35: The style property GtkButton:child-displacement-y is deprecated and shouldn't be used anymore. It will be removed in a future version

(catfish:1254): Gtk-WARNING **: 21:08:44.000: Theme parsing error: gtk.css:73:46: The style property GtkScrolledWindow:scrollbars-within-bevel is deprecated and shouldn't be used anymore. It will be removed in a future version

(catfish:1254): Gtk-WARNING **: 21:08:44.001: Theme parsing error: gtk.css:84:28: The style property GtkWidget:focus-padding is deprecated and shouldn't be used anymore. It will be removed in a future version

(catfish:1254): Gtk-WARNING **: 21:08:44.001: Theme parsing error: gtk.css:85:31: The style property GtkWidget:focus-line-width is deprecated and shouldn't be used anymore. It will be removed in a future version

(catfish:1254): Gtk-WARNING **: 21:08:44.327: ../../../../gtk/gtkwidget.c:8584: widget not within a GtkWindow

hhh · 2019-02-13 03:11:09

@johnraff, our "System" menu entry still uses gksu instead of pkexec, so those items (GParted, Alternatives, etc...) are broken ATM.

johnraff · 2019-02-13 04:25:48

hhh wrote:

@johnraff, our "System" menu entry still uses gksu instead of pkexec, so those items (GParted, Alternatives, etc...) are broken ATM.

Only in your system.
I think you must have some old config files left in ~/.

hhh · 2019-02-13 08:14:40

johnraff wrote:

hhh wrote:
@johnraff, our "System" menu entry still uses gksu instead of pkexec, so those items (GParted, Alternatives, etc...) are broken ATM.
Only in your system.
I think you must have some old config files left in ~/.

Hmm. I'll check this, thanks.

hhh · 2019-02-13 08:30:20

johnraff wrote:

hhh wrote:
@johnraff, our "System" menu entry still uses gksu instead of pkexec, so those items (GParted, Alternatives, etc...) are broken ATM.
Only in your system.
I think you must have some old config files left in ~/.

It's new config files, I'm using bl-obmenu-generator ATM and the commands in schema.pl are all gksu. I've changed them to pkexec and it's working, of course. I'll let @martix know via the tutorial thread here.

-edit- https://forums.bunsenlabs.org/viewtopic … 488#p82488

Last edited by hhh (2019-02-13 08:48:13)

johnraff · 2019-02-14 05:44:12

^Ah, so you weren't talking about the default BunsenLabs menu? Sorry, I'm not telepathic... tongue

bl-obmenu-generator is a user-contributed resource.

hhh · 2019-02-14 22:07:33

johnraff wrote:

Sorry, I'm not telepathic...

Well, work on that, would you? smile

damo · 2019-02-14 22:11:55

hhh wrote:

johnraff wrote:
Sorry, I'm not telepathic...
Well, work on that, would you?

Yeah, it's in the repos

$ apt-cache policy libtelepathy-qt5-0
libtelepathy-qt5-0:
  Installed: (none)
  Candidate: 0.9.7-5
  Version table:
     0.9.7-5 500
        500 https://deb.debian.org/debian buster/main amd64 Packages

hhh · 2019-02-14 22:13:16

^ Nice! big_smile

Bearded_Blunder · 2019-02-15 18:15:54

Just wondering, rather than editing /etc/network/interfaces mightn't a better approach be tweaking /etc/NetworkManager/NetworkManager.conf

man NetworkManager.conf(5) wrote:

IFUPDOWN SECTION
This section contains ifupdown-specific options and thus only has effect
when using the ifupdown plugin.
managed
If set to true, then interfaces listed in /etc/network/interfaces are
managed by NetworkManager. If set to false, then any interface listed
in /etc/network/interfaces will be ignored by NetworkManager. Remember
that NetworkManager controls the default route, so because the
interface is ignored, NetworkManager may assign the default route to
some other interface.
The default value is false.

The default .conf it installs looks like:

[main]
plugins=ifupdown,keyfile

[ifupdown]
managed=false

changing it to

managed=true

It certainly seems to do the trick here, & should anyone wish to subsequently purge network-manager later because they're on a wired connection & really don't need it, nothing breaks like it does if you'd edited /etc/network/interfaces & forgotten you did.

The Debian wiki also seems to indicate this would be a valid approach.

pet peeve with netinstall wrote:

Would also be kinder in the netinstall script than clobbering the existing interfaces file, which puts anyone who commented network-manager out of packages-norecs offline. Could test for /etc/NetworkManager/NetworkManager.conf existing & sed if so. Or even use your fancy new ini parser @johnraff ;-)

hhh · 2019-02-15 18:55:11

^ Nice suggestion! @johnraff?

Bearded_Blunder · 2019-02-15 21:43:19

Just noticed with the Lithium install browsing the Windows network doesn't work, on Helium that works OOTB you *can* still access shared resources, but you have to do the Thunar > Go > Open Location thing & then enter the ip or fqdn.

I've spent some effort with search engines researching possible causes, installing && removing various things, I've not found a proper cure yet, so if you do, I'd also appreciate knowing exactly what said cure is :-)

Last edited by Bearded_Blunder (2019-02-16 03:13:42)

johnraff · 2019-02-16 07:10:21

Bearded_Blunder wrote:

Just wondering, rather than editing /etc/network/interfaces mightn't a better approach be tweaking /etc/NetworkManager/NetworkManager.conf

Good idea!

According to 'man NetworkManager.conf' there are a couple of available directories to drop config snippets in, and so avoid overwrites by package upgrades:
/etc/NetworkManager/conf.d/
/usr/lib/NetworkManager/conf.d/
It will need some testing to make sure /etc/NetworkManager/NetworkManager.conf doesn't override them, though. If a snippet works, then it can be installed by bunsen-configs, and the netinstall script simplified a bit more. cool

---
There is a long-standing irritation with the Debian netinstall isos, that even though (with the "firmware" versions anyway) it's possible to do the install over a wireless connection, at the end of the install process all the wireless info is removed from /etc/network/interfaces. If you chose not to install any DE then your barebones CLI-only install will have no internet, and you have to write something in /e/n/i by hand to get it working. There are security arguments why this should be so, and they don't plan to change it AFAICS.

I hit this again just yesterday. It's possible to work around it by copying the functioning /e/n/i somewhere in the target system before exiting the installer, then copying it into place after reboot, but I always forget till it's too late. neutral

I should do it all over again once more, just so I can document the fix properly for posterity, but it's quite a PITA.

Bearded_Blunder · 2019-02-19 10:59:20

earlier wrote:

Just noticed with the Lithium install browsing the Windows network doesn't work, on Helium that works OOTB you *can* still access shared resources, but you have to do the Thunar > Go > Open Location thing & then enter the ip or fqdn.

Seems this is tied to gvfs-backends which uses libsmbclient to get the info but since SMB1 is now deprecated doesn't have a mechanism to call the browse data as it's SMB1 only functionality.

Most of my info comes from the discussion in this Fedora bug which concludes:

While it is annoying, you can work around it by using avahi/bonjour/mDNS in addition to SMB browsing. Linux and Mac machines will pick it up.
Or just wait, until smbc_setOptionProtocols gets into Samba release (it is not yet in 4.9.2).

There's more in that discussion than what I've pulled out here.

It's not just Bunsen, I see the same non-functioning browse network icons in all the other Debian Buster DEs I've tried. Which seems to imply that's either not in or not being used by gvfs-backends with 4.9.4 (current Buster) either.

Think we may just have to live with it being as it is through the Buster release cycle unless someone figures out that avahi/bonjour/mDNS workaround, it's currently eluding me.

johnraff · 2019-02-20 02:41:37

Bearded_Blunder wrote:

unless someone figures out that avahi/bonjour/mDNS workaround, it's currently eluding me.

Isn't installing and using avahi-daemon enough?

Bearded_Blunder · 2019-02-20 10:50:54

johnraff wrote:

Isn't installing and using avahi-daemon enough?

EDIT:
Nope: To add to that an individual *might* make it work for an individual machine if they have iTunes installed & set iTunes to advertise shares using bonjour. Windows, however has no native means of advertising the shares in a manner that would enable avahi finding them.

What is needed is something that uses the WS-DISCOVERY protocol which Windows does use.

Personally, and absent a secure fix, I'd rather see the icon itself go away as it has in PCManFM than just left, because the internet is full of bad advice about turning on reinstalling & using SMBv1 to "get it working again".

original reply wrote:

Possibly for the majority case, does Thunar use it even if it's there? How would one make it do so if not? I'll need to set up a whole separate network to test that, avahi doesn't play nice with .local domains and my network was set up way back when kb296250 from Microsoft was current (actually when it was still Q296250 & referred to NT4 rather than SBS) . Microsoft now seem to be doing their dead level best to hide the fact they ever advised using .local even though they did for many years hey-ho.
That said the usual tweaks for avahi on a .local domain aren't cutting it here, they do on stretch so I'm wondering. I'm used to having to tweak whenever avahi gets on. Exactly why Poetttering couldn't have defaulted avahi to .avahi & not interfered with the widely deployed already .local defeats me also, but no, just force reconfiguring of already deployed networks for his avahi offering The guy seems to have zero concept of backwards compatibility.
I'm not wanting to turn this into help & support for my weird case, it's more about flagging that network browsing from Thunar is no longer operative OOTB for the far more common mixed Windows/SMB-shares+Linux environment with the default WORKGROUP which'll be somewhat awkward for me to test
Perhaps someone with a default Windows network can enlighten us if simply adding avahi-daemon is enough?

Last edited by Bearded_Blunder (2019-02-21 15:12:08)

Bearded_Blunder · 2019-02-23 05:57:01

Incidentally, latest apt upgrade updated catfish, and for me at least it now launches from the menu.

iMBeCil · 2019-03-18 17:07:33

Installing Lithium via Helium.

Instead of a bit more difficult route as explained in the Experimental BunsenLabs Lithium repository has been set up (by johnraff), at this particular moment, it is possible to install Lithium on fresh Helium install (at least).

What is it good for? Well, network installation is straightforward, all hardware supported - along with various quirks - is supported OOTB, and most importantly: one doesn't have to type manually all the stuff in johnraff's post (linked above)! big_smile

Steps, tested on real hardware:
1) Install BunsenLabs Helium.
2) After first reboot, start GUI. Do not start bl-welcome; instead, when prompted, press 'q' (quit). Open terminal, and execute

$ sudo apt update
$ sudo apt upgrade   # or:    sudo apt dist-upgrade

Do not reboot.
3) Still in GUI, open in terminal or in any editor:
- in '/etc/apt/sources.list' change all 'stretch' to 'buster'
- in '/etc/apt/sources.list.d/bunsen.list', change existing single line to

deb https://kelaino.bunsenlabs.org/~johnraff/debian lithium main

- execute

$ wget https://kelaino.bunsenlabs.org/~johnraff/lithium-dev.asc
$ sudo cp helium-dev.asc /etc/apt/trusted.gpg.d/

4) Reboot, and in grub select Bunsen on TTY, i.e. do not boot GUI! Log in, and then execute:

$ sudo apt update
$ sudo apt dist-upgrade

It takes some time to finish this. When finished, reboot, for example executing 'reboot'. Reboot into GUI.
6) If something is odd, reboot once again, into GUI.
5) ??????
6) Profit! Voila, you have Lithium. cool
7) Open terminal and execute:

$ bl-welcome

and do a postinstallation according to taste. Here, I didn't test everything, but some stuff probably doesn't work for one reason or another (for example, there is no bunsenlabs-extra-images package in Lithium).

Warning: I haven't thoroughly tested this way of installing Lithium; however, I can confirm that on my installation I was able to install Oracle Java 11, Eclipse 2018, and everything worked as expected.

Please, be gentle ... angel

EDIT1: as of today (March 2020), I can confirm that the installation above works (with few easily solvable quirks [tint2? conky?]). And it owrks for both adm64 and i386.

PS: the described installation of the Lithium worked on my another (older) Helium install (in VBox), with various packages installed, and with bl-welcome executed during Helium install. This might be the sign that above procedure may be used, by experienced person, to update from existing Helium to Lithium.

Last edited by iMBeCil (2020-03-09 14:46:37)

hhh · 2019-03-18 19:30:08

I'll gladly test this when I have an hour. Thanks!

#26 2019-02-12 18:53:36

Re: Experimental BunsenLabs Lithium

#27 2019-02-13 00:12:42

Re: Experimental BunsenLabs Lithium

#28 2019-02-13 00:22:33

Re: Experimental BunsenLabs Lithium

#29 2019-02-13 00:29:46

Re: Experimental BunsenLabs Lithium

#30 2019-02-13 00:39:29

Re: Experimental BunsenLabs Lithium

#31 2019-02-13 01:13:11

Re: Experimental BunsenLabs Lithium

#32 2019-02-13 02:10:19

Re: Experimental BunsenLabs Lithium

#33 2019-02-13 03:11:09

Re: Experimental BunsenLabs Lithium

#34 2019-02-13 04:25:48

Re: Experimental BunsenLabs Lithium

#35 2019-02-13 08:14:40

Re: Experimental BunsenLabs Lithium

#36 2019-02-13 08:30:20

Re: Experimental BunsenLabs Lithium

#37 2019-02-14 05:44:12

Re: Experimental BunsenLabs Lithium

#38 2019-02-14 22:07:33

Re: Experimental BunsenLabs Lithium

#39 2019-02-14 22:11:55

Re: Experimental BunsenLabs Lithium

#40 2019-02-14 22:13:16

Re: Experimental BunsenLabs Lithium

#41 2019-02-15 18:15:54

Re: Experimental BunsenLabs Lithium

#42 2019-02-15 18:55:11

Re: Experimental BunsenLabs Lithium

#43 2019-02-15 21:43:19

Re: Experimental BunsenLabs Lithium

#44 2019-02-16 07:10:21

Re: Experimental BunsenLabs Lithium

#45 2019-02-19 10:59:20

Re: Experimental BunsenLabs Lithium

#46 2019-02-20 02:41:37

Re: Experimental BunsenLabs Lithium

#47 2019-02-20 10:50:54

Re: Experimental BunsenLabs Lithium

#48 2019-02-23 05:57:01

Re: Experimental BunsenLabs Lithium

#49 2019-03-18 17:07:33

Re: Experimental BunsenLabs Lithium

#50 2019-03-18 19:30:08

Re: Experimental BunsenLabs Lithium

Board footer