[00:01] <cnd> RAOF: Sarvatt: there's some code here that I think we could duplicate for our purposes somewhat: http://lxr.linux.no/linux+v2.6.33/drivers/video/fbmem.c#L1509
[00:01] <cnd> it seems to destroy framebuffers that are already registered if a superseding one is found
[00:01] <cnd> what we need is a fb priority
[00:02] <cnd> where vga16fb = 0, vesafb = 10, intel, nouveau, radeon = 20
[00:02] <cnd> and we need to kick off lower prio framebuffers and prevent lower prio framebuffers from being added on after higher prio fbs
[00:03] <cnd> does that make sense?
[00:04] <RAOF> I think that's overcomplicated.  Our proper kms drivers are already loading first, and claiming devices.  I think this could be fixed more simply by vga16fb actually checking whether it can claim a device.
[00:04] <RAOF> I'm just not familiar enough with kernel internals to work out how to do that.
[00:06] <cnd> RAOF: see, that makes sense, except why did the dual gpu case have vga16fb grab the fb first?
[00:07] <cnd> so I'm thinking that there's a race condition in the loading of the modules
[00:07] <RAOF> Yeah, that's possible to.
[00:07] <cnd> the vga16fb module may be loaded second, but it registers first
[00:07] <RAOF> But claiming the fb != claiming the device.
[00:08] <cnd> RAOF: I'm not sure I follow
[00:09] <RAOF> I'm fairly sure that one problem is that vga16fb doesn't actually claim any hardware; it just grabs a pointer to the VGA memory and goes nuts writing in it.
[00:09] <RAOF> When it loads fast enough to get fb0, that results in the poor kms driver having all sorts of card state overwritten, because things actually write to fb0.
[00:10] <RAOF> When it loads and claims fb1, that's not such an issue; nothing's trying to output on fb1, so vga16fb doesn't scribble over interesting state.
[00:10] <RAOF> s/claims fb1/gets assigned fb1/
[00:10] <cnd> RAOF: still, we don't want it at all, cause if someone does try to access fb1 it'll mess things up, right?
[00:11] <RAOF> Right; I think that's what lshw is triggering.
[00:11] <Sarvatt> seems like something in the logic deciding which device to use and by the time its set up both enough to be ready to allocate fb's to them vga16fb already loaded, yeah
[00:11] <cnd> so that's where I think we need a fb priority
[00:12] <cnd> so that we can kick off vga16fb when nouveau comes after, or prevent vga16fb if nouveau comes first
[00:12] <RAOF> So, if vga16fb actually tried to claim a VGA device, in the sense of “let me scribble on this device iff no other driver thinks it can scribble on it”, then we'd be ok.  vga16fb would fail to load, because the kms driver has already claimed the hw.
[00:13] <cnd> RAOF: is your comment in reference to the priority implementation, or some other mechanism
[00:14] <RAOF> Some other mechanism.  I *know* drivers have the ability to claim hardware, because nouveau prevents nvidia from loading because nouveau's claimed the hardware.
[00:15] <cnd> RAOF: yes, but the problem here is: what if vga16fb claims the hw first?
[00:15] <cnd> it would prevent other drivers from working
[00:16] <Sarvatt> I think other framebuffer drivers actually have code to not screw up KMS and vga16fb just wasnt updated too
[00:16]  * cnd goes back to lxr
[00:16] <Sarvatt> like efifb will hand off control over to a KMS driver right
[00:17] <Sarvatt> in 2.6.33 at least, not lucid's kernel
[00:18] <Sarvatt> yeah - http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=4410f3910947dcea8672280b3adecd53cec4e85e and http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=89f3f2199084a160a3a45fa6d9af235696321758
[00:19] <RAOF> cnd: Yes, in that case vga16fb would prevent other drivers from working.  I think we're safe there because modules.order should ensure the kms driver starts loading first, and I think they claim hardware early.
[00:19] <cnd> Sarvatt: AHHH! they use that exact block of code I found
[00:19] <cnd> info->flags = FBINFO_FLAG_DEFAULT | FBINFO_MISC_FIRMWARE;
[00:20] <cnd> the FBINFO_MISC_FIRMWARE says "destroy me if another fb registers the same space"
[00:20]  * RAOF stands corrected.
[00:20] <cnd> so basically it's a binary priority like I suggested
[00:22] <cnd> so this looks fairly simple
[00:22] <cnd> just port the changes to vga16fb
[00:22] <cnd> I'll take a look at it
[00:23] <RAOF> Great!  Thanks.
[00:28] <Sarvatt> thanks for looking at it cnd, I'm swamped at the moment and can't mess with it
[02:18] <RAOF> cnd: Do you have a bug # about vga16fb in mind?  I'm wandering through the -intel bugs, and I think I've found some duplicates of that behaviour (multi gpu, vga16fb incorrectly claims fb0).
[02:19] <cnd> RAOF: no
[02:19] <cnd> I just tried a test kernel, but it didn't work :(
[02:19] <RAOF> :(
[02:19] <cnd> gotta figure out what went wrong
[02:21] <cnd> RAOF: actually, I think it would work
[02:21] <RAOF> If only...?
[02:21] <cnd> the current logic unregisters a fb if a better one comes along
[02:22] <cnd> but it doesn't prevent vga16fb from registering after a hw fb
[02:22] <cnd> so I've fixed up vga16fb, but I need to fix up the register_framebuffer logic
[02:24] <RAOF> You didn't make any change to fbmem.c? (Which seems to be where the registration happens)
[02:27] <cnd> RAOF: the change I made for the kernel I just tested was to enable handoff in vga16fb
[02:27] <cnd> now I'm changing fbmem
[02:27] <RAOF> Ah, right.
[02:44] <RAOF> I've moved bug #518387 over to linux for the vga16fb framebuffer fixes.  There's also bug #527369 with very different symptoms and almost certainly the same cause.
[02:44] <ubot3> Malone bug 518387 in linux "vga16fb sometimes claims fb0 before kms driver, a causing blank screen on boot" [High,Confirmed] https://launchpad.net/bugs/518387
[02:44] <ubot3> Malone bug 527369 in linux "sudo lshw causes console to turn blue on dell inspiron 1011 and fujitsu livebook T4410" [High,Triaged] https://launchpad.net/bugs/527369
[02:46] <cnd> RAOF: thanks
[02:47] <cnd> kengyu: around?
[02:47] <cnd> I see you've taken bug 527369
[02:47] <ubot3> Malone bug 527369 in linux "sudo lshw causes console to turn blue on dell inspiron 1011 and fujitsu livebook T4410" [High,Triaged] https://launchpad.net/bugs/527369
[02:47] <cnd> I'm working on a couple patches to fix it
[02:48] <cnd> hopefully I'll have some results in a bit
[02:48] <cnd> if you haven't done much, feel free to reassign it to me
[02:50] <cnd> kengyu: RAOF: going down for testing. if you don't see me back in a few mins I hosed my laptop and won't bother with it till tomorrow :)
[02:50] <RAOF> :)
[02:52] <RAOF> That looks promising :)
[02:53] <cnd> well, mostly cause it still didn't work right...
[02:53] <cnd> I still got me /dev/fb1
[02:55] <cnd> I'll have to do some printk debugging tomorrow
[02:55] <cnd> I'll post any updates in the bugs (hopefully in the form of a test kernel)
[02:55] <RAOF> Huzzah!
[05:14] <bryceh> JFo, btw I'm bumping some bugs over from radeon that needs quirk fixes in the drm, probably easy bugs.  Search for 'pll' in the linux bug list and they'll show up
[05:15] <bryceh> JFo, I don't think the bug reports are dupes, they are just different hardware that all need the same quirk or whatever
[05:15] <bryceh> JFo, they're all RV530/RV515 systems
[05:45] <crimsun> JFo: is there a tag to be used when a patch fixing a bug is CCed to<EMAIL_ADDRESS>[05:46] <crimsun> JFo: e.g., bug 502226
[05:46] <ubot3> Malone bug 502226 in linux "Audio Stops, video speeds up" [Undecided,Triaged] https://launchpad.net/bugs/502226
[05:46] <crimsun> JFo: to clarify, these are external patches lacking BugLink links in the git commit msg
[08:29] <JohnFlux> Hey all
[08:30] <JohnFlux> I made a change locally to ubuntu-lucid/drivers/staging/rt2870
[08:30] <JohnFlux> can I recompile just that driver and load it ?
[08:31] <JohnFlux> so far I've been using debian/rules  to recompile and install, which is kinda slow for each small change
[08:36] <bigon> https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/545585 << are you aware of this bug ?
[08:36] <smb> JohnFlux, You might carefully use "make O=./debian/builds/build-generic" (or whatever flavour you are compiling) if you did not clean up after the last full build
[08:36] <ubot3> Malone bug 545585 in linux "lucid iwlagn  free more than tfds_in_queue" [Undecided,Confirmed]
[08:36] <smb> bigon, No
[08:38] <bigon> it's spamming dmesg a lot
[08:38] <smb> bigon, Actually not from the header. But I know there seem to be problems with dropping the connection
[08:39] <bigon> smb: let me se if I get connexion drop
[08:40] <smb> bigon, At least the bug report you mention says something about drops. But the other reports seem to be either less or worse impacted. And without the message about tdfs_in_queue
[08:43] <amitk> cooloney: ericm_: it seems like the VFP patch from Imre that you included isn't yet ack'ed by Russell
[08:44] <amitk> bug 507503
[08:44] <ubot3> Malone bug 507503 in linux-mvl-dove "VFP/NEON state is not preserved around signal handlers, causing state corruption between user processes" [High,Fix released] https://launchpad.net/bugs/507503
[08:44] <amitk> specifically, he noted some problems with the patches
[08:46] <smb> bigon, Ah, ok. Finally went through the whole report. Seems the message itself might be a different issue. But I try to get a test kernel prepared for the proposed patch
[08:48] <bigon> smb: great
[08:59] <JohnFlux> smb: cd
[09:00] <JohnFlux> smb: /home/johnflux/ubuntu-lucid is not clean, please run 'make mrproper'
[09:00] <smb> JohnFlux, you are now in $HOMe
[09:01] <JohnFlux> :)
[09:01] <JohnFlux> smb: it says that when I do the make  command that you said
[09:01] <smb> with O= (careful never do mrproper)
[09:01] <JohnFlux> smb: yes, with the O=
[09:02] <JohnFlux> smb: I assumed you meant /build/ instead of /builds/
[09:02] <JohnFlux> ~/ubuntu-lucid (master)$ make O=./debian/build/build-generic
[09:02] <JohnFlux> I'm doing that
[09:02] <smb> As I tried to get the dirs from my memory likely
[09:03] <smb> maybe that needs a C= too... give me a sec
[09:14] <smb> JohnFlux, Hm, it seems to work for me. Potentially you could use $(pwd) instead of . (thought that should not change much).
[09:15] <JohnFlux> smb: I'm just doing "make modules" instead.  Any reason to not do it the old fashioned way?
[09:16] <amitk> JohnFlux: if you're getting the 'make mrproper' message, you've probably run make in the ubuntu kernel directory without the O=
[09:16] <smb> JohnFlux, But I think, when you did call make once wrong without O= it can spoil things. If you call make modules you do that
[09:16] <smb> amitk, I was thinking that
[09:17] <amitk> best to save your changes as a commit, reset the git tree and reapply the commit again
[09:17] <JohnFlux> hmm
[09:17] <smb> JohnFlux, You could recover by mv'ing debian one level up. Then call make mrpropoer and then mv debian back
[09:17] <smb> JohnFlux, builds with O= and without don't mix well
[09:17] <JohnFlux> I could just use 'make modules'  instead right?
[09:17] <JohnFlux> and not bother with the debian packages?
[09:18] <amitk> yeah
[09:18] <smb> Then you use a different configuration, get different function checksums and your module won't laod
[09:18] <smb> amitk, no
[09:18] <amitk> but assuming you copy the .config correctly
[09:18] <JohnFlux> I copied /boot/config-blah
[09:18] <smb> amitk, You need the right symversions
[09:18] <JohnFlux> I think it was the right .config
[09:19] <JohnFlux> and I built the kernel with AUTOBUILD=1    wasn't that to do with checksums or something?
[09:19] <amitk> smb: aah right, I thought he was just test compiling. The compiled modules won't work on the ubuntu kernel for shit
[09:19] <smb> And the symversions are only created by a full build, after that you could use that for incrementals
[09:20] <smb> JohnFlux, I'd run a full build once, then use "make O=$(pwd)/debian/build/build-generic modules
[09:20] <smb> for the incrementals
[09:20] <JohnFlux> do I need to prepend AUTOBUILD=1   to that?
[09:20] <smb> JohnFlux, AUTOBUILD is a herring rouge with lucid
[09:20] <smb> I don't think it has any effect
[09:21] <smb> JohnFlux, You just need a "fakeroot debian/rules binary-generic" run once
[09:22] <amitk> ...after resetting the tree
[09:23] <smb> amitk, right. After doing a make modules in there
[09:24] <JohnFlux> okay thanks - I'll give that a try
[11:46] <JFo> crimsun, sounds good, I'll look at them today
[11:47] <JFo> I don't know of a tag that we could use on them
[11:47] <JFo> rather bryceh :)
[11:47] <JFo> <-still half asleep
[11:51] <JFo> bryceh, I see 9 bugs. That sound about right?
[12:38] <JohnFlux> I. AM. BRILLIANT!
[12:38] <JohnFlux> smb: okay, so I got my hardware working with a one line change
[12:39] <JohnFlux> smb: just a simple case of adding the USB_DEVICE to the code
[12:40] <JohnFlux> smb: any chance I can just ask someone here to add the change?
[12:40] <JohnFlux> It would be great if this works out of the box for 10.04
[12:41] <smb> The preferred way would be to send it upstream. But for a start send it for discussion to<EMAIL_ADDRESS>It also helps to have a bug report open to refer to.
[12:46] <JohnFlux> yep, there's an open bug report about it
[12:50] <JohnFlux> smb: okay I wrote up my summary on https://bugs.launchpad.net/ubuntu/+source/linux/+bug/441990
[12:50] <ubot3> Malone bug 441990 in linux "Buffalo WLI-UC-GN 802.11n USB-WiFi adapter non functional" [Undecided,Confirmed]
[12:52] <smb> JohnFlux, Cool, thanks. If you either attach your patch there and/or send it with a reference to the bug to the mailing list to indicate there is a simple fix for that. Makes it a bit simpler to not loose things
[13:00] <JohnFlux> smb: done
[13:00] <JohnFlux> smb: I mean, I've sent an email to the mailing list
[13:01] <JohnFlux> hmm the email bounced
[13:01] <smb> JohnFlux, Ok, thanks. :)
[13:01] <smb> Hm, did I give the wrong address
[13:01] <JohnFlux> no, I've subscribed etc
[13:03] <JohnFlux> smb: should I create a proper git format-patch  for it?  It's so small it didn't seem worth it
[13:03] <JohnFlux> smb: did my email send correctly ?
[13:03] <JohnFlux> smb: "Trivial patch for supporting.."
[13:03] <smb> JohnFlux, Yep, its there
[13:03] <JohnFlux> okay good
[13:03] <JohnFlux> smb: so, should I send this 'upstream' as well?
[13:04] <JohnFlux> smb: does the email contain sufficient info?
[13:05] <smb> JohnFlux, For start its enough info. You should send it upstream. But then it needs a proper patch and go to the right people. Also I would add a CC<EMAIL_ADDRESS>in the section where you put your signed-off-by
[13:05] <smb> Give me a sec, lets see who should get it
[13:06] <JohnFlux> smb: reading the TODO file in the directory, it says to not bother the kernel people
[13:06] <smb> Oh, staging, then Greg
[13:06] <JohnFlux> smb: okay done - I've forward the email to him
[13:06] <smb> Err, he probably wants proper format
[13:06] <smb> Even for such small thing
[13:07] <JohnFlux> hmm
[13:07] <smb> He can afford to be lazy :)
[13:07] <JohnFlux> I guess, but it's such a pain to get git to send via gmail
[13:07] <JohnFlux> I can never remember how to get send-imap working
[13:07] <JohnFlux> :-)
[13:07] <smb> JohnFlux, I could forward it in your name and put your credentials into it
[13:08] <JohnFlux> that would be good thanks :)
[13:08] <JohnFlux> could you put both lines in
[13:08] <JohnFlux> both the changes that I suggest
[13:09] <smb> JohnFlux, Yep, either that or make two small patches of it. Do you have the other hw as well?
[13:10] <JohnFlux> nope
[13:10] <JohnFlux> but I gave a link where several users say it works for them
[13:10] <smb> Ah ok. Guess that should be enough
[13:52] <JFo> crimsun, we can use patched-upstream if you think that is descriptive enough
[14:21] <cnd> smb: there's some bugs where the vga16fb poorly interacts with other framebuffers
[14:22] <cnd> there's some logic to kick off generic framebuffers if a hw-specific fb comes along
[14:22] <cnd> but that logic is based on the aperture location overlapping between the generic fb and the hw fb
[14:23] <cnd> it seems that vga16fb, with its hardcoded aperture location, does not overlap with hw-specific fb aperture locations
[14:23] <cnd> I'm thinking of modifying the code that kicks a generic framebuffer off to do the same to vga16fb any time a new fb comes along
[14:23] <cnd> do you have any insight or thoughts?
[14:24] <smb> Ok, so that does not work. I don't know off my memory whether we build in vga16fb or not. I had the feeling its  module but loadded by early userspace
[14:24] <cnd> smb, we build it as a module
[14:24] <cnd> there's two problems
[14:24] <cnd> 1: there's a race condition where in dual gpu nvidia systems vga16fb somehow gets /dev/fb0 even though its loaded after nouveau
[14:25] <cnd> 2: even if nouveau gets /dev/fb0 and vga16fb claims /dev/fb1, if you run lshw as root it does something to /dev/fb1 that screws up the vt
[14:25] <cnd> so ideally we want vga16fb to be usable if there's no other fb available, but we want to kill it if there is
[14:26] <cnd> and really, any fb is better than vga16fb, so it makes sense to me to kill it if any other fb comes along
[14:26] <cnd> even vesafb
[14:27] <smb> cnd, That might be something to discuss with Keybuk. He knows the plumbing layer bringing up the fbs and stuff like that
[14:27] <cnd> smb, I think we're below the plumbing layer though
[14:28] <cnd> basically, I think we need to decide whether this approach is reasonable, because vga16fb is unmaintained upstream
[14:28] <cnd> I'll send out an e-mail to linux-kernel
[14:28] <cnd> but we may need to decide this ourselves
[14:29] <smb> And I am probably not so much help there. Yes, that might be a better idea. Though you probably want also to be sure there is nohing hard loading vga16fb
[14:29] <smb> For whatever reason. And understand that reason
[14:29] <cnd> smb, what do you mean by "hard loading"
[14:30] <smb> modprobe vga16fb
[14:30] <Keybuk> cnd: what kind of timescale are you thinking?
[14:30] <Keybuk> smb: nothing should do that, we load vga16fb by alias
[14:30] <cnd> Keybuk: what do you mean by that?
[14:30] <Keybuk> cnd: for the modifications you're talking about to vga16fb
[14:30] <smb> Keybuk, Ok, just wanted us to be sure
[14:30] <Keybuk> it sounds like the kind of project that would take longer than we have left before kernel freeze?
[14:31] <cnd> Keybuk: well, the modifications aren't very much, so I can have a patch ready by end of today
[14:31] <cnd> we're talking about 10 lines of code max
[14:31] <cnd> but I defer to you and smb as to whether that's still acceptable
[14:31] <Keybuk> but the "kick the generic framebuffer out" code in our current kernel is broken, right?
[14:31] <Keybuk> it works in .34
[14:31] <Keybuk> but not in .32
[14:32] <cnd> Keybuk: it seems to be all there to me
[14:32] <Keybuk> it isn't
[14:32] <Keybuk> breaks nouveau iirc
[14:32] <smb> cnd, Keybuk Well to me this sounds like it should not be hasted then
[14:32] <cnd> Keybuk: are you referring to vga16fb?
[14:32] <Keybuk> ok
[14:32] <Keybuk> let me back up a second
[14:32] <smb> cnd, Is blacklisting vga16fb a workaround?
[14:32] <Keybuk> smb: NO!
[14:33] <Keybuk> would it help if I explained for a moment why we're doing things the way we are right now
[14:33] <cnd> smb, we can't blacklist otherwise we can't fallback to vga16fb if its the only thing that works
[14:33] <Keybuk> and how we'd prefer to do them if we could
[14:33] <cnd> Keybuk: sure
[14:33] <Keybuk> ok
[14:33] <smb> yeah
[14:33] <Keybuk> so in general we want a framebuffer for our console
[14:33] <Keybuk> it means we're always using fbcon
[14:33] <Keybuk> it means our x86 story is the same as our ports story
[14:34] <Keybuk> and it means we can do things like always fallback to the X fbdev driver if we can't find a better one
[14:34] <Keybuk> but we can't quite do that today
[14:34] <Keybuk> so what we do today
[14:34] <Keybuk> KMS drivers include a framebuffer - so when we auto-load them by alias - we get a framebuffer (win!)
[14:34] <Keybuk> non-KMS drivers don't by default - so we arranged for vga16fb (most basic fb that works) to also be alias loaded
[14:34] <Keybuk> but alias loaded *after* anything else first like nouveau, radeon, intel, etc.
[14:35] <Keybuk> since vga16fb is just a framebuffer to the VGA, it doesn't bind to hardware like those do
[14:35] <Keybuk> but that has never seemed to be a problem
[14:35] <Keybuk> you just end up with an fb1 that would draw using the VGA if you reset the video mode back to a VGA mode
[14:35] <Keybuk> (and the KMS drivers have it in native modes, so you never see it)
[14:35] <Keybuk> so this works well enough
[14:36] <Keybuk> we have a framebuffer
[14:36] <Keybuk> (fb0 is either native or vga16fb)
[14:36] <Keybuk> so we have fbcon
[14:36] <Keybuk> and vga16fb is good enough for plymouth
[14:36] <Keybuk> but isn't good enough for X
[14:36] <Keybuk> --
[14:36] <cnd> Keybuk: the problem is there's a race condition we've seen where vga16fb will still get /dev/fb0 (bug 518387)
[14:36] <Keybuk> how we'd LIKE to do it:
[14:36] <ubot3> Malone bug 518387 in linux "vga16fb sometimes claims fb0 before kms driver, a causing blank screen on boot" [High,Confirmed] https://launchpad.net/bugs/518387
[14:36] <Keybuk> cnd: why would it cause a blank screen?
[14:36] <cnd> Keybuk: sorry, thought you were done, continue
[14:37] <Keybuk> if fb0 is vga16fb, that should imply that vga16fb is also what the fbcon is bound to
[14:37] <Keybuk> and it's what plymouth will draw to
[14:37] <cnd> Keybuk: probably some interaction between nouveau and vga16fb
[14:37] <Keybuk> so vga16fb winning should mean you lack KMS but not lack anything on screen
[14:37] <Keybuk> ok
[14:37] <Keybuk> so...
[14:37] <Keybuk> what we'd PREFER to have been doing
[14:37] <Keybuk> grub can set video modes via VBE, and can payload those into the kernel so the kernel knows a video mode has been set
[14:37] <Keybuk> if that happens, the kernel uses the "efifb" built into it
[14:38] <Keybuk> (since EFI's "the video mode is set" code is apparently so similar to VBE, it works with BIOS+VBE :p)
[14:38] <Keybuk> so we'd boot with efifb
[14:38] <Keybuk> this fails right now because fbcon is a module for some reason
[14:38] <Keybuk> if fbcon were built-in (like it is on arm, ports, etc.) then we would win
[14:39] <Keybuk> but with it as a module, if you have a boot failure before the module is loaded, you never see anything on screen after grub
[14:39] <Keybuk> so, we'd like GRUB to set the video mode, payload it into the kernel, kernel uses efifb from its own init, with a built-in fbcon
[14:39] <Keybuk> so we have a true colour framebuffer from the get go on all of our platforms
[14:40] <Keybuk> but then the real KMS driver loads
[14:40] <Keybuk> and that needs to kick out and transition the console from efifb to i915/nouveau/radeon/etc.
[14:40] <Keybuk> some of that code is in our kernel
[14:40] <Keybuk> but there are "it didn't work, make it work" bug fixes in .33 and .34
[14:40] <pmatulis> on hardy, is there any chance of adding support for a HP 10 Gb network card (HP NC522SFP; http://is.gd/aYF2r) ?
[14:41] <Keybuk> I suspect that's the same hand-off code you're talking about for vga16fb
[14:41] <pmatulis> module (netxen_nic) is in hardy but it doesn't work
[14:41] <cnd> Keybuk: so efifb would be kicked out with the code we have in the kernel, bug vga16fb can't be kicked out like that
[14:41] <Keybuk> cnd: efifb is not kicked out reliably with the code we have in the kernel *now*
[14:41] <cnd> Keybuk: either way, we still have the issue that vga16fb can't be kicked out using that framework (I think)
[14:42] <cnd> because the vga16fb aperture is a hardcoded 64K block of physical memory
[14:42] <Keybuk> right
[14:42] <cnd> but the vga16fb aperture is different than what's used by the hw fbs
[14:42] <Keybuk> yes
[14:43] <Keybuk> vga16fb is a wildly different type of framebuffer
[14:43] <cnd> so the vga16fb uses 0xA0000-0xB0000, but that never overlaps the nouveau fb at 0x80000000-<blah>
[14:43] <Keybuk> if you were talking to fb0 before, you'd be in planar mode
[14:43] <Keybuk> and most likely doing raw VGA16 opcodes
[14:43] <Keybuk> to suddenly have that switched to being a KMS-driven true-colour packed pixel fb would not work so well <g>
[14:43] <Keybuk> https://bugzilla.kernel.org/show_bug.cgi?id=15151
[14:44] <ubot3> bugzilla.kernel.org bug 15151 in Video(DRI - non Intel) "Black screen after loading nouveau module" [Normal,Closed: code_fix]
[14:45] <cnd> yeah, so basically efifb, with that fix, can be kicked off
[14:45] <Keybuk> yeah
[14:45] <cnd> but vga16fb can't be kicked off because its aperture will never overlap with hw-specific fb apertures
[14:45] <Keybuk> though then we'd have to test things like what if grub had the wrong resolution, how do we deal with resolution changes in plymouth, X, etc.
[14:45] <Keybuk> but once we solve that, and we have efifb => native fb (or just efifb all the way) then we have a great story
[14:45] <cnd> so my thought was: if there's ever another fb loaded, kick off vga16fb
[14:45] <Keybuk> there's always a framebuffer on x86, always a fbcon, X can always fallback to fbdev
[14:46] <Keybuk> we only ever do one more switch at grub, we can have grub paint purple ubuntu logos so there's no black screen during boot
[14:46] <Keybuk> cnd: but how do you kick it off?
[14:46] <Keybuk> and more to the point, how do you deal with the fact that userspace may have started using the vga16fb fb0?
[14:46] <cnd> Keybuk: in the same code that kicks off other generic fbs, just do it without checking the aperture overlap for vga16fb
[14:47] <Keybuk> cnd: but that isn't the same
[14:47] <Keybuk> that's my point
[14:47] <Keybuk> the "other code" works by handing over fb0
[14:47] <Keybuk> so fb0 never vanishes
[14:47] <Keybuk> just between instructions, the driver that's dealing with it can change
[14:47] <Keybuk> one minute you're drawing to efifb, the next you're drawing to nouveau
[14:47] <Keybuk> but you never know
[14:48] <Keybuk> (modulo resolution changes, etc. see above)
[14:48] <Keybuk> but you can't hand over fb0 from vga16fb to nouveau
[14:48] <Keybuk> as you pointed out, the aperture is wrong
[14:48] <Keybuk> the size of that aperture is wrong
[14:48] <Keybuk> the resolution is almost certainly wrong
[14:48] <cnd> Keybuk: This is the diff that does the hand off: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=4410f3910947dcea8672280b3adecd53cec4e85e;hp=b586640141ab5f4ab3b194419bc2c0f039e91dbc#patch3
[14:48] <Keybuk> and vga16fb is a planar framebuffer, not a packed pixel framebuffer! :D
[14:48] <Keybuk> so the code you use to write it is completely different!
[14:49] <cnd> there's nothing complex there, you just unregister the generic one and register the hw one in its place
[14:49] <cnd> I don't see why you can't just do the same for vga16fb, the only difference is you wouldn't check the aperture bounds first
[14:50] <Keybuk> because it'd crash any app talking to that framebuffer?
[14:50] <cnd> oh wait, I see what you're saying now
[14:51] <cnd> it's all because the aperture wouldn't be consistent across the transition
[14:51] <Keybuk> right
[14:52] <Keybuk> from a kernel POV that patch is almost certainly a good idea
[14:52] <Keybuk> but from a userspace POV, it won't work at all
[14:52] <cnd> yeah
[14:52] <Keybuk> I see fb0 turn up, it's vga16fb
[14:52] <Keybuk> so I mmap the VGA aperture, and I start drawing on it
[14:53] <Keybuk> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/lucid/plymouth/lucid/annotate/head:/src/plugins/renderers/vga16fb/vga.h#L43
[14:53] <Keybuk> that's example code from Plymouth that deals with vga16fb
[14:53] <Keybuk> see how it's actually talking directly to the VGA? :p
[14:54] <Keybuk> if you rip that frame-buffer out, and replace it with a packed pixel one, plymouth will just crash and burn
[14:54] <Keybuk> and so would X if that was running
[14:54] <Keybuk> etc.
[14:54] <cnd> Keybuk: so what do we do if we see that Ubuntu is failing on all nvidia dual gpu systems like in the bug?
[14:54] <Keybuk> the reason that aperture check is there in the hand-off code (aiui) is precisely because efifb/vesafb and nouveau/etc. *are* compatible
[14:55] <Keybuk> if you had fb0 mapped from efifb, you have the same address mapped as nouveau would map
[14:55] <Keybuk> so you can carry on regardless
[14:55] <cnd> yeah
[14:55] <Keybuk> cnd: well, I'd actually investigate why the nouveau module isn't creating the framebuffer first
[14:55] <Keybuk> that seems a bit odd
[14:55] <Keybuk> we already wait for nouveau init to return before trying vga16fb
[14:55] <JFo> cnd, bug 539878 was the one I meant to show you the other day when I was pinging you on LVDS stuff.
[14:56] <Keybuk> if nouveau init guaranteed it had made its framebuffer before returning, vga16fb would be always fb1
[14:56] <ubot3> Malone bug 539878 in linux "nouveau out of sync LVDS (basically card not supported)" [High,Triaged] https://launchpad.net/bugs/539878
[14:56] <JFo> sorry for the oversight
[14:56] <cnd> Keybuk: my guess (I could be wrong), is that the probe is asynchronous to the init
[14:57] <cnd> so nouveau inits and registers itself as the module, as does vga16fb
[14:57] <cnd> before nouveau_probe is called
[14:57] <Keybuk> cnd: yes
[14:58] <cnd> maybe you can add a spinlock or some such so the init doesn't return until the probe finishes, but that sounds messy
[14:59] <Keybuk> fwiw, it doesn't sound like the other drivers are async init
[14:59] <Keybuk> and it doesn't sound like nouveau is in the single-card case?
[15:00] <Keybuk> is it the single-card with dual-gpu case?
[15:00] <Keybuk> or the dual-cards?
[15:00] <cnd> not sure
[15:00] <Keybuk> because I have a thought
[15:00] <Keybuk> about dual-cards
[15:00] <Keybuk> bear with me a sec:
[15:00] <Keybuk> dual-cards have, err, dual cards
[15:00] <Keybuk> the first card is a PCI graphics card, the second is a PCI graphics card
[15:00] <Keybuk> what might happen is:
[15:01] <Keybuk> PCI announces first card
[15:01] <Keybuk> we modprobe nouveau
[15:01] <Keybuk> nouveau doesn't pick it up (nothing plugged in maybe?)
[15:01] <Keybuk> we modprobe vga16fb
[15:01] <Keybuk> vga16fb takes fb0
[15:01] <Keybuk> PCI announces second card
[15:01] <Keybuk> nouveau picks it up, takes fb1
[15:02] <cnd> Keybuk: sounds plausible, though I'm not sure how that could be fixed...
[15:02] <Keybuk> right :-/
[15:02] <Keybuk> it's a bugger
[15:02] <Keybuk> I do actually have dual nvidia cards here, so I can test :p
[15:02] <Keybuk> (and nouveau didn't work for me - this may be why)
[15:04] <cnd> Keybuk: now that I actually look at the bug some more, they don't even have nouveau loaded
[15:04] <cnd> so no wonder things didn't work...
[15:05] <cnd> oh wait, it's an intel bug
[15:05] <cnd> hrm...
[15:07] <smb> Keybuk, cnd, So I guess this is in good hands between the two of you. At least I understand why we don't want to get rid of vga16fb and that kicking off is not a good idea.
[15:08] <cnd> Keybuk: doesn't seem like we have useful data for that bug yet, the only data we have is pre 2.6.32-16 when we switched to .33 drm
[15:09] <cnd> Keybuk: the one thing we could do is forbid vga16fb from loading if there's already a fb
[15:09] <cnd> apparently, if you run lshw as root on a vt, it does something to vga16fb even if it's /dev/fb1 and causes issues (bug 527369)
[15:09] <ubot3> Malone bug 527369 in linux "sudo lshw causes console to turn blue on dell inspiron 1011 and fujitsu livebook T4410" [High,Triaged] https://launchpad.net/bugs/527369
[15:11] <Keybuk> possibly
[15:19] <zul> csurbhi: ping any progress on #276472?
[15:24] <Keybuk> cnd: the other obvious fix
[15:24] <Keybuk> vga16fb is loaded by alias
[15:24] <Keybuk> on load, it could check whether the device is one of those supported by nouveau, i915 and radeon, and simply return without enabling
[15:25] <Keybuk> actually
[15:25] <Keybuk> that would mean no splash for the nvidix-glx crowd
[15:25] <cnd> Keybuk: that's fine for ubuntu, but not in general, cause what if the modules aren't available?
[15:25] <Keybuk> in which case - don't ship vga16fb anyway
[15:25] <Keybuk> which is a "clear with sabdfl" issue
[15:27] <JohnFlux> smb: your email didn't have any sort of attachment
[15:27] <JohnFlux> smb: was it supposed to?
[15:27] <smb> JohnFlux, no, there were two other mails send as threaded mails
[15:28] <smb> [PATCH 1/2] Staging: rt2870: Add USB ID for Buffalo Airstation	NFinitiWLI-UC-GN
[15:28] <smb> [PATCH 2/2] Staging: rt2870: Add USB ID for Ralink 2070L
[15:28] <JohnFlux> oh I see.  git fixed that behave to add them as replies
[15:28] <JohnFlux> hmm, maybe not in a release version of git though
[15:28] <JohnFlux> *released
[15:28] <JohnFlux> s/behave/behaviour/
[15:29] <smb> JohnFlux, It seems to work. Though Thunderbird is often no so cooperative when they seem to arrive in the wrong order to it
[15:29] <JohnFlux> smb: gmail doesn't handle it at all
[15:30] <JohnFlux> smb: Anyway, upgrade git when the next release comes out :-)
[15:30] <JohnFlux> smb: and thanks
[15:31] <smb> JohnFlux, Heh, ok. Np, I try to get it into next upload (path 1) as sort of pre-stable. The other one I really would love to see some confirmation first
[15:32] <JohnFlux> can you post your .deb  somewhere?  And i'll ask people to try them directly?
[15:32] <JohnFlux> people are more likely to click on .deb than spend a whole day to compile and patch manually
[15:32] <smb> JohnFlux, Yes that was the plan. I will upload it to some place and add the pointer to the bug
[15:32] <JohnFlux> thanks
[15:50] <cnd> Keybuk: any chance we can skip to efifb still :)
[15:50] <Keybuk> cnd: not enough time to test all the permutations
[15:51] <cnd> there doesn't appear to be any locking when you register a fb, so I don't even see how we can reasonably do checks for vga16fb after hw fb
[15:51] <Keybuk> right now we have an issue with a simple story => "have this bug? blacklist vga16fb"
[15:51] <Keybuk> we'd be swapping it for a can that we haven't opened yet, and may contain worms
[15:51] <cnd> yeah
[15:52] <cnd> and for the lshw issue, I think we just need to fix lshw so it doesn't do whatever it's doing to the vga16fb framebuffer
[15:53] <Keybuk> right
[16:06] <cnd> smb: I'm getting somewhat lost in lxr, do you know if driver probe functions are called serially in all cases?
[16:07] <cnd> cking, amitk: ^?
[16:08] <cking> cnd, sorry, no idea on that
[16:08] <smb> cnd, IIRC probing can be parallelized. And you have some helpers to wait for certain groups.
[16:09] <cnd> I'm wondering how register_framebuffer gets away without any locking...
[16:09] <smb> cnd, apw / csurbhi have been looking into loading the ramdisk in parallel. There would be a patch for that in Lucid. Maybe that helps
[16:09] <cnd> smb, I'll take a look
[16:10] <cnd> hmmm, can't find anyting in git log
[16:14] <amitk> cnd: probing is parallelized as smb said
[16:15] <cnd> amitk: would you have any idea how register_framebuffer (called from probe functions) gets away without have any locking?
[16:15] <smb> If there is only one of its kind...
[16:15] <cnd> my guess is that most people don't have multiple framebuffers enabled
[16:16] <smb> Could be
[16:16] <cnd> but we'll have two in our kernel (hw and vga16 fbs)
[16:25] <cnd> smb: module loading is serialized, and we know that vga16fb is a module. What do you think of an ubuntu sauce patch just for lucid that keeps the vga16fb from registering if there's another fb already registerd
[16:26] <cnd> It could fail to work properly if vga16fb were compiled in statically, but it would fix bug 527369 in lucid, and we're likely to move to efifb for M per Keybuk
[16:26] <ubot3> Malone bug 527369 in linux "sudo lshw causes console to turn blue on dell inspiron 1011 and fujitsu livebook T4410" [High,Triaged] https://launchpad.net/bugs/527369
[16:28] <smb> cnd, I am a bit undecided atm. Or not sure to be able to think of all implications.
[16:29] <cnd> smb: if it makes you feel any better it would be a one-line patch :)
[16:29] <smb> cnd, If you think you can do a patch quite quickly, maybe do that and we discuss it on the ml
[16:29] <cnd> k, already got the patch built, just need to test
[16:29] <smb> Even those can have drastic effects. :)
[16:30] <cnd> yeah
[16:30] <smb> I wonder whether there could be a case where another fb is loaded but would not be usable but vga16fb would
[16:31] <cnd> smb: if that were the case, we'd probably have bigger issues, cause I assume everything in user space is trying to use /dev/fb0
[16:32] <cnd> Keybuk, any thoughts ^^?
[16:33] <Keybuk> everything is trying to use fb0
[16:33] <Keybuk> but I don't think you patch will help
[16:34] <Keybuk> you say that vga16fb is claiming fb0 and that is the problem
[16:34] <Keybuk> if it's claiming fb0, then that means that no other framebuffer is registered at that time
[16:34] <Keybuk> so your patch is a no-op
[16:34] <Keybuk> all your patch would do is stop fb1 appearing as vga16fb when we already have a framebuffer
[16:34] <cnd> Keybuk: I'm trying to solve a different problem
[16:35] <cnd> where vga16fb is /dev/fb1
[16:35] <cnd> no one should be using it
[16:35] <cnd> but if you run sudo lshw, it opens it
[16:35] <cnd> and corrupts the hw framebuffer
[16:36] <cnd> so my change would prevent vga16fb from registering /dev/fb1
[16:36] <Keybuk> ok
[16:36] <Keybuk> that sounds reasonable to me
[16:36] <cnd> ok, I'm going down to test, be back in a few (hopefully)
[16:38] <mjg59> Hm
[16:38] <mjg59> This sounds like a failure in resource allocation
[16:39] <mjg59> (an unsurprising one, but still)
[16:39] <mjg59> vga16fb should really be going through the vga arbiter
[16:39] <mjg59> Which should claim the resources
[16:39] <mjg59> And then refuse to let vga16fb bind if another driver is already there
[16:40] <cnd> mjg59: looks like I was rebooting while you were typing
[16:40] <cnd> what did I miss?
[16:40] <mjg59> 16:38 < mjg59> Hm
[16:40] <mjg59> 16:38 < mjg59> This sounds like a failure in resource allocation
[16:40] <mjg59> 16:39 < mjg59> (an unsurprising one, but still)
[16:40] <mjg59> 16:39 < mjg59> vga16fb should really be going through the vga arbiter
[16:40] <cnd> smb: Keybuk: patch worked, vga16fb failed to load
[16:41] <pabelanger> Afternoon.
[16:41] <cnd> mjg59: the issue is that vga16 has a hard coded aperture location (64K at 0xA0000) that is separate from where the modern aperture locations are
[16:41] <mjg59> cnd: That's what the vga arbiter is for
[16:41] <cnd> ahhh
[16:43] <cnd> I looked at vgaarb last night, but it didn't seem related
[16:43] <pabelanger> If I have distcc setup, and used the 'fakeroot debian/rules binary-...' script, would I have to do anything special to make it use distcc? Or would environment variables be enough
[16:44] <cnd> mjg59: still, even if it should be using vgaarb, that would require a rewrite of vga16fb, right?
[16:45] <mjg59> cnd: Yeah
[16:45] <mjg59> Which isn't high on my list of requirements :)
[16:45] <cnd> understandably so :)
[16:46] <cnd> mjg59: we'll be pushing to move away from vga16fb for M anyways, if I understood Keybuk right
[16:46] <cnd> so a quick and dirty hack for Lucid may be the best option given the Lucid timeframe
[16:50] <Keybuk> bearing in mind of course that the pushing to move away is to something we figured out only last week :p
[16:50] <mjg59> Ha. What?
[16:51] <Keybuk> abusing efifb ;)
[16:52] <mjg59> There's no real functional difference between efifb and vesafb
[16:52] <mjg59> You end up with the same suspend/resume issues
[16:53] <mjg59> That's why we went with vga16fb rather than vesafb
[16:53] <mjg59> (way, way back in the day)
[16:57] <Keybuk> ah right, that's interesting to knpw
[16:57] <mjg59> Both just give you access to an unaccelerated linear framebuffer
[16:57] <Keybuk> the suspend/resume issue being "can't reset the mode"?
[16:58] <mjg59> The only difference is how you got that - with efifb you've got a mode set by the bootloader, with vesafb you've got a mode set by the kernel on entry
[16:58] <mjg59> efifb has no way of resetting a mode on resume
[16:58] <mjg59> You could potentially reset a vesa mode, but that depends on being lucky in vbios implementation
[16:58] <Keybuk> how does efifb reset the mode when you VT switch out of X?
[16:59] <mjg59> It doesn't
[16:59] <Keybuk> (or vesafb for that matter)
[16:59] <mjg59> X is responsible for reprogramming the original mode
[16:59] <Keybuk> ahh, right, I know this
[16:59] <mjg59> The advantage of vga16fb is that if you hit the hardware before it's initialised, you tend to just get your port io timing out
[17:00] <mjg59> Whereas with vesa, you're writing to a region of memory that may now be used by the card for something else entirely
[17:00] <Keybuk> right, because it can move across a suspend/resume
[17:00] <mjg59> Yeah, you have no idea what state the card is in on resume
[17:01] <mjg59> With vesafb, you can freeze the framebuffer before suspend, try reprogramming it with vbetool on resume and then unfreeze it
[17:01] <mjg59> But with efifb, you don't know what mode you were in to start with...
[17:01] <mjg59> (Note that the freeze/reprogram/resume thing helps but does not fix this issue)
[17:02] <Keybuk> yeah
[17:02] <Keybuk> it almost becomes easier to declare that we don't support suspend/resume if you install nvidia-glx
[17:03] <Keybuk> and remove the menu options <g>
[17:03] <mjg59> nvidia will typically manage suspend/resume itself, as long as it's entirely in control of modesetting
[17:03] <mjg59> Which means no console framebuffer with the exception of vga16fb
[17:04] <bryceh> JFo, sounds right
[17:04] <bryceh> JFo, I think we've been tagging them needs_pll_quirk or some such
[17:29] <JFo> bryceh, yeah, I see the descriptions with that in
[17:35] <bdrung^2> what's the status of the lucid kernel regarding SSDs? Is TRIM supported in ext4?
[19:21] <pmatulis> lastlog -clear
[19:22] <pmatulis> will there be another point release of 8.04 ?
[19:44] <smb> Just for the (public) record: not one I am currently aware of. The last I know was beginning of this year
[22:31] <crimsun> manjo: for bug 548371, your mic switches are muted again. Did you uncheck the sound preferences and untick (unmute) the mic in the Input tab?
[22:31] <ubot3> Malone bug 548371 in pulseaudio "[LUCID] Samsung N310 External microphone unable to record sound." [Undecided,New] https://launchpad.net/bugs/548371
[22:55] <manjo> crimsun, yes I did
[22:55] <manjo> crimsun, I even increased the input to 1/2 way
[22:57] <crimsun> manjo: can you rerun http://www.alsa-project.org/alsa-info.sh, please?
[22:57] <manjo> crimsun, yes can do ... give me 10mts to reboot that netbook again
[23:04] <crimsun> to conference, will check back
[23:10] <manjo> crimsun, uploaded info you asked for
[23:30] <RAOF> Argh!  Die, vga16fb, die!
[23:55] <RAOF> I don't suppose we can flip around our vga16fb system?  Currently we have a patch adding an alias so that vga16fb bind to any VGA device - could we instead make drivers that won't provide kms manually add vga16fb?
[23:56] <RAOF> Man, that was broken English.


