Thursday, 2018-07-26

NeoChapaylbt: add plz to mer-core
abransonNeoChapay: looks GPL3/commercial license. those sorts of things can't be included in Mer.07:21
*** frinring_ is now known as frinring07:39
NeoChapayabranson: oh.....08:15
r0kk3rzit might be nice to have a non-core place in mer for gplv3 stuff08:31
Nokius_pcnot sure if you have good spot for it, location wise08:34
abransonhome's quite good:
Nokius_pcKazan is much better let's visit omp :DD08:35
Nokius_pcyeah let's home there are now clouds and the moon will hide :(08:35
r0kk3rzdamn sneeky moon08:36
* Nokius_pc falcepam wrong window sorry for the noise 08:38
Nokius_pcgood day everyone :)08:39
r0kk3rzmoo Nokius :)08:40
NeoChapayNokius: you going to kazan O_o ?08:44
r0kk3rzbig OMP party!08:45
coderusabranson: wtf? Mer is open and could contain anything we want! If you don't want to include something in sfos device firmware - just don't. But please don't try to stop foss.09:02
r0kk3rzit could go into mer-contrib09:06
abransoncoderus: i disagree. unless there's some automatic and infallible way to check dependencies to make sure gplv3 doesn't end up in firmware, then I think mer, as a mobile OS intended for uses that might not be able to support gplv3, should avoid such components and find alternatives. mixing in v3 alternatives in the core repo will end up causing problems. I think a separate repo is a good idea though.09:21
abransoni don't think it's correct to say that being anti-gplv3 is being anti-foss either. gplv3 is quite restraining, which is the opposite of free.09:22
abranson(my opinions btw, this isn't my call)09:22
coderusabranson: image is never build using random binaries. this problem is imager/infra/e.g. task, and it should never block development.09:52
abransoncoderus: not random, but dependencies are very complicated and a seemingly innocuous provides could end up pulling in the wrong stuff, especially if it's in the same package09:59
abransonthe gplv3 stuff has been a problem, and influencing development for several years. legal risks shouldn't be taken just so everything can be in one repo. separation is the way to go10:01
coderusabranson: nah nah nah. if i add some new package, no deal, nothing in base image require it.10:09
abransoncoderus: and how do you make sure that it never gets included by accident?10:10
coderusabranson: omg, there are a lot of QA engineers around. rpm -qa --qf %{LICENSE} | grep GPLv310:10
coderusabranson: if you want GPL2 only Mer, you should fork it and use outdated branches, no big deal. But please do not harm to others.10:11
abransoncoderus: it's not about outdated branches, it's often about using alternative packages.10:14
abransonyou're not saying anything against the separate repo approach10:14
coderusmer-core:gpl3 is okay for me11:07
malNeoChapay: just curious, what is the benefit of qtdeclarative-render2d ?11:09
NeoChapaymal: software rendering of qml11:42
NeoChapaymal: if i use spi displays and etc i can use qml without qtdeclarative-render2d11:43
NeoChapaymal: needed for this11:43
malok, is it a common case to use software rendering instead of hw accelerated11:48
malNeoChapay: hmm, shouldn't that kind of things belong to device adaptation, not to everyone? that is not a build requirement so I think it could stay in device adaptation repo, or optionally the config as a separate package11:51
maloh, misread the PR, it seems to be in a separate package11:51
malsorry about that11:51
NeoChapaymal: i just whant add nemo-sessions-render2d is ks file and know - all dependendends will be installed12:05
malyes, I somehow missed the new package name12:07
lbtcoderus: for the record Mer has always been about making it easy for commercial entities to make devices based on OSS software. We know that including GPLv3 adds a layer of difficulty so we don't include GPLv3 stuff unless there's a really pressing reason. We also strive to be minimal. Packages are added when a feature really needs them. Eg Recently we considered adding openldap but were able to avoid that by ./configuring and patching the requiring12:44
lbtpackage to not need it. ie we work hard to *avoid* adding packages to mer-core. Our policy is that the default answer is "no" - there has to be a good justification12:44
coderuslbt: there are a lot of packages in repos not used bu build/etc, like tools e.g. accessible to install via default repos12:47
coderuslbt: so i tried, but dont really see your point12:47
lbt2 points. mer-core tends not to use GPLv3. mer-core tries not to add packages without a good reason.12:50
lbtAs you say - it often makes sense to add them to tools or HA or somewhere else12:50
coderusso, if not mer-core, can we have separate repo and obs project for random libs/tools with possible gplv3?12:51
lbtof course - that's what home:* is for :)12:52
Venemomal: about your render2d question: it is part of Qt in later versions, but used to be a separate package earlier.13:19
Venemomal: its point is to make QML apps usable on old machines that don't have a respectable GPU. for example we had good success with it on a very old Intel Atom netbook which didn't have hardware acceleration on linux13:20
Nokius_NeoChapay: nope sorry,noplans in near future :(15:23
abransonVenemo: when was it included in Qt?16:27
Venemoabranson: see
Venemoabranson: short answer is 5.8, and it's been even relicensed to match QtDeclarative16:31
malwouldn't that mean the new repo is not really needed as it would only be a temporary solution because Qt 5.9 update is coming soon-ish16:49
*** Nokius_ is now known as Nokius18:39

Generated by 2.14.0 by Marius Gedminas - find it at!