[03:28] <jayT> I'm trying to build a module, but everytime I get the error: ERROR: Kernel configuration is invalid.
[03:28] <jayT> however, I can build my kernel just fine
[03:28] <jayT> the module is outside the kernel tree
[03:28] <jayT> just a simple hello test module
[03:28] <jayT> modules inside the kernel source tree are built fine
[03:28] <jayT> I have tried make oldconfig, make prepare, etc, and re-built the whole kernel,
[03:29] <jayT> but always got that error when I tried to compile a module outside
[03:29] <jayT> could anyone give a hint what's going wrong?
[03:30] <jayT> using ubuntu 11.04
[05:50] <philipballew> How do I put a the kernel time in my terminal when i issue comands?
[06:00] <jk-> philipballew: what do you mean by the kernel time?
[06:02] <philipballew> jk-, I have seen it by my kernal dev friends where on the side of the terminal the system time is there and shows next to each command and each line of output.
[06:02] <jk-> so just the time of the day?
[06:03] <jk-> ^ philipballew
[06:03] <amitk> philipballew: export PS1="[\d \t \u@\h:\w ] $ "
[06:04] <jk-> yep, what amitk said :)
[06:04] <jk-> but I'm a bit puzzled about the date appearing next to each line of output.
[06:05] <amitk> philipballew: not really kernel related, but here are the keywords to google for: PS1 linux shell prompt time
[06:06] <amitk> jk-: you could remove the '
[06:06] <amitk> \d
[06:06] <jk-> amitk: no, more that you're only setting the prompt, which won't affect terminal output.
[06:07] <jk-> philipballew mentioned "shows next to each command *and each line of output*"
[06:07] <amitk> jk-: PS2 is your friend for that trick
[06:08] <amitk> I suspect
[06:08] <jk-> PS2 is for the secondary prompt
[06:08] <jk-> not output
[06:08] <jk-> ie, continuations
[06:08] <amitk> aah, i see what you mean now. I doubt it is on every line of output
[06:08] <jk-> yeah, me too :)
[06:08] <amitk> maybe he just saw dmesg with printk times
[06:09] <jk-> maybe.
[06:09] <amitk> which might explain "kernel time"
[06:09] <jk-> philipballew: show us a screenshot if you can.