[04:08] <Taggg> hi, can anyone tell me how long a bug fix bzr branch typically takes to get merged into the current development series?
[05:35] <ScottK> It would be nice if someone could look at what's up with python-qt4 and autopkgtests.  It's been running them for about a day now.
[06:29] <lifeless> ScottK: it's aiming for completeness :P
[06:30] <ScottK> I'm not in a particular rush for it, as long as it's progressing.
[07:32] <dholbach> good morning
[07:36] <didrocks> thanks cjwatson for promoting some parts (not sure what triggered you looking into it as Mir was in universe)
[07:36] <JackYu> dholbach, morning:)
[07:37] <cjwatson> didrocks: dep-wait from mesa.  Am I good to finish the promotion now that you're around?
[07:38] <didrocks> cjwatson: I've finished it, just need a publisher run I think
[07:38] <cjwatson> ok, cool
[07:38] <didrocks> cjwatson: you can unblock xorg-server and mesa that Laney should have pinned
[07:38] <dholbach> hi JackYu
[07:38] <didrocks> (it was to avoid promotion during the week-end and nobody around to look)
[07:40] <cjwatson> didrocks: it was just xorg-server.  Done
[07:40] <didrocks> thanks
[07:41] <cjwatson> there'll be a publisher run starting in two minutes
[07:41] <didrocks> excellent ;)
[07:41] <didrocks> cjwatson: FYI, one those are migrated, we'll make unity-system-compositor (depending on this xorg-server + driver patches) entering the archive but staying in universe
[07:41] <didrocks> basically, it's installing this package that toggles Mir on/off
[07:41] <cjwatson> ok
[07:42] <didrocks> so, hopefully, nobody will notice the difference right now, with that additional build-dep without u-s-c
[07:42] <dholbach> does anyone know why there's "syncpackage: Error: Debian version 1.11-2 has not been picked up by LP yet. Please try again later."?
[07:43] <dholbach> according to mitya57: "I don't know what to do about that, given that the package was uploaded > two weeks ago."
[07:43] <cjwatson> I already answered that on #launchpad a while back
[07:43] <cjwatson> And filed a bug on the broken Debian package that failed import
[07:44] <cjwatson> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=718605
[07:45] <dholbach> ah ok cool - thanks
[08:08] <seb128> doko, hey, can you commit your gtk+ changes to the packaging vcs?
[08:09] <doko> otp
[08:13] <seb128> jibel, hey
[08:13] <seb128> jibel, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html is blocking poppler because libreoffice tests failed, hitting a disk space issue ... can you do something about it?
[08:14] <jdoles> cjwatson: I don't know, but it only worked when I did LC_ALL=C pwdx
[08:16] <cjwatson> As opposed to what other locale?
[08:16] <cjwatson> And did you get strace output?
[08:17] <cjwatson> Mind you its strtol calling sequence looks broken
[08:19] <jdoles> cjwatson: this is broken for example: LC_ALL=en_US.UTF-8 pwdx 23879
[08:19] <jdoles> Even if the locale would not exist, it should still fall back to C.
[08:19] <cjwatson> jdoles: please could I see strace output?
[08:20] <cjwatson> And does the locale not exist in this case?
[08:20] <cjwatson> aha, never mind, reproduced it
[08:23] <jdoles> cjwatson: http://paste.kde.org/p7354a5b2/
[08:23] <jdoles> cjwatson: this is my strace.
[08:23] <jibel> cjwatson, does something need to be done for poppler blocked on libreoffice or it will be considered anyway because libreoffice is hinted?
[08:23] <cjwatson> jibel: the autopkgtest needs to be unstuck
[08:24] <cjwatson> or forced
[08:24] <cjwatson> jibel: ah, I have a force at an old version.  I'll update it
[08:24] <cjwatson> seb128: ^-
[08:24] <seb128> cjwatson, jibel: thanks
[08:25] <jdoles> cjwatson: I think a tool like pwdx probably also shouldn't be implemented in C in the first place.
[08:25] <cjwatson> jdoles: Nonsense
[08:25] <cjwatson> It's in procps, it's perfectly reasonable to be in C
[08:25] <cjwatson> jdoles: It's a one-line fix, I think.  I'll test shortly and file a Debian bug with the patch
[08:26] <jdoles> cjwatson: sure, everything can be written in C, but nobody is going to run pwdx in an inner loop and shell would be fast enough.
[08:26] <cjwatson> It's a system utility, it's not that complex in C
[08:26] <cjwatson> Shell has its own gotchas
[08:26] <cjwatson> This is a pointless discussion since I'm not going to reimplement it anyway
[08:26] <cjwatson> Seeing as I'm not procps upstream
[08:27] <jdoles> cjwatson: I thought the idea of having your own OS was that you could replace everything you didn't agree on :)
[08:27] <cjwatson> Eh, that doesn't mean doing work for the sake of it
[08:27] <cjwatson> This is also a collaborative OS
[08:28] <jdoles> The way I see it is that a bug was introduced because of premature optimization.
[08:28] <cjwatson> I'm not going to continue this
[08:28] <cjwatson> I'm going to fix the bug instead
[08:29] <jdoles> cjwatson: ok, let'
[08:29] <jdoles> s just end the discussion there.
[08:33] <didrocks> cjwatson: just noted a funny thing, RAOF has xorg-server depending on mir on powerpc where Mir doesn't build on powerpc
[08:34] <didrocks> so I guess it will get block on proposed, I think xorg-server should treat powerpc as mir-less
[08:39] <cjwatson> didrocks: Agreed
[08:39] <cjwatson> Presumably that's easy enough
[08:40] <didrocks> cjwatson: the drivers are patched to use some xorg - xmir API, they need to #ifdef to return false on powerpc I guess
[08:41] <RAOF> BAh.
[08:41] <cjwatson> I suppose so
[08:41] <RAOF> Well, they (should) build and work against a non-XMir server, so it's a simple matter of arch-restriction.
[08:41] <didrocks> RAOF: as the drivers have some xorg-xmir api call, does the #ifdef thing make sense to unblock them? (and so, removing the mir build-dep on powerpc)?
[08:42] <didrocks> ah nice, you already have that detection when building
[08:42] <didrocks> (xorg)
[08:42] <RAOF> Yup.
[08:42] <RAOF> Less well tested, but *should* work.
[08:42] <didrocks> RAOF: want to try that upload? ;)
[08:43] <RAOF> The life of ppc
[08:43] <didrocks> heh, indeed :)
[08:43] <RAOF> What's the arch string for ppc? ppc?
[08:43] <RAOF> Ah, powerpc.
[08:43] <cjwatson> Debian architecture or GCC?
[08:44] <RAOF> Debian arch; I see it's powerpc.
[08:44] <cjwatson> Indeed
[08:48] <cjwatson> jdoles: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=718766
[08:54] <chrisccoulson> hmmm, any idea what might have caused https://launchpad.net/~ubuntu-mozilla-security/+archive/ppa/+build/4848763 ? (and should i just retry it?)
[08:56] <lifeless> cjwatson: in case you missed scrollback - I've finally files bug 1208268 about my grub issue on 3TB GPT disks... any pointers on moving forward will be much appreciated
[08:56] <ogra_> chrisccoulson, i'd ask in #launchpad ... probably there is a way to prevent you from having to rebuild
[08:57] <maxb> I do not think there is
[08:59] <RAOF> didrocks: Enjoy your PPC upload.
[08:59] <ogra_> RAOF, oh, should XMir work on armhf ?
[08:59] <didrocks> RAOF: I'll surely enjoy it deeply! Thanks :)
[08:59] <cjwatson> lifeless: Ah, not sure I'm going to have time to have a look for some time unfortunately - got a lot to do before debconf next week
[08:59]  * ogra_ ponders to trash his chromebook for a try :)
[09:00] <didrocks> ogra_: you will need to install unity-system-compositor once available to trash it properly though :)
[09:00] <ogra_> hehe
[09:00] <RAOF> ogra_: Yes, as long as your armhf system has an nvidia, radeon, or intel GPU :)
[09:00] <cjwatson> lifeless: I guess grub-probe -vv is always useful
[09:00] <ogra_> well, i'm not sure Mir itself will work yet
[09:01] <lifeless> cjwatson: thats ok, I have a workaround (USB key ;))
[09:01] <lifeless> cjwatson: attaching that now
[09:01] <ogra_> RAOF, mali ... same board as the nexus 10 (manta)
[09:01] <cjwatson> (with whatever grub-probe call is actually failing)
[09:02] <lifeless> cjwatson: it installs fine, the error is when you reboot
[09:02] <RAOF> ogra_: No dice, at least until we do a generic egl-based XMir driver.
[09:03] <ogra_> yeah, i feared that
[09:04] <cjwatson> lifeless: oh dear, that's unusual
[09:05] <cjwatson> lifeless: Might be worth trying installing with --debug-image=all and seeing what the last screenful of output is
[09:05] <cjwatson> (Though I appreciate this may be a pain to iterate on)
[09:06] <lifeless> cjwatson: last screenful of output from the install, or from booting ?
[09:06] <cjwatson> lifeless: install
[09:06] <cjwatson> err
[09:06] <cjwatson> sorry, misunderstood
[09:06] <cjwatson> lifeless: booting :)
[09:07] <lifeless> cjwatson: when I previously mentioned this to you you suggested getting some disk sectors might let you reproduce? I will capture a photo of the boot shortly...
[09:07] <didrocks> RAOF: seems you have to do a .install file dance
[09:07] <didrocks> https://launchpadlibrarian.net/146820236/buildlog_ubuntu-saucy-powerpc.xorg-server_2%3A1.14.2-0ubuntu5_FAILEDTOBUILD.txt.gz
[09:07] <lifeless> right now... for dev in /dev/sdb /dev/sdc /dev/sdd /dev/sde; do ....
[09:08] <RAOF> didrocks: Whoops. Oh, no, I just need to be less stupid
[09:14] <cjwatson> seb128: so the remaining poppler blocker is that docvert-libreoffice depends on python-uno, which has been removed in the latest libreoffice in favour of python3-uno
[09:15] <seb128> cjwatson, I was *just* looking at that as well/building the python-uno rdepends list
[09:15] <cjwatson> seb128: the actual Python code in question is (confusingly) in docvert rather than docvert-libreoffice, but it does otherwise seem like a real problem
[09:15] <cjwatson> core/lib/pyodconverter/pyodconverter.py
[09:16] <cjwatson> Do you know if there was a particular reason to aggressively remove python-uno in advance of Debian?
[09:18] <seb128> cjwatson, I don't, trying to have a look
[09:19] <cjwatson> I would have expected Sweetshark to use grep-dctrl or similar to search for reverse-dependencies before dropping the binary ...
[09:20] <seb128> cjwatson, not explanations with the commit: http://anonscm.debian.org/gitweb/?p=pkg-openoffice/libreoffice.git;a=commitdiff;h=a2d74f4a43949da2710a29e63fd3a9d87f679ecf
[09:21] <cjwatson> Indeed
[09:21] <seb128> cjwatson, and Sweetshark is off on holidays this week :/
[09:21] <cjwatson> (What on earth was that Conflicts doing there ...)
[09:21] <cjwatson> Oh, I suppose it actually ships stuff in /usr/lib/libreoffice/ as well
[09:22] <cjwatson> seb128: So, I could demote docvert to -proposed for now, if you could make sure to get Sweetshark to sort this out when he gets back
[09:22] <seb128> cjwatson, that would be great, thanks
[09:23] <lifeless> cjwatson: output in a photo linked on https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1208268
[09:23] <lifeless> cjwatson: let me know if you can't access it and I'll shuffle it into LP itself
[09:25] <cjwatson> lifeless: thanks, yes I can.  FWIW GRUB thinks your drive doesn't have LBA extensions
[09:25] <cjwatson> Apparently
[09:25] <lifeless> cjwatson: interesting... it is a 3TB drive on a fairly old machine, but linux handles the entire drive just peachy
[09:26] <lifeless> cjwatson: and the bios boot partitions are at the front, deliberately.
[09:26] <cjwatson> Not saying it's necessarily right, but that's why it's failing
[09:26] <cjwatson> I suspect there's RAID metadata or something at the back
[09:26] <lifeless> sure; just erring on the side of verbal diarrhea
[09:27] <cjwatson> All hail --debug-image=all for making this clear in a single screenshot though :)
[09:27] <lifeless> :>
[09:28] <mlankhorst> ever since sweetshark has left on vacation I've been hearing a lot less about libreoffice!
[09:28] <cjwatson> Linux will be using a proper driver rather than going through the BIOS
[09:29] <lifeless> cjwatson: yeah - 2007 motherboard :)
[09:29] <cjwatson> Really shouldn't be lacking LBA
[09:30] <lifeless> definitely has some LBA support; previous drives were 1TB's, which IIRC were also in the LBA only world.
[09:30] <cjwatson> Though of course it's the BIOS version that matters, not the motherboard, but even so
[09:31] <cjwatson> Either GRUB thinks that INT 13h extensions aren't present at all, or it tried one of them and got the impression they were broken
[09:32] <cjwatson> seb128: Demoted - https://launchpad.net/ubuntu/+source/docvert/+publishinghistory
[09:35] <cjwatson> lifeless: Oh, I had a factor of two error, I had the limit in my head as 4TB not 2TB
[09:35] <lifeless> cjwatson: googling is suggesting that LBA has a 2.1GB limit of some sort.
[09:35] <cjwatson> lifeless: Traditional BIOS can't reliably read from over 2TB
[09:35] <doko> RAOF, xorg-server, please do the same for arm64 (as for powerpc)
[09:37] <lifeless> cjwatson: so, understood. But grub shouldn't need to to bring this up.
[09:37] <cjwatson> lifeless: In theory the call is 64-bit-capable (https://en.wikipedia.org/wiki/INT_13H#INT_13h_AH.3D42h:_Extended_Read_Sectors_From_Drive), but in practice my understanding is that you're hosed without UEFI
[09:37] <lifeless> cjwatson: it's not showing the mdadm filter being invoked at all, for instance.
[09:37] <cjwatson> lifeless: So is - look at the mentions of diskfilter in that screenshot
[09:37] <cjwatson> grub's raid module is a layer on top of diskfilter
[09:37] <lifeless> ok.
[09:38] <cjwatson> There's one remaining way I can think of in which this might be GRUB's fault
[09:38] <cjwatson> What RAID version are you using on this array?
[09:39] <cjwatson> metadata version, I mean
[09:40] <lifeless>         Version : 1.2
[09:40] <cjwatson> So that stores the metadata 4K from the start of the device
[09:41] <lifeless> thats my understanding :)
[09:41] <cjwatson> It's possible that GRUB tries to read from the end of the partition when checking for the presence of some other metadata version, and then incorrectly thinks LBA is completely broken and falls back to CHS
[09:42] <lifeless> that sounds plausible to me
[09:42] <lifeless> this is a problem that will self solve itself eventually
[09:43] <cjwatson> If that is the case, then http://paste.ubuntu.com/5950617/ should help
[09:44] <cjwatson> (Could doubtless be tighter as the addressable CHS range is smaller than that)
[09:45] <lifeless> I'll try rolling a custom package with that , but not tonight
[09:45] <cjwatson> Also that code has wrong error handling, so isn't applicable as-is
[09:45] <lifeless> oh, I shouldn't try the patch?
[09:47] <lifeless> of course, content in /boot/ could be too high up the disk, but thats a different discussion; I can make a vg and shuffle it to the front once we get far enough up the stack
[09:48] <cjwatson> lifeless: Perhaps http://paste.ubuntu.com/5950640/ instead
[09:50] <lifeless> linked in the bug.
[09:50] <lifeless> Thanks for making the time to eyeball this.
[09:52] <cjwatson> ta
[09:57] <smartboyhw> How long does a uploaded package wait in the queue before it gets approved into -proposed?
[09:57] <cjwatson> smartboyhw: Which queue?
[09:57] <smartboyhw> cjwatson, raring
[09:57] <cjwatson> Which queue in raring?
[09:57] <smartboyhw> cjwatson, SRU ofc
[09:57] <cjwatson> (new, unapproved, ...)
[09:58] <smartboyhw> unapproved
[09:58] <cjwatson> can't give you a particular time period, depends on SRU team members having time to review
[09:58] <ogra_> shouldnt promotion to -proposed be immediately ?
[09:59] <cjwatson> ogra_: no, not for unapproved
[09:59] <smartboyhw> ogra_, obviously, it needs a SRU team member to approve it in...
[09:59] <ogra_> ah
[09:59] <cjwatson> this is ibus-cangjie I presume
[09:59] <smartboyhw> cjwatson, yeah...
[09:59] <smartboyhw> Stuck for 25 days
[09:59] <cjwatson> I'll have a look now
[09:59] <smartboyhw> cjwatson, many thanks!
[10:01] <cjwatson> smartboyhw: seems fine, apologies for the delay.  accepted
[10:01] <smartboyhw> cjwatson, great! Thanks
[10:24] <seb128> doko,  lp:~ubuntu-desktop/gtk/ubuntugtk3 for the gtk packaging vcs btw
[10:25] <ev> seb128: do you happen to know if there's plans for a first use screen on Touch?
[10:25] <ev> or who would know the answer to that? :)
[10:26] <seb128> ev: there is, Cimi is working on it
[10:26] <ev> seb128: how convenient. He often sits next to me.
[10:26] <ev> cheers
[10:26] <seb128> yw
[10:26] <Cimi> ev, see you friday :P
[10:26] <ev> is there a blueprint/google doc that you're aware of?
[10:26] <ev> Cimi: :D
[10:27] <Cimi> ev, shared
[10:27] <ev> thanks!
[10:31] <wizard_A> how to get the callback function that is called when someone right clicks on a file..
[10:31] <didrocks> RAOF: I think I'll do another xorg-server upload, there is an extra build-dep on powerpc from the -dev package
[10:48] <seb128> cjwatson, seems like docvert still makes libreoffice unhappy?
[10:48] <seb128> cjwatson, or does it need another publisher cycle?
[10:48] <cjwatson> Oh, damn, I forgot to block it
[10:50] <wizard_A> which portion of the code does get executed when someone right clicks on a file in ubuntu??
[10:50] <cjwatson> seb128: should work next run
[10:51] <seb128> cjwatson, thanks
[10:57] <seb128> cjwatson, great, it migrated this time ;-)
[10:57]  * seb128 just got a bunch of archive emails about the poppler stack hitting saucy
[10:58] <wizard_A> i want to work on feature of ubuntu, please help me get started
[10:59] <cjwatson> wizard_A: there's no single answer to that question; it depends on the context where you're right-clicking
[11:00] <wizard_A> yes
[11:00] <cjwatson> like, is it on the desktop, or the open dialog in some application (which?), or ...
[11:00] <wizard_A> a file icon within the directory browser
[11:01] <cjwatson> the directory browser, as in nautilus?
[11:01] <wizard_A> what is nautilus??
[11:02] <wizard_A> yes
[11:02] <cjwatson> nautilus is the file manager from GNOME
[11:03] <wizard_A> yes thats where i was meaning.......
[11:03] <wizard_A> sorry i am just begining to develop so i stumble upon many things... sorry for that
[11:06] <seb128> wizard_A, what are you trying to achieve? add a menu item to that right click menu?
[11:06] <wizard_A> yes
[11:06] <cjwatson> Right, so this is why you need to know which application you're right-clicking in.  The widget toolkit (usually GTK+ or Qt - GTK+ in the case of nautilus) implements a lot of generic behaviour, but nautilus does its own context menus
[11:07] <cjwatson> It connects to the "button-press-event" signal on its view and detects right button presses
[11:07] <cjwatson> (well, button 3)
[11:09] <cjwatson> I believe that the contents of the context menu are defined in src/nautilus-directory-view-ui.xml
[11:09] <seb128> you can add items through libnautilus-extension
[11:09] <seb128> look at ubuntuone-client-gnome or file-roller for examples
[11:09] <cjwatson> Yeah, that would normally be better
[11:09] <seb128> e.g file-roller add "extract here..." items when you right click on an archive
[11:10] <seb128> wizard_A, e.g https://git.gnome.org/browse/file-roller/tree/nautilus/nautilus-fileroller.c
[11:10] <cjwatson> seb128: oops, I may have been wrong in asking you to patch shared-mime-info - looks like I should have shipped my own .xml file in click (according to upstream)
[11:11] <cjwatson> so I'll do that and revert the shared-mime-info change
[11:11] <seb128> cjwatson, ok, works for me. What's the rational? that the number of handlers for that type is mostly going to be low?
[11:11] <wizard_A> what i am trying to achieve is: when someone already has vlc installed onto system then any .mp3, .avi, .mkv etc files right click option should contain a menu as "Add to vlc media playlist".
[11:12] <cjwatson> seb128: that it's basically specific to a single package
[11:12] <seb128> cjwatson, I never understood where they draw the line, seems to depends of the maintainer of the day, they include e.g the deb and rpm types
[11:12] <cjwatson> https://bugs.freedesktop.org/show_bug.cgi?id=66689
[11:13] <seb128> ok, that makes sense
[11:13] <cjwatson> meh, I'm happy to go with the flow for now rather than fight upstream about it
[11:13] <cjwatson> save energy for more useful fights :)
[11:14] <cjwatson> There's python-nautilus too
[11:14] <seb128> indeed
[11:19] <wizard_A> cjw: does the patch mean that its already done??
[11:24] <cjwatson> wizard_A: what patch?
[11:24] <wizard_A> patch for bug66689
[11:24] <cjwatson> wizard_A: that was one suggested patch which I'm now going to do in a different way
[11:24] <cjwatson> wizard_A: but it was unrelated to the conversation with you
[11:25] <wizard_A> oh i see
[11:26] <wizard_A> so how do i get started with my idea, i really want to learn contributing to ubuntu..
[11:31] <seb128> wizard_A, look at https://git.gnome.org/browse/file-roller/tree/nautilus/nautilus-fileroller.c they don't something similar to archive types
[11:31] <seb128> cjwatson, btw, did you see my ping about click packages/install size on friday evening?
[11:33] <cjwatson> seb128: I did but you'd logged off by the time I could respond
[11:34] <cjwatson> seb128: I don't think I agree that owned data should be the responsibility of click itself to figure out, because (longer-term) click wants to be independent of things like Ubuntu Touch and details of where an app stores its user data seem to be rather specific to the environment
[11:35] <cjwatson> seb128: So I agree we should only implement this once, but my instinct is to say that it should be one layer up from click
[11:35] <seb128> ok
[11:36] <seb128> so you would add a new service/library to do that? or do you see a place in our current stack where it would make sense to add the feature?
[11:36] <seb128> lool, ^ fyi
[11:38] <cjwatson> seb128: I'm not sure what the right location is.  Putting it in the Click PackageKit plugin would have the same convergence problem
[11:43] <seb128> cjwatson, ok ... do you think that's something worth discussing on a mailing list (which one)?
[11:55] <cjwatson> seb128: ubuntu-appstore-devel I suppose
[11:56] <seb128> cjwatson, ok, I will do that, thanks
[14:01] <cr3> how can I do something like a mount of an image when building a package? the build process seems to be done in a fakeroot, so I can't just use mount nor can I use sudo
[14:06] <brendand> cr3, baguette
[14:08] <ogra_> cr3, fakechroot ... but not sure that will allow mounts ... have a look at the ubuntu-touch-generic-initrd package i'm using fakechroot in there to gain (virtual) root access
[14:17] <stokachu> doko: could i bother you to take a look at a couple of bugs?
[14:18] <doko> stokachu, I'll try
[14:18] <stokachu> doko: bug 1121874 and bug 1207123
[14:18] <stokachu> was hoping to get these uploaded to start the sru process
[14:19] <doko> didrocks, seb128, RAOF: please would disable MIR related things for arm64 too? The ones you do disable for powerpc
[14:19] <didrocks> doko: I saw your upload, will do in the following upload when we have something to push
[14:19] <didrocks> (we'll be needed anyway for -ati and -nouveau)
[14:19] <doko> ok, thanks
[14:20] <jono> who is taking care of audio?
[14:20] <jono> Skype audio no longer worksin Saucy
[14:20] <seb128> doko, thanks for commiting the gtk changes to the vcs ;-)
[14:20] <seb128> jono, diwic and TheMuso
[14:20] <jono> thanks se
[14:20] <jono> seb128,
[14:20] <jono> diwic, TheMuso are you aware of this issue?
[14:21] <seb128> jono, btw, is there still a vUDS planned for this month (or next one)?
[14:21] <jono> seb128, yep, end of month
[14:21] <seb128> jono, I still didn't see an announce for it (hint: list user here)
[14:22] <jono> email about schedulinggoing out this week
[14:22] <seb128> jono, would be nice to announce it...
[14:22] <jono> seb128, will go out this week
[14:22] <seb128> thanks
[14:22] <jono> np
[14:28] <broder> cjwatson: sorry for not getting this up sooner - the shell i was setting things up in died - but first lintian run for saucy is up (http://lintian.ubuntuwire.org/saucy/), and the cronjobs should have it caught up the rest of the way soon
[14:28] <cjwatson> Lovely, thanks
[14:30] <jono> diwic, TheMuso see https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1208485 for the Skype audio bug report
[14:32] <diwic> jono, are you using skype from the partner repository ?
[14:32] <diwic> jono, there is a workaround since ~ a week back or so
[14:33] <diwic> jono, at least for one bug, not exactly sure if this is the same.
[14:33] <diwic> jono, also have you confirmed with others if this is a generic problem or hardware specific?
[14:37] <jono> diwic, I am using Skype from skype.com
[14:37] <jono> I haven't confirmed with others
[14:37] <jono> diwic, what is the workaround?
[14:38] <diwic> jono, start skype from the terminal like this: "PULSE_LATENCY_MSEC=50 skype"
[14:40] <diwic> jono, start skype from the terminal like this: "PULSE_LATENCY_MSEC=50 skype"
[14:40] <jono> diwic, didnt work
[14:40] <jono> removing this version of skype and installing the partner one
[14:56] <diwic> jono, so I tested here. Skype works fine here, the second time. echo123 hang up on me the first time, but I doubt that was PulseAudio related.
[15:45] <cr3> ogra_: sorry for the lag, I ended up build-depending on p7zip-full to extract what I need from an ISO with the 7z command.
[15:46] <ogra_> ah, cool solution
[15:46] <jodh> jibel, pitti, slangasek: FYI, having issues using nested kvm on openstack: 200% cpu usage with occasional dashes of kernel panics (bug 1208455).
[15:46] <slangasek> hmm
[17:50] <doko> seb128, which one was the package we had issues with one gcc-linaro merge?
[17:50] <seb128> doko, gtk+3.0
[17:50] <seb128> doko, https://bugs.launchpad.net/ubuntu/+source/gcc-4.8/+bug/1194123
[17:52] <doko> seb128, could you recheck this with the gcc-4.8 from the ubuntu-toolchain-r/test ppa?
[19:02] <dkessel> hello, i have sent a mail to the ubuntu-devel-discuss ML three days ago. I only got an automatic response that my mail is pending approval by a moderator. what can i do?
[19:02] <dkessel> should i just ask/present the problem here or should i wait?
[19:04] <rbasak> dkessel: I don't think ubuntu-devel-discuss is moderated for subscribers. Are you sure it's ubuntu-devel-discuss (and not ubuntu-devel) that you sent the message to, and that you sent the email from your subscription address?
[19:05] <dkessel> rbasak, hm. the response did not state that i have to subscribe...
[19:05] <dkessel> i have not subscribed
[19:06] <rbasak> dkessel: it's pretty common to require subscription to avoid moderation. Most mailing lists do it to avoid spam.
[19:06] <rbasak> dkessel: easiest way to get it through is to subscribe, then send from your subscription address. You can even disable delivery once subscribed if you don't want to actually "subscribe".
[19:07] <dkessel> rbasak. ok, thank you.
[19:07] <rbasak> dkessel: I suggest that you subscribe, cancel the original message (a link to do that is in the "awaiting moderation" email, and then re-send. That way you don't need to wait on a moderator (I'm not sure who that is).
[19:07] <rbasak> None of this applies to the ubuntu-devel list, which is moderated for non-Ubuntu-developers.
[19:08] <rbasak> )
[19:08] <dkessel> rbasak, i am afraid i have already deleted the automated response...
[19:10] <dkessel> ok, mail is out
[21:32] <darkxst> is there some way I can generate apt source lines from LP-PPA-* tags (LP-PPA-gnome3-team-gnome3)
[21:32] <darkxst> Software properties api wants ppa:x/y style input
[21:42] <darkxst> cjwatson, ^


