Messages

1

Feature requests & roadmap / Re: Development and maintenance, backwards compatibility, git branches. etc

« on: June 02, 2023, 02:20:57 am »

main login page seems alright but anything below gives 500

2

Feature requests & roadmap / Re: Development and maintenance, backwards compatibility, git branches. etc

« on: May 14, 2023, 05:17:57 am »

Just forked and cloned lms in the git and now the server seems to throw a 500. :-(

3

Feature requests & roadmap / Re: Development and maintenance, backwards compatibility, git branches. etc

« on: May 09, 2023, 03:20:42 am »

Will try to get to the patches it's been a bit crazy lately. Also have had problems with my DVB-S2 dongle which is a pain and seems pointless if I can't use that because that was the whole point of it. I see some fixes go into Linux 6.2 for the dongle which I am about to test out. Will post what I have done when I can make branches just haven't had the hard drive space to do more builds and out of the two drives I ordered was wrong spec from the description and the other was faulty. Cheers

4

Feature requests & roadmap / Re: Development and maintenance, backwards compatibility, git branches. etc

« on: December 04, 2022, 12:43:05 am »

<waves> Hi!

Very nice. I'd be interested in those patches. I remember having lots of webadmin issues that *I* couldn't figure out. I don't even recall the last time I tried bionic, but it is the last place I remember having access to the old ruby 1.8.

A lot changed from trusty to xenial it seemed like everything was broken. What was working on bionic stopped after I did a rebuild and new install because the php location changed again. It's difficult to keep up with it. LTS? Wow.

The main problem with the panel not working apart from mysql were php upgrades. Seeing errors in apache logs regarding HTML_Template_IT and adodb, which are included in the lmce-admin sources. I tried updating those to later versions from upstream which fixed a lot of the problems including web orbiter. I looked through the apache logs again and found some more errors and tried porting those as well. Still some to do for the later php on bionic but most of the pages for basic settings that I try seem to function.

I've yet to find out if the media and automation functionality works or try on real hardware, my process was going through the buildscripts replacements from the last ubuntu release looking to see if the package was available in the distro or trying to find the deb sources if they were needed. I had a long break from this until I found the qemu image and starting playing around again with rebuilt hardware.

Haven't tried running later distributions than bionic yet, maybe it is possible if those packages still build but not getting my hopes up for that. At least I have a better idea about where to look for mysql and php problems but detection should be a little better with the patches.

Ruby is what all all the GSD (generic serial devices) use to interact/communicate with lmce. Receivers, TVs, thermostats through serial, ethernet, wifi. A large chunk of communicating with other hardware is in GSD. Porting to the new Ruby is not a simple task, if it's even possible.

Thanks for the explanation, hitting a wall here

I got a ruby1.8 replacement building and tcl package stolen from previous ubuntu release which I thought was a dep of ruby but I'm not sure if it's used, only for the package tests to complete. Anyway, it builds and it's there in a local branch.

Are these patches in the lmce git somewhere? Can you link to them for me so I don't have to hunt around for them? (It's been a while since I have checked out any other patches but my own)

I posted what I thought was useful at the time up on gitlab userspace but this is old and outdated now;

https://git.linuxmce.org/Gavlee/linuxmce/-/branches?state=all&sort=updated_desc

I have a few other branches from experiments that I have not pushed yet, uncommitted hacks I need to separate into branches so I can possibly send a pull request. Some of those locally stored branches are probably ready to merge as is, like the ruby patch, some for the php changes etc but this was broken when I built again on bionic, so I have a hack for php detection in the deb package which is not committed locally yet. Some other updates for pthsem and lirc if they are needed also, I had some problems building these packages so tried "fixing" them but in the end  found some other workarounds. Most of the patches are in feature or bug topic branches checked out from master and then cherry picked all the commits into a branch for building, as you can probably see from the latest branch name. Some commits/branches I left out afterwards for testing if they weren't needed. I'll push more of what I have of this shortly.

minus php detection and the sql stuff in postinst scripts which I am about to redo this is most of the changes for lmce-admin;
https://git.linuxmce.org/Gavlee/linuxmce/-/commit/52337a08b745c8fcbfd6670741c577223c8fec9d
https://git.linuxmce.org/Gavlee/linuxmce/-/commit/84de9d47d3cc2843956fe7a9b42dd33cfe9dd01b?w=1
https://git.linuxmce.org/Gavlee/linuxmce/-/commit/5f3beb896e6485cc80463e721e33f36a7b7209ea
https://git.linuxmce.org/Gavlee/linuxmce/-/commit/c77d8d0f860e2c991032edb93dba48354d016b95

