[01:19] <dmg> Hey, it appears the latest mplayer svn makes dash segfault during ./configure.  Can anyone else reproduce this?
[01:20] <dmg> My version of dash is the latest in jaunty, 0.5.4-12ubuntu2.  mplayer svn is at svn://svn.mplayerhq.hu/mplayer/trunk .
[01:20] <dmg> I'd give a backtrace, but dash is stripped.  Should I build one by hand with -g?
[01:22] <cjwatson> http://wiki.ubuntu.com/DebuggingProgramCrash has instructions for acquiring debugging symbols and getting backtraces
[01:22] <dmg> cjwatson: thanks
[01:22] <cjwatson> (i.e. yes, it's stripped, but we save the debug symbols in packages on ddebs.ubuntu.com)
[01:51] <dmg> cjwatson: looks like dash and mplayer's configure script are both wrong.
[01:52] <dmg> the configure script has a bug -- they replaced all the `` with $(...) instances, but there's a place where they had
[01:52] <dmg> `(echo foo | grep ...)`
[01:52] <dmg> that turned into $((echo ...) ...
[01:52] <cjwatson> hah
[01:52] <cjwatson> arithmetic expansion
[01:52] <dmg> and dash slurped in the entire file while parsing looking for the closing ))
[01:53] <cjwatson> I don't entirely blame dash for getting confused, although obviously it's still a bug
[01:53] <dmg> it segfaulted because parser builds stuff using alloca(), and it ran out of room.
[01:54] <ebroder> Good for them for quoting things properly, though!
[01:54] <ebroder> ...or something
[02:00] <cjwatson> indeed, the problem is obvious from http://bazaar.launchpad.net/~vcs-imports/mplayer/trunk/revision/29144
[02:01] <cjwatson> interestingly, bash manages to parse it as the author intended, although I have no idea how
[02:01] <cjwatson> it must be doing some serious lookahead to manage that
[02:07] <dmg> cjwatson: probably once it sees something that's not an arithmetic token, it gives prunes that branch of the parse tree and figures it must just be a normal command line replacement?
[02:08] <dmg> (i.e, 'echo' isn't numeric ...)
[02:09] <dmg> I'd need to go back and look at bash's grammar..
[02:21] <dmg> cjwatson: my two-line patch has been sent to the mplayer mailing list.  I suppose that's good enough.
[02:21] <dmg> Thanks for your help.
[03:36] <jdong> kees: I'm getting multiple user feedback that the udev update doesn't trigger a reboot notification. Is this intended?
[05:42] <mrooney> kirkland: just thought you might like to know that I got my sheeva plug (http://www.linuxdevices.com/news/NS9634061300.html) today and it is running jaunty server, in a 150mb footprint no less!
[05:43] <mrooney> I will hopefully be putting up a blog post soon about it, I imagine not too many people are shipping jaunty already, let alone the ARM port
[05:52] <kees> jdong: lacking it is not intended, no.  It was mentioned in the USN, though.
[05:53] <jdong> kees: ah, okay. I suppose it doesn't make much sense to spam another update to pop up a pretty bubble.
[05:53] <kees> jdong: but it's possible the packaging lacked it originally
[05:53] <jdong> yeah about 5 users told me it on separate accounts, so I'm assuming the packaging lacked it.
[05:53] <jdong> I don't think we had to replace udev very often (the binary itself) :)
[05:54] <kees> jdong: it's actually never happened before for -security.  :P
[05:54] <jdong> :)
[05:54] <jdong> I'm kind of shocked that of all the other major distros that I subscribe security notifications to, none have mentioned this yet.
[05:54] <jdong> when was this vulnerability discovered?
[05:54] <kees> jdong: last week
[05:55] <jdong> yikes
[05:55] <kees> jdong: 1700 UTC today was the coordinated release time... *shrug*
[05:55] <jdong> ah, I see
[05:55] <jdong> I suppose it looks like a one-man show for now, huh? :)
[05:55] <kees> but yeah, I'm a bit surprised, this is a pretty serious issue.  :P
[05:55] <jdong> yeah, painfully serious.
[05:55] <kees> 1700 was SUSE's recommendation, too.
[05:55] <ebroder> I'm still trying to figure out if I care enough to patch my high-use Debian machine myself while I wait for them to get their act together
[05:56] <jdong> and it's not like the SELinux profiles in RHEL do anything to stop it either. udevd_t is shockingly unconfined_domain()
[05:56] <kees> yup.  the Xen-guest SELinux-escape route is possible with this vuln too.
[05:57] <jdong> ouch, xen guests can exploit the host you mean?
[05:57] <ebroder> Wait..what?
[05:57]  * ebroder may really care now
[05:57] <kees> it was a paper that was written about a specific Xen guest-to-host vulnerability.
[05:57] <jdong> haha ebroder is gonna have a sleepless night :D
[05:57] <kees> ebroder: the Xen issue was fixed a long while ago.
[05:58] <ebroder> Oh, ok
[05:58] <jdong> ah, dan walsh wrote a reflection on that, I recall
[05:58] <jdong> i.e. it being a mistake RH didn't confine VM's in the host.
[05:59] <kees> jdong, ebroder: http://invisiblethingslab.com/pub/xenfb-adventures-10.pdf
[05:59] <kees> jdong: no, it was confined, but allowed block device access.
[06:00] <kees> anyway, same principles could be used to escape SELinux with the udev vuln.  I think, I'm not much of an selinux-escape-artist
[06:00] <jdong> mmm I see.
[06:00] <dholbach> good morning
[06:00] <jdong> currently what I see in refpolicy is that the "user_u, sysadm_u, staff_u" users do not have the ability to use netlink_socket
[06:01] <jdong> I assume that means users confined under these domains would not have then ecessary access to pull this off.
[06:01] <jdong> however, the default config is to place users in unconfined_u so this is moot.
[06:04] <bryce_> slangasek: so, evidence is piling up that switching "greedy" on is a very good thing.  There is only one data point to the negative - your firefox case
[06:05] <bryce_> slangasek: so I'm wondering how to reproduce that issue, and if we can definitively tie it to greedy, or if it might be an unrelated issue
[06:05] <slangasek> bryce_: which was informally confirmed by others on IRC last night; so we'd be trading performance for correctness...
[06:06] <slangasek> the only thing that changed to trigger the behavior was turning on greedy
[06:06] <slangasek> reproducing> i965, switch/scroll windows rapidly
[06:06] <bryce_> slangasek: was it?  I missed that discussion.
[06:07] <bryce_> slangasek: I'm on i965 and not reproducing it
[06:07] <slangasek> er, sorry - 945
[06:08] <slangasek> you'd think I'd know by now what I'm running
[06:08] <bryce_> heh
[06:08] <bryce_> what were other people on?  who else reported seeing the issue?
[06:08] <bryce_> if it's only appearing on !i965 or only i945 or whatever, maybe we can conditionalize those cases
[06:09] <slangasek> I'll check my logs
[06:13] <slangasek> bryce_: it was Lure this morning
 slangasek: I have also noticed some black areas with greedy (but not to the level that I would go back to non-greedy ;-))
