=== YDdraigGoch is now known as Richie === Amaranth_ is now known as Amaranth [08:03] Good morning [08:08] * bryce waves to pitti [08:08] hey bryce [08:09] bryce: so you think hal-less X.org would actually be feasible for lucid? from the ML and mjg59's comments it seemed that it would be too hard [08:09] pitti, I don't really think it is feasible without incurring a considerable number of regressions [08:10] pitti, however keybuk felt it had to be done regardless [08:11] pitti, so I'm unclear as to what to do and could use your direction on this one [08:12] bryce: for normal mice/keyboards it shouldn't actually be hard; I'm mostly concerned about those wacom things [08:12] TBH I have no idea how those work [08:12] for normal mice/keyboards, I'm happy to build a test X.org server in a PPA with the patch, and with the Ubuntu specific bits to set the keyboard layout [08:14] mostly I'm concerned with the manpower that'll be required to chase down and fix regressions this change may cause [08:15] bryce: do you know of other "weird" input devices that we need to be concerned about? [08:15] touch screens seem to be represented as normal mice [08:16] I have a Joystick, we can test those as well [08:16] yeah [08:16] anything where we have some fdi files, I guess those will need changed into udev rules [08:16] but the basic task is actually quite simple: get the input device list from the kernel (lsinput-like), augment it with some properties like keyboard layout, and poke it into X [08:17] right now, it's udev -> hal -> X.org, and we'd just skip the middle man [08:17] for wacom, I've contacted the wacom driver developer about it [08:17] keyboard layouts are well understood, they just need to be grabbed from /etc/default/console-setup for us [08:18] one problem I know of are options for the synaptics driver [08:18] we'll need xserver 1.7 but once we're on that, there is a fixed -wacom available we can use [08:18] oooh [08:18] well, 1.7 is the plan anyway, right? [08:18] bryce: so, I don't see a principal reason why the synaptics options couldn't become udev properties instead of hal properties [08:18] right (and not coincidentally) [08:18] it might not be the cleanest solution, but it will work [08:19] in the long run, those options should maybe get back into xorg.conf [08:19] noooo [08:19] or an xorg.conf.d/50-synaptics or so [08:20] but anyway, converting that synaptics fdi file into an udev rules file to slam the parameters to the touchpad input device seems entirely feasible [08:20] hey bryce and pitti [08:20] bonjour didrocks! comment vas-tu? [08:20] heya didrocks [08:21] bryce: I reopened the BP for now [08:21] pitti: sehr gut, und du? :) [08:21] (not sure of my german though) [08:22] didrocks: tres bien, merci! [08:22] :) [08:22] didrocks: your German is perfect :) [08:23] pitti: ahah, if I only use few words... ;) [08:26] bryce: want me to write some udev rules to produce sth. like on http://thread.gmane.org/gmane.comp.freedesktop.xorg.devel/2108 ? [08:26] pitti, sounds good [08:27] bryce: so, I think if we are going to do this, we should do it soon, to see where the regressions are [08:27] so how about: [08:27] 1. apply the patch soon (by alpha-1), pitti to create udev rules for keyboard layout, etc. [08:28] morning everyone [08:28] 2. update to new wacom driver and test it (who could do this?) [08:28] when's alpha-1? [08:28] 3. at alpha-3, make the call to revert (because of regressions), or keep [08:28] ? [08:28] bryce: hm, december 10th [08:28] perhaps alpha-2 then [08:29] ok that sounds more doable [08:29] bryce: I don't think that the original patch requires 1.7 (just the new wacom does) [08:29] but ICBW, I didn't try to apply it yet [08:29] #2 has as pre-requisite merging in xserver 1.7 (and all of its protos and libs that it depends on) [08:30] true the udev patch may work against what we have now for xserver [08:30] in which case I can probably slap it in tomorrow [08:33] bryce: does Alberto or you have a wacom device for testing? [08:33] or Timo? [08:34] I sent Alberto a tablet, and I've got one myself [08:34] I think Timo has one but am not certain [08:35] I have a waltop, not proper wacom [08:35] and it doesn't work with the driver in karmic [08:35] don't know if it ever will [08:36] bryce: options in xorg.conf> http://thread.gmane.org/gmane.comp.freedesktop.xorg.devel/2108 [08:36] pitti, oh -evtouch supported devices probably will also break when we move away from hal [08:36] the brand name is aiptek media tablet 10000U [08:39] bryce: oh, do we use that? at least the "fake" touchscreen in kvm is just a normal evdev mouse; we could ask ogra to check on his real touchscreen [08:39] it's in universe, hmm [08:41] pitti, yeah all the touchscreen stuff is in a really sorry state [08:41] jcristau (the author of the udev patch) said that the only missing bit is recognizing a synaptics device [08:41] the hal changes will just make it sorrier [08:42] because now it's done by matching input.touchpad, but udev doesn't have that AIUI [08:42] tjaalton, ogra told us in the touchscreen session that he'd fixed up -evtouch to work with hal, and added some fdi's for it [08:42] bryce: I meant synaptics [08:42] oh gotcha [08:42] tjaalton: well, hal has to figure it out somehow, too (IIRC it looks at the types of events it can produce and sets this capability) [08:43] tjaalton: no reason that this bit cannot become an udev callout to set the property, if we need it [08:43] pitti: right [08:43] but not there yet ;) [08:43] I can write that bit [08:44] I guess that's why it's not merged upstream yet [08:44] I'd probably just stick it into udev proper, into some extras/ [08:44] once it works [08:47] what ML did you refer to where it was said to be hard to drop hal? [08:48] * pitti tries to remember [08:48] tjaalton: I think it was from mjg59, probably somewhere on devkit-devel@ [08:48] pitti: thanks, I'll check that out [08:48] at that time I thought we didn't want to backport that stuff, and that wacom would be too big of a problem for lucid [08:49] tjaalton: he basically said that "xorg is not ready for this yet, so we'll have to keep hal for the next cycle" [08:49] wacom does it's own hotplugging now, and set's up the device according to what the kernel says it has [08:50] yay [08:51] tjaalton, had a chance to look at what we need to do for getting xserver 1.7 in lucid? [08:51] bryce: only ~6 libs to go, then updating xorg & xorg-server [08:52] sweet [08:52] there are more libs to upload to unstable when jcristau has time (maybe tomorrow), then the rest of the proto's can go too [08:52] uploading them now would make the xserver unbuildable [08:52] so they need to go in at the same time [08:53] * bryce nods [08:54] bryce: do you know if there's a newer patch than the original one proposed by Julien in http://thread.gmane.org/gmane.comp.freedesktop.xorg.devel/2108 ? [08:55] hmm, not spotting it [08:55] bryce: it's not in that thread, but there were some discussions how to improve it [08:56] yeah [08:56] seems not to be in git yet [08:56] at least, not in master [08:57] bingo http://cgit.freedesktop.org/~jcristau/xserver/ [08:57] rocking [08:57] pitti, ^ newer stuff there [08:59] bryce: I'm working on creating udev rules now (a default "evdev for everything" corresponding to 10-x11-input.fdi, and one for "synaptics" corresponding to 11-x11-synaptics.fdi) [08:59] ok [08:59] Hello, when I attempt to install gnome-shell (in karmic), I found that it wants to pull several -dev packages, is that a bug ? [09:03] AnAnt: the Ubuntu version is old , its better you use the upstream version [09:04] mac_v: is there a PPA ? [09:06] AnAnt: hmm , there is a ppa mentioned in this thread > http://ubuntuforums.org/showthread.php?t=1305154 , but its pretty easy to build from upstream version itsefl [09:06] itself* [09:07] AnAnt: its just like 4 commands to install from upstream and you get the shell ;) [09:07] mac_v: ok, but why does the deb package depend on -dev packages ? [09:07] depend or recommend [09:08] AnAnt: hmm odd, it doesnt show the -dev packages as depends for me [09:09] attempting to install gnome-shell says that it will install a number of -dev packages [09:19] pitti: please keep me informed about your progress with the udev rules for synaptics as a patch of mine in synaptics makes use of 11-x11-synaptics.fdi for setting quirks [09:19] tseliot: I was going to transform the existing quirks to udev rules, too [09:21] pitti: great, I would like to see the that file when it's ready [09:22] * tseliot is glad that we won't have to deal with corrupted fdi cache any more :-) [09:34] mpt: hi.. is there a blueprint for the -symbolic icons? [09:36] mac_v, not as far as I know. If you like, you could register one with me as drafter, kwwii as assignee, and ivanka as approver [09:37] * mac_v scratches head... needs to figure out how to draft a blueprint ;p [09:41] mpt: its a blueprint in xdg naming specs or...? [09:42] good morning there [09:42] hey seb128 [09:42] pitti: my girlfriend has a wacom tablet, so she can test it too if you ping me. [09:42] hey seb128 [09:42] hey pitti didrocks [09:42] mpt: yay... no work for me ... there is already one , >https://blueprints.launchpad.net/icon-naming-spec/+spec/extra-icon-namespace [09:42] * seb128 overslept [09:43] seb128: jet lag FTW? [09:43] sort of, I had no issue going to sleep [09:43] but I wanted to finish syncs and it took me ages [09:44] so I went to bed quite late and sleep through ;-) [09:44] mac_v, cool, thanks [09:45] seb128: take care of having some good rest before the week-end this week :) [09:45] lol [09:47] good morning glatzor [09:49] morning mpt! [09:49] hi everybody! [09:49] sorry for saying good bye to you personally, but I haven't seen you on friday [09:49] I keep receiving this message during boot up: One or more of the mounts listed in /etc/fstab cannot yet be mounted: [09:50] on did not find a good solution on ubuntu forums [09:53] hey glatzor [09:55] morning mvo [09:56] mvo, the sessioninstaller is nearly complete. I am currently adding the ability to install PackageKit catalogs [09:56] glatzor: woah, sweet [09:56] * mvo hugs glatzor [09:57] glatzor: just give me a shout when its ready and I will package/upload [09:57] mvo, it isn't any rocket science. just providing simple dialogs and some basic python-apt stuff :) [09:57] glatzor: its still sweet :) [09:58] and useful, great to have [09:59] * glatzor is away peeling potatoes [10:21] bryce, tseliot: I think I figured it out; I'll mail you (and julien) [10:21] pitti: great, thanks [10:21] nice [10:21] I've got the touchscreen spec mostly drafted -- https://wiki.ubuntu.com/X/Blueprints/Touchscreen [10:22] tseliot, btw, I also drafted up the proprietary driver spec, but you may want to review that [10:22] bryce: sure, I was about to ask you about that one [10:24] tseliot, sure shoot [10:25] bryce: I wanted to know who would deal with that wiki page as per pitti's email. You've already given me an answer ;) [10:26] bryce: also, we're not going to use alternatives, are we? [10:27] tseliot, isn't that what was decided at UDS? Was there subsequent discussion to the contrary? [10:27] * tseliot would be happy with a clean up and with better documentation of the packages [10:28] bryce: from what I remember pitti said that weird things can happen with alternatives (not that diversions are any better) [10:28] so I took that as a no [10:28] maybe I misunderstood [10:29] tseliot, ahh, I think we addressed that concern - some of your comments resolved his worries [10:29] guess happy pitti smiles didn't transfer through the mike [10:30] bryce: ah, ok so my promise about the hooks for the nvidia-installer was convincing then :-) [10:30] yep [10:30] hehe [10:30] very well [10:30] we just make sure that the maintscripts apply enough force to not leave dangling alternatives behind [10:30] usually the user can override the system default [10:31] pitti: do you mean "override" with update-alternatives? [10:31] tseliot: I don't know alternatives handling very well; I try to stay away from it like the plague :) [10:31] as the nvidia-installer won't be capable of doing such things [10:32] pitti: diversions are not fun either, I assure you ;) [10:32] I'll do my best to come up with something sane this time [10:33] well, sane is a big word when dealing with this kind of packages... [10:33] tseliot: good luck! [10:34] thanks, I'll need it ;) [10:34] bryce: so if we really attack xorg halsectomy, I guess I should work on suspend quirks halsectomy, and dropping hal from the few remaining gnome bits :) [10:35] *nod* [10:35] bryce: the wiki pages look good to me [10:35] bryce: I mailed the udev rules and updated the whiteboard; do you see anything else which needs to be converted for a first test? [10:35] I will try to take a look at getting jcristau's xserver patches packaged tomorrow maybe [10:35] pitti: would suspend quirks work with udev? This is something I will need for OEM stuff too [10:36] tseliot: they wouldn't go into udev; Victor and I plan to put them into a text file straight into pm-utils [10:36] nothing else uses them [10:36] and udev is not appropriate for this kind of information [10:36] tseliot: Victor wrote a script to convert the fdi into a simple text format [10:37] pitti: and what is that loads the text file so that the system knows how to suspend? [10:37] tseliot: pm-suspend/pm-hibernate [10:37] yes, of course [10:37] * bryce rotfl's at GOTO's [10:37] so you don't need to worry about them at all any more [10:37] it will "just happen" [10:38] that's good [10:38] bryce: my initial rule was one big one, but I found that this doesn't work for some reason: [10:38] IMPORT{parent}="ABS", ENV{ABS}=="?*" [10:38] with two separate rules it works [10:38] iz udev bug [10:38] ok === asac_ is now known as asac [11:09] hey asac [11:09] asac: do you still remember your pm-utils patch "90-nm-proper-wakeup.patch" which adds a --print-reply? [11:09] pitti: yes [11:09] whats up? [11:10] asac: that's not in upstream yet; did that get forwarded upstream? or was it only a hack? [11:10] its definitly a workaround [11:10] not sure if it should go upstream [11:10] basically without --print-reply the process might exit too early and no message gets send out [11:11] afaik the --print-reply workaround was posted to the dbus mailing list [11:12] asac: would you mind posting it to https://bugs.freedesktop.org/enter_bug.cgi?product=pm-utils ? I'd like to commit it to Debian as well, etc. [11:13] but we shouldn't keep such hacks forever without at least having it forwarded [11:14] maybe its fixed by now [11:25] asac: oh, it's already in Debian, too, so I'll keep it for now; but the final fate of it would still be interesting [11:25] yes [11:25] as i said. it was a bug in dbus ... which is known upstream ;) [11:26] (to dbus upstream at least) === mpt_ is now known as mpt [12:05] hey slomo [12:05] hi seb128 :) [12:05] slomo, do you think you could make the vala build run the testsuite and break on error? [12:06] that's the only diff we have in ubuntu [12:06] we could sync if debian was doing that too ;-) [12:06] seb128: no, the testsuite fails if dbus can't be started... which is the case in some debian buildds :( [12:06] are you sure? [12:07] we didn't get any build issue during the karmic cycle [12:07] though soyuz != debian buildds [12:07] the ubuntu buildds are much more easy to handle than debian's :) [12:07] you even have writable home directories ;) [12:07] ok [12:07] shame [12:07] pitti, ^ any opinion? [12:08] having to merge this one every time is annoying [12:08] but making the build fail on testsuite errors was a mir requirement by security team [12:08] I guess I should talk to kees again about this one... [12:08] seb128: i could add something to debian/rules to only make the testsuite fatal on ubuntu [12:08] slomo, that would be nice of you ;-) [12:09] seb128: right, would be nice to have the test suite working [12:10] ubuntu buildds have problems with d-bus too, though [12:10] now i only need to wait until git.debian.org works again ;) [12:10] slomo: hm, I have pushed several bits in the last hour [12:10] pitti, do you know if we have a meeting today btw? [12:11] seb128: I guess we do [12:11] ok, thanks [12:11] 17:30 local right? [12:11] rightg [12:11] cool [12:13] pitti: works now :) [12:13] seb128: you can sync 0.7.8-2 from debian/unstable later [12:14] slomo, thanks! [12:14] btw, who's responsible for pulseaudio in ubuntu? :) [12:17] hello [12:18] slomo, TheMuso and dtchen [12:21] dtchen: are you going to enable flat volumes again for next release? [12:22] seb128: uploaded :) [12:23] seb128: btw, the dbus tests didn't work in my pbuilder chroot ;) [12:23] slomo, rock on, thanks again! [12:24] slomo, do you think flat volumes are a good idea? [12:24] we got many bugs from confused users while it was on [12:25] seb128: definitely a good idea, yes. and those bugs should all be fixed now, at least in every gnome/gstreamer application (it's a bit sad that nobody forwarded the gstreamer related bugs upstream though) [12:26] what does flat-volumes do? [12:26] pitti, I think it makes channels volume move in a sync way [12:26] ie when you change volume you change master and pcm together [12:27] pitti: http://0pointer.de/blog/projects/oh-nine-fifteen.html first part [12:32] slomo, well there is still some users or card having saturation issues [12:32] which is probably driver or hardware issue but when you force all channels to act in a sync way you remove the ability to workaround those easily [12:58] ok, I'm away for debugging my uncle computer [12:58] I'm not far so feel free to call if something is needed, otherwise I should be back in 1 or 2 hours... === MacSlow is now known as MacSlow|lunch [13:27] did anyone actually see "[pitti away: lunch]" and "[pitti back: gone 00:39:00]"? I hope these are just local messages from my IRC client (got a major update yesterday) and they don't get echoed to the channel [13:27] good afternoon everyone [13:29] hey chrisccoulson [13:29] hey pitti, how are you today? [13:29] I'm great, how about you? [13:30] yeah, i got quite a good night sleep last night, and enjoying my 2 weeks off work too :) [14:08] pitti: no, no sign [14:09] Laney: thanks === MacSlow|lunch is now known as MacSlow === robbiew_ is now known as robbiew [15:08] jcastro good morning [15:18] dtchen: can you hop into #ubuntu-meeting? [15:51] can anyone tell me in how many hours the desktop team meeting starts [16:02] tgpraveen221, it was canceled for today [16:04] re! [16:04] so karmic 0 - win xp 2, grrrrr [16:07] trying to install karmic on my uncle box is a fail [16:07] seb128: what kind of problem? [16:09] the first install ubiquity crashed [16:10] there was a ntfs partition change dunno if that was due to it [16:10] after running it again it was saying that no OS was installed [16:10] it scared me for a moment I though it destroyed the win install [16:10] oh :-( [16:10] after reboot install worked correctly [16:10] the first did the disk changes after all and working... [16:11] but after reboot no grub [16:11] oh, weird [16:11] so there is a karmic installed and no way to boot it now [16:11] I decided I spent enough time on that today [16:11] will go back an another day [16:11] ok [16:11] did it have no grub but booted properly back into xp immediately? [16:11] yes [16:12] ok [16:12] known issue? [16:12] i don't know, sounds like it either didn't install or somehow installed to the linux partition instead of the mbr (if that is possible) [16:12] there is 2 disks in the box [16:13] karmic was installed on the second one [16:13] oh ok, or a 3rd option it installed to the mbr of the second disk [16:14] i haven't ever tried installing to a second hard drive before, so not sure what it tries to do in that case [16:16] I think I did once [16:17] and back then there was some confusion about which MBR it installs to [16:19] seb128: next time you are at your uncle, have a look into the bios; all halfway recent BIOSes should allow you to select the hard disk order on boot [16:19] pitti, ok thanks [16:20] in the best case, the installer picked up the win partition and added it to grub [16:20] otherwise is there a way to just re-do grub install? [16:20] and all you have to do is to try booting from the second hda first [16:20] with grub 1 there was "grub-install /dev/sda" [16:21] and according to --help it should still work for grub 2 [16:21] but I never used it with grub 2 manually [16:21] other story is that new ipod + ubuntu = fail ... [16:21] not ubuntu specific [16:22] but neither the ipod nano 5g nor the itouch works [16:22] db changes and libgpod need changes, upstream is on it though [16:22] and I can't get the touch to connect to wifi [16:23] apple = fail [16:23] rickspencer3: did you send the "team meeting cancelled" to everyone or just me? [16:23] pitti, ok, thanks [16:23] oh [16:23] pitti, I sent it to the list [16:23] no team meeting? [16:23] canonical-desktop-team [16:23] hum [16:23] rickspencer3: I only see me in To: [16:23] I need to filter those out somewhere [16:24] there land in middle of thousand of launchpad bug emails [16:24] rickspencer3: ah, through LP magic? [16:24] yes [16:24] launchpad = noise so far for me [16:24] weird [16:24] and then seb128 filters it out [16:24] :) [16:24] seb128: for me it's "To: Martin Pitt ", and no X-LP-Bugs: stuff [16:24] I'm wondering if I should have 2 lp account [16:24] one for "work" and one for bug spam [16:25] I could just recreate the list locally, but I forgot to back up my lists on evo last time I reinstalled, and the lp page is right there and so easy [16:25] * pitti gently points seb128 to https://wiki.ubuntu.com/Bugs/HowToFilter [16:26] pitti, I've filters thanks, I just need a new one for this case [16:26] rickspencer3: I added tseliot to that team [16:26] I'm already putting assigned bugs, etc on the side [16:27] pitti, ok [16:27] looks like the rotations starts officially Nov 30th [16:27] * rickspencer3 just got mail [16:27] right [16:27] I got that email too [16:27] morning [16:28] hey bryce [16:31] urg, "finish merges" [16:32] is that a "continue merges" or are those supposed to be done now? [16:32] * seb128 still has tons of those to do [16:32] * rickspencer3 whip cracking noises [16:32] seb128: there's no immediate deadline for it [16:33] seb128: it was just a gentle reminder "those still exist, too" :) [16:33] but this week, drafting blueprints has higher urgency [16:35] the after sprint+uds stack of tasks is exiting and depressing... ;-) [16:36] I hope that was meant to mean "exciting" :) [16:36] * pitti hugs seb128 [16:36] * seb128 hugs pitti [16:37] not sure, add this to the burn-out chart ;-) [16:37] lol [16:37] seb128, agreed [16:39] * seb128 kicks launchpad [16:39] stop sending me a zillion email each time somebody runs apport-collect [16:39] 21 emails by run [16:40] it's ridiculous... [16:40] rickspencer3: ^ how many "whip crack noises" should we account for every assignee on the burn-out chart? [16:40] pitti, could be tar.gz those on client side...? [16:40] hehe [16:40] seb128: in theory yes, but that woudl make them even less convenient to look at? [16:40] I guess it will make people complain about that making thoses harder to review though [16:41] * pitti wants those condensed in one mail [16:41] but fortunately there is a "delete thread" key in mutt [16:41] * seb128 too [16:42] well, I don't want to delete the thread [16:42] I use my bugboxes archive to find bugs [16:42] quicker than using web search [16:44] pitti, it would be lovely if the apport-collect emails had some text or tag we could make procmail rules for to exclude them... [16:44] although I admit I've pretty much given up on my bug inbox [16:45] hmm, no meeting today? or did daylight savings get me again? [16:45] - bug.addAttachment(comment='', [16:45] + bug.addAttachment(comment='apport-collect data', [16:45] bryce: ^ like so? [16:46] bryce: meeting was cancelled, see Rick's recent mail [16:46] pitti, yeah [16:47] bryce: it's not a mail subject, though [16:47] so you have to filter on the body [16:47] addAttachment() doesn't have a subject field [16:47] pitti, yeah that would be better but body filtering is doable [16:48] erf, wish I'd known the meeting was canceled, I'd have not gotten up early ;-) [16:48] bryce: committed [16:48] sweet [16:49] seb128, ^^ there you go [16:50] # Notifications of apport data collection [16:50] :0 B: [16:50] * ^apport-collect data$ [16:50] launchpad.apport [16:50] haven't tested it, but think that's the right procmail rule for this [16:51] hm, I guess what you really want is to get the first one in your regular bug mailbox [16:51] and all others to /dev/null [16:51] so perhaps the first one should have a different comment? [16:51] yeah [16:52] at least I want to know that people added new info [16:52]