Are there upstream changes in their git repository or are these changes you made? We have a snapshot of the upstream build... form whenever I last updated them in our repo, lol.

I was never able to successfully achieve this. Very nice.

Both. For lms I need to clone the included submodule and submit the changes there. I did something last time and wiped it lol it's basically just upstream but with the debian dir modified for the newer version.

For ruby I made a branch on my local linuxmce repo and merged the latest changes from upstream brightbox on github. Then made a couple commits on top to try and get it building for bionic (see tcl, and to disable bugged? tests). This is a pretty big patch because of tcl seeing as it's only used for test?

Thanks again, and for the guidance.

lol, I wouldn't! You'd definitely want to do some intense testing in a parallel boot and be able to revert to your 1404 install if necessary. I'm still running 1404 in my house but mostly doing lighting control these days.

Heheh.
I think if I can keep/get mythtv and zwave working and not have to reboot too much there will be no complaints here
asterisk crashed too much on xenial to even attempt that but bionic looks like a better candidate to upgrade to.

Our git isn't setup to do auto builds. If we can get patches applied to our repo that work then we *may* be able to get bionic debs updated.

I still have VM build servers here for 1204 through 1604 and I have a 2204 builder as well... although I got to a point that I decided without ruby I wouldn't be able to achieve much and backed off. I *think* fluffy is still alive and if I can get a build working we might be able to kick a build over there.

There were big changes to mysql that broke our sqlcvs system pretty majorly. I got it working with credentials but no anonymous submissions can be approved and added. If you have the specifics I should be able to make that update.

The database files for the builder are dumped from the live sqlcvs server. As we don't have anything replacing in the search and replace functions the prepfiles aren't really a thing per se... What's the issue with mysql on bionic? If there are extra, or missing, dependences for install send me the specific details and I'll see about getting them updated.

Ah, ok. I was looking in the gitlab yaml file thinking it would be possible, having wrote most of the scripts for a packer image they could probably be reused. It's long and complex build. I'm glad I ask first

Maybe there is a configration problem on my firewall blocking sqlcvs, I'm sure I added rules for that. Will check again.

For me to do is tidying up the branches I was working on and commit the changes for php detection, in preparation for possible pull request.
It's probably best if I start with mysql/asterisk/php because it's all related and there is no lmce-admin panel on >=xenial unless that's fixed. I'll redo it into another branch and do a test on trusty with it first though. Sound ok?

PS. UI2 works in qemu with virgl, the flickr screensaver isn't showing pictures though. hmmm

Keep having fun!

Cheers

5

Feature requests & roadmap / Re: Development and maintenance, backwards compatibility, git branches. etc

« on: November 30, 2022, 03:04:40 pm »

Hello. It's been a while

Apologies for reviving an old thread but this is a continuation of what I was doing before my workstation blew up.

So a few years back I tried building LinuxMCE on xenial and bionic with packer and vagrant. (I can hear the cackling, hahaha)
Since then a lot has happened.

Despite the patching we did, the xenial build spewed so many errors in syslog from asterisk the vm image filled up and crashed. I came to the conclusion after a few attempts that asterisk was too unstable on xenial to try and fix that with the amount of errors and the mysql changes along with it. It's a shame, I thought the screenshots above were quite pretty

I also did a bionic build with the _REALLY_OLD_ ruby 1.8.x updated to what was the latest upstream patchlevel. A couple of tests were patched out of the deb to get it to install for some reason, bugged tests? Building in container or user problem? I don't know yet I'm still looking but related to gdbm (removed in latest upstream ruby) and webrick.  After finding the vm image I did in 2020 it loaded in qemu, asterisk doesn't crash every few seconds there. I redid some patches and tried another build as I wrote this and it seems to compile again. More stuff was broken, php got updated again. And, for some reason the wizard didn't start on my newer build so I tried to find out what I did in the vm to make it go.
I managed to iron out the problems in bionic and I have the web admin and orbiter running again there now.

