[01:05] <GunnarHj> doko: Whatever the reason was for the l-s build failure a few hours ago, it has made it now, so you can disregard my question above.
[05:07] <hrob> hi
[05:08] <hrob> I see very old bug reports about ubuntu crashing when creating new master pointer devices...  yet  xinput2 has been around for 5 or more years.
[05:09] <hrob> I need a little help around Ubuntu's support for Wacom only... and also how Ubuntu has been crashing when creating a second master input device.
[05:09] <hrob> I'm wondering what I can do to get things going on these two fronts.
[05:11] <hrob> so, the first issue... there are many competing pen taplet/screen/touch brands out there,  yet the Ubuntu config menu specifically rejects any brand that isn't "Wacom"
[05:11] <hrob> this is super strange... considering that the other brands. such as  Yiyama  together with  Wacom/Cintiq   use the usb input devices standard.... so... its like an ISO standard here. fully supperted already by xorg xinput
[05:12] <hrob> yet... the tablet config menu ... not so aptly named "Wacom" ... rejects my non wacom pen device...    xinput does not... it sees it and says hello
[05:13] <hrob> I've had to go out of my way and develop a more general config app that supports both.... http://wenhsinjen.github.io/ptxconf/
[05:13] <hrob> it talks with xinput
[05:14] <hrob> Now,  should I continue on this path... or is it easier just to change the name of the Ubuntu wacom config dialog too... pen and tablet config dialog?
[05:29] <hrob> hello
[05:34] <hrobjartur> hello
[05:38] <hrobjartur>  does anyone know the motivation for Ubuntu ignoring other usb input devices "ISO" compliant devices?
[05:39] <hrobjartur> Ok so in the ubuntu config panel there is a trademark name "Wacom"
[05:39] <hrobjartur> I meant
[05:39] <hrobjartur> instead of saying "pen device/touch device" config it says "wacom" config
[05:39] <hrobjartur> and the config rejects any input mode absolute pointing device that isn't with manufacturer Wacom.
[05:40] <hrobjartur> not good code re-usability there -- should I develop my own xinput configurator ?    seems pointless, unless Wacom is sponsoring Ubuntu not to reject other pen devices
[05:41] <hrobjartur> *to reject
[05:59]  * tsimonq2 is gone: 
[06:35] <amigaguru> hi
[06:36]  * amigaguru greets everybody politely
[06:46] <amigaguru> @all: you heard of Amiga?
[06:46] <udevbot> Error: "all:" is not a valid command.
[06:46] <amigaguru> lol
[07:25] <pitti> Good morning
[07:26] <pitti> hallyn: thanks for the patch, will look at it right now
[07:34] <lpotter> my first computer was an amiga 500
[07:37] <amigaguru> my too
[07:39] <amigaguru> err sorry. my first computer was a Dragon 32
[07:42] <pitti> hallyn: hm, this doesn't yet seem to suffice in my tests
[07:45] <pitti> hallyn: and the original code looks right (the non-inverted condition)
[08:09] <pitti> hallyn: hah, got it
[08:15] <hallyn> pitti: you fixed my broken patch? :)  +1  (though my patch *did* work fo rme for libvirt, but i assumed it couldn't be so simple)
[08:19] <pitti> hallyn: wow, I actually don't see how it could have worked
[08:20] <pitti> hallyn: xenial fix uploaded and bug updated.
[08:22] <pitti> hallyn: sorry, I didn't realize the double calling of dh_s_s on Friday night..
[08:23]  * pitti preps the wily SRU
[08:24] <smb> more libvirt fun... note to myself to check for cdbs in other pkgs too
[08:26] <hallyn> pitti: oh - yeah.  i had noticed the two stanzas
[08:27] <amigaguru> exibel
[08:29] <hallyn> pitti: thanks!
[08:29]  * hallyn -> bed
[08:31] <pitti> hallyn: good night!
[09:31] <ginggs> pitti: morning!  [08:43:45] <tumbleweed> d!oko: cffi got caught up in your python3.4-dropping. packages are building without 3.4 in proposed, but the adt tests are expecting 3.4, because they're using the old -defaults
[10:05] <jamespage> pitti, good morning - I was chatting with stgraber last week about the correct way to detect whether something is running in-container or not - for upstart/14.04 we have /run/container_type - is the same applicable for 16.04?
[10:06] <pitti> ginggs: ack, re-running with p3-defaults from -proposed
[10:06] <xnox> Odd_Bloke, http://www.redmine.org/issues/5880#change-68618 =)
[10:06] <pitti> jamespage: no, that's upstart specific
[10:07] <pitti> jamespage: please use systemd-detect-virt --container
[10:08] <Laney> not running-in-container?
[10:08] <pitti> that's also an ubuntu-ism
[10:09] <pitti> and systemd-detect-virt works under sysv and upstart too
[10:10] <Laney> hah
[10:10] <Laney> interesting name
[10:13] <ginggs> pitti: thanks!
[10:14] <Laney> ginggs: hey, do you know if https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/d/dbus-test-runner/20160115_172614@/log.gz is caused by the new pcre3?
[10:16] <ginggs> Laney: it could be, that was run against the old pcre3.  can we try run it against the new pcre3?
[10:18] <Laney> hmm this is perl itself
[10:18] <Laney> yeah it's probably the perl update
[10:18] <Laney> nm
[11:11] <ancaemanuel> jdstrand: https://bugs.launchpad.net/ubuntu/+source/lz4/+bug/1531923 for http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#apt please ?
[11:12] <ancaemanuel> or anybody else ?
[11:42] <alkisg> Hi, https://launchpad.net/ubuntu/+source/adobe-flashplugin/+changelog says "NPAPI: 11.2.202.559" yet the flash player about site says 11.2.202.554, and firefox complains that flash is out of date
[11:43] <alkisg> chrisccoulson: would that be a bad installation on my behalf, or is it possible that the last adobe-flashplugin has the wrong NPAPI version installed?
[11:43]  * alkisg checks more...
[11:46] <alkisg> Hmm no sorry, my version 1:20151208.1-0ubuntu1 is too old even though I've dist-upgraded, checking what went wrong with the updates.
[11:47] <alkisg> Nope that's the latest version for 16.04
[11:47] <alkisg> chrisccoulson: as far as I can see, adobe-flashplugin 1:20151228.1-0ubuntu1 claims to have NPAPI: 11.2.202.559 but has .554
[11:48] <ricotz> alkisg, are you using -proposed?
[11:49] <alkisg> No
[11:49] <ricotz> "1:20151228.1-0ubuntu1 	proposed (partner) 	2015-12-28" claims to be still in the partner-proposed pocket
[11:50] <teward> which i just said in #ubuntu+1 where this ended crossposted
[11:50] <alkisg> Hmmm let me investigate how I ended up with that adobe-flashplugin version, without having -proposed, and with the wrong flash inside it
[11:51] <alkisg> I'll look at apt logs
[11:53] <alkisg> OK bad eyes. The version numbers are different, 1208 vs 1228.
[11:53] <alkisg> It's been in proposed for 20 days though, and no versions show up in the partner repository... is there something blocking it?
[11:57]  * alkisg enabled the partner-proposed repository and everything is good again, thank you guys...
[11:58] <doko> xnox, do you keep a list of s390x porting stuff?
[12:01] <xnox> doko, elaborate? there is a report of things that have never built on s390x yet (in launchpad that is)
[12:01] <xnox> doko, http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/primary-xenial-s390x-release.html
[12:02] <xnox> doko, i am working on those things. But e.g. from main i ahve only opencryptoki (in progress) and openvswitch to get done. I'm ignoring the rest of main packages, as they are desktop only. and then universe.
[12:02] <xnox> doko, is there something in particular you are after?
[12:02] <doko> xnox, well I thought instead of fiddling around with mpich, maybe better port openmpi
[12:03] <xnox> doko, .... haha =) it's listed as unported in like fedora and suse. so i guess nobody cares to port it =)
[12:03] <doko> should be a handful of assembler lines and using the GCC atomics
[12:04] <xnox> doko, on my list of priorities it's all the way down with the "build freepascal cross compiler, to bootstrap freepascal on arm64 and ppc64el" =)
[12:04] <xnox> doko, hm, sounds interesting. it would be nice indeed to have openmpi.
[12:04] <doko> xnox, fpc is done for arm64, and works on the trunk on ppc64el
[12:04] <Laney> doko doesn't mess around when it comes to pascal
[12:05] <doko> Laney, well, I tried to backport the trunk fpc to 3.0 for ppc64el, but then lost interest
[12:06] <Laney> you monster
[12:06] <cjwatson> fpc is done?  oh, experimental only
[12:07] <doko> yep
[12:08]  * xnox knows how to derail a conversation
[12:08] <teward> heh
[12:14] <ogra_> are there actually still people that use pascal (beyond for academic and teaching purposes) ?
[12:26] <xnox> ogra_, as far as i can tell dephi and/or kylix are dead as far as I can tell, and i guess that's the end of objective pascal....
[12:26] <ogra_> yeah
[12:28] <rbasak> I hear about legacy projects that are still maintained from time to time.
[12:29] <ancaemanuel> @Michael Hudson-Doyle: \o/ https://lists.ubuntu.com/archives/xenial-changes/2016-January/005020.html GO go !
[12:29] <udevbot> Error: "Michael" is not a valid command.
[12:32] <ancaemanuel> ^ Updates for s390x support, for golang \o/
[12:34] <ancaemanuel> that means juju people have some work to do...
[12:41] <cjwatson> doko: OK, will do
[12:41] <cjwatson> err, echan
[12:53] <ancaemanuel> freepascal is more important than apt ?!?
[12:53] <cjwatson> ancaemanuel: huh?
[12:54] <ancaemanuel> https://bugs.launchpad.net/ubuntu/+source/lz4/+bug/1531923 for http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#apt please ?
[12:54] <cjwatson> I don't know how on earth you get from there to "more important than apt"
[12:55] <cjwatson> there is not a single linear to-do list for all developers
[12:55] <ancaemanuel> I sent the same message several hours ago
[12:56] <ancaemanuel> no answer
[12:56] <cjwatson> ancaemanuel: and the person it's assigned to is likely asleep right now
[12:56] <cjwatson> the world is inconveniently spheroid
[12:57] <cjwatson> it makes more sense to wait for them to wake up in order to find out how far along they are, rather than potentially duplicating work
[12:57] <ancaemanuel> ok, thanks
[13:01] <LocutusOfBorg> good morning ubuntu developers
[13:02]  * LocutusOfBorg for a very strange meaning of "morning"
[13:02] <LocutusOfBorg> I did upload libsdl2_2.0.4 on debian experimental, and I would like to know your opinion about a sync
[13:03] <LocutusOfBorg> it changed API/ABI, but upstream convinced us that the changes are still ABI safe (and if something segfaults, it's because they are using the library in a wrong way)
[13:03] <LocutusOfBorg> so I didn't bump soname
[13:03] <LocutusOfBorg> https://lists.alioth.debian.org/pipermail/pkg-sdl-maintainers/2016-January/thread.html
[13:03] <LocutusOfBorg> the rationale is there ^^^
[13:03] <LocutusOfBorg> how do you feel about a sync from experimental or unstable (I plan to test reverse dependencies a week or two and then go for unstable)
[13:04] <LocutusOfBorg> s/sync/merge
[13:04]  * ogra_ guesses you should ask the same in #ubuntu-mir 
[13:27] <sil2100> pitti, cjwatson: hey guys! Do you remember how the translations work for the overlay PPA? We're using ubuntu-rtm/15.04 for the translations there, but we were wondering if uploads to the overlay PPA are scanned, or is there some assumption that we land the same thing to the development series?
[13:28] <sil2100> pitti, cjwatson: e.g. is an upload to overlay-ppa only enough for launchpad to do its work?
[13:30] <cjwatson> sil2100: uploads to the overlay PPA have their translations magically redirected to the ubuntu-rtm/15.04 series
[13:30] <sil2100> seb128: ^
[13:30] <cjwatson> uploads to vivid in that PPA, anyway
[13:30] <sil2100> seb128: so it's as I thought, some workaround is done
[13:31] <sil2100> cjwatson: thanks
[13:31] <seb128> ok, I don't know why it's not working then
[13:31] <cjwatson> see https://git.launchpad.net/launchpad/tree/lib/lp/archivepublisher/rosetta_translations.py
[13:32] <seb128> cjwatson, the template from https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay/+sourcepub/5961354/+listing-archive-extra wasn't imported
[13:32] <seb128> but now I manually uploaded it so that might have changed the state to be able to debug
[13:32] <seb128> cjwatson, should those import show on e.g https://translations.launchpad.net/ubuntu-rtm/15.04/+source/trust-store/+imports ?
[13:47] <cjwatson> seb128: That upload doesn't appear to have built a _translations.tar.gz, so nothing to import
[13:47] <cjwatson> seb128: see the build logs
[13:53] <seb128> cjwatson, hum, right ... do you know why? pkgstriptranslations is used and the package is in main
[13:53] <seb128> pitti, ^
[13:56] <cjwatson> seb128: because it's a build in a non-virtual PPA, so tries to behave like the primary archive, and that package is in universe in the primary archive for vivid.  Adding X-Ubuntu-Use-Langpack: yes to debian/control would fix it
[13:56] <seb128> cjwatson, oh ok, I looked at the package for xenial, thanks!
[13:57] <cjwatson> np.  took me way too long to spot that :)
[13:58] <seb128> well at least you did figure it out ;-)
[14:15] <Laney> doko: any chance you could look at why http://autopkgtest.ubuntu.com/packages/u/ubuntu-sso-client/xenial/i386/ started failing?
[14:15] <Laney> the package itself didn't change
[14:17] <Laney> pitti: ...and do you know anything about udisks2/ppc64el or upstart? :)
[14:18]  * Laney goes to lunch it up
[14:19] <pitti> seb128: looking
[14:19] <seb128> pitti, unping
[14:19] <pitti> sorry, I ignored IRC while handling moving files in essential packages, that needed some attention :)
[14:19] <seb128> pitti, the package was in universe in vivid
[14:19] <seb128> Colin figured it out
[14:19] <pitti> seb128: oh, good
[14:21] <pitti> Laney: TBH I even have trouble finding the failed test in upstart log
[14:22] <pitti> not ok 26 - with single-line script that is killed
[14:22] <pitti> wrong value for WIFSIGNALED (status), expected TRUE got FALSE
[14:22] <pitti> at tests/test_job_process.c:1760 (test_start).
[14:22] <pitti> ah, here we are
[14:23] <pitti> Laney: no clue, but it started failing before glib, so I'm fine with badtesting it
[14:28] <ricotz> hi, as a reminder https://bugs.launchpad.net/ubuntu/+source/gettext/+bug/1532799
[14:37] <pitti> Laney: so the dbus-test-runner regression "Unescaped left brace in regex is deprecated", that's prce, not glib, right?
[14:37] <cjwatson> that's a new warning from perl 5.22
[14:38] <cjwatson> https://bugs.launchpad.net/intltool/+bug/1490906
[14:38] <pitti> ah right; still, not glib, so I'm force-skiptesting, the rest looks unrelated
[14:38] <cjwatson> dobey might be able to look at that perhaps?
[14:41] <ricotz> the mentioned gettext update also includes a perl 5.22 fix for texi2html
[14:59] <ancaemanuel> @piti, how is possible to run for more than 24 hours on armhf on autopkgtest for apache2 ?
[14:59] <udevbot> Error: "piti," is not a valid command.
[15:00] <ancaemanuel> unnoticed ?
[15:02] <ancaemanuel> piti: ? ^
[15:04] <cjwatson> people's highlights usually work better if you spell their nicks correctly :)
[15:04] <cjwatson> tab-completion helps
[15:05] <pitti> ancaemanuel: that's an lxc bug in xenial, I killed them earlier today
[15:05] <pitti> and fixed adt-run to properly time out on a hanging lxc-stop
[15:06] <ancaemanuel> oh,
[15:12] <ancaemanuel> this one: http://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/commit/?id=9008c6f285bcfa6c4f8f6cf172497116042307db ?
[15:12] <pitti> ancaemanuel: right
[15:21] <ancaemanuel> thanks, pitti, waching now http://autopkgtest.ubuntu.com/running.shtml
[15:23] <ancaemanuel> pitti, is there anything to speed up apt ( see messages above )
[15:24] <pitti> ancaemanuel: apt isn't even running ATM?
[15:24] <pitti> ancaemanuel: but I speed it up as much as possible -- I disable translations, foreign arches, set dpkg unsafe IO and run through eatmydata
[15:24] <ancaemanuel> it needs lz4
[15:24] <cjwatson> pitti: ancaemanuel is talking about https://bugs.launchpad.net/ubuntu/+source/lz4/+bug/1531923, which requires somebody in ~ubuntu-mir to handle it
[15:25] <ancaemanuel> in main
[15:25] <cjwatson> i.e. neither you nor I :)
[15:25] <pitti> ancaemanuel: ah, you mean https://launchpad.net/ubuntu/+source/apt/1.2 doesn't build
[15:25] <pitti> (nothing to do with tests)
[15:25] <pitti> ancaemanuel: right, needs MIR team
[15:26] <ancaemanuel> https://bugs.launchpad.net/ubuntu/+source/lz4/+bug/1531923 for http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#apt please ?
[15:27] <ancaemanuel> I repeated this the #3 time now
[15:28] <Odd_Bloke> !regression-alert
[15:28] <cjwatson> yes, and you still haven't waited long enough for the person it's assigned to to be clearly within their working hours
[15:28] <cjwatson> patience!
[15:28] <Odd_Bloke> https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/1535349
[15:28] <Odd_Bloke> Oh, that's an exciting list of people to ping.
[15:29] <cjwatson> Odd_Bloke: it's been in trusty-updates for a month, so I shouldn't think that blacklisting it from the archive is appropriate at this point
[15:30] <cjwatson> chiluk prepared the upload and mterry/cyphermox sponsored it, so perhaps they can look
[15:31]  * mterry looks up
[15:31] <Odd_Bloke> cjwatson: Yeah, agreed.  (The SRU wiki page doesn't make it clear what will happen when you do !regression-alert; I would probably have been a bit more chill if I'd realised it would ping all the people ^_^)
[15:32] <mterry> chiluk, ^
[15:32] <cyphermox> indeed that's very broken
[15:33] <mterry> Odd_Bloke, ok, assigned bug to chiluk and opened a trusty task
[15:35] <Odd_Bloke> mterry: Great, thanks. :)
[15:43] <Laney> pitti: I handled the regex one already
[15:43] <Laney> just those three I pinged about
[15:44] <Laney> I mean sure we could badtest things, but ...
[15:46] <ogra_> pitti, do you have an idea whyx systemd always grabs the last option from the kernel commandline and appends it to init ?
[15:46] <ogra_> i.e.:     1 ?        Ss     2:32 /lib/systemd/systemd fixrtc
[15:47] <pitti> ogra_: not off the back of my hand, but supposedly to do something like "single", like the old runlevels?
[15:47] <ogra_> (it doesnt do harm indeed, but its like an itch i cant scratch :P )
[15:51] <Laney> like obviously something changed to break ubuntu-sso-client build
[15:52] <Laney> I was happy to take the pain until we find out what that is
[16:10] <pitti> hallyn: with schroot I now get tons of "call to remove-on-empty (freezer:0) failed: invalid request"; is that due to the new libpam-cgm cgroup?
[16:19] <ginggs> where do i report a gcc internal compiler error? package ncbi-tools6, only happens in arm64 build, package built fine in debian
[16:21] <xnox> pitti, can you retrigger golang-github-gorilla-handlers autopkgtest with golang as a trigger?
[16:21] <xnox> pitti, or is there a way for me to do that?
[16:22] <pitti> xnox: with both gorilla and golang; done
[16:22] <pitti> xnox: no, not at the moment
[16:22] <pitti> xnox: only folks with snakefruit access
[16:38] <mdeslaur> infinity: I've filed bug 1535379 to get refpolicy removed from xenial. What team do I need to subscribe to that bug?
[16:39] <rbasak> mdeslaur: ~ubuntu-archive usually, or should this be an exception?
[16:39] <mdeslaur> rbasak: ok, thanks
[16:45] <chiluk> Odd_Bloke, cjwatson, mterry re: coreutils bug, I'll take a look tomorrow.  Xenial appears to have the correct behavior so hopefully the diff is not too great. I'll take a closer look tomorrow when I'm fully back from holiday
[16:47] <Odd_Bloke> chiluk: Thanks!
[17:05] <tumbleweed> pitti: didn't seem to have any effect on s390x. (python-cffi)
[17:13] <hallyn> pitti: it is - it's fixed in the new (ubuntu4) version;  did that not pass proosed yet?
[17:14] <hallyn> pitti: no, it got promoted - can you check if you still get it with the upgrade?
[18:53] <tkamppeter> Anyone around who can help me on a buildds problem? https://launchpad.net/ubuntu/+source/cups/2.1.2-2 It says that cups-filters (> 1.0.38~) is not going to be installed.
[18:57] <cjwatson> tkamppeter: root cause is that liblouisutdml needs an MIR
[19:45] <mjeanson> cking: I'm using zfsutils-linux on xenial, the package "Replaces" and "Conflicts" with zfs but does not "Provides" so I can't install packages that depends on zfs, would it be possible to add it?
[19:54] <cking> mjeanson, sure, please file a bug so I can track this and I'll get around to it this week
[19:59] <mjeanson> cking: thanks, here you go : https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/1535428
[20:07] <cking> mjeanson, thanks!
[20:19] <allizom> which repository should patent-encumbered FLOSS software not officially supported by the Ubuntu team be packaged into? universe or multiverse?
[20:26] <Pharaoh_Atem> allizom: multiverse
[20:27] <allizom> thanks Pharaoh_Atem, why x264, lame and other software are in universe then?
[20:28] <Pharaoh_Atem> allizom: because universe technically maps to debian's main repos, while multiverse maps to nonfree and contrib
[20:29] <Pharaoh_Atem> universe and multiverse are filled out by importing from the corresponding debian repos
[20:30] <allizom> I understand, that was not so clear in the user documentation
[20:30] <allizom> so when a given software is not packaged in debian, but has the aforementioned properties, it goes in multiverse
[20:31] <allizom> but when it is in debian main, i'd say en exception is granted and it goes in universe
[20:32] <allizom> did I understand it the correctway?
[20:38] <ScottK> allizom: No.
[20:38] <ScottK> The patent policy is a bit complicated.
[20:38] <ScottK> It mostly depends on how active enforcement of the patents is.
[20:39] <ScottK> If no one is actively suing over patents, the policy is to ignore them (as it's impossible to write any non-trivial piece of software that doesn't at least in theory infringe some patent)
[20:41] <allizom> ScottK: hmm... can you show me an example? for instance why avidemux is in multiverse while other video editing software are in universe? or another one if you prefer
[20:43] <tumbleweed> allizom: probably because it came from debian-multimedia.org
[20:44] <ScottK> Not really.
[20:44] <Pharaoh_Atem> allizom: it'd be dangerous to give an example
[20:44] <ScottK> https://wiki.ubuntu.com/PatentPolicy
[20:45] <allizom> tumbleweed: what does "came from" mean in this context?
[20:45] <Pharaoh_Atem> because then that means someone knows, and then it's willful infringement
[20:46] <Pharaoh_Atem> allizom: as it is, Canonical is walking on a tightrope here, so...
[20:48] <allizom> Pharaoh_Atem: I believed the user is the one tasked with obtaining applicable patent licenses, the software itself can be distributed without issues, or am I wrong?
[21:00] <pitti> hallyn: ah cool, thank you!
[21:03] <pitti> hallyn, stgraber: out of interest -- will you deprecate the user lxc mode in favor of lxd at some point in the future, or continue to support all three modes (sys lxc, user lxc, lxd)?
[21:04] <pitti> AFAIUI lxd is the privilege level of user lxc, but shared amongst all users
[21:04] <Pharaoh_Atem> allizom: wrong
[21:04] <Pharaoh_Atem> completely wrong
[21:05] <stgraber> no plan on deprecating anything though the lxc-* tools will be moving to a new lxc-legacy binary package (lxc will in turn become a meta-package installing lxc-legacy for now)
[21:05] <Pharaoh_Atem> allizom: it depends on the jurisdiction, really
[21:05] <hallyn> pitti: no, lxd is more like libvirt - users who may use lxd on the host areno longer unprivileged
[21:05] <Pharaoh_Atem> software patents are super-murky
[21:05] <stgraber> note that you can also run LXD itself as an unprivileged user, not all features work then though
[21:06] <pitti> stgraber: ah, so the "lxd" group more or less just gives you containers that are shared amongst users, but the same privileges in the container?
[21:08] <Pharaoh_Atem> allizom: if it was quite that simple, Fedora would be shipping that stuff
[21:08] <Pharaoh_Atem> and while Ubuntu doesn't have Fedora's policy, Canonical isn't US-based
[21:08] <allizom> Pharaoh_Atem: of course a distribution bears a risk of getting sued, I understand
[21:10] <allizom> Fedora policy is more straightforward in this regard, the Ubuntu one is not clear cut
[21:11] <allizom> but is this why a package gets put in universe rather than in multiverse? or is it the software license?
[21:12] <allizom> from what i read, free software = universe, nonfree = multiverse
[21:14] <allizom> no mention as to the patents
[21:19] <ari-tczew> is it true, that debhelper since 9.20160114 uses autotools-dev as default? does it mean, if we got that revision, adding autotools-dev to d/rules and B-D to d/control will be not needed anymore?
[21:19] <Pharaoh_Atem> Debian and Ubuntu's policies on this are... confusing
[21:19] <Pharaoh_Atem> allizom: it's a bit inconsistent from what I can tell
[21:20] <allizom> Pharaoh_Atem: that's why I got confused in the first place and asked here :)
[21:21] <Pharaoh_Atem> Mageia's policy is that patent encumbered stuff goes into nonfree
[21:21] <Pharaoh_Atem> Fedora's policy is that it doesn't go into the distribution at all
[21:21] <Pharaoh_Atem> Debian's policy is... ???
[21:22] <allizom> Pharaoh_Atem: it goes in main if it is free software, even as it is patent-encumbered
[21:22] <tumbleweed> Pharaoh_Atem: https://www.debian.org/legal/patent
[21:22] <ginggs> Pharaoh_Atem: https://wiki.debian.org/SourcesList#Component
[21:22] <allizom> tumbleweed: interesting
[21:24] <tumbleweed> "patent encumbered" isn't clear-cut. I think it's safe to assume that there are patents covering every piece of software in the archive, because many many stupid, unenforceable patents are granted. So, there's some value in not wasting time on the problem
[21:36] <rbasak> Also there's a jurisdiction problem. "Patent encumbered" in which jurisdiction?
[21:37] <rbasak> And who decides whether a patent applies to a particular piece of software, given that a court could end up deciding something different?
[21:37]  * tumbleweed prefers the jurisdictions that don't recognise patents :)
[21:37] <rbasak> Also, mere examination for patent encumbrance risks triple damanges in some jurisdictions.
[21:37] <rbasak> (if you decide differently from what a court later decides)
[21:39] <rbasak> http://www.ubuntu.com/legal/ubuntu-advantage/assurance is relevant here. You always carry a risk regardless of what distro you use. For Ubuntu, Canonical will take the risk away (for a fee).
[21:42] <allizom> debian policy seems to reject software that is 'encumbered' by patents, without explaining for instance whether a royalty-free licensing and not-to-sue assertions are considered 'encumbering'
[21:42] <tumbleweed> debian wouldn't consider royalty-free licencing an option
[21:43] <tkamppeter> cjwatson, found out that I had forgotten to "git push" the separation of the Braille stuff, will appear with cups-filters 1.7.0-1.
[21:43] <tumbleweed> DFSG #8
[21:43] <tkamppeter> cjwatson, but thanks anyway for the hint.
[21:45] <allizom> tumbleweed: that just says it cannot be debian-specific
[21:45] <allizom> I have a feel we are being quite ot now though
[21:46] <allizom> if it is royalty-free for all, then it should be good
[21:46] <tumbleweed> sure
[21:47] <tumbleweed> and in that situation nobody will sue, so there's no problem anyway
[21:50] <allizom> thank you tumbleweed and the others, that's enough discussing this issue for me, even though the only conclusion that I can draw wrt my original question is: the reasoning behind why to put X in universe or multiverse is inconsistent
[21:52] <allizom> as far as some freely licensed software that *may* infringe on some patents goes
[22:01] <Pharaoh_Atem> allizom: Red Hat does something similar to Canonical for RHEL, too: https://www.redhat.com/en/about/open-source-assurance
[22:02] <Pharaoh_Atem> royalty-free does not imply freely usable
[22:03] <Pharaoh_Atem> as the key is that it has to be usable, redistributable, and modifiable
[22:03] <Pharaoh_Atem> that's a hard requirement
[22:05] <allizom> Pharaoh_Atem: the code implementing the patented invention has to be free software, so that freedoms would be granted
[22:06] <allizom> how about modifying a patent?
[22:07] <Pharaoh_Atem> allizom: not required
[22:07] <Pharaoh_Atem> and not possible
[22:07] <Pharaoh_Atem> but the license of the patent must allow for the software implementing it to be freely modifiable
[22:09] <allizom> of course. what about a license that permits anyone to implement the covered patent royalty-free the way they choose?
[23:24] <barry> doko: \o/
[23:54] <ari-tczew> xnox, doko: is there any plan to grab latest cmake soon?
[23:55] <xnox> ari-tczew, do you need it, or is it a nice-to-have thing?
[23:55] <ari-tczew> xnox:  I'm having odd trouble with FTBFS, I'm guessing it's cmake related
[23:56] <xnox> ari-tczew, show me =)
[23:56] <ari-tczew> xnox: https://launchpadlibrarian.net/234550380/buildlog_ubuntu-xenial-amd64.kraft_0.59-1~ppa01_BUILDING.txt.gz
[23:56] <ari-tczew> the same package builds fine on Debian
[23:56] <xnox> ari-tczew, link to ppa? one cannot go from launchpadlibrarian -> build record reliably =)
[23:57] <ari-tczew> xnox: https://launchpad.net/~ari-tczew/+archive/ubuntu/testing/+build/8867098
[23:57] <xnox> tah
[23:57] <ari-tczew> however, the same FTBFS I got on pbuilder locally
[23:58] <xnox> ari-tczew, the error is with kdelibs5-dev provided cmake module, and the package you are building, have you tried debian's cmake and does it actually make any difference?
[23:58] <cjwatson> xnox: one actually can for package builds, though it's utterly undocumented and obscure :-)
[23:58] <xnox> i'd think either ubuntu's or debian's kdelibs5-dev are ahead.
[23:59] <xnox> cjwatson, i don't want to know... =) is like iterating build-records with API calls?
[23:59]  * xnox ain't got time for that =))))))
[23:59] <cjwatson> xnox: find the bit that says PACKAGEBUILD-8867098, then https://launchpad.net/builders/+build/8867098 redirects
[23:59] <xnox> fun. thanks.
[23:59] <xnox> kind of like bugs/+bug/ i guess.
[23:59] <cjwatson> doesn't work for all build types, I've never bothered to work out what's different