Ok, I am convinced with doing option 2.

@zlatan.todoric I made pictures of the module in my Librem 13 v3 (see below). I didn't recieve the module from thinkpenguin yet, I'll send pictures as soon as I receive it.

@mak can you take pictures of our and the ordered module? Also mak can elaborate more as he has the one.
@stefannagy can you also attach images of module you ordered? Trisquel having something and Debian not is of interest to me (adding also @jonas.smedegaard to maybe try and track what is the difference).

That's pretty interesting!
It might even be that the "firmware" actually isn't real firmware but rather a set of config options. I have seen something like this for CSR based Bluetooth chips too. The settings would then also control the WiFi/Bluetooth coexistence which is probably the reason why it does not work w/o the blob in the Librems - the antenna switch does not switch it to the Bluetooth chip without it and thus the BT does not "see" any other devices around.
According to kernel sources our device is a
/* Atheros AR3012 with sflash firmware*/
The firmware it loads consists of two parts:
ramps_0x11020100_40.dfu
and
AthrBT_0x11020100.dfu
The "ramps" file is sysconfig the second is a RAM patch file for the in chip flash firmware.

People from thinkpenguin.com told me that in fact not all Qualcomm Atheros wireless combo cards require proprietary firmware for bluetooth to function. But with current distros you won't even notice that you have a card that doesn't need the firmware since the kernel wouldn't try anything without it… If you don't make the firmware available the driver (and not the firmware loading mechanism) will be disabled.

Interesting, I wonder what caused network-manager-openvpn-gnome to not be installed on my new system... Ah well!

Done, I moved everything away from Github a while ago.

@d3vid Yes - although technically, you would also need to check the recommends of the whole dependency tree that pureos-gnome (or any other package) depends on.
If the package is in the Depends line, you will have it regardless of whether the installation is new, if it is just recommended it might only be present on new installations.

Thanks for confirming that @mak , much appreciated!

I just generated new images, network-manager-openvpn-gnome is preinstalled on all of them ([installed,automatic]).
I therefore think it's safe to close this issue.

@chris.lamb That it's in recommends just means that a user can remove the package.

This is resolved in debootstrap >= 1.0.104pureos1 now.
You are now able to bootstrap purple and landing based on a revised green script.

@guido Ubuntu's scripts have a less-generic name though - that's why debootstrap in Debian has "green" and the Tanglu distribution names ("chromodoris", etc.) but not "staging" (Tanglu's equivalent to "landing") - I assume the same will be true for the generic landing name.

NB. this is an external, USB adaptor.

Assigning @mak (in the first instance) as it's installer-related...

Linking the .dev.0.fw to .4.0.fw apparently can work but there is an issue with NetworkManager using random MAC addresses that prevents associations:

I have the same trouble in the installed system. I've installed firmware-ath9k-htc; this has an htc_9271-1.dev.0.fw blob and also puts this in /etc/modprobe.d/ath9k_htc.conf:

options ath9k_htc use_dev_fw=1

however, the kernel is looking for htc_9271-1.4.0.fw and fails. I've tried linking the .dev.0.fw to .4.0.fw but it doesn't seem to work.

This problem seems to specifically point to the installer not changing its own active locale during the install process, but merely setting the default locale for the install on disk.

Check the Depends and Recommends of, for example, the pureos-gnome packages (and similar).

@mak I've been meaning to file this issue for a while, so it could be the update happened between my last install and me actually filing the issue. Since you've confirmed it I'm happy to close.

Works. Seems to have been fixed by a recent update, defaulting to java to jre10?

Hmm, this is a tough problem to solve. We can not really make a purism-specific seed for default packages. We could enable Purism branding on specific installs though, in which case the existing seed would always need to install Purism branding though (even if it is not shown).

I assume this is resolved.. as in, shorten your hostname? :)

(renaming to reflect underlying issue as I understand it.

Unless you are suggesting we upload the 'experimental' version directly to PureOS for now?

@mladen.pejakovic So, GNUcash was removed from the Debian "testing" repository and it is thus not in PureOS. There is, therefore, nothing to backport against!

https://bugs.debian.org/901134#47 further movement FYI

Ubuntu's scripts (/usr/share/debootstrap/scripts) are also in Debian. Would be great if the same were to be true for pureos since that would tickle to all downstreams and enable many more people to contribute without hazards.

@mak, go forward with this implementation so contributions and work of phone team becomes natural within pureos :)