I'm still learning about LinuxMCE but I assume the ruby component is necessary for a lot to function, and this is tied to that ruby version unless code is ported. I'm guessing this is not a trivial task and I don't even know how to get a listing of what would need to be ported if indeed this is so. I am not a pro ruby programmer, if the ruby is stored in the db that make it even more, interesting.

With the small php changes I posted and the db ticket changes in my branch I think the panel is functional on trusty, xenial and bionic, I tried adding a room and user from the last bionic build I did in 2020 which include the patches from my xenial branch (minus the php detection). The problem on xenial was not so much the panel after my patches but asterisk chewing through cpu time and restarting all the time making the system unusable and filling up the disk with logs. I'm not sure if asterisk actually works on bionic but at least it doesn't crash every minute, allowing to debug the system a bit more easily.
The php.ini changed location a few times, this is currently at /etc/php/7.2/apache2/php.ini on bionic, I have another patch that I haven't submitted yet trying to fix version detection of php through the cli in the core/webadmin postinst scripts to support trusty onwards.
Some more porting is needed for later php versions but most of the pages in the lmce-admin work from brief testing.

The builds scripts that I was working on I converted from json to the newer hcl packer format and I was going to post them up on the gitlab but the board on my main computer blew a few caps (seems contagious): I had to do a rebuild and salvage parts all over the place. The vagrant build/test script kind of works but for some reason I can't get in to any of my vms any more with it so am testing manually again with qemu. I want to upload it to the gitlab as well but problems like this keep preventing me from doing so.

logitechmediaserver also needed an update for latest perl on bionic which brought it to 8.3, I had the package building but somehow my changes got overwritten and needed to do them again. I will get around to doing another build on trusty to see if everything works there.

Yep, I'm slow. LinuxMCE takes a long time to build and test. Can't promise anything but I'll post up the next round of patches that I have again soon. Lots of things may still be broken on bionic but I can install through the built debs. The hybrid did boot, went through the firstboot setup, and asterisk, dcerouter and mysql are all running with access to the web panel at least.

I'm not brave enough to install over the currently running 14.04 with my built debs yet , that's providing my telly around the house and some other stuff but I'm getting closer :-)

I'm trying to think of the best way to get bionic deb packages across, I think it's possible to build in the gitlab CI but does it have the runners (docker?) and will it burn through someones hosting bill - it's a big repo. I guess the only way is to have a go at it?

Notes: pluto-libresolution needs libconfuse0 which doesn't exist on bionic, I fudged the dep with a fake package made with equivs but the dep needs fixing properly in the database. I can't update it?
Also, the dependencies on bionic in my copy of the database seem to miss a few essential packages. It seems I can't update to the latest version due to mysql being blocked. Is it possible to do a dump of the database prepfiles to git please? I think that could be a viable workaround. I would do it but it seems pointless if my copy of the db is ancient.

Cheers

6

Feature requests & roadmap / Re: Development and maintenance, backwards compatibility, git branches. etc

« on: September 09, 2019, 01:17:38 pm »

Very cool!!!  Some of these issues may be fixed from recent additions.  Be sure to grab any updates!  The majority of the system is building on ubuntu bionic and debian buster now too but ruby/gsd is dead and I'm not sure it can be resurrected.  Great to see xenial installed!  I don't remember when the last time I tried that was.  Awesome stuff!

Kind words, thank you!

When you go to push anything to git we should do it in a new branch so we can test the changes before dropping them in master.

What I have been doing is making bug or feature branches for every error or feature, then making a testing branch and cherry picking all the commits from those branches into it and compiling from that branch. Will be trying to clean up the rough edges and upload the fixes but having trouble keeping track of everything at the moment!

There are lots of web clients for IRC that you can also use.  Personally I use Quassel because I can run a single instance on my dcerouter and then use clients on any computer or android phone I have.

That's a good idea, I have no problem with IRC itself really, I used to use it a lot on freenode with screen and irssi. The issue I have is some time ago I asked for a cloak, all was well then. However, I didn't log in for a few months and now my identity has been taken and I cannot log in with my old nick. So the fact I cannot hide my IP and don't have my old login is a little bit of a pain and every time I connect I get booted for having a taken username! Have been using xmpp for a while now just wondered if that could be a solution if any of you guys or girls have an account.

ok, I've pushed everything I've had from the last year into the repo and brought bionic up to about the same point as xenial (build side anyways).  Check git.linuxmce.org as I've touched a ton of tickets and commented on some things you've been commenting on as well. 

