14:33:36 #startmeeting 14:33:36 Meeting started Sat Feb 4 14:33:36 2017 UTC. The chair is Jaymzz_. Information about MeetBot at http://wiki.merproject.org/wiki/Meetings. 14:33:36 Useful Commands: #action #agreed #help #info #idea #link #topic. 14:33:39 who are the video chair? :p 14:33:56 Jaymzz_: is the chair for the IRC portion of the meeting after that I think we'll be freestyling 14:34:16 Ok :) 14:34:22 As usual, I am the chairman, this time is a bit different, you can watch us live on YouTube and comment there OR here! Link: https://www.youtube.com/watch?v=gpABm5T7wMM 14:34:27 I can seee yoooou 14:34:32 \o faenil 14:34:33 #info As usual, I am the chairman, this time is a bit different, you can watch us live on YouTube and comment there OR here! Link: https://www.youtube.com/watch?v=gpABm5T7wMM 14:34:54 #link https://www.youtube.com/watch?v=gpABm5T7wMM 14:34:58 wow, this lag is with the videa is like a NASA mission :) 14:35:12 hi faenil ! 14:35:13 #topic Brief introduction, please introduce yourselves for 5 minutes ;) 14:35:21 #info nh1402, community member 14:35:23 Sfiet_Konstantin: yo! o/ 14:35:28 #info Steph Gosling, community & porter 14:35:30 #info Cedric Heintz, community member 14:35:35 #info James Noori, Community manger at Jolla 14:35:39 #info Znurre, community member 14:35:39 #info Sfiet_Konstantin community dev 14:35:44 #info mattaustin, community / developer (Australia) 14:35:47 #info Dylan Van Assche, developer 14:35:49 #info vgrade , community 14:35:51 #info robbster community member 14:35:59 #Info Fabio Isgrò, community 14:36:00 * Sfiet_Konstantin and stephg are at fosdem and will look at IRC often 14:36:03 #info Kimmo Lindholm, community, porter'ish.. 14:36:08 #info Matti Lehtimäki, community porter 14:36:14 #info Leszek Lesner, community, app dev 14:36:15 #info Tommi Keisala, community member 14:36:16 o/ kimmoli 14:36:17 #info Sebastian Wolf, community member, SFOS app developer 14:36:17 #info Carol Chen, community member 14:36:24 Sfiet_Konstantin: o/ JvD_ o/ 14:36:26 #info Norbert Wenzel, community 14:36:28 #info Pablo, aka @chipiguay in telegram fan group. Community member and apps coder :) 14:36:29 #info Paul van Tilburg, community-member 14:36:35 perfect Sfiet_Konstantin :) 14:36:38 #info eekkelund, maemo community council + community dev 14:36:40 #info Thomas Dierig, community-member 14:36:47 #info Pami Ketolainen, backend developer @ Jolla 14:36:55 #info AL13N user, appdev @FOSDEM 14:36:57 #info Andrea Bernabei, Nemomobile community 14:37:15 #info Martin Kolman, community, modRana developer 14:37:23 #info Tadeusz Sośnierz, community, bootyhunter dev 14:37:40 #info marja, user, @fosdem 14:38:02 #info Thomas, works on things related to Mer 14:40:03 this is kinda weird 14:40:05 Alright we shall move 14:40:09 yep 14:40:10 #info Aniello, long time Maemo user/contributor (Xournal), user now. @fosdem also 14:40:23 #topic Handling Python modules SDK (asked by DylanVanAssche, 20 minutes ) 14:40:30 #info some details about the topic: Currently the Sailfish SDK can't handle Python packages and modules. A solution would be to allow the use of PIP to add those modules to the RPM of the application, almost the same way as the packages in the Jolla repo are handled for every target. When an RPM is build, PIP will automatically upgrade the Python modules to the latest version if available. Or allow PIP on the Saiflish OS devices 14:40:30 themself, it's installed by default but not allowed for Harbour apps. 14:41:58 you can already public Python packagers in Jolla store 14:42:07 upgrading global modules may break exiting modules. Wouldn't something like virtualenv be better? 14:42:07 *publish 14:42:10 virtualenv is the solution to this? 14:42:34 something with virtualenv would be great -> sandboxing every app 14:42:55 agree to sandboxing 14:43:00 I think this is really about easier bundling at package creation time & with the SDK 14:43:07 DylanVanAssche: sandboxing is a much better idea 14:43:09 using PIP at install time is not robust 14:43:29 * Sfiet_Konstantin think about something like docker 14:43:45 (fancy words for a sandboxing solution) 14:43:47 or wheels 14:43:49 Using PIP to bundle the modules when building the RPM 14:43:52 http://pythonwheels.com/ 14:43:52 yes it starts containerish indeed 14:44:11 virtualenv is more useful in development or server configurations - you can usually bundle other python modules within your app and just add the dir to the python path as part of the app initialisation? 14:44:33 #info at fosdem there is a discussion about the posibility of virtualenv as solution 14:44:53 stream died 14:44:57 yep 14:44:58 stream stopped 14:44:58 Oops 14:45:00 also, yes, wheels (as mentioned by dr_gogeta86) are likely useful :) 14:45:00 boom. 14:45:02 streaming down 14:45:06 sec 14:45:36 Python modules which need additional compiling or something else is not possible by just add them to the pro file 14:45:40 too many secrets ;-) 14:45:41 due to limitated storage and for avoiding to download the same packages several times, maybe some sort of pool could provide the packages and the app would just point what release it needs 14:45:42 virtualenv short term solution, flatpak or snaps long term solution 14:45:57 BTW, it would also help if you could add more packages for your application 14:45:58 right tad_, that's why it crashed... 14:46:07 like it's possible on OpenRepos 14:46:23 M4rtink +1 14:46:32 M4rtinK +1 14:46:36 like you would still have to package the stuff 14:46:42 right M4rtinK ! 14:46:57 or use packaging from somewhere else (Fedora/OpenSUSE) etc, 14:47:05 #info (sledges) we will come back in 2-3 weeks about packaging 14:47:11 but would not need to bundle everything 14:47:35 #info connectivity issues onsite 14:47:39 also there could be a pool (Nieldk ? ;-) )of such packages on OBS and you would just pick them to you application "repo" 14:48:04 I paused the time so far 14:48:24 elfio: would that imply some OS provided abstraction layer to manage to library dependencies 14:48:31 M4rtinK: that would make sense to me, just like most distros make it 14:48:47 default packages has the default name, olders append the release version 14:48:49 we are talking about how RPM packages are built at (eg) Fedora 14:49:05 and how we could transit from how we build at Mer to something similar to Fedora 14:49:18 SfietKonstantinW: is still a risk 14:49:32 for ex. i need an older one or a newer one 14:49:36 frankly 14:49:40 Sfiet_Konstantin: isn't fedora and opensuse discussing changing that as it is too painful for them 14:49:44 (personal opinion) I'm still not convinced about unbundling most of the stuff, and let apps to be able to bundle their deps 14:49:57 flatpak ... can heal but not solve 14:50:04 leszek: we are onl discussing about how to profit from Fedora / OpenSuse's work for Mer 14:50:25 #info problem at Mer is that we are lacking manpower to maintain all the packages we have 14:50:29 I think building a custom "embedded" distro is not needed anymore 14:50:39 I personally have the experience, that you can use other distro RPM packaging as a *starting* point, nothing else 14:50:43 yes, theses are the reasons that these container/sandboxing solutions are emerging 14:50:53 Sfiet_Konstantin: bundling deps is also possible if PIP or something else can handle the deps at build time for every target 14:50:57 I think every piece we can reuse from something existing is good for reduce workload 14:50:58 just base it no a major distro, add a mobile shell & maybe change some defaults 14:51:07 tbr: so profiting from them, ie using their SPEC would be out of question ? 14:51:08 tad_: I hope you're not trying to be an imposter of me 14:51:35 Sfiet_Konstantin: if you want to use fedora or opensuse packages, then you need to be opensuse or fedora. 14:51:51 tbr: I see 14:52:01 there's also a third way which is OE-based, like asteroidOS did 14:52:04 legally? 14:52:13 nemo-libhybris stack but OE 14:52:16 @tad__: Nope, coincidently. Even though I use this since around 1990. 14:52:25 tbr: really ? I don't think so 14:52:40 tbr: there are quite a few Fedora rebuilds 14:52:42 M4rtinK: it's a consequence 14:52:56 tad_: in this case: nice nick ;) 14:52:59 yes, but they are very close to whichever fedora they base on 14:53:12 you'll quickly run into dependency hell 14:53:13 @tad__: I think we know each other! Same full name. 14:53:46 why not trying to decrease the number of packages, and basically use flatpack like stuff (or docker or ...) 14:53:51 well, I'm talking about not using just a few packages - that might indeed be complicated 14:54:12 I mean just basing the whole thing of a distro with custom stuff on top 14:54:36 like I don't think Mer can beat the hundreds/thousands of Fedora packages for example 14:55:16 hell, you can even base it no CentOS it you want long term stability 14:55:29 yeah flatpak is the future. Though the base system with its runtimes needs compiling aswell and it would mean nothing else then asking the same question who should be responsible for the deps ? Pack them with the app or in a runtime ? 14:55:33 sure, but that'd be a hard cut transition. you'd need to rebase everything, just like e.g. asteroidsos 14:55:45 could be possible then to use Fedora repos as a base and with affordable amount of work adapt it for using in SFOS? 14:56:08 one discussion IRL happening now: how to ensure QA 14:56:18 stream up 14:56:21 will Jolla accept using Fedora / CentOS updates directly 14:56:23 Yiipieh 14:56:25 back :D 14:56:27 without any sort of QA ? 14:56:31 leszek: yeah, even flatpack apps need something to run on & the something needs security updates, etc. 14:57:00 darn 14:57:03 if people want to use $userspace from $distro, then the way is to essentially ship containers 14:57:04 gone 14:57:04 crashed ? 14:57:08 damnit xD 14:57:22 chroot into your container and you have what you want 14:57:33 well, containers do make a whole lot of sense on mobile devices 14:57:44 yep 14:57:50 true 14:57:52 but if you also want them to sandbox - that's hard to do correctly 14:57:53 do they really provide any advantage over plain ol' virtualenv in this case? 14:57:59 M4rtinK: how ? 14:58:04 How about snaps? https://snapcraft.io/ 14:58:05 of course every package essentially shipping its own distribution will not make them small 14:58:06 (for our intents and purposes) 14:58:17 Sfiet_Konstantin: so you don't cripple the apps 14:58:25 There's some buzz about them in the Ubuntu community.... 14:58:32 ha didnt know snaps, will take a look at this later 14:58:47 ced117: snap is essentially what ubuntu uses for their ubuntu phones 14:58:49 they are very ubuntu centric so far, although some ports have been done 14:58:55 M4rtinK: it shouldn't really ? 14:59:01 alright, will check that anyway Sfiet_Konstantin :) 14:59:06 pasko__: yeah snaps is almost exactly the same though snaps don't have dependency management thought out yet 14:59:07 just to know how that works 14:59:10 Sfiet_Konstantin: not used on current phones. They're for Ubuntu Core 14:59:17 faenil: really ? 14:59:29 systemd-nspawn? 14:59:39 :) 14:59:41 ha, it's developed by ubuntu 14:59:45 Sfiet_Konstantin: if you want to sandbox properly, you need to for example have system dialogs for file access 15:00:05 is this going too offtopic? 15:00:09 yeah and some other stuff that android does for permission management 15:00:14 Sfiet_Konstantin: and for example current Ubuntu Touch (click based) can only forward single file at a time to an app 15:00:16 M4rtinK: that's something different, but you can provide solution 15:00:20 leszek: ok snaps are at their infancy now, right? 15:00:26 think about dbus ? 15:00:28 Alright guys it seems that we can't get the stream back up so far 15:00:29 Sfiet_Konstantin: and they work on other distros too. 15:00:34 good look viewing photos from your camera uSD card 15:00:38 and the time on this topic is over. 15:00:39 that's sad 15:00:40 faenil: sorry, mixed snap & click 15:00:43 same thing for everything else 15:00:46 sure 15:00:51 (disclaimer: I work at Canonical, although not on snaps) 15:00:54 pasko__: basically yes. But so is flatpak and appimage 15:01:14 location, using system services, controlling the phone, accessing contacts, hardware 15:01:18 so no solution for including easily Python packages into apps atm? 15:01:23 we're stuck in a side argument at fosdem about sandboxing versus dep management 15:01:31 There is a specific track these days about Distro management 15:01:36 (just like on IRC ?) 15:01:38 :D 15:01:41 what's wrong with virtualenv? 15:01:42 I mean, "easy"-wise 15:01:42 Sfiet_Konstantin: isn't 20 minutes up? 15:01:43 ;) 15:01:47 yes 15:01:59 Stskeeps: Jaymzz_ did you restarted the timer ? 15:02:07 Moving on to the next topic. Apologies for the streaming issues 15:02:10 And the outlook in long term is ... we don't care we stuff crap on containers ... and every body happy 15:02:19 no problem, it happens sadly. 15:02:26 #topic Updating Mer Architecture diagrams at https://wiki.merproject.org/wiki/Architecture to the actual state. Current diagrams are very outdated (3-5 years old) (asked by coderus, 15 minutes) 15:02:28 tadzik: nothing. As I said best solution for the short term. long term we need something like snaps or flatpak. But I personally would say use the short term solution now and let the snaps and flatpaks of the world evolve 15:03:00 stream on 15:03:01 the topic did not come with additional info, as it is self explanatory 15:03:02 back online 15:03:08 stream back ? 15:03:14 yep 15:03:15 stream back 15:03:20 nope 15:03:23 nope 15:03:24 nope 15:03:25 down again :( 15:03:29 yep 15:03:31 this is crazy 15:03:32 takes 3 minutes :) 15:03:32 it lasted 10s ! 15:03:33 refreshed, and it works I think (?) 15:03:38 #info at fosdem Stskeeps says there has been some work done in the sailfishos wiki, that the ones on the mer wiki are extremely old 15:03:41 back again ? 15:03:41 up again 15:03:43 Guys could we please carry on with the topics? :) 15:03:49 youtube sucks! /me hides 15:03:51 Jaymzz_: +1 15:04:05 +1 15:04:06 #info Andrey Kozhevnikov, community, omprussia 15:04:13 and not going to get updated on my behalf 15:04:15 hi coderus ! 15:04:19 i tried refresh, it doesn't work 15:04:21 youtube is fucked up. mv /home/youtube /dev/null 15:04:24 Let's stop caring about the stream as the connection is terrible there, and carry on with the topics 15:04:27 hello coderus 15:04:39 sure Jaymzz_ :) 15:04:45 diagram is extremely useful to explain users and devs how mer is working, but its very outdated now 15:04:51 Hi coderus! The stage is yours :) 15:05:12 link us to new diagram? 15:05:19 https://sailfishos.org/wiki/Architecture ? 15:05:27 #link https://sailfishos.org/wiki/Architecture 15:05:30 don't know if it qualifies as a diagram since it is just layed blocks 15:05:32 Hi everybody 15:05:38 hello norsky 15:05:41 every architecture diagram is a lie 15:06:11 #info every architecture diagram is a lie 15:06:31 #link https://wiki.merproject.org/wiki/Architecture 15:06:33 this one 15:06:37 #info locusf says that the diagram would also likely be wrong due to the nemo middleware mer merge 2 years ago 15:06:49 coderus: we are talking about this one :) 15:06:57 for new contributers that can be great for understanding where to look. 15:06:58 and if this will be updated. The question is likely no 15:07:04 there are a lot of entries about X11 stuff and so 15:07:11 lplqAAlll 15:07:24 q 15:07:45 maybe someone from Jolla has something to say about the topic? is there any plan on it? 15:07:53 so, anyone who know about this stuff please feel free to say anything :) 15:08:13 the discussion in the room seems to be mostly “they cause more confusion than anything else” 15:08:28 Stskeeps is giving an example of a Tizen diagram, that says nothing about the stack 15:08:47 or we should make new from scratch 15:08:53 #info if there is any new documentation it will be clean on the sailifhos wiki 15:08:57 ah, it was not tizen but https://it.wikipedia.org/wiki/File:Bada_architecture.png 15:09:01 bada 15:09:03 I can probably produce something using the follow up software to agile browser. the graphics will be huge and inaccurate, just as Stskeeps said 15:09:04 ah Bada : 15:09:05 :D 15:09:08 :D 15:09:14 that would be limited to mer:core 15:09:26 that seems silly. if the diagrams aren't useful, make them useful/accurate. 15:09:50 useful and accurate are mutually exclusive in this case 15:10:26 Robbster: are you volunteering? 15:10:27 But you're not thinking about not doing new diagrams, ru? 15:10:29 I think the architecture blocks on the sailfishos.org wiki site is enough as a starting point 15:10:49 tbr: would be great to understand how to generate incoming data 15:10:56 then we can think how to make better diagrams 15:11:02 add a little color to them and it looks good 15:11:07 5 minutes left guys. 15:11:21 color is key in any visual information/diagram 15:11:43 AL13N_jolla_: no knowledge, sadly. 15:11:59 idea IRL: keep improving a digram when question arises 15:12:14 so that it can organically grow to an accurate and useful diagram 15:12:27 coderus: there are scripts that process the XML data of the rpm repositories and can then be digested by AgileBrowser (both are not easy to find, e.g. on the gitorious archive) 15:12:34 or add a nice little tux logo besides the kernel to make it look more sweet 15:13:15 tbr: thats okay, let me know what to search 15:13:17 something like that: https://neptuneos.com/files/NeptuneOS/Article/neptune-structure-202x300.png 15:13:23 if the information is better in the sailfishos wiki then the stuff in mer should be removed? 15:13:32 coderus: poke me next week, I'll give you hints 15:13:34 :D 15:13:44 #info there are scripts that process the XML data of the rpm repositories and can then be digested by AgileBrowser (both are not easy to find, e.g. on the gitorious archive) 15:13:46 tbr: roger 15:14:02 coderus are we done with your topic soon? :) 15:14:12 Jaymzz_: yes thanks 15:14:18 Alright moving on! 15:14:31 #topic PGP/MIME and the Mail App (Asked by kat6, 15 min) 15:14:41 #info some details about the topic: Currently, the mail app doesn't handle encrypted content. Damien Caliste seems to be working on it, but in the meanwhile, can something be done so as to enable downloading the encrypted content as an attachment? Then one can easily decrypt using GnuPG. What is the feasibility of this? 15:14:43 we are discussing a bit IRL about duplication of info 15:14:50 (mer / SFOS wiki) 15:15:36 +1 mails should be downloadable as txt files (or even viewable) 15:15:46 this is a reply in the SFOS ML 15:15:48 I think the encrypted part of an email is already available from command line. QMF is saving already decoded the various part of a multipart email in .qmf/mail. Doing a ll -rt there gives the latest received emails and the parts are in a subdirectory. Then it can be copied by ssh or directly decoded in fingerterm. It is simpler imho than proposing the encrypted file in the UI where anyway one cannot do anything with it 15:15:49 even not save it somewhere. 15:16:24 #info I think the encrypted part of an email is already available from command line. QMF is saving already decoded the various part of a multipart email in .qmf/mail. Doing a ll -rt there gives the latest received emails and the parts are in a subdirectory. Then it can be copied by ssh or directly decoded in fingerterm. It is simpler imho than proposing the encrypted file in the UI where anyway one 15:16:30 cannot do anything with it even not save it somewhere 15:16:33 #info cannot do anything with it even not save it somewhere 15:16:44 Damien Calliste sadly can't be here today 15:17:03 (what is qmf?)_ 15:17:11 tadzik: QMF is the Qt messenging framework 15:17:16 thanks 15:17:28 actually it is what handles mails in Mer+Nemo side 15:17:40 and jolla-email is simply a GUI front-end for QMF 15:17:54 Entry for CC http://talk.maemo.org/showpost.php?p=1522621&postcount=85 15:18:06 #link http://talk.maemo.org/showpost.php?p=1522621&postcount=85 15:18:13 #link http://talk.maemo.org/showpost.php?p=1522621&postcount=85 15:18:23 snap! :D 15:18:30 haha no problem :D 15:18:30 jolla-email has far more serious problems than encryption :/ 15:18:40 ApBBB: :D 15:18:48 ApBBB: +1 15:18:52 tell us more ApBBB 15:18:54 is QMF in mer? 15:19:04 I guess, based on Damien's app, we can do something better (if we wanted) 15:19:06 AL13N_jolla_: yes 15:19:34 sec, searchign for a link 15:19:49 my main issue is mails being late when it is set to be always up to date. no matter connection (wifi - mobile data). 15:20:11 #link https://git.merproject.org/mer-core/messagingframework 15:20:13 QMF link 15:20:26 ApBBB: using imap idle ? Because that works fine for me 15:20:46 ApBBB: works fine for me with GMail at least, phone usually vibrates before the mail even appears in the browser interface :) 15:21:09 not on private servers 15:21:11 yep. gmail as normal email. reported on tjc long time ago 15:21:21 my problem with jolla-email: emails deleted/moved from one folder with another imap client don't disappear from that folder ondevice 15:21:21 #info there was a push notification solution written by tbr, a tech PoC which works 15:21:48 10 minutes left on this :) 15:21:48 ApBBB: leszek :What about mail for exchange, there is also a problem with sync. 15:22:05 #info MQTT https://github.com/dm8tbr/irssi-mqtt-sailfish.git 15:22:11 don't know don't use exchange 15:22:26 #link https://github.com/dm8tbr/irssi-mqtt-sailfish.git 15:22:34 alias support for mail would be great 15:22:34 tadzik: i agree. recognizing moves would be good 15:22:47 #info that is a technology demonstration! 15:22:47 tadzik: I have the same problem with a private server 15:22:54 BearT: I'd use the word "essential" ;) 15:23:02 question IRL: who can live without push notifications 15:23:04 #info it would require significant work to be usable in general 15:23:04 tbr: temporary solutions are the most permanent ones 15:23:05 :P 15:23:09 and many people said that they can live without it 15:23:13 honestly I don't think I even reported it (or checked that it's reported), I just assumed that mobile email clients are shit and there's nothing in the world that'll ever change that 15:23:15 a straw poll at fosdem of users here say they can live without push notifications in email 15:23:19 Stskeeps: that's true 15:23:19 (presented without comment) 15:23:31 Stskeeps: well it was "enough for me" and there was no interest, so I stuck with it, sure 15:23:35 mail for exchange works until there is not too much item to sync 15:23:55 tadzik: thats not true. I have a blackberry and this is best messaging ever 15:24:00 tadzik: i got used to double delete my mails, though most of it is anyway not visible to mail app (moved to subfolder before it reaches the phone) 15:24:08 leszek: ah, I never used one 15:24:26 BearT: yeah, I stopped syncing jolla-email automatically whatsoever 15:24:39 and I only sync it manually when I need a boarding pass or someshing 15:25:23 same here 15:25:27 the stream works again, for now. 15:25:32 could we stick to the topic? 15:25:48 elfio: +1 15:25:50 current IRL topic: things that are shit about jolla-email ;) 15:26:06 tadzik: oh, my bad ;) 15:26:17 currently: deleting emails manually as a 5-line script 15:26:33 but now, you can follow the stream :) 15:26:53 * Robbster gets popcorn 15:27:05 just a couple of minutes left on this topic, are we almost done? 15:27:06 any more questions/suggestions on topic? 15:27:07 Jaymzz_: how many time left on the topic ? 15:27:12 exchange works fine for me, only sending large attachments timeouts too easy 15:27:18 Sfiet_Konstantin: just said it xD 15:27:30 Jaymzz_: bad timing 15:27:46 also the email needs a redesign 15:27:50 haha, so I assume we're moving on? 15:27:52 I use my Jolla for buisines and private mail. active sync and imap via push works there okay. i wish there would be an auto-update for subfolder und alias function 15:27:53 UI wise 15:28:07 tbr would like to talk about 'what is the state of mer core and where should it go' in All Other Business 15:28:11 I'll give it 3 more minutes (as it's left) 15:28:37 stephg: Do I make it a topic? 15:29:00 yeah 15:29:21 @kimmoli yes, but by my side when I've a lots of unread email to sync, sync never go through the end 15:29:24 #topic what is the state of mer core and where should it go 15:29:35 info tbr: jolla has been very careful to maintain a backwards compatible distro 15:29:38 This is being talked about live on FOSDEM: https://www.youtube.com/watch?v=gpABm5T7wMM 15:29:38 #info tbr: jolla has been very careful to maintain a backwards compatible distro 15:29:48 #info This is being talked about live on FOSDEM: https://www.youtube.com/watch?v=gpABm5T7wMM 15:29:56 and then relayed an anecdote about difficulties he had rebuilding/upgrading himself 15:30:08 What is wrong with mail for exchange support ? 15:30:12 he asks: do we update gcc, do we update glibc, what is the directiom? 15:31:01 #info sledges jolla is going to open all of the webhooks and such that they use for the mer portion of sfos 15:31:33 discussion moves to a mer-devel/mer-next 15:31:53 (is the topic of enabling the use of jolla-made qml components (camera etc) available to apps still upcoming?) 15:31:55 now the talk is about binary compatibility troubles about upgrades (of gcc etc) 15:31:56 #info Stskeeps in general binary compatability isn't a problem 15:32:27 #typically upgrading glibc or gcc isn't a problem for bin compat, but packages tend to stop building 15:32:40 #info there is also the problem of GPLv3 license changes with some packages 15:32:53 Stskeeps: please say "cute" not cutie :D 15:32:55 stephg: #typically :D 15:33:09