 thank you
[01:18] <lool> pitti: I bisected udev; thanks for the idea!  it was rather painful as I've hit many different races during boot, but the revision which caused me to be dropped in an initramfs prompt was "libudev: monitor - use SOCK_NONBLOCK"
[01:18] <lool> pitti: Unfortunately, I've build 171 ubuntu1 + this patch reverted, and my system wouldn't boot, one error message on screen related to dmsetup
[01:18] <lool> pitti: I wanted to mention that I use LVM
[01:19] <lool> pitti: During tests, I've hit races with mountall and fsck checks, it was hard to tell whether it was another regression from 171 or an already existing bug which just got more visible
[01:22] <lool> pitti: after looking at the other commits, I can't see another one in 171 which would introduce more races (except the above SOCK_NONBLOCK); the rest is mainly changes to symbols and to the systemd configs
[01:54] <lool> pitti: Ok; fixed my system now: both your ubuntu2 with the reverted 171 changes and my 171 ubuntu1 + reverted broken commit from bisect were failing to boot in strange ways; only some LVM volumes were brought up, /home was missing; I disabled the /home volume and enabled it again, and everything worked with both your ubuntu2 package and with my 171ubuntu1 + reverted broken commit
[01:55] <lool> pitti: So the bisected commit was the right one can be patched on top of latest udev
[01:55] <lool> I'm pushing a package to my PPA for others to test
[02:03] <Keybuk> I wonder why that breaks things
[03:41] <cdbs> lool: So the udev fix is now in the archive?
[03:42] <cdbs> Even I get an initramfs shell at boot
[03:46] <cdbs> okay, pitti reverted those
[05:25] <Gacy> http://www.blogtalkradio.com/billywalshe/2011/06/01/youre-too-chicken-shit-to-call-into-this-radio-show?ie8c=0
[05:26] <micahg> !offtopic | Gacy
[05:26] <micahg> that wasn't what I expected that to do...
[05:26] <Gacy> oh
[05:26] <micahg> second part applies though
[05:33] <pitti> Good morning
[05:33] <stgraber> morning pitti
[05:34] <StevenK> Hai pitti
[05:34] <pitti> lool: ah, thanks for bisecting
[06:08] <TheMuso> c
[06:27] <pitti> lool: I changed the udev bzr back to 171 plus SOCK_NONBLOCK reverted, but I'll upload it after a1 only; once Kay is up, I'll discuss with him
[07:08] <micahg> if I"m going to have an armel specific  version of a source package, should I append -arm or -armel?
[07:15] <infinity> micahg: Ideally, you shouldn't have one at all...
[07:15] <infinity> micahg: What's the scenario that's preventing you from shipping a patch in the regular source package and only applying it for ARM?
[07:15] <micahg> infinity: I know, it's a special case :)
[07:15] <infinity> micahg: Or having ARM-specific rules in debian/rules, etc?
[07:17] <StevenK> micahg: And if you're having an armel specific version of the source, are you going to Conflict with the non-armel, or change them too? What about the rdepends?
[07:17] <StevenK> This is a rabbit hole.
[07:17] <micahg> no, it's for chromium, since the arm build takes over a day and we have no advanced notice, I split the source in the stable release so we can get the non-arm binaries out faster
[07:17] <infinity> micahg: Err, but we release everything at once anyway.  I'm failing to see how this helps...
[07:18] <infinity> micahg: If glibc and gcc get to suffer, so does chromium?
[07:19] <micahg> I didn't really want to start the why debate...but in short, there's no USN so they can be published as they're ready
[07:19] <infinity> micahg: Which is true even if you release while ARM is still building...
[07:19] <micahg> infinity: no, you can only copy a source once
[07:20] <infinity> micahg: Yes, and?
[07:20] <infinity> micahg: You can then release the binaries later.
[07:20] <infinity> micahg: We've been doing that for years.
[07:20] <micahg> infinity: no, the binaries + source can only be copied once
[07:20] <infinity> micahg: I suspect I'm not the person you want to argue with about this.  At all.
[07:20]  * micahg didn't want to argue with anyone
[07:21] <infinity> micahg: You can release binaries for architectures whenever you feel the urge.
[07:21] <infinity> micahg: A USN could, in theory, be source-only, if someone thought that was a sane thing to do (which it isn't), and you could trickle the arches down one at a time.
[07:21] <micahg> soyuz doesn't work like that AFAIK
[07:21] <infinity> It really does.
[07:22] <sbeattie> infinity: that's not what the security team's been told.
[07:23] <infinity> sbeattie: They were lied to.  Or there was a miscommunication.
[07:23] <infinity> sbeattie: Either way, I don't see us splitting other long-building packages for the sake of one slow arch.  Still not seeing the unique snowflake case.
[07:24] <infinity> sbeattie: But at the level we're dealing with here, BPRs are all tied to SPRs, yes, but there's no reason you need to move/copy all the BPRs with an SPR.
[07:25] <dholbach> good morning
[07:26] <wgrant> infinity: Due to the current way that security updates are unembargoed, that's not really possible at the moment.
[07:26] <wgrant> We should be able to.
[07:26] <wgrant> It's easy enough to do.
[07:26] <wgrant> Just need to expose the interface.
[07:26] <wgrant> But we've not been asked with any significant importance.
[07:27] <wgrant> micahg: So, please ask for LP to be fixed before you start implementing such hacks!
[07:27] <infinity> wgrant: I suspect the above is significant enough, before people get unique snowflakey more. :P
[07:27] <wgrant> infinity: Probably.
[07:27] <infinity> wgrant: What's the issue?  I only vaguely recall the security-on-PPA hackery (I was doing security when it was a proper pocket)... Are the SPRs moved/wiped with a release?
[07:27] <wgrant> Basically, delayed copies are a vile hack.
[07:27] <infinity> wgrant: Thus leaving the BPRs effectively orphaned?
[07:27] <micahg> wgrant: I thought I talked to the relevant parties, I guess I forgot to chat with you about it :)
[07:27] <infinity> wgrant: Cause that's about the only way I could see it breaking.
[07:28] <micahg> wgrant: they're not in the private PPA
[07:28] <wgrant> micahg: Unless you talked to bigjools or me or possibly Stevenk, you were probably misinformed.
[07:28] <wgrant> infinity: So, there are two ways this breaks:
[07:29] <wgrant> 1) The copy checker will forbid copies when the source has pending builds, because multi-stage copies don't work very well. This can be easily fixed once multi-stage copies are.
[07:29] <infinity> wgrant: (1) isn't an issue, it's a tool that needs unbreaking. :)
[07:29] <wgrant> 2) Delayed copies (used for private copies) create a fake PackageUpload, and more than one of those for a single source won't be accepted into a particular suite.
[07:29] <wgrant> 2 will go away once StevenK deletes delayed copies in a few weeks.
[07:30] <wgrant> 3) The copy APIs provide no facility to copy binaries, only sources. And they're not set up to copy only missing things.
[07:30] <wgrant> Well, for binaries it already mostly works. It won't create duplicate publications.
[07:30] <wgrant> But it will republish the sources and break a few worlds.
[07:30] <infinity> Republishing source is a non-issue, IIRC.
[07:31] <infinity> It just no-ops at the level that any human cares about it.
[07:31] <wgrant> It will create a new publication.
[07:31] <wgrant> It might not break much, but it's undesirable.
[07:31] <wgrant> and easily fixable.
[07:31] <infinity> Well, see the "any human" bit. :)
[07:31] <wgrant> Heh.
[07:31] <infinity> Pretty sure we used to do it all the time.
[07:31] <infinity> And if it made Soyuz cry, Celso never slapped me.
[07:31] <wgrant> infinity: Pre-s-i-s, maybe.
[07:32] <wgrant> Or back when the copier was less pedantic.
[07:32] <wgrant> It was made more bullet-proof to stop PPA users from killing themselves.
[07:32] <micahg> wgrant: so, should we have a longer chat later today?
[07:32] <infinity> Hahahaha.
[07:32] <StevenK> You mean back when the package copier was er, Celso?
[07:32] <infinity> But yes, I'd love to see people not attempting these crazy hacks.
[07:32] <wgrant> micahg: I think so.
[07:32] <micahg> wgrant: what time do you start (UTC)?
[07:32] <wgrant> micahg: This is a reasonable thing for a maintenance squad to take on in a post-critical era (probably Septemberish)
[07:32] <infinity> StevenK: Well, okay, there was a time when copying packages was actually some SQL hacks that I'd do.
[07:33] <infinity> StevenK: But no, I vaguely recall having something more fancy.
[07:33] <wgrant> micahg: 2300-0800 are my coreish hours.
[07:33] <wgrant> micahg: But I'm often floating around several hours later
[07:33] <wgrant> infinity: Sure you're not recalling the wonderful dak hack?
[07:33] <micahg> wgrant: ok, feel free to grab me when you start tomorrow, I should be around
[07:33] <infinity> wgrant: No, that would be entirely different.
[07:33] <wgrant> micahg: Will do.
[07:34] <micahg> wgrant: thanks
[07:34] <infinity> wgrant: With DAK, it was a series of real uploads.
[07:34] <wgrant> infinity: Yeah :/
[07:34] <infinity> wgrant: But I'm talking pocket copying, versus PPA->pocket insanity which SiS uses.
[07:34] <infinity> wgrant: And I'm pretty sure pocket copying, and triggering source republishing, and other fun arch-skew issues were a non-issue, in practice.
[07:34] <wgrant> infinity: Ah, that must have been before the pedantry.
[07:34] <infinity> wgrant: Though I can see how they're irksome in theory.
[07:35] <wgrant> infinity: Now it will outright forbid those copies, because there are builds in the wild.
[07:35] <wgrant> (somewhat draconian, but the copier is a mess and doesn't handle duplication perfectly)
[07:35] <infinity> wgrant: I'd respectfully claim that's broken. :P
[07:35] <wgrant> It's all being cleaned up at the moment.
[07:35] <wgrant> Which will make it feasibleish to fix in a few months.
[07:35] <infinity> wgrant: Since BPRs have no relation to SPRs as a whole unit, only as a related child.
[07:36] <wgrant> infinity: Right.
[07:36] <wgrant> infinity: But it's a bit messy.
[07:36] <infinity> wgrant: Story of Soyuz's life, yes. ;)
[07:36] <wgrant> infinity: Because normally on a copy we create missing builds in the target.
[07:36] <wgrant> infinity: For multi-stage copies we'd have to suppress that.
[07:37] <wgrant> Basically, binaries are messy, everyone should just use source :)
[07:37] <infinity> wgrant: Copies creating builds in the target should probably be the exception, not the rule.  Source-only copies (say, in PPAs), and new-release mass copies.
[07:37] <StevenK> wgrant: Who do you think we are, Gentoo?
[07:38] <infinity> wgrant: (And yes, that's an argument I probably should have made years ago)
[07:38] <wgrant> infinity: I was about to say ENOT2006
[07:38] <StevenK> infinity: i-f-p does not use the package copier, thank $DEITY
[07:38] <infinity> wgrant: Because the "copy-creates-build" semantic is just as broken if you have an FTBFS in security and then copy to updates and create an updates build, for instance.
[07:38] <infinity> wgrant: Which you really don't want.
[07:38] <wgrant> infinity: Yes.
[07:39] <wgrant> infinity: I have long argued that this needs to be rethought.
[07:39] <wgrant> But it's hard, particularly in the new structure.
[07:39] <wgrant> (there is no Soyuz team)
[07:39] <infinity> I'll bottle some essence of cprov and mail it to you.
[07:39] <wgrant> Heh
[07:40] <infinity> StevenK: Except, note the irony that i-f-p is one of the few times when you DO want builds created. ;)
[07:40] <StevenK> Heh
[07:40] <wgrant> infinity: ... and it doesn't!
[07:40] <wgrant> queue-builder used to.
[07:40] <infinity> Yup.
[07:40] <wgrant> But we destroyed queue-builder.
[07:40] <wgrant> Because it is evil.
[07:40] <infinity> I remember painful q-b runs after opening a new release.
[07:40] <wgrant> Heh.
[07:41] <StevenK> Oh, that took many hours?
[07:41] <infinity> It would take a whole day at UDS.
[07:41] <StevenK> Ugh
[07:41] <wgrant> queue-builder took 30 minutes even in a good case.
[07:41] <infinity> I'd keep popping open a screen session to tell people "no, not there yet".
[07:41] <infinity> Good times.
[07:41] <infinity> FSVO "good".
[07:42] <StevenK> Haha
[07:50] <wgrant> Hmm, using karma for search works pretty well.
[07:54] <didrocks> good morning
[07:56] <pitti> $ sudo rm -r /home/dchroot/dapper/
[07:57]  * pitti sheds a tear
[07:57] <pitti> dragon vs. duck anyone?
[07:57] <wgrant> Oh, already? I thought it was next week.
[07:57] <wgrant> Sad.
[07:58] <infinity> Poor Dapper.
[07:58] <wgrant> Means we can upgrade the buildds, yay.
[07:59] <pitti> wgrant: yes, but as we don't have a pending tzdata update, I don't need it any more
[07:59] <infinity> To?
[08:00] <infinity> wgrant: Unless CAT has an urge to start supporting their own kernels again, I imagine the thing stopping buildds from being upgraded is the lack of Xen dom0 kernels in newer releases.
[08:00] <infinity> (But that's just speculation)
[08:02] <wgrant> infinity: Yeah, dom0 will stay on hardy, but I don't care about dom0.
[08:02] <wgrant> launchpad-buildd doesn't have to work there.
[08:02] <infinity> wgrant: Fair point.
[08:24] <jaap_> goodmorning
[08:24] <jaap_> i'am trying to install FTjam
[08:24] <leoquant> goodmorning jaap_
[08:25] <jaap_> i don't can use the software center of install by apt-get
[08:25] <jaap_> i  need to changes some string in the software
[08:26] <leoquant> so you are modifying software to improve it
[08:27] <jaap_> yes to compile argyll
[08:28] <leoquant> ok seems difficult  ツ
[08:31] <jaap_> hello??
[11:28] <hrw> pitti: https://launchpad.net/ubuntu/+source/gcc-4.6-armel-cross exists now. can I get PPU permissions for it (as it was given me by DMB)?
[11:28] <hrw> pitti: package got uploaded into NEW queue
[11:39] <hrw> cjwatson: archive administration page lists you as today's admin. can I get gcc-4.6-armel-cross from NEW to archive? I can answer any questions about package.
[11:53] <lool> dholbach, jibel: https://launchpad.net/~lool/+archive/ppa/+build/2539347 (amd64) https://launchpad.net/~lool/+archive/ppa/+build/2539348 (i386) has udev 171 + reverted patch; it fixes the boot with real 171 for me
[11:55] <lool> pitti: You mentioned udev' bzr this morning, but yesterday it was failing to import http://package-import.ubuntu.com/status/udev.html#2011-05-16 09:17:00.101675
[12:05] <cjwatson> hrw: I'm on holiday today
[12:10] <hrw> cjwatson: sorry then
[12:10] <pitti> lool: I meant the ubuntu package branch at https://code.launchpad.net/~ubuntu-core-dev/ubuntu/natty/udev/ubuntu
[12:10] <pitti> hrw: added
[12:14] <hrw> pitti: thank you
[12:24] <dholbach> lool, confirmed
[12:31] <lool> dholbach: cool, thanks
[12:31] <lool> pitti: ^
[12:41] <pitti> lool: do you have any idea what actually happens in the initramfs? is udevd running? does udevadm info --export-db work, for example?
[12:41] <pitti> it certainly seems to be a race condidtion, as it doesn't happen everywhere
[12:58] <lool> pitti: No, I didn't know how to debug this much; I saw that some devices by UUID had been created, I'm getting messages from udev that it can't open /dev/null and such, so it's definitely being started
[12:59] <lool> pitti: if you like, we can try investigating together
[12:59] <pitti> I'd still love to be able to reproduce this
[12:59] <pitti> I still didn't try installing the faulty udev on my mini 10
[13:00] <pitti> kvm and my laptop work
[13:00] <lool> pitti: are you using lvm?
[13:00] <pitti> lool: no, just plain ext4 /
[13:00] <lool> dholbach, jibel: You folks using LVM?
[13:00] <pitti> I think jibel reproduced it with the faulty desktop iso
[13:03] <soren> Where can I find a list of things that changed in python 2.7.2? I have a test case that fails under 2.7.2, but works under 2.7.1.
[13:05] <soren> Err.. /me tries in #python instead
[13:07] <jibel> lool, pitti , right, default desktop install with the faulty iso.
[13:19] <alkisg> Hi, in bug #737728 I put a "verification-done" tag but it was removed and "verification-needed" was inserted without explanation. Why? Is it some kind of meta-bug which needs some special form of verification? If so, how can I identify such bugs so that I don't put tags on them?
[13:29] <pitti> alkisg: kernel is special, only the QA team signs them off
[13:29] <alkisg> pitti: so when I see verification-needed in kernels, I shouldn't put verification-done, right? Thanks.
[13:29] <pitti> feedback is still appreciated, of course
[13:29] <pitti> alkisg: well, for "real" kernel bugs you are welcome to
[13:30] <pitti> just not for the tracking meta-bugs
[13:30] <alkisg> Got it. Thanks for the explanation.
[13:45] <mterry> @pilot in
[14:01] <pitti> mterry: happy flying
[14:01] <mterry> pitti, :)
[14:05] <sladen> my goodness. soft freezes already
[14:05] <sladen> development moves fast
[14:07] <Laney> still looks like a long way if you look at the release schedule :-)
[14:13] <dholbach> lool, kvm
[14:16] <lool> dholbach: kvm or lvm ? :-)
[14:16] <\sh> moins
[14:17] <dholbach> lool, whatever natty qemu-kvm gives me
[14:18] <lool> dholbach: ok
[15:44] <achiang> chrisccoulson: what does the ~mfs mean in this version string? 4.0.1+build1+nobinonly-0ubuntu0.11.04.1~mfs~lucid1
[15:56] <EtienneG> Looking for the release schedule of the lts-backport kernel, wondering whent he natty one will show up in lucid.  Anybody know?
[16:05] <pitti> ScottK: what kind of shrinking did we use to do in pkg-kde-tools' cdbs rules?
[16:06] <pitti> ScottK: we recently moved the remaining ubuntu specific bits of gnome.mk/debhelper.mk to pkgbinarymangler, seems we should just add the KDE bits there as well?
[16:09] <JontheEchidna> pitti: lzma compression
[16:11] <JontheEchidna> might need to be added to the new dhmk magic from Debian
[16:13] <JontheEchidna> pitti: Yeah, this chunk is in the old debian-qt-kde.mk but not in the new one: http://paste.ubuntu.com/615911/
[16:16] <JontheEchidna> oh, but it also uses the kde.pm sequence, which should include lzma compression there....
[16:21] <ScottK> JontheEchidna: I think we need to look and make sure.
[16:21] <ScottK> pitti: Is the changelog symlinking in the pkg-binarymangler now?
[16:25] <sladen> doesn't each symlink still take up a full block on the disk?
[16:26] <pitti> ScottK: yes, it is
[16:27] <pitti> sladen: depends on the file system; but certainly not in .debs or the squashfs
[16:28] <ScottK> pitti: We may be OK then if the lzma situation is good.  Fortuitous that you moved stuff.
[16:40] <mterry> @pilot out
[16:44] <JontheEchidna> ScottK: we seem to have pulled GTK in to the CD via libcanberra0
[16:44] <JontheEchidna> that is at least part of our space problems
[16:44] <ScottK> JontheEchidna: Ah.  Well that would do it.
[16:44] <ScottK> So we can work on that for Alpha 2.
[16:44] <ev> mvo: can you point me in the direction of this GIR wrapper you were talking about earlier?
[16:45] <JontheEchidna> apachelogger: ^
[16:47] <mvo> ev: bzr+ssh://bazaar.launchpad.net/~kamstrup/%2Bjunk/giraffe/
[16:48] <ev> mvo: thanks!
[16:48] <mvo> yw
[16:53] <apachelogger> JontheEchidna: oh good
[16:53] <apachelogger> JontheEchidna: you should split the gtk stuff out :P
[16:54]  * apachelogger will likely not have time until tomorrow afternoon
[16:54] <JontheEchidna> it's not a priority for alpha1, so there should be plenty of time for you to fix it :P
[16:55] <apachelogger> JontheEchidna: oh, ok
[16:56] <apachelogger> JontheEchidna: I have an upload pending for libcanberra anyway
[16:56] <JontheEchidna> cool
[16:56] <apachelogger> I'll do the changes on my way to randa and upload past alpha
[16:56] <JontheEchidna> apachelogger: technically I think the GTK stuff is already split out, but libcanberra0 depends on the gtk package
[16:56] <apachelogger> IIRC it should only depend on glib
[16:57] <apachelogger> it was particularly designed to not depend on arguable stuff :P
[16:57] <JontheEchidna> well somehow libcanberra-gtk0 made it on to the CD :P
[17:08] <apachelogger> JontheEchidna: maybe it likes us
[19:11] <smoser> ok. i'm looking at build output of a ubuntu cloud image: http://uec-images.ubuntu.com/lucid/20110531.1/
[19:11] <smoser> this image was built yesterday, but did not receive 1.1.1-2ubuntu5 from lucid-updates.
[19:12] <smoser> instead it received 1.1.1-2ubuntu2 (release).
[19:13] <smoser> it *did* get other things from -updates. looking at https://launchpad.net/ubuntu/+source/pam it looks like maybe there was just a bad-timing snafu in correlation with security update 1.1.1-2ubuntu5.3 .
[19:13] <smoser> anyone else able to explain that ?
[19:23] <geser> doko_: is the "python3.2-config --ldflags" behaviour correct with including the libs to link too? ("python3.2-config --libs" just lists the libs as expected)
[19:36] <slangasek> smoser: there was a severe SRU regression in pam yesterday that led to 1.1.1-2ubuntu5.2 being marked unreadable to block the damage from spreading
[19:37] <ScottK> So that means 'feature.  not-a-bug.'
[19:37] <slangasek> smoser: as a result, apt would probably have fallen back to the release pocket during that window, since 1.1.1-2ubuntu5.2 was unavailable, 1.1.1-2ubuntu5.1 was superseded, and 1.1.1-2ubuntu5.3 was not yet available
[19:37] <smoser> slangasek, thank you. bad timing then for me :-(
[19:39] <mdeslaur> smoser: sorry for that. my bad.
[19:40] <lifeless> smoser: hi
[19:40] <lifeless> smoser: jkakar says you've worked with / build a highly component-based thing before
[19:41] <lifeless> smoser: in Launchpad we're just starting down a migration to such a setup, and I'd like to tap your knowledge, if I may :)
[19:41] <elmo> lifeless: i thought that was smagoun?
[19:41] <smoser> "highly component based thing"
[19:41] <lifeless> hahhha
[19:41] <lifeless> smoser: sorry.
[19:41] <smoser> whew
[19:41] <lifeless> smoser: E-EARLY-MORNINGS
[19:41] <lifeless> elmo: thank you
[21:09] <sebner> persia: I'm wondering if you ever become DD (thinking about your #1 bug) :P
[21:15] <psusi> persia: could you get around to adding me to universe-contrib per last week's DMB?
[21:20] <geser> psusi: done
[21:21] <psusi> geser: yay!  thanks!
[21:21] <Laney> we have been naughty on the minutes
[21:23] <geser> Laney: we (DMB) should perhaps update the team description for https://launchpad.net/~ubuntu-dev a little bit
[21:23] <Laney> geser: yeah, and rename https://launchpad.net/~universe-contributors to UCD probably
[21:27] <geser> Laney: if I didn't miss anything only the bzr package set and PPU for John Rigby needs to be done from the last meeting
[21:34] <Laney> not sure, I haven't been following the outcomes
[22:24] <dart> Hello, I am experiencing some regression after a new natty SRU but I am not 100% sure
[22:25] <jdstrand> dart: what is the regression?
[22:26] <dart> after a fix to this bug --> Bug #774938, My pointer has started behaving oddly. I have also commented on the bug report.
[22:28] <dart> I am not sure if its related to this update or not but i started experiencing this problem only two days back.
[22:32] <ScottK> !regression
[22:32] <ScottK> Sigh.
[22:32] <dart> Downgrade to earlier xorg-server will be safe?
[22:33] <ScottK> !regression-alert
[22:33] <slangasek> hoboy
[22:34] <ScottK> It's probably a bit late for blacklisting, but here you go ...
[22:34] <slangasek> dart: can you try downgrading the package to the natty release version, to verify that the problem is resolved?
[22:35] <dart> Ok. I will do it. It is safe right?
[22:35] <slangasek> dart: please also file a bug with 'ubuntu-bug xserver-xorg-core' and attach /var/log/apt/term.log
[22:35] <dart> I got some data should i take a backup
[22:36] <slangasek> dart: nothing in this world is provably safe; downgrading that package won't eat any data from your system, however
[22:36] <ScottK> Downgrading the package should be safe.   You should always have current backups, I don't think you particularly need them more because of downgrading the package.
[22:37] <dart> ok...I am doing it now
[22:37] <ScottK> You'll need to restart X after the downgrade.
[22:37] <dart> ok wait
[22:39] <dart> The exact package is xserver-xorg-core or anything else?
[22:39] <ScottK> xserver-common as well
[22:39] <dart> ok
[22:42] <slangasek> cnd: hey there!  dart is reporting cursor misbehavior after upgrading his X server; has commented on the bottom of bug #774938
[22:43] <cnd> slangasek, thanks
[22:43] <slangasek> ah, dart has just disconnected, presumably to test his X server downgrade
[22:43] <cnd> ahh
[22:44] <slangasek> I've asked him to file a new bug as well, so we get the apport goodness
[22:44] <cnd> good
[22:44] <cnd> thanks
[22:44] <ScottK> If we killed his computer and don't have to deal with it, that's a form of win too.
[22:44] <ScottK> ;-)
[22:44] <cnd> heh
[22:44] <cnd> any luck?
[22:45] <dart> hello, I downgraded xorg server and the problem seems to have gone but I need more time to confirm this
[22:45] <cnd> dart, is this with a trackpad?
[22:45] <cnd> or a touchscreen?
[22:45] <cnd> or?
[22:46] <dart> I am mostly using external mouse. No touchscreen.
[22:47] <cnd> dart, can you do the steps noted here: https://wiki.ubuntu.com/Multitouch/Testing/uTouchEvEmu#Debugging
[22:48] <dart> There is a difference between touchpad and mouse sensitivity on my system. Its more noticeable with external mouse
[22:48] <cnd> skip steps 3, 4, and 9
[22:48] <cnd> and instead of looking for a touch device node, use the node for your mouse
[22:48] <cnd> let me know if you need help figuring out what event node it is
[22:51] <dart> ok  m doing it now
[22:52] <cnd> once you have the device.prop and device.record files, upload them to the new bug you created
[22:55] <dart> its /dev/input/event7 for optical mouse
[22:55] <cnd> ok
[22:59] <dart> how long it takes for evemu-record?
[23:00] <cnd> dart, it should time out after about 10 seconds
[23:00] <cnd> 10 seconds of no motion
[23:00] <dart> no motion? I moved my pointer around
[23:00] <cnd> yeah, move your pointer, then stop and wait 10 seconds
[23:01] <dart> not sure if i did like this...should I do it again coz i moved pointer all the time
[23:02] <cnd> dart, I just need a recording exhibiting the bug
[23:02] <cnd> it can be 5 seconds of motion
[23:02] <cnd> or it can be more
[23:04] <dart> ok, one last thing...I am currently doing this with stock xorg server in natty repos and not the SRU one. That would be fine?
[23:04] <cnd> yeah
[23:04] <dart> ok
[23:07] <dart> where are these prop and record files are stored?
[23:08] <cnd> if you copy and pasted the commands, they should be saved in the directory in which you ran them
[23:08] <cnd> probably your home directory
[23:08] <ScottK> cnd: Should he do it against with the xserver from -updates?
[23:08] <dart> ok got them
[23:08] <cnd> ScottK, we are recording events from the kernel, so it doesn't matter what the x server is
[23:08] <ScottK> Ah.  OK.
[23:09] <cnd> dart, which bug have you created for this issue?
[23:10] <dart> I have yet to create...its 3 am here I am a bit slow in doing things : )
[23:10] <cnd> ahh
[23:10] <cnd> np
[23:10] <cnd> dart, when you create the bug, please subscribe me
[23:10] <cnd> my launchpad id is chasedouglas
[23:10] <dart> ok
[23:10] <cnd> in fact, instead of subscribing just assign it to me
[23:11] <cnd> I have to go to an appointment now, but I'll be back later to check on things
[23:11] <cnd> thanks!
[23:22] <dart> in apport  should i select this -->  the problem started after system software update or I don't know would be fine
[23:22] <ScottK> Either is fine, but after update would be better.
[23:22] <dart> ok thanks
[23:34] <dart> all right done -- Bug #791596
[23:36] <dart> ScottK, Plz check bug. Do I need to add some more information?
[23:47] <RAOF> dart: I've assigned that bug to cnd as he asked; he's got the most insight into X input behaviour.  You should probably attach /var/log/apt/term.log to the bug as well, but it looks like you've got all the info cnd asked for.
[23:47] <nemo> Hey guys, I ran into a ubuntu forum article that fixed suspend/hibernate on my Sony VPC-F11 - is there an ubuntu wiki page where I can check to see if this problem is reported?
[23:48] <nemo> I'd just like to make sure it gets picked up for future releases.  Fix from forums was adding acpi_sleep=nonvs to boot params
[23:50] <nemo> Other issue was it was totem (not mplayer) having a black screen until I set output to No Xv in gstreamer
[23:51] <nemo> Oh, and it seems helpless to pick up the built in microphone, but since I haven't found a fix for that yet, no point in reporting it anywhere
[23:51] <RAOF> nemo: For the suspend issue you'd be wanting to check the bugs against the kernel on lanchupad.net.
[23:52] <nemo> RAOF: I was hoping there was maybe some laptop compatibility database I could just dump these issues in :)
[23:52] <nemo> but 'k. I'll stick with "check for existing bugs and report as necessary"
[23:52] <RAOF> I'm not sure why you'd think that just because you can't fix it you shouldn't report it!  Launchpad is full of bugs that people reported but couldn't fix :)
[23:53] <nemo> RAOF: 'cause I was hoping to add to some list of known fixes - I certainly do report bugs I don't know how to fix on launchpad
[23:54] <RAOF> There's an ad-hoc collection of pages on wiki.ubuntu.com.  There's also an effort to get more structured reporting happening, but I'm not sure where that is :)
[23:54] <nemo> I'm playing around with /usr/share/doc/alsa-base/driver/HD-Audio-Models.txt.gz hoping I can find a magic profile that fixes the mic
[23:55] <nemo> RAOF: ah, yeah. that's what I'd more be looking for. something like the Linux on Laptops writeups, but more rigorous and ubuntu version focused
[23:57] <dart> RAOF, I have attached term.log