Thanks so much for the hard work and advice you have given, I will be pulling all the updates and doing rebuilds on top of those changes.

The master branch of build-scripts and the master branch of linuxmce are building on ubuntu 1204/1404/1604/1804 and raspbian wheezy/jessie/buster.  There are still some missing database incompatibilities for 1804 and buster but both are building.  GSD is broken post xenial/jessie due to ruby upgrades.  I can't get ruby 1.8 to build on the newer releases and the GSD implementation is completely broken with newer versions of ruby.

Yes I notice the ruby problem, I gather all the ruby code is stored in the database?
I found the github for the ruby1.8 but didn't get that far yet to try anything.

The pluto-database-settings package that sets up the database users and passwords is number one priority for installs from xenial onwards.  I haven't been able to setup any test systems yet, just builders.  Really need testing on that package as it sets up the database users and passwords.  Clearly it isn't working properly from the issues identified on gitlab.  If we can get that working then testing installs will be much easier!

From my test install the packages installed with no errors from post-install scripts only the lmce-admin login not working because of the password issue, have mention this on the gitlab but will need to test again and have a look at the pluto-database-settings package.

We should try to connect and chat at some point.

I agree.
Been trying to get on freenode through disroot.org IRC gateway but still don't have a nick and get booted all the ones I try.


PS. I've been doing the builds for the packages in docker recently, I'm not sure if there was a bug in docker causing the pthsem package to fail but I haven't seen that error since upgrading to bionic on my build host. Everything is much faster compiling in docker compared to a VM and that is much time saved. I am finding Docker is great for building LinuxMCE and will be uploading the scripts when I can figure out how best to get the ugly hacks put into git patches.

7

Feature requests & roadmap / Re: Development and maintenance, backwards compatibility, git branches. etc

« on: September 06, 2019, 04:53:02 pm »

another shot of the desktop

8

Feature requests & roadmap / Re: Development and maintenance, backwards compatibility, git branches. etc

« on: September 06, 2019, 04:52:03 pm »

Hello, back again.

Some screenshots of my building and testing on xenial.

Built under packer and tested Qemu + virgl. (having trouble testing in vagrant so used qemu but almost there)

Was surprised to see the setup tutorial videos came up and played great but for some reason those screen captures were blank from qemu screendump. so used spectacle instead.

Am I brave enough to install it on my home server...? 

Some notes:

chan-sccp have fixed some in the buildscripts and linuxmce but the /etc/asterisk/sccp.conf file still collides with lmce-asterisk on install
my vdr patches compile but probably break things, not tested yet
tried to fix most of the compile errors in autotagger, advanced_ip_camera/onvif and buildscripts so the build completes through
Switching from the orbiter and kde works great!

will be uploading it to git when I can

Cheers

PS Having trouble getting on IRC . Does anybody use XMPP by any chance please? it's lonely!

9

Users / Re: Possible Q Orbitor Issues

« on: January 11, 2019, 04:22:50 am »

One more thing.

The QOrbiter was added on the core first, before running the QOrbiter on the android device?

Maybe you could try on the android device, deleting settings left over to remove any chance of conflict, then delete the QOrbiters on the core and quick reload the router. Once all the settings are nuked try loading the QOrbiter again without doing anything on the core.

I could be wrong but adding the QObiter first on the core may confuse things, should the QOrbiter not be automatically detected by the core when it first runs? I think that's how it should be but I'm not 100% about that.

10

Users / Re: Possible Q Orbitor Issues

« on: January 08, 2019, 10:37:48 am »

From the information provided, my guess is it's either a network configuration problem or something to do with the Android versions. I haven't tried QOrbiter on Android 8 yet, though I don't see why there would be a network problem like this if the QOrbiter works otherwise, It has worked for me from android 4.x ish.

I have had a similar problem with the QOrbiter running and showing the main screen but not any devices like lights etc. I do not remember what the problem was but I remember my network config was different then, most things seems to work in the QOrbiter for me at the moment but I have the bridge connected to the internal LMCE network not off my router box like yourself.

If I were you I would run pcap or wireshark or some packet sniffer on the device and core if you can, also check the pfsense/firewall logs while the QOrbiter is connecting. Doing that may show if any traffic is being sent and not receiving a reply and may help diagnose the problem.

Only other thing I can think of is removing the settings files QOrbiter creates (on the android device) and starting over.

