[21:27] <Texou> hi
[21:30] <Texou> I'm testing unity and have a question: how can I move a shortcut from the panel to the launcher (Alt-F10 I have everything, I'd like to have Brasero in the Launcher (alt-f1). How can I do (I only have success with a mouse)?
[22:04] <Texou>  dconf-editor &/j #vinux


[18:27] <wendar> I'd like to get that first lens pushed through
[18:27] <wendar> any meta thoughts on the repo layout?
[18:27] <wendar> should I send it to vote?
[18:28] <wendar> sounds like mhall119 has a stack to push through once we settle on the layout for the merged repos
[18:29] <wendar> mhall119: once we get through the list of Oneiric lenses, we can start on the Precise ones, have those lined up and ready to go before the Precise launch
[18:33] <mhall119> wendar: already have a list :)
[18:34] <mhall119> wendar: in fact, if you PM me your G+ email, I'll share the doc with you
[18:34] <wendar> cool, will do
[18:44] <wendar> mhall119: I'm assuming the music scopes are compatible with the default Music Lens
[18:45] <mhall119> wendar: I'm assuming so, yes
[18:45] <wendar> we can't do those with our merged repository strategy, will need to talk to the Music Lens developers on how they want to handle it
[18:46] <wendar> if they're okay with it, I'd say we do one merged source package for the collection of music-related scopes
[18:46] <wendar> the lens is a main package, which extras can depend on
[19:07] <ajmitch> wendar: right, I think that's a good idea & the layout you proposed looks good
[19:17] <stgraber> wendar: I'll "try" to have a look this afternoon, was planning on doing that over the weekend but ended up not being around much
[19:30] <ajmitch> stgraber: you're not the only one :)
[19:31]  * ajmitch is feeling a bit guilty about wendar doing all the work this month
[20:14] <wendar> ajmitch: aw, it'll be someone else's turn next month :)
[22:04] <ajmitch> wendar: unity-lens-graphicdesign is a native package? (version is 0.1)
[22:11] <stgraber> yep, I think that makes sense considering it's a mix of multiple sources
[22:11] <stgraber> and 0.1 should ensure it's going to be lower to whatever might end up in the archive at some point
[22:13] <ajmitch> I'd have thought you'd want extras in the version at least
[22:13] <ajmitch> something to match how versioning is done for the other packages
[22:14] <ajmitch> if you really want, I believe you can have different versions for the binary package than the source package :)
[22:18] <stgraber> yeah you can can but it's black magic at this point ;)
[22:18] <ajmitch> true
[22:18] <ajmitch> it warped my mind when I saw it being done
[22:18] <stgraber> I guess 0.1~extra1~11.10 or similar could work (if dpkg doesn't explode telling us a nativ package shouldn't have such weird version number)
[22:18] <ajmitch> I don't think it should complain
[22:18] <ajmitch> I think dpkg even treats 0~0 as valid
[22:22] <ajmitch> so for this lens & scope set, they're all by the same author at the moment?
[22:33] <wendar> ajmitch: it's 0.1-0extras11.10.1~ppa1  in the PPA
[22:33] <wendar> ajmitch: maybe I didn't push that change to the remote repo
[22:34] <wendar> ajmitch: bzr builddeb refuses to accept extras version numbering
[22:34] <wendar> ajmitch: so I've been doing development with native version numbers, and changing it at the end before I push to the ppa
[22:34] <ajmitch> wendar: right, I should have checked the PPA as well, sorry :)
[22:34] <wendar> so the final version will be 0.1-0extras11.10.1
[22:34] <ajmitch> it probably refuses to accept the - in the version
[22:35] <wendar> actually, what it complains about is combining "3.0 (native)" format with a non-native version
[22:35] <ajmitch> it may be worth changing it from 0.1-0extras11.10.1 to 0.1~extras~11.10.1 as stgraber suggested, for native packages
[23:26] <wendar> yeah, could be (worth the change to ~), but if we were going to change I'd rather change all over, so we don't have to explain two version number schemes to developers
[23:26] <wendar> they can't get our current scheme right, so I hesitate to introduce any more complexity
[23:28] <wendar> (or, to put it another way, since I'm the one setting the ARB versions anyway, it's not really a big deal to remember to use debuild for the final build with proper version numbers)
[23:28] <wendar> or, maybe we can talk to the bzr-builddeb folks about an exception for version numbers that match "extras"
[23:30] <wendar> ajmitch: oh, and yes, this lens and scopes are all by the same author, just originally developed as multiple separate packages
[23:32] <wendar> ajmitch: so, in the future, we can just tell the author to develop their lenses that way to begin with (and get quickly to create lens/scopes that way too)
[23:35] <ajmitch> wendar: ok
[23:37] <wendar> oh, and on guallet, I changed the format from "3.0 (native)" to "3.0 (quilt)", but it seemed to cause the developer more grief than it was worth.
[23:38] <wendar> "3.0 (native)" seems to be more approachable, more like the "my software is just a bundle" idea.
[23:40] <ajmitch> so any patches are applied inline?


