[06:34] <alkisg> tjaalton: hello, regarding https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1625540, would it be possible for a user to self-build xserver-xorg-video-sis in 16.04 with a simple apt-get source, debuild; or would it also involve fixing a whole lot of incompatibilities with the newer xservers?
[06:34] <alkisg> Are there any chances of success with a plain apt-get source/debuild?
[09:11] <tjaalton> alkisg: sure
[09:12] <tjaalton> oh
[09:12] <tjaalton> not for that gpu
[09:12] <alkisg> tjaalton: thanks, I'll probably need it in a few schools here...
[09:12] <alkisg> (like, 500 schools :()
[09:12] <tjaalton> create a ppa, put it there
[09:12] <alkisg> They have some onboard sis, pentium 4's
[09:12] <tjaalton> maybe that's old enough
[09:13] <tjaalton> newer SiS were never supported
[09:13] <alkisg> It worked in the patched 12.04 package
[09:14] <alkisg> (the one that initially had the segfaults, and then was fixed)
[09:14] <alkisg> ty tjaalton, you give me hope :D
[09:16] <alkisg> tjaalton: would I need to rebuild it on every xorg update, within the 16.04.1 cycle? Or just on point updates, like 16.04.2 etc?
[09:17] <tjaalton> you have no reason to use point-releases
[09:17] <tjaalton> on obsolete hw
[09:17] <alkisg> True, but they have mixed-client labs, and they're all netbooted from a single image
[09:17] <tjaalton> so use .1
[09:18] <alkisg> But my main question is, if a xorg security update or something comes out, will I need to rebuild xserver-xorg-video-sis to match?
[09:18] <tjaalton> no
[09:18] <alkisg> Cool
[09:19] <tjaalton> you probably need at least 0.18.0 from upstream
[09:19] <tjaalton> which has build-fixes for 1.18
[09:19] <tjaalton> 0.17 from trusty doesn't build
[09:19] <tjaalton> 0.19 is for 1.19
[09:19] <tjaalton> with a single commit
[09:19] <tjaalton> no, two commits
[09:20] <alkisg> Ah, ok, thank you, that should save me quite some time in debugging the build :D
[09:21] <alkisg> (the bad thing when booting from a single image, is that you have those -sis clients, and also skylake clients, and it's difficult to find one release that supports both of them...)
[09:21] <alkisg> 14.04.1 supports -sis, and I think skylake is supported from 14.04.3 onwards or something...
[09:22] <tjaalton> right
[09:22] <tjaalton> understood
[09:22] <tjaalton> so if you want to use 16.04.2 with -hwe-16.04 stack then you'd need to modify the source and rename it to x-x-v-sis-hwe-16.04 or sth
[09:23] <alkisg> No no I'll stick with 16.04.1
[09:23] <alkisg> If some school needs > 16.04.1 for newer hardware, and also has -sis, I'll tell them to exchange the old clients with some other school :D
[16:08] <tjaalton> ricotz: can you add me to the gfx team? I'd upload mesa 13.0.4 for xenial
[16:09] <tjaalton> tseliot: or you
[16:09] <tseliot> tjaalton: sure
[16:09] <ricotz> tjaalton, 13.0.4?
[16:09] <ricotz> I would expect 17.0.0~rc3 ;)
[16:09] <tseliot> tjaalton: done
[16:10] <ricotz> tjaalton, please give some more info on what you want to upload
[16:10] <tjaalton> ricotz: all the build-deps
[16:10] <tjaalton> 13 is ready now
[16:10] <tjaalton> 17 isn't even in zesty yet
[16:10] <ricotz> I assume wayland, llvm, libdrm, ...
[16:10] <tjaalton> it just needs libdrm and llvm-3.9
[16:10] <tjaalton> tseliot: thanks!
[16:10] <tseliot> wait a second, though, isn't the PPA just for binary drivers?
[16:10] <ricotz> tseliot, isnt wayland 1.11 required?
[16:11] <tseliot> ricotz, tjaalton: maybe support for wayland can be disabled
[16:11] <ricotz> tseliot, no
[16:11] <tjaalton> tseliot: the description should be changed
[16:11] <tseliot> oh
[16:12] <tseliot> tjaalton: so what's the difference between edgers and this PPA?
[16:13] <tjaalton> this is not edgers
[16:13] <tseliot> I think the idea was to make binary drivers available without having to pull in anything else
[16:13] <tseliot> (e.g. mesa or X)
[16:13] <ricotz> exactly
[16:13] <tseliot> tjaalton: so what's the purpose of the upload?
[16:14] <ricotz> although mesa and libdrm will be update unconditionally afaik
[16:14] <ricotz> so not hwe package renames anymore
[16:14] <tjaalton> the team name is too generic then if it's just for nvidia
[16:14] <tjaalton> :)
[16:14] <tseliot> true
[16:15] <tseliot> with fglrx gone, it's just nvidia now
[16:15] <ricotz> tjaalton, point me to the things you want to copy, and I can take a look
[16:15] <ricotz> preferred are proper version suffixes to indicate their origin
[16:16] <tjaalton> ricotz: https://launchpad.net/~canonical-x/+archive/ubuntu/x-staging/+packages
[16:16] <ricotz> xedgers can be called prerelease currently ;)
[16:17] <tjaalton> I can happily create a ppa under canonical-x too and call that official
[16:17] <tjaalton> just for mesa
[16:17] <mamarley> tjaalton: I noticed that in canonical-x/x-staging you are working on getting Mesa to use glvnd.  Are we going to make the NVIDIA binaries work with that too?
[16:17] <tjaalton> mamarley: eventually
[16:18] <mamarley> In Zesty, or at some point after that?
[16:18] <tjaalton> compiz crashes within a minute of idling, so it's not going in zesty anytime soon
[16:18] <ricotz> tjaalton, currently I would be more comfortable with ppa:graphics-drivers/mesa
[16:18] <tjaalton> ricotz: then it would need to carry vulkan as well?
[16:19] <ricotz> tjaalton, vulkan is already in since nvidia requires i
[16:19] <ricotz> t
[16:19] <tjaalton> you didn't answer my question ;)
[16:20] <ricotz> tjaalton, carry where?
[16:20] <tjaalton> mesa ppa
[16:20] <tjaalton> or would both need to be enabled
[16:21] <ricotz> tjaalton, all those different builds are a pita
[16:21] <ricotz> also those different version schemes :\
[16:22] <tjaalton> easily fixed
[16:22] <tjaalton> jorge is not here..
[16:22] <tjaalton> we've been discussing mesa with feral and paulo
[16:22] <ricotz> and you want this for xenial only?
[16:22] <tjaalton> no
[16:22] <ricotz> good
[16:23] <ricotz> so xenial and later
[16:23] <ricotz> or even trusty?
[16:23] <tjaalton> no way
[16:24] <ricotz> ok
[16:25] <ricotz> might be good to stage all of this in a separate ppa which proper versioning?
[16:25] <tjaalton> there would be a separate beta ppa for "oibaf" mesa
[16:26] <tjaalton> these are not beta versions though
[16:26] <tjaalton> and so far anyone using this are on nvidia
[16:26] <ricotz> yeah, like mesa in edgers now
[16:27] <ricotz> don't ignore optimus/prime users
[16:27] <tjaalton> nothing changes there
[16:27] <ricotz> huh?
[16:28] <tjaalton> how do you stage nvidia releases? in edgers?
[16:28] <ricotz> intel gpu would be driven by mesa, no?
[16:28] <tjaalton> sure
[16:28] <ricotz> in private ppas
[16:28] <ricotz> and/or local builds
[16:29] <ricotz> nvidia doesnt consist of multiple source packages ;)
[16:29] <ricotz> ok, so better have a separate staging ppa for get those packages aligned and built?
[16:30] <ricotz> bbl
[17:34] <tjaalton> oh, padoka ppa mesa has an epoch..
[17:45] <tjaalton> ricotz: beta ppa is fine
[18:11] <Sarvatt> tjaalton: was the -backports idea a no go?
[18:17] <tjaalton> Sarvatt: no, but it's harder to use than a ppa
[18:17] <tjaalton> and more paperwork
[18:18] <tjaalton> harder for the user I mean
[18:33] <tjaalton> ricotz: actually, these don't need a staging ppa. they've already been tested. I'd upload llvm first
[18:34] <tjaalton> 3.9.1-3ubuntu1~gpu16.04.1, a proper version number too
[18:35] <tjaalton> hmm not that
[18:35] <tjaalton> -4u1
[18:37] <ricotz> tjaalton, ok, better -0u0~ and pass -V3.9.1 for llvm?
[18:37] <tjaalton> why -0u0 if the packaging is based on newer?
[18:38] <tjaalton> -0u0 says nothing
[18:38] <ricotz> to avoid possible conflicts with archive uploads or the like
[18:38] <tjaalton> ~ already means it's older
[18:39] <ricotz> I know, although the versioning of some archive uploads can be a mess ;)
[18:39] <tjaalton> there won't be llvm-3.9 in xenial
[18:40] <ricotz> just to be sure it won't override any future official uploads
[18:40] <tjaalton> sorry but I don't agree :)
[18:40] <ricotz> really, I though mesa 13/17 will land in xenial at some point?
[18:40] <ricotz> thought
[18:41] <tjaalton> they will
[18:41] <ricotz> llvm-4.0
[18:41] <tjaalton> llvm-4.0 is a separate source
[18:41] <tjaalton> mesa 13 won't
[18:41] <ricotz> I know, so there must be some official llvm backport?
[18:42] <tjaalton> yes and it's based on the latest version
[18:42] <tjaalton> once it's backported
[18:42] <ricotz> you are making it hard to understand
[18:43] <tjaalton> zesty has 1:4.0~+rc1-1 right now
[18:44] <tjaalton> it'll have 4.0.1 or something when 17.04 is released
[18:44] <tjaalton> say, 4.0.1-1ubuntu1
[18:45] <ricotz> ok, so why not use llvm-4.0 already?
[18:45] <tjaalton> that will be officially backported as -1ubuntu1~16.04.1
[18:45] <tjaalton> eh
[18:45] <tjaalton> mesa 13 doesn't work with it
[18:45] <tjaalton> llvm-3.9 doesn't upgrade to -4.0
[18:46] <ricotz> ok, so use mesa 17? which will be released this week?
[18:46] <tjaalton> no
[18:46] <tjaalton> I thought you were concerned about forcing a new mesa to folks using this ppa ;)
[18:47] <tjaalton> I wanted to give stable mesa 13
[18:47] <tjaalton> now
[18:47] <ricotz> I am, still is seems weird not to use/test what will actually be backported in the end
[18:47] <tjaalton> once it's at .1 or something
[18:47] <tjaalton> it's not even in zesty yet
[18:48] <tjaalton> and the mir egl patch is being worked on, I'm not allowed to touch it before it lands
[18:48] <tjaalton> well, I won't touch it before..
[18:48] <ricotz> I see
[18:48] <ricotz> why is this mir patch not upstreamed?
[18:49] <tjaalton> because it was not ready
[18:49] <tjaalton> apparently it will be after this
[18:49] <tjaalton> still waiting for new xmir..
[18:49] <tjaalton> for two months now
[18:50] <tjaalton> which is why xserver 1.19 isn't in zesty yet, and which will block any libglvnd work from happening in the archive
[18:51] <ricotz> hmm, ok
[18:51] <tjaalton> anyway, llvm versions; I'm the one doing official backports
[18:51] <tjaalton> so you can count on having proper versioning there
[18:52] <tjaalton> same goes for libclc, libdrm, mesa
[18:52] <ricotz> alright, use numbers instead of release-names ;)
[18:52] <tjaalton> yeah that's for sure
[18:52] <tjaalton> needed for hwe-16.04 too, because release names won't sort anymore, after zesty
[18:53] <ricotz> exactly
[18:53] <tjaalton> 1:3.9.1-4ubuntu1~gpu16.04.1
[18:54] <tjaalton> -4u1 is in zesty-proposed, fixes some regression on radeonsi
[18:54] <ricotz> how will the archive version look like for xenial?
[18:54] <tjaalton> hmm
[18:54] <tjaalton> well, in this case there won't be any
[18:54] <tjaalton> but you're right
[18:54] <ricotz> 0u0 is useful!
[18:54] <tjaalton> it'd be ~16.04.1
[18:54] <tjaalton> hehe
[18:55] <tjaalton> ~0gpu
[18:55] <tjaalton> :P
[18:55] <ricotz> no
[18:55] <ricotz> "llvm-toolchain-4.0 - 1:4.0~+rc1-0ubuntu0~xedgers16.04.1"
[18:56] <ricotz> better do it like that
[18:56] <tjaalton> loses too much informatino
[18:56] <tjaalton> -on
[18:56] <ricotz> as I said create the package with -V...
[18:56] <tjaalton> you're putting "gpu" in the wrong place! :)
[18:56] <tjaalton> -V does what?
[18:57] <ricotz> to include previous changelog entries in the dsc/changes
[18:57] <ricotz> which will then appear on launchpad as well
[18:57] <tjaalton> you mean -v?
[18:57] <tjaalton> for debuild at least
[18:57] <ricotz> yeah
[19:00] <ricotz> "backportpackage" would append "~ubuntuXX.XX.1" too afaik
[19:01] <tjaalton> oh right
[19:01] <tjaalton> actually it would be -4ubuntu1.16.04.1
[19:01] <tjaalton> if zesty had -4 it would be -4~ubuntu16.04.1
[19:01] <ricotz> I don't think so
[19:01] <tjaalton> err
[19:02] <tjaalton> -4~ubuntu0.16.04.1
[19:02] <tjaalton> I've done those
[19:02] <ricotz> anyway, the version in the ppa *must* be lower than any possible official upload
[19:02] <ricotz> this is getting cumbersome
[19:03] <tjaalton> yes, unlike padoka :)
[19:03] <tjaalton> it's unfortunate you chose to version them like that
[19:03] <ricotz> things like that are really bad
[19:04] <tjaalton> -4ubuntu1.16.04.1 was wrong of course
[19:05] <mamarley> Lots of people don't seem to understand the difference between -, ~, and + in those version numbers.
[19:06] <tjaalton> dpkg --compare-versions is your fried
[19:06] <tjaalton> uh, friend
[19:08] <tjaalton> ~16.04.1~gpu1 would solve it
[19:10] <tjaalton> or just ~16.04~gpu1