Can't think of much else at the moment.

11

Users / Re: Possible Q Orbitor Issues

« on: January 04, 2019, 03:47:47 pm »

I do not have a /var/www/lmce-admin/skins at all.

Getting puzzled how you have this set up
Can I ask more about the network config please, by the sounds of it you have this working before? What changed?

The QOrbiter is hanging off a wifi access point on the pfsense box and also on the internal network? Please clarify because this seems a bit contradictory if the Qorbiter is trying to access the core going through the 'external' IP address, say 192.168.1.x.
What is providing the DHCP to the QOrbiter, the pfsense box or the lmce core?

There are probably a lot of different ways to set this up.
The way I have seen to do this are as follows:

1. wifi off your pfsense box
you will need rules and nat set up properly, maybe even port forwarding, if you get this to work please post how, i tried this method and think i hit the same issues as you did but that was a while ago.

2. wifi access point/bridge in the internal network
 how I have currently, some docs on lmce wiki and elsewhere how to set up a wifi bridge

3. VPN
I have had this working on and off but the default config needs some small tweaks I think, which is scattered all over the forums and web.
this require set up VPN in android or the device connecting to a interface that has the udp 500 port forwarded to the lmce ext interface. the android device will appear as on the internal network 192.168.80.x once connected through the encrypted tunnel. as a bonus one can have this on 3g/4g roaming and access your lmce network from outside by QOrbiter / SIP/ lmce-admin / orbiter etc.

Probably more ways but getting this crystal clear what you plan to do may allow more help. The VPN route is best and most secure IMHO but needs some love in the default config, especially for android.

HTH some
Gav

12

Users / Re: Possible Q Orbitor Issues

« on: January 02, 2019, 02:05:32 pm »

Hey

I use the QOrbiter on android on a phone (LineageOS 14.1 - Android 7.1) and a tablet, also android 7. All I did was install the apk provided by the download link in the lmce-admin. I haven't needed to mess with skins or anything like that, I think they are provided over the network. There is an option in the Qorbiter settings screen for something to do with skins but I have never altered it.

Please could you provide more info about your network, for example what subnet the QOrbiter devices are on, if they are in the same network as the internal - 192.168.80.x or external. From what I remember having a similar problem before it was communication issue between the core and qorbiter, maybe a firewall or routing issue? What android version are these devices?

As it stands for me right now I can control lights, execute scenarios and view cameras etc which is what I mainly use it for.

Edit: forgot to mention this is on 14.04

13

Feature requests & roadmap / Re: Development and maintenance, backwards compatibility, git branches. etc

« on: November 29, 2018, 02:37:43 pm »

All my builds are in Virtual Box.  I have one builder with multiple chroots.  I also have an armhf builder (that I need to resurrect) as I need to get the RPi3+ booting.

I've been using the packages built this way from you for a long time so it works good I know that. I have no problem with VirtualBox at all, although I probably do have some bias to qemu. packer doesn't discriminate which builder one wants to use, it makes it trivial to add some json and use another builder with the same scripts to provision the box, it has made it very easy to compare build time across the three that I have set up so far. In fact i started with VirtualBox which is the default provider, then Docker then Qemu. Qemu seemed to compile couple hours faster when building so I went with that due to the time. I know a couple things though, compliing in a VM is painful and you have patience.

I also have some armhf boxes and had the idea of doing this build in docker on them but it's back to pthsem error?

I'm very interested in exactly how you've got this setup and launching.

packer provides all the setup for this, docker is more lightweight like a chroot than a vm so when the build is finished it's tagged and stored locally in the docker image repository. packer builds locally so it can't be done on a remote docker instance. packer can export docker images but I wanted them tagged locally for now.

it's just another 'builder' under packer and using the same provisioning scripts wrapping the buildscripts, with some if statements to do a few things differently in a container rather than a vm.

I will clean up the scripts and upload to git because I do think docker as build platform would be good if it wasn't for pthsem failing, snapshot and cloning of image is easy. I could not reproduce the pthsem error under VirtualBox or Qemu.

QEmu == Ewww, I can agree with that.  Not sure if you're referring to automated 'modeling'/testing of distributed lmce network or the exact specifics.  All my 'live' testing has so far been done using VMWare or VirtualBox and snapshot systems to install/test/revert/repeat.

