/srv/irclogs.ubuntu.com/2012/05/21/#ubuntu-x.txt

=== johanbr_ is now known as johanbr
=== yofel_ is now known as yofel
mlankhor1tmorning07:01
mlankhor1tRAOF: I've been added to xorg-pkg :)07:05
RAOFGood morning!07:05
RAOFAnd has Pete got back to you regarding hardware at all?  ☺07:06
RAOFThat was a bit weekendy, though.07:07
RAOFmlankhor1t: If you want review before/after you push to pkg-xorg feel free to ping us!07:08
mlankhor1tsure07:32
mlankhor1twhat about packages that are identical to precise? For example if x11proto never changed07:35
RAOFmlankhor1t: 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
mlankhor1tRAOF: do they need to be reuploaded with a changelog bump for precise?07:39
RAOFUnless 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
mlankhor1toh indeed I did07:43
RAOFI am the master of the semi-colon!07:44
mlankhor1thm, not all x11 packages have ubuntu changes?07:45
brycehmost don't07:45
brycehe.g. we don't have any changes for proto libs.07:45
mlankhor1tah k, no point in checking those out then07:45
brycehmainly the things we tend to change are the server, mesa, and a few drivers07:46
brycehand 'xorg' but that's a debian package more than upstream07:47
mlankhor1thm k07:49
mlankhor1thas there been a synch to debian then yet for all the updated x packages?07:50
RAOFWe'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
mlankhor1tok :)07:54
mlankhor1tRAOF: shall I see if I can rebuild xserver-xorg-core then?09:33
mlankhor1tRAOF: actually what was the magic you used to automatically merge conflicts in debian/changelog?09:47
tjaaltongit mergetool? i use meld09:52
RAOFmlankhor1t: dpkg-mergechangelogs in .git/info/attributes09:52
RAOFSpecifically, “debian/changelog merge=dpkg-mergechangelogs”09:52
tjaaltonhuh, never heard of that09:53
RAOFThat obviously goes for everyone else who doesn't already use it to merge changelogs with git :)09:53
tjaaltonhmm I seem to have it in ~/.gitattributes09:54
mlankhor1tweird10:00
=== mlankhor1t is now known as mlankhorst
mlankhorstRAOF: I'm trying to merge debian/changelog but it filters out the most recent debian changelog entry?10:15
mlankhorstautomerge*10:15
mlankhorstwhat's the proper way to merge it, looks wrong it's filtered out10:16
mlankhorstoh derp, some utf-8 dash was used for the -m, making it fail10:17
tjaaltonare you using git mergetool?10:20
tjaaltonie. what's the next thing you do after git merge?10:21
mlankhorstI added the dpkg-mergechangelogs thing, the manpage online converted the dash for the ~/.gitconfig entry into a smart dash10:21
tjaaltoni've never had conflict-free changelog merges, so have to resort to using meld every time10:21
mlankhorsttjaalton: well, it requires an entry in .gitconfig for dpkg-mergechangelogs to work10:23
tjaaltonwonder why I have it in .gitattributes10:23
mlankhorst'man dpkg-mergechangelogs' had the entry you need in ~/.gitconfig10:24
tjaaltonif it's supposed to be in $git/info/attributes, then .gitattributes is the proper place and not -config10:24
tjaaltonah10:24
mlankhorstit auto merges the conflicts properly with that entry :)10:24
tjaaltonwell, doesn't sound like it :)10:24
tjaaltonoh it needs both10:25
mlankhorsttjaalton: that was because I had some weird −m instead of -m10:25
mlankhorsti wish there was some global option for $git/info/attributes, though10:26
mlankhorstoh10:26
tjaaltonok so that's why my ~/.gitattributes doesn't work10:26
mlankhorstseems ~/.gitattributes should work10:26
tjaaltonshould?10:27
mlankhorst Attributes that should affect all repositories for a single user should be10:27
mlankhorst       placed in a file specified by the core.attributesfile configuration option (see git-config(1)). Attributes for all10:27
mlankhorst       users on a system should be placed in the $(prefix)/etc/gitattributes file.10:27
mlankhorstI guess if it doesn't work for you globally.. git config --global core.attributesfile ${HOME}/.gitattributes10:28
tjaaltonok, need to try it out then :)10:33
mlankhorstI guess this shows my knowledge of git is higher than that of packaging10:34
mlankhorstRAOF: I'm updating xf86-input-synaptics atm to 1.6.1, style fixes are annoying >:(10:49
tjaaltonyou've pulled in git master to upstream-ubuntu?10:50
tjaaltonor 1.6-branch10:50
RAOFmlankhorst: Are you starting with what's in Debian git?  IIRC one of the Debian guys has started(/finished) that for Debian.10:51
tjaaltonalso, http://www.bryceharrington.org/X/Reports/ubuntu-x-swat/package_status.html10:53
tjaaltonthough it's not showing the quantal versions yet10:53
tjaaltonthe ubuntu specific upstream branches are used only when we need something newer than in debian10:54
mlankhorstRAOF: ubuntu has a lot more changes..10:57
mlankhorstat least, 01-99 is for debian only right?10:57
RAOFRight.10:58
RAOFBy convention - we'd be in trouble if Debian needed 100 patches :)10:58
tjaaltonwhat's upstream/1.6.1+10:58
tjaalton?10:58
tjaaltona mistake?10:58
tjaaltondon't push tags, btw :)10:58
mlankhorstwoops10:59
mlankhorstseems so10:59
tjaaltonthough it's not a tag but some branch11:01
mlankhorstjust kill it11:01
mlankhorstwhat's the exact name it shows up as ?11:01
tjaaltonalso, join #debian-x on oftc11:01
tjaaltonyou don't get the commit messages? join debian-x@lists.debian.org too11:02
tjaaltonthen you'll also get all the debian bugmail, but you can filter the commit mail separate from that11:03
mlankhorstwas a wip, but accidentally did git push -a instead of quilt push -a :)11:03
tjaaltonlooks like git pull didn't pull it here11:04
mlankhorsti think it rejected it11:06
tjaaltonmaybe11:07
mlankhorstcould someone look if this is correct? http://pastebin.com/zNp9hSsX11:20
RAOFmlankhorst: 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
tjaaltonand don't do everything in one commit11:22
tjaaltonyou've dropped a bunch of patches too11:22
tjaaltonor at least should have I guess :)11:23
tjaaltonmost of which should be upstream now11:23
mlankhorstthe fixes aren't in 1.6.1 yet11:23
mlankhorst1.6.1 seems to mostly consist of a massive 'indent consistently' commit11:23
mlankhorsthttp://cgit.freedesktop.org/xorg/driver/xf86-input-synaptics/log/?h=synaptics-1.6-branch11:24
mlankhorsthm that might actually screw things up11:24
tjaaltonso, 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 meantime11:25
tjaaltonit's easier to sport mistakes then11:25
tjaaltonspot even11:25
mlankhorsthm actually, seems to be diverging after that style fix11:26
mlankhorstwoops, I guess it's really 1.6.99.900.0~git-20120517 not 1.6.1 :)11:29
tjaaltonwhat we have now?11:30
mlankhorsti mean what i was working on11:31
tjaaltonno11:31
tjaaltonyou merged from debian-unstable, so it's based on 1.6.111:31
tjaaltonat least that's what the current ubuntu branch has11:32
tjaaltonand now I see cnd's update to 1.6.0-0u1, dropping the upstream patches11:32
mlankhorsthm true11:33
tjaaltonin any case, it's painful to update to 1.6.1 :)11:34
tjaaltonsince we carry so many patches..11:35
mlankhorsttjaalton: I fixed it though11:35
tjaaltonok, if it builds and works then it's just a matter of doing the changes piecemeal imo11:36
mlankhorsttjaalton: 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
tjaaltonmlankhorst: well, probably leave it UNRELEASED too11:40
tjaaltonthe subject looks wrong too11:40
mlankhorstI was just following the previous commit11:41
tjaaltonthe [PATCH] part?-)11:42
mlankhorsttjaalton: that's not part of the patch11:42
mlankhorstit's because I used git-format-patch to export it11:42
tjaaltonahh11:42
tjaaltonwell, 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 update11:44
tjaaltonjust need to remember to include those to the source.changes when running dpkg-buildpackage/debuild (-v$previous_ubuntu_version)11:45
mlankhorsttjaalton: 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
tjaaltonmlankhorst: yes, that would be fine11:48
mlankhorsthttp://pastebin.com/j9kpabeC ?11:49
tjaaltonthe subject should probably mention the refreshes, not the upstream version, and the changelog should have '* Merged from Debian unstable' on top11:50
mlankhorstok11:50
mlankhorstanything else or is that it11:52
tjaaltonI 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 details11:52
mlankhorstok that changes git's subject to 'Update to debian unstable' though :P11:54
tjaaltondrop that line :)11:54
tjaaltonthat would be a commit of it's own though, if you want to split it11:55
mlankhorstthat was the previous commit11:55
tjaaltonright11:56
tjaaltonthis would be 'update the changelog'11:56
tjaaltonthen the actual changes to patches etc11:56
tjaaltonbut it's not that critical, just mention the merge11:56
tjaaltonin the changelog11:56
mlankhorsthttp://pastebin.com/bvZStqLG last attempt I hope11:57
tjaaltonyes :)11:58
mlankhorstI'll see if it runs on my laptop then ask if I can get someone to upload it :)12:01
mlankhorstannoyingly, all the commits right on top of that in the upstream 1.6 branch are exactly all the bugfixes we want12:05
tjaaltonyeah12:08
tjaaltonyou can add them as individual patches though12:09
tjaaltonguess 1.6.2 isn't that far away either12:09
mlankhorsttrue12:09
mlankhorstI'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
tjaaltonyou mean s/xf86-input-synaptics-1.6.1/synaptics-1.6-branch/12:12
tjaalton?12:12
tjaaltonhmm that doesn't work either12:12
mlankhorsttjaalton: no, checkout the git, then do a git format-patch relative to that tag12:13
mlankhorst:-)12:13
tjaaltonah, right12:13
tjaaltonbut you won't have debian/patches there :)12:13
mlankhorsthm true12:14
mlankhorstmight as well12:16
tjaaltongit format-patch -o debian/patches xf86-input-synaptics-1.6.1..upstream/synaptics-1.6-branch12:16
tjaaltonand with --start-number 200 :)12:16
tjaaltonhum no, it'll use four digits anyway12:17
mlankhorstexactly :P12:18
mlankhorstrename s/000/20/ 000?*12:20
mlankhorstdo I append it to the existing changelog entry?12:21
tjaaltonyes, as long as the current one is UNRELEASED12:22
tjaaltonthat's the point :)12:22
tjaaltonthen after it's uploaded a new one needs to be created12:22
tjaaltonsometimes we pull an unreleased debian version, and add on top of that. then we'll change the version from -1 to -0u112:23
mlankhorsthttp://pastebin.com/H3Lbefnz ?12:23
tjaaltonI'd reverse the order of description / patch12:27
tjaaltonalso, it's enough to refer to the bug number, no need for a full url (so, fdo #nnn or such)12:28
tjaaltonand would be greate if you have lp bug numbers to match12:28
mlankhorstok12:28
tjaalton*great12:28
tjaaltonthose would have (LP: #nnn)12:29
mlankhorstwhat about bugs in redhat tracker?12:34
tjaaltonso it's not on the commit msg?12:36
tjaaltonif the fdo bug# is linked to rh, then it's enough to just mention the fdo bug imo12:37
tjaaltonbut best would be to find a match from lp and then just mention that12:38
mlankhorsttrue12:40
mlankhorstbut there are so many resume bugs linked to synaptics hard to find the CORRECT one ;)12:40
tjaaltonmaybe put it in a ppa for precise and ask people to test12:42
tjaaltonit's not like there's any rush pushing it to quantal yet..12:43
tjaaltonor push the merge now, and test the fixes separately12:43
tjaaltonor just skip the part adding lp bug refs12:44
tjaaltonlinux is about choice!12:44
mlankhorstk12:44
tjaaltonplenty of choices here :)12:44
mlankhorstI choose not to waste more time, did a best effort search and now pushed it. ;-)12:45
mlankhorsthm.. I really need to figure out how to automatically fix all those patches to work with the coding style commit, automatically13:54
mlankhorstI have something evil in mind..13:54
jcristaucoding style commits are evil13:56
mlankhorstno easy solution sadly13:59
mlankhorstI'm trying to think of ways to automate it14:03
mlankhorstbest i can come up with is manually moving tree back to before big style commit14:04
mlankhorstapply each patch, rerun style change on affected files14:04
mlankhorst29 patches that will probably all need to be restyled :\14:06
mlankhorsthm 27 debian excluded14:06
tjaaltonoh speaking about the xserver now?14:07
mlankhorstyeah14:07
mlankhorstalthough I guess other packages are probably affected14:08
mlankhorstso I'm going to automate it :)14:08
bjsnidertseliot, have you taken a look at the changes in the 302 nvidia-settings?14:29
tseliotbjsnider: yes, and I have the relevant packaging changes in a local branch of mine14:29
bjsniderlocal meaning not in the cloud anywhere?14:31
tseliotbjsnider: yep, I haven't committed them yet14:32
bjsnidertseliot, could you pastebin me your rules?14:32
tseliotbjsnider: drop Drop 02_nvidia-settings-format-string.patch and here's the rules file: http://paste.ubuntu.com/999114/14:36
bjsniderlooks like you pasted it twice or something14:41
bjsnidertseliot, the problem i ran into was that a lot of it is now being built into /usr/local14:41
tseliotbjsnider: I think I worked around that14:41
bjsniderthe main makefile is totally different than it used to be14:42
bjsnidermy solution, which i assumed was too ugly, is this: mv $(CURDIR)/debian/$(PKG_name)/usr/local/* $(CURDIR)/debian/$(PKG_name)$(PKG_libdir)/14:42
tseliotbjsnider: what I did in override_dh_auto_install does the right thing14:50
mlankhorstok, created a dumb script to port all the patches15:52
mlankhorstbryceh: ping?16:40
brycehhi16:54
mlankhorstwas refreshing the patch series on x16:55
mlankhorstit's annoying, have to refresh literally every patch because of coding style changes16:57
* bryceh nods16:57
tseliotbjsnider: sorry this is the actual debian/rules I was talking about : http://paste.ubuntu.com/999349/16:57
mlankhorsti created a script to automate it though16:57
brycehmlankhorst, excellent16:57
brycehmlankhorst, maybe worth adding to xorg-pkg-tools?16:57
mlankhorstbryceh: maybe, drivers might be affected too16:58
mlankhorstah might as well16:59
mlankhorstthe real scary part is that it actually builds except for the pointer barrier thresholds patch17:53
Sarvattmlankhorst: http://kernel.ubuntu.com/~sarvatt/patches/500_pointer_barrier_thresholds.diff18:11
Sarvattmight want to run your script over that, thats refreshed for xserver 1.12 and what i use in edgers18:11
Sarvatti didnt fix up coding style, just made it work with xserver 1.12 and made it apply18:12
mlankhorstok18:12
mlankhorstSarvatt: I updated all other patches for 1.12 at least :-)18:13
mlankhorstSarvatt: blegh, I fear running indent twice produces DIFFERENT results..18:22
mlankhorstI'll just take that patch raw, easier18:27
mlankhorstSarvatt: actuall.. what happened to the gtest parts of that patch?18:30
Sarvattmlankhorst: oh right18:30
Sarvattforgot i dropped that, sorry :(18:30
Sarvattso not a direct replacement18:30
mlankhorstok that's fine18:30
mlankhorstlooks like it's just gtest parts and easy to do mself18:34
tjaaltonso are we merging 1.12 soon?18:54
brycehin quantal?  RAOF had thought we should wait a bit longer18:55
tjaaltonright18:55
mlankhorstbryceh: I'm just practicing on packaging, if we need 1.12 I did a lot of the patches rebasing now. :-)18:56
brycehyep no prob18:56
tjaaltonyeah18:56
mlankhorstwould still need a bump for all the input/video drivers before I could push it, though.18:57
mlankhorstshould I just set up a ppa?18:58
mlankhorsthm actually, how do I just rebuild the input/video drivers against my newly built xorg-dev package18:59
brycehyes19:00
brycehactually I seem to recall we had a work item from UDS to do exactly that19:00
brycehlet me dig it up19:00
mlankhorstI think that was for testing lts stuff19:00
bryceh[ubuntu-x-swat] consider PPA per stable release 1.12.x 1.13.x: TODO19:00
brycehnope, unrelated to lts19:01
brycehwant to take that work item?19:01
mlankhorstsure19:01
tjaaltonprobably wisest to do it once it's in quantal first19:01
brycehthere 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
mlankhorstwell so far x server succesfully refuses to start because of abi mismatch, but since it's succesful, ship it? :D19:02
brycehthe question raised was whether it should go into a ppa under ubuntu-x-swat or xorg-edgers.19:02
mlankhorstI vote for x-swat since it's supposed to be slightly more stable than xorg-edgers19:03
brycehmlankhorst, ok, fine with me19:07
mlankhorstbut yeah done for today, should I push the x 1.12 commit as a form of backup?19:08
brycehpushing to git would be ok, but maybe wait on pushing to the ppa until you actually feel it's ready for people to use19:09
tjaaltonalso, maybe we should write a policy for all the backport ideas flying around?19:10
brycehor push to a personal ppa if you just want to get it built experimentally19:10
brycehtjaalton, probably a good idea, what are you thinking?19:10
tjaaltonbryceh: well, i'm worried it might otherwise get a bit out of hand :)19:11
mlankhorsthopefully the x.org can be left to just a few packages only19:12
tjaaltonthe x.org?19:13
brycehtjaalton, ok, would you like to draft something up?  19:14
tjaaltonbryceh: i might19:14
mlankhorsterm I mean the packages we have to update in the updates pocket so userspace won't suddenly break (x11proto)19:14
brycehtjaalton, if nothing else a naming scheme would be useful19:15
mlankhorstalso EOD :-)19:15
brycehmlankhorst, enjoy :-)19:15
brycehtjaalton, now that ppa's can be deleted and so on, I'm a lot less concerned about ppa cruft than I used to be19:16
brycehbut certainly if we set up PPAs for an LTS, they're likely to be around a long while19:16
tjaaltonright, 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/used19:17
mlankhorsttrue19:17
tjaaltonspeaking as one who has never pushed to any of them :)19:18
brycehhah19:18
mlankhorstbleh I'll leave channel, i want to be done so ttyall in morning :P19:18
brycehmlankhorst, ok cya.19:18
brycehtjaalton, there's also the distinction about what belongs with each team.  And even why we have two teams.19:19
brycehlike, I wonder if we should make one team a sub-team of the other (now that we can do that)19:20
tjaaltonbryceh: oh canonical-x vs. ubuntu-x-swat?19:20
brycehah, three teams then :-)19:20
brycehubuntu-x-swat, xorg-edgers, and canonical-x19:20
tjaaltonoh edgers, yeah19:20
brycehbut canonical-x is clear enough, it's the other two that feel a bit fuzzy to me19:21
bryceh*shrug* not a big deal though19:21
* bryceh wanders off looking for food19:21
tjaaltonwell, u-x-s gets all the bugmail, which x-o probably doesn't want19:21
Sarvattxorg-edgers is crack from git with as many ubuntu patches dropped as possible, ubuntu-x-swat is everything else, hows that confusing? :P19:32
Sarvattxorg-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-updates19:34
Sarvattwe had to do crack from git for nouveau, so nouveau went there before the distro19:35
Sarvattby 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
bjsnidermore than the past year19:48
bjsniderSarvatt, 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
Sarvattoh 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 august20:30
Sarvattbjsnider: well the amd.com installer makes debs that work fine, my care level is low personally :)20:30
Sarvattbjsnider: sheesh time flies by20:32
Prf_JakobSarvatt: Hey I saw the updated on the bug, when will the package be downloadable?23:45
SarvattPrf_Jakob: takes 7 days from the upload to go from precise-proposed to precise-updates and come in automatically23:46
Sarvattits already in quantal23:46
Prf_Jakobok23:46
Sarvattso ~may 25th23:47
Prf_JakobThanks23:47
Prf_JakobWe are also going to do a release to fix bug 996821, I hoping todo that tomorrow.23:48
ubottuLaunchpad 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/99682123:48
Prf_Jakobhttp://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_JakobBut I don't know how paraniod you guys are about updating packages.23:50
RAOFBugfix only releases can be SRUd without problems.23:51
Prf_JakobK thanks23:51
RAOFIt'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!