In that case network-manager-openvpn-gnome was definitely not installed on my new system (installed 2018-04-26). :)

@chris.lamb I didn't misread the report, I just mistyped the package name (fixed). The statement in itself is still true.

@mak I fear you have misread this bug report. This is about network-manager-openvpn-gnome, not network-manager-gnome.

There's also tools like vmdeboostrap that invoke deboostrap / pbuilder directly. It would be much simpler if they could work out of the box.

No, with the new installation there can't be a kernel mismatch anymore. The problem here is that Libreboot is run with an UEFI payload which boots into an (unsupported) EFI mode of the live-cd, which still offers a debian-installer install option.
See https://tracker.pureos.net/T460 for reference.

@chris.lamb No, if network-manager-openvpn-gnome is in the list it *will* be installed, unless there is something else pulled in that is mandatory and conflicts with the package.
It will not be explicitly seeded if it is pulled in by another package that is also seeded.

This has nothing to do with Plan. You just happened to hit/see it whilst installing Plan.

IIRC, we had a couple different customer questions about Steam functioning under PureOS, and even though I knew it wouldn't, I thought I should test so as to not tell them wrong. In other words, don't test on your production machine ;)

@james.rufer (any reason why you added i386?)

oot@librem15v3-enterprise-pureos:/home/james# dpkg --print-architecture
amd64
root@librem15v3-enterprise-pureos:/home/james# dpkg --print-foreign-architectures
i386

Just went to do this but network-manager-gnome-openvpn is already in the list of Recommends since 31 May 2017 and crucially is actually on the same level as network-manager-gnome. Thus, whatever installed network-manager-gnome via the recommends system should have also installed network-manager-openvpn-gnome for you.

@kyle.rankin wrote:

And your smb.conf please! Sorry, not sure why I didn't ask before given that the error message clearly says it is "invalid"

Odd thing is when I went into the menu to open another application, "Plan" and "Plan Work package" are now installed

PureOS never had Chrome package in its archive and Chromium is now removed and blocked as well.

@zlatan.todoric This is my only source

Fair enough, but there are two mentions here, and chrome is a package which is installed through the package manager. Any thoughts on font issues there?

Just installed and tried it, works here. Can you update your system and see if it works for you as well?

I'll take this back unless there is strong objection as it's still literally open in another window..although will upload after lunch.. :)

Installing "Plan" works fine for me. I suspect the installation failure here is a symptom of a different problem. Can you try and do an PureOS upgrade on the command line? ie. sudo apt update && sudo apt dist-upgrade and look specifically for any samba issues?

There is new OEM image in place, please open new bug if it doesn't work as expected.

Yeah, I did mean in collaborative way (aka ping the current maintainer, offer help etc). Thanks for noticing my not so good way of putting it out :)

what the...did you maybe enable multiarch on PureOS (aka adding 32bit packages/libs). Also what sources do you have enabled (did you add any sources on your own?).

No. This could be closed unless you have reason to keep it open.

if you see some assigned bug to other person but you can fix it, go ahead

@mak is it possible that we have a kernel mismatch now with new ISO?

Here is report from terminal after running

@james.rufer are you still experiencing the issue?

I just tried and installation went fine for me so I can't reproduce this @chris.lamb can you reproduce it? Also @james.rufer can you try running sudo apt install --reinstall samba-common-bin and then try again installing the package?

eh, you can do it, I assigned it to mak as he was doing all previous uploads (the ones I recall) though assigning is not at all blocker for anyone else to do it so go ahead (also on contrary, if you see some assigned bug to other person but you can fix it, go ahead).

Sure thing :)

It should work just fine (be sure to turn off secure boot and uefi if possible inside your BIOS). In general if you can boot Debian testing main, PureOS should also work there.

@zlatan.todoric Why re-assign? I did the last pureos-meta upload at least & was literally just doing this another window (have stopped, mind you..)

Isn't this upstream issue? If yes we would really need to create upstream tag as there are some bugs popping up looking like that.

Unless someone ports it to Wayland we can't actually work on this :-/

is this an upstream issue and did you update your PureOS to latest available updates?

Installation via snap is currently of out of scope for PureOS (we can't and will not guarantee third-party repos as that is contrary to FSF rules of endorsement).

Chris, can you own this one? :)