Yes that is what I meant, in vagrant to automatically fire up a LinuxMCE network with vagrant up, bringing up a core or hybrid and even model netboot with 20 machines seems very useful. This can also be done in VirtualBox which is the default provider for vagrant, but at the moment I am using the libvirt vagrant plugin (qemu).

Add 'NUM_JOBS=XX' to /etc/lmce-build/builder.custom.conf to set the number of cores used during the build.

This is exported through the environment when I execute, either automatically by nproc command or set manually but some builds still only use one core, I know this is a tricky problem to solve because of some builds failing.

Using the above will avoid building anything that fails multi-core builds.

^^

This is something that needs to be looked into going forward, our current build system is outdated, but it's not as simple as in many projects due to the database system we rely on.

The build system may be outdated but I cannot criticise it, I have built distribution from source and know how difficult it is. So much changes in different Ubuntu versions it's hard to keep up with that alone, and the amount of packages LinuxMCE glues together is perplexing. Yes the database is a hurdle for me at the moment and something that's a requirement to learn to make any progress I can see, have been reading about sqlCVS but am still very unfamiliar with packages and what needs to be done to make one.

Most everything is sacred but the knx/eib stuff has to work.  Everything we do here is supported and enabled by someone that relies on knx and that must be maintained.  Oh... and VDR too

I can probably help test VDR but being MythTV is what I have used in forever that is what I have running at the moment because I couldn't get VDR to work. I guess that is just a matter of being familiar with MythTV and not knowing anything about VDR. And being lazy!

Right now database changes have to be made by one of a few devs, some that haven't been seen for a while.  Changes in mysql forced updates in sqlCVS that seem to have broken anonymous commits/approvals.  I can work with you to get things input if necessary.

I have been reading about how this works on the wiki but to be honest I haven't done many changes to the database yet through not knowing enough. I have experience with making rpm, ebuild and some deb packaging but how this relates to the database is something I am still learning. I appreciate your continued help in all of this so thank you very much, it has  really helped me understand so much more about the system.

Official builds are all produced on one machine for all i386 and X86_64 builds and all official armhf builds have been made on my armhf builder.  Essentially all our build scripts cater to this primary builder.  I've added lots of speed-ups and I skip many steps in the build process in my chroot environments but that depends on not destroying the environments and knowing how to reset those steps to occur, none of these things are documented anywhere.

I can understand that, the contrast with packer is faithful build from provisioning a base OS image for each branch and arch all the way to deb so these steps you take and all that knowledge are missed. Those little scripts and hacks I have had to take may be useful to you and it's the same for me. I notice by doing build this way this is documented in code.

The firewall is severely broken and you're best option is to disable it entirely.

Ouch, I have had to in Vagrant but my running network is behind another firewall so do not notice this.

Things are pretty quiet but you might try to join #linuxmce-devel on freenode irc.  I try to get on daily and if I'm around then it can be easier to converse and 'brain dump'

I have tried to get on IRC but had trouble using the service recently, one of the reasons I hit the forum and bug tracker. Will try again, the forums are great but it would be good to chat about the subject with less latency.

Keep having fun!

Cheers

14

Feature requests & roadmap / Re: Development and maintenance, backwards compatibility, git branches. etc

« on: November 27, 2018, 12:13:41 pm »

First off sorry for rambling on, this is almost brain dump off stuff I've been thinking about..

I can give you an example though thinking about it more it could be achieved with 2 branches. I know more branches adds complexity and maintenance by having to backport between them so having one branch say 'pre-bionic' and just use master for bionic onwards would suffice in this particular case maybe.

A little background on my current LinuxMCE build and to how this came about.

The way I have build LinuxMCE so far is through packer and vagrant, I am used to building in chroot and have no problem with that at all but I thought to extend this further by utilising new container systems so I can move OS easier. This led me back to packer and vagrant.
So far I have been able to build LinuxMCE in VirtualBox, Docker and qemu all through single provisioning scripts wrapping the LinuxMCE build scripts in packer, in theory this could be used to build LinuxMCE in the 'cloud' by whatever provider packer supports.
Granted I have had to take a lot of shortcuts and do a lot of horrible hacks at the moment but I have had a few succesful builds so far.