[22:35] <ae0000> hello.. i'm pretty interested in making a couple of small apps for ubuntu phone and trying to decide what to put my energy into learning. For phone dev, is their much difference between using python versus c++ via qt5 etc.?
[22:39] <ae0000> are the bindings between qml and python very good? I'd prefer to use python
[22:39] <GuidoPallemans> only javascript and c++ are supported for now
[22:40] <GuidoPallemans> python is not
[22:40] <ae0000> ah ok
[22:41] <ae0000> are there performance issues using js instead of c++?
[22:41] <JanC> QML uses EcmaScript/JavaScript AFAIK
[22:42] <JanC> I guess the C++ is more for the backend stuff then?
[22:42]  * JanC might be totally wrong  ;)
[22:44] <GuidoPallemans> not purely, but it is encouraged to use javascript
[22:44] <GuidoPallemans> integrates much better too
[22:45] <ae0000> i haven't used qt or anything before.. but is qml a markup for qt... which is a UI framework for C++ apps. and you can use js in qml for logic stuff... ubuntu has its own set of components you can plugin to qt/qml.. is this about the size of it?
[22:45] <ae0000> trying to get my head around phone dev
[22:46] <JanC> GuidoPallemans: you are also from Belgium, right?   ☺
[22:47] <GuidoPallemans> yup
[22:47] <JanC> there is also #ubuntu-be & our mailing list etc.   ;-)
[22:47] <GuidoPallemans> oh nice
[22:48] <GuidoPallemans> where do i subscribe to the mailing list?
[22:48] <JanC> https://lists.ubuntu.com/mailman/listinfo/ubuntu-be
[22:48] <GuidoPallemans> thanks!
[22:49] <JanC> it's not always very active, but still should give you some idea about what activities we are planning
[22:49] <JanC> (for support we use -nl/-fr/-de channels & lists & forums)


