[00:03] <cjwatson> soren: because it needs large chunks of it anyway in order to generate configuration files that refer to other detected operating systems
[00:03] <cjwatson> soren: also, it *does* call grub-install
[00:04] <cjwatson> soren: the thing it's really replicating is update-grub (grub-install doesn't generate a configuration file ...), and that's because update-grub really isn't all that good at handling the initial installation case
[00:06] <soren> cjwatson: Ah, right. Other operating systems. That was the missing piece of the puzzle. I haven't had to worry about such a thing for a looong time :)
[00:29] <xivulon> I have uploaded umenu code to https://code.launchpad.net/umenu
[00:30] <xivulon> make prerequisites && make && make test
[03:35] <TheMuso> Ok, there is one bug I can consistantly reproduce with partman-dmraid, however its a little hard to explain without knowing how partman presents the UI. How can I turn up debugging to max so I can get a deacent log to show to you guys?
[04:08]  * TheMuso smacks whoever wrote the part of the dmraid init script that sources /etc/default/rcS, and doesn't check whether it even exists.
[06:53] <cjwatson> TheMuso: DEBCONF_DEBUG=developer is usually the most useful kind of logging for that
[06:58] <TheMuso> cjwatson: Thanks, once I get an install done, I'll dig deeper. Still got to get my custom CD to behave first. :p
[07:22] <evand> cjwatson: if you have a free moment today, I've finished off the patch I showed you before that there was confusion over.  If you could just review the partman-partitioning changes and let me know if they're too hackish to use, I'd very much appreciate it.
[07:22] <evand> http://pastebin.ubuntu.com/4535/
[07:44] <TheMuso> Yes! Passed the kernel/base system stage. Now the only worry is grub/grub-installer.
[08:15] <TheMuso> gah. Grub failure, somewhat expected.
[08:16] <TheMuso> evand: If you're still around, and had made a start on dmraid main inclusion, do you have anything that I might find useful for the report?
[08:17] <evand> TheMuso: I haven't had a chance to touch it all.  Unfortunately, I leave you with a blank slate.
[08:17] <TheMuso> evand: No problem, thanks anyway.
[08:25] <CIA-22> ubiquity: evand * r2454 ubiquity/ubiquity/frontend/kde_ui.py: Stub set_grub_combo in kde_ui for the time being so it doesn't crash.
[08:27] <TheMuso> evand: How is that privelage separation stuff going? Is that likely to land before FF?
[08:28] <evand> TheMuso: oh wow, I never did merge that.  I'll take care of that today.
[08:28] <evand> It's done though.
[08:28] <evand> Though I might need to update it slightly to reflect some recent changes.
[08:29] <TheMuso> evand: Right, let me know, and I'db e glad to hammer it, at least with accessibility testing. :)
[08:30] <evand> TheMuso: will do :)
[08:32] <tjaalton> cjwatson: got time to talk about input-hotplug?
[08:33] <tjaalton> cjwatson: I heard you are in the middle of a meeting, so ping me when done
[08:41] <TheMuso> cjwatson: Where is the best place to set that debconf variable?
[08:44] <cjwatson> TheMuso: kernel command line
[08:44] <cjwatson> tjaalton: sure
[08:46] <tjaalton> cjwatson: ok, so I'm aware that FF is tomorrow, and we still don't use input-hotplug. I tried to get the hal-script working (to autoconfigure the devices on fly), but either it won't work or I'm doing something wrong
[08:47] <tjaalton> cjwatson: I sent an email to debian-x about it, and David answered a month ago saying that he prefers patching the server to use the settings on the xorg.conf, which would make it work for everyone
[08:47] <cjwatson> patching the server to do what?
[08:47] <tjaalton> cjwatson: but he's been really busy lately, and hasn't published any patches
[08:47] <cjwatson> oh
[08:47] <cjwatson> sorry, I'm dense and can't read
[08:47] <tjaalton> heh
[08:47] <cjwatson> does it not honour xorg.conf right now?
[08:47] <tjaalton> no
[08:47] <tjaalton> if using input-hotplug
[08:47] <cjwatson> for keyboard layout and such?
[08:47] <tjaalton> rihgt
[08:48] <tjaalton> -ght
[08:48] <cjwatson> huh, ok
[08:48] <cjwatson> I think I also prefer patching the server
[08:48] <cjwatson> my concern is that the installer changes required are ... well, not hideously complicated, but not trivial either
[08:48] <cjwatson> and we're really short of installer bandwidth for feature freeze
[08:48] <tjaalton> are there any changes needed, really?
[08:49] <tjaalton> console-setup works and the xorg configuration still feeds on that
[08:50] <tjaalton> let me dig up the post for you, a sec
[08:51] <tjaalton> http://lists.debian.org/debian-x/2007/12/msg00234.html
[08:51] <tjaalton> I also tried #hal, but got no help :/
[08:53] <tjaalton> the problem with _not_ going input-hotplug is that upstream is still fixing issues with legacy input
[08:53] <tjaalton> they are all using evdev now
[08:54] <cjwatson> changes> console-setup generates /etc/default/console-setup, xorg generates xorg.conf based on that. Does the HAL script use either of those?
[08:54] <cjwatson> ah, I see from your post
[08:55] <cjwatson> ok, I'm less concerned about something that uses the same keyboard configuration files
[08:55] <tjaalton> right
[08:56] <cjwatson> sleep 15> does output from 'set -x' go anywhere?
[08:56] <tjaalton> I need to reproduce it now, but AIRI it didn't
[09:01] <cjwatson> you could do 'exec 2>/tmp/foo' up-front
[09:02] <tjaalton> before running hal?
[09:02] <cjwatson> no, at the top of your hal script
[09:02] <tjaalton> ah, ok
[09:02] <cjwatson> right below the shebang
[09:03] <tjaalton> ok, I'll play with it and report back what happens
[09:03] <tjaalton> thanks
[09:12] <CIA-22> ubiquity: evand * r2455 ubiquity/ubiquity/frontend/kde_ui.py: Replicate fix for the installer window briefly showing in kde_ui.
[09:20] <tjaalton> cjwatson: ok, the same as before; without sleeping I get 'Could not initialise connection to hald.' after the command, and with sleep 15 it doesn't even run h-s-p
[09:21] <tjaalton> but the hald output says '/usr/lib/hal/scripts/hal-setup-xorg exited'
[09:22] <cjwatson> sleep 15 || true
[09:22] <cjwatson> ?
[09:22] <cjwatson> oh, I wonder if its PATH is bogus
[09:22] <cjwatson> try PATH=/usr/sbin:/sbin:/usr/bin:/bin at the top?
[09:22] <cjwatson> export PATH=blah, that is
[09:23] <tjaalton> but it runs without sleep, and hal has a default value all scripts can use
[09:23] <cjwatson> doesn't seem to be a problem for built-in scripts though
[09:23] <tjaalton> setting || true didn't help
[09:33] <tjaalton> ok, it terminates the script after 10 seconds, so setting sleep 9 makes it complain the same about hald not running
[09:34] <tjaalton> hrm, what about running the script from /etc/X11/Xsession.d ?-)
[09:40] <tjaalton> nope, no change. the fault is not that hald isn't running, the command works when run by hand
[09:57] <tjaalton> hmm, maybe policykit has something to do with this
[10:15] <TheMuso> Does anybody know off-hand what an error code of 20 from grub-installer is supposed to mean?
[10:16] <TheMuso> Oh its something to do with debconf in this situation. Will need to dig into the source...
[10:18] <cjwatson> $ grep 20 /usr/share/perl5/Debconf/ConfModule.pm
[10:18] <cjwatson>         syntaxerror => 20,
[10:18] <cjwatson>  should come with an attached descriptive message
[10:29] <TheMuso> cjwatson: Yeah I saw that in the debug output which was how I worked it out.
[11:55] <TheMuso> \o/
[11:55]  * TheMuso has an install of hardy on a dmraid setup.
[12:02] <tjaalton> cjwatson: I sent an email to the hal-list, hopefully it'll get sorted
[12:07] <cjwatson> tjaalton: cool, thanks
[12:07] <cjwatson> TheMuso: nice. what was the grub-installer problem?
[12:07] <TheMuso> cjwatson: db_input input not being given enough arguments. I've already tested the fix, and its in bzr.
[12:08] <TheMuso> The fix allowed the install to happen to be precise.
[12:09] <TheMuso> Note that this wasn't a dual boot. If I can get this in as a feature before FF, I intend to put it all through its paces, including an install alongside 1 and 2 different windows installs, on the same fakeraid setup.
[12:12] <TheMuso> cjwatson: So to have it considered as a feature, is it just a matter of filling out an MIR, or is there more to the process than that?
[12:12] <cjwatson> TheMuso: looks good; please upload grub-installer at your convenience. I've committed the same fix upstream.
[12:13] <TheMuso> cjwatson: Ok, I assume you saw my change...
[12:13] <cjwatson> TheMuso: https://wiki.ubuntu.com/MainInclusionProcess and it would probably be best to explicitly talk to pitti about it
[12:14] <cjwatson> TheMuso: yep, I updated when you said you'd committed it
[12:14] <cjwatson> TheMuso: that's on the error path though - if that error fires, surely the install is broken?
[12:14] <cjwatson> (the fix was clearly right all the same)
[12:15] <TheMuso> Yeah, why it triggered an error though, I don't know. But yes, that gets triggered if there is a problem, which is why several configs need testing.
[13:01] <TheMuso> Hrm. Looks like whatever does the UUID to device name/node translation is picking up the first disk in the raid1 mirror, instead of the devmapper device. Need to check dmraid bugs to see if there is any thing similar reported.
[13:25] <TheMuso> cjwatson: We're in luck. Theres already an MIR for dmraid. I'll give it a look over, and change anything that needs changing, and file the bug if that also hasn't been done already.
[13:53] <cjwatson> cool
[14:16] <evand> cjwatson: did you happen to catch my above message?  If you haven't had a chance to look it over, that's perfectly fine, I just wanted to make sure you saw it.
[14:27] <TheMuso> Ok, dmraid MIR reviewed, and looks ok. Wrote partman-dmraid MIR, and filed bugs for both. Unless anybody needs help with other FF stuff, I'm off to bed.
[14:28] <evand> goodnight TheMuso
[14:40] <cjwatson> evand: I'm still not entirely confident I understand it, but please go ahead and commit and if there's a problem I'm sure it'll come to light later
[14:42] <evand> cjwatson: ok, it will probably be easier to follow when you can see the UI in action anyway.
[15:27] <CIA-22> ubiquity: evand * r2456 ubiquity/ (debian/changelog ubiquity/frontend/kde_ui.py):
[15:27] <CIA-22> ubiquity: * Add the progress bar for automatic mode that was already present in
[15:27] <CIA-22> ubiquity:  gtk_ui to kde_ui.
[15:45] <CIA-22> ubiquity: evand * r2457 ubiquity/ (5 files in 4 dirs): * Replace the resize slider with a custom widget in gtk_ui.
[20:02] <CIA-22> ubiquity: evand * r2458 ubiquity/ (d-i/manifest debian/changelog):
[20:02] <CIA-22> ubiquity: * Automatic update of included source packages: apt-setup
[20:02] <CIA-22> ubiquity:  1:0.31ubuntu5, grub-installer 1.27ubuntu5, hw-detect 1.58ubuntu2,
[20:02] <CIA-22> ubiquity:  partman-partitioning 54ubuntu2.
[20:12] <CIA-22> ubiquity: evand * r2459 ubiquity/debian/changelog: releasing version 1.7.7
[20:14] <CIA-22> ubiquity: evand * r2460 ubiquity/ (9 files in 6 dirs): Bump to 1.7.8
[22:33] <TheMuso> Hrm. Dmraid doesn't 1) halt on a degraded array setup, and 2) have any options to state that you don't want a degraded array, and no real way of checking the status, and getting something meaningful back with an exit code.
[23:02] <TheMuso> And, the array doesn't seem to be rebuilding under Linux, as well as dmraid stating that status is ok, even though it is incomplete...


