[13:04] <lemonsqueeze> hiya, i'd like to request an SRU for bug #1085457
[13:04] <ubot2> Launchpad bug 1085457 in xnee (Ubuntu) "cnee broken in lucid" [Undecided,New] https://launchpad.net/bugs/1085457
[13:04] <lemonsqueeze> looking for a bug supervisor to target the bug to lucid (as per wiki.ubuntu.com/StableReleaseUpdates)
[13:04] <lemonsqueeze> am i in the right place ?
[13:06] <penguin42> it's a bit quiet today, if you don't get any response then you could also try #ubuntu-devel  but let me just look at that bug first
[13:06] <lemonsqueeze> oh yeah, sunday ...
[13:07] <penguin42> lemonsqueeze: Can you confirm whether the version in raring works?
[13:07] <lemonsqueeze> yup
[13:07] <lemonsqueeze> using it at the moment
[13:07] <lemonsqueeze> 3.13-1 that is
[13:08] <penguin42> ok, good
[13:08] <penguin42> lemonsqueeze: So then I guess the problem you might hit is that you don't have a fix so much as an upgrade to latest is the fix, you will probably get some push back from just jumping to a new version
[13:11] <lemonsqueeze> hmm, what's the best way then ? initially i thought of asking for a backport but apparently it's not appropriate for bugs ...
[13:11] <penguin42> hmm interesting package - hadn't come across that before
[13:12] <penguin42> lemonsqueeze: Is this it always breaks or it just breaks with those options?
[13:13] <lemonsqueeze> from what i can tell it's always broken.
[13:13] <penguin42> ok, and it's a different bug than bug 706794 ?
[13:13] <ubot2> Launchpad bug 706794 in xnee (Ubuntu) "gnee/pnee packages for Ubuntu lucid crash on record" [Undecided,New] https://launchpad.net/bugs/706794
[13:14] <lemonsqueeze> yeah, it doesn't crash. it's just that it doesn't work at all
[13:14] <penguin42> ok
[13:16] <penguin42> do you know if the version in precise (3.11) works?
[13:18] <penguin42> lemonsqueeze: I've marked it as Fix Released - because the newer version works as you say; now that means it's then closer to the right state to ask for an sru I think
[13:18] <lemonsqueeze> ok
[13:19] <lemonsqueeze> haven't tried 3.11. Can give it a shot if necessary
[13:20] <penguin42> lemonsqueeze: It might be worth it; the interesting question I think is whether it needs a fix for Precise as well as lucid
[13:22] <lemonsqueeze> ok, one moment ...
[13:25] <penguin42> lemonsqueeze: If you can find an actual fix in that went into xnee that fixed the problem then you have a much better chance of getting sru - i.e. if you can say 'we need *that* patch' then I think you've got a much better chance
[13:28]  * penguin42 goes to get breakfast - back in 30mins or so
[13:30] <lemonsqueeze> ok
[13:30] <lemonsqueeze> have to reboot to test, will be back afterwards
[13:31] <lemonsqueeze> enjoy breakfast =)
[13:51] <lemonsqueeze> ok, cnee works under precise. so 3.11 ok as far as this bug is concerned
[14:03] <penguin42> ok, so add that as a comment to the bug; so in that case it's just Lucid you're after fixing
[14:12] <penguin42> lemonsqueeze: I've added a nominate for Lucid on it and added a comment; it might be worth checking with some others on -devel etc but I don't think it could be SRUd without finding a patch
[14:16] <lemonsqueeze> ok, thanks dave.
[14:21] <lemonsqueeze> i thought SRU in this case would be straightforward. it's probably not worth the time finding the exact patch as long as affected ppl can find the bug report ...
[14:22] <penguin42> lemonsqueeze: yeh I don't think generally the SRUs are 'this is the problem - here is the fix' because they are low risk; where as putitng in a new version people worry about if it will break anything else
[15:01] <alo21> hi. I am fixing this bug: https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1095521
[15:01] <ubot2> Launchpad bug 1095521 in util-linux (Ubuntu) "Manpage for mount list different options in same paragraph (keybits, nofail, iversion)" [Undecided,In progress]
[15:01] <penguin42> great
[15:01] <alo21> Once I did, Do I propose a merge, or attach a patch to the bug?
[15:01]  * TheLordOfTime glances in
[15:02] <penguin42> alo21: So is it an Ubuntu specific bug or general upstream?
[15:02] <alo21> penguin42, as I can see here, is a Ubuntu specific
[15:03] <penguin42> alo21: OK, it's worth checking though - if it was in upstream as well I'd send it upstream
[15:04] <penguin42> alo21: But if it's an ubuntu only then you have a choice of attaching a debdiff, or doing a bzr branch - bzr branches normally go in quicker in my experiences
[15:04] <TheLordOfTime> is util-linux pulled from Debian at all?
[15:04] <TheLordOfTime> if so, does the b ug exist in Debian?
[15:04] <penguin42> I would have thought so, so it's also worth checking that
[15:04] <TheLordOfTime> (if so, a patch should be sent to Debian too)
[15:05] <TheLordOfTime> because if the package is, at any point, pulled into Ubuntu from Debian, then its worth checking in Debian, even if there's an ubuntu delta (such that ubuntu-only changes happened after being synced from Debian)
[15:08] <TheLordOfTime> in which case you may want to just attach a patch, so that it can easily be sent to Debian (they don't use bzr nor merging :P)
[15:12] <alo21> penguin42, TheLordOfTime I checked in Debian, and seems that the bug is not reported here
[15:13] <penguin42> alo21: But is it actually in debian; i.e. is the package just  a copy of the debian package so the change should go back into debian anyway?
[15:14] <alo21> penguin42, yea... it comes from debian, and now is x.ubuntu4
[15:16] <alo21> penguin42, What should I do? Check the bug in upstream, and if it is there too, fix it upstream?
[15:17] <alo21> Upstream I mean not debian
[15:17] <penguin42> alo21: Well it's always worth checking upstream to see if they already fixed it; if it affects upstream then you should send your patch upstream; I tend to also attach the patch to the ubuntu bug and also connect the upstream bug report to the ubuntu one
[15:19] <alo21> penguin42, hmm... well. I've never work upstream. So is it the upstream code: http://freecode.com/projects/util-linux
[15:19] <alo21> ?
[15:22] <penguin42> hmm, I was going to check on http://packages.ubuntu.com/raring/util-linux   but the 'homepage' link on there is broken
[15:23] <penguin42> alo21: Yes I think so
[15:25] <TheLordOfTime> i'd also suggest filing this in Debian.
[15:25] <penguin42> yep
[15:26] <TheLordOfTime> if it gets fixed/accepted in Debian (and it likely will), then we can sync the fixed package to Raring assuming it doesn't break anything (some'll check with release and devel teams), and for older releases with the issue it may be SRU-able
[15:26] <TheLordOfTime> but given the proximity to the april release i'm erring on the side of caution, probably more than i should be.
[15:26] <alo21> good
[15:26] <TheLordOfTime> but also i should point this out:
[15:26] <TheLordOfTime> Debian's under freeze.
[15:26] <TheLordOfTime> so the bugfix in Debian may take a while.
[15:27] <TheLordOfTime> and i mean a *while*
[15:27]  * TheLordOfTime checks debian freeze status pretty much daily
[15:28] <penguin42> TheLordOfTime: Debian seems a bit weird on this; they've been stuck since July; some packagers seem to be ok about taking fixes into sid, some not
[15:28] <TheLordOfTime> penguin42, usually i see the packages I monitor hit Experimental
[15:28] <TheLordOfTime> (usually znc, sometimes nginx)
[15:28] <TheLordOfTime> so i usually don't ahve to worry much about sid/testing
[15:28] <penguin42> TheLordOfTime: I got a fix for horgand into sid and that bubbled back into Raring quickly; I was quite surprised
[15:29] <TheLordOfTime> you must've had a sync happen
[15:29] <TheLordOfTime> they have... what... random sync times?
[15:29] <TheLordOfTime> usually i have to request syncs (universe things)
[15:29] <TheLordOfTime> but sometimes syncs pull in things :P
[15:30] <penguin42> TheLordOfTime: I can't tell from the bug 891939 what caused the sync
[15:30] <ubot2> Launchpad bug 891939 in horgand (Ubuntu) "horgand segfaults at startup (due to buffer overflow)" [High,Fix released] https://launchpad.net/bugs/891939
[15:31] <alo21> TheLordOfTime, penguin42 I checked the code (upstream), and seems there is no line about 'keybits' related to my bug
[15:31] <TheLordOfTime> alo21, then its likely a debian-originated manpage bu
[15:31] <TheLordOfTime> g
[15:31] <TheLordOfTime> alo21, or they fixed it upstream and it has yet to trickle into Debian
[15:32]  * penguin42 looks
[15:32] <alo21> TheLordOfTime, It is so weird that some line are different/missed upstream
[15:33] <penguin42> alo21: Not necessarily, it might be a patch added by debian
[15:33] <TheLordOfTime> indeed
[15:33] <TheLordOfTime> i see that a lot of time
[15:33] <TheLordOfTime> s
[15:33] <TheLordOfTime> bleh, stupid keyboard
[15:34] <penguin42> alo21: RIght, if you look at the package you'll see that the util-linux_2.20.1-5.1ubuntu4.diff.gz  contains the patch that adds it
[15:34] <penguin42> (Oddly It doesn't seem to be cleanly done with a debian/patches directly)
[15:36] <alo21> penguin42, so.. is neither related to debain, but Ubuntu only. Right?
[15:37] <penguin42> alo21: Not sure - that's a diff between the upstream and what Ubuntu has
[15:38] <alo21> penguin42, I will download debian source and check
[15:38] <TheLordOfTime> since we're not sure i'd suggest attaching the patch *and* proposing the bzr merge.
[15:39] <TheLordOfTime> so if it has to be fixed in Debian, we can just upstream it
[15:39] <penguin42> yeh
[15:39] <TheLordOfTime> or if it has to be fixed upstream, we send the patch there too.
[15:40] <alo21> penguin42, debian doesn't have mount manpage
[15:40] <TheLordOfTime> ... okay, that's weird...
[15:40] <penguin42> alo21: ?
[15:41] <TheLordOfTime> i found a discrepancy in the php5 package...
[15:41] <alo21> penguin42, sorry, It has
[15:41]  * TheLordOfTime goes to ping the relevant channels about it
[15:41] <penguin42> TheLordOfTime: 'discrepancy' ?
[15:41] <TheLordOfTime> penguin42, they dropped php5-mcrypt, php5-imap, and a couplle of others from the php5 source package, replaced with stuff in Universe
[15:41] <TheLordOfTime> but the universe stuff (if they're versioned right) is using 5.4.6 series of code
[15:42] <TheLordOfTime> and raring has 5.4.9 php5
[15:42] <TheLordOfTime> discrepancy, or breakage, or both?
[15:42] <TheLordOfTime> :P
[15:42] <penguin42> TheLordOfTime: Got split, then main one got updated and universe hasn't got there yet?
[15:43] <TheLordOfTime> the changelog of the drop is raring-only
[15:43] <alo21> penguin42, is there a way to check manpage syntax from a file like file.1?
[15:43] <TheLordOfTime> the changes prevent backporting due to breakage, i'll ask where i need to about it
[15:43] <penguin42> alo21: Not that I'm aware of
[15:44] <penguin42> alo21: I see that bug in my debian vm
[15:44]  * TheLordOfTime needs to backport it for special-case use in a Precise server.
[15:44] <TheLordOfTime> hence PPAs  :P
[15:47] <alo21> penguin42, the bug is in Debian too
[15:47] <alo21> If I well checked
[15:52] <TheLordOfTime> alo21, i can upstream the bug, if you attach a patch to the ubuntu bug i'll forward that ot Debian too (make sure it applies cleanly to Debian)
[15:52] <TheLordOfTime> or you can, if you want
[15:53]  * TheLordOfTime doesn't care :P
[15:53] <alo21> ok. I will make a debdiff
[15:53] <TheLordOfTime> just a patch would suffice
[15:53] <TheLordOfTime> not sure Debian accepts debdiffs :P
[15:53] <alo21> TheLordOfTime, OK
[15:55] <TheLordOfTime> ... assuming my system ever stops being SLOW
[15:55] <penguin42> TheLordOfTime: They take debdiffs
[15:55] <TheLordOfTime> penguin42, oh good, then a debdiff'll suffice.
[15:55] <TheLordOfTime> ... okay, apparently my internet needs slapping, so i can't upstream the bug right now
[15:55]  * TheLordOfTime grabs the diagnostic tools and a hammer and goes to fix his network
[15:58] <penguin42> TheLordOfTime: diffs with the http://dep.debian.net/deps/dep3/  tags at the top seem to make packagers happy; they don't need to do much, it has the links to what it fixes and you get to put your name in it
[15:58] <TheLordOfTime> indeed.
[15:58] <TheLordOfTime> penguin42, assuming you wrote the patch that is
[15:58] <penguin42> yep
[15:58] <TheLordOfTime> my name ends up in the changelogs more than not because of upstream patches :P
[15:59]  * TheLordOfTime pulls upstream patches and applies them in ubuntu, thereby getting his name in debian/changelog at least once
[15:59] <TheLordOfTime> moreso for nginx, apparently *I* am the go-to guy for ubuntu bugfixing for nginx :/
[15:59] <penguin42> TheLordOfTime: Yeh which is a bit weird, if I put a patch in as a diff then I don't appear in changelog but I appear in the diff
[16:00] <TheLordOfTime> and debian/changelog :P
[16:00] <TheLordOfTime> for me, case in point: https://launchpad.net/ubuntu/+source/nginx/1.1.19-1ubuntu0.1
[16:01] <TheLordOfTime> also, for my much older commits to things, before they gave me correct changelog entries...
[16:01] <TheLordOfTime> https://launchpad.net/ubuntu/+source/nginx/0.7.65-1ubuntu2.3 and https://launchpad.net/ubuntu/+source/nginx/1.0.5-1ubuntu0.1
[16:01]  * TheLordOfTime still got his name in the changelogs
[16:01] <TheLordOfTime> albeit the address there is no longer active.
[16:26] <alo21> penguin42, TheLordOfTime have I to apport change in debian manpage, or ubuntu?
[16:28] <penguin42> apport?
[16:28] <alo21> penguin42, bring*
[16:30] <penguin42> alo21: Pick one, doesn't really matter which if they both have the same problem; attach the fix to one, and then whichever way add the debian bug as also-affects on the Launchpad bug
[16:30] <alo21> penguin42, OK
[16:30] <penguin42> alo21: That wya the fix is visible to both of them - just say what you've done
[16:31] <alo21> penguin42, may be the lines are different
[16:32] <penguin42> alo21: If it's just a line number diff then the patch will probably apply cleanly anyway
[16:32] <penguin42> alo21: But like you can apply it to one and then just in the other one just point to the patch
[16:36] <alo21> penguin42, I read guides online. Is there a way to create a debdiff, without make a .dsc file?
[16:39] <penguin42> I think debuild can do it all for you - but I can't remember the details; but if it gets a bit messy a plain diff should do
[16:40] <arand> debdiff only works on (u)debs or dsc files; are you thinking of dpkg-source --commit?
[16:43] <alo21> penguin42, I a build with the debuild, there will be changelog changes too in my debdiff
[16:43] <alo21> if I build* ...
[16:44] <TheLordOfTime> debuild -S will generate a source package
[16:44] <TheLordOfTime> you can do a debdiff then
[16:44] <TheLordOfTime> that's what I do for my bugs, although usually they're security bugs for stuff
[16:44] <TheLordOfTime> so i have to follow a specific changelog format
[16:44] <TheLordOfTime> so even if I don't use the generated source package, i do it for a debdiff
[16:45] <TheLordOfTime> ... which explains all the cruft in my packaging directories
[16:45] <alo21> TheLordOfTime, I think is not good put changelog changes in a debdiff
[16:46] <TheLordOfTime> you and I can argue later on that
[16:46] <TheLordOfTime> security team wants em, some don't
[16:46] <alo21> ok
[16:46] <TheLordOfTime> usually i include them anyways, if Debian says "Remove the changelog" then add an exclude rule when you run debdiff
[16:46] <TheLordOfTime> but i usually include them anyways
[16:46] <TheLordOfTime> now, explain to me why you think its not good to put changelogs into a debdiff
[16:46] <TheLordOfTime> including in a diff, i'd understand
[16:47] <TheLordOfTime> but a debdiff usually *has* to have a changelog entry somewhere
[16:47] <penguin42> lemonsqueeze: What do you expect 'gnee' to do?  It disappears (even on raring) when I hit record but still seems to be running in the background, is that the expected behaviour?
[16:47] <alo21> TheLordOfTime, and, as always, I have to upgrade the number too. Right?
[16:47] <TheLordOfTime> alo21,  for an ubuntu debdiff, yes, you should, as well as follow the number patterns
[16:48] <TheLordOfTime> lemme pull those up forst
[16:48] <TheLordOfTime> first *
[16:49] <TheLordOfTime> what's the version in Ubuntu now?
[16:50] <TheLordOfTime> (note for Debian i usually upload a patch and let the maintainers incorporate the patch :P)
[16:50] <alo21> x_ubuntu4, so I put 5
[16:50] <TheLordOfTime> i think its 4.1
[16:50] <TheLordOfTime> not 5
[16:50] <alo21> why?
[16:51] <TheLordOfTime> just standby
[16:51] <TheLordOfTime> i lost the link, i could poke thes ecurity team but i'd rather poke MOTU to fidn ubuntu versioning guides
[16:52] <TheLordOfTime> the version numbering is all explained already in some wiki doc somewhere, i forgot where it was though
[16:54] <TheLordOfTime> okay, i know this one's under the security team domain, but i follow its versioning numbering pretty much everywhere unless told otherwise (with nginx, znc, php5, etc. this versioning scheme seems to be the standard, even with non-security updates): https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging
[16:55] <TheLordOfTime> so unless MOTU says otherwise, i'd follow that version scheme
[16:55] <TheLordOfTime> s/MOTU/the governing guidelines for that package or that pocket/
[17:02] <TheLordOfTime> jbicha, repeat what you said in -gnome here please.
[17:02] <TheLordOfTime> since i wanted to ping you, but missed you joining here :P
[17:03]  * TheLordOfTime could paste logs, but is currently fighting against  his computer over the clipboard
[17:03] <TheLordOfTime> ah, there we go, here's the info: jbicha (who knows things) said that "the SRU team generally prefers using the same version numbering you'd use for security bugs"
[17:04] <TheLordOfTime> assuming stable release then it falls under that.
[17:28] <alo21> TheLordOfTime, do you think is ok: http://ubuntuone.com/3dUKaoqDwWTi6i6Vf2xuua
[17:28] <alo21> ?
[18:15] <Teufelchen> could anyone have a look, please: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1079801
[18:15] <ubot2> Launchpad bug 1079801 in mesa (Ubuntu) "mysterious application behaviour for the intel "sandy bridge" hardware" [Undecided,New]
[18:24] <penguin42> ooh a mysterious bug
[18:25] <penguin42> Teufelchen: Ah that one; I was the one who was asking for some information a few weeks back on it
[18:25] <Teufelchen> penguin42, i tried to add some information. not sure if it is enough
[18:26] <penguin42> Teufelchen: The problem is it's not obvious that your problem is actually related to sandy bridge; you're seeing crashes - but how do you know it's related to it being a sandy bridge
[18:27] <Teufelchen> i dont know, its intuition. the updates on a different machine with a nvidia graphics chip worked fine yesterday, when compiz related stuff was updated
[18:29] <penguin42> Teufelchen: I'd run a memtest on that machine; get yourself an older memtest86 binary; the one on the Quantal image is very broken
[18:29] <Teufelchen> system rescue cd?
[18:30] <Teufelchen> what if the memtest shows no errors?
[18:30] <penguin42> yeh, just get a rescue cd or any ubuntu install cd (older than Quantal) and run a memtest for a few hours
[18:30] <penguin42> if memtest doesn't show any errors then you really have a bug
[18:30] <Teufelchen> i will add the result to the bug report comments then
[18:30] <Teufelchen> planning on running the tests tonight
[18:31] <penguin42> Teufelchen: I believe the bug in quantal memtest is it gives false errors in pass 7; so just watch out for that
[18:32] <Teufelchen> i have a burned CD of system rescue cd 3.1.1
[18:32] <Teufelchen> thanks a lot of caring about this issue, penguin42
[18:34] <penguin42> Teufelchen: My dad runs with a sandybridge quantal system, we had a lot of problems getting it working, I ended up running on a daily kernel build, which is the other thing you could try - but that symptom was tht it just didn't boot when connected to certain monitors
[18:34] <Teufelchen> also not acceptable
[18:35] <Teufelchen> something is borked with these cheap and energy efficient chips, regarding support
[18:35] <Teufelchen> like somebody would try to avoid that they become popular
[18:36] <penguin42> don't read a conspiracy into it just being screwed
[18:36] <Teufelchen> okay! :)
[23:30] <notgary> Could someone please mark the Ubuntu task on this bug report as triaged and set it to a medium priority please? https://bugs.launchpad.net/rhythmbox/+bug/1038738. I think medium because it matches a number of the points mentioned here https://wiki.ubuntu.com/Bugs/Importance
[23:30] <ubot2> Launchpad bug 1038738 in One Hundred Paper Cuts "Rhythmbox does not show the Library Location" [Medium,Triaged]
[23:31] <xnox> notgary: i believe it's expected behaviour.
[23:37] <notgary> xnox, It is indeed designed to do that, but the design is bad the developer has even admitted so. If someone sends him a patch to improve it before he gets round to it, then he'll merge it in
[23:38] <xnox> notgary: sure, but that's upstream bug and a hard one =)
[23:39] <notgary> xnox, is it really that hard? The multiple locations already have entries in gconf. I'd have thought it would be just a case of rejigging the interface for managing them.
[23:40] <xnox> notgary: by default we set two locations: ~/Music & the one for Ubuntu One Music store downloads. Ideally users should see & be able to change the first one, but not the second one.
[23:40] <xnox> because then their music store won't work.
[23:40] <xnox> but there are other music stores as well... each with their own download locations...
[23:41] <xnox> so there needs to be different "types" of music locations..... with ability to enable/disable (for music) and edit (for personal locations)
[23:41] <xnox> for music sotres that is.
[23:47] <notgary> xnox, Ah, now I get it. I think I'll still have a go at it, but bearing all that in mind.