[06:14] <jdong> kees: *WOW*, the Xen dude is quite an escape artist. Quite an amazing read.
[06:14] <slangasek> bryce_: did you get a fixed patch that doesn't cause insta-segv?
[06:14] <jdong> kees: by far the biggest mistake was xend_t being allowed *ALL* block devices.
[06:14] <bryce_> slangasek: no, but based on the good perf numbers we're getting I'm considering taking a shot at making one
[06:14]  * slangasek nods
[06:15] <bryce_> slangasek: I mean, if it's worth giving it a shot
[06:16] <bryce_> ideally, I'd like to have the black firefox problem out of the way though
[06:18] <maco> slangasek: wait, is it scroll in firefox quickly *or* switch between various windows, or is it switch between firefox windows? i'm confused
[06:18] <maco> ive got a 945 at home i can play with in the morning and a 965 here
[06:20] <bryce_> I also have a 945 I can upgrade and play with tomorrow I guess
[06:34] <slangasek> maco: a lot of all of the above
[06:41] <maco> slangasek: ok
[07:23] <tjaalton> sigh, this klogd hang is driving me nuts
[07:24] <tjaalton> it's not doing any remote logging, so that's not it
[07:24] <tjaalton> Keybuk: shouldn't init wait for the network to be up before it proceeds to rc2?
[07:25] <liw> tjaalton, I don't think init sets up networking, and anyway, it shouldn't wait, since it can take indefinitely long (e.g., if the dhcp server is down during boot)
[07:26] <liw> tjaalton, where does klogd hang for you?
[07:27] <tjaalton> liw: it hangs on boot if the network is not up yet (normal dhcp setup, network-manager isn't used)
[07:27] <liw> tjaalton, hmm... weird
[07:27] <tjaalton> because the dhcp server is on another network, so it might take a while to get a lease
[07:27] <tjaalton> I'll try to strace it..
[07:29] <tjaalton> ldap is used, and it tries to run it as 'klog' user.. maybe that's why it fails
[07:49] <maxb> window level all
[07:53] <tjaalton> hm, now that I messed up the klogd initscript (it didn't try to start it at all), it fails in the next initscript which is dbus
[07:54] <tjaalton> so klogd is not at fault here, that's for sure
[08:27] <tjaalton> liw: it's the mountnfs-scripts that are failing.. looks like mountnfs.sh is run even though the network is not up, and that hangs the boot
[08:28] <liw> tjaalton, that'd be a bug, yes
[08:28] <liw> the fix would be to switch to using upstart events, I'm sure :)
[08:37] <pitti> Good morning
[08:37] <seb128> hello pitti
[09:25] <slangasek> TheMuso: we're slipping in one kernel upload post-RC; one change is specific to lpia, but the other applies to anyone running ext4.  Can you sync up linux-rt and linux-ports and get them into the upload queue, so we can push that through ASAP after RC is done?
[09:31] <liw> slangasek, any chance you'd accept a further change to fix my SATA/SEMB problems? http://bugzilla.kernel.org/show_bug.cgi?id=11579 (but I haven't verified the patch yet)
[09:31] <slangasek> liw: is that a blocker for installability?
[09:32] <slangasek> oh, if the patch isn't verified yet, then the timeline probably doesn't work
[09:32] <liw> slangasek, it prevents installing on a bunch of WD SATA hard disks -- the kernel doesn't recognize them as hard disks
[09:32] <slangasek> the kernel in question is already uploaded, and needs to be accepted for building by tomorrow in order to make this work out time-wise
[09:32] <liw> ah, too bad
[09:33] <liw> I'll test the patch RSN anyway, it'd be nice to get this fixed in an SRU
[09:33] <TheMuso> slangasek: ok I'm on it, I have one bug I need to kill thats powerpc-specific as well, so this is good news, thanks.
[09:33] <liw> (although it probably requires an updated ISO image, too, hmm)
[09:34] <slangasek> liw: yeah, which would have made it useful to have in for final :/
[09:36] <TheMuso> slangasek: ...or I could if the git commits were pushed to kernel.ubuntu.com.
[09:36] <slangasek> smb_tp: ^^ linux-ports folks need those kernel commits :)
[09:37] <smb_tp> slangasek, TheMuso The patches itself are there. Just a sec I forward Tims mail with the ids
[09:38] <smb_tp> I am currently locally building that kernel to get the abi files for the merge back
[09:38] <TheMuso> smb_tp: Not really useful, as I list the exact changelog bits from mainline in the ports upload'
[09:38] <TheMuso> I could generate it however, so I'll see what I can come up with.
[09:39] <smb_tp> TheMuso, would the exported patches be ok? You could apply them with git am
[09:40] <TheMuso> smb_tp: that would be fine, means I rebase by hand, i.e no script, but thats ok.
[09:40] <TheMuso> seems the RSS for gitweb is not updating which is why I thought some of the patches weren't there.
[09:41] <pitti> smb_tp: I just updated bug 321474 to remove the v-failed/regression tags
[09:42] <pitti> smb_tp: is there a plan when to release the intrepid kernel to -updates?
[09:43] <smb_tp> pitti, Yes, I definitely wanted to go over the open stuff to see where we stand and have Intrepid and Hardy moved to updates soon
[09:44] <smb_tp> TheMuso, I created a local topic branch for that upload and have to merge it back as soon as I got the abi files. Then I'll push everything
[09:44] <smb_tp> TheMuso, Mail is away
[09:44] <TheMuso> smb_tp: thanks
[09:45] <TheMuso> smb_tp: re your email regarding intrepid ports, I'll read it again on the weekend and look into it then.
[09:45] <smb_tp> pitti, The when: is early next week ok for you or would it be better this week?
[09:46] <smb_tp> TheMuso, NP, it has been behind quite some time now. So a little longer won't hurt
[09:46] <pitti> smb_tp: I don't mind, the actual copying is trivial
[09:47] <pitti> smb_tp: I see two regression-proposed bugs: bug 337929 and bug 311716
[09:47] <pitti> smb_tp: no v-failed any more
[09:47] <pitti> if we could clarify those two, then we'd be good to go
[09:47] <pitti> smb_tp: oh, and no regressions reported against the hardy update
[09:49] <smb_tp> pitti, The regdom thingy should be somewhere. But it might be in the patches queued up. I have to check. With brightness problems I fight a bit. Trying to get info about the specific issue as all are mixed up. But from the general feeling that is not worse than the version in updates now, just not better.
[09:54] <smb_tp> pitti, Oh, right the regdom bug is for lbm. I see andy asked for feedback which seems to have arrived now. But it is not yet uploaded to proposed
[09:55] <pitti> smb_tp: ah, so it needs another lbm upload first?
[09:55] <smb_tp> pitti, yes
[09:56] <smb_tp> pitti, I put it onto my list to get done soonish.
[09:59] <smb_tp> pitti, About the inverted brightness: as it is that way on 2.6.27-11 and (maybe as I have not clear feedback) the same in proposed. Would it be ok to move proposed to upadates anyway? I even think the inversion issue should be fixed in the proposed.
[09:59] <lool> The linux-backports-modules-intrepid-generic in ship-live seems to be bogus; anybody minds if I drop it?
[10:01] <smb_tp> lool, What means bogus?
[10:01] <lool> It's not in jaunty anymore
[10:01] <lool> smb_tp: The fact that's a package not existing in jaunty is listed there seems wrong, I'm not saying tehre are bugs in the package  though :)
[10:01] <smb_tp> lool, Oh, is that the meta-package
[10:02] <lool> eagle-usb-utils isn't in jaunty either
[10:02] <lool> smb_tp: Not really, it's a task listing additional packages to install in the live CD I think
[10:03] <lool> eagle-usb-utils isn't in jaunty anymore either; looks like I could cleanup this seed
[10:03] <smb_tp> lool, I pretty much think so. The nameing with the release in it looks like that
[10:03] <smb_tp> It would then be linux-backports-modules-jaunty-generic
[10:11] <TheMuso> smb_tp: hrm ok, since you haven't also uploaded other patches that are in the jaunty tree, theres no point rebasing. I'll just use that ext4 patch fix, and do another bug fix I need to do, and that will be it.
[10:12] <lool> stgraber: Hey, we really need the ARM images added to the tracker
[10:13] <pitti> mvo: hm, should I remove the current intrepid-proposed update-manager due to lack of feedback, or do you want to test it yourself? (bug 292179)
[10:13] <smb_tp> TheMuso, that new kernel only consists of that config change in lpia and the ext4 fix (compared to the last release)
[10:13] <TheMuso> smb_tp: from there on in, any SRUs that are likely to be useful for ports can just be pulled as patches directly, no tree rebasing.
[10:13] <TheMuso> smb_tp: yes I know
[10:13] <lool> stgraber: Could you please add an entry in Ubuntu for desktop armel imx51 babbage (that's a live) and split the netboot ones with one per flavor (versatile, ixp4x, iop32x)
[10:14] <lool> stgraber: Also, UMPC needs dropping and UNR should be its own toplevel project (and server as well BTW)
[10:14] <pitti> mvo: (I'd prefer the latter, of course)
[10:14] <TheMuso> smb_tp: what I'm saying is that there are other commits in the jaunty tree that haven't been uploaded, so I don't need to rebase, and for SRUs, commits will only need to be pulled where they are applicable to ports
[10:14] <slangasek> lool: why is there any need to reorganize the products?
[10:15] <lool> slangasek: Well the current situation is inconsistent, the MID and UNR images are listed in different ways, but they are built in the same way
[10:15] <lool> slangasek: But I can understand if you prefer avoiding any reorg at this point
[10:16] <lool> stgraber: ^
[10:16] <slangasek> lool: ah, well; UNR is built from main, which also sets it apart from MID presently?
[10:16] <lool> slangasek: UNR is built from universe as well; it includes cheese for instance
[10:16] <smb_tp> TheMuso, A complete rebase would pull things not yet uploaded, yes. So it is not useful here. When we are doing sru's I guess both approaches are ok. With rebasing you get all things, but if you prefer you can cherry pick what you find applicable/useful
[10:16] <slangasek> lool: oh
[10:17] <TheMuso> smb_tp: yeah the cherry-picking will likely be what I'll do.
[10:17] <lool> slangasek: This might be a bug though, not one I expect to be fixed before release though, there are ~24 binaries from universe or so
[10:19] <smb_tp> slangasek, I just had the full test-compiles done for that proposed kernel and just saw lpia ftbs due to a missing module. I look into that and get back to you. Maybe the package I uploaded should get dropped
[10:19] <slangasek> smb_tp: ack, let me knwo
[10:21] <smb_tp> slangasek, Yeah, the problem was the change for CONFIG_PACKET from m to y. Which needs a little tweaking with the modules list
[10:21] <mvo> pitti: I can do it myself if, but probably not today
[10:22] <pitti> mvo: doesn't need to happen today, I was just wondering if it makes sense to keep it in -proposed
[10:22] <slangasek> smb_tp: rejecting this upload, please reupload at your discretion
[10:22] <smb_tp> slangasek, ok, thanks
[10:22] <pitti> mvo: especially because I assume we'll need more u-m SRUs soon
[10:22] <smb_tp> TheMuso, If you are not picking the config change for lpia, you will be ok
[10:22] <TheMuso> slangasek: mind having a quick look at bug 355344? Since another ports upload is forthcoming, I'd like to get this fixed now, rather than have to do an SRU.
[10:23] <TheMuso> smb_tp: I'm not, since lpia is not built from ports at all
[10:23] <slangasek> TheMuso: sorry, can't do it right now
[10:23] <TheMuso> slangasek: ok I subscribed ubuntu-release to it anyway
[10:24] <pitti> mvo: ubuntu-vm-builder is in a similarly sad state :(
[10:31] <mvo> pitti: ok, I put that on my list as wel
[10:32]  * pitti hugs mvo
[10:32] <pitti> I'm currently doing a cleanup round for -proposed
[10:55] <lool> mdke_: Around?
[10:55] <lool> mdke_: We'd need some help in getting the installation instructions in shape for UNR
[10:56] <lool> mdke_: We have some bits in the middle of https://wiki.ubuntu.com/UNR and some reqs on https://help.ubuntu.com/community/Installation/SystemRequirements
[11:26] <pitti> slangasek: there's a new tzdata update (http://launchpadlibrarian.net/25523792/2009e-2009f.diff) with a trivial, but urgent diff; would you rather have this as an SRU, or can I upload it to jaunty?
[11:28] <slangasek> pitti: jaunty
[11:28] <pitti> ok, thanks
[11:28] <pitti> slangasek: oh, doko uploaded a tzdata as well, I'll look at it and integrate
[11:28] <pitti> ah, installs a missing file; seems safe enough
[11:29] <pitti> doko: I reject your tzdata upload, I'll integrate it into the 2009f one
[11:32] <YokoZar> mvo: poke
[11:36] <doko> pitti: ok, thanks
[11:56] <superm1> pitti, TheMuso should have hardware that will be able to reproduce and test the package from -proposed for bug 297245
[11:56] <superm1> he's got the one system I had that could do it
[11:58] <TheMuso> superm1: I'll isntall intrepid on it tomorrow and test that.
[11:59] <superm1> TheMuso, it's actually a hardy proposed package i think in question
[11:59] <TheMuso> superm1: oh
[11:59] <TheMuso> well it will be hardy then
[11:59] <superm1> TheMuso, you don't need to install to test it, it will fail off a hardy live disk, and you can install the deb in the live mode to verify X comes back to life
[11:59] <slangasek> superm1: morning
[11:59] <TheMuso> superm1: good enough, thanks
[11:59] <TheMuso> I'll do that tomorrow and report back
[12:00] <slangasek> superm1: mesa has just been accepted; it's a .5h build, then a 1.5h wait for the publisher, then I'll reroll mythbuntu
[12:00] <superm1> slangasek, g'morning.  dog kept waking me up all night, so i figured i might as well stay up :)
[12:00] <pitti> Keybuk: for bug 283316, is "sudo udevadm monitor --udev" really the correct thing to debug the udev rules? I only get some "change" event on the USB host, not the actual rules processing (the tracks/vol_id detection is probably the part which causes this)
[12:00] <slangasek> superm1: heh
[12:00] <superm1> slangasek, sounds good.
[12:00] <superm1> TheMuso, thanks
[12:00] <slangasek> superm1: testing resources will be available around then?
[12:01] <superm1> slangasek, i'll be able to, not so sure anyone else is up yet though
[12:01] <slangasek> superm1: well, that gives them another 3h to wake up :)
[12:02] <slangasek> superm1: you and fader seem to have been the main testers, anyway
[12:03] <superm1> slangasek, yeah at least for those that report it.  there's a handful of people that we've been getting testing dailies and reporting whether things are broke for their situations, but can't seem to get them reporting to the iso tracker yet
[12:03] <slangasek> heh, ok
[12:07] <TheMuso> slangasek: BTW I won't be able to get linux-rt sorted until a new linux-source package is in the archive, since that doesn't currently use a git repo, and build deps on the linux-source-2.6.28 package to build
[12:08] <slangasek> ok
[12:21] <wubbbi> Any Packagebuild or bugfixes needed here?
[12:21] <mvo> YokoZar: /poke
[12:21] <YokoZar> hi
[12:21] <pitti> Keybuk: nevermind, --environment was missing
[12:28] <YokoZar> So I've seen quite a few changes for the kernel set as "fix committed" - is a new kernel gonna roll out for the release candidate?
[12:33] <slangasek> no
[12:42] <ogra> slangasek, so one time back to the ltsp change ... formerly the amd64 server + i386 client installations didnt have to touch dhcpd.conf, while they had to rebuild their chroots for i386 the conffile was preconfigured for i386 and didnt have to be touched ...
[12:43] <ogra> slangasek, as i understand conffiles the change in the package will quietly replace the existing dhcpd.conf for these users
[12:43] <ogra> (on upgrades)
[12:43] <ogra> which means their clients will silently stop booting
[12:47] <slangasek> ogra: conffiles> correct; the flipside seems to be that amd64-on-amd64 is the only thing you can actually configure out-of-the-box right now, and that common case fails?
[12:47] <slangasek> dholbach: could you elaborate on why you consider bug #361765 a bug?  AFAICS, the task still exists
[12:47] <ogra> right, but doe sthat justify to break all existing amd64->i386 setups (which is a huge amount imho)
[12:48] <slangasek> ogra: discuss that with stgraber?
[12:48] <ogra> i did, i just wanted a second opinion
[12:49] <ogra> the problem is known since breezy and since we didnt have a proper solution we kept it the way it was until tonight
[12:49] <slangasek> ah
[12:49] <dholbach> slangasek: I think it's just the term
[12:49] <ogra> i'd rather perfer to work out a proper solution than breaking it for many people on RC day
[12:50] <davmor2> ogra: I don't think the fix has gone in yet has it slangasek?
[12:50] <slangasek> ogra: then that's a good argument for rejecting it, but I would like you to come to an agreement with stgraber instead of me being a mediator for that
[12:50] <slangasek> dholbach: i.e., "edubuntu" vs. "Ubuntu Education Edition"?
[12:50] <ogra> yes, he will come here once he is online again (he is commuting atm)
[12:50] <dholbach> slangasek: yes
[12:50] <ogra> davmor2, nope
[12:51] <ogra> davmor2, its waiting for the freeze to fall, thats why i brought it up
[12:51] <davmor2> ogra: Okay.
[12:51] <ogra> dholbach, the dvd installs edubuntu-desktop
[12:51] <slangasek> dholbach: ok, makes sense
[12:51] <ogra> as a package/task
[12:52] <ogra> and by the definition RichEd set up "Ubuntu Education Edition" != edubuntu
[12:53] <ogra> (though dont ask me what "Ubuntu Education Edition" is actually after his definition :) )
[12:53] <ogra> but the two are very distinct on all websites so you need to update these as well
[12:54] <slangasek> hrm?
[12:54] <slangasek> I have no idea what definition that is.  As far as I was ever told, Ubuntu Education Edition was a new name for edubuntu.
[12:55] <ogra> http://www.ubuntu.com/education was referring to edubuntu as a distro ... www.edubuntu.org was referring to ubuntu in education as something different from edubuntu
[12:55]  * ogra checks if that was fixed/changed already
[12:56] <ogra> edubuntu is still in the menu on ubuntu.com but apparently the text referring to it was removed now
[12:57] <ogra> there is still http://www.ubuntu.com/products/WhatIsUbuntu/edubuntu though
[12:57] <ogra> that should point to http://www.ubuntu.com/education
[12:57] <dholbach> ogra: https://bugs.launchpad.net/ubuntu-website/+filebug :)
[12:58] <ogra> slangasek, the prob is that the actual strategy was never made clear to anyone by rich so there is a lot confusion
[12:59] <ogra> dholbach, i'm not doing edu stuff and am busy up to my ears in arm, can you file it ?
[12:59] <dholbach> ogra: I don't know much about the edubuntu situation, just noticed it during the installation
[13:00] <ogra> (that should really be discussed with LaserJock rather)
[13:01] <ogra> dholbach, the transition rich had to do is only half way done, i have no idea who has taken over his role but if we change it on the DVD it should be changed everywhere for a professional look
[13:01] <dholbach> ogra: I'm not sure we'll find the right answer here in #ubuntu-devel
[13:02] <ogra> no idea
[13:02] <ogra> i dont mind if it stays as is, just pointing out the overall inconsistency
[13:08] <liw> is the queue with uploaded packages that aren't entering the archive due to the freeze visible somewhere?
[13:09] <slangasek> https://launchpad.net/ubuntu/jaunty/+queue?queue_state=1
[13:09] <soren> liw: http://launchpad.net/ubuntu/jaunty/+queue
[13:09] <soren> ...and choose "Unapproved"
[13:10] <liw> thanks
[13:10] <soren> Or save slangasek's link if you're the bookmarking sort of person.
[13:10] <soren> :)
[13:10] <liw> I'd like to save the bookmark where I can easily find out such things :)
[13:11] <soren> It's called #ubuntu-devel :)
[13:11] <soren> You may have heard of it.
[13:11] <soren> :p
[13:12] <slangasek> irc://chat.freenode.net/%23ubuntu-devel
[13:12] <geser> it's part of the secret knowledge passed on from one developer generation to the next one :)
[13:13] <liw> I'm not sure oral history is the best way to document things
[13:13] <liw> but I'll ask more things again :)
[13:14] <geser> I don't know how well google has indexed http://irclogs.ubuntu.com/
[13:14] <ScottK> wget and grep work though.
[13:14] <directhex> wgrep!
[13:23] <vlada_> hi
[13:24] <vlada_> can someone help me set up development environment the easiest way?
[13:24] <vlada_> I need boost package. Is it called libboost in ubuntu?
[13:27] <Pici> apt-cache search boost
[13:29] <vlada_> ah, thanks
[13:30] <vlada_> I've found one package with version number attached after libboost.
[13:30] <vlada_> Is it advised to call that one, or should I proceed with libboost-dev only?
[13:33] <ScottK> vlada_: It depends on what version you want.
[13:34] <directhex> vlada_, generally, version numbers in package names refer to ABI versions, versionless -dev packages pull in the most recent headers corresponding to the most recent API/ABI in the archive
[13:38] <ScottK> directhex: Generally, yes, but not in the case of boost
[13:39] <ScottK> vlada_: ^^
[13:53] <mdz> lool: regarding bug 362071, are we actually using lpia for any alternate ISOs?
[13:54] <cjwatson> mdz: I filed it after getting a bug report from a user who was doing so.
[13:54] <cjwatson> mdz: actually, I think they were using a netboot image
[13:54] <cjwatson> nevertheless, http://cdimage.ubuntu.com/ports/daily/current/jaunty-alternate-lpia.iso exists
[13:54] <mdz> cjwatson: is it being considered RC?
[13:55] <lool> mdz: A bunch of people seem to be trying to install Ubuntu flavours with the lpia arch via the alternate images
[13:55] <lool> mdz: I guess they think lpia is best for their atom or whatever
[13:55] <cjwatson> mdz: not quite, but there was an ext4 bug that we wanted to fix anyway
[13:55] <cjwatson> mdz: (Medium bugs aren't RC)
[13:56] <cjwatson> I discussed it with slangasek last night
[13:57] <slangasek> not publishing the alternate is also an option, if the kernel update is considered untenable; but the ext4 issues are fairly high-profile as well, and the delta is very manageable here
[14:07] <pitti> meh, svn.debian.org/wsvn is just about the worst svn browser I've ever seen
[14:07] <pitti> I just want to look at a file...
[14:08] <azeem> pitti: heh, I feel your pain
[14:08] <directhex> they updated wsvn to a version which can't browse source
[14:08] <directhex> use viewvc
[14:08] <slangasek> superm1, fader_: mythbuntu build going now
[14:08] <fader_> slangasek: Thanks
[14:08] <cheleo> is the rc to be released today?
[14:16] <vlada_> thank you all
[14:16] <vlada_> I have another strange problem
[14:16] <vlada_> cmake generates this message:
[14:16] <vlada_> -- The CXX compiler identification is unknown
[14:16] <vlada_> CMake Error: your CXX compiler: "CMAKE_CXX_COMPILER-NOTFOUND" was not found.   Please set CMAKE_CXX_COMPILER to a valid compiler path or name.
[14:17] <vlada_> every other pagkage seems to recoganized
[14:30] <dholbach> slangasek: do you think bug 334657 is release-critical?
[14:32] <slangasek> dholbach: is it really only VBGR/VRGB that are affected?  That seems like a blatant configuration error, then?
[14:33] <dholbach> slangasek: I have no idea - ccm (in #ubuntu-bugs) told me about it and asked how to get more attention to it
[14:33] <slangasek> (you don't use the vertical subpixel settings unless your pixels are laid out vertically; which for most people they aren't0
[14:33] <dholbach> seb128, Riddell: any idea about bug 334657?
[14:34] <seb128> dholbach: why would I have any idea about qt?
[14:34] <seb128> no
[14:34] <seb128> I've no clue about fontconfig, fonts or qt
[14:36] <ccm> hi there
[14:38] <dholbach> ccm: slangasek asked: "is it really only VBGR/VRGB that are affected?  That seems like a blatant configuration error, then?"
[14:39] <ccm> dholbach: in my tests it is and all users seemed to report so
[14:40] <ccm> dholbach: it happened directly after an upgrade to jaunty for me
[14:41] <slangasek> ccm: why did you have VRGB set?
[14:41] <slangasek> that's not a default, and it's not the subpixel orientation that most users have
[14:45] <ccm> slangasek: actually that was a result of lcd (laptop) display tuning for getting better font results - as it is quite easy to reach this menu in ubuntu and you dont even need admin rights for it, i think a bunch people tested it
[14:45] <ccm> slangasek: and might still have turned it on as it had no negative side effect
[14:46] <slangasek> well, it's still a misconfiguration if you click a setting that doesn't actually match your subpixel layout, and if it looked good at all that was an unintended side-effect in the first place
[14:47] <slangasek> so I don't see that this is a critical bug
[14:47] <slangasek> superm1, fader_: mythbuntu 20090416 up
[14:47] <fader_> slangasek: Thanks, I'll start grabbing it
[14:48] <slangasek> superm1, fader_: can you give an estimate of how long it'll take to get the tests covered?
[14:48] <fader_> slangasek: I think I can get the i386 ones done in 1-1.5h once I have it downloaded
[14:49] <slangasek> fader_: how long's the download take? :)
[14:49] <fader_> slangasek: I'll let you know in just a moment :)
[14:49] <slangasek> ok
[14:51] <fader_> slangasek: rsync says about 15 minutes for the download
[14:51] <slangasek> cool
[14:52] <ccm> slangasek: well actually vrgb is broken now. that means at least it will hit users who intentionally configured it for rotated displays and those who turned it on by chance. so the question seems more if it might have impact to a remarkable amount of users after release - be it by misconfiguration or intention, in fact both will be presented unusuble qt applications and might have no clue at all on how to fix it
[14:53] <Keybuk> fbond: what would you like to know?
[14:54] <slangasek> ccm: can you give me a simple test case with which to reproduce the bug, given that I'm running Ubuntu with no Qt apps currently installed?
[14:55] <fbond> Keybuk: Can you point me to docs in the wiki?
[14:55] <Keybuk> fbond: what are you trying to do?
[14:55] <fbond> I want to force r8168 to be loaded before r8169.
[14:55] <Keybuk> fbond: there is no r8168 driver
[14:55] <fbond> Oh, crap, that's right.  This system is actually Debian.  Sorry.
[14:56] <Keybuk> fbond: off to #debian with you then ;)
[14:56] <ccm> slangasek: I assume no
[14:56] <fbond> Keybuk: sorry about that.  I forgot that I sometimes am on machines that *aren't* running Ubuntu.
[14:56] <slangasek> ccm: hmm?
[14:56] <cody-somerville> Its okay fbond. I make that mistake *all* the time.
[14:56] <ccm> slangasek: at least "qtconfig" is enough as a test application
[14:56] <cody-somerville> :P
[14:56] <tjaalton> Keybuk: network is started up both by udev and init, but why?
[14:56] <Keybuk> fbond: though in general, first check whether your device is supported by the other driver (modinfo r8168)
[14:56] <slangasek> ccm: ok, grabbing
[14:56] <pitti> fbond: curiously, I sometimes forget that there are machines out there which aren't running Linux.. :)
[14:56] <Keybuk> tjaalton: physical devices are started by udev, logical devices by init
[14:57] <slangasek> ccm: in any case, even if the conclusion is that Qt is Really Broken, this is likely to be a matter for an SRU rather than an emergency pre-release fix
[14:58] <fbond> Keybuk: I'm bugging people in #debian now, but in this case r8168 and r8169 both support the chip in question, but r8169 is buggy on it while r8168 works fine.
[14:58] <fbond> Keybuk: Meanwhile, the *other* chip on the system requires r8169.
[14:58] <ccm> slangasek: then go you to you display settings and enale "lcd" mode and "vrgb" (while no qt app is running)
[14:58] <ccm> slangasek: then start qtconfig
[14:58] <tjaalton> Keybuk: well, ifup -a is run twice here, since /e/n/interfaces has eth0
[14:58] <slangasek> augh, just turning on VRGB hurts my eyes
[14:58] <Keybuk> fbond: ah, then you need both 8168 and 8169 loaded
[14:59] <tjaalton> at least the services in if-up.d are run twice
[14:59] <Keybuk> tjaalton: ifup -a should only be run once
[14:59] <Keybuk> tjaalton: udev does not run it, it will run ifup eth0
[14:59] <Keybuk> fbond: in that case, you're going to have to poke things in /sys/bus/pci/drivers/r8169 and 8168
[15:00] <tjaalton> Keybuk: right, true.. but the services are restarted
[15:00] <Keybuk> tjaalton: shouldn't be
[15:00] <Keybuk> tjaalton: if the device is up, it won't be run again
[15:00] <slangasek> ccm: I cannot say with certainty that what qt is doing there is actually wrong for true VRGB
[15:00] <tjaalton> nfs-common is run three times here (obviously a bug, it shouldn't do that in rc2/S20)
[15:00] <slangasek> wait, yes I can, I can rotate my output :)
[15:00] <Keybuk> tjaalton: are you sure they're not just getting run again because you don't actually check multiple devices?
[15:00] <Keybuk> tjaalton: they'll be run for "ifup lo" *and* "ifup eth0" remember
[15:01] <ccm> slangasek: well qtconfig looks unusable, right? in all display directions
[15:01] <fbond> Keybuk: That seems ... unreasonable.
[15:01] <Keybuk> fbond: why?
[15:02] <fbond> Keybuk: Well, I just can't help but feel that I have to know an awful lot of implementation details to do something that seems pretty simple.
[15:02] <fbond> Keybuk: Between udev/modprobe/sysfs ...
[15:02] <Keybuk> fbond: changing drivers is not supposed to be "simple"
[15:02] <Keybuk> you're not supposed to need to worry about it at all
[15:02] <fbond> Keybuk: Oh, well that's true.
[15:02] <fbond> Keybuk: Any docs on the particular pokings that need to occur?
[15:02] <slangasek> ccm: ah, yes, it's still unusable when I rotate my monitor (and not just because it makes my neck hurt)
[15:03] <tjaalton> Keybuk: ah, excellent..
[15:03] <Keybuk> fbond: there's lots of documentation, e.g. in the kernel source
[15:03] <Keybuk> tjaalton: there's a reason we don't start services in that directory ;)
[15:03] <slangasek> ccm: so it's certainly a valid bug, but we certainly can't commit to fixing this before release when there's no known fix yet
[15:04] <tjaalton> Keybuk: hmm, you mean the ones in if-up.d shouldn't be run?
[15:04] <fbond> Keybuk: Would it be unreasonable to, e.g., blacklist both r8168 and r8169 and then put both in /etc/modules?
[15:04] <ccm> slangasek: okay then. If that does not fit into release critical thats fine for me. I just wanted to bring this up to somebody who can say so as it did not get any attention so far and I wanted to prevent that it just got overseeing.
[15:04] <Keybuk> fbond: wouldn't make any difference
[15:04] <ccm> slangasek: thank you for the taking the time
[15:05] <Keybuk> fbond: both would load, and the existing rules for binding would still take place
[15:05] <slangasek> ccm: no problem :)
[15:05] <ccm> dholbach: and thank you for getting me in contact :)
[15:05] <Keybuk> tjaalton: they're not services usually, they're tasks
[15:05] <dholbach>  ccmno worries
[15:05] <dholbach> ccm: no worries :)
[15:05] <Keybuk> tjaalton: ie. they poke or prod or do something when a network device comes up
[15:05] <Keybuk> tjaalton: we don't start/stop services based on the presence or not of network devices
[15:06] <Keybuk> fbond: the kernel makes the decision which driver gets which device
[15:06] <fbond> Keybuk: Things currently work if I rmmod both, modprobe r8168, and then modprobe r8169.  I was under the impression that drivers "claim" devices.
[15:06] <Keybuk> fbond: ah, that's more interesting then - yes you can force that
[15:06] <Keybuk> though that should be forceable with a tweak to modules.order
[15:07] <fbond> Keybuk: Ah, perfect.  Let me read about that.
[15:07] <Keybuk> ie. edit /lib/modules/$(uname -r)/modules.order and make sure r8168 is before r8169
[15:07] <Keybuk> (assuming both claim your device, that will make 8168 "win")
[15:07] <fbond> Keybuk: If depmod gets run will my changes be overwritten?
[15:08] <Keybuk> fbond: no, only a kernel upgrade would overwrite your changes
[15:08] <Keybuk> use dpkg-divert to prevent that
[15:08] <fbond> Keybuk: Great, thanks for your help.
[15:08] <fbond> I'm still hoping that one day I will understand udev, modprobe, and kernel interactions.  But I think it would take a few days of reading.
[15:09] <Keybuk> fbond: there's good books on it which are only slightly out of date <g>
[15:10] <fbond> Keybuk: You're pulling my leg, right?  Does such a book truly exist?
[15:11] <Keybuk> fbond: "Linux Device Drivers" by Greg Kroah-Hartman
[15:11] <fbond> Keybuk: Oh, I have an old old copy of that, I think.
[15:12] <tjaalton> Keybuk: yes, figured as much. maybe I just need to hack around the mountnfs issues for now, and make sure this works properly when sysv-initscripts are replaced by upstart events ;)
[15:12] <Keybuk> tjaalton: karmic, hopefully
[15:12] <tjaalton> Keybuk: yeah, looking at the specs
[15:12] <Keybuk> fbond: http://lwn.net/Kernel/LDD3/ is the current edition
[15:13] <Keybuk> fbond: ch.14 is the relevant one, though there are improvements there that the book misses
[15:13] <fbond> Keybuk: I think I bought my copy about 5 years ago.  I'll have a look at the recent edition.
[15:13] <Keybuk> fbond: LWN is an excellent resource for catching up on the changes since
[15:15] <fbond> Keybuk: Okay, thanks again.
[15:16] <Keybuk> (in summary, rather than all the _PRODUCT, _ID, etc. nonsense, the kernel now exports a single MODALIAS string that describes the device uniquely
[15:16] <Keybuk>  and modules have aliases that wild-card match these strings
[15:16] <Keybuk>  so if we do 'modprobe $MODALIAS' we get whatever module(s) think they can support that card)
[15:17] <slangasek> superm1: ping?
[15:18] <tkamppeter> pitti, hi
[15:19] <slangasek> fader_: hmm, I forgot that I'd already neutered the sync-mirror script - you don't actually have mythbuntu 20090416 yet
[15:19] <slangasek> (because I failed to fully publish it)
[15:19] <fader_> Ah, heh... okay, I'll stop testing :)
[15:19] <slangasek> publishing now
[15:19] <fader_> Should I just grab it from cdimages via http?
[15:20] <slangasek> fader_: whichever way you'd like to grab it - just make sure you're grabbing the 20090416 serial
[15:20] <fader_> slangasek: roger that... I'll just grab it via http
[15:21] <pitti> hey tkamppeter, how are you? had a good travel back?
[15:23] <tkamppeter> Yes, and I have a new SRU, for Jaunty and for Intrepid, bug 357732
[15:23] <tkamppeter> The patch is small, perhaps the Jaunty version can directly get in after the RC.
[15:27] <azeem> W31
[15:27] <azeem> bah, sorry
[15:30] <pitti> tkamppeter: should rather become an SRU
[15:35] <tkamppeter> pitti, uploaded to Debian BZR of CUPS
[15:36] <pitti> tkamppeter: ok, thanks
[15:36] <tkamppeter> pitti, how to proceed for the Jaunty SRU?
[15:37] <pitti> tkamppeter: we should create a jaunty branch anyway
[15:38] <tkamppeter> pitti, also uploaded upstrream now.
[15:39] <pitti> tkamppeter: "uploaded"?
[15:39] <tkamppeter> Upstream is http://www.openprinting.org/download/printing/pdf-printing/
[15:40] <pitti> ah, that part :)
[15:40] <tkamppeter> pitti, you thought that upstream is Debian?
[15:40] <pitti> tkamppeter: no, I thought that you got cups upstream commit rights now
[15:49] <vlada_> can somebody tell me how can I get c++ executable
[15:50] <vlada_> gcc is already installed?
[15:50] <directhex> gcc is a C compiler
[15:50] <vlada_> -? +!
[15:50] <directhex> g++ is for c++
[15:50] <directhex> install build-essential.
[15:50] <vlada_> didrocks: thanks
[15:51] <vlada_> I've never thought these could be separate packages
[15:56] <superm1> slangasek, pong
[15:56] <slangasek> superm1: hi, mythbuntu images are up and waiting :)
[15:56] <superm1> okay cool thanks
[15:57] <fader_> superm1: I'm testing the i386 ones atm
[15:58] <fader_> (Just FYI)
[15:58] <superm1> fader_, cool, i'll grab amd64 then
[15:58] <superm1> i've got amd64 hardware that failed that open luckily enough
[15:58] <fader_> Works out well then :)
[16:15] <tkamppeter> pitti, bug 357732 is prepared for a Jaunty SRU. An Intrepid SRU is not needed (here the bug does not occur).
[16:16] <pitti> tkamppeter: thanks, this will be a good reminder
[16:16] <tkamppeter> bug 357732
[16:17] <evand2> seb128: Do you have any suggestions for a workaround for bug 361112?  I'm convinced it's a GTK/metacity bug as we definitely call set_transient_for.
[16:18] <seb128> evand2: better to ask mvo about wm issues
[16:18] <evand2> sure thing.  mvo ^
[16:34] <mvo> evand: looking now
[16:34] <evand> thanks!
[16:37]  * jtholmes is away: for about 3 hours
[16:48] <mvo> evand: could you please try http://paste.ubuntu.com/152178/ ?
[16:50] <evand> will do
[16:50] <mvo> evand: I will be away for a bit for dinner but I will read backlog
[16:51] <evand> ok
[16:55] <evand> mvo: no such luck
[16:59] <Keybuk> liw: Matrix Keysigning Party?
[16:59] <Keybuk> we all wear PVC, Bondage Gear, Sunglasses and come with large guns?
[17:02] <jdong> now THAT'S a keysigning party :)
[17:07] <jdong> WHOOO I GOT video-intel TO HANG AGAIN!!
[17:07] <jdong> compiz's fade-in animation for the Firefox awesomebar did it in this time.
[17:07] <Keybuk> jdong: there's no prize for that, you know? :)
[17:08] <jdong> Keybuk: so that's why I'm not filthy rich yet :)
[17:08] <Keybuk> getting video-intel to not hang is where the prize is at
[17:09] <jdong> now that's no fun.
[17:10] <ogra> jdong, well, at least it hangs for you ... for me it does that:
[17:10] <ogra> Swap:      4803392    4352308     451084
[17:10] <jdong> awesome
[17:10] <jdong> does it put itself out of misery soon thereafter?
[17:10] <ogra> until i hit OOM at some point and the whole machine hangs
[17:10] <jdong> aww.
[17:11] <ogra> though i'm adventurous and use UXA
[17:11] <jdong> apart from hanging after 30 minutes of use, 90% probability of crash-after-resume is my other problem.
[17:11] <jdong> this is under UXA
[17:11] <jdong> EXA has completely stopped working for me in Jaunty
[17:11] <jdong> (when compiz attempts to launch I get a GPU lockup)
[17:11] <ogra> works here just not fast
[17:12] <Keybuk> UXA is full of lock-up bugs
[17:12] <Keybuk> really no prizes there
[17:12] <ogra> yeah
[17:12] <ogra> but i somehow got used to see xchat through my terminal windows while working
[17:12] <ogra> no UXA no compiz for me
[17:22] <slangasek> superm1: how's it looking for you?
[17:24] <fader_> slangasek: Sticking my $0.02 in, i386 looked great
[17:26] <superm1> slangasek, not sure yet.  my download took awhile, so i'm just testing now
[17:26] <slangasek> ok
[17:26] <superm1> fader_, what graphics hardware did you test with?
[17:29] <superm1> fader_, not sure if you saw with your disconnect; what graphics hardware did you test with?
[17:29] <fader_> I tested in virtualbox... not sure what it emulates
[17:30] <superm1> vesa
[17:30] <superm1> and mythtv-setup was fine for the last step correct?
[17:30] <fader_> superm1: Correct... I didn't see any problems in any of the setup screens
[17:31] <superm1> fader_, okay cool; good
[17:49] <pitti> tkamppeter: I thought bug 357732 wasn't needed for intrepid? You requested an intrepid task; also, the jaunty task is needsinfo, is it still waiting on something?
[17:53] <fbond> Keybuk: FWIW, blacklist r8168, blacklist r8169, and putting r8168, r8169 in /etc/modules does do the trick.  initramfs needs to be regenerated, of course, and your root fs can't be on a network filesystem.
[17:53] <fbond> Keybuk: modules.order doesn't seem to be used/present on any systems I have available here, BTW.
[17:54] <fbond> Keybuk: (but I didn't look that hard)
[17:54] <superm1> slangasek, i'm having a hard time authenticating with iso tracker for some reason (getting 403 errors), but the test turned out mostly right.  the bug we were trying to fix is fixed, but it uncovered another (in ubiquity) that is lower priority.  so i'd say push rc, and i'll have the ubiquity bug fixed for final
[17:54] <Keybuk> fbond: ok
[17:54] <slangasek> superm1: ok, thanks
[18:03] <pitti> lool: notify-osd bzr branch has two uploads which aren't in jaunty; and the second is unreleased
[18:06] <pitti> lool: the second one has major changes, I hope you didn't intend them to go into jaunty?
[18:06] <lool> pitti: The first is in the queue
[18:06] <lool> pitti: the second is just in progress stuff not worth an upload
[18:06] <pitti> lool: ok, that's for karmic then; I'll branch off a jaunty branch and commit the stuff DX asked for for jaunty
[18:07] <lool> pitti: The changes are trivial, but they might show a big diff; happy to defer to karmic
[18:08] <tkamppeter> pitti, I have updated bug 357732 now. I have requested the Jaunty and Intrepid tasks before I found out that the bug is not present in Intrepid. The Intrepid task I have set Invalid now. I have also set the CUPS/Jaunty task to "In progress" now as the reporter has done the requested tests and the fix is uploaded upstream and commited to Debian.
[18:25] <kees> pitti: hi, I have a friend experiencing the volume-notification part of bug 338837, but he's running notify-osd past 0.9.5 which supposedly fixed it
[19:00] <kees> does anyone have a T60 that can reproduce this: 362463 ?
[19:02] <Pici> bug 362463
[19:04] <bryce> pitti, slangasek:  https://wiki.debian.org/XStrikeForce/InputHotplugGuide
[19:08] <Pici> kees: I can reproduce that here.
[19:08] <chrisccoulson> Pici - you see anything on the session bus?
[19:10] <Pici> chrisccoulson: dbus-monitor? No. I get activity for changing the brightness, but not from volume changes/mutes.
[19:10] <chrisccoulson> i'd be tempted to reassign that to gnome-settings-daemon then
[19:10] <chrisccoulson> it's not a notify-osd bug if there is no messages being sent to it
[19:15] <kees> chrisccoulson: what's the method for debugging this?
[19:15] <kees> Pici, chrisccoulson: dmandell is the filer of 362463
[19:16] <kees> dmandell: can you run "dbus-monitor" and see if you get messages for volume changes?
[19:16] <kees> dmandell: Pici was not seeing dbus notifications, so it seems like this is a lower regression than just notify-osd
[19:17] <pitti> kees: can you please follow up in the bug and talk to MacSlow about it?
[19:17] <dmandell> Sure
[19:18] <kees> pitti: sure, though I'd like to have more specific details.
[19:18] <pitti> bryce: want me to do anything with that guide? (ECONTEXT)
[19:19] <dmandell> No messages when I change my volume.
[19:19] <kees> dmandell: okay, cool.  can you add that detail to the bug report?
[19:19] <dmandell> Yup.
[19:19] <kees> chrisccoulson, pitti: what is actually responsible for sending those dbus messages?
[19:19] <bryce> pitti: nope, just reference
[19:20] <pitti> kees: that's done by libnotify1
[19:20] <pitti> kees: programs usually link to that, and this converts the libnotify API calls to d-bus messages, which notification-daemon or notify-osd pick up
[19:21] <pitti> kees: but I doubt that there's a problem with the dbus side
[19:21] <pitti> I guess it just fails to draw the bubbles
[19:21]  * pitti -> dinner
[19:22] <kees> the drawing works, but the app linked to libnotify1 isn't sending... but I don't know what app that is on a T60.  :)
[19:24] <pitti> kees: oh, I see; that's an app problem then, and dbus-monitor should show whether it's actually sending the calls
[19:26] <kees> pitti: right, I just don't know how the button-press maps all the way into dbus.
[19:26] <kees> pitti: and it's clearly HW specific.  2 T60 people see it, and I don't.
[19:26] <kees> pitti: and their volume buttons actually function.
[19:27] <ebroder> kees: Should I add openafs-client.NEWS entries to all of the debdiffs for bug 356861?
[19:27] <kees> ebroder: we tend not to, but you can if you want.  :)
[19:27] <kees> tedg: ah-ha, there you are.  trying to track down the root cause of bug 362463
[19:28] <ebroder> kees: *nods* Ok. Since the intrepid one is the only one that needs changing, I'll pull it from there for consistency :)
[19:28] <ebroder> Hmm...actually, I take that back. I think I do want them in there so people know you need to upgrade the kernel modules
[19:29] <tedg> kees: My guess would be gsd would be the next place to look.
[19:29] <tedg> kees: The person to ask about that is davidbarth, who doesn't seem to be in this channel.
[19:29] <tedg> kees: #ayatana
[19:29] <kees> tedg: what can dmandell do to diagnose that?
[19:30] <kees> tedg: he's not in #ayatana either :(
[19:30] <tedg> kees: Hmph.  There goes passing it off :)
[19:34] <kees> tedg: any ideas on how to diagnose gnome-settings-daemon ?
[19:34] <hyperair> add some fprintf hooks in it
[19:34] <hyperair> =p
[19:34] <tedg> bratsche: The bug we're talking about is bug 362463
[19:34] <tedg> kees: No, not really :(  I'm hoping that bratsche does :)
[19:34] <kees> tedg: could debian/patches/16_use_synchronous_notifications.patch have done it?
[19:35] <bratsche> I'll take a look.
[19:35] <kees> tedg: that's the only thing that seems to touch notifications recently.
[19:35] <kees> bratsche: cool, thanks
[19:35] <tedg> kees: Well, that should make them work at all.  So it should have to be there.
[19:35] <kees> heh
[19:35] <tedg> kees: It may have changed though, and that might be the issue.
[19:36] <bratsche> kees: You know, I think this may have been removed deliberately because some people (including myself and dobey) were complaining that it's annoying to hit the "volume up" button and then see a notification that basically says "you just hit the volume up button, as you thought you did."
[19:37] <kees> bratsche: but this still happens for me on my machine.
[19:37] <kees> bratsche: i.e. it's specific to the T60 or something.  also, I thought that was the point of those notifications?
[19:37] <kees> bratsche: it gives you an indication of where you are on the spectrum of volume, min, max, etc
[19:38] <kees> bratsche: I would imagine mpt would freak out if volume-change-notifications were _removed_.  :P
[19:38] <bratsche> I just tested, and when I do volume up key.. I get the volume progress bar kind of notification.. but I no longer get the one that just says "you hit the volume up button" or whatever.
[19:39] <bratsche> Let me go test on my Thinkpad.
[19:39] <kees> bratsche: right, we're debugging a total lack of the progress bar notification.
[19:39] <bratsche> Ah, I see.
[19:39] <bratsche> Okay hang on.
[19:39] <bratsche> I misunderstood.
[19:39] <kees> np :)
[19:39] <bratsche> I'm getting the progressbar notification on my T61
[19:39] <bratsche> Let me update and make sure I'm on the latest package.
[19:41] <kees> bratsche: dmandell (and Pici) are seeing the problem, so anything you can have them do to help diagnose would rock (if you can reproduce it yourself).
[19:42] <a|wen-> pitti: ping
[19:43] <bratsche> I'm updating now.
[19:49] <dmandell> top
[19:53] <bratsche> kees: I just did an update and restarted my T61 and the volume progress notification is still working for me.
[19:53] <kees> bratsche: okay, please work with dmandell, he's the one seeing the issue.  :)
[19:54] <kees> heya mneptok
[19:54] <mneptok> kees: ahoyhoy!
[19:54] <mneptok> kees: you going to be in town around the middle of June?
[19:54] <mneptok> (PDX)
[19:54] <dmandell> bratsche: Anything I should do to debug?
[19:55] <kees> mneptok: I think so, yes, drop me a line.  :)
[19:55] <bratsche> dmandell: I'm not familiar with this code yet.  Let me take a look in it.
[19:55] <dmandell> Ok.
[19:55] <bratsche> dbarth did the gsd patches I think, but he's not around right now.
[19:56] <bratsche> dmandell: You're up-to-date right?  And you reset after your last update?
[19:56] <mneptok> kees: roger roger
[19:58] <dmandell> bratsche: I updated yesterday to see if the problem had been fixed, rebooted after the update.
[19:58] <bratsche> Okay, just checking.
[19:59] <dmandell> I can do it today to rule that out as a problem.
[19:59] <bratsche> I'm looking through the code, but I'm not really sure what to be looking for yet.  I should talk to dbarth probably since he's more familiar with it.
[20:08] <pitti> kees: oh, it's about the volume buttons?
[20:08] <pitti> kees: the path is roughly like this:
[20:09] <pitti> kees: keypress -> kernel -> evdev event KEY_VOLUMEUP -> X.org -> X.org key Event XF86VolumeUp -> gnome-settings-daemon -> call libnotify to produce volume up notification -> dbus -> notify-osd picks it up and draws bubble
[20:09] <pitti> a|wen-: hi
[20:09] <sbeattie> pitti: where does the actual sound volume adjustment occur in that pipeline?
[20:10] <pitti> sbeattie: that's also g-s-d, triggering the mixer when it receives the keypress
[20:11] <sbeattie> pitti: cool, thanks.
[20:11] <a|wen-> pitti: i was just in a longer discussion in #ubuntu-modu about the sru policy https://wiki.ubuntu.com/StableReleaseUpdates ... motu-sru would like to give the ack before upload, and afaik for main uploading before ack is ok?
[20:12] <pitti> sbeattie, kees: if you strace -p `pidof gnome-settings-daemon` and press the button, you should see some open("/dev/snd/controlC0", O_RDWR) fiddling
[20:13] <pitti> and in dbus-monitor there should be something like http://paste.ubuntu.com/152308/
[20:13] <pitti> i. e. g-s-d sending to dest=org.freedesktop.Notifications the notification-audio-volume-high message
[20:14] <pitti> a|wen-: right; it's much easier (and rare) to reject something from the queue than to have the uploader wait for another round of bug ping pong
[20:15] <pitti> a|wen-: however, that's standard practice for main; if motu-sru wants ack-before-upload, that's totally fine for me
[20:15] <pitti> a|wen-: just let me know what you decide, so that I stick to it
[20:15] <pitti> a|wen-: right now, my practice is that when I see an universe upload in the queue, I look at the bug and check if it's ack'ed; if not, I sub motu-sru and ask for ack
[20:15] <chrisccoulson> dmandell - for the volume notification issue, it might be useful to do "killall gnome-settings-daemon; gnome-settings-daemon --debug --no-daemon" and attach the output to the bug report when you hit the volume key
[20:16] <chrisccoulson> g-s-d is quite verbose in debug mode
[20:17] <a|wen-> pitti: all started with the process description not being clear about ack before upload or not necessary ... you might get a ping from jdong at some point about updating the description to reflect their decision (nobody fills compelled with changing wordings in processes too much)
[20:18] <dmandell> chrisccoulson: No output at all from hitting volume key
[20:19] <chrisccoulson> very strange
[20:20] <chrisccoulson> if you completely kill gnome-settings-daemon and then hit the volume key, then does the volume change?
[20:20] <chrisccoulson> it shouldn't, but i just wonder if you've got something else that grabs the key (very unlikely)
[20:21] <chrisccoulson> i should check to see if i get debug output on volume change actually;)
[20:21] <chrisccoulson> i get this output each time i hit the volume key:
[20:21] <chrisccoulson> ** (gnome-settings-daemon:28950): DEBUG: Using volume step of 6
[20:22] <chrisccoulson> you don't see that no?
[20:35] <liw> Keybuk, I keep forgetting that movie exists, ever since the sequels
[20:39] <ion_> liw: http://xkcd.org/566/ (the bottom one)
[20:50] <seb128> dmandell: there?
[20:50] <dmandell> seb123: I'm back
[20:50] <dmandell> seb123: Went to lunch.
[20:51] <seb128> dmandell: I was not there before but I read the bug, what hardware do you have? do you event for those keys in xev?
[20:52] <dmandell> chrisccoulson: The volume buttons on my T60 stlil work with gnome-settings-daemon disabled.
[20:52] <chrisccoulson> right#something else has to be grabbing the volume button
[20:53] <chrisccoulson> wierd
[20:53] <dmandell> seb123:  I'm just a normal user, I don't think I'm doing anything weird, how would I check xev?
[20:54] <dmandell> chrisccoulson: Per the bug, this worked in Jaunty until fairly recently, I haven't made any config changes in that time, just apt-get updates.
[20:54] <seb128> dmandell: open a command line and type "xev"
[20:55] <chrisccoulson> dmandell - my volume doesn't change when i kill gnome-settings-daemon
[20:55] <seb128> chrisccoulson: hi, you get the bug too?
[20:56] <chrisccoulson> no, it works fine for me
[20:56] <dmandell> when I start gnome-settings-daemon --debug --no-daemon, I see the following:
[20:56] <dmandell> ** (gnome-settings-daemon:25566): DEBUG: Unable to parse: 'XF86AudioMedia'
[20:56] <dmandell> Not sure if it has anything to do with anything, but it's audio related so I thought I'd bring it up.
[20:56] <chrisccoulson> dmandell - what does xev show when you press the key with no gnome-settings-daemon running?
[20:56] <seb128> dmandell: should not, could you run xev and see what events you get for those keys?
[20:57] <seb128> chrisccoulson: could be bug #357673 but it doesn't have lot of details, still good to debug it
[20:57] <dmandell> nothing in xev
[20:57] <seb128> dmandell: is g-s-d running?
[20:57] <seb128> does stopping it makes a difference?
[20:57] <dmandell> seb128: yes
[20:57] <dmandell> (running)
[20:57] <chrisccoulson> you should kill it first
[20:58] <seb128> chrisccoulson: you think that g-s-d grab events and do nothing with those?
[20:58] <dmandell> no, killing it doesn't make a difference.
[20:58] <chrisccoulson> seb128 - i think there is something else on the system grabbing the key
[20:58] <LaserJock> hmm, did Gnome switch to git today?
[20:58] <seb128> ok, so sounds similar to #357673
[20:58] <chrisccoulson> dmandell says that the volume still changes with no g-s-d running at all
[20:59] <seb128> LaserJock: they are in the middle of it not sure if it's done yet
[20:59] <seb128> chrisccoulson: his laptop might have those cabled, ie acting on an hardware level
[20:59] <LaserJock> seb128: does that mean any bzr mirrors or bzr-svn branches are going to not work now?
[20:59] <seb128> LaserJock: that would be a question for #launchpad rather I guess
[20:59] <chrisccoulson> seb128 - quite possible, but they worked at some point before
[21:00] <LaserJock> seb128: right, just thought you might know
[21:00] <seb128> chrisccoulson: before today or before a linux or xorg update? ;-)
[21:00] <seb128> LaserJock: no, I don't use bzr imports, I use svn directly usually
[21:00] <seb128> it's faster and less buggy (no outdated imports)
[21:01]  * chrisccoulson finds it very confusing to understand how keypresses get from the hardware to an application
[21:01] <LaserJock> seb128: ah, but I guess you'll have to switch to git or find a bzr <-> git method
[21:01] <seb128> LaserJock: I'm not using bzr to work on GNOME so I've nothing to switch really
[21:01] <seb128> LaserJock: we only have the debian directory in bzr for desktop packages and we use tarballs
[21:01] <dmandell> seb128: the timeframe of bug 357673 approximately matches my own.  I think I lost volume notifications at around the same time.
[21:02] <chrisccoulson> dmandell - could you switch to a terminal (CTRL+ALT+F1), and run "sudo showkey -k" and press the volume button
[21:02] <chrisccoulson> do you see any keycodes when you do that?
[21:02] <LaserJock> seb128: ah, I thought you were doing more upstream stuff so that you'd often want VCS checkouts
[21:02] <LaserJock> seb128: anyway, I'll ask #launchpad
[21:03] <seb128> chrisccoulson: https://wiki.ubuntu.com/Hotkeys/Troubleshooting is quite detailed
[21:03] <chrisccoulson> thanks seb128 - i'll have a read of that
[21:03] <seb128> dmandell: you might want to follow instructions on https://wiki.ubuntu.com/Hotkeys/Troubleshooting too
[21:03] <ion_> I didn’t read the bug report, but i think some package changed something so that the volume control keys don’t control software volume *at all*, since they can’t be prevented from controlling the hardware volume. That’s probably why there’s no indicator.
[21:04] <dmandell> chrisccoulson: nothing happens
[21:04] <dmandell> no keycodes
[21:04] <chrisccoulson> dmandell - that's wierd, so the kernel is not producing any keypress event at all
[21:04] <seb128> dmandell: do you still have old linux versions installed you can boot?
[21:04] <ion_> chrisccoulson: That’s probably an intentional workaround.
[21:05] <dmandell> seb128:  I may, hold on.
[21:05] <chrisccoulson> thanks ion_ - is there a reference to that somewhere? do you know what changed?
[21:05] <ion_> hotkey-setup (0.1-23ubuntu10): * Drop the override of the hotkey mask for ThinkPads.  This is currently used for brightness keys, volume keys, and the ThinkVantage button: - overriding the volume keys causes double-stepping of the volume, because the volume was also being adjusted in the hardware mixer, which we can't disable - so we don't want these keys exposed for now. LP: #355300.
[21:06] <chrisccoulson> ion_ - thanks
[21:06] <chrisccoulson> dmandell^^^
[21:06] <chrisccoulson> looks a likely suspect for your issue
[21:08] <seb128> and that was uploaded around the time where it broke
[21:09] <seb128> bug #357673 is on 2009-04-08
[21:11] <kees> ion_: what's the correct fix for this?
[21:12] <ion_> kees: I haven’t investigated the issue, but probably either finding a way to disable the hardware mixer control, or making the keys control the indicator but *not* software volume.
[21:12] <ion_> The latter one would probably be a bit of a kluge.
[21:13]  * kees 's head spins
[21:13] <kees> ion_: so prior to that fix, pressing volume keys on that hardware would double-step?
[21:14] <ion_> Yes
[21:15] <ion_> The behavior used to be such that like 80% of the volume indicator would be equivalent to total silence and the last 20% would suddenly raise the volume.
[21:15] <kees> icky.  :)
[21:16] <dtchen> can you try deselecting the relevant tracks using system> preferences> sound> devices> default mixer tracks ?
[21:16] <dtchen> s/relevant tracks/relevant mixer elements/
[21:16] <ion_> Which makes sense if you plot [0:1] x*x
[21:23] <cjwatson> slangasek: "RC candidate"? :-)
[21:23] <calc> heh
[21:23] <ebroder> Courtesy of the Department of Redundancy Department :)
[21:29]  * jdong starts seeding the .torrent torrent
[21:30] <ebroder> Oh, do torrents need seeds? I have bandwidth I can throw at the problem, too
[21:30] <sladen> ebroder: throw it, and see if there are catchers
[21:33] <DnaX> ogra: about status of irda-utils bugs?
[21:35] <ericdc> I am remastering a Ubuntu Server 8.04 LTS CD with a preseed file. I would like to include some packages on the CD to avoid grabbing them from the internet. Can anyone help me or tell me when I can get help?
[21:38] <ebroder> ericdc: You want to look at https://help.ubuntu.com/community/InstallCDCustomization
[21:42] <ericdc> ebroder: thats where I started
[21:58] <akgraner> mdz: What happened to the animal theme for the desktop background?
[21:59] <directhex> akgraner, good question. i kept the default wallpaper for hardy & intrepid, but jaunty has pushed me towards nabbing something else
[22:00] <akgraner> directhex: I was waiting for it, just downloaded the updates and was notified that the RC was done...Was hoping the last update would have the artwork.
[22:01] <akgraner> well the animal artwork I mean...
[22:05] <rickspencer3> akgraner: hi
[22:05] <rickspencer3>  I hear you were asking about default artwork?
[22:05] <BUGabundo> akgraner: hi
[22:05] <akgraner> rickspencer3: hi
[22:05] <akgraner> rickspencer3: yes...I was asking about the artwork
[22:06] <rickspencer3> sorry I missed it
[22:06] <rickspencer3> I hear through the irc grapevine you're looking for a bunny with antlers?
[22:06] <rickspencer3> :)
[22:06] <mdz> akgraner: I wouldn't go so far as to say there is a theme...the wallpaper has changed in different ways for each release.  these days, the design team develops it and we just drop it in
[22:07] <akgraner> rickspencer3: yes...I was hoping with last updates I installed, when I did the reboot a Jackalope would appear...I was a little disappointed...
[22:07] <rickspencer3> too bad
[22:07] <rickspencer3> I'm sorry you're dissapointed
[22:07] <akgraner> I liked the charm of that..was an announcement I missed.
[22:07] <rickspencer3> kwwii: is there not a different background that would suit with one of the alternate themes?
[22:08] <rickspencer3> akgraner: I don't think you missed an announcement
[22:08] <rickspencer3> like mdz says, we just help out the art team by dropping in their great work
[22:08] <mdz> akgraner: why did you expect to see a jackalope on your wallpaper?
[22:08] <LaserJock> extrapolation from a data set of 2?
[22:09] <akgraner> rickspencer3: maybe I'm just to new...well there was ipex and a heron...
[22:09] <rickspencer3> yeah
[22:09] <akgraner> so I guess I just expected a jackalope
[22:09] <rickspencer3> akgraner: you're right, the totally abstract background is a break from tradition
[22:10] <rickspencer3> but I think there are some good jackalope backgrounds out there
[22:10]  * ScottK would have enjoyed Bassalope, but is many releases too late for that.
[22:10] <ikus060> join #launchpad
[22:10]  * ScottK hands ikus060 a '/'
[22:10] <rickspencer3> I personally like how the new background has elements that are picked up elsewhere, like the default search page and such
[22:11] <rickspencer3> I think kwwii, our resident artist is in Germany, so it's late there, but he'll be able to connect you with some of the community submitted themes that have the jackalopes
[22:11] <akgraner> rickspencer3: I thought something that would break a tradition would have been discussed, that's why I asked if I missed something....
[22:12] <LaserJock> akgraner: well, the animal theme was new for Hardy
[22:12] <rickspencer3> akgraner: honestly, I don't know where it was discussed, I know the current background has been in the product for quite a while, since the week before visual freeze
[22:13] <rickspencer3> I wish I tracked this more, but I think there's a way for community members to submit themes and such, so I know it's a totally public deciscion
[22:13] <akgraner> rickspencer3: yes the current one as been there I just thought the final *pop* would be the animal showing up...that's all...
[22:13] <calc> is it possible to have comments in the control file?
[22:13] <rickspencer3> hehe
[22:14] <mdz> akgraner: 8.04 was, I believe, the first release to have animal-themed wallpaper.  if there was a tradition, the people making the wallpaper didn't know about it :-)
[22:15] <akgraner> rickspencer3: I'll go on a virtual hunt for the jackalope...just wish I had known it wasn't going to be there..I was *really* waiting to see it...
[22:15] <ScottK> calc: yes.  leading '#'
[22:15] <akgraner> mdz: see I blame on being the newbie..:)
[22:15] <akgraner> blame it I mean
[22:15] <ScottK> rickspencer3 and akgraner: There is a package called community-themes
[22:15] <rickspencer3> akgraner: I invite you to come back tomorrow in (what is your) morning
[22:15] <rickspencer3> ScottK - thanks
[22:15] <akgraner> cool thanks!
[22:17] <akgraner> rickspencer3: ok..
[22:17] <akgraner> rickspencer3: what time and for what?
[22:17] <rickspencer3> kwwii: will be here, he's a really good guy and is generally in charge of our artwork, perhaps you will meet in Barcelona
[22:17] <calc> ScottK: ok cool :)
[22:18] <ScottK> calc: I use it all the time to stub out misbehaving binaries.
[22:19] <pwnguin> did i miss something? is there going to be a 9.06?
[22:19] <calc> ScottK: cool :)
[22:19] <cjwatson> pwnguin: ...
[22:19] <calc> ScottK: i'm working on repackaging OOo and using it for better documenting
[22:19] <akgraner> rickspencer3: ok  thank you, I'm afraid I won't be able to make Spain...:(
[22:19] <rickspencer3> oh bummer
[22:19] <rickspencer3> you know me and Pete work together right?
[22:19] <rickspencer3> my wife couldn't make Barcelona either
[22:20] <akgraner> rickspencer3: I do now
[22:20] <pwnguin> cjwatson: someone posted to -devel about a problem with 9.06 installing netbook-remix
[22:20] <rickspencer3> akgraner: let me know how the background works out for you
[22:20] <rickspencer3> ttyl
[22:20] <akgraner> rickspencer3: I will, Thanks..:)
[22:21] <calc> akgraner: maybe you can make it to 10.04 UDS :)
[22:21] <calc> akgraner: it should be somewhere in the US
[22:21] <akgraner> calc: I hope one day...:)
[22:21] <cjwatson> pwnguin: typo
[22:22] <cjwatson> or possibly abject confusion
[22:22] <akgraner> calc: if not I've already been talking to Outback steak houses for release parties..:)
[22:22] <mdke_> lool: I know that Dougie Richardson was interested in helping out with UNR documentation, I'm unlikely to be able to help until the end of Sunday but if you post to ubuntu-doc I'm pretty sure you'll get a bite
[22:23] <cjwatson> pwnguin: the mail is very confusing and suggests that perhaps they were getting an image from somewhere entirely different, not us
[22:23] <pwnguin> probably
[22:23] <akgraner> thanks ya'll for info...be back tomorrow..:)
[22:23] <BUGabundo> akgraner: what theme colour would you like for KK? not sure if we are going Green (that would be too much openSUSE)
[22:23] <robbiew> akgraner: http://kiriyard.com/2009/03/sarusaslu-jaunty-jackalope/
[22:24] <akgraner> robbiew: me goes to look
[22:24] <lool> mdke_: We posted, but are held for moderation I think
[22:24] <lool> mdke_: Thanks
[22:25] <akgraner> BUGabundo: I need to think about that question...
[22:25] <akgraner> robbiew: Thanks!  Great site...:)
[22:25] <BUGabundo> humm we are going out of raibow colours lol
[22:25] <StevenK> akgraner: Outback Steak House for a release party? Oh, there has to be something better ... :-)
[22:25] <BUGabundo> already used most of the brownish
[22:26] <robbiew> akgraner: no problem
[22:26] <BUGabundo> suse is grean, redhat is redish
[22:26] <BUGabundo> and KDE uses all it can from blue and black
[22:26] <akgraner> StevenK: there are but the Koala theme...seemed to go with it...and the bar areas are cool....:)
[22:26] <BUGabundo> akgraner: are you imagining kk yellow? LOL
[22:27] <mdke_> lool: did you post with an Ubuntu or Canonical address?
[22:27] <StevenK> Argh, yellow is bad.
[22:27] <StevenK> Yellow would require developers to wear sunglasses to use the release
[22:27] <lool> mdke_: ubuntu
[22:27] <mdke_> lool: nothing in the moderation queue
[22:27] <mdke_> lool: those addresses should be whitelisted anyhow
[22:27] <lool> mdke_: Might have gone through then -- I'm not sub-ed
[22:28] <lool> mdke_: Right
[22:28] <BUGabundo> StevenK: ehehe
[22:29] <mdke_> lool: I don't see anything
[22:30] <lool> mdke_: http://article.gmane.org/gmane.linux.ubuntu.doc/12370
[22:30] <lool> largish thread already
[22:30] <lool> mdke_: It's in the middle of it, sorry
[22:30] <cjwatson> lool: FYI, pi-makelist-vfat seems to have broken with the partitioned armel images
[22:31] <mdke_> lool: ok, I see that, but it doesn't look lik a request for help. Better to start a new thread and clearly request assistance :)
[22:31] <lool> cjwatson: I think you had fixed that; it borke again?
[22:31] <cjwatson> lool: if I remove the 2>/dev/null | sed from the end, I get http://paste.ubuntu.com/152384/
[22:31] <cjwatson> definitely broke, we're seeing zero-sized .list files
[22:32] <lool> cjwatson: That's bad; that's when a tool doesn't want LBA but only CHS addresses for partitions or verifies that they match both
[22:32] <ogra> erm
[22:32] <cjwatson> can I leave it with you?
[22:32] <ogra> did you add a ~/.mtoolsrc ?
[22:32] <cjwatson> yes
[22:32] <lool> cjwatson: Yeah except I don't know what to do
[22:32] <cjwatson> see debian-cd/tools/pi-makelist-vfat
[22:33] <cjwatson> lool: you say that as if I do ;-)
[22:33] <lool> I guess I have to compute CHS and LBA compliant addresses; but I don't know how parted picks them
[22:33] <lool> The thing is that parted seems to change the disks' CHS depending on the partitions you create
[22:33] <lool> That is if you "parted mkpart" twice, you see different CHS values for the disk
[22:33] <cjwatson> if you can't figure it out, I can have a look tomorrow, maybe
[22:34] <cjwatson> I know where to look for parted's CHS handling, at least roughly, but I don't know offhand how it behaves or how to control it
[22:34] <lool> I'll try to fix it; I was hoping never to have to do that but it seems I was lucky until now
[22:35]  * ogra doesnt see the mtools_skip_check=1 in the MTOOLSRC ...
[22:35] <ogra> i think mtools need that for all image operations
[22:35] <ogra> if you dont use actual devices
[22:35] <lool> mdke_: Point taken; will write a new email asking explicitely
[22:35] <mdke_> lool: roger. If nothing happens by the weekend, I'll lend a hand
[22:36] <lool> ogra: That looks like a good setting to avoid touching this stuff altogether  :-)
[22:36] <ogra> heh
[22:37] <lool> mdke_: I'll wait til Tobin tries out various image writing tool and include his description in the list of things to help with; thanks
[22:40] <mdke_> lool: ok
[22:40] <ebroder> Looking at bug #356861, is the security team not going to handle the Jaunty upload? So I should find a sponsor?
[22:43] <kees> ebroder: for jaunty, you need to clear it with motu-release since jaunty is frozen.
[22:44] <blfgomes> could anybody help me setup bzr to work with a proxy that requires authentication? =/
[22:44] <cjwatson> blfgomes: #bzr is probably a better place to ask
[22:45] <ebroder> Any motu-release types around to OK?
[22:45] <lool> cjwatson: Sorry which image borke for armel?  live or alternate?
[22:45] <blfgomes> cjwatson: it was down a while ago, but I guess it's up now... thanks!
[22:45] <cjwatson> lool: I was looking at desktop, but both seem to have the problem
[22:46] <cjwatson> blfgomes: that could only have been the server; individual channels on the same IRC server can't really be down independently
[22:46] <blfgomes> cjwatson: whatever it was, it wasn't connecting :)
[22:50] <dtchen> ebroder: i've pinged a -release member in -motu
[22:53] <lool> ogra: What was the syntax to use skip_check in mtoolsrc?
[22:53] <ogra> lool, well, whats said in the error message ;)
[22:54] <ogra> mtools_skip_check=1
[22:54] <lool> ogra: I should learn to read really
[22:58] <ericdc> I do I prevent ppp-udeb to be loaded by the ubuntu installer OR how do I skip the detection with a preseed?
[22:58] <ericdc> How do I prevent ppp-udeb to be loaded by the ubuntu installer OR how do I skip the detection with a preseed?
[22:59] <lool> ogra, cjwatson: No, the skip_check isn't enough
[22:59] <lool> damn
[22:59] <cody-somerville> ericdc, What image are you using?
[22:59] <ogra> but its definately needed if you work with images
[22:59] <ogra> so keep it
[23:00] <lool> ogra: Why?
[23:00] <ogra> no idea, but i cant work with images with mcopy or mdir if i dont have it set ... i think it was explained in the manpage somewhere
[23:01] <ogra> All the Mtools commands perform a few sanity checks before going ahead, to make sure that the disk is indeed an MS-DOS disk (as opposed  to,  say  an  ext2  or  minix
[23:01] <ogra>        disk). These checks may reject partially corrupted disks, which might otherwise still be readable. To avoid these checks, set the MTOOLS_SKIP_CHECK environmental variable or the corresponding configuration file variable (see section  global variables)
[23:01] <lool> Yes it wasn't needed so far
[23:01] <lool> So I'd better keep the safety checks if disabling them isn't enough and they used to pass
[23:01] <ericdc> cody-somerville>Ubuntu 8.04 LTS Server
[23:02] <ogra> i never managed to work with mtools on images without them
[23:02] <ogra> i remember i used to set MTOOLS_SKIP_CHECK in former scripts i did, nowadays i just have it in mtoolsrc
[23:03] <ericdc> cody-somerville: I remastered the CD image with some extra packages and now it's failing detection pppoe concentrators. Which is BAD because I want the process to be fully automated.
[23:03] <cody-somerville> ericdc, Did it try to detect PPPOE before?
[23:04] <ericdc> cody-somerville: the worst part is I don't use pppoe
[23:04] <ericdc> cody-somerville: no never
[23:04] <ericdc> cody-somerville: only since I added extra packages
[23:05] <cody-somerville> ericdc, I think you can preseed the the error messages so they don't show. I couldn't figure out how to make it not try and detect except by removing the udeb and regenerating the archive indices.
[23:06] <ericdc> cody-somerville: I can't seem to find what d-i directive to use to skip it
[23:06] <cody-somerville> ericdc, There is none
[23:06] <ericdc> cody-somerville: I wish there was a list
[23:06] <ericdc> really
[23:06] <ericdc> crap ok
[23:25]  * calc is beginning to think that the only reason multiple OOo can't be installed at the same time is due to buggy packaging (nothing in upstream itself)
[23:25] <jdong> calc: is there ever a better reason for why you can't install the same package to two prefixes?
[23:26] <calc> jdong: well its already essentially doing that by default, the debian packaging just changes it to be in a non-versioned prefix
[23:26] <calc> at least afaict so far
[23:27] <calc> OOo doesn't exactly follow the FHS
[23:27] <calc> which makes it fairly easy to do the multiple install
[23:27] <jdong> meh the FHS is a "recommendation"
[23:27]  * jdong watches the pitchforks come
[23:27] <calc> jdong: sticking arch indep data into /usr/lib isn't exactly a good idea
[23:28] <jdong> ok that's a bit painful.
[23:28] <calc> jdong: and as far as debian is concerned FHS isn't just a recommendation its required
[23:28] <calc> of course some debian packages are thus buggy when it is too painful to try to fix them
[23:29] <calc> there are 6 noted exceptions to FHS in policy
[23:31] <jdong> right.
[23:32] <jdong> I see the merit, but it does make packaging a lot hairier
[23:32] <jdong> how do you put up with OOo packaging anyway? isn't there a good 6-8 hours of pipeline latency when you build a package? :)
[23:33] <kees> pitti: I seem to have both /etc/default/apport and /etc/default/apport.default :(
[23:33] <chrisccoulson> kees - there's a bug report for that already isn't there?
[23:33] <calc> jdong: for a cached build it takes ~ 1-2hr
[23:33] <kees> chrisccoulson: oh, dunno
[23:34] <calc> jdong: for the buildds it takes ~ 36hr before they are all done (armel is really slow)
[23:34] <jdong> ah I see
[23:34] <jdong> at least caching makes it bearable then
[23:34] <chrisccoulson> kees - bug 361543
[23:34] <kees> chrisccoulson: thanks
[23:34] <calc> jdong: yea
[23:35] <calc> jdong: aiui there is a better c++ linker that might help as well in binutils but it is still experimental
[23:39] <kwwii> lol, I put mascots in the wallpapers and kinda felt the heat for it, and now we don't use them and people miss them, funny that
[23:39] <kwwii> if it makes anyone feel better there is already a bunch of work going on in the ubuntu-artwork team creating koala pics ;)
[23:39] <kwwii> personaly, I prefer my desktop without a mascot
[23:40] <calc> kwwii: yes... no matter what you do it is wrong ;-)
[23:40] <ebroder> I thought the Ibex was really well done. I swear I looked at the background for at least 2 months before even realizing it was supposed to be an Ibex
[23:40] <jdong> kwwii: I'm thinking animated wallpapers
[23:40] <jdong> like maybe with a jackalope and if you click it it runs across and shatters some desktop icons
[23:41] <jdong> courtesy of compiz?
[23:41]  * ebroder twitches
[23:42] <askand> Anyone here familiar with the new notify-osd?
[23:44] <askand> I am thinking of bug 338695 where lowresimages appears in the bubbles, in the case with pidgin it appears that they do not actually have a highresversion of the icon in question and therefore we see a lowresicon, would the way to go in this case be to file a bug against pidgin for not providing scalable images, or at least highresversions?
[23:49] <cjwatson> ericdc: your remastering has probably set incorrect Priority fields; compare the Priority fields in your Packages files against those in the archive
[23:51] <cjwatson> ericdc: also look through the installer's syslog to see which udebs it's loading; it generally includes a brief explanation of why
[23:57] <cody-somerville> cjwatson, Does d-i load all the udebs on the cd or just those of a certain priority or what?
[23:58] <cjwatson> cody-somerville: http://lists.debian.org/debian-boot/2004/07/msg01207.html
[23:59] <cjwatson> in brief, by default it loads Priority: standard and above, and anything installed explicitly using an anna-install command (and the dependencies of both of those, of course)
[23:59] <cjwatson> or the Enhances thing I mention; I forget whether I ever looked into how that really behaves