[01:40] <jandrusk`> Decided to try ERC instead of IRSSI. Very cool.
[01:53] <jrgifford> ERC?
[01:53] <jrgifford> oh, emacs stuff
[01:57] <Unit193> Emacs OS :P
[02:14] <jrgifford> very true Unit193, and jandrusk` is about as close to it as you can get. ;P
[02:15] <Unit193> Hmmm... Time to take pics of the snow
[02:16] <canthus13> Unit193: that's not snow, it's the ashes of dead aliens.
[02:17] <Unit193> First thought was Doctor Who :D
[02:17] <canthus13> :)
[02:18] <Unit193> I'd assume you saw the CMas one too?
[02:18] <canthus13> Yep.  Not as good as previous ones. :/
[02:20] <Unit193> True...
[02:24] <jandrusk`> Planet Emacs ;)
[02:25] <jandrusk`> http://planet.emacsen.org/
[10:10] <Unit193> Ah, right. That's supposed to be this week
[19:21] <Cheri703> Unit193: I'm scrapping u-h tonight. I don't have time :/
[19:21] <Cheri703> 1/11/12 will be the next for us, ok?
[19:23] <Unit193> K O!


[05:54] <MTeck> I'm moving from one launchpad account to another. I was wondering if it would maybe be possible to have the new account added to the ~ubuntu-members team with the same expiration date and the old account removed.
[05:55] <Tm_T> we don't con't control that group
[05:55] <Tm_T> uhhh, palm + touchpad = failure
[05:55] <rww> I'd probably poke CC about it if I were you. Or not do it in the first place :|
[05:57] <rww> (since you can rename accounts now, which I totally took advantage of a while back :D)
[05:59] <MTeck> rww: I'm trying to make a few (a whole lot) of changes and a simple little rename won't work.
[05:59] <MTeck> rww: I toyed with that long and hard but.... it's just not going to work
[06:02] <MTeck> I've actually cleared off about 100-150 GB of dev data I don't need anymore because of all the changes being made. I'm making part of my life involve the outdoors. Or... at least more than a 3ft radius...


[09:37] <bluesabre> Looks like https://bugs.launchpad.net/ubuntu/+source/thunar/+bug/1822380 is almost fixed.
[15:39] <Spass_laptop> hi, not sure if the team has an ability to edit this site, but it looks like someone forgot to delete the old links from here: http://cdimage.ubuntu.com/xubuntu/releases/18.04.2/release/
[15:39] <Spass_laptop> "Desktop image" section is duplicated
[15:40] <Spass_laptop> top one is correct imho, so the links point to the newest point release 18.04.2
[16:50] <knome> Spass, this is something that happens with every LTS..
[16:54] <Spass> ah ok, I wasn't sure if that's intentional or not, someone mentioned it here: https://www.reddit.com/r/xubuntu/comments/bdfz49/the_agony_of_choice_14gb_vs_13gb_though/
[16:54] <Spass> so I just wanted to let you know
[16:59] <knome> yeah.. we have little control over that page
[17:00] <knome> Spass, so the first one is the last point release, the second one is the non-point-release release
[17:00] <knome> i don't know what makes them appear twice
[17:03] <knome> if you want to reply, you can include that information and a note to check the file name in linked URL; one is clearly .x and one is not
[17:06] <Spass> sure, I've edited my response and gave some more info, thanks
[17:06] <knome> np
[17:07] <knome> i didn't remember the situation with the visuals was so bad (maybe it wasn't), there's now a process we can follow to get our own stylesheet applied to that page
[17:07] <knome> i really should follow up with that...
[19:34] -SwissBot:#xubuntu-devel- ::platform:: Seed linux-restricted-modules. @ http://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/platform/commit/?id=a30845a6ecd92e3297bd8ddc7bf3130fa57e087b (by Adam Conrad)
[23:55] <bluesabre> Unit193: you around for an opinion?
[23:56] <Unit193> Yeah. :3
[23:56] <bluesabre> Unit193: https://bugzilla.xfce.org/show_bug.cgi?id=15200#c16 fixes the right-click menu in Thunar... while not already committed, I have tested and verified the fix. Think it's cool to package that up?
[23:57] <Unit193> In regards to it being uncommitted?  Yes that's fine.
[23:58] <bluesabre> Cool
[23:58] <bluesabre> Unit193: want to test it yourself before I write up the bug template and upload? https://paste.ubuntu.com/p/M6ZzkpCYds/
[23:59] <Unit193> Specifically since it's the maintainer, but on the other hand there's got to be a reason he didn't.  Either way, it fixes it without regression, soooo...Good enough bandaid for now.


