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