[06:29] <eugenesan> Hi all, I am experiencing data loss on USB storage devices while entering S3, can qemu/kgdb help here?
[06:37] <jj-afk> eugenesan: what kid of data loss?,  What fs is on the usb storage, did you sync and unmount before suspend, ...
[06:39] <eugenesan> jj-afk: Looks like data not committed to filesyste, ext4 loose journal, for example
[06:40] <eugenesan> jj-afk: I am talking about root filesystem on USB
[06:41] <jj-afk> Ah Bug #706795
[06:41] <ubot2> Launchpad bug 706795 in linux "[All releases] Suspending with rootfs on USB, causes silent corruptions, kernel panic on mount attempt, data loss and leaving system unbootable." [Undecided,Confirmed] https://launchpad.net/bugs/706795
[06:41] <eugenesan> Indeed, this is the bug
[06:42] <jj-afk> so it is possible that using a vm to test on will help
[06:43] <jj-afk> it will depend some what on where the bug is and how good the vm's usb emulation/pass through is
[06:43] <jj-afk> it certainly can't hurt to try replicating it on a vm
[06:44] <eugenesan> jj-afk: yes, I'll just wanted to check if someone already have tried.
[06:44] <jj-afk> however, I will note that suspend/resume with an external dev mounted generally causes the fs to be unmounted
[06:45] <jj-afk> and treated as if they are ejected and then reinserted
[06:45] <jj-afk> unplugged/plugged ..
[06:46] <jj-afk> it might help if you set USB persist
[06:46] <eugenesan> Well with rootfs this different. No mount/umount events. I suspect USB-host get's reset/sleep too soon, before data got actually written
[06:47] <jj-afk> yes, and this can be device specific
[06:47] <jj-afk> it will depend on the devices driver and the device firmware, ...
[06:48] <eugenesan> do you mean USB dongle specific or specific for USB-MassStorage in general?
[06:48] <jj-afk> both really, or the interplay between them
[06:50] <eugenesan> actually bug is persistent on variety of USB hosts and USB dongle, and correct for all Linux versions and flavors.
[06:50] <jj-afk> basically a bug in the device, the device firmware, the computers firmware, the usb mass storage layer, or even the fs could do it
[06:50] <jj-afk> correct for all Linux versions and flavors?
[06:50] <eugenesan> yes
[06:51] <jj-afk> so the variety of devices would point to the machine or the OS
[06:51] <eugenesan> I think this case is just not treated in code, since with SATA it's almost same data path but working.
[06:51] <jj-afk> by all linux versions do you mean all other versions?
[06:52] <eugenesan> I mean, issue reconstruct easily on every HW and any Linux version, and I tried many...
[06:53] <jj-afk> eugenesan: ah okay thanks for clarifying
[06:54] <jj-afk> so yeah that would point to something in the usb code not handling this correctly
[06:54] <jj-afk> have you tried with other filesystems
[06:55] <eugenesan> I even suspect, in past, there were similar reports regarding SD and SATA...
[06:55] <eugenesan> Yes, they all affected
[06:56] <jj-afk> eugenesan: okay, well I know I have run some linux devices with the root OS on an sd card that could successfully suspend resume.
[06:56] <jj-afk> I will take a shot at replicating
[06:56] <jj-afk> but yes I have heard of root on SD cards being corrupted by suspend/resume before
[06:57]  * jj-afk is going to finish reading your bug now
[10:10] <TeTeT> following up on yesterdays query on the video switch key upon lid open on a Thinkpad, I know built a kernel where I've commented out all KEY_SWITCHVIDEOMODE in acpi/video.c, but the event is still generated. The customer tells me that there is no such event generated when a RHEL4 desktop is installed on the T61
[10:11] <TeTeT> I grepped for KEY_SWITCHVIDEOMODE in the source tree,  but didn't find anything that looks like it would be used
[10:18] <TeTeT> strangely with sudo input-events 5 I know get a KEY_UNKNOWN (0xf0) pressed and released, instead of 0xe3 as yesterday
[11:43] <amitk> cking: something for your bedtime hacking: https://lwn.net/Articles/429812/ :)
[11:44] <cking> amitk, sounds all too familiar
[11:44] <cking> I downloaded the image yesterday, but got sidetracked
[11:45] <amitk> * Run Intel's power management reference code to override your BIOS's configuration.  This includes writing the ACPI tables for P-states and C-states, replacing those normally provided by your BIOS.
[11:45] <amitk> wow ^^
[11:45] <cking> funny how that seems to admit that ACPI has failed to deliver
[11:59] <TeTeT> found it, I commented the acpi_bus_generate_proc_event(...) call as well, then there is no longer a keypress event generated, even not an unknown one
[13:22] <herton> apw, just a heads up, the guy which reported that race with framebuffer tested the patch, https://lkml.org/lkml/2011/2/24/442
[13:22] <herton> should be good to go to repost it
[14:33] <smb> herton, apw is not around today (only by luck)
[14:38] <herton> smb, thanks for informing, I'll check with him again later then
[14:39] <smb> herton, He took the day off today. Later would need to be Monday
[14:41] <herton> hmm, then perhaps I should CC him again on lkml, he wasn't kept on all messages on the thread, as its his patch he will need to repost
[14:41] <smb> herton, Keeping him on cc definitely is good
[14:42] <herton> I added him on CC on my replies to the thread, but some of the replies were not on the messages he was on CC I think
[14:44] <smb> Yeah, I am not sure he will keep track of the thread when not on cc. He gets enough mail to loose track even for the ones written directly to him
[16:16] <JFo> <-lunch and errands bbiab
[16:41] <hggdh> JFo: bug 725089 <- SRU testing
[16:41] <ubot2> Launchpad bug 725089 in linux "QRT test-kernel-security causes kernel panic on EC2 AMD64 image" [High,New] https://launchpad.net/bugs/725089
[16:44] <smb> hm, trying to do something with tsc...
[16:45] <smb> hggdh, Is that the first try with ec2 from regression testing or was there a previous run that was ok?
[16:47] <hggdh> smb: to my knowledge -- which is quite fragmented -- the first. i386 passes, BTW
[16:49] <smb> hggdh, Ok, thanks
[17:07] <bjf> smb, what's the right way to bump the abi in dapper, it doesn't seem to be the same rules as later kernels (just changing the abi in the changelog)
[17:07] <smb> bjf, There is a bumpabi target that you run
[17:08] <bjf> smb, AH!
[17:09] <smb> bjf, And also be careful that Dapper (as Hardy) needs the control files and stuff stored in git with the update
[17:29] <kees> bjf: if you're bumping dapper's abi, can you try to get it and the -meta package using the same ABI number? right now they're off by one.
[17:29] <bjf> kees, will try
[17:30] <kees> bjf: cool; thanks
[17:30] <kees> I'm not sure if the linux-source-2.6.15 package or the meta needs to be bumped twice.
[17:30] <kees> let me look
[17:30] <smb> kees, They use the same abi number. I guess what you want is the same upload number
[17:31] <kees> smb: no, they're not the same abi in the package name (yes, all the deps are correct, but it's goofy)
[17:31] <kees> linux-source-2.6.15 | 2.6.15-55.93
[17:31] <kees> linux-meta | <IP_ADDRESS>
[17:31] <kees> note 55 vs 56
[17:31] <kees> bjf: so, linux-source-2.6.15 needs to go to -57 instead of -56, and then the meta can go to .57
[17:32] <kees> and then I can drop these special-cases for dapper I've got in the archive kernel ABI checker :)
[17:32] <smb> Oh, right. Well actually there is no abi number in the meta package
[17:32] <bjf> kees, ok, i just went to 56
[17:32] <smb> Just that abi number and upload number are close
[17:33] <kees> smb: I don't know what you mean by "upload number"
[17:33] <kees> bjf: can you move linux-source-2.6.15 to 57?
[17:33] <bjf> kees, will attempt to do so
[17:33] <smb> kees, For the meta package <IP_ADDRESS>  the 56 is the uplload number
[17:33] <bjf> kees, :-)
[17:33] <kees> smb: heh, okay, well, for every other kernel package, upload number == ABI number.
[17:34] <smb> kees, For the linux kernel package 2.6.15-56.93 the 56 is the abi number and the 93 is the upload number
[17:34] <kees> bjf: cool; thanks
[17:34] <kees> smb: uhmm...
[17:34] <smb> kees, It probably serves just the mental sanity
[17:34] <kees> linux | 2.6.35-25.44
[17:34] <kees> linux-meta | <IP_ADDRESS>.32
[17:34] <kees> that's maverick
[17:34] <smb> Usually we only need a new meta package when the abi bumps
[17:34] <kees> the meta's upload number is .32 not .25. .25 is the Abi
[17:35] <smb> but it could also be for a different reason
[17:35] <kees> smb: the problem, I guess, was that dapper lacked an ABI number
[17:35] <kees> smb: so I guess I'm hoping to align dapper's upload number with the ABI, since for all the other releases, there is both ABI and upload number in the meta version
[17:36] <smb> kees, I am rather hoping to be in June soon and not to have to care about Dapper any longer. :)
[17:36] <smb> Otherwise, yes we probably added a meta number to avoid further confusion later
[17:37] <kees> smb: yes! I'm going to throw a party for dapper eol
[17:37]  * smb wished he could be there to join. :)
[18:59] <bjf> smb, are you looking at bug #725089 ?
[18:59] <ubot2> Launchpad bug 725089 in linux "QRT test-kernel-security causes kernel panic on EC2 AMD64 image" [High,New] https://launchpad.net/bugs/725089
[19:00] <bjf> ogasawara, hi :-)
[19:02] <jjohansen> ogasawara: hey
[19:02] <jjohansen> bjf: I started looking at that yesterday
[19:03] <bjf> jjohansen, ah
[19:04] <jjohansen> bjf: there is also a lucid issue that is different, hrmm not sure what its bug number is
[19:04] <bjf> jjohansen, it's still unassigned and no additional comments so wasn't sure
[19:04] <jjohansen> bjf: ah, yeah I actually got the info before the bug was opened
[19:04] <jjohansen> I'll assign it to my self
[19:05]  * ogasawara waves
[19:05] <bjf> ogasawara, o/
[19:06] <bjf> jjohansen, the lucid issue is with lucid-ec2 ?
[19:06] <ogasawara> wtf, the kid starts crying right when I start typing
[19:06] <sconklin> ogasawara: o/
[19:06] <vanhoof> ogasawara: hi :D
[19:06] <sconklin> hahaha
[19:06] <vanhoof> ogasawara: its a sign
[19:06] <jjohansen> bjf: yep, its a failure in the qrt mem mapping checks
[19:06] <bjf> ogasawara, are you traveling to uds ?
[19:07] <ogasawara> bjf: I think so, wayne and I were discussing it yesterday
[19:07] <jjohansen> bjf: hrmm just a sec, or was that on hardy
[19:07] <bjf> ogasawara, wayne was saying "no NO! pleeeeese don't go"
[19:07] <ogasawara> bjf: heh, a little :)
[19:09] <ogasawara> bjf: we figured kai will be about 5mo at the time and a little more settled and better able to survive a week without me
[19:09] <jjohansen> ogasawara: you could always bring him :)
[19:09] <ogasawara> jjohansen: you guys would probably kill me on the flight over
[19:09] <bjf> ogasawara, ah you new parents and your little fantasies
[19:10] <jjohansen> ogasawara: hehe not me, and think of the excellent excuse you would have to miss the config review
[19:10] <ogasawara> jjohansen: heh having a kid was all part of my giant scheme just to get out of the config review :)
[19:11] <ogasawara> bjf: I think I'm more worried about wayne surviving the week
[19:11] <jjohansen> bjf: so the memory thing is lucid not the hardy issue
[19:11] <jjohansen> ogasawara: hah, I knew it
[19:11] <bjf> ogasawara, hehe i can imagine
[19:12] <jjohansen> ogasawara: and well worth it :)
[19:14]  * ogasawara will drop back in later ..
[20:17] <kees> smb: so "upload" number should be used instead "revision"? should https://wiki.ubuntu.com/Kernel/Dev/KernelPackageVersioning be updated?
[20:36] <bjf> jjohansen, just to be perfectly clear, there is a lucid issue that you know about ?
[20:37] <jjohansen> bjf: yes, though I am not sure whether it is a regression
[20:37] <bjf> jjohansen, do you have a bug # ?
[20:37] <jjohansen> let me check if hggdh opened a bug for it
[20:41] <jjohansen> bjf: I don't see one, I'll coordinate with hggdh and make sure there is one, and get the information attached and then let you know what it is
[20:41] <bjf> jjohansen, thanks
[20:44] <hggdh> I did open a bug, jjohansen
[20:44] <hggdh> jjohansen: bug 725089
[20:44] <ubot2> Launchpad bug 725089 in linux "QRT test-kernel-security causes kernel panic on EC2 AMD64 image" [High,New] https://launchpad.net/bugs/725089
[20:44] <jjohansen> hggdh: I figured you probably did but my lp foo is weak
[20:44] <jjohansen> bjf: ^
[20:44] <jjohansen> hggdh: thanks
[20:45] <jjohansen> err wait
[20:45] <hggdh> oops
[20:45] <jjohansen> hggdh: not that one
[20:45] <jjohansen> hggdh: the failed qrt memory test on lucid
[20:45] <hggdh> jjohansen: yeah, sorry. No, no bug yet, I will open one
[21:16] <lamont> is umask visible under proc/$pid??
[21:34] <sforshee> lamont, not that I can find
[21:35] <lamont> yeah - I resorted to gdb
[21:55] <hggdh> jjohansen: you are talking about http://reports.qa.ubuntu.com/reports/kernel-sru/home/ubuntu/sru-kernel-test/lucid-2.6.32-313.25-ec2/m1.small-i386/qrt-kernel-security.txt
[21:55] <hggdh> right?
[21:56] <jjohansen> hggdh: yep, thanks
[21:56] <jjohansen> bjf ^
[21:56] <hggdh> jjohansen: so you want a bug on that?
[21:57] <jjohansen> hggdh: yeah, that is doesn't pass the mem test is disturbing and I'll look into it
[21:57] <hggdh> jjohansen: opening one now. It will be manually opened (no apport collection)
[21:58] <jjohansen> hggdh: thats okay, and thanks
[22:21] <cnd> kamal, thanks for the endorsement :)
[22:22] <kamal> cnd: my pleasure :)
[22:41] <JFo> k, I'm starving. See you guys Monday :)