| === johanbr_ is now known as johanbr | ||
| === yofel_ is now known as yofel | ||
| mlankhor1t | morning | 07:01 |
|---|---|---|
| mlankhor1t | RAOF: I've been added to xorg-pkg :) | 07:05 |
| RAOF | Good morning! | 07:05 |
| RAOF | And has Pete got back to you regarding hardware at all? ☺ | 07:06 |
| RAOF | That was a bit weekendy, though. | 07:07 |
| RAOF | mlankhor1t: If you want review before/after you push to pkg-xorg feel free to ping us! | 07:08 |
| mlankhor1t | sure | 07:32 |
| mlankhor1t | what about packages that are identical to precise? For example if x11proto never changed | 07:35 |
| RAOF | mlankhor1t: I'm not sure what your question is - at the start all the packages from precise are copied into quantal, so what we've currently got is what was in precise, plus anything that we've uploaded to quantal. | 07:39 |
| mlankhor1t | RAOF: do they need to be reuploaded with a changelog bump for precise? | 07:39 |
| RAOF | Unless there's some reason why we'd want to rebuild them then there's no need. | 07:40 |
| RAOF | (Assuming you mean "quantal" there; if that's in regard to the precise-backports work, then we'll only be backporting things which are necessary; if, say, x11proto-xv hasn't changed between precise quantal then we don't need to backport it) | 07:43 |
| mlankhor1t | oh indeed I did | 07:43 |
| RAOF | I am the master of the semi-colon! | 07:44 |
| mlankhor1t | hm, not all x11 packages have ubuntu changes? | 07:45 |
| bryceh | most don't | 07:45 |
| bryceh | e.g. we don't have any changes for proto libs. | 07:45 |
| mlankhor1t | ah k, no point in checking those out then | 07:45 |
| bryceh | mainly the things we tend to change are the server, mesa, and a few drivers | 07:46 |
| bryceh | and 'xorg' but that's a debian package more than upstream | 07:47 |
| mlankhor1t | hm k | 07:49 |
| mlankhor1t | has there been a synch to debian then yet for all the updated x packages? | 07:50 |
| RAOF | We've got a bunch of updated packages; -ati, -nouveau, and a couple of other drivers that we don't have a delta on got autosyncd over the weekend. | 07:53 |
| mlankhor1t | ok :) | 07:54 |
| mlankhor1t | RAOF: shall I see if I can rebuild xserver-xorg-core then? | 09:33 |
| mlankhor1t | RAOF: actually what was the magic you used to automatically merge conflicts in debian/changelog? | 09:47 |
| tjaalton | git mergetool? i use meld | 09:52 |
| RAOF | mlankhor1t: dpkg-mergechangelogs in .git/info/attributes | 09:52 |
| RAOF | Specifically, “debian/changelog merge=dpkg-mergechangelogs” | 09:52 |
| tjaalton | huh, never heard of that | 09:53 |
| RAOF | That obviously goes for everyone else who doesn't already use it to merge changelogs with git :) | 09:53 |
| tjaalton | hmm I seem to have it in ~/.gitattributes | 09:54 |
| mlankhor1t | weird | 10:00 |
| === mlankhor1t is now known as mlankhorst | ||
| mlankhorst | RAOF: I'm trying to merge debian/changelog but it filters out the most recent debian changelog entry? | 10:15 |
| mlankhorst | automerge* | 10:15 |
| mlankhorst | what's the proper way to merge it, looks wrong it's filtered out | 10:16 |
| mlankhorst | oh derp, some utf-8 dash was used for the -m, making it fail | 10:17 |
| tjaalton | are you using git mergetool? | 10:20 |
| tjaalton | ie. what's the next thing you do after git merge? | 10:21 |
| mlankhorst | I added the dpkg-mergechangelogs thing, the manpage online converted the dash for the ~/.gitconfig entry into a smart dash | 10:21 |
| tjaalton | i've never had conflict-free changelog merges, so have to resort to using meld every time | 10:21 |
| mlankhorst | tjaalton: well, it requires an entry in .gitconfig for dpkg-mergechangelogs to work | 10:23 |
| tjaalton | wonder why I have it in .gitattributes | 10:23 |
| mlankhorst | 'man dpkg-mergechangelogs' had the entry you need in ~/.gitconfig | 10:24 |
| tjaalton | if it's supposed to be in $git/info/attributes, then .gitattributes is the proper place and not -config | 10:24 |
| tjaalton | ah | 10:24 |
| mlankhorst | it auto merges the conflicts properly with that entry :) | 10:24 |
| tjaalton | well, doesn't sound like it :) | 10:24 |
| tjaalton | oh it needs both | 10:25 |
| mlankhorst | tjaalton: that was because I had some weird −m instead of -m | 10:25 |
| mlankhorst | i wish there was some global option for $git/info/attributes, though | 10:26 |
| mlankhorst | oh | 10:26 |
| tjaalton | ok so that's why my ~/.gitattributes doesn't work | 10:26 |
| mlankhorst | seems ~/.gitattributes should work | 10:26 |
| tjaalton | should? | 10:27 |
| mlankhorst | Attributes that should affect all repositories for a single user should be | 10:27 |
| mlankhorst | placed in a file specified by the core.attributesfile configuration option (see git-config(1)). Attributes for all | 10:27 |
| mlankhorst | users on a system should be placed in the $(prefix)/etc/gitattributes file. | 10:27 |
| mlankhorst | I guess if it doesn't work for you globally.. git config --global core.attributesfile ${HOME}/.gitattributes | 10:28 |
| tjaalton | ok, need to try it out then :) | 10:33 |
| mlankhorst | I guess this shows my knowledge of git is higher than that of packaging | 10:34 |
| mlankhorst | RAOF: I'm updating xf86-input-synaptics atm to 1.6.1, style fixes are annoying >:( | 10:49 |
| tjaalton | you've pulled in git master to upstream-ubuntu? | 10:50 |
| tjaalton | or 1.6-branch | 10:50 |
| RAOF | mlankhorst: Are you starting with what's in Debian git? IIRC one of the Debian guys has started(/finished) that for Debian. | 10:51 |
| tjaalton | also, http://www.bryceharrington.org/X/Reports/ubuntu-x-swat/package_status.html | 10:53 |
| tjaalton | though it's not showing the quantal versions yet | 10:53 |
| tjaalton | the ubuntu specific upstream branches are used only when we need something newer than in debian | 10:54 |
| mlankhorst | RAOF: ubuntu has a lot more changes.. | 10:57 |
| mlankhorst | at least, 01-99 is for debian only right? | 10:57 |
| RAOF | Right. | 10:58 |
| RAOF | By convention - we'd be in trouble if Debian needed 100 patches :) | 10:58 |
| tjaalton | what's upstream/1.6.1+ | 10:58 |
| tjaalton | ? | 10:58 |
| tjaalton | a mistake? | 10:58 |
| tjaalton | don't push tags, btw :) | 10:58 |
| mlankhorst | woops | 10:59 |
| mlankhorst | seems so | 10:59 |
| tjaalton | though it's not a tag but some branch | 11:01 |
| mlankhorst | just kill it | 11:01 |
| mlankhorst | what's the exact name it shows up as ? | 11:01 |
| tjaalton | also, join #debian-x on oftc | 11:01 |
| tjaalton | you don't get the commit messages? join debian-x@lists.debian.org too | 11:02 |
| tjaalton | then you'll also get all the debian bugmail, but you can filter the commit mail separate from that | 11:03 |
| mlankhorst | was a wip, but accidentally did git push -a instead of quilt push -a :) | 11:03 |
| tjaalton | looks like git pull didn't pull it here | 11:04 |
| mlankhorst | i think it rejected it | 11:06 |
| tjaalton | maybe | 11:07 |
| mlankhorst | could someone look if this is correct? http://pastebin.com/zNp9hSsX | 11:20 |
| RAOF | mlankhorst: The debian/changelog entry should be more verbose - check one of the previous merge entries. It'll start with ‘merge from Debian unstable, remaining Ubuntu changes:’ | 11:22 |
| tjaalton | and don't do everything in one commit | 11:22 |
| tjaalton | you've dropped a bunch of patches too | 11:22 |
| tjaalton | or at least should have I guess :) | 11:23 |
| tjaalton | most of which should be upstream now | 11:23 |
| mlankhorst | the fixes aren't in 1.6.1 yet | 11:23 |
| mlankhorst | 1.6.1 seems to mostly consist of a massive 'indent consistently' commit | 11:23 |
| mlankhorst | http://cgit.freedesktop.org/xorg/driver/xf86-input-synaptics/log/?h=synaptics-1.6-branch | 11:24 |
| mlankhorst | hm that might actually screw things up | 11:24 |
| tjaalton | so, first merge with debian, mention it in the changelog listing the whole diff, commit that, then start making changes to adapt it to whatever upstream or debian has done in the meantime | 11:25 |
| tjaalton | it's easier to sport mistakes then | 11:25 |
| tjaalton | spot even | 11:25 |
| mlankhorst | hm actually, seems to be diverging after that style fix | 11:26 |
| mlankhorst | woops, I guess it's really 1.6.99.900.0~git-20120517 not 1.6.1 :) | 11:29 |
| tjaalton | what we have now? | 11:30 |
| mlankhorst | i mean what i was working on | 11:31 |
| tjaalton | no | 11:31 |
| tjaalton | you merged from debian-unstable, so it's based on 1.6.1 | 11:31 |
| tjaalton | at least that's what the current ubuntu branch has | 11:32 |
| tjaalton | and now I see cnd's update to 1.6.0-0u1, dropping the upstream patches | 11:32 |
| mlankhorst | hm true | 11:33 |
| tjaalton | in any case, it's painful to update to 1.6.1 :) | 11:34 |
| tjaalton | since we carry so many patches.. | 11:35 |
| mlankhorst | tjaalton: I fixed it though | 11:35 |
| tjaalton | ok, if it builds and works then it's just a matter of doing the changes piecemeal imo | 11:36 |
| mlankhorst | tjaalton: since my changes from the debian merge are only refreshing the patches to apply, what do I have to fix? just a more verbose changelog entry? | 11:37 |
| tjaalton | mlankhorst: well, probably leave it UNRELEASED too | 11:40 |
| tjaalton | the subject looks wrong too | 11:40 |
| mlankhorst | I was just following the previous commit | 11:41 |
| tjaalton | the [PATCH] part?-) | 11:42 |
| mlankhorst | tjaalton: that's not part of the patch | 11:42 |
| mlankhorst | it's because I used git-format-patch to export it | 11:42 |
| tjaalton | ahh | 11:42 |
| tjaalton | well, like RAOF said the changelog should be more verbose, and there's no need to mention the upstream version since it's already covered in the debian update | 11:44 |
| tjaalton | just need to remember to include those to the source.changes when running dpkg-buildpackage/debuild (-v$previous_ubuntu_version) | 11:45 |
| mlankhorst | tjaalton: in that case, I just need to add in my changelog from quantal to UNRELEASED, and the fact that I refreshed the patches? | 11:47 |
| tjaalton | mlankhorst: yes, that would be fine | 11:48 |
| mlankhorst | http://pastebin.com/j9kpabeC ? | 11:49 |
| tjaalton | the subject should probably mention the refreshes, not the upstream version, and the changelog should have '* Merged from Debian unstable' on top | 11:50 |
| mlankhorst | ok | 11:50 |
| mlankhorst | anything else or is that it | 11:52 |
| tjaalton | I use debcommit -a -e, meaning that when the changelog entry has multiple lines it'll give me an editor to change the commit msg, so I'll leave the real meat in the subject and rest as details | 11:52 |
| mlankhorst | ok that changes git's subject to 'Update to debian unstable' though :P | 11:54 |
| tjaalton | drop that line :) | 11:54 |
| tjaalton | that would be a commit of it's own though, if you want to split it | 11:55 |
| mlankhorst | that was the previous commit | 11:55 |
| tjaalton | right | 11:56 |
| tjaalton | this would be 'update the changelog' | 11:56 |
| tjaalton | then the actual changes to patches etc | 11:56 |
| tjaalton | but it's not that critical, just mention the merge | 11:56 |
| tjaalton | in the changelog | 11:56 |
| mlankhorst | http://pastebin.com/bvZStqLG last attempt I hope | 11:57 |
| tjaalton | yes :) | 11:58 |
| mlankhorst | I'll see if it runs on my laptop then ask if I can get someone to upload it :) | 12:01 |
| mlankhorst | annoyingly, all the commits right on top of that in the upstream 1.6 branch are exactly all the bugfixes we want | 12:05 |
| tjaalton | yeah | 12:08 |
| tjaalton | you can add them as individual patches though | 12:09 |
| tjaalton | guess 1.6.2 isn't that far away either | 12:09 |
| mlankhorst | true | 12:09 |
| mlankhorst | I'm tempted to just do git-format-patch -o debian/patches xf86-input-synaptics-1.6.1 and commit those unrenamed (git uses 4 numbers) | 12:10 |
| tjaalton | you mean s/xf86-input-synaptics-1.6.1/synaptics-1.6-branch/ | 12:12 |
| tjaalton | ? | 12:12 |
| tjaalton | hmm that doesn't work either | 12:12 |
| mlankhorst | tjaalton: no, checkout the git, then do a git format-patch relative to that tag | 12:13 |
| mlankhorst | :-) | 12:13 |
| tjaalton | ah, right | 12:13 |
| tjaalton | but you won't have debian/patches there :) | 12:13 |
| mlankhorst | hm true | 12:14 |
| mlankhorst | might as well | 12:16 |
| tjaalton | git format-patch -o debian/patches xf86-input-synaptics-1.6.1..upstream/synaptics-1.6-branch | 12:16 |
| tjaalton | and with --start-number 200 :) | 12:16 |
| tjaalton | hum no, it'll use four digits anyway | 12:17 |
| mlankhorst | exactly :P | 12:18 |
| mlankhorst | rename s/000/20/ 000?* | 12:20 |
| mlankhorst | do I append it to the existing changelog entry? | 12:21 |
| tjaalton | yes, as long as the current one is UNRELEASED | 12:22 |
| tjaalton | that's the point :) | 12:22 |
| tjaalton | then after it's uploaded a new one needs to be created | 12:22 |
| tjaalton | sometimes we pull an unreleased debian version, and add on top of that. then we'll change the version from -1 to -0u1 | 12:23 |
| mlankhorst | http://pastebin.com/H3Lbefnz ? | 12:23 |
| tjaalton | I'd reverse the order of description / patch | 12:27 |
| tjaalton | also, it's enough to refer to the bug number, no need for a full url (so, fdo #nnn or such) | 12:28 |
| tjaalton | and would be greate if you have lp bug numbers to match | 12:28 |
| mlankhorst | ok | 12:28 |
| tjaalton | *great | 12:28 |
| tjaalton | those would have (LP: #nnn) | 12:29 |
| mlankhorst | what about bugs in redhat tracker? | 12:34 |
| tjaalton | so it's not on the commit msg? | 12:36 |
| tjaalton | if the fdo bug# is linked to rh, then it's enough to just mention the fdo bug imo | 12:37 |
| tjaalton | but best would be to find a match from lp and then just mention that | 12:38 |
| mlankhorst | true | 12:40 |
| mlankhorst | but there are so many resume bugs linked to synaptics hard to find the CORRECT one ;) | 12:40 |
| tjaalton | maybe put it in a ppa for precise and ask people to test | 12:42 |
| tjaalton | it's not like there's any rush pushing it to quantal yet.. | 12:43 |
| tjaalton | or push the merge now, and test the fixes separately | 12:43 |
| tjaalton | or just skip the part adding lp bug refs | 12:44 |
| tjaalton | linux is about choice! | 12:44 |
| mlankhorst | k | 12:44 |
| tjaalton | plenty of choices here :) | 12:44 |
| mlankhorst | I choose not to waste more time, did a best effort search and now pushed it. ;-) | 12:45 |
| mlankhorst | hm.. I really need to figure out how to automatically fix all those patches to work with the coding style commit, automatically | 13:54 |
| mlankhorst | I have something evil in mind.. | 13:54 |
| jcristau | coding style commits are evil | 13:56 |
| mlankhorst | no easy solution sadly | 13:59 |
| mlankhorst | I'm trying to think of ways to automate it | 14:03 |
| mlankhorst | best i can come up with is manually moving tree back to before big style commit | 14:04 |
| mlankhorst | apply each patch, rerun style change on affected files | 14:04 |
| mlankhorst | 29 patches that will probably all need to be restyled :\ | 14:06 |
| mlankhorst | hm 27 debian excluded | 14:06 |
| tjaalton | oh speaking about the xserver now? | 14:07 |
| mlankhorst | yeah | 14:07 |
| mlankhorst | although I guess other packages are probably affected | 14:08 |
| mlankhorst | so I'm going to automate it :) | 14:08 |
| bjsnider | tseliot, have you taken a look at the changes in the 302 nvidia-settings? | 14:29 |
| tseliot | bjsnider: yes, and I have the relevant packaging changes in a local branch of mine | 14:29 |
| bjsnider | local meaning not in the cloud anywhere? | 14:31 |
| tseliot | bjsnider: yep, I haven't committed them yet | 14:32 |
| bjsnider | tseliot, could you pastebin me your rules? | 14:32 |
| tseliot | bjsnider: drop Drop 02_nvidia-settings-format-string.patch and here's the rules file: http://paste.ubuntu.com/999114/ | 14:36 |
| bjsnider | looks like you pasted it twice or something | 14:41 |
| bjsnider | tseliot, the problem i ran into was that a lot of it is now being built into /usr/local | 14:41 |
| tseliot | bjsnider: I think I worked around that | 14:41 |
| bjsnider | the main makefile is totally different than it used to be | 14:42 |
| bjsnider | my solution, which i assumed was too ugly, is this: mv $(CURDIR)/debian/$(PKG_name)/usr/local/* $(CURDIR)/debian/$(PKG_name)$(PKG_libdir)/ | 14:42 |
| tseliot | bjsnider: what I did in override_dh_auto_install does the right thing | 14:50 |
| mlankhorst | ok, created a dumb script to port all the patches | 15:52 |
| mlankhorst | bryceh: ping? | 16:40 |
| bryceh | hi | 16:54 |
| mlankhorst | was refreshing the patch series on x | 16:55 |
| mlankhorst | it's annoying, have to refresh literally every patch because of coding style changes | 16:57 |
| * bryceh nods | 16:57 | |
| tseliot | bjsnider: sorry this is the actual debian/rules I was talking about : http://paste.ubuntu.com/999349/ | 16:57 |
| mlankhorst | i created a script to automate it though | 16:57 |
| bryceh | mlankhorst, excellent | 16:57 |
| bryceh | mlankhorst, maybe worth adding to xorg-pkg-tools? | 16:57 |
| mlankhorst | bryceh: maybe, drivers might be affected too | 16:58 |
| mlankhorst | ah might as well | 16:59 |
| mlankhorst | the real scary part is that it actually builds except for the pointer barrier thresholds patch | 17:53 |
| Sarvatt | mlankhorst: http://kernel.ubuntu.com/~sarvatt/patches/500_pointer_barrier_thresholds.diff | 18:11 |
| Sarvatt | might want to run your script over that, thats refreshed for xserver 1.12 and what i use in edgers | 18:11 |
| Sarvatt | i didnt fix up coding style, just made it work with xserver 1.12 and made it apply | 18:12 |
| mlankhorst | ok | 18:12 |
| mlankhorst | Sarvatt: I updated all other patches for 1.12 at least :-) | 18:13 |
| mlankhorst | Sarvatt: blegh, I fear running indent twice produces DIFFERENT results.. | 18:22 |
| mlankhorst | I'll just take that patch raw, easier | 18:27 |
| mlankhorst | Sarvatt: actuall.. what happened to the gtest parts of that patch? | 18:30 |
| Sarvatt | mlankhorst: oh right | 18:30 |
| Sarvatt | forgot i dropped that, sorry :( | 18:30 |
| Sarvatt | so not a direct replacement | 18:30 |
| mlankhorst | ok that's fine | 18:30 |
| mlankhorst | looks like it's just gtest parts and easy to do mself | 18:34 |
| tjaalton | so are we merging 1.12 soon? | 18:54 |
| bryceh | in quantal? RAOF had thought we should wait a bit longer | 18:55 |
| tjaalton | right | 18:55 |
| mlankhorst | bryceh: I'm just practicing on packaging, if we need 1.12 I did a lot of the patches rebasing now. :-) | 18:56 |
| bryceh | yep no prob | 18:56 |
| tjaalton | yeah | 18:56 |
| mlankhorst | would still need a bump for all the input/video drivers before I could push it, though. | 18:57 |
| mlankhorst | should I just set up a ppa? | 18:58 |
| mlankhorst | hm actually, how do I just rebuild the input/video drivers against my newly built xorg-dev package | 18:59 |
| bryceh | yes | 19:00 |
| bryceh | actually I seem to recall we had a work item from UDS to do exactly that | 19:00 |
| bryceh | let me dig it up | 19:00 |
| mlankhorst | I think that was for testing lts stuff | 19:00 |
| bryceh | [ubuntu-x-swat] consider PPA per stable release 1.12.x 1.13.x: TODO | 19:00 |
| bryceh | nope, unrelated to lts | 19:01 |
| bryceh | want to take that work item? | 19:01 |
| mlankhorst | sure | 19:01 |
| tjaalton | probably wisest to do it once it's in quantal first | 19:01 |
| bryceh | there was also a discussion on ubuntu-x@ last week about it. I was trying to rope in a community member that expressed interest in it. | 19:02 |
| mlankhorst | well so far x server succesfully refuses to start because of abi mismatch, but since it's succesful, ship it? :D | 19:02 |
| bryceh | the question raised was whether it should go into a ppa under ubuntu-x-swat or xorg-edgers. | 19:02 |
| mlankhorst | I vote for x-swat since it's supposed to be slightly more stable than xorg-edgers | 19:03 |
| bryceh | mlankhorst, ok, fine with me | 19:07 |
| mlankhorst | but yeah done for today, should I push the x 1.12 commit as a form of backup? | 19:08 |
| bryceh | pushing to git would be ok, but maybe wait on pushing to the ppa until you actually feel it's ready for people to use | 19:09 |
| tjaalton | also, maybe we should write a policy for all the backport ideas flying around? | 19:10 |
| bryceh | or push to a personal ppa if you just want to get it built experimentally | 19:10 |
| bryceh | tjaalton, probably a good idea, what are you thinking? | 19:10 |
| tjaalton | bryceh: well, i'm worried it might otherwise get a bit out of hand :) | 19:11 |
| mlankhorst | hopefully the x.org can be left to just a few packages only | 19:12 |
| tjaalton | the x.org? | 19:13 |
| bryceh | tjaalton, ok, would you like to draft something up? | 19:14 |
| tjaalton | bryceh: i might | 19:14 |
| mlankhorst | erm I mean the packages we have to update in the updates pocket so userspace won't suddenly break (x11proto) | 19:14 |
| bryceh | tjaalton, if nothing else a naming scheme would be useful | 19:15 |
| mlankhorst | also EOD :-) | 19:15 |
| bryceh | mlankhorst, enjoy :-) | 19:15 |
| bryceh | tjaalton, now that ppa's can be deleted and so on, I'm a lot less concerned about ppa cruft than I used to be | 19:16 |
| bryceh | but certainly if we set up PPAs for an LTS, they're likely to be around a long while | 19:16 |
| tjaalton | right, we already have a number of ppa's, so defining their function wouldn't hurt I guess, and the way they're supposed to be updated/used | 19:17 |
| mlankhorst | true | 19:17 |
| tjaalton | speaking as one who has never pushed to any of them :) | 19:18 |
| bryceh | hah | 19:18 |
| mlankhorst | bleh I'll leave channel, i want to be done so ttyall in morning :P | 19:18 |
| bryceh | mlankhorst, ok cya. | 19:18 |
| bryceh | tjaalton, there's also the distinction about what belongs with each team. And even why we have two teams. | 19:19 |
| bryceh | like, I wonder if we should make one team a sub-team of the other (now that we can do that) | 19:20 |
| tjaalton | bryceh: oh canonical-x vs. ubuntu-x-swat? | 19:20 |
| bryceh | ah, three teams then :-) | 19:20 |
| bryceh | ubuntu-x-swat, xorg-edgers, and canonical-x | 19:20 |
| tjaalton | oh edgers, yeah | 19:20 |
| bryceh | but canonical-x is clear enough, it's the other two that feel a bit fuzzy to me | 19:21 |
| bryceh | *shrug* not a big deal though | 19:21 |
| * bryceh wanders off looking for food | 19:21 | |
| tjaalton | well, u-x-s gets all the bugmail, which x-o probably doesn't want | 19:21 |
| Sarvatt | xorg-edgers is crack from git with as many ubuntu patches dropped as possible, ubuntu-x-swat is everything else, hows that confusing? :P | 19:32 |
| Sarvatt | xorg-edgers has always been crack from git, the confusing part is what goes where in ubuntu-x-swat because there never has been any concrete plans for the ppas outside of a "best effort" to update things in x-updates | 19:34 |
| Sarvatt | we had to do crack from git for nouveau, so nouveau went there before the distro | 19:35 |
| Sarvatt | by concrete plans i mean people interested in uploading, bjsnider has been doing x-updates for the past year and i'm trying to do stable driver releases in there but there are always transitions like an intel driver needing newer libdrm that breaks nouveau until there is a mesa release that works with it in august now.. | 19:38 |
| bjsnider | more than the past year | 19:48 |
| bjsnider | Sarvatt, that reminds me, do we care about putting fglrx in x-updates at this point or is it ok for people to use the amd installer? | 20:03 |
| Sarvatt | oh fun, cairo in quantal is already 1.12? sucks for nouveau users :( the fixes to make cairo 1.12 usable need the libdrm-nouveau2 change, and mesa that works with that wont be released until august | 20:30 |
| Sarvatt | bjsnider: well the amd.com installer makes debs that work fine, my care level is low personally :) | 20:30 |
| Sarvatt | bjsnider: sheesh time flies by | 20:32 |
| Prf_Jakob | Sarvatt: Hey I saw the updated on the bug, when will the package be downloadable? | 23:45 |
| Sarvatt | Prf_Jakob: takes 7 days from the upload to go from precise-proposed to precise-updates and come in automatically | 23:46 |
| Sarvatt | its already in quantal | 23:46 |
| Prf_Jakob | ok | 23:46 |
| Sarvatt | so ~may 25th | 23:47 |
| Prf_Jakob | Thanks | 23:47 |
| Prf_Jakob | We are also going to do a release to fix bug 996821, I hoping todo that tomorrow. | 23:48 |
| ubottu | Launchpad bug 996821 in xserver-xorg-input-vmmouse (Ubuntu) "vmmouse 12.8 behaves erratically in when running as a VMware guest" [Undecided,Confirmed] https://launchpad.net/bugs/996821 | 23:48 |
| Prf_Jakob | http://cgit.freedesktop.org/xorg/driver/xf86-input-vmmouse/ <-- there are two other fixes as well in the release but it should be safe to upgrade. | 23:49 |
| Prf_Jakob | But I don't know how paraniod you guys are about updating packages. | 23:50 |
| RAOF | Bugfix only releases can be SRUd without problems. | 23:51 |
| Prf_Jakob | K thanks | 23:51 |
| RAOF | It's once you start adding things that aren't clear bugfixes that the SRU process becomes patch cherry-picking :) | 23:52 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!