Docker is probably the fastest method I have tried due to the least overhead, however compiling pthsem fails in the container. VirtualBox while working, is unusable in my opinion for the size of LinuxMCE. Qemu does work but takes a fair few hours to do a complete build on a quad core under kvm but does work great for compiling and providing a functional test environment in vagrant. To model a LinuxMCE network system, even OpenGL with virgl and networking between systems, netboot, disked md etc. I have found this invaluable tool to test LinuxMCE more. I have used lxc in the past but have not tested this path yet but will do so as these are lightweight like a chroot. VMWare and several others are possible.

So after that rambling explanation, it's taking hours to build LinuxMCE under qemu, before I can look at fixing why pthsem fails in docker, I started looking for ways to reduce build time.
On bionic and greater includes debhelper 11. by changing the debhelper requirement in the deb package control and bumping the compat file to 10 most any build that uses the debhelpers should utilise parallel building. I notice when compiling LinuxMCE, on a lot of the builds there is only a single core being utilised so by bumping the debhelper requirements on bionic and onwards, it should speed up build times for a lot of packages.

There are obviously some packages that will need fixing due to this change too, some packages will fail when make is invoked as parallel. some linking methods are different, I think --as-needed flag, so some libs will need juggling around with the link ordering, this is where I stopped, I reverted it because I knew it would break trusty and time better spent elsewhere.

So anyway, back to the original answer a change like this would break pre bionic builds and the only way I see is another branch. Knowing how LinuxMCE deals with this would be useful to move foward.

I can understand the develpoment model and trying not to deviate too much from master across all the branches and having to test across them all.

In the script on packer/vagrant would be trivial to select which build os and then specify which target git branch to build, at the moment I am just feeding in my own tree and have experimented through ways getting the sources into the container and evaluating which methods are faster or portable across providers.

This has been a long journey the last few months but I would like to work on this path more it has really helped me being able to test LinuxMCE across the different versions without having a dedicated box and not touching my working system on 14.04. this came about by looking at ways to make the build faster because it's a little painful inside a vm right now, I would rather take longer and have the build self contained like this though because it has many benefits being able to copy the dev environment around, working on a foreign OS and bringing up the image with only a few commands.

Another option was to look at way to remove pthsem with more updated software that depended on it but it looks like it's used by some core things I cannot test due to lack of knx/eib hardware so that isn't an option currently for me.

Just thinking of ways to improve LinuxMCE, I know extra branches equals more effort and time is the enemy but I don't want to break backwards compatilbility either, I think you guys and girls have done a stellar job and the current system works great. I hope you not think I'm poking holes at LinuxMCE just I think with packer/vagrant it is how one would set up machines manually so by me wrapping this, eventually those wiki pages "building LinuxMCE" could be redundant. It could be codified and at the end of a couple packer commands out pops a (HUGE) machine image with dev environment and built deb packages, and from then even various machine images, like core, hybrid etc. can be made. At the moment I am looking at ways to get my database changes in using this method but I am not going to lie I am struggling with LinuxMCE as you can well imagine.

I would like to know more about how you work and how this all fits because I do not want to interfere with current build methods, so I am trying to make this an extension if you like, a wrapper around the buildscripts. I would welcome and help with this I don't want to waste your time the only thing stopping me uploading at the moment is it being so rough and cutting corners but I hope to work these out.

If you can make sense of this rambling posts and weird bug reports there is some method to my madness I hope

Cheers.

P.S. While I think of it, I have just managed to install a hybrid in vagrant with the debs from deb.linuxmce.org, I got access the vm by disabling the firewall in /etc/pluto.conf with a hack in the Vagrantfile but this is hardly optimal so wondered if there was a way to enable ssh access by the cli after apt install lmce-mybrid. the firewall comes up and blocks access so i had to disable the firewall because I don't know how to enable programmatically, the outside ssh access in LinuxMCE settings to stick. Phew. Thanks!

15

Feature requests & roadmap / Development and maintenance, backwards compatibility, git branches. etc

« on: November 24, 2018, 09:24:06 am »

Hello

After taking the plunge and trying to build LinuxMCE after being a consumer for too long. One of the things I notice is the problem of keeping backward compatibility while working on newer Ubuntu branches.

Would it be feasible to add some branches in git like ubuntu-14.04, ubuntu-16.04, ubuntu-18.04 for example, to allow maintenance on these older Ubuntu versions without holding up current developments?

I know some things have do be done by conditionals in the code for each branch and there is the database to consider but some things in the code repo can only be done with another branch from what I can tell.

Anyone have thoughts on this?

Cheers.