[02:03] <bjsnider> Sarvatt, is gstreamer-vaapi mature in any sense?
[02:04] <bjsnider> last i looked at it there were some issues
[02:04] <bjsnider> but that was awhile ago
[05:26] <tjaalton> RAOF: it's in the NEW queue, hint hint :)
[05:26] <tjaalton> (along with a bunch of other packages I've pushed..)
[05:26]  * RAOF is not an archive admin
[05:26] <tjaalton> oh
[05:26] <RAOF> I just play one on TV :)
[05:27] <tjaalton> I thought you were
[05:27] <RAOF> I have the powers, for SRU work.
[05:27] <tjaalton> ok
[05:27] <RAOF> Because Launchpad's permissions scheme is not sufficiently fine-grained.
[05:31] <tjaalton> i don't know what's wrong with the -vaapi packaging, but it fails to build the glx backend on sbuild, pbuilder is fine.. check for '-lGL' fails for some reason
[05:31] <tjaalton> had already spent a day on it so meh..
[05:32]  * RAOF might have a look, given that's likely to break on the buildds.
[05:33] <tjaalton> yeah you can grab it from the queue I guess
[05:33] <tjaalton> or git.debian.org/git/users/tjaalton-guest/gstreamer-vaapi.git
[05:33] <tjaalton> bf ->
[05:34] <RAOF> apitrace should be nearly ready, too.
[07:39] <ricotz> RAOF, hi, do you think colord can be synced?
[10:03] <RAOF> ricotz: Yes, colord can be syncd
[10:04] <RAOF> Well, modulo a test-build.
[10:13] <ricotz> RAOF, good, i built and running it, but probably not actually using it
[10:13]  * ricotz was hoping to solve a g-s-d problem with it
[10:13] <RAOF> Ah.
[10:13] <RAOF> I am planning to sync it; I just felt that a little bit of time marinating in Debian wouldn't hurt it.
[10:14] <RAOF> It's pretty well seasoned now, though :)
[10:14] <ricotz> yeah that's right, but avoiding a FFe is easier
[10:18] <seb128> ricotz, hey
[10:19] <seb128> ricotz, do you know what is wrong between unity-greeter and new g-s-d?
[10:20] <ricotz> seb128, hey, no, i havent bothered looking into it, sorry -- i am using gdm
[10:20] <seb128> ricotz, no worry ... any news about gdm 3.2? ;-)
[10:20] <ricotz> libcolor in g-s-d makes some trouble though
[10:20] <seb128> I would still like to get that in precise if we can
[10:20] <seb128> ricotz, yeah, I read that on #gnome-hackers earlier
[10:21] <ricotz> seb128, havent looked at gdm 3.2 for some time
[10:21] <ricotz> but it seems worth some work
[10:22] <ricotz> seb128, so g-c-c and g-s-d 3.4 are on the table again?
[10:22] <RAOF> ricotz: The newer colord doesn't make your work any easier, does it?  I could sync it now if you need it.
[10:23] <ricotz> tjaalton, hi, maybe worth to split up wacom a bit more to avoid breaks/conflicts -- although the plain update it in ppa:ricotz/staging
[10:23] <seb128> ricotz, dunno about g-c-c yet but g-s-d seems doable, I plan to spend today on that
[10:24] <ricotz> RAOF, i guess not sine i am already running it, might be an update issue of g-s-d
[10:24] <ricotz> RAOF, but go ahead ;)
[10:24] <seb128> ricotz, I will revert the keybinding to gsettings first though, the diff seems easy enough that it should be adaptable to use one codepath or the other at runtime if you are interested to work on that to unblock a possible gnome-shell update
[10:24] <tjaalton> ricotz: what exactly?
[10:25] <ricotz> seb128, alright, a runtime solution would be nice
[10:26] <ricotz> tjaalton, they bumped the soname and the libwacom0 contains some common things
[10:26] <seb128> ricotz, the commit is line an hundred lines and it's mostly replacing a gconf object by a gsetting one through a file, so it's likely you could do a if else on the environment
[10:26] <tjaalton> i noticed the soname change
[10:27] <ricotz> seb128, good :)
[10:28] <ricotz> tjaalton, so it might be better to move "usr/share/libwacom" into libwacom-common
[10:29] <tjaalton> ricotz: ok
[10:32] <tjaalton> hmm, or -data
[10:34] <ricotz> tjaalton, i think "*-common" is widely used -- your call
[10:35] <tjaalton> i don't mind either way
[10:39] <tjaalton> 134 packages with -common, -127 with -data.. yay for consistency :)
[10:40] <tjaalton> more accurate numbers 83 and 53
[10:40] <tjaalton> ok so -common it is..
[10:40] <ricotz> ;)
[10:42] <ricotz> lol
[10:56] <tjaalton> hmm -common needs to replace libwacom0 though
[11:15] <tjaalton> seb128: libwacom 0.3 is now building
[11:16] <seb128> tjaalton, thanks!
[11:16] <Lekensteyn> Is this the right channel to talk about Xorg in Precise?
[11:16] <tjaalton> Lekensteyn: yes
[11:17] <Lekensteyn> alright, I've found that AutoAddDevices "false" segfaults X
[11:17] <Lekensteyn> for some reason, the memory in InputOption* has been corrupted, the keys contain garbage values
[11:18] <Lekensteyn> Reproducable with: sudo gdb --args Xorg :7 -isolateDevice PCI:1:00:0 -sharevts -noreset -nolisten tcp -verbose 3 -config /etc/bumblebee/xorg.conf.nouveau
[11:18] <tjaalton> ok. why do you need that btw?
[11:19] <ricotz> tjaalton, small problem
[11:19] <tjaalton> ricotz: ?
[11:19] <Lekensteyn> xorg.conf.nouveau stripped to the core becomes: http://paste.ubuntu.com/840248/
[11:20] <Lekensteyn> it's supposed to make X start faster for Bumblebee, a hack to allow the use of nvidia Optimus hardware
[11:20] <tjaalton> heh
[11:20] <ricotz> tjaalton, the wacom changes in this way doesnt use the benefits of a split
[11:20] <tjaalton> ricotz: what do you mean?
[11:20] <tjaalton> it is split
[11:21] <ricotz> libwacom-common should be arch all and libwacom2 should have a unversioned or >= depend
[11:21] <tjaalton> libwacom-common 0.3-1 needs to replace libwacom0
[11:21] <ricotz> the replace is ok
[11:21] <ricotz> i am just thinking about the next soname bump
[11:22] <tjaalton> oh right, missed the 'all' part
[11:22] <tjaalton> copied it from -dev
[11:22] <tjaalton> why would it be unversioned depends?
[11:22] <tjaalton> *should
[11:24] <ricotz> to make it possible it have two library versions in parallel, which is more for convenience reason on transitions
[11:24] <ricotz> otherwise the split isnt needed at all
[11:24] <tjaalton> it is needed, since the lib is multiarched
[11:24] <ricotz>  libwacom-common (>= ${upsream:Version}),
[11:25] <ricotz> right, so arch: all and a not strict dep on -common
[11:28] <tjaalton> ok, assuming the data format doesn't change
[11:29] <ricotz> exactly
[11:29] <tjaalton> so why not a strict one?
[11:29] <tjaalton> if the data files are updated, it could break the old lib
[11:29] <ricotz> this makes library transitions easier
[11:30] <ricotz> yeah, right
[11:31] <Lekensteyn> tjaalton: gdb session http://paste.ubuntu.com/840259/
[11:32] <tjaalton> Lekensteyn: file a bug
[11:32] <tjaalton> upstream too, if possible
[11:33] <Lekensteyn> Upstream is Debian right? The involved code is different from the official xorg sources
[11:34] <tjaalton> Lekensteyn: no, freedesktop.org. it's probably the same issue with 1.12. you could verify that with the packages from xorg-edgers ppa
[11:34] <jcristau> no, upstream is not debian
[11:34] <tjaalton> Lekensteyn: first make sure to run the latest server, your's is 1.11.3 while precise has 1.11.4
[11:34] <Lekensteyn> no issues with xorg-edgers
[11:34] <tjaalton> -'
[11:34] <tjaalton> ok then
[11:35] <Lekensteyn> xorg-edgers (oneiric) -> no issues. Precise daily image (from yesterday) -> faulty
[11:35] <tjaalton> well it's not running the latest upload
[11:35] <tjaalton> oh, it is
[11:36] <tjaalton> the server version string is still 1.11.3
[11:36] <tjaalton> so file a bug on launchpad
[11:37] <tjaalton> hmm which xserver version does edgers on oneiric have?
[11:37] <Lekensteyn> <IP_ADDRESS> iirc, let me check
[11:38] <tjaalton> so too old
[11:38] <Lekensteyn> <IP_ADDRESS>2 in oneiric
[11:38] <tjaalton> yep, run precise + edgers
[11:39] <Lekensteyn> ok brb then
[11:39] <ricotz> Lekensteyn, if you are brave enough ppa:ricotz/unstable
[11:39] <Lekensteyn> it's a Live CD so it cannot get worse than having to reboot :)
[11:39] <Lekensteyn> what one would you recommend?
[11:40] <tjaalton> ricotz: i'm keeping the = depends, since it's the safest for upgrades
[11:40] <ricotz> tjaalton, ok
[11:40] <tjaalton> also widely used it seems
[11:40] <ricotz> Lekensteyn, this ppa together with xorg-edgers will give you 1.12 on oneiric
[11:40] <ricotz> tjaalton, ;)
[11:41] <Lekensteyn> what about precise?
[11:41] <Lekensteyn> I'm running a non-presistent Live USB Kubuntu Precise right now
[11:41] <ricotz> oh you are running precise
[11:41] <ricotz> i thought you are on oneiric, never mind then
[11:42] <tjaalton> Lekensteyn: enable edgers
[11:43] <ricotz> while running from the cd a restart shouldnt be needed and restarting x will work
[11:44] <Lekensteyn> I don't think I'll need a relogin at all since I'll use a different display number?
[11:45] <Lekensteyn> no crashes with xorg-edgers/ppa
[11:49] <tjaalton> thanks for confirming, now file a bug :)
[11:49] <Lekensteyn> okay :)
[11:49] <tjaalton> against xorg-server
[11:51] <Lekensteyn> Lovely. Titles with "Xorg crash".
[11:52] <Lekensteyn> should it be tagged with "regression"?
[11:55] <tjaalton> yeah
[11:55] <tjaalton> and precise
[11:58] <Lekensteyn> https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/931397
[11:58] <ubot4`> Launchpad bug 931397 in xorg-server (Ubuntu) "Xorg crashes with AutoAddDevices "false" (affects: 1) (heat: 6)" [Undecided,New]
[11:59] <tjaalton> thanks
[11:59] <Lekensteyn> I've not added hardware details. Is that important for this case?
[12:00] <Lekensteyn> Can you reproduce this issue?
[12:00] <tjaalton> haven't tried
[12:00] <tjaalton> hw doesn't matter i think
[12:19] <Lekensteyn> ricotz: can xorg-edgers/ppa on Oneiric be updated? Each time I enter and leave my Wacom Bamboo tablet, I get three lines with "[dix] Unknown event type 35. No filter" in Xorg.0.log. These errors do not occur in Precise (both xorg-edgers/ppa and default) nor the default packages on Oneiric
[12:23] <ricotz> Lekensteyn, please try the oneiric packages in ppa:ricotz/unstable as i said ealier it contain 1.12 for oneiric, but i guess it needs a bit of testing before Sarvatt is comfortable with it ;)
[12:23] <ricotz> Lekensteyn, keep xorg-edgers enabled of course
[19:33] <FernandoMiguel> evening


[12:25] <boodllebat> Hello I recently wrote an small application for Gnome and Unity Env under Gtk 3 It would be great if you take a look and give me feedback I have hosted it on Github Here is the video Demo https://vid.me/QhyM and here is the github link https://github.com/argunner/StickFace2


[01:20] <_rick> hoi
[01:35] <mjg59> Hello
[01:36] <Micksa> hi
[01:36] <Micksa> okay, so the story so far with STR on my laptop is
[01:37] <Micksa> stuff seems to mostly work okay, except the graphics card :)
[01:37] <Micksa> on resume the PCI config is trashed
[01:37] <Micksa> and "vbetool post" doesn't do a thing
[01:37] <Micksa> so
[01:37] <Micksa> could that be a BIOS related thing at all?
[01:37] <Micksa> could it be related to the fact that it's on a PCIe port?
[01:37] <mjg59> PCI config won't be restored because there's no PCI driver bound to it
[01:38] <mjg59> If it's PCIe, then the issue is probably that the kernel doesn't currently resume PCIe bridges properly
[01:38] <mjg59> There's a patch on acpi-devel - hang on a moment...
[01:38] <Micksa> oooh
[01:41] <mjg59> http://www.codon.org.uk/~mjg59/tmp/pcie.diff
[01:42] <Micksa> oh, but! Mark Lord has an inspiron 9300, which *seems* to be almost identical to a 6000, and his patches, which get STR working for him, don't fix this problem for me
[01:42] <Micksa> um, I'll get back to you :)
[01:42] <_rick> i have problem to compile the kernel with dpkg-buildpackage
[01:43] <Micksa> hmm, that patch applied.
[01:44] <Micksa> on top of his patches I mean.
[01:44] <mjg59> His patches are just for SATA, aren't they?
[01:45] <Micksa> nono, not just the patch you told me about
[01:45] <Micksa> sorry, forgot they were the same person :)
[01:46] <mjg59> So you get working resume but no working video at the moment, right?
[01:46] <mjg59> That's a touch more miserable to fix
[01:47] <Micksa> yeah
[01:47] <Micksa> but at least I can poke the machine via the network after resume. that sure helps.
[01:47] <Micksa> ml has a page at http://rtr.ca/dell_i9300/ which goes into great detail about how to get the i9300 to work with linux
[01:48] <Micksa> and it links to a patch which covers...
[01:48] <Micksa> well, sata and the touch pad :)
[01:50] <Micksa> I'm not actually sure if we have exactly the same PCIe bridge
[01:52] <Micksa> how do you get lspci to accept output from "lspci -vvx" as input?
[01:53] <mjg59> You can't
[01:53] <mjg59> You need to use setpci
[01:53] <mjg59> But the easiest thing to do is to use /sys/bus/pci/devices/foo/config
[01:53] <mjg59> You can cat that out before suspend and back after resume
[02:00] <Micksa> nono, I thought you could pass the output of "lspci -vvx" to the input of a "lspci -F"
[02:00] <Micksa> to get numeric PCI ids, for example
[02:00] <Micksa> (not that ml gave me the right format anyway :) )
[02:05] <mjg59> Oh, right
[02:05] <mjg59> No idea, I'm afraid :)
[02:06] <Micksa> bah
[02:06] <Micksa> what kind of support channel is this
[03:32] <Mithrandir> it's not a support channel.
[03:33] <Mithrandir> it's a development channel
[03:33] <Mithrandir> (says so in the topic)
[05:07] <jbailey> lamont: Hey, how much do you know about crazy ia64 things? =)
[05:07] <swarm> I have found that kernel for amd64-k8 coming with Ubuntu Hoary 5.04 isn't compiled for preemption. That could be the reason for input devices loss of interactivity during heavy /dev/hda I/O activities?
[05:07] <jbailey> swarm: Sure.  Or your dma could be disabled on the harddrive.
[05:07] <swarm> jbailey: it's set to udma5
[05:08] <jbailey> Compiling a kernel with preemtion is still not considered the Right Thing for distro kernels.
[05:08] <lamont> jbailey: very little, truth be told.
[05:08] <jbailey> lamont: Ah, 'kay.
[05:08] <lamont> jbailey: but it's on my list to be come a guru of such things, I fear
[05:09] <jbailey> lamont: I came up with the idea that Xen on ia64 might be able to run an i386 kernel.
[05:09] <swarm> jbayley: is it available any kernel running on amd athlon 64 with preemption enabled provided by Ubuntu team?
[05:09] <jbailey> swarm: No
[05:09] <jbailey> lamont: I haven't told you the truly horrific part yet. =)
[05:09] <jbailey> I want to part the Hurd to Xen. =)
[05:09] <lamont> jbailey: the horror is that there's a chance it could work
[05:10] <lamont> that's part the Hurd _with_ Xen. :-)
[05:10] <jbailey> Right, same thing really. =)
[05:11] <swarm> perhaps it's the wrong place but I ask here... do you know if sun jre/jdk >= 1.4.2 amd64 release run on Ubuntu Hoary amd64?
[05:11] <jbailey> Right, it's the wrong place. =)  Please try in #ubuntu.
[05:13] <swarm> I tried yesterday and before.. On #debian-amd64 said that it's normal having that Sun things run on debian amd64. Thanks for the info about kernel
[05:14] <lamont> jbailey: does that mean yopu
[05:14] <jbailey> lamont: I've been looking for little kernel and compiler projects that will allow me to learn stuff in my spare time without having someone else run me over on it.  I suspect this might be an amusing one that noone else would be actively trying to make work right now. =)
[05:14] <lamont> you're going to make Xen work with NPTL?
[05:14] <lamont> jbailey: well, _THAT's_ for certain. :0)
[05:15] <lamont>  /topic jbailey's interest in the Hurd finally explained
[05:15] <jbailey> lamont: It looks like it might now.  I was reading a mailing list and talking with some folks on #xen, and it looks like they can emulate what they need now at a huge penalty, or you can do a custom glibc that uses a few line patch to do TLS accesses differently.
[05:15] <lamont> is there anyway to make that patch part of the standard glibc, I wonder?
[05:16] <jbailey> lamont: What might be interesting is to see if it's possible to get Xen'ness exposed as an HWCAP and then just build an extra pass onto glibc with that patch.
[05:17] <lamont> sounds reasonable
[05:17] <jbailey> Unlikely.  I don't know all of what happens with the patch, but it looks like it doesn't use %gs:# to access the thread stuff anymore, but calculates it.
[05:17] <lamont> ah, blech
[05:19] <jbailey> lamont: If I do take this on, would you mind the occasional ia64 question?  You know, like "Is it true the last twinky^Witarnium rolled off the assembly line in 1970 and they're just selling the stock now?"
[05:19] <lamont> eep.  must take daughter to girlscouts
[05:19] <lamont> bbl
[05:19] <jbailey> c'ya
[05:20] <lamont> jbailey: you can ask whatever you like (literally).  I reserve the right to not answer. :-)
[05:20] <lamont> and yes, I have stopped beating my wife.
[05:20] <jbailey> Err.
[05:20] <jbailey> Why?
[05:21] <jbailey> (That's question #1)
[05:21] <lamont> I let her win now.
[05:21] <jbailey> =)
[05:26] <swarm> Using headers of current kernel image got with Ubuntu Hoary, config from /proc/config.gz, I should be able to modify kernel config only for preemption with easy, right?
[05:26] <jbailey> I guess so, dunno.
[05:26] <jbailey> I don't build my own kernels.
[06:48] <jbailey> lamont: w-b question for you.  Does it respect the Architecture field, or does it hand everything to everyone?
[06:50] <lamont> w-b respects Packages-arch-specific.  It cares not one wit about Architecture:
[06:50] <lamont> dpkg/debhelper will fail the build based on Architecture: though
[07:41] <swarm> jbailey: solved input devices latency problem related to kernel preemption disabled.
[07:46] <swarm> I'm using kernel 2.6.11 amd64-k8 smp from Ubuntu. CONFIG_PREEMPT is not set while, of course, CONFIG_SMP=y. My pc has 1 CPU. Now there is no latency and it's very usable. Why?


[08:37] <ara> morning all :-)
[09:05] <davmor2> Morning All
[09:08] <jpds> davmor2: Hey, you possibly coming to the London bugjam?
[09:09] <jpds> (Info: https://wiki.ubuntu.com/GlobalBugJam/London)
[09:21] <davmor2> jpds: I'm looking into how my finances are if I can I will be yes
[09:21] <jpds> This will be costy for me too, since I'm flying over from Spain ;-)
[11:46] <davmor2> ara, schwuk: Can you think of any other hardware testcases for either laptop/server/netbook/desktop that I might of forgotten here http://testcases.qa.ubuntu.com/Hardware
[11:46] <davmor2> I suppose the is keyboard and mouse D'oh
[11:46] <davmor2> s/the/there
[11:47] <schwuk> davmor2: Optical Drives?
[11:47] <ara> davmor2: external harddrive??
[11:47] <davmor2> good, good anything else ?
[11:47] <schwuk> davmor2: USB Storage
[11:48] <davmor2> schwuk: covered on external ports
[11:48] <schwuk> davmor2: spotted that
[11:48] <ara> davmor2: printers? scanners?
[11:48] <davmor2> cool
[11:53] <davmor2> added printer, scanners, usb hard drive (Thought about it you can install from them so deserving of their own section) and optical :)  Thanks
[16:03] <Blaimi> hi
[16:08] <davmor2> Blaimi: hello
[16:08] <Blaimi> I have no sound, uninstalling or reinstalling the packages pulseaudio and libpulse0 doesn't help, dpkg-reconfigure also not.. the sound-manager displays only an analog device. lspci: Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 02)
[16:09] <davmor2> Blaimi: What are you running?
[16:10] <Blaimi> jaunty
[16:13] <Blaimi> the problem is since ~1 week.. i thought, there would come an update, like in november (bug #296738), but there are no updates for pulseaudio since I have the problem
[16:13] <ubot4> Launchpad bug 296738 in pulseaudio "[Jaunty] Sound muted on boot (dup-of: 299093)" [Medium,Confirmed] https://launchpad.net/bugs/296738
[16:13] <ubot4> Launchpad bug 299093 in alsa-utils "[jaunty] initscript fails to (re)store mixer settings due to check for nonexistent /sbin/alsactl (inadvertently moved to /usr/sbin/alsactl ?)" [Low,Fix released] https://launchpad.net/bugs/299093
[16:13] <davmor2> Blaimi: not sure then my HDA Intel - ALC883 Analog is working fine.
[16:13] <davmor2> which I think is based on the same chipset
[16:13] <davmor2> Blaimi: is this on a laptop?
[16:14] <Blaimi> IBM X60t
[16:14] <Blaimi> Lenovo X60
[16:15] <davmor2> Blaimi: try clicking on the sound icon, then click on Volume Control on sound prefs click on output and ensure it is using the speaker and not the modem
[16:18] <Blaimi> its not a mixer problem, if I start alsamixer, ther is only one mixer (Master) and it's NOT mute
[16:19] <Blaimi> paplay gives also no sound...
[16:27] <davmor2> You might be better off a/ writing a bug and b/ having a chat on #ubuntu+1


[00:22] <ikepanhc> infinity: eh, I forget to write tracker bug number...
[01:13] <bjf> ikepanhc: did you run verify-release-ready ?
[01:13] <ikepanhc> bjf: eh, no. how to use it?
[01:14] <bjf> ikepanhc: it is in the wiki as one of the steps .. one sec.
[01:15] <bjf> https://wiki.ubuntu.com/KernelTeam/StableHandbook/StablePatchApplication
[01:15] <bjf> ikepanhc: ^
[01:15] <ikepanhc> bjf: thanks....
[01:15] <bjf> ikepanhc: step #11
[01:16] <ikepanhc> bjf: ACK... I shall print this page
[04:59] <ChogyDan> hey folks.  I'm trying to write a compile a kernel guide.  Am I on the right track?  ( I still have to figure out the configuration part) http://chogydan.blogspot.com/2012/08/pre-draft-build-instructions.html
[05:00] <ChogyDan> any feedback will be much appreciated.  I would really like to write the guide so folks can do it in the proper Ubuntu setup way, whatever
[05:18] <bjf> ChogyDan: https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
[05:20] <ChogyDan> bjf: I keep getting that link
[05:20] <ChogyDan> or maybe not
[05:23] <ChogyDan> bjf: thanks
[05:23] <bjf> ChogyDan: np
[05:39] <Lin_Hi_Nun_> test
[05:48] <Lin_Hi_Nun_> I filed a bug against the ubuntu-kernel 3.5.x packages.
[05:48] <Lin_Hi_Nun_> I hope I did the right thing
[05:49] <Lin_Hi_Nun_> https://bugs.launchpad.net/ubuntu/+source/policykit-desktop-privileges/+bug/1042540
[05:49] <ubot2`> Ubuntu bug 1042540 in policykit-desktop-privileges "Cannot install 3.5.x kernel, virtual-box-guest errors during compile" [Undecided,New]
[09:58] <brendand> why is there another spin of the precise -proposed kernel?
[10:01] <henrix> brendand: i'm currently re-spining it (again) because we need to revert a patch
[10:02] <henrix> brendand: bug #1031630 failed to be verified, and since it didn't came from a stable update, we'll revert it
[10:02] <ubot2`> Launchpad bug 1031630 in linux "“[drm:pch_irq_handler] *ERROR* PCH poison interrupt” shows after S3 resume when connecting with an external monitor" [High,Fix released] https://launchpad.net/bugs/1031630
[10:03] <brendand> henrix - thanks!
[10:03] <henrix> brendand: np
[11:23] <davmor2> hey guys I have an issue on a HP G62.  When ever the webcam is activated it kills the system.  There are no flashing leds,  I've tried using ssh and tailing the syslog but as soon as the webcam activates the ssh stops sending and the system is in hard lock up, there isn't a sysrq button on the laptop either :(
[11:23] <davmor2> this however stops me installing via ubiquity as it triggers the webcam
[11:23] <davmor2> checking the logs currently
[11:30] <davmor2> paste.ubuntu.com/1171601/ is all I see in the syslog,  I mounted the cd to log where the I started the cheese application.
[11:30] <davmor2> 12:19 I'm assuming is the start of the restart after hard powering it down
[11:35] <davmor2> if I can provide any other info please let me know what
[11:56]  * ogra_ looks around for someone with a bit of kernel packaging knowledge ... seems the omap4 packaging needs some slight changes to fix bug 1041607
[11:56] <ubot2`> Launchpad bug 1041607 in linux-meta-ti-omap4 "cannot install linux-ti-omap4 3.5.0-209-omap4" [Undecided,New] https://launchpad.net/bugs/1041607
[12:01] <rtg> ogra_, looking. I'll get back to it in a bit.
[12:01] <ogra_> great, thanks
[12:59] <ChogyDan> hi guys, Im trying to write a specific guide for compiling a kernel.  Ive been following this page: https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel     and there are some errors
[13:01] <rtg> ChogyDan, the 'Building the kernel' part should prolly use dpkg-buildpackage so that uninstalled build dependencies get caught
[13:02] <ChogyDan> rtg: oO     that wasn't even what I was talking about.  Do you know of a guide that is actually accurate?
[13:03] <rtg> ChogyDan, on the surface of it, I think it looks accurate. maybe you could tell me what specific errors you're having ?
[13:04] <ChogyDan> the part about configuration.  chmod a+x debian/scripts/misc/*     <---- that doesn't hit /debian/scripts/config-check
[13:04] <ChogyDan> (Im having trouble understanding the configuration stuff in general, which is why Im focusing on it)
[13:05] <rtg> ChogyDan, looks like its  already executable, at least if you clone it using git.
[13:05] <ChogyDan> rtg: Im using apt-get
[13:06] <rtg> lemme check...
[13:08] <ChogyDan> rtg: anyway, it is a minor error.  The main issue is after I apply a patch set Im working on, Im getting config errors.  I still need to work through that
[13:09] <ChogyDan> rtg: thanks for confirming the guide!
[13:09] <rtg> I'll add the one line so that all the files are marked executable
[13:12] <ChogyDan> sounds good
[13:46] <sconklin> jjohansen: you here? It looks like CVE-2012-3400 is flapping between needed and pending in the tracker
[13:46] <ubot2`> sconklin: ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3400)
[14:19]  * ogra_ wonders what went wrong with rsalveti's patch to install linux/omap_drv.h
[14:19] <ogra_> i cant find it in either 3.5.0-12.12 nor 3.5.0-13.13
[14:20] <ogra_> (assuming its supposed to land in the linux-libc-dev binary package)
[14:23] <rtg> ogra_, 'UBUNTU: [Config] installing omapdrm specific headers for external drivers' ?
[14:23] <ogra_> rtg, yeah
[14:24] <ogra_> that should install linux/omap_drv.h in linux-libc-dev:armhf
[14:24] <rtg> should be in Ubuntu-3.5.0-12.12
[14:24] <ogra_> but i somehow cant find where it actually ends up
[14:24] <ogra_> right, its neither in 12.12 nor in 13.13
[14:24] <rtg> ogra_, its in the headers package
[14:24] <ogra_> which one ?
[14:25] <rtg> ogra_, in each flavour AFAICT
[14:25] <ogra_> if it goes into an arch specific headers package that doesnt help, we only install linux-libc-dev:armhf from that build on panda
[14:25] <ogra_> all other headers come from linux-ti-omap4
[14:26] <ogra_> well, everything thats called linux-hearders-* at least
[14:27] <ogra_> aha
[14:27] <ogra_> ubuntu@panda:~$ dpkg -c linux-headers-3.5.0-12_3.5.0-12.12_all.deb |grep omap_drv.h
[14:27] <ogra_> -rw-r--r-- root/root      7442 2012-07-21 22:58 ./usr/src/linux-headers-3.5.0-12/drivers/staging/omapdrm/omap_drv.h
[14:28] <ogra_> hmm
[14:28] <ogra_> dkms seems to search for linux/omap_drv.h
[14:28] <rtg> ogra_, linux-headers-3.5.0-12_3.5.0-12.12_all.deb is an install dependency for the flavour specific headers package
[14:28] <ogra_> and very likely under my kernel version (omap4) not under some x86 one
[14:29] <ogra_> rtg, well, i assume the prob is that i run a totally differen version on pandas ...
[14:29] <ogra_> and dkms will likely look in usr/src/linux-headers-$kver/
[14:29] <rtg> ogra_, yeah, we may have aconsolidated headers package for omap4
[14:30] <rtg> a consolidated*
[14:30] <ogra_> well, imho that header should really go into linux-libc-dev:armhf
[14:31] <rtg> ogra_, because its a DKMS dependency ? I'm not sure that makes sense. its not used to build glibs or anything else is it ?
[14:31] <rtg> glibc*
[14:31] <ogra_> no, its only used to build the video driver
[14:31] <henrix> brendand: just fyi, the precise kernel respin has been cancelled. we've decided to keep the patch i was reverting.
[14:32] <rtg> ogra_, in which case you just need to adjust the include path
[14:32] <rtg> but you know that...
[14:32] <brendand> henrix - hmm, so we should still test 48?
[14:33] <henrix> brendand: yep
[14:33] <brendand> henrix - ok. bugs are being updated to reflect that i guess?
[14:34] <henrix> brendand: yes, still working on that. i can ping you back when that's all done
[14:40] <henrix> brendand: ok, everything should be updated now. let me know if you find any inconsistency.
[15:03] <davmor2> Hey guys anyone about who can help with this machine killing webcam I have?  I had the same issue in precise but it got fixed, but currently I can't complete the install process which will become more of an issue if the alternate cd goes away
[15:11] <rtg> davmor2, do you know how it got fixed in precise ?
[15:11] <ayan> there is a laptop going though the certificaiton process that has an unusual bug that after an s3 cycle, once you try to shut down, it will only reboot under precise.  i tried a few kernels from the mainline build page and the earliest kernel that doesn't have this bug is 3.4.1-quantal.
[15:11] <davmor2> rtg: no idea it was broken pre beta when I did a fresh install for beta it worked
[15:11] <ayan> i tried bisecting between 3.4 and 3.4.1 using the precise configuration but NONE of the builds worked.
[15:12] <rtg> ayan, cking is back tomorrow. he'll likely have some suggestions.
[15:12] <ayan> finally, i tried manually budiling with the quantal kernel config and that build didn't have the bug.
[15:13] <davmor2> rtg: the annoying thing for me is that I ssh'd into the box prior to running cheese did tail -f /var/log/syslog and nothing the machine is killed so bad that not even ssh works :(
[15:14] <rtg> davmor2, can you collect apport info on it ? you might have a crash in dmesg if its that messed up
[15:14] <ayan> rtg: i compared the two kernel configs and nothing seemed obvious.
[15:15] <rtg> ayan, you tried to build 3.4, or you tried installing 3.4 ?
[15:18] <ayan> rtg: i haven't built 3.4 but i tried one of the precompiled packages bulit for precise and it has the bug.
[15:18] <ayan> rtg: i might be interesting to build a 3.4 with the quantal .config.
[15:18] <rtg> ayan, so the precompiled 3.41. _did_ work, right ?
[15:18] <rtg> 3.4.1 *
[15:19] <ayan> rtg: but i think i've verified that the configuration is the culprit by building 3.4.1 with both.
[15:19] <ayan> rtg: yes, it does work.
[15:19] <rtg> ayan, so the precompiled 3.4.1 likely started with the Precise config. apw - is that right ?
[15:20] <davmor2> rtg: will do
[15:20] <ayan> rtg: no, it started with the quantal configh iirc.
[15:20] <apw> rtg, it started with whatever the -series part of the directory name says it was
[15:20] <apw> but it would have been the config at the build time
[15:20] <ayan> http://kernel.ubuntu.com/~kernel-ppa/mainline/
[15:21] <ayan> rtg: v3.4 goes up to -precise and -quantal starts at v3.4.1.
[15:21] <rtg> ayan, how unfortunate :)
[15:21] <apw> thats helpful of me to change in the middle like that :)
[15:22] <apw> rtg, perhaps i should kick off a v3.4-quantal to allow comparison
[15:22] <ayan> rtg: yes. :^)  this has kept me up for about two days now.
[15:22] <rtg> ayan,  I see a 3.4 Precise as well as a 3.4 Quantal. do they both behave the same ?
[15:22] <ayan> wow.  somehow i missed the 3.4-quantal.
[15:22] <rtg> apw, there is already a 3.4 Quantal
[15:22] <ayan> i'll give it a whirl now.
[15:23] <apw> now i am confused, i thought ayan said that v3.4 was precise
[15:23] <rtg> apw, thats the one he tried, but I think he missed seeing the 3.4 Quantal
[15:24] <ayan> ya -- there is a v3.4 quantal in that directory.
[15:24] <apw> oh how nice of me to make both
[15:24] <rtg> apw, ayan, so if the Quantal config works then we know its not code, rather its a config difference
[15:24] <apw> rtg sounds resaonable indeed
[15:32] <davmor2> rtg: bug #1042809
[15:32] <ubot2`> Launchpad bug 1042809 in linux "machine locking webcam" [Undecided,New] https://launchpad.net/bugs/1042809
[15:32] <rtg> ogra_, wrt bug #1041607, is there any reason that postinst should just always call 'update-initramfs -c -k $version' as opposed to 'update-initramfs -u -k $version' ?
[15:32] <ubot2`> Launchpad bug 1041607 in linux-ti-omap4 "linux-ti-omap4 generates the initial initrd to late for its own postinst scripts" [High,New] https://launchpad.net/bugs/1041607
[15:37] <ayan> rtg, apw: 3.4-quantal does not have the bug.
[15:38] <rtg> ayan, well, bisecting between configs is gonna be a real pain in the ass
[15:38] <apw> ayan, so 3.4-precise has it, and 3.4-quantal does not -- correct ?
[15:38] <ayan> (thought i thought i already confirmed this by testing 3.4.1 with quantal and precise configs. :^P )
[15:38] <ayan> s/thought/though/
[15:38] <ayan> apw: correct.
[15:38] <apw> rtg, i would expect the differences that early to be small
[15:39] <apw> ayan, so if you extract both of those .configs from /boot and compare them with diff
[15:39] <rtg> apw, true, damn near no-existent. is the tools set different ?
[15:39] <apw> how bad is it
[15:39] <ayan> apw: i'll take a look now.
[15:39] <apw> rtg, we may have compiler changes too
[15:39] <apw> rtg, no both are built in precise chroots i think
[15:39] <davmor2> rtg: if you get a chance let me know if there is anything of any use there if not if there is anything I can do to get more info for you
[15:40] <ayan> i wrote a tool to show differences and they were pretty dramatic between a recent quantal config and precise.
[15:40] <ogra_> rtg, -u doesnt create the initrd on some arches if there isnt a pre-existing one
[15:40] <rtg> davmor2, actually, I need the crash info _after_ you'ce started the USB camera
[15:41] <rtg> ogra_, which is why I'm thinking just always use '-c'
[15:41] <ogra_> rtg, in other news, beyond the fact that we need the omap_drv.h file in linuc-ti-omap4, it seems we also miss http://dev.omapzoom.org/?p=integration/kernel-ubuntu.git;a=commit;h=0428bbdcdb53255b8b42a8ed73ab6ec1d8975054
[15:41] <ogra_> rtg, right
[15:41] <davmor2> rtg: no probs I'll see if I'm able to trigger it and trigger apport via terminal or not
[15:41] <ogra_> (our omap_drv.h searches for omap_priv.h which is non-existing)
[15:45] <davmor2> rtg: Meh nope looks to be stuck at collecting problem info and now the system is unresponsive, I'll see if this finishes or not though
[15:45] <rtg> ogra_, ok. isn't there a bug about the difficulties compiling against omapdrm ?
[15:45] <ogra_> not that i know of
[15:46] <ogra_> and if so, it would be outdated ... i just uploaded the first (supposedly) working pvr for quantal right now
[15:46] <ayan> rtg, apw: maybe this will be useful: http://pastebin.com/tKdi1PyK
[15:46] <rtg> ogra_, then you should start one so we can track this (please)
[15:47] <apw> ayan, could i have both of the v3.4-{precise,quantal} configs please
[15:47] <ogra_> rtg, will do, but i want to debuig that properly with rsalveti first
[15:47] <ayan> CONFIG_X86_MCE_XEON75XX ?
[15:47] <ayan> apw: sure.
[15:47] <rtg> ogra_, ok. just assign it to me once you've created the bug and explained the issues.
[15:48] <ogra_> ok
[15:48] <davmor2> rtg: and now it's completely dead :(
[15:48] <rtg> apw, why are there _any_ differences in the final .config file ? its the same Kconfig's
[15:49] <apw> rtg, it is starting from a different configuration shoved into the same valid options
[15:50] <apw> rtg, there is cirtainly the possibility of a different result
[15:50] <ayan> apw: http://zinc.canonical.com/~ayan/apw/
[15:51] <ayan> d'oh.
[15:51] <ayan> sorry.
[15:51] <ayan> uploading config from 3.4-quantal and 3.4-precise.
[15:54] <rtg> davmor2, so this must be the built-in HP Webcam-101 that is crashing, right ?
[15:54] <davmor2> rtg: it is yes
[15:55] <davmor2> rtg: but it doesn't crash the app as such it's just the system stops responding to anything
[15:55] <rtg> davmor2, which means its crashing the kernel somewhere
[15:56] <davmor2> rtg: indeed but I don't get all the flashing led like I would normally from a kernel crash and there is no apport data in /var/crash
[15:57] <rtg> davmor2, that just means something has gone far more wrong then usual. could be a DMA wedging the PCI bus or something.
[16:02] <ayan> apw,rtg: http://zinc.canonical.com/~ayan/apw/
[16:02] <ayan> the are makred with -quantal and -precise.
[16:03] <rtg> davmor2, it seems like this should behave as a standard UVC USB video  device. You say this works fine on Precise, right ?
[16:03] <jjohansen> sconklin: okay I will look into it
[16:03] <davmor2> rtg: yeap and the first alpha too iirc
[16:04] <rtg> davmor2, the first Quantal alpha was a 3.4 based kernel IIRC
[16:04] <sconklin> jjohansen: I prepped the meeting report for today without running the normal merge process I do, so no hurry
[16:04] <rtg> davmor2, I've got an HP mini. lemme have a look at it.
[16:06] <davmor2> rtg: I can't be certain on the first alpha though. But I know alpha 2 onward I started using alternate as the desktop ubiquity would die on the webcam page
[16:11] <rtg> davmor2, unfortunately mine is a different device, Chicony Electronics. I'm also not finding any crash reports in Google
[16:12] <davmor2> rtg: so Joseph just linked my bug to this one https://bugs.launchpad.net/bugs/875297
[16:12] <ubot2`> Ubuntu bug 875297 in linux "Ubuntu installer hangs on "Choose a picture" screen. Never recovers. Installation not bootable." [Critical,Incomplete]
[16:12] <davmor2> rtg: so it could well be the one driver
[16:13] <rtg> davmor2, can you disable the camera from the BIOS ?
[16:13] <davmor2> rtg: let me reboot the box I'll let you know
[16:15] <davmor2> rtg: Nope very few hardware settings
[16:16] <rtg> davmor2, drat
[16:16] <rtg> davmor2, so the bug jsalisbury has linked to has a different device. Furthermore its a USB 1.0 device whereas yours is USB 2.0.
[16:18] <rtg> davmor2, in fact, that bug originated with 11.10, so I don't think its the same problem.
[16:18] <rtg> jsalisbury, ^^
[16:18] <jsalisbury> rtg, ack, I'll unlink it as a dupe
[16:18] <davmor2> rtg: so the uvcvideo module is the one I have however
[16:19] <rtg> davmor2, yeah, its kind of a generic video handler.
[16:19] <rtg> USB has a standard for video class devices IIRC
[16:20] <davmor2> rtg: any of the devs close to the midlands in the UK?  I'm happy to pay a visit if it gets it fixed :)
[16:21] <rtg> davmor2, apw lives in Wimbledon
[16:23] <davmor2> rtg: I might be able to make a trip to the new office but I was hoping for more of a trip 30 minutes up the road rather than 2-3 hours away :)
[16:23] <rtg> davmor2, UDS ?
[16:24] <davmor2> Nope
[16:24] <jsalisbury> **
[16:24] <jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[16:24] <jsalisbury> **
[16:24] <rtg> davmor2, well, maybe you can bribe apw to meet you somewhere.
[16:24] <davmor2> rtg: I can take a trip to the office at some point in the near future, I'll sort something out apw
[16:25] <apw> davmor2, hmmm is this an installation issue or something which appears when installed
[16:25] <davmor2> apw: both
[16:26] <apw> davmor2, and whats the known good/bad kernels at this point
[16:26] <rtg> davmor2, you can work around it for now by using the alternate installer, then black listing the module before you reboot.
[16:26] <davmor2> apw: because there is a webcam page in the installer it kills that, but also cheese kills the system on an installed system
[16:27] <davmor2> rtg: that's what I did but the devs are looking to lose alternate soon so that won't be an option for much longer
[16:27] <apw> davmor2, does rtgs work around make it work, or just get rid of your webcam
[16:27] <rtg> davmor2, thats true
[16:27] <apw> rtg, what module breaks
[16:28] <rtg> uvcvideo (I think)
[16:28] <rtg> apw, his machine wedges so bad that he can't get a stack trace
[16:28] <davmor2> apw: alternate works,  I can try and disable the webcam module as described in 875297 and see if I can complete the install via live if you want
[16:29] <apw> uvcvideo.__disable__=true on the kernel command line under F6 in the installer?  davmor2 ?
[16:29] <apw> that sort of thing?
[16:30] <davmor2> https://bugs.launchpad.net/bugs/875297 this was remove the module and black list it
[16:30] <ubot2`> Ubuntu bug 875297 in linux "Ubuntu installer hangs on "Choose a picture" screen. Never recovers. Installation not bootable." [Critical,Incomplete]
[16:30] <davmor2> apw: it worked on precise from beta1 on iirc
[16:31] <davmor2> apw: and iirc I was able to install alpha 1 I think it died after alpha 1
[16:35] <davmor2> apw: if it help I can start a live install and add openssh-server and probably give you access but to be honest once the webcam page appears for me the system is dead and I couldn't get any info locally via ssh but you might know a lot more cli-fu
[17:01] <apw> ogasawara, you are about 10% there
[17:01] <rtg> ogasawara, your mumble session went completely to hell
[17:01] <ogasawara> damn
[17:01] <ogasawara> I'm just going to write up what we just talked about and circulate it
[17:27]  * rtg -> lunch
[17:32] <apw> ;b msm/b msm
[17:34]  * henrix -> EOD
[20:02] <phillw> hi good people, is the Quantal kernel in todays builds, or do we have to wait for the cron job to do a daily respin?
[20:08] <rtg> phillw, https://launchpad.net/~ubuntu-x-swat/+archive/q-lts-backport linux-meta-lts-quantal
[20:14] <rtg> herton, were you gonna review the last patch for Lucid CVE-2012-3412 ?
[20:14] <ubot2`> rtg: ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3412)
[20:16] <herton> rtg, it was scarily almost equal to the patch I posted, so I think it's ok, you applied it already to lucid didn't you?
[20:17] <herton> *to the diff I posted
[20:17] <rtg> herton, no, I have not pushed it to the main repo yet, only my public repo.
[20:18] <rtg> herton, the only change from your patch was to move netif_skb_features() into a header file as a static inline.
[20:20] <herton> rtg, ah now I see. Yes that's ok, I think we can push it
[20:20] <rtg> herton, ack
[20:48]  * rtg -> EOD
[21:01] <jwi> ogasawara: was bug 1042903 tested on a 3.5.3 based kernel? looks like it might be fixed by 9830605d4c0
[21:01] <ubot2`> Launchpad bug 1042903 in linux "mgag200 driver hangs on HP ProLiant Gen 8 platform" [Medium,Confirmed] https://launchpad.net/bugs/1042903
[21:02] <ogasawara> jwi: yes, that test kernel I posted was built on a v3.5.3 based kernel.
[21:02]  * ogasawara looks at that sha1
[21:15] <jwi> ogasawara: I meant if the bug was reproduced on 3.5.3 - "Quantal OS" isn't very specific.
[21:17] <ogasawara> jwi: thanks, I've asked if we could get a quick re-test with the 3.5.0-13.13 kernel that was just uploaded and rebased on v3.5.3.  the test kernel I built was based on 3.5.0-13.13 but disabled that experimental driver and previous tests were on a 3.5.0-12.12 or older kernel which was only rebased to v3.5.2 or older.
[21:22] <jwi> ogasawara: thanks - not that disabling experimental drivers for server hw is bad per se, but if there's an easier way to fix it ...;)
[21:23] <ogasawara> jwi: indeed, thanks for the heads up


[13:49] <LinDol> hi all :)
[14:06] <LinDol> hi all
[15:43] <botus> hi
[15:44] <botus> Anyone know how the privacy on ubuntu gnome work? thinking about collecting data and ip and such?
[19:52] <eliasps> darkxst when should we start working on uploading gnome in staging for xenial? During the final freeze?
[21:07] <darkxst> eliasps, soon
[21:52] <eliasps> darkxst ok, let me know!
[22:30] <darkxst> eliasps, can probably start with the core bits, once 3.19.2 tarballs are out


[02:07]  * wgrant throws rocks at SKS
[02:10] <StevenK> wgrant: Oh?
[02:10] <wgrant> Its 404 message has changed
[02:10] <wgrant> That's why we're getting oopses from it
[02:10] <wgrant> But it doesn't actually crash the page
[02:10] <StevenK> What's one of the OOPSes?
[02:10] <wgrant> OOPS-7d16107fdc9d638d26333ce4668d524e
[02:12] <StevenK> I thought we dealt with both 404 and 500?
[02:12] <wgrant> We do
[02:12] <wgrant> But if the error message isn't plausible, we raise a soft OOPS
[02:12] <StevenK> Ah
[02:13] <StevenK> And they changed it
[02:13] <wgrant> Yes
[02:24] <StevenK> wgrant: So I can't find any OOPSes for "[^:]DistroSeries:+localpackagediffs"
[02:24] <wgrant> StevenK: Probably because nobody uses it, potentially because it doesn't work
[02:31] <wgrant> StevenK: https://code.launchpad.net/~wgrant/launchpad/sks-404-msg/+merge/155647
[02:49] <StevenK> wgrant: No fair landing something
[02:50] <StevenK> wgrant: Meh, that was probably fair enough to be a self-review. r=me
[02:52] <wgrant> Probably
[02:52] <wgrant> But the r=wgrant in the log was getting a bit boring
[02:53] <StevenK> Haha
[02:53] <StevenK> Only because the last 9 landings on the trot have been mine
[02:56] <StevenK> wgrant: It does load, though
[02:57] <StevenK> Of course, now it times out for me.
[02:57] <wgrant> StevenK: What or who loads?
[02:57]  * StevenK shoots Murphy in the face.
[02:57] <wgrant> Oh, +localpackagediffs?
[02:57] <StevenK> https://launchpad.net/ubuntu/raring/+localpackagediffs
[02:58] <wgrant> 7.87s
[02:58] <wgrant> Nice
[02:59] <StevenK> 52 queries/external actions issued in 7.43 seconds
[02:59] <StevenK> Yeah
[03:00] <StevenK> It spends 300ms looking up the DSDs, and then 3.5seconds grabbing the publications
[03:00] <wgrant> Yeah
[03:00] <wgrant> Explaining now
[03:00] <wgrant> It's using SPR.spn, which is probably the main problem
[03:00] <wgrant> I missed another one :(
[03:01] <StevenK> Can you also explain why it runs the query four times?
[03:01] <StevenK> It's Launchpad, not Santa Claus.
[03:01] <wgrant> Hey, you were on the team that wrote that page, not me :)
[03:01] <wgrant> But I'd get an OOPS and check what calls it
[03:01] <wgrant> Because that's hilarious
[03:02] <wgrant>  Total runtime: 90667.543 ms
[03:02] <wgrant> ooh yeah
[03:02] <wgrant> 350ms->65ms by dropping the SPR join
[03:03] <StevenK> wgrant: http://pastebin.ubuntu.com/5651202/
[03:03] <wgrant> Oh right
[03:03] <StevenK> wgrant: Just check that I'm not going insane, and it is
[03:03] <wgrant> This is the derpquery
[03:03] <wgrant> That has the completely strange anti-optimisation technique
[03:03] <wgrant> To try to prevent it from using the index that is probably now optimal
[03:03] <wgrant> AND SourcePackagePublishingHistory.archive+0 = Archive.id
[03:04] <wgrant> 3ms
[03:04]  * wgrant enbranchinates
[03:04] <StevenK> Ah
[03:04] <StevenK> I was going to do that
[03:04] <StevenK> Beh eh
[03:04] <wgrant> No'
[03:04] <wgrant> I get the trivial ones today, to let me escape from translations crap :)_
[03:05] <StevenK> And all four of them are different
[03:05] <wgrant> Meh
[03:05] <wgrant> I'll make them not suck
[03:05] <StevenK> derived_series vs parent_series
[03:05] <wgrant> Then we can separately eliminate the dupes
[03:05] <wgrant> Ah
[03:05] <wgrant> Anyway
[03:05] <wgrant> Not so bad once they're a direct index scan
[03:05] <wgrant> What's the traceback?
[03:05] <wgrant> Not sure which func it is
[03:06] <wgrant> I guess I could just grep for +0...
[03:06] <StevenK> That +0 might be a red herring
[03:06] <StevenK> I was pulling it from the query log
[03:07] <wgrant> No
[03:07] <wgrant> I remember the query
[03:07] <StevenK> eager_load_dsds
[03:07] <wgrant> It was deliberately used as an anti-optimisation technique
[03:08] <wgrant> And the archive join is just pointless
[03:08] <StevenK> Twitch
[03:08] <StevenK> It's limited to purpose PRIMARY, though
[03:08] <wgrant>         # XXX: GavinPanella 2011-06-23 bug=801097: The + 0 in the condition
[03:09] <wgrant>         # below prevents PostgreSQL from using the (archive, status) index on
[03:09] <wgrant>         # SourcePackagePublishingHistory, the use of which results in a
[03:09] <wgrant> get the ID :)
[03:09] <wgrant>         # terrible query plan.
[03:09] <wgrant> Yeah
[03:09] <wgrant> But you know what we can do instead...
[03:09] <StevenK> Fetch self.context.main_archive.id ?
[03:09] <StevenK> wgrant: Anyway, damn you for stealing my bug
[03:10] <wgrant> Hmm
[03:10] <StevenK> Now I have to find another.
[03:10] <wgrant> May not be able to do this,a ctually
[03:10] <wgrant> Because it cares about the parent
[03:10] <StevenK> "#899003 deadlock detected when importing .po file" is likely going to die as a case of your chainsawing ?
[03:10] <_mup_> Bug #899003: deadlock detected when importing .po file <lp-translations> <oops> <rosetta-imports> <Launchpad itself:Triaged> < https://launchpad.net/bugs/899003 >
[03:11] <wgrant> Unlikely
[03:11] <wgrant> Unless I rewrite rosetta
[03:11] <StevenK> Pity
[03:11] <StevenK> Maybe I should destroy the puller
[03:11] <StevenK> That will keep me out of trouble for a long while
[03:11] <wgrant> Heh
[03:11] <StevenK> But I have no idea where jelmer got up to
[03:11] <wgrant> A very very long while
[03:12] <StevenK> We can't just transition the branches of type MIRRORED to code imports and destroy it?
[03:12] <wgrant> You can get rid of mirrored branches just by migrating the existing ones, really, but that won't obviate the need for the puller.
[03:12] <wgrant> The puller is still used for imports
[03:13] <StevenK> I'm thinking of the broken netstrings critical
[03:13] <StevenK> Migrating MIRRORED branches and dropping the type might close it, or at least drop it to Low
[03:14] <wgrant> I don't think so
[03:32] <wgrant> StevenK: https://code.launchpad.net/~wgrant/launchpad/bug-1160461/+merge/155651
[03:33] <StevenK> wgrant: v = ? Really?
[03:33] <wgrant> Really!
[03:33] <wgrant> I can change it if you want
[03:34] <StevenK> I would prefer view =
[03:34] <StevenK> And you're not trying to force a long line to be short enough
[03:36] <wgrant> wtf
[03:36] <wgrant> dsd indices are terrible
[03:40] <wgrant> StevenK: Fixed.
[03:41] <StevenK> I just saw
[03:41] <StevenK> You're a terrible person
[03:41] <StevenK> r=me
[03:42] <wgrant> Thanks
[03:44] <wgrant> And the 1s DSD-finding query is now mysteriously 2ms
[03:44] <wgrant> (* may actually be index, not actual mysteriousness)
[03:45] <StevenK> Haha
[03:59] <wgrant> StevenK: https://dogfood.launchpad.net/ubuntu/quantal/+localpackagediffs
[03:59] <wgrant> And that's without the DSD index
[03:59] <wgrant> Still slow, but that's hopefully just because DF is DF
[04:10] <wgrant> StevenK: https://code.launchpad.net/~wgrant/launchpad/localpackagediffs-rargh/+merge/155657
[04:17] <StevenK> wgrant: What's the index out of interest?
[04:19] <wgrant> (derived_series, status, difference_type)
[04:19] <wgrant> Not going to add it for now
[04:19] <wgrant> But it's something we might want to look at later
[04:20] <StevenK> wgrant: Going to link 801097 to the MP?
[04:20] <wgrant> A good point.
[04:21] <StevenK> wgrant: r=me
[04:21] <wgrant> Thanks.
[04:26]  * StevenK glares at the critical list
[04:27] <StevenK> wgrant: I do wonder about a BugJob that does notification
[04:27] <StevenK> But I worry that I'd get murdered
[04:30] <wgrant> StevenK: Sort of
[04:31] <StevenK> I'd get sort of murdered?
[04:31] <wgrant> Deferring recipient calculation by storing the criteria in a table would work
[04:31] <wgrant> But it's a fair bit of work
[04:32] <StevenK> wgrant: Suggestions for what I should look at, then?
[04:32] <wgrant> Um
[04:32] <wgrant> Stuff.
[04:32] <wgrant> And things :)
[04:32] <StevenK> Thanks for being so very helpful. :-P
[04:33] <StevenK> I do wonder how txlongpoll is run, WRT 960868
[04:33] <wgrant> It might almost be worth making another pass at the loggerhead criticals
[04:33] <wgrant> You can probably fix several of those in one day
[04:33] <StevenK> But it's loggerhead ...
[05:06] <StevenK> wgrant: How do I land stuff against loggerhead?
[05:07] <StevenK> Hmmm, we're 7 revs behind
[05:17] <wgrant> Should just need to commit directly to trunk
[05:17] <wgrant> Check the recent history
[05:31] <StevenK> wgrant: We have no codebounce on staging/qas ?
[05:32] <wgrant> StevenK: Yes, it's there
[13:18]  * jelmer waves
[13:18] <czajkowski> jelmer: boo
[13:18] <jelmer> StevenK: migrating MIRRORED branches to code imports should do the trick
[13:19] <jelmer> StevenK: I don't think there was a reason for not doing that, apart from the time it would take to manage that transition
[13:19] <jelmer> czajkowski: hey hey :)
[23:54] <wgrant> StevenK: Can you QA your loggerhead thing?
[23:56] <wgrant> StevenK: And shouldn't that LH task be Fix Committed?