| 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 |
|---|---|---|
| ubottu | Launchpad bug 1625540 in xorg (Ubuntu) "There is no video server for SiS chipsets" [Undecided,Won't fix] | 06:34 |
| alkisg | Are there any chances of success with a plain apt-get source/debuild? | 06:34 |
| === broder_ is now known as broder | ||
| === JanC is now known as Guest10239 | ||
| === JanC_ is now known as JanC | ||
| tjaalton | alkisg: sure | 09:11 |
| 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:12 |
| tjaalton | newer SiS were never supported | 09:13 |
| alkisg | It worked in the patched 12.04 package | 09:13 |
| alkisg | (the one that initially had the segfaults, and then was fixed) | 09:14 |
| alkisg | ty tjaalton, you give me hope :D | 09:14 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| alkisg | Ah, ok, thank you, that should save me quite some time in debugging the build :D | 09:20 |
| 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:21 |
| 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:22 |
| 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 | 09:23 |
| tjaalton | ricotz: can you add me to the gfx team? I'd upload mesa 13.0.4 for xenial | 16:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| tseliot | tjaalton: so what's the difference between edgers and this PPA? | 16:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| tjaalton | ricotz: https://launchpad.net/~canonical-x/+archive/ubuntu/x-staging/+packages | 16:16 |
| ricotz | xedgers can be called prerelease currently ;) | 16:16 |
| 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:17 |
| 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:18 |
| ricotz | tjaalton, vulkan is already in since nvidia requires i | 16:19 |
| ricotz | t | 16:19 |
| tjaalton | you didn't answer my question ;) | 16:19 |
| ricotz | tjaalton, carry where? | 16:20 |
| tjaalton | mesa ppa | 16:20 |
| tjaalton | or would both need to be enabled | 16:20 |
| ricotz | tjaalton, all those different builds are a pita | 16:21 |
| ricotz | also those different version schemes :\ | 16:21 |
| 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:22 |
| ricotz | so xenial and later | 16:23 |
| ricotz | or even trusty? | 16:23 |
| tjaalton | no way | 16:23 |
| ricotz | ok | 16:24 |
| 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:25 |
| 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:26 |
| ricotz | don't ignore optimus/prime users | 16:27 |
| tjaalton | nothing changes there | 16:27 |
| ricotz | huh? | 16:27 |
| 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:28 |
| 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:29 |
| ricotz | bbl | 16:30 |
| tjaalton | oh, padoka ppa mesa has an epoch.. | 17:34 |
| tjaalton | ricotz: beta ppa is fine | 17:45 |
| Sarvatt | tjaalton: was the -backports idea a no go? | 18:11 |
| tjaalton | Sarvatt: no, but it's harder to use than a ppa | 18:17 |
| tjaalton | and more paperwork | 18:17 |
| tjaalton | harder for the user I mean | 18:18 |
| tjaalton | ricotz: actually, these don't need a staging ppa. they've already been tested. I'd upload llvm first | 18:33 |
| tjaalton | 3.9.1-3ubuntu1~gpu16.04.1, a proper version number too | 18:34 |
| tjaalton | hmm not that | 18:35 |
| tjaalton | -4u1 | 18:35 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| tjaalton | zesty has 1:4.0~+rc1-1 right now | 18:43 |
| tjaalton | it'll have 4.0.1 or something when 17.04 is released | 18:44 |
| tjaalton | say, 4.0.1-1ubuntu1 | 18:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| ricotz | exactly | 18:53 |
| tjaalton | 1:3.9.1-4ubuntu1~gpu16.04.1 | 18:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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 | 18:57 |
| ricotz | "backportpackage" would append "~ubuntuXX.XX.1" too afaik | 19:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| tjaalton | -4ubuntu1.16.04.1 was wrong of course | 19:04 |
| mamarley | Lots of people don't seem to understand the difference between -, ~, and + in those version numbers. | 19:05 |
| tjaalton | dpkg --compare-versions is your fried | 19:06 |
| tjaalton | uh, friend | 19:06 |
| tjaalton | ~16.04.1~gpu1 would solve it | 19:08 |
| tjaalton | or just ~16.04~gpu1 | 19:10 |
| === JanC_ is now known as JanC | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!