[06:09] <amitk> totally :)
[06:24] <philipballew> amitk, jk-  sorry, Had to step away
[06:25] <philipballew>  export PS1="[\d \t \u@\h:\w ] $ " should be pasted where
[06:27] <jk-> philipballew: in to the terminal, and it will change the prompt temporarily
[06:27] <philipballew> alright, ill see what happenes
[06:27] <jk-> if you want to change it permanently, then add that line to ~/.bashrc
[06:29] <philipballew> oh, alright. Im ive seen it where it shows the system time. so you can see exactly when a partictular event happens
[06:29] <amitk> philipballew: type dmesg and tell me if you saw that?
[06:30] <jk-> philipballew: I'm still not clear on what you mean by 'system time', and how that differs from the current "clock" time.
[06:31] <philipballew> did like I would like when i tyoe dmesg i can have a system time stamp next to each line on the terminal output
[06:31] <philipballew> *type
[06:31] <jk-> that's what the numbers in square-brackets are - seconds since boot
[06:32] <philipballew> is that a common thing to have in your terminal?
[06:32] <philipballew> http://pastebin.ubuntu.com/663993/
[06:33] <jk-> no, it's specific to dmesg
[06:34] <philipballew> hum. haha. alright. Ill look around
[06:35] <jk-> you could add `| awk '{print strftime("%H:%M:%S")" "$0}'` after every command you type, but I don't think that's very convenient :D
[06:36] <philipballew> very true. im trying to debug a possible kernel power management error to see if an error is the kernal or grub related. thought it might help
[06:37] <philipballew> might be to much hassle
[06:37] <jk-> it's probably not a grub issue :)
[06:38] <philipballew> the desktop will not restart
[06:38] <philipballew> ive seen the issue be a boot loader issue,
[06:38] <jk-> ok, that doesn't sound like a power management issue then
[06:39] <philipballew> haha. it hangs on reboot, but shutdown -h now works fine.
[06:39] <jk-> riight
[06:40] <philipballew> seemes weird. but i think I have the wrong boot parameters myself
[06:40]  * philipballew is now off topic
[06:40] <jk-> where does it hang? do you see the BIOS screen?
[06:40] <jk-> no, this is now *on* topic :)
[06:41] <philipballew> whenever I type sudo reboot or just click reboot the comp shuts down all processes then says will now reboot and just sits there
[07:15] <apw> and what kernel command line options do you have
[07:18] <philipballew> none
[07:18] <philipballew> well easily
[07:18]  * philipballew is not a kernal know-it-all
[07:20] <jk-> philipballew: cat /proc/cmdline
[07:20] <philipballew> BOOT_IMAGE=/boot/vmlinuz-2.6.35-30-generic root=UUID=3ccd7388-34b9-40fe-960b-15371e1fb72a ro quiet splash
[07:21]  * philipballew is doing this from sshing to his desktop (if that matters)
[07:21] <jk-> philipballew: yeah, that's cool. nothing unusual there.
[07:22] <philipballew> maybe it needs something unusual to work?
[07:23] <apw> there is a reboot=<letter> which switches reboot mode
[07:23]  * apw finds the documentation
[07:24] <philipballew> it might be a bug for my hardware but the desktop is 6 years old so a big bug like this should mave been fixed
[07:25] <apw> philipballew, not necessarily it may be unsusual h/w to have linx on
[07:26] <apw> philipballew, ok i've pm'd you the documentation for the reboot=<x> command line option
[07:26] <philipballew> true. but i never had this problem with ubuntu and only xubuntu gives it. haha
[07:27] <apw> hmmm
[07:27] <apw> well thats odd as i would expect those to have the same kernels, our kernels, and so to behave the same
[07:27] <apw> which ubuntu worked (version) and which of xubuntu does not
[07:27] <philipballew> i would to. i had ubuntu server on there and nothing
[07:27] <philipballew> both 10.10 and 11.04
[07:28] <philipballew> but ubuntu 10.10 didnt
[07:28] <philipballew> i ran ubuntu on it for years from 7.10 up to 10.10 and no problems ever
[07:28] <apw> so i can ignore the xubuntu thing
[07:28] <apw> as its a new version which doesn't work
[07:29] <philipballew> ubuntu 10.10 reboot works. xubuntu 10.10 reboot = bad
[07:29] <apw> and which kernle does xubuntu 10.10 have in it
[07:29] <apw> cat /proc/version_signature tells you
[07:30] <philipballew> Ubuntu 2.6.35-30.56-generic <IP_ADDRESS>
[07:32] <apw> and have you tested the same version in ubuntu 10.10 ?
[07:32] <apw> ie. how are you comparing to vanilla 10.10
[07:33] <philipballew> i can run a live cd you think?
[07:37] <siji> apw, goodafter noon
[07:37] <apw> well you are telling me a fact about ubuntu 10.10 so i am assuming you have tested it, i am asking how and when you _did_ test it.  so i can work oout if that would have had a similar or different kernel
[07:37] <apw> hi
[07:37] <siji> am trying here to fix the bug which we discussed yesterday
[07:38] <siji> http://marcin.juszkiewicz.com.pl/2010/10/19/how-to-cross-compile-arm-kernel-under-ubuntu-10-10/
[07:38] <siji> can you pls tell  me whether this doc is capable of building kernel for beagle
[07:39] <siji> which is based on xdeb
[07:39] <siji> (till now i tried build the kernel directly in beagle , which consuming time)
[07:41] <philipballew> apw it was 10.10 about 3 months ago. i tested it by knowing I restarted it and it worked just fine
[07:41] <apw> siji, it looks viable
[07:41] <siji> ok
[07:42] <apw> philipballew, ok so that had a lot older kernel so its entirly possible its an upstream stable change which has affected the kernel here ... you have a vanilla ubuntu kernel in your xubuntu image, so i suspect a real ubuntu install will also be affected the same way
[07:42] <siji> instead of linux-linaro have to use linux-omap3 right ?
[07:42] <apw> philipballew, so the correct thing to do is now is to test those reboot= options.  as the kernel includes a table to select the appropriate reboot option.  let us know which if a
[07:42] <apw> any work for you
[07:43] <apw> siji, i would guess so, i have obviously never actually tried it
[07:43] <philipballew> ill do it right now
[07:43] <siji> apw, ok will give a try
[07:43] <amitk> siji: you might find the author of the blogpost on #ubuntu-arm or #linaro as 'hrw'
[07:43] <siji> ok
[07:51] <philipballew> force did not work. onto next
[07:52] <siji> amitk, thanks i got him @ ubuntu-arm
[07:54] <amitk> siji: I know, I'm there too :)
[07:54] <siji> :)
[08:09] <siji> apw, amitk can you pls suggest some other method to cross compile the kernel
[08:10] <siji> (am familiar with OE)
[08:11] <apw> siji, i do all my cross-compiles in a regular chroot with the cross tools installed as in that post
[08:13] <siji> regular chroot  = x86 chroot | Cross tools=xdeb & gcc-arm-linux-gnueabi ?
[08:15] <amitk> siji: I haven't used xdeb either
[08:15] <amitk> I probably should try again, it was broken last time I tried
[08:16] <siji> amitk, i installed it with out any errors
[08:16] <amitk> siji: it is the kernel compilation bit that was broken for xdeb
[08:21] <siji> amitk, ok
[10:19] <apw> siji, regular chroot with the cross compiler installed
[10:21] <siji> apw, ya understod
[11:03] <Kaleo> hi
[11:09] <apw> hi
[13:10] <tjaalton> hum, how to build an amd64.deb mainline kernel with mainline-build? it defaults to i386
[13:12] <tgardner> apw, ^^
[13:16] <tjaalton> looks like it's hardcoded in mainline-build-one, I'll try creating one for amd64
[13:17] <ogasawara> tjaalton: I hand edit the mainline-build-one script to generate amd64 debs
[13:17] <tjaalton> ogasawara: heh, okay
[13:18] <ogasawara> tjaalton: http://pastebin.ubuntu.com/664241/
[13:18] <tjaalton> thanks, that saved me some time
[13:19] <apw> tjaalton, does it not make both by default
[13:20] <tjaalton> apw: nope
[13:20] <apw> don't understnad why not for you, it does normally
[13:20] <apw> http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.0.1-oneiric/
[13:20] <tjaalton> this is the -one script
[13:21]  * apw thinks, is that something someone else added
[13:21] <ogasawara> apw: or maybe changes didn't get checked into kteam-tools?
[13:21] <tjaalton> mainline-build sends email to the list, so running that directly doesn't feel like a good idea :)
[13:21] <apw> ogasawara, no whats used daily is whats in the tree
[13:22] <apw> mainline-build-one builds the amd64 first i think
[13:23] <apw> it does clean, binary-indep, clean, binary-generic (in <release>) and then binary-generic (in <release-i386>)
[13:23] <apw> so it defiantly makes both
[13:23] <apw> tjaalton, ogasawara, ^^
[13:24] <tjaalton> well it didn't here, though I did run it against linux.git HEAD
[13:25] <apw> well ... it must have said something when it tried.  perhaps your chroots are not the right names
[13:29] <apw> tgardner, in case you hadn't noticed i've pushed up an empty LBM
[13:29] <apw> it even builds as of just now
[13:30] <tgardner> apw, ah ,and this tidbit of information implies I should upload it ?
[13:30] <apw> tgardner, i was hoping you'd glance over it for now
[13:30] <apw> as it only produced a single .udeb i am unsure if we care if it is uploaded or not yet
[13:30] <apw> ogasawara, t
[13:31] <apw> ogasawara, those lbm net packages, i think you added them
[13:31] <apw> ogasawara, do you know where the source was from, ie. does oneiiric need them?
[13:31]  * ogasawara tries to remember the lbm net bits
[13:31] <ogasawara> apw: was that the updated e1000e driver?
[13:32] <apw> that and igp or something
[13:32] <apw> igb
[13:32] <apw> something like that
[13:32] <tgardner> that stuff should all be upstream by now
[13:32] <ogasawara> apw: if I remember correctly, those were picked from upstream so O shouldn't need them
[13:32] <apw> ok then off is correct for them
[13:32] <ogasawara> apw: but let me double check to make sure
[13:33] <apw> gawd they have changed the login screen to be all mad and off centre, really jars in my OCD world
[13:35] <ogasawara> apw: yep, don't need them for O
[13:40] <tgardner> apw, ogasawara: I think we can drop the LBM alsa, input, and media directories (and assorted rules and control.d cruft) since they aren't even enabled in Natty.
[13:40] <ogasawara> tgardner: works for me
[13:54]  * ogasawara wonders if bjf is really here or in transit
[13:55] <bjf> unfortunately, really here, i just couldn't make myself sleep in
[13:55] <bjf> flight doesn't leave unti 13:30
[13:56] <bjf> but i'm _not_ going through ATL
[13:56] <tgardner> bjf, JFK instead ?
[13:56] <ogasawara> bjf: I'm going to change the format for this weeks IRC meeting.  Rather than me repeating myself every week with the delta review blueprint, I'm instead going to harp about outstanding work items that need done for the upcoming beta-1 milestone
[13:56] <bjf> tgardner, PDX -> AMS
[13:57] <tgardner> ogasawara, hmm, will that make you a 'harpie' or 'harpette' ?
[13:57] <ogasawara> heh
[13:57] <bjf> ogasawara, cool
[13:58]  * ogasawara back in 20
[14:29] <brendand> hi sconklin
[14:30] <brendand> sconklin - do you reckon we'll need to fully retest the respun kernel, or will the change be minor enough to make our results from the current valid?
[14:35] <sconklin> well,  on one hand, since he tests didn't catch this, being a graphics issue and all, there's not much to be added by retesting. On the other hand, these are probably invasive changes so I think we'll have to completely retest.
[14:35] <sconklin> But capping that off, we really don't have a fix yet, so we don't know what's required
[14:35] <sconklin> So I think we'll probably have to recertify plus run some additional tests to see if the graphics work on those platforms
[14:39] <tgardner> apw, ogasawara: uploaded linux-backports-modules-3.0.0_3.0.0-8.1
[14:39] <ogasawara> tgardner: thanks!
[14:39] <brendand> sconklin - is it only affecting particular gfx cards?
[14:40] <apw> tgardner, heh, oh i'll take that as being ok :).  /me orders ram for pete
[14:40] <tgardner> apw, oh, it was fine. I ripped out some obsolete stuff though.
[14:41] <apw> sconklin, did we have a display regression on 38-11 in natty ?
[14:41] <sconklin> brendand: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/814325 We know it affects Intel graphics, I don't know whether we have a subset of models.
[14:41] <ubot2> Ubuntu bug 814325 in linux "fuzzy and corrupted display with update in natty-proposed" [High,Triaged]
[15:15] <apw> tgardner, yeah i half heartedly stripped it
[15:15] <tgardner> apw, I got out the bob nailed boots....
[15:15] <tgardner> hob*
[15:15]  * apw was liking the thought of bobs hammered into my boots
[15:16]  * tgardner is going back to learning cloud infrastructure
[15:17]  * apw notes that unity is the biggest source of bugs in oneiric again this week
[15:20]  * smb is glad he only needs to cope with the olds ones this week
[15:20]  * apw finds 5 bugs in the first 5 minutes as usual
[15:21] <smb> apw, You are using it in an unusual using manner
[15:22] <apw> smb, yeah i am using it rather than osx
[15:23] <smb> And trying to get some work done with it instead of looking how nice it looks... ;-P
[15:24] <apw> just managed to get compiz to coredump
[15:24] <apw> after trying to restart it cause it hung
[15:24] <apw> quality s/w
[15:25] <tgardner> apw, yeah, I've been having compiz issues this morning also
[15:25] <apw> luckily i only updated my scrapper today
[15:26]  * apw checks, beta 1 is definatly later than alpha 1
[15:28]  * smb reminds apw about optimism
[15:28] <apw> i stand my interpretation, stupid (n)
[15:29]  * smb keeps silent about apw having upgraded any machine
[15:31]  * jjohansen thanks apw for the subtle reminder not upgrade while traveling
[15:32]  * ogasawara feels compelled to upload today
[15:32] <apw> ogasawara, :)
[15:32] <ogasawara> tgardner, apw: anything else you want to shove onto master-next before I kick some test builds and upload
[15:32] <smb> ogasawara, And then run for the weekend. :)
[15:32] <ogasawara> smb: of course!
[15:32] <apw> ogasawara, nothing i know of here
[15:33]  * ogasawara goes back to opening P
[15:33] <tgardner> ogasawara, the only thing pending is perhaps jjohansen's AA patches.
[15:34] <ogasawara> tgardner: ack, I'll maybe wait till about lunch time to kick off builds to give him time to respond
[15:34] <ogasawara> tgardner: if not, they can go up in the next round
[15:34] <tgardner> ogasawara, ack
[15:37] <mdeslaur> herton: think you can build me a test kernel with ROAF's two patches from comment #27?
[15:38] <herton> mdeslaur: yep, I'm about to copy built kernels here, hang on
[15:38] <mdeslaur> herton: ah, cool :)
[15:40] <jjohansen> ogasawara: just upload my patches are not worth holding off for
[15:42] <ogasawara> jjohansen: ack, I'm in no big hurry to upload so if they're not in by noon-ish I'll pull the trigger.
[15:42] <jjohansen> ogasawara: okay, but it may be worth holding off on them and waiting to hash it out next week after I have talked to jdstrand
[15:43] <herton> mdeslaur: hmm, had to restart build here because an error, will ping you when I finish
[15:43] <ogasawara> jjohansen: ah, in that case then we can wait and I'll go ahead an upload
[15:43] <mdeslaur> herton: thanks
[15:57] <herton> mdeslaur: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/814325/comments/44
[15:57] <ubot2> Ubuntu bug 814325 in linux "fuzzy and corrupted display with update in natty-proposed" [High,Confirmed]
[15:58] <mdeslaur> herton: it only takes you 14 minutes to build a kernel? :P
[15:58] <mdeslaur> herton: thanks
[15:58] <herton> yes, I use one of our build machines, it's pretty fast
[15:59] <mdeslaur> kernel team gets all the cool toys :)
[16:00] <tgardner> mdeslaur, the kernel team has this really annoying guy that makes lots of demands
[16:00] <mdeslaur> tgardner: hehe :)
[16:12]  * herton -> lunch
[16:38] <georg> hi fellows! had an GPF using dm raid5 with dm crypt on top. Trace: http://pastebin.com/QK15DkaU (actual kernel: ubuntu natty 2.6.38-8-generic #42-Ubuntu SMP x86_64 GNU/Linux). is this known, should i file a bug?
[18:00] <tgardner> ogasawara, do you remember how I added a macro to chromium? For example, I can enter 'bug 1' in the URL window which automatically expands to https://bugs.launchpad.net/ubuntu/+bug/1. The Lucid version in -proposed is wedging on some searches, so I wanted to make sure my browser is mostly vanilla.
[18:00] <ubot2> tgardner: https://bugs.launchpad.net/ubuntu/+bug/1 (Not reporting large bug)
[18:01] <ogasawara> tgardner: hrm, I don't know how to do it with chromium.  I did for firefox
[18:01] <tgardner> is ther e a common extensions directory?
[18:01] <ogasawara> no idea
[18:01] <tgardner> how did you do it for FF ?
[18:01] <apw> tgardner, you do that in the search section
[18:01] <tgardner> I must have imported something
[18:01]  * ogasawara digs through notes to remember
[18:02] <apw> tgardner, hit the spanner, preferences, then on the basics tab there is a "Manage Search Engines"
[18:02] <apw> add a newone at the bottom with a keyword and you are good
[18:03] <apw> ogasawara, ^^
[18:03] <tgardner> apw, indeed, thats where it is
[18:03] <ogasawara> apw: awesome, thanks!
[18:03] <tgardner> so, thats unlikely to be the root of my lockup
[18:07]  * tgardner --> lunch
[18:28] <apw> BAH pidgin just ate a bunch of my disk space ... it seems
[18:28] <apw> any suggestion where it put it
[18:31] <apw> i had that 2G left message, cleared 8, and got it back in minutes ... and found pidgin consuming a whole CPU
[18:34] <apw> ahhh .xession-errors ... 15GB
[19:08] <jjohansen> apw: its beer o'clock, its just telling you to start the weekend
[19:41] <kamal> how does one build the linux-tools-{version} binary package?   I discovered "fakeroot debian/rules binary-tools" which seems to try but eventually bombs out with this (on tangerine):
[19:41] <kamal>   dpkg-gencontrol: error: package linux-image-3.0.0-8-tools not in control info
[19:43] <kamal> ... along the way, the build yields warnings about "newt not found, disables TUI support" and "/usr/bin/python-config is not an executable".
[19:43] <kamal> apw, tgardner, ogasawara: is tangerine set up to build the binary-tools target?  am I doing it wrong?
[19:44] <ogasawara> kamal: I can't say I've specifically ever tried fdr binary-tools
[19:44]  * ogasawara tries
[19:44] <tgardner> kamal, I don't remember that as being a target
[19:45] <kamal> tgardner: it is a target :-)    ogasawara, thanks!
[19:46] <tgardner> kamal, I think its binary-perarch
[19:46] <ogasawara> kamal: I just did a fdr binary tools (but on tyler) and it seems to be building
[19:46] <ogasawara> kamal: ah, fails
[19:47] <kamal> ogasawara: you did "binary<space>tools"  or "binary-tools"?
[19:47] <ogasawara> kamal: binary-tools
[19:47] <ogasawara> kamal: fails in the end though
[19:47] <ogasawara> kamal: same error
[19:47] <kamal> ogasawara: ok, thanks for confirmation
[19:48] <kamal> tgardner: I'll try binary-perarch
[19:48] <tgardner> kamal, the only reason I say that is because of this: 'debian/rules.d/2-binary-arch.mk:binary-perarch: toolspkg = $(tools_pkg_name)'
[19:48] <kamal> tgardner, ogasawara: yes, binary-perarch builds the pkg fine
[19:49] <kamal> tgardner: thanks!
[19:50] <tgardner> kamal, you also need linux-tools-common so that it installs the wrappers
[19:52] <kamal> tgardner: understood, thanks
[19:53] <tgardner> kamal, I presume you're looking at the x86 power tools ?
[19:54] <kamal> tgardner: my purpose here is to figure out whether the new "tools/power/cpupower/..." stuff is going to be built and packaged in linux-tools-* or not.  do you know?
[19:55] <tgardner> kamal, indeed I do, 'UBUNTU: [Config] Package x86_energy_perf_policy and turbostat'
[19:55] <kamal> tgardner: I saw that, but was unclear what effect that would have on the tools packaging.
[19:56] <tgardner> it adds wrapperd ala perf so that the correct ABI related tool is launched
[19:56] <tgardner> wrappers*
[20:01] <kamal> tgardner: I think I'm talking about something else... I'm talking about the (very) new tools/power/cpupower/... stuff that just landed in the v3.1-rc1 tree (its the userspace utility that used to be called 'cpufrequtils' but is now called 'cpupower').
[20:02] <tgardner> kamal, ah, I've not seen that yet
[20:45]  * tgardner --> EOW
[20:56]  * herton -> eow
[22:13] <asabil> hi all
[22:14] <asabil> is it normal that I don't have any pdflush process running ?
[22:15] <khanx> yep
[22:15] <khanx> its perfectly normal
[22:29] <milehigh> 2.6.38-10-generic-pae kernel, is CONFIG_NR_CPUS set to 7 for a reason? How can I change it while still using packaged kernels?