[00:01] <doug__> \And I do have a small problem, which I've solved before but doesn't come to mind at the moment, which is how to remove the black borders from all around my monitor when running Linux.  :(
[00:01] <ouroumov> doug__, When you start your computer, after a random delay the software update will run a scan of the Ubuntu update servers and automatically prompt you when you need to install stuff
[00:02] <doug__> Oh, that is a nice feature.  OK, thanks for that!
[00:02] <ouroumov> If you're worried you're not up-to-date, you can also manually trigger the check for updates
[00:03] <ouroumov> About your monitor, maybe check in System -> Preferences -> Hardware -> Displays
[00:03] <ouroumov> If you can't solve it from that GUI configuration tool you'll want to look at the manual for the xrandr command.
[00:04] <doug__> Well, I'm a pretty interested person in making sure my stuff is up to date (some people are cat people - so maybe it's ok that I'm a "make sure my compute device is up-to-date) kind of person
[00:05] <doug__> ok! Looking, thanks - nice to be supported in the first 120 seconds I build a lynux device - kind of amazing actually
[00:06] <doug__> linux sorry
[00:06] <enyc> doug__: hahahaha I like tho "some people are cat people"
[00:06] <enyc> doug__: you remind me of the start of this article:
[00:06] <enyc> doug__: http://coding2learn.org/blog/2013/07/29/kids-cant-use-computers/
[00:08] <ouroumov> oh, that was a very good article
[00:09] <doug__> hmm
[00:09] <ouroumov> doug__, you were lucky to get support in under 120 secs, it's not like we watch this window all the time. :)
[00:09] <doug__> not seeing anything about the borders but am thoroughly impressed by this experience
[00:10] <enyc> doug__: look above again
[00:10] <ouroumov> doug__, that said, you were still there after 120 seconds, which increased your chances by quite a lot. A lot of people don't have even that much patience. x)
[00:10] <doug__> I heard about a Rasperry PI and got a couple on Amazon, heard the support community was pretty amazing and am floored - really
[00:11] <ouroumov> It's time for me to eat.
[00:12] <ouroumov> The massive plate of spaghetti awaits!
[00:12] <doug__> I bought a credit card and put it into a cheap case, hooked up left over USB keyboard and mouse and in about 30 minutes I'm talking with people willing to help me literally from the first screen that pops up in (Ubuntu? not sure what I have running .... ugh)
[00:13] <doug__> *credit card sized computer
[00:13] <doug__> ok bye for now, thanks!
[00:13] <enyc> doug__: dos't be surprised to get a hard to solve problem either...  learning to  ask very clearly helpful well worded questions  and post them on mailing lists or forums too  is helpgful...
[00:13] <ouroumov> If you're in this channel you're most likely running Ubuntu MATE versions 15.10 or 16.04 for rpi.
[00:13] <enyc> doug__: don't get "stuck" / annoyed on a single thing impotientyl
[00:13] <doug__> hmm
[00:14] <doug__> ok! thanks again - took me about an hour to get the pi working and now my wife wants my attention too
[00:14] <doug__> so, must multithread
[00:14] <doug__> will be back thanks guys and girls :)
[00:15] <ouroumov> Damn
[00:16] <ouroumov> If he hadn't .join()'ed already I'd have told him the technical term best suited to describe his situation was that he'd just received an interrupt.
[00:19] <joshua__> asdas
[00:19] <joshua__> Hello
[02:15] <eric_> Anyone have a notion why my Pi 3 would tell me my wifi device is not ready when it was working great when I first installed ubuntu mate?
[02:17] <lost_thought> I need some help with ubuntu. Im visiting my folks and my mom wants to get off of windows so i tried installing ubuntu 16.04 and mate on her pc. I have never seen this kind of problem before and don't know where to start. Sometimes the mouse and keyboard and working on the windows in the background. Ok lets say i open firefox. Every thing works. Now with firefox open I also open thunderbird. Ok so thunderbird is on top. But
[02:17] <lost_thought> my mouse and keyboard are still clicking and typing to firefox. After some time of this i loose the ability to click anything. F12 still works for the drop down term which is the only way i can reboot. Does anyone have any idea why this is happening??
[02:26] <pavlushka> lost_thought: may be your keyboard buttons are faulty, that's just a guess, but need to know the pc- configuration, that might help.
[02:31] <lost_thought> every thing works under windows 7. intell 2500k. nvidia 560 ti/ 8 gig ddr3. 256gig ssd. um what els.  i just downloaded the ubuntu mate and normal ubuntu iso and burnded it to a cd. what els can i tell you about the pc. both usb mice and keyboard work under windows and manjaro. but manjaro is to buggy for her
[02:33] <lost_thought> i have not tryed 14.04 yet
[02:35] <lost_thought> basic ubuntu install. erase the the hole disk. format with ext4. i have notest that this problem will show up if i go strait to install ubuntu. i have to click try ubuntu then install from there. if i dont the the mouse stops working on the screen that shows what changes will be made to the disj
[02:36] <lost_thought> disk*
[02:36] <cjbayliss> lost_thought: could to run this and give this link it provides?
[02:36] <cjbayliss> lspci | curl -F 'sprunge=<-' http://sprunge.us
[02:38] <lost_thought> yes but it will have to wait till tomorrow. i had to clown windows back over to it so she could use it for now. i guess i was just hopping for some one to say "yeah i had that problem. this is how to get around it" but tomorrw when she gos to work ill run it. i know what lspci is but what is sprunge=<
[02:39] <cjbayliss> lost_thought: basically that posts the output of lspci to http://sprunge.us/
[02:40] <cjbayliss> (my prefered pastbin, because it is plain text)
[02:40] <lost_thought> oooh i see
[02:40] <cjbayliss> e.g: http://sprunge.us/VacP
[02:40] <lost_thought> thats handy
[02:44] <pavlushka> lost_thought: if a working system is a preference over latest release and not for you but for you mom, you should use a more stable release like 14.04.4's, and you can always upgrade to 16.04.1 after the release of 16.04.1 around July, :0
[02:44] <pavlushka> :)
[02:54] <tianlei> hey,guys.Can anyone tell me how to config fcitx
[04:25] <draco_> I have ubuntu 15.10 installed on my machine and for a while I heard many good things about Ubuntu Mate. Is there an official way of installing whole mate desktop from ubuntu mate project on existing installation?if I will install ubuntu-mate-desktop, will that be vanilla mate or mate from ubuntu mate project?
[04:25] <draco_> I don't want to dualboot, I want to have option of choosing different DE on login screen
[04:37] <alkisg> draco_: yes, installing ubuntu-mate-desktop should be fine
[04:37] <alkisg> You can also use virtualbox if you want to test it
[04:38] <cjbayliss> (NOTE: I don't use Ubuntu) One way would be to install tasksel, run 'sudo tasksel' and choose the ubuntu mate option
[04:46] <Guest99618> Hi,. new guy here, just installed ~~
[04:48] <Guest99618> got an old pavillion dv7 - 17" - with an intel core I3 with 6 gig ram,.. i just put in a 250 gig, samsung evo 850 SSD  .. wow !!!
[04:49] <Guest99618> in 23 seconds from power up. i am on web
[06:46] <david_> Hey Linux Community, im new to Linuy and installed it yesterday on my dell xps 13. So far I got 2 issues. 1. My display flickers or blacks out for a sec and 2 I want to implement the vertical down scroll with 2 fingers.
[07:42] <tiox> Who else uses xpad?
[08:40] <danboid> What's Wimpy's IRC nick?
[08:40] <danboid> gordonjcp: Hi!
[08:41] <gordonjcp> danboid: hello
[08:41] <danboid> gordonjcp: How to spot a Wimpy man here?
[08:42] <danboid> He's been a naughty boy! :)
[08:44] <danboid> I may just have to lurk a while longer eh?
[08:49] <alkisg> danboid, what's the issue?
[08:50] <tiox> danboid: wimpy
[08:50] <tiox> He's online atm
[08:50] <danboid> Its a bit OT for this channnel really - I'm wondering when he'll be updating the Arch MATE packages to 1.14? I understand he's been busy with 16.04 recently
[08:51] <tiox> Just sayin' danboid, we call him wimpy because he's wimpy. (Real name is Martin Wimpress.)
[08:52] <danboid> Just wondering if there has been another hold up apart from the usual annoying obvious life and time things
[08:52] <danboid> tiox: Well aware :)
[08:52] <alkisg> Sure, 16.04 support, raspberry pi development, he has a lot in his hands
[08:52] <danboid> I'm suffering Arch version cold turkey now :)
[08:53] <danboid> We're supposed to be bleeding edge over here! :)
[08:53] <tiox> I am truly thankful for the MATE team's efforts. I almost, ALMOST have my Ubuntu 10.10 desktop back thanks to Ubuntu MATE, save for some GTK3 enhancements.
[08:53] <tiox> If only Avant Window Navigator wasn't a casualty in Canonical's plans to dominate all other docks with Unity.
[08:55] <tiox> It might seem dumb to some people, but I had a dock setup that was AWN, with DockbarX inside of AWN thanks to a special package that added a DockX wrapper so it functioned within AWN.
[09:19] <andrews> Hi
[09:19] <andrews> Have few questions
[09:19] <andrews> i am a new user of Ubuntu
[09:20] <andrews> was a windows user for many years,now is a little bit different to tweak this new system
[09:21] <andrews> is easy or hard to set up the encryption of the disk at the beginning when you are installing the system ???
[09:21] <andrews> i didntdo it cause i was worried if it takes too much time
[09:27] <andrews> any suggestions ?
[10:08] <superkuh> Like tiox said, yeah, Ubuntu MATE is great. I'm getting ready to switch over from my 10.04 partition to a new Ubuntu MATE 16.04 install. I've spent the last week or so setting up a test in a VM and it is almost perfectly matching my 10.04 install.
[10:09] <superkuh> Much smoother than my experience with MATE desktop on 12 or Ubuntu MATE on 14.04.
[11:08] <danboid> Wiiiiiiiiiiimpy!?!?
[11:09] <danboid> Am I looking out for a sensible/obvious nick then like mwimp?
[11:18] <alkisg> Nope :)
[12:01] <TwoNotes> Should Ubuntu-MATE boot on an RPi3 with no display connected?  Mine seems to boot only with a display.
[12:04] <gordonjcp> TwoNotes: HDMI?
[12:04] <ouroumov> TwoNotes, it should
[12:04] <gordonjcp> TwoNotes: wonder if it's possible to watch the composite output for clues?
[12:05] <TwoNotes> I would need some sort of special connector for that I think
[12:05] <TwoNotes> The symptom waas that the WiFi never started.  I gave it plenty of time
[12:07] <TwoNotes> And without logging in, pulseaudio never started, so that is another problem.  This is to be a headless music player.
[12:09] <gordonjcp> maybe installing ubuntu server would be a better fit?
[12:10] <gordonjcp> if I was going to make an intentionally headless machine, I wouldn't start with a desktop OS
[12:12] <TwoNotes> I was going to use Ubuntu Server, butwhich of the downloads listed at http://www.ubuntu.com/download/server/arm is for Rpi3, which I think has a Broadcom chip?
[12:39] <TwoNotes> I was hoping that, after I got it properly configured, there was a way to lobotomize U-M to be a server
[13:36] <tiox> Forum is broken.
[13:53] <Paddy_NI> For some strange reason I cannot access or ping my router on my ThinkPad
[13:53] <Paddy_NI> Running Ubuntu MATE 16.04
[13:56] <Paddy_NI> No proxies or strange firewall rules
[13:56] <Paddy_NI> Very confused
[14:10] <sindre> Howdy good morning/evening
[14:36] <mate|nik> hi
[14:36] <mate|nik> in ubuntu mate for rpi3 is it possible to run all that can be done on ubuntu pc desktop?
[14:37] <gordonjcp> mate|nik: pretty much
[14:38] <gordonjcp> there's a lot of binary-only stuff that won't work on ARM
[14:39] <mate|nik> and that one can be compiled in some way for arm?
[14:49] <pjpmate> community site is unavailable from US
[14:54] <gordonjcp> mate|nik: probably not; if it's binary-only the chances are the sources are unavailable
[14:58] <mate|nik> :( ok! because i want to install this: http://cartodb.readthedocs.io/en/latest/install.html
[14:59] <mate|nik> do you think that is possible?
[15:08] <gordonjcp> mate|nik: good question; probably
[15:08] <gordonjcp> mate|nik: from experience, OSM tile rendering requires an unholy amount of memory
[15:17] <mate|nik> yes but only for tests do you think that will work? i don't want to use it as server
[15:18] <mate|nik> i tryed to install on raspbian and i was not able to install it
[15:18] <gordonjcp> mate|nik: you really want a fairly meaty machine
[15:21] <pjpmate> mate community is read mode now
[16:40] <r10t> kudos to the community behind ubuntu mate, after trying all of the "mainstream" versions and running into bugs, 16.04 of _this_ release works perfectly...even on my terrible hp laptop :)
[16:41] <Talikka> I noticed Ubuntu Mate is much better translated into Finnish than into Arabic.
[16:43] <Talikka> In my installation the top panel disappeared and I had to create a new user account. I don't know how the panel can be made working again.
[16:44] <Talikka> There was a crash and an error message of mate-panel but it did not succeed in reporting i guess since I couldn't connect to wifi with the panel away.
[17:47] <supusr> I have the intel ¡915 integrated graphics driver for the Intel Core i5-2310 CPU @ 3.2GHz cpu.  Currently I'm using 14.04 and the 4.2.0-36-generic kernel, which appears to be the last kernel to support my graphics.  I cannot get Ubuntu unity or any of the other flavors to work with it in 16.04.  Any suggestions?
[17:54] <ouroumov__> hi supusr
[17:55] <ouroumov__> How far did you get with Ubuntu MATE?
[17:55] <Akuli> supusr, but everything worked in 14.04 with a 4.x kernel?
[18:07] <supusr> So, with MATE, my preference, the beta and alpha versions would install, but with almost unreadable blurry displays (my default is 19820x1080).  I figured the bugs would be ironed out by 16.04, so never complained or installed.  With the release of the LTS final version of 16.04, I had the same problem.  The <IP_ADDRESS> kernel works, which is why I'm
[18:07] <supusr> now on 14.04, but the new one does not.
[18:08] <supusr> I meant 1920x1080, clearly.
[18:09] <supusr> I want to use 16.04 MATE or Xubuntu, but cannot.
[18:16] <Akuli> I'd suggest sticking with 14.04
[18:17] <Akuli> it'll be supported until 2019, so many good years of lts to come :)
[18:17] <supusr> Yes, that will work for now, but I have older versions of the programs.  Any chance point updates will update the kernel?
[18:17] <Akuli> do you want or don't want to update the kernel?
[18:18] <Akuli> you can apt-mark hold linux* to hold all linux kernel things, i do that on my computers but #ubuntu people think it's a bit of a security issue :)
[18:18] <supusr> I am an intermediate user - if I could learn to do it in order to use my current system with 16.04, I would want to.  My only other solutions would be to stay with 14.04 or get a newer machine.
[18:19] <Akuli> You can install 16.04's kernel in 14.04
[18:19] <Akuli> sudo apt-get install linux-generic-lts-xenial
[18:20] <supusr> But, if the kernel is the problem, won't that bring the problem with 16.04 into my 14.04 setup?  Wouldn't the better idea be to somehow use the older kernel with 16.04?
[18:22] <ouroumov__> Yes it would
[18:22] <supusr> Is that a possibility?
[18:22] <ouroumov__> What is the kernel in 14.04 by now? 3.14 - something?
[18:22] <supusr> <IP_ADDRESS>
[18:23] <supusr> I think later ones bring the problem with my express chipset.
[18:23] <ouroumov__> That doesn't sound righ
[18:23] <ouroumov__> right
[18:23] <supusr> Just did a screenfetch.
[18:23] <ouroumov__> supusr, did you manually install a higher kernel?
[18:24] <supusr> supusr@cm6850-5:~$ screenfetch
[18:24] <supusr>                           ./+o+-       supusr@cm6850-5
[18:24] <supusr>                   yyyyy- -yyyyyy+      OS: Ubuntu 14.04 trusty
[18:24] <supusr>                ://+//////-yyyyyyo      Kernel: x86_64 Linux 4.2.0-36-generic
[18:24] <supusr>            .++ .:/++++++/-.+sss/`      Uptime: 1d 20h 2m
[18:24] <supusr>          .:++o:  /++++++++/:--:/-      Packages: 1909
[18:24] <supusr>         o:+o+:++.`..```.-/oo+++++/     Shell: bash 4.3.11
[18:24] <supusr>        .:+o:+o/.          `+sssoo+/    Resolution: 1920x1080
[18:24] <supusr>   .++/+:+oo+o:`             /sssooo.   DE: Unity 7.2.6
[18:24] <supusr>  /+++//+:`oo+o               /::--:.   WM: Compiz
[18:24] <supusr>  \+/+o+++`o++o               ++////.   WM Theme: Ambiance
[18:24] <supusr>   .++.o+++oo+:`             /dddhhh.   GTK Theme: Ambiance [GTK2/3]
[18:24] <supusr>        .+.o+oo:.          `oddhhhh+    Icon Theme: ubuntu-mono-dark
[18:24] <supusr>         \+.++o+o``-````.:ohdhhhhh+     Font: Ubuntu 11
[18:26] <ouroumov__> Thanks for the flood
[18:26] <ouroumov__> Well anyway
[18:27] <ouroumov__> You can grab any kernel you want and run it on 16.04
[18:27] <ouroumov__> I don't think it'll break a lot of the OS stack
[18:28] <supusr> OK.  I know the commands to get them, but now how to keep them without getting updated kernels.,,
[18:28] <supusr> but not how...
[18:29] <ouroumov__> I think the one time I did that was using synaptic
[18:29] <ouroumov__> Yes
[18:30] <supusr> So, if I understand the experiment you propose, which I am not opposed to trying, I would first install the (blurry) 16.04, then install synaptic, then get the older kernel in place and indicate I would like to keep it.  Sound right?
[18:30] <ouroumov__> You pick the kernel you want, then go to Package and check lock version
[18:31] <ouroumov__> supusr, indeed
[18:31] <ouroumov__> I'm curious to know if it'll work or not.
[18:32] <supusr> OK.  Provided I can see the screen  well enough to do it all, it might work.  I will try it later today.  How can I let you know the result?
[18:32] <ouroumov__> If it doesn't change anything it might be that it's the fault of i915 and not of the kernel
[18:33] <supusr> Yes.  It's worth it to try to find that out.
[18:33] <ouroumov__> supusr, you can just come back here and tell us
[18:34] <supusr> OK.  Iĺl need to wait a bit until I know I have a few hours on the machine, but I'll give it a whir.
[18:34] <supusr> whilr.
[18:34] <supusr> whirl.
[20:21] <danboid> No Wimpy?
[20:28] <pavlos> community website gives me, 400 Bad Request
[20:30] <ouroumov__> hi pavlos
[20:30] <ouroumov__> There is currently restructuring work in progress on the forum
[20:30] <pavlos> hi ouroumov__
[20:30] <pavlos> ok np
[20:31] <ouroumov__> pavlos, availability comes and goes
[20:31] <pavlos> I'll wait
[22:33] <Nosophorus> hello, guys
[23:05] <supusr> Ubun+uM@+e
[23:20] <supusr> I was asked to send this info for those who were helping me this morning: For those using the Intel ¡915 integrated graphics driver not supported by the newer linux kernels in 16.14, this is the fix:  install the older kernel that works (linux-image-4.2.0-040200-generic_4.2.0-040200.201510260713_amd64.deb) (and headers), then mark it as locked in s
[23:20] <supusr> ynaptic, then reboot, and it works.  One can now get native resolution 1920x1080 working and thereby use 16.04.
[23:58] <HetroErectus> BUG ALERT! my mate taskbar applets (volume control primarily) stops working ... and there are several steam games that wont start.. such as dota 2