[03:28] <Fudge> hi guys, adding ppa to maverick but i get Error reading https://launchpad.net/api/1.0/~mozilla-ubuntu-daily/+archive/ppa: HTTP Error 404: Not Found
[03:28] <Fudge> executing as root apt-add-repository ppa:mozilla-ubuntu-daily/ppa
[03:29] <micahg> Fudge: ppa:ubuntu-mozilla-daily
[03:30] <Fudge> oh the page had it the other way round
[03:31] <micahg> Fudge: what page?
[03:33] <Fudge> https://launchpad.net/~ubuntu-mozilla-daily/+archive/ppa
[03:34] <micahg> Fudge: that makes no sense
[03:35]  * micahg doesn't see that anywhere on that page
[03:39] <Fudge> did i give the wrong url?
[03:40] <Fudge> You can update your system with unsupported packages from this untrusted PPA by adding ppa:ubuntu-mozilla-daily/ppa to your system's Software Sources. (Read about installing)
[03:40] <Fudge> you cant see that?
[03:41] <micahg> Fudge: that's correct
[03:41] <Fudge> I do not know why I can, it was my first google result
[03:41] <Fudge> and anyway it lead me to here and you have helped me. :)
[03:41] <micahg> it doesn't say  ppa:mozilla-ubuntu-daily/ppa
[03:42] <micahg> Fudge: are you looking for dailies for Firefox 4?
[03:42] <micahg> *or
[03:43] <Fudge> yes, i use orca and find firefox very slow with orca
[03:44] <Fudge> oh yes, you are right im sorry. i do not understand how i got those two words wrong way round. :$ lets jsut blame it on using tts and hide that line away somewhere, deep
[03:45] <micahg> heh, ok, I want to make sure you get the right PPA though, what were you looking for?
[03:45] <Fudge> blledign edge firefox
[03:45] <Fudge> bleeding
[03:45] <micahg> Fudge: ok, then you're in the right place :)
[03:47] <Fudge> nice
[03:56] <Fudge> defenantly faster
[03:56] <Fudge> sometimes on webpages orca takes so long after the text ahs appeared to start reading
[03:57] <Fudge> its my belief that somethings broken in linux ff aposed to windows ff for accessibility
[04:05] <micahg> Fudge: it's probably using different libraries
[04:05] <micahg> Fudge: I believe the accessibility is better in 4.0 that 3.6 and Ubuntu 11.04 should help as well hopefully
[04:05] <Fudge> true it is, ill upgrade orca too
[09:52] <fta2> chrisccoulson, hey, yt?
[09:53] <chrisccoulson> fta2, yeah
[09:53] <fta2> chrisccoulson, i'm wondering why my ppa stats are broken in ff4, http://people.ubuntu.com/~fta/chromium/stats/stats.html   any idea?
[09:53] <fta2> it's supposed to look like this: http://people.ubuntu.com/~fta/chromium/stats/ppa-stats.ogv
[09:54] <fta2> my ff4 console is filled with errors of all kinds, but nothing in my own code
[09:56] <chrisccoulson> fta - hmmm, not too sure. i'll have a look at that in a bit, i just need to grab some coffee first :)
[09:56] <fta2> sure, thanks
[10:05] <chrisccoulson> fta - i see this in my error console:
[10:05] <chrisccoulson> Error: element.dispatchEvent is not a function
[10:05] <chrisccoulson> Source File: http://people.ubuntu.com/~fta/javascript/prototype/prototype.js
[10:05] <chrisccoulson> Line: 4619
[10:05] <chrisccoulson> which looks like something overwrote that function
[10:06] <chrisccoulson> fta - and, then i saw this: http://stackoverflow.com/questions/980697/element-dispatchevent-is-not-a-function-js-error-caught-in-firebug-of-ff3-0
[10:06] <chrisccoulson> might be a clue ;)
[10:07] <fta2_> prototype is not mine. it's a widely used js stack
[10:08] <fta2_> chrisccoulson, ^^, and why is it a problem only in firefox?
[10:31] <vish> chrisccoulson: i attached the SRU patch for Lucid and Maverick for that FF4+compiz bug and i have subscribed the SRU team too, [maybe you can upload it before pitti goes on the SRU rounds? ;) ]
[10:55] <chrisccoulson> vish, i can try, but i'm not sure i can upload compiz to lucid (not a core-dev)
[10:55] <chrisccoulson> i'm not special enough ;)
[10:55] <vish> chrisccoulson: apply! ;)
[10:56] <vish> but just lazy enough ;p
[10:56]  * vish thought seb128 wanted you to apply a while ago.
[10:56] <chrisccoulson> vish - i don't know what to put on my application. i do most of my work inside the packageset i can already upload too, and the DMB wouldn't use that to assess my suitability ;)
[10:57] <chrisccoulson> i do have things sponsored outside of my usual packageset, but they are generally quite trivial uploads
[10:57] <chrisccoulson> so i just can't be bothered really ;)
[10:57] <vish> ;p
[12:31] <fta2_> grrr, i officially hate ff
[12:32] <fta2_> i guess i have to rewrite my stuff to use only jquery
[15:29] <crass_> is the firefox-4.0 package notbeing built anymore?
[15:42] <micahg> crass: where?
[15:43] <micahg> fta: BTW, I just had a new ioquake3 sync'd which might fix your openarena issue if you're available to test it once it builds
[16:03] <fta> micahg, ok, sure.
[16:04] <fta> micahg, btw, what about chromium 10?
[16:06] <micahg> fta: I'll go back to testing as soon as I finish nss
[16:12] <fta> ok
[16:26] <chrisccoulson> crass, no, the nightlies are broken atm
[16:26] <chrisccoulson> i've got changes pretty much ready to push, but it renames the source package again
[17:10] <fta> Error: (new component).QueryInterface is not a function
[17:10] <fta> Source File: resource://gre/modules/XPCOMUtils.jsm
[17:10] <fta> Line: 242
[17:11] <fta> chrisccoulson, ^^ expected?
[17:11] <chrisccoulson> fta - under what condition is that?
[17:12] <fta> just opened the console
[17:12] <fta> maybe addon related
[17:12] <fta> i have this before:
[17:12] <fta> Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIINIParser.getString]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: chrome://nightly/content/nightly.js :: <TOP_LEVEL> :: line 467"  data: no]
[17:13] <fta> (i didn't start ff in a long while here)
[17:13] <crass> chrisccoulson: ok, was wondering if they were stopping coinciding with the release of 4.0 final
[17:18] <fta> uh? firebug is not compatible with ff4??
[17:22] <chrisccoulson> fta - it should be. i'm running it here ;)
[17:39] <fta> chrisccoulson, yeah, i had the one that work only with 3.6.
[18:18] <fta> hm, i wonder why $.ajax() gives me an object on my own servers but a string in people.u.c
[23:16] <BUGabundo> guud evening folks! sofa time


[05:56] <hikiko> hello
[06:07] <noam> Hi! Where is the script that produces the ubuntu ISO images?
[08:53] <seb128> doko, hey, re your reply on the list about the sponsoring item, see +activity on the log, somebody sponsored the item yesterday and unsubscribed sponsors when doing so, so they were subscribed... it's just that we don't have much active sponsors :-/
[08:53] <doko> seb128: ahh, I see
[09:29] <alkisg> The version of nbd-client in xenial doesn't really support systemd, see for example https://bugs.launchpad.net/ubuntu/+source/nbd/+bug/1487679
[09:29] <alkisg> The version of nbd-client in debian stretch does support systemd.
[09:29] <alkisg> How easy would it be to have an SRU for syncing with the new version, instead of targetting individual bug fixes, which I think is quite hard wrt the code changes?
[09:30] <seb128> bdmurray, hey, the +activy package does show when the team was unsubscribed on that sponsoring bug, where are you looking?
[09:31] <seb128> alkisg, hey, depending of the complexity of the changes and how good the package testsuite (or manual testing) is, you basically need to convince the SRU team that the update is not going to create new issues for users who had it working
[09:32] <seb128> alkisg, if the previous version can't work for anyone it should be pretty easy to argument for an update, if it's not that obvious then you need to convince of the pros&cons
[09:33] <alkisg> seb128: ty; I'll file a bug report and make a few arguments there
[09:33] <seb128> alkisg, thanks
[09:37] <ricotz> helloW: APT had planned for dpkg to do more than it reported back (4 vs 6).
[09:37] <ricotz>    Affected packages: base-files:amd64
[09:38] <ricotz> oops, was about to ask if this was reported somewhen in the past
[09:39] <ricotz> "apt-get install --reinstall base-files" doesn't resolve it
[09:42] <ricotz> juliank, hi, ^
[09:43] <juliank> ricotz: oh, a bug there, nice. I sometimes wish DonKult was here, he wrote that stuff ...
[09:44] <juliank> ricotz: That's in yakkety?
[09:44] <juliank> or zesty?
[09:44] <juliank> or where?
[09:44] <ricotz> juliank, no idea, what this is about ;), on zesty
[09:44] <juliank> OK.
[09:44] <ricotz> I assume this package is in this state for a while
[09:45] <juliank> ricotz: It's a disagreement how many steps dpkg will execute.
[09:45] <juliank> ricotz: Does that actually break anything?
[09:46] <ricotz> so far I dont see any side-effect, the package was configured too
[09:46]  * juliank has no idea, that's fairly new stuff - DonKult recently made apt not queue each dpkg request in detail but allowed dpkg to act a bit more on its own. This obviously means that our view of what dpkg will do should match what dpkg does.
[09:46] <juliank> I told DonKult about it, but it's probably a good idea to open a bug for that
[09:46] <ricotz> (but it is marked as not completely installed)
[09:47] <ricotz> iW  base-files                                                       9.6ubuntu8                                           amd64
[09:47] <juliank> Open a bug in LP, and add all your details there :)
[09:47] <juliank> I don't want to play proxy between #ubuntu-devel here on #debian-apt on OFTC
[09:48] <Laney> but you do it so efficiently
[09:48] <juliank> and a bug is more persistent and we can actually mark it as solved :)
[09:48] <Laney> almost no dropped packets
[09:48] <juliank> Laney: How do you know?
[09:48] <Laney> the N in laney stands for NSA
[09:49] <juliank> Oh. I always thought Laney means LA, ney - a misspelling of LA, nay.
[09:50] <Laney> La NSA 'ears you
[09:50] <juliank> Actually, it appears ney is used as well
[09:50] <mmmm> Would my computer be able to run ubuntu? https://postimg.org/image/yqfdsljtb/
[09:50] <juliank> but it's an instrument
[09:50] <juliank> A type of end-blown flute.
[09:51] <sladen> mmmm: the hardware would be more than capable for installing Debian or Ubuntu, yes
[09:53] <mmmm> Trying to get the secure boot disabled has been the hardest part
[09:53] <bdmurray> seb128: In the wrong column on the activity log. :-|
[09:53] <seb128> bdmurray, k
[09:54] <bdmurray> seb128: feel free to follow up
[09:54] <seb128> bdmurray, somebody else did
[09:55] <sladen> mmmm: yes, the difficulties will be things like changing the boot order/boot setup to get either Debian or Ubuntu installed
[10:20] <mitya57> pitti, hi, can you please help me a bit using your archive team powers?
[10:20] <mitya57> I need a package removal (bug 1646867) and decruft of gnome-panel (rm old binaries)
[10:21]  * mitya57 did a general ping two times here, but nobody responded :(
[10:32] <rharper> pitti: thanks for the sanity check, I was able to get things working with just adding a +Before=systemd-networkd.service to resolvconf.service
[10:34] <rharper> pitti: since that file is part of the resolvconf package I'll update bug 1636912 with the details;  should I mark that verification-failed and link to a resolvconf change? or leave it -needed, and wait till we also have a resolvconf update ?
[10:37] <infinity> mitya57: Removal done, though LP is timing out on me trying to close the bug. :P
[10:38] <mitya57> infinity, thanks a lot!
[10:38] <infinity> mitya57: Not sure what "decrufting" you're looking for for gnome-panel.
[10:39] <mitya57> infinity, I meant removing old libpanel-applet0{,-dbgsym} and gir1.2-panelapplet-5.0 binaries to that the new version can migrate
[10:40] <mitya57> (which changed to libpanel-applet2 and no gir bindings)
[10:40] <infinity> mitya57: It'll migrate fine without doing that.
[10:40] <infinity> mitya57: We remove NBS packages *after* migration, not before.
[10:40] <infinity> (doing it before would break the archive)
[10:40] <mitya57> OK, I was probably confusing with Debian then. Thanks again!
[10:40] <mitya57> pitti, unping :)
[10:41] <infinity> mitya57: http://paste.ubuntu.com/23587930/ shows that the only issue is command-runner-applet, which will clear up after the next publisher run.
[10:43] <mitya57> OK, I do check that page, but not always sure that I parse it correctly.
[11:05] <pitti> mitya57: good; sorry, sprint week, negligible IRC bandwidth
[11:07] <mitya57> Thanks anyway and sorry for the noise!
[13:38] <slashd> cyphermox, xnox, I have a critical bug here LP: #1579609 for os-prober, there is a patch proposed in debian, I test the patch with different users experiencing the issue, and they claimed it solve the situation, since the patch is not yet merge in debian and that this is a CRITICAL bug as it may cause some FS corruption, do you think we can go ahead with the SRU anyway or better wait the merge in debian ?
[13:42] <juliank> mdeslaur: Feel free to query ...
[13:49] <cyphermox> slashd: we can land it in a SRU, it's not a problem if the patch is sane.
[13:50] <slashd> cyphermox, it is, and has been tested by different users
[13:50] <cyphermox> well, I'll be the judge of that ;)
[13:50] <slashd> cyphermox, sure
[13:54] <cyphermox> slashd: seems to me like it probably should just drop the else part
[13:54] <slashd> cyphermox, agree
[13:56] <slashd> cyphermox, if I understand properply you are good with it (minus the else part) ? or you need more time to check ?
[13:56] <cyphermox> slashd: I think I'd be more ok if it was just changing the else part of that if, rather than changing both branches
[14:04] <slashd> like this ? https://pastebin.canonical.com/172868/
[14:04] <slashd> cyphermox ^
[14:04] <cyphermox> right, but the error message is probably wrong too in this case
[14:08] <slashd> cyphermox, any suggestion ?
[14:15] <cyphermox> "failed to probe for filesystem type" or something like that?
[14:15] <slashd> Yeah, I like that
[14:16] <slashd> cyphermox, ok will proposed a debdiff today, tks, do you think you'll have time to sponsor it this week ?
[14:17] <slashd> cyphermox, enjoy Seville chanceux ;)
[14:22] <xnox> pitti, i do not understand the libseccomp NMU
[14:22] <xnox> it seems weird. What does Build-Depends-Package in .symbols do?
[14:43] <pitti> xnox: it makes sure that the generated shlibs depends is never lower than the version of the specified package in that flag
[14:43] <pitti> xnox: see dpkg-shlibdeps(1)
[14:44] <pitti> xnox: "version" as in "installed during package build", that is
[14:49] <xnox> pitti, interesting
[14:50] <juliank> Someone remind me to actually try to SRU ndiswrapper everywhere with newer kernels - all these build failure reports are somewhat annoying...
[14:50] <juliank> s/build failure/dkms failure/
[14:51] <juliank> It certainly would be nicer if we also did ndiswrapper uploads that work with new kernels when new kernels enter LTS releases
[14:54] <doko> wgrant: because you fixed xdelta3 to run the tests ... is the desktop team really the correct bug subscriber?
[14:55] <doko> I mean, they were for trusty, but now?
[15:06] <pitti> cpaelzer: https://launchpad.net/ubuntu/+source/postgresql-9.5/9.5.4-3
[15:22] <slashd> cyphermox, I have attach the debdiffs to LP: #1579609
[16:41] <seb128> @pilot in
[17:22] <chiluk> sarnold: mind if you upload https://bugs.launchpad.net/ubuntu/+source/virt-manager/+bug/1634304 for me?
[17:31] <chiluk> seb128:  ^^
[17:58] <sarnold> chiluk: sorry, I don't have sufficient privileges :(
[17:59] <chiluk> ah.. I figured you did considering your earlier review of that bug.
[17:59] <chiluk> or were you just a concerned user of virtinst?
[18:00] <chiluk> sarnold ^
[18:11] <sarnold> chiluk: pff, worse than that, I just can't help myself. I read every patch just because it's there. I should try to just a group therapy for it or something but no one else is wlling to publicly admit they suffer from the same condition
[18:12] <chiluk> sarnold: you are definitely in the minority within the minority.
[18:12] <sarnold> chiluk: aye.
[18:12] <sarnold> at least regular obsessed people climb mountains or something.
[18:13] <chiluk> sarnold: we give free operating systems to underprivileged kids in third world countries.
[18:13] <chiluk> I think that's pretty respectful.
[18:13] <sarnold> chiluk: thanks for being my ennabler :)
[18:14] <chiluk> any time.
[18:14] <chiluk> now go find me a sponsor.
[18:14]  * chiluk works on motu application.
[20:59] <wgrant> doko: I'm not sure who owns the snappy packages for main purposes. Will poke around.
[20:59] <wgrant> doko: Do you have any other concerns about the MIR so far?
[21:04] <maqifrnswa> Hello again - when someone gets a chance, can you re-trigger autopkgtest for python-qtconsole against ipython? https://autopkgtest.ubuntu.com/request.cgi?release=zesty&arch=amd64&package=ipython&trigger=python-qtconsole%2F4.2.1-3
[21:08] <maqifrnswa> There might be a circular dependency problem preventnig ipython, glueviz, and python-qtconsole from migrating
[21:09] <maqifrnswa> (from proposed). ipython used to have a bug in autopkgtest, so it would fail and never migrate. python-qtconsole autopkgtest saw that ipython couldn't migrate, so it wouldn't. glueviz sees python-qtconsle can't automigrate, so it won't - but it also requires the newest version of ipython (which is also stuck)
[21:11] <maqifrnswa> migrating ipython is prevented because it will break the old version of glueviz, but the new version of glueviz requires the new version of ipython
[21:12] <maqifrnswa> thank you!


[19:35] <pikachuAB> hey guys
[19:37] <pikachuAB> I am a student...and want to start contributing into open source. Would be great if someone help me to start


[22:14] <joey> FunnyLookinHat: thanks for the recommendation on the ratp3.  It's been exactly what I needed
[22:16] <FunnyLookinHat> joey, glad you like it!


[04:46]  * Guest42341 What a fine day for science!
[05:28] <RAOF> *Man* we don't care about object ownership at all.
[05:29] <RAOF> Want to receive events when a new surface is created? Congratulation! You're now a part-owner in all surfaces.
[05:31] <RAOF> Oh, for the love of god.  Hulk SMASH!
[05:47] <Guest42341> :))
[09:14] <duflu> anpok_: It appears in my bucket-of-cheap-spare-mice that I have a choice between too-fast or smooth-but-sometimes-missing-kernel-events. Any hints for making mice smoother or more reliable?
[09:14] <duflu> Hmm, maybe "don't use cheap spare mice"
[09:45] <alf> vogons: Please take a look at the Display configuration API proposals in https://docs.google.com/document/d/1wpoHVYdPZGthN2WS8oDvhRlpyuUqrizK1C4quE4XwMk/edit# so we can have more meaningful discussions during upcoming meetings (standup, eu/aus/us syncs)
[10:04] <sturmflut2> I finally rebuilt glmark2 against the stable phone overlay PPA so it works on OTA-7 again, but it looks like at least on krillin sometimes the OpenGL ES context freezes until I trigger an event in Unity8, e.g. swipe in the launcher or the app switcher.
[10:05] <sturmflut2> I can post a link to the new click package for testing purposes
[10:09] <sturmflut2> Also happens on mako
[10:18] <alan_g> sturmflut2: thanks for trying the rebuild. I'm not sure who's best placed to investigate, but the link will help.
[10:21] <sturmflut2> http://hogsmeade.lieberbiber.de/~sturmflut/glmark2.sturmflut_0.5.0_armhf.click
[10:22] <sturmflut2> alan_g: At least the binary continues to write to stdout and switches between the benchmark scenes, so it's not completely frozen I think, it keeps trying to output something that maybe then isn't handed to the display in the end?
[10:24] <sturmflut2> I'll build it against X11 on the desktop too to make sure it's not a problem with the glmark2 code itself
[10:27] <Guest42341> sturmflut2, glmark2
[10:27] <Guest42341> Segmentation fault (core dumped)
[10:27] <Guest42341>  (on wily)
[10:27] <sturmflut2> Works fine on a 15.10 desktop with an Intel Ivybridge CPU/GPU (i915 driver)
[10:30] <alan_g> alf: any thoughts on the above?
[10:32] <duflu> sturmflut2: Not your fault. We know about it... https://bugs.launchpad.net/qtmir/+bug/1497828
[10:34] <duflu> alan_g: That freeze is a known issue ^
[10:34] <duflu> And then it was EOD
[10:35] <alan_g> duflu: ack, have a good evening
[11:08] <alan_g> anpok_: what's the state of https://code.launchpad.net/~andreas-pokorny/mir/load-all-supported-input-platforms/+merge/274421? Your last comment links it to https://code.launchpad.net/~andreas-pokorny/mir/move-cookie-test-to-acceptance-tests/+merge/275502 which got rejected.
[11:12] <anpok_> alan_g: bschaefer made a better version of the same
[11:12] <anpok_> so I removed my mp
[11:13] <anpok_> and that one landed this morning
[11:13] <alan_g> So load-all-supported-input-platforms is good to go?
[11:13] <anpok_> yes..
[11:14] <anpok_> evertything is currently waiting on the input abi bump
[11:14] <anpok_> which I reworked after a discussin with raof hmm on friday
[11:15] <alan_g> Great.
[11:15] <alan_g>  alf: could you look over https://code.launchpad.net/~alan-griffiths/mir/nested-server-applies-display-config-policy/+merge/275542 - I think it is orthogonal to your proposal (modulo stuff that still needs fixing) but I'd like your thoughts.
[11:16] <alf> alan_g: doing that right now (I also linked a bug report about this I had file some time ago)
[11:17] <alan_g> :)
[11:29] <alf> anpok_: When you get the time could you please take a look at https://code.launchpad.net/~alan-griffiths/mir/nested-server-applies-display-config-policy/+merge/275542 (see my last comment)
[12:00] <alan_g> anpok_: Looks like the merged pre-req confuses LP - https://code.launchpad.net/~andreas-pokorny/mir/input-configuration-api/+merge/273975
[12:13] <tjaalton> I'm about to push mesa 11.0.4 with ftbfs fix (1509005) to xenial, FYI
[12:23] <anpok_> alan_g: aye
[12:23] <anpok_> alf: I believe that is close to the reverse of the bandaid we had
[12:26] <anpok_> alf, alan_g: I believe the problem back then with the split-out greeter was that the screen is turned off usc switched to a newly craeated greeter session that turned the displays back on again.. because the nested server applied the display configuration on startup..
[12:26] <anpok_> *when the screen..
[12:27] <anpok_> but a lot changed since then... maybe usc would catch that..
[12:29] <anpok_> adding that to the review
[12:29] <anpok_> (i really didnt like the 'solution' back then)
[12:29] <alan_g> anpok_: that sounds like it would be caught by the check I added for "!= current config"?
[12:32] <anpok_> alan_g: hm what if the nested session sees the screen turned off on startup?
[12:34] <alan_g> anpok_: rather than speculate, there ought to  be a test case (even if we decide to land these changes first).
[12:34] <anpok_> i mean then the configs would/might be != .. and it would apply them - still this is the wrong place to make that decision
[12:34] <anpok_> yes.. imo the nested server should do that..
[12:35] <alan_g> Hmm. The greeter doesn't go through the nested server, so these changes shouldn't affect it.
[12:36]  * alan_g wonders if he understood the scenario correctly
[12:39] <anpok_> alan_g: hm oh i dont know how the greeter is done currently. That split greeter back then never landed..
[12:40] <anpok_> so for that scenario you need to have a nested session, turn the screen off, start a second nested session, focus the second nested session..
[12:40]  * alan_g was thinking of the spinner
[12:41] <anpok_> hm spinner is not submitting a config, is it?
[12:41] <alan_g> no
[12:43] <alan_g> Sounds like this isn't a scenario that currently matters. (And with the other bugs in this area I suspect it has problems anyway.)
[12:45] <alan_g> And at least a part of it is about USC policy.
[12:49] <anpok_> hm i think I wrote something similar to the review
[13:04] <kdub> should we be sending an initial visibility event? (I think we should be)
[14:04] <alan_g> kdub: what do you mean by "an initial visibility event"?
[14:05] <kdub> https://code.launchpad.net/~kdub/mir/initial-visibility-event/+merge/275704
[14:05] <kdub> :)
[14:06] <alan_g> alf: NI answered? https://code.launchpad.net/~alan-griffiths/mir/nested-server-applies-display-config-policy/+merge/275542
[14:06] <alf> alan_g: yes


[04:40] <KickStarRabbit> hello
[04:40] <KickStarRabbit> i request my cloak be affiliated to ubunto I sent email to<EMAIL_ADDRESS>already
[04:40] <KickStarRabbit> is this the correct process
[07:00] <MooDoo> Have you read this ?. https://wiki.ubuntu.com/IRC/Cloaks
[07:01] <MooDoo> ah gone :(
[07:45] <MooDoo> pleia2: :p