[00:00] <glaksmono> hi
[00:00] <glaksmono> why do you guys withdrew from GSoC?
[00:00] <glaksmono> may i know?
[00:17] <maxb> seb128: The libbonoboui doc change has had unintended consequences - bug 348228 - ooi, why choose to carry something seemingly so minor as ubuntu delta?
[00:19] <slangasek> maxb: so that our LiveCDs fit on a CD.
[00:19] <maxb> ah
[00:20] <JanC> glaksmono: I don't know any official reason, but IIRC there were some "bad experiences" in the past
[00:36] <UsamaAkkad> hello ,can I add ext4 support to hardy?
[00:45] <slangasek> UsamaAkkad: it wouldn't be a sane thing to do.  It's not supported by the hardy kernel, or the hardy partitioning tools, or the hardy bootloader.
[00:46] <UsamaAkkad> :S I've crated one using other os and now I can't use it :)
[00:52] <o0Chris0o> Hello to all the Ubuntu Devs :) I am trying to get in touch with the devs that have worked on Weather Applet 2.26.0
[00:53] <o0Chris0o> not sure if this is the right channel to ask or not
[00:53] <Hobbsee> won't behere
[00:53] <Hobbsee> you need to find where gnome does their irc
[00:53] <RAOF> o0Chris0o: The /usr/share/doc/gnome-applets/copyright file should contain the relevant emails, but hitting lits.gnome.org is likely to be much more interesting.
[00:54] <o0Chris0o> RAOF: thanks :)
[00:54] <Hobbsee> http://live.gnome.org/GnomeIrcChannels by the looks of it, too.
[01:06] <ScottK> slangasek: re the beta announcement: I was offline all day today.  We'll have something for you tomorrow.
[01:06] <slangasek> sounds good
[01:30] <LordKow> hey the ubuntu devs probably work with local filesystem repos a bit. dput seems to work nicely for uploading to local but is there not an easy way to remove a package from it?
[01:33] <slangasek> that would be a function of the repo software you're using.
[01:34] <LordKow> hm, well i guess that would be mini-dinstall.
[02:11] <sparky_> anybody know what the system-wide folder is for firefox extensions??
[03:25] <calc> what is the name of the package for git?
[03:25] <calc> "git" seems to be something else
[03:26] <calc> is it git-core?
[03:26]  * calc tries it out
[03:26] <TheMuso> calc: git-core
[03:28] <calc> ok
[03:28] <calc> i saw all the matching verison numbers in dselect and thought it was probably that one
[04:48] <icarus> i guess theres not much ubuntu developement going on anymore
[04:48] <icarus> thats a shame
[04:49] <TheMuso> icarus: we are coming up to teh beta and final releases, so we are only fixing important bugs
[04:50] <StevenK> It's also European night, so this channel is quiet around this time.
[04:59] <calc> cjwatson: wrt the GPT issue again, apparently msdos label has a hard limit of 2TB(?) if so we will hit that limit this year as 2TB hard drives are already available
[04:59] <calc> cjwatson: saw someone mention there is a limit on ubuntu-devel-discuss
[05:01] <calc> cjwatson: https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2009-March/007555.html
[05:01] <TheMuso> calc: thats going to screw many windows users over who want 2TB drives IMO.
[05:01] <TheMuso> Unless Vista 32 can also work with GPT
[05:03] <calc> TheMuso: aiui vista works with gpt but doesn't boot from it except for 64bit, they will probably patch that soon i would imagine
[05:03] <TheMuso> calc: They'll have to.
[05:03] <TheMuso> Unless they want even more backlash.
[05:04] <calc> http://wdc.com/en/products/products.asp?driveid=576
[05:05] <calc> I think WDC is the only maker with 2TB drives currently, but the rest will catch up soon
[05:05] <TheMuso> yep
[05:06] <calc> looks like we probably should default to using GPT for drives > 2TB if the drive is not partitioned, assuming the information in the thread is accurate
[05:08] <calc> what i'm unclear about is whether it is msdos doesn't support drives > 2TB or just partitions > 2TB
[05:09] <TheMuso> yeah
[05:10] <calc> http://www.carltonbale.com/2007/05/how-to-break-the-2tb-2-terabyte-file-system-limit/
[05:10] <TheMuso> In any case, I think with these sized drives coming on now, we will have to start moving away from the legacy piece of crap that is BIOS.
[05:10] <calc> that article implies you don't need GPT if you use linux if you have large block device support enabled
[05:12] <calc> i don't see CONFIG_LBD in our amd64 kernel so not sure if that is a current option or not
[05:14] <TheMuso> it may have changed nam possibly
[05:15] <calc> TheMuso: yea, i emailed cjwatson so when he wakes up can take a look at it
[05:21] <calc> heh large drives are one way to get rid of XP
[05:22] <calc> XP 32bit only supports up to 2TB disk in total (not per partition)
[05:22] <TheMuso> yep
[05:23] <calc> apparently you can't boot off a GPT disk with Vista unless your bios is EFI
[05:23] <calc> that is bad news
[05:26] <TheMuso> This was my point earlier
[05:26] <TheMuso> EFI is needed
[05:26] <TheMuso> and even then 64-bit vista is the only one that supports EFI./
[05:28] <Amaranth> TheMuso: Except it doesn't :/
[05:28] <calc> i see lots of claims that Windows 7 defaults to GPT
[05:28] <calc> but not anything authoritative
[05:28] <Amaranth> That'd be cool
[05:29] <Amaranth> We don't support GPT, do we?
[05:29] <calc> some regular pc's apparently have uefi though so i can't tell if it just defaults to GPT in those cases or not
[05:29] <Amaranth> Oh, Vista SP1 added EFI
[05:29] <calc> Amaranth: iirc we do on systems with uefi
[05:29] <Amaranth> hmm
[05:30] <Amaranth> Pretty sure I had to have rEFIt do the sync thing before I could get Ubuntu installed
[05:31] <TheMuso> Amaranth: yes you would have had to do that.
[05:31] <TheMuso> However grub has GPT patches
[05:32] <calc> hmm if you use rEFIt can you install Vista SP1 64bit using GPT?
[05:33] <calc> hmm nm it seems rEFIt isn't a EFI emulator like I thought it was
[05:34] <TheMuso> calc: no its not
[05:34] <TheMuso> The move to EFI in the PC BIOS area will be quite a big job, since lots of drivers will have to be rewritten to work with EFI. Hell I think everyone will just have to get new hardware.
[05:35] <TheMuso> I don't see manufacturers releasing updates to their video card's BIOS for example.
[05:36] <calc> apparently MSI sells motherboards with uefi bios available, not sure what it does for video bios though
[05:37]  * calc gone to bed, bbl
[05:37] <Amaranth> calc: Most of them just emulate a traditional BIOS so things will keep working
[05:37] <Amaranth> I think the goal there is later on once everything is updated they can release a patch that just turns off the emulation
[05:37] <TheMuso> At least someone is thinking ahead...
[05:38] <TheMuso> Amaranth: I bet those boards also have no legacy components, i.e no COM headers, no PS/2, no ISA bridge of any kind.
[05:38] <Amaranth> I'm sure
[05:38] <Amaranth> btw, I think Gateway was the first PC maker to ship machines with UEFI
[05:38] <Amaranth> which seems really odd so I thought I'd mention it :P
[05:40] <TheMuso> s/c
[05:55] <RAOF> I presume that the standard way to get CONFIG_MMIOTRACE set in the generic kernels is to file a bug?
[05:59] <dholbach> good morning
[06:27] <slangasek> superm1: what do we do about bug #341898?
[07:10] <kaduk> Hi
[07:10] <kaduk> How to include modules.dep in initramfs for custom kernel ?
[07:10] <kaduk> Any ideas ?
[07:25] <pitti> Good morning
[07:27] <pitti> kirkland: ugh, how did you change it to German so permanently in the first place? usually you just "export LANG=" in a terminal, and if you are done with it, you close the terminal or set it back to en_US.UTF-8; other terminals/apps should have never been affected..
[08:25] <kirkland> pitti: thanks, uninstalling the langpack seemed to solve it for me
[08:26] <pitti> kirkland: very strange; you are sure that your system locale is en_US.UTF-8?
[08:26] <pitti> kirkland: the langpack shouldn't have any effect then
[08:26] <kirkland> pitti: how do i check that?
[08:29] <pitti> kirkland: echo $LANG
[08:29] <pitti> or, better, "locale"
[08:32] <kirkland> pitti: those look right, en_US.UTF-8
[08:32] <kirkland> pitti: i think i'm back to normal
[09:22] <lool> Keybuk: around?
[09:23] <lool> Keybuk: I think my init just became somewhat broken on armel after today's upgrade; it's not respawning gettys anymore
[09:23] <lool> The only thing in daemon.log is:
[09:23] <lool> Mar 25 09:00:52 babbage init: Re-executing /sbin/init
[09:24] <lool> In syslog I also see immediately thereafter:
[09:24] <lool> Mar 25 09:06:49 babbage kernel: [159660.980000] udev: starting version 140
[09:26] <lool> PID 1 is in: select(7, [3 5 6], [], [], NULL
[09:41] <lool> It seems it's the libc6 upgrade triggering the restart of init/upstart
[09:47] <ion_> A free geolocation database: <http://blogama.org/node/58>. It could be useful for Ubuntu if they’re going to provide a server for the mirror method.
[09:47] <lool> Keybuk: This happened on my two armel installs
[09:48] <seb128> lool: today's upgrade should be pretty non-update since we are frozen for beta no?
[09:48] <lool> Keybuk: I did a "touch /etc/event.d/ttyS0", this made upstart go out of the select, scan the file again, but it didn't respawn the getty
[09:49] <lool> seb128: I think the bug was there before beta, but any libc update which runs "init u" will have triggered it, and there was a libc update just before beta freeze (last friday)
[09:49] <lool> I'm only upgrading now
[09:50] <lool> seb128: But right, it's the upgrade which I ran today, not from the updates the archive got today, thanks for clarifying
[09:50] <lool> running "init u" manually has a larger effect, but still doesn't respawn; /me reboots
[09:54] <lool> Keybuk: 348346
[10:04] <lool> Keybuk: Actually not armel specific at all, same issue on my desktop
[10:10] <lool> Keybuk: At least one dup, perhaps two
[10:30] <cjwatson> calc: yes, I'm aware of that, the partitioner already defaults to GPT on >2TB drives
[10:32] <cjwatson> ion_: yeah, I heard of that recently and posted a comment to a related installer bug
[10:33] <cjwatson> ion_: the database is an 11MB zip file, so we'd certainly have to have a server for it
[10:40] <siretart`> dholbach: thank you very much! I probably should have written that mail in english in the first place, but OTOH, perhaps it's better that to have it reflected by someone not that much involved
[10:41] <dholbach> siretart`: no worries - was easy enough to do
[11:03] <cjwatson> ion_: I'm filing a (non-urgent) request with our sysadmins to set up a service using that database
[11:04] <ion_> cjwatson: Cool, thanks,
[11:42] <Toobaz> "not app development on Ubuntu" means "not app development using Ubuntu" or "not app development for Ubuntu"? I'd like to know how to comply with jaunty's new notifications... but if it's offtopic please feel free to tell me (in that case, any hint on where to ask?)
[11:43] <Hobbsee> Toobaz: the former, I think.  And I believe you want #dx, if people are around at this time of day :)
[11:43] <Hobbsee> as that's where that team tends to hang out
[11:44] <Toobaz> Hobbsee: thanks (what is "dx" for?!)
[11:44] <soren> desktop experience, I believe.
[11:44] <Toobaz> soren: nice, thanks
[11:44] <Hobbsee> yes, that
[11:58] <ogra> mdz, did you file a bug about ubiquity offering to install to the source media ?
[11:59]  * ogra just got the SD card offered trying an install in the babbage board
[11:59] <mdz> ogra: bug 347916
[11:59] <ogra> thanks
[11:59] <mdz> ogra: I'm not sure that's the same thing you're talking about though
[11:59] <mdz> that's about the warning dialog saying that it's mounted
[12:00] <ogra> well, it didnt offer me to unmount it, but /dev/mmcblk0 was in the partitioner and selected as default target
[12:00] <ogra> (/dev/mmcblk0 isd the boot devicer for the livefs in my case)
[12:01] <apw> whats the most concise way to find out what version of a package you have, and if there are any upgrade candidate.  i often see output like below in bugs so i assume its command generate: libdrm2:
[12:01] <apw>   Installed: 2.4.4-0ubuntu6
[12:01] <apw>   Candidate: 2.4.5-0ubuntu1
[12:01] <ogra> cjwatson, want a new bug for it ? or should i follow up on mdz's ?
[12:01] <Hobbsee> apw: apt-cache policy packagename
[12:01] <apw> policy, obviously !?!, thanks
[12:02] <ogra> (on a sidenote, ubiquity does the base install and partitioning fine on babbage now, though we're missing the kernel bits, so there it will fail)
[12:02] <mdz> ogra: sounds like a different issue to me
[12:02] <ogra> yeah
[12:02] <mdz> it's easy enough to dupe later if not
[12:02] <Hobbsee> apw: yeah.  There always were interesting names in apt-cache.  You're welcome.
[12:03] <ogra> ok, i dont think ubiquity every took SD cards into account as install media (it didnt hasve to before :) )
[12:03] <ogra> *have
[12:03] <apw> pitti, how come apport can still produce notification icon things and be all nice and quiet about its work, and yet that was imposisble for update-manager and it has to hide and jump out at you?
[12:04] <cjwatson> ogra: your bug is sort of the opposite of mdz's. New bug, yes please
[12:04] <ogra> on it :)
[12:04] <ogra> i'm impressed, i didnt even expect it to get that far :)
[12:05] <pitti> apw: it has always popped up for crashes of your own programs
[12:05] <pitti> apw: but that's not possible with system crashes which you need root privs for
[12:05] <apw> sorry yeah thats good and thats all good
[12:05] <pitti> apw: that issue was on the table, bot not considered jaunty critical, because we'll disable apport in the final release
[12:05] <cjwatson> ogra: file it on partman-base, please
[12:05] <ogra> oh, ok
[12:05] <apw> what i mean is we were forced to accept update-manager without its cute icon and click me to do things interface
[12:05] <cjwatson> ogra: it needs to be educated about mmcblk*
[12:06] <apw> and yet apport still can do it.  wondering why update-manager can't do what apport does
[12:06] <apw> with apport as a good thing
[12:06] <cjwatson> I hate the way device name handling is spread all over the place :-/
[12:06] <pitti> apw: I guess the design team doesn't truly like the way apport does it either; but unlike update-notifier/manager, the system crashes can't run as user :(
[12:06] <pitti> apw: I guess I'll still get my share of a beating from them
[12:07]  * apw offers you a shield of defence +1
[12:07]  * pitti gladly adds it to his asbestos pants
[12:08] <cjwatson> loggerhead is so nice for SRU proposals
[12:08] <cjwatson> particularly now that the URLs have been made saner
[12:08] <ogra> GRRR
[12:08] <cjwatson> just being able to link to http://bazaar.launchpad.net/~ubuntu-core-dev/tasksel/intrepid-proposed/revision/1388?compare_revid=1383 beats having to mess around attaching a debdiff
[12:09] <ogra> i really dont like jauntys X crashyness
[12:09] <pitti> cjwatson++
[12:09] <pitti> ogra: is it really so bad? just after suspend, or on other occasions?
[12:09] <pitti> I get it after suspend sometimes, but that's finally tracked down
[12:10] <ogra> pitti, out of the blue
[12:10] <ogra> but i'm using UXA deliberately
[12:10] <pitti> ah, I'm not
[12:10] <ogra> often the mouse pointer still works but the rest is stuck
[12:10] <ogra> somethimes it kicks me to gdm
[12:10] <ogra> *times
[12:11] <pitti> ogra: does upstream know about the bug, logs, registers, etc.?
[12:11] <pitti> I reported some myself, and although it takes a while, there has been progress
[12:11] <ogra> no, i didnt find the time to capture anythng yet
[12:11] <pitti> my workstation often suffers from pipe underruns
[12:12] <ogra> it seems related to using an external monitor on my laptop together with UXA
[12:12] <Hobbsee> ogra: oh, i thought X freezing & dying was just me
[12:12] <jcastro> I just realized mine was dying on resume
[12:12] <ogra> it doesnt die if i use it with normal resolution on the laptop LCD ... the external one uses 1900x1200 while the LCD uses 1024x800
[12:12] <jcastro> unfortunately I for the first few times I had assumed that gnome must have given up on session restore completely
[12:13] <Hobbsee> mine will die while switching to a guest session
[12:13] <pitti> jcastro: that's the bug I was talking about; fix is avaialble and will land after beta
[12:13] <jcastro> pitti: yes james_w pointed it out to me thanks
[12:13] <cjwatson> also 'bzr cat -rtag:foo' much quicker than having to mess around unpacking source packages ...
[12:14] <pitti> ogra: I'm using an external TFT as well; do you get occasional flickering?
[12:15] <ogra> no, by my TFT is very expensive, it might have some flicker preventing thing builtin
[12:15] <pitti> uh, that would be magic
[12:15] <pitti> ogra: how often does it freeze for you?
[12:15] <ogra> how doe that flicker manifest for you ?
[12:15] <pitti> ogra: i. e. if you tried something to fix it, would you notice?
[12:15] <ogra> every few days
[12:15] <pitti> ogra: well, the screen jumps for a subsecond and then restores
[12:16] <ogra> no, i dont see that
[12:18] <ogra> cjwatson, Bug #348411
[12:19] <cjwatson> taavikko:
[12:20] <cjwatson> oops, sorry taavikko
[12:20] <cjwatson> ogra: ta
[12:20] <ogra> ugh ...
[12:21]  * ogra just notices he picked the 2G USB key instead of the 4G one for the install test
[12:21] <ogra> i wonder if that will survive to the end
[12:30] <Keybuk> lool: what was broken, specifically?
[12:38]  * pitti looks at the panel and notices that it's 1337 o'clock
[12:38] <pitti> time for hacking, apparently :)
[12:38]  * Mithrandir notes pitti lives in the past. :-P
[12:38] <Mithrandir> 13:38  * pitti looks at the panel and notices that it's 1337 o'clock
[12:39]  * pitti hugs Mithrandir
[12:39] <ogra> heh, same here :)
[12:40]  * Mithrandir ruffles pitti 
[12:41] <ogra> oh, ubiquity is such a liar on the babbage
[12:41] <ogra> "less than a minute remaining" .... shown since tem minutes already
[12:41] <ogra> *ten
[12:42] <pitti> ogra: there's a typo in "millenia"
[12:44] <ogra> heh
[12:50] <ogra> hmm, apt isnt happy about /dev/mmcblk0 being mounted as /cdrom :(
[12:52] <cjwatson> ogra: why does apt care what's mounted there as long as it has the right structure?
[12:53] <ogra> hmm, then probably the structure is wrong, sadly the board just crashed
[12:53]  * ogra starts over ... damned, i was at 89%
[12:54]  * ogra starts over
[12:56] <lool> Keybuk: getty wouldn't be respawned
[12:56] <lool> Keybuk: Or anything else I guess; see the bug report
[12:57] <lool> Keybuk: I confirmed on my desktop, so it looks like some urgent we want to fix for jaunty
[12:57] <Keybuk> getty was initially spawned?
[12:57] <Keybuk> you logged in, logged out, and then it wasn't respawned?
[12:57] <lool> Keybuk: Yes
[12:57] <lool> Keybuk: Well after telinit u, no getty would get respawned
[12:57] <lool> The running ones would still work
[12:58] <lool> But when I'd logout, new ones wouldn't come up
[12:58] <Keybuk>  Mar 25 09:00:52 babbage init: Re-executing /sbin/init
[12:58] <lool> I noticed on armel because we use serial console a lot, but it's the same on my desktop if I login, telinit u, logout
[12:58] <Keybuk> what killed init?
[12:58] <lool> Keybuk: libc6 upgrade
[12:58] <Keybuk> *sigh*
[12:59] <lool> Keybuk: "init u" is run except for a sysvinit version blacklist
[12:59] <Keybuk> someone keeps uncommenting that damned fix
[12:59] <Keybuk> so that's the bug
[12:59] <Keybuk> don't use init u/telinit u
[13:00] <Keybuk> it causes upstart to lose all of its state
[13:03] <lool> Keybuk: What weird is that upstart doesn't seem to honor its config files either
[13:03] <Keybuk> lool: how do you mean?
[13:03] <lool> Keybuk: e.g. even if I touch /etc/event.d/ttyS0, no getty is respawned
[13:03] <Keybuk> sure
[13:03] <Keybuk> "start ttyS0" :)
[13:03] <lool> So I guess the triggering event doesn't happen
[13:04] <Keybuk> touching config files has nothing to do with events
[13:04] <lool> I never start ttyS0
[13:04] <lool> So it's something else starting it
[13:04] <lool> start on stopped rc2
[13:05] <lool> So I guess upstart should save its state and/or pick up jobs which match the current criterions for being respawned
[13:05] <Keybuk> err, neither
[13:05] <lool> Keybuk: If the behavior is that bad on telinit q, it might be worth not killing init and logging a warning that this isn't implemented yet
[13:06] <Keybuk> lool: I've commented out that line about half a dozen times over the last few years
[13:06] <Keybuk> someone keeps putting it back
[13:06] <cjwatson> mdz: since bug 346589 bites UNR quite noticeably, do we need to release-note it for beta?
[13:06] <mdz> cjwatson: yes
[13:06] <cjwatson> Keybuk: I've found that glibc changes not committed to bzr have a habit of getting lost
[13:06] <mdz> cjwatson: or rather, I'd say that bug 347916 needs to be release noted
[13:07] <lool> Keybuk: But even if we avoid calling into that, we're at risk until either upstart behaves as expected in face of such use or doesn't do anyting
[13:07] <cjwatson> mdz: both, surely
[13:07] <Keybuk> lool: yes
[13:07]  * RainCT wonders if apport is compatibly with Debian's bug hooks
[13:07] <lool> Keybuk: So will you remove the kill and log a warning instead?
[13:07] <lool> Or will you implement state saving/restoring?
[13:08] <Keybuk> lool: implementing state saving/restoring is planned
[13:08] <lool> I understand the immediate workaround is to comment out he init q in libc6
[13:08] <Keybuk> it'll take about a year to write ;)
[13:08] <lool> Keybuk: Perhaps it's worth it to remove the kill then
[13:08] <lool> Cause the effects are nasty ATM
[13:08] <Keybuk> not that nasty really
[13:08] <Keybuk> the glibc upgrade tells you to restart your system anyway, no?
[13:08] <lool> No
[13:09] <cjwatson> Keybuk: I can't find a record of any glibc upload from you since feisty
[13:09] <lool> Keybuk: It's enough to dpkg-reconfigure libc6 to trigger the bug
[13:09] <cjwatson> Keybuk: and neither your dapper nor your feisty upload were relevant - are you sure you uploaded these fixes?
[13:09] <Keybuk> cjwatson: hmm, strange
[13:10] <Keybuk> cjwatson: maybe you persuaded me not to, on the basis then init would still have the old glibc open
[13:10] <lool> So can we just replace the kill with a warning for now until state saving is implemented?
[13:10] <cjwatson> I'm not sure I was aware that it caused breakage
[13:10] <Keybuk> lool: I'm not sure we should rush into this
[13:11] <cjwatson> I think the last time I persuaded you to add a dummy 'init u' implementation instead?
[13:11] <cjwatson> but it was a while back
[13:11] <Keybuk> cjwatson: yeah, I'm trying to think why I did that at all
[13:11] <Keybuk> I would have known it stops gettys from respawning :)
[13:11]  * Keybuk wishes you could grep irclogs
[13:12] <cjwatson> I have local logs back to early 2007
[13:12] <Keybuk> bug #188925 apparently
[13:12] <Keybuk> 23 Sep 2008
[13:12] <cjwatson> try the 2008-09-29 logs
[13:12] <Keybuk> ohh
[13:12] <lool> Keybuk: What's the kill good for?  it picks up a new libc or a new ld-linux or a new init; is there any other reason for it?
[13:12] <Keybuk> now that title explains everything doesn't it ;)
[13:13] <Keybuk> including why we can't just put a warning there instead
[13:14] <cjwatson> hah, neat
[13:14] <Keybuk> ahh
[13:14] <Keybuk> and then the day after we had that discussion about the scary assertion when upgrading libc6
[13:14] <Keybuk> because restarting upstart caused it to drop the connection to initctl/telinit
[13:15] <Keybuk> and it went WAAAH
[13:15]  * Keybuk remembers now
[13:15] <Keybuk> lool: so yeah
[13:15] <Keybuk> there's a rock, and a hard place
[13:15] <lool> I am afraid one of you two will have to teach me why not re-execing upstart prevents remounting ro; is this because a fd is open on libc?
[13:15] <Keybuk> take your pick ;)
[13:15] <lool> Was this only for a particular version of libc6?
[13:16] <Keybuk> lool: you can't remount a system if you have any "dirty" files open
[13:16] <Keybuk> dirty files include those files you have opened which have been unlinked
[13:16] <Keybuk> upgrading libc replaces the libc6 .so
[13:16] <Keybuk> init would have the old .so open if it wasn't restarted
[13:16] <Keybuk> so the filesystem is busy
[13:17] <lool> Can't we re-exec upstart on shutdown only?
[13:18] <Keybuk> that'd kill the shutdown sequence ;)
[13:19] <Keybuk> I don't think this is a sky-is-falling bug, since there's a simple command to restart the terminal - and it's fine after a reboot
[13:20] <lool> Well it happens on all libc6 upgrades, so on all dist upgrades
[13:20] <ogra> hmm, where is redboot-tools
[13:20] <Keybuk> lool: most of the time, these tend to require a reboot anyawy
[13:20] <lool> ogra: I saw it in aptitude when updating earlier
[13:20] <ogra> i dont see it on the babbage
[13:21] <ogra> trying to install redboot-tools and redboot-imx here after a fresh atp-get update
[13:21] <ogra> *apt
[13:22] <lool> ogra: weird, I could swear I saw it earlier, and I don't anymore
[13:22] <ogra> i see the source
[13:23] <ogra> lool, seems the binaries were not published or ports hangs once again
[13:23] <lool> ogra: the binaries are in NEW
[13:23] <ogra> ah !
[13:23] <lool> I must have confused this with the other redboot package
[13:24] <ogra> well, i'll try without bootloader for now
[13:24] <lool> Keybuk: So we should probably recommend a reboot when init-u-ing
[13:24] <Keybuk> lool: agree
[13:25] <cjwatson> wah, what happened to /dev/kvm
[13:26] <cjwatson> doesn't kvm load the modules it needs?
[13:26] <lool> Keybuk: https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/92177 looks like it could be closed with the current init u implementation
[13:27] <Keybuk> no, it cna't
[13:30] <cjwatson> Keybuk: bug 340873, if you haven't seen it
[13:30] <cjwatson> Keybuk: should that be targeted to jaunty?
[13:34] <Keybuk> ironically there doesn't seem to be a bug that upstart doesn't support reexec properly
[13:35] <Keybuk> cjwatson: err, I thought I got all those
[13:35] <lool> Keybuk: You can make the respawn one that bug if you like
[13:36] <cjwatson> Keybuk: I'll take that as a yes, then
[13:36] <Keybuk> cjwatson: yeah
[13:36] <Keybuk> though where does your bluez modprobe come from?
[13:36] <cjwatson> bluez-utils
[13:36] <Keybuk> quest bluez-4.25% grep -r modprobe .
[13:36] <Keybuk> zsh: exit 1     grep -r modprobe .
[13:36] <ogra> isnt that in the initscript ?
[13:36] <Keybuk> quest bluez-4.32% grep -r modprobe .
[13:36] <Keybuk> zsh: exit 1     grep -r modprobe .
[13:37] <cjwatson> maybe some old version? dpkg -S still lists it, though
[13:37] <Keybuk> cjwatson: could be
[13:37] <Keybuk> cjwatson: bluez-utils only contains /usr/share/doc/bluez-utils for me
[13:37] <Keybuk> bad clean up of a transiational?
[13:38] <ogra> same here
[13:38] <cjwatson> but then dpkg -L would not list it ...
[13:39] <cjwatson> I mean, I can't find it in the source either
[13:39] <Keybuk> yes it would
[13:39] <cjwatson> hmm, indeed, it isn't in the .deb
[13:39] <ogra> dpkg -L gives me /usr/share/doc/bluez-utils and its contents
[13:39] <Keybuk> dpkg -L includes all files owned by the package
[13:39] <cjwatson> ok, so it's a stale conffile left around from a previous version
[13:39] <Keybuk> including any adopted from previous versions
[13:39] <cjwatson> something should clean it up, though
[13:39] <Keybuk> cjwatson: sure
[13:40] <Keybuk> if I upload, they'll queue for after-beta right?
[13:44] <Keybuk> ogra: can you do irda-utils
[13:44] <Keybuk> the maintainer scripts are insane, and I'm not going near them ;)
[13:45] <Keybuk> cjwatson: err, wtf is oss-compat?
[13:45] <Keybuk> it seems to be utterly irrelevant in ubuntu given our alsa packages
[13:46] <ogra> Keybuk, hrm for what ? i dont have irda HW to test and am massively busy getting babbage in shape
[13:46] <cjwatson> Keybuk: queue> yes
[13:46] <Keybuk> ogra: you touched it last
[13:46] <ogra> me ??
[13:47] <ogra> Keybuk, cn that happen after beta, i really dont have a spare minute
[13:47] <cjwatson> Keybuk: oss-compat> say hello to Hurd compatibility ;-)
[13:47] <ogra> babbage enablement is my highest prio atm
[13:47] <Keybuk> cjwatson: but all it does is add lines which are in our own alsa-base file
[13:47] <cjwatson> several packages seem to depend on it
[13:47] <broonie> cjwatson: TBF, I suspect it's more for the benefit of BSD.
[13:47] <cjwatson> mm
[13:48] <cjwatson> Depends: module-init-tools | modutils | hurd
[13:48] <Keybuk> cjwatson: I'll let crimsun sort that one out
[13:48] <cjwatson> ogra: this is certainly post-beta material
[13:49] <Keybuk> cjwatson: sane-backends and bluez-utils queued
[13:49] <ogra> ok, then i can do it, if there is a bug, please assign it to me
[13:49] <Keybuk> ogra: done
[13:49] <Keybuk> and thanks
[13:50] <ogra> thanks as well, i wasnt even aware i ever touched it
[14:03] <cellofellow> I installed libasound2-plugins from the source package to enable the JACK plugin, but apt keeps wanting to update it to the binary version. How do I edit the source so that the version number is higher so that apt won't update it?
[14:04] <ogra> could someone let redboot-tools out of NEW ?
[14:05] <mdz> seb128: what's the easiest way to trigger the gnome-keyring dialog?  I don't have a WPA network in KVM
[14:06] <pitti> mdz: use ssh?
[14:06] <pitti> mdz: connecting to an sftp or smb server should also trigger it
[14:06] <ogra> wohoo, babbage is in langpack installation !!
[14:06] <cellofellow> Current version of libasound2-plugins in both binary and source is 1.0.17-0ubuntu5. Can I change the version in the sourcecode to 1.0.17-0ubuntu5-1?
[14:07] <cjwatson> cellofellow: edit debian/changelog. You should make it .1 rather than -1 for technical reasons.
[14:07] <cellofellow> k
[14:07] <cjwatson> cellofellow: debian/changelog has a fixed format; you may want to install devscripts and use 'dch -v1.0.17-0ubuntu5.1' to edit it
[14:09] <mdz> pitti: thanks, connecting to an sftp server was the simplest
[14:09] <cellofellow> http://paste2.org/p/171047
[14:11] <cjwatson> cellofellow: look carefully and spot your typo
[14:11] <cellofellow> lol, thanks
[14:13] <cellofellow> what's the recommended package to build (every webpage I read has something different).
[14:14] <cjwatson> debuild
[14:14] <cjwatson> well, that's a command not a package, but you already have the relevant package installed
[14:15] <cellofellow> yeah, I mean't command
[14:16] <cellofellow> anyway to pass -j2 to make using debuild (dual threading)?
[14:17] <cjwatson> cellofellow: see the dpkg-buildpackage(1) manual page and note that you can generally pass dpkg-buildpackage options to debuild as well
[14:17] <maxb> cellofellow: DEB_BUILD_OPTS="parallel=2" I think
[14:17] <maxb> though this relies on the package's debian/rules interpreting it
[14:17] <cjwatson> the suggestion I made shouldn't rely on that
[14:18] <cellofellow> ok
[14:18] <cjwatson> dpkg-buildpackage(1) documents an alternative approach
[14:18] <cellofellow> um, got a gpg error
[14:20] <cjwatson> ignore it
[14:20] <cjwatson> use -uc -us options if you would prefer not to get it in future
[14:25] <cellofellow> well, thanks guys, no more annoying Update Notifier bugging me to update.
[14:26] <mdz> cjwatson: is the status of bug 44194 correct, i.e. there is still work needed in openssl and wpasupplicant?
[14:31] <cjwatson> mdz: work's still needed in wpasupplicant. It's an error that the openssl task is still open; I'll fix that
[14:32] <cjwatson> oh, hmm, apparently I forgot to upload openssl
[14:33] <mdz> ok, so it's correct
[14:33] <mdz> that table is impossible to scan visually
[14:33] <cjwatson> I've uploaded openssl now. I think I forgot that because there was already a .upload file there from the previous PPA upload
[14:34] <mdz> .upload files are the devil's work
[14:34] <mdz> for each time they saved me from a harmless error, they have 10 times caused a grievous one
[14:37] <evand> pitti: I just tested usb-creator with today's ISO (sorry for taking so long, was caught up in ubiquity work), and it's working fine for me.  Do you have any more information?
[14:39] <pitti> evand: very little unfortunately, just what I wrote on bug 348078
[14:40] <mdz> Keybuk/cjwatson: in bug 341928, is it the fact that a /dev/block name is being returned that is causing the trouble?  or is that a separate issue?
[14:40] <evand> pitti: ok, I'll follow up there
[14:41] <pitti> evand: I attached an ls -lR, maybe there's some file missing?
[14:41] <Keybuk> mdz: it could be indicative of a more fundamental underlying problem
[14:42] <tkamppeter> pitti, I have prepared an Intrepid SRU to fix bug 345183. I have uploaded the changes to my LP BZR repository. Please merge them into the main Intrepid repo for CUPS and upload the package to -proposed. Thanks.
[14:42] <evand> pitti: do you still have the disk in question?
[14:42] <mdz> Keybuk: should it be a separate bug, or would fixing that fix 341928 as well?
[14:42] <Keybuk> mdz: I don't know
[14:42] <pitti> evand: yes, I didn't touch it since the boot test
[14:42] <Keybuk> there isn't enough information on the bug to tell
[14:43] <evand> pitti: could you dd it to a file and stick it somewhere I can pull from?  rookery?
[14:43] <pitti> evand: I could, but it's 1 GB, so it'll take a fair while with my 50 KB/s upstream
[14:44] <evand> gah
[14:44] <evand> nevermind then
[14:44] <pitti> evand: does usb-creator write an MBR and/or install-grub?
[14:44] <pitti> i. e. something I could check/upload on the first couple of MB?
[14:44] <evand> yes, the one from syslinux
[14:44] <evand> it should match /usr/lib/syslinux/mbr.bin
[14:45] <pitti> nice, is that really 404 bytes
[14:46] <cjwatson> mdz: the fact that a /dev/block name is being returned is the proximate cause
[14:47] <cjwatson> mdz: I'm going to look into it more after beta if Keybuk doesn't beat me to it
[14:47] <pitti> evand: sudo dd if=/dev/sdc bs=404 count=1 | cmp - /usr/lib/syslinux/mbr.bin
[14:47] <pitti> evand: says it's identical
[14:49] <evand> pitti: can you elaborate on it not booting?  Does it just sit there, does it give you an operating system not found error, does it give you any other error?
[14:49] <pitti> evand: the second
[14:49] <pitti> evand: in particular, I plug it in, choose the stick in the bios to be first priority, but it still boots from hard disk
[14:50] <pitti> tried it on two different computers
[14:50] <pitti> on those computers, my other USB stick with an ubiquity install boots fine
[14:50] <pitti> so I don't think I'm too dumb to drive the bios, or the bios is too dumb to boot from usb
[14:50] <pitti> evand: I added fdisk -l output to the bug
[14:50] <mdz> cjwatson: do you need access to a system with the appropriate controller?
[14:51] <evand> pitti: very odd
[14:51] <pitti> evand: I'll do an image to my local hard disk, then zero it out and start over again
[14:52] <evand> pitti: ok, thanks
[14:52] <pitti> evand: do you know if the partition type is any relevant here?
[14:53] <cyberix> Is this the right chanel for problems that might have been introduced by some architectural changes?
[14:53] <cjwatson> mdz: yes, it would be useful, although only if I can get full console-level access
[14:53] <cjwatson> mdz: inc. ability to boot arbitrary images
[14:53] <mdz> fader: can you arrange that for cjwatson?
[14:54] <evand> pitti: you might want to compare the VBR as well.  re partition type> looks ok
[14:54] <fader> cjwatson: Is this access to the certification hardware that you need?
[14:55] <cjwatson> fader: yes please. I have to go out now but will be back later
[14:55] <cjwatson> fader: post-beta though, I don't have time this week
[14:55] <pitti> evand: vbr?
[14:55] <fader> mdz, cjwatson: I will see what the process is to get all that access, as it needs to be worked through IS
[14:55] <evand> pitti: volume boot record
[14:55] <mdz> fader: all the more reason to start early, so that when he needs it, it's ready
[14:56] <fader> mdz: absolutely
[14:56] <mdz> fader: while you're talking to them, it would be worth exploring if we can grant access en masse
[14:57] <fader> mdz: I'm concerned about coordination of resources if there are a lot of people in there... we have to make sure that nothing gets rebooted while someone is working on it and that enough hardware is left to actually do the certification tests :)
[14:58] <evand> pitti: the code runs syslinux /dev/sdb1 as well as copies the syslinux mbr to the disk mbr
[14:59] <evand> as the latter case was necessary to deal with situations like the user having grub on there for whatever odd reason
[15:00] <mdz> fader: on the flip side, though, we never know who will need it and when, and the harder it is to get access, the less chance it will benefit developers
[15:01] <fader> mdz: True.  I will find out what the process is/should be as I don't know everything that's involved at the moment.
[15:02] <cr3> mdz: we have a locking mechanism in place where people can request access to a machine, which then gets locked when all the pending activities have been completed on the hardware
[15:02] <cr3> mdz: when a lock is acquired, a message is sent to the user who will then have to unlock it explicitly when done
[15:02] <cr3> mdz: during that time, all activities for that hardware will be enqueued and some might expire depending on the duration of the lock
[15:03] <pitti> evand: ah, did you use persistency?
[15:03] <pitti> evand: ISTR I used persistency two weeks ago, but not yesterday
[15:06] <superm1> slangasek, well i've talked to bryce about it, and given it made it past xorg server 1.6 freeze he advised that we go to xorg upstream before reverting their patches
[15:07] <superm1> now for mythbuntu disks, that means you can't really use them unless you are using Intel graphics or one of the closed drivers on the reboot, which is less desirable of course
[15:07] <evand> ah, that might be the difference
[15:07] <evand> I did indeed
[15:07] <evand> pitti: testing now without it
[15:08] <pitti> evand: just done, worked fine
[15:08] <pitti> evand: so, same .iso, same non-persistency mode, same usb-creator version
[15:09] <evand> very odd
[15:10] <jdstrand> mathiaz: hey, so on bug #305264 what in your opinion is needed to close it out? AIUI, gntuls is sitting in -proposed but probably shouldn't be pushed until the openldap SRUs for hardy and intrepid. Is this correct?
[15:11] <pitti> evand: where is that vbr thing? should I diff it (previous image vs. current stick)
[15:11] <mathiaz> jdstrand: agreed.
[15:12] <pitti> evand: for kicks, I'll try changing the partition type again
[15:12] <jdstrand> mathiaz: are you doing the openldap SRUs?
[15:13] <jdstrand> s/doing/doing and\/or planning on doing/
[15:14] <pitti> evand: ok, that wasn't it; ok, nevermind that one for now
[15:18] <ogra> could some archive admin let redboot-tools out of NEW ?
[15:18] <ogra> we need it on the babbage
[15:20] <mathiaz> jdstrand: hm - not at the moment.
[15:20] <mathiaz> jdstrand: that would require backporting the patch to intrepid and hardy version
[15:21] <mathiaz> jdstrand: although the patch is rather simple it may need some work for hardy
[15:21] <jdstrand> mathiaz: yes. I thought that is what we were talking about?
[15:21] <mathiaz> jdstrand: yes. So I can take a look at it.
[15:21] <jdstrand> mathiaz: ok excellent :)
[15:26] <davmor2> guys I got an issue with a samba share from hardy server.  If I use places/network I can see it I double click it and it changes to the workgroup,  I double click on that and I get told I don't have access.  However if I click on places/connect to server I can get it to function fine is this a known issue?
[15:30] <cbr> does ubuntu's xorg support KMS?
[15:36] <evand> pitti: if you dd the non-working image back on, and then run syslinux -s /dev/sdb1 (or whatever the right value is) does it then boot?
[15:43] <maco> cbr: dont know about xorg, but ubuntu's kernel doesn't
[15:46] <seb128> mdz: https://bugs.edge.launchpad.net/ubuntu/+source/gdm/+bug/348428 seems to be an issue similar to the one I was mentionning yesterday
[15:46] <seb128> "exaCopyDirty: Pending damage region empty!
[15:46] <seb128> *** glibc detected *** /usr/bin/X: double free or corruption (out): 0x0d73de98 ***
[15:46] <seb128> [15:46] <seb128> /lib/tls/i686/cmov/libc.so.6[0xb7ba8604]
[15:46] <seb128> /lib/tls/i686/cmov/libc.so.6(cfree+0x96)[0xb7baa5b6]
[15:46] <seb128> /usr/lib/libdrm_intel.so.1[0xb77e6837]
[15:46] <seb128> "
[15:47] <seb128> mdz: that seems a different one than yours
[15:47] <seb128> mdz: especially that in this case there is no suspend or resume and no reason for the clock to go backward
[15:47] <seb128> bryce, tjaalton: ^ is that a known issue?
[15:48] <seb128> the crash is a libdrm one
[15:48] <mdz> seb128: the problem turned out to be memory corruption, so it's hard to say whether it's related. could be fallout from that bug
[15:48] <seb128> well the timestamp corruption is only when the clock goes backward no?
[15:49] <seb128> there is no reason to have that on user switching is it?
[15:50] <cbr> maco: do you know whether i still need intelfb compiled for kms?
[15:51] <maco> cbr: i dont know, but i have an idea who would...let me see if i can catch him on jabber
[15:53] <maco> cbr: no, you don't
[15:53] <maco> cbr: still need CONFG_FB for termnal though, he says
[15:54] <cbr> oh, then i guess i didnt get my kms working
[15:54] <cbr> i only see a framebuffer with intelfb
[15:54] <cbr> without it, it switches off the screen
[15:58] <kees> seb128: the memory corruption starts with X.org has been running for >28 hours, and when a log message is generated
[15:58] <kees> i.e. the "seconds" count exceeds 5 digits.
[15:59] <seb128> I don't think it's my issue
[15:59] <seb128> I usually reboot daily
[15:59]  * kees nods
[16:04] <pitti> evand: trying
[16:07] <pitti> evand: it's really sdb1, not sdb? i. e. the partition, not the device?
[16:08] <evand> pitti: yes
[16:11] <tedg> slangasek: I remember you showed me some trick to make dch behave better, but I don't remember what the trick was... can you point me to it again?
[16:12] <cjwatson> DEBCHANGE_RELEASE_HEURISTIC=changelog is the usual main one
[16:12] <cjwatson> in ~/.devscripts
[16:13] <cjwatson> I recently discovered DEBCHANGE_MULTIMAINT_MERGE=yes as well, which is nice
[16:14] <tedg> cjwatson: Yes, that was it.  Thank you!
[16:15] <james_w> I'm starting to wonder why that is not default
[16:15] <james_w> and if the second does what I think then I think it definitely should be
[16:15] <pitti> yeah, it's one of those "unbreak it" settings
[16:15] <pitti> I have that as well
[16:15] <tedg> It's hazing for new debian packagers ;)
[16:15] <james_w> I fear it's just a case of the devscripts maintainers not wanting to annoy those who like the current way
[16:15] <cjwatson> james_w: likewise
[16:16] <james_w> cjwatson: are you not a devscripts maintainer?
[16:17] <slangasek> superm1: so is this a recent regression wrt mythbuntu, or was everyone just using intel or closed drivers for the alpha?
[16:18] <slangasek> superm1: and does this become a release notes item for beta, if we have to round-trip to upstream to get the underlying bug fixed?
[16:22] <cjwatson> james_w: no, sort of been meaning to get round to that
[16:22] <cjwatson> I think they'd add me if I asked, given they've nearly said so in the past :)
[16:22] <james_w> are you a lintian maintainer?
[16:22] <cjwatson> yes
[16:22] <james_w> ah, that's it
[16:22] <james_w> I can bring the issue up if you like
[16:23] <cjwatson> and debian-policy these days, because apparently I'm mad
[16:23] <cjwatson> wouldn't hurt
[16:23] <james_w> heh
[16:29] <cbr> maco: okay, kms terminal works now too.. it didnt yesterday but now it works.. anyway, Xorg still doesn't play ball
[16:29] <cbr> so i guess something in jaunty doesn't support it
[16:30] <cbr> installed latest xorg-intel stuff from xorg-edgers
[16:31] <maco> cbr: talk to bgamari. you wont find him in any ubuntu channels except #ubuntu because he's a fedora user, but he does some intel work with upstream and is who i usually ask (mostly just because we go to school together...)
[16:31] <cbr> i see
[16:31] <cbr> thanks
[16:32] <cjwatson> ogra: accepted redboot-tools
[16:33] <ogra> yay !!!
[16:35] <ogra> cjwatson, i have one odd issue on that babbge that enforces to shut down syslog, i assume we cant get proper installer logs with a clever preseed option anyway ?
[16:35] <cjwatson> you can do networked syslog
[16:36] <cbr> Default kernel mode setting to off, add configure flag to enable
[16:36] <cjwatson> log_host=foo log_port=bar I think
[16:36] <cbr> in intel driver 2.6.0 changelog
[16:36] <ogra> hmm, that would require a properly working NIC driver
[16:36] <cbr> i wonder what's the flag though
[16:36] <cjwatson> ogra: do you mean that you can't run syslog at all?
[16:37] <ogra> cjwatson, the kernel spills a ton of USB messages all the time ... that makes syslog/klog/debug grow to 100s of MB ...
[16:37] <ogra> which in the end makes the system hit oom
[16:38] <cjwatson> well, you're a bit stuffed then aren't you ;-)
[16:38] <cjwatson> unless you want to be creative and replace log-output and logger with things that write to files or something, but be careful with log-output's semantics
[16:41] <ogra> well, we'll need a relatively big howto for babbage install anyway ...
[16:41] <ogra> one part was to shut down syslog right at the start in beta
[16:41] <ogra> post beta the kernel should be quieter
[16:44] <mterry> Is http://summit.ubuntu.com/uds-karmic/interest/ working?  I registered on launchpad last week, but that page still says I haven't
[16:47]  * slangasek applauds cjwatson's debian-policy madness
[16:58] <ogra> can anyone remond me why casper removes the hwclock call on shutdown ?
[16:58] <ogra> *remind even
[16:59] <Keybuk> ogra: because you don't want a *Live CD* mucking around with the hardware clock of the machine it's into
[16:59] <Keybuk> the entire point is that you can try Ubuntu without changing your computer
[17:00] <Keybuk> last thing we want is "I tried Ubuntu, and my Windows clock is now wrong" types of bugs
[17:00] <ogra> hmm
[17:01] <calc> grr my disk is acting up again on my laptop, need to do a destructive disk test on it :\
[17:01] <ogra> Keybuk, my prob on the babbage is that it has no battery to keep the clock ... the capacitor used only holds power for a very short time
[17:02] <Keybuk> so it's not going to help you anyway
[17:02] <ogra> well, it would if i could just reboot to have it right
[17:06] <calc> at least now i get to play with the new security erase feature... easy way to write to all sectors to hopefully kick smart into fixing whatever is wrong
[17:10] <cbr> hmm.. seems like Xorg is completely oblivious of KMS stuff going on.. the intel driver change log says that it's supposed to automagically enable UXA and everything should be dandy
[17:10] <cbr> but it aint :(
[17:11] <cjwatson> ogra: can you give me a one-line description of the computers that will run this imx51 image?
[17:12] <cjwatson> ogra: like for plain armel, we say "For ARMv5t processors and above."
[17:12] <ogra> i'm not sure we should mention the manufacturer ...
[17:12] <ogra> its only running on the babbage boar atm
[17:12] <ogra> *board
[17:12] <superm1> slangasek, this is a recent regression, but since a lot of people generally use closed drivers, it wasn't caught until recently.  i think it has to either become release notes item for beta or beta get deferred. still haven't decided what's the better way to go about it
[17:13] <cjwatson> ogra: I don't mind what we say, just need a description for the web site :-)
[17:14] <ogra> yeah, i know ... but just "babbage board" might be to less
[17:14] <slangasek> superm1: unless you expect a fix to be in the pipe by this weekend, I would certainly suggest the release notes option
[17:14] <cjwatson> ogra: I can just say "iMX51 systems" or something
[17:14] <slangasek> and even then, you'll be dealing with all of the suddenly-unfrozen stuff landing when you'd be trying to do your beta
[17:14] <broonie> cjwatson: That's normally misleading, it'll depend very strongly on which i.MX51.
[17:15] <ogra> cjwatson, there are more imx51 SoCs ... it will only run on the babbage
[17:15] <superm1> slangasek, OK well i'll discuss with our folks more.  i mean there is the fix in the pipe of reverting those 3 patches, but probably do need to hear what upstream has to say about it before doing so
[17:15] <broonie> cjwatson: Based on what ogra's just said how about "i.MX51 based babbage board"
[17:16] <ogra> broonie, sounds good
[17:17] <superm1> bryce, do you know if the author of those patches, Eric Anholt I think is on IRC at all?  i've not gotten any feedback on the upstream bugs or mailing list posts, so at least getting his opinion on the matter would be good i think
[17:21] <cjwatson> ogra: http://cdimage.ubuntu.com/custom/20090325-armel+imx51/ should appear shortly
[17:22] <ogra> cjwatson, i havemt confirmed the preseed fix yet
[17:22] <cjwatson> ogra: that's OK, we can publish another one
[17:22] <ogra> (and havent added the change to the script)
[17:22] <ogra> ah, k
[17:23] <ogra> thanks then
[17:23] <cjwatson> please check that the HTML index is suitable
[17:23] <seb128> re
[17:23] <seb128>  ok, so how do I valgrind X? ;-)
[17:23] <seb128>  valgrind doesn't like the X binary setuid
[17:23] <ogra> that will make elmo happy, another 800M less on my home pn people :)
[17:23] <ogra> *on
[17:23] <seb128> slangasek, mdz: ^ any hint? ;-)
[17:23] <mdz> seb128: just make it not setuid :-)
[17:24] <mdz> and let gdm start it
[17:24]  * slangasek nods
[17:24] <mdz> seb128: slangasek provided a recipe in bug 328035
[17:24] <seb128> mdz: I did follow the recipe and hit the setuid issue
[17:24] <seb128> but I picked the wrong option
[17:25] <slangasek> I overlooked the setuid part when I was writing the recipe blindly, sorry
[17:25] <seb128> tried to set valgrind setuid which didn't work
[17:38] <ogra> cjwatson, hmm, the cd burning guide surely doesnt apply to the .img :)
[17:40] <seb128> hum
[17:40] <ogra> cjwatson, the text from http://cdimage.ubuntu.com/ubuntu-netbook-remix/daily-live/current/ would fit better
[17:40] <seb128> no luck valgrinding X, the log are almost empty
[17:41] <cjwatson> ogra: feel free to edit directly on antimony
[17:41] <cjwatson> cdimage/www/full/custom/...
[17:41] <ogra> ok
[17:41] <cjwatson> yeah, I should have remembered to copy from something mobile-shaped
[17:42] <ogra> well, it technically isnt a USB image either
[17:42] <ogra> i guess i need to write a SD card guide :)
[17:45] <ogra> gah, the "detecting hardware" part in ubiquity makes my heart stop every time for a beat ... i always think the board crashed
[17:45] <seb128> slangasek, mdz: I've something weird, the log got created and have the command which is ran
[17:45] <seb128> but
[17:45] <seb128>  2531 tty7     Rs+    0:43 X.copy :0 -br -audit 0 -auth /var/lib/gdm/:0.Xauth -nolisten tcp vt7
[17:45] <ogra> (he barbershop animation in the progressbar gets stuck)
[17:45] <seb128> not valgrind in the process list
[17:50] <ogra> cjwatson, hmm, ubiquity failed again at the bootloader step ...could it be that the preseed option is ubiquity/configure_bootloader=false instead (or install_bootloader and configure_bootloader)
[17:56] <BlackLukes> is there anyone who's active in ubiquity development?
[17:57]  * ogra points BlackLukes to #ubuntu-installer
[18:03] <cjwatson>         install_bootloader = self.db.get('ubiquity/install_bootloader')
[18:03] <cjwatson>         if install_bootloader == "true":
[18:03] <cjwatson> ogra: ^-
[18:04] <ogra> yeah
[18:04] <ogra> (i moved over to the appropriate channel btw :) )
[18:13] <seb128> slangasek, mdz: is xorg supposed to start in a reasonable time under valgrind?
[18:14] <seb128> when I "sudo valgrind X :1" it doesn't seem to do a lot, or it's taking ages
[18:22] <directhex> am i right in thinking usplash is on death row, given kernel modesetting magicks?
[18:22] <TheMuso> directhex: I believe it will be replaced by plymouth in karmic yes
[18:23] <directhex> no point filing a "this sucks" bug of any kind, then?
[18:23] <mrooney> "deprecated row" sounds a little nicer :)
[18:25] <directhex> hm. is jono or jcastro about?
[18:25]  * jono looks up
[18:26]  * mrooney waves at jono
[18:26] <directhex> jono, can we move to /msg?
[18:26] <jono> directhex, sure
[18:26] <jono> hey mr_pouit
[18:27] <jono> oops
[18:27] <jono> hey mrooney
[18:27] <mrooney> jono: just waving at you, saying hello :)
[18:27] <mrooney> I'd say good morning but it probably isn't for you
[18:28] <pitti> james_w: got a minute to ponder bug 275432?
[18:28] <pitti> james_w: my gut feeling is that we should't assume a default configuration if only libpolkit2 is installed
[18:28] <pitti> james_w: I'd much rather fix CK itself to get along with PK not being available, and just act as if PK support wasn't compiled in in the first place
[18:29] <pitti> james_w: i. e. continue to run, but disable the reboot/shutdown functions
[18:29] <pitti> james_w: WDYT?
[18:34] <Laney> how do I go about getting/using people.ubuntu.com hosting? Or is it for canonical types only?
[18:35] <cjwatson> Canonical-only at the moment I'm afraid
[18:37] <sladen> Laney: bug #149560 IIRC
[18:38] <LordKow> that shouldnt be too hard considering all that needs to be done is switch the DNS info
[18:38] <LordKow> same server as far as ping tells me
[18:39] <LordKow> except there will be a lot of broken links which at first i forgot about
[18:39] <LordKow> euw, okay nevermind. i go back to building vlc snapshots now.
[18:41] <Laney> cjwatson, sladen: alright, thanks
[18:56] <ScottK> mvo: Thank you very much for your python-central change.  I think that will clarify a lot.
[19:13] <slangasek> seb128: I wouldn't promise 'reasonable time', no...
[19:14] <seb128> slangasek: I stopped trying to get it working, it stays on an empty screen and valgrind is not listed in the processes list
[19:17] <mvo> ScottK: cheers, I was suspecting that the reporting was not 100% reliable, now it should be better. I have a zope3 update pending for the other half of the bug, but want to have doko check the diff out before I go ahead with the upload
[19:20] <\sh> guys, should tail -f <apache-logfile> occupy at least 100% of cpu while tailing the logfile when 6 clients are poking apache with 150 concurrent requests? the load goes up straight to heaven when tail is running...and top tells me that one core of eight is fully loaded with 100% work
[19:21] <\sh> (no x included...just plain console)
[19:21] <broonie> That doesn't sound entirely suprising.
[19:23] <\sh> broonie: for me it was surprising
[19:24] <broonie> The terminal app will be updating the screen as fast as it can possibly go.
[19:25] <\sh> broonie: you are talking of the vt1-4 linux console...I thought it still pushes the bytes over irq <whatever> instead of painting the characters ,-)
[19:25] <broonie> No, I was thinking of an X11 terminal application.
[19:26] <\sh> broonie: as said, no x involved
[19:26] <\sh> broonie: it's intrepid server (better: ubuntu-minimal meta)
[19:26] <broonie> Though if it's a framebuffer rather than text console it's kind of the same deal.
[19:27] <\sh> bah...now a beer for the magic kernel append param to disable framebuffer and just giving me the old text console
[19:30] <\sh> sometimes life could be so easy fb=false will be my friend
[19:36] <\sh> actually it helped a bit but still
[19:44] <\sh> ok tail is not a good idea ... tail output enabled: load goes up to 5 without tail only 2 cores are fully busy...fun I love stress testing
[19:44] <\sh> load without tail <= 2
[19:45] <broonie> You're asking for an awful lot of I/O with tail - look at the volume of logging!
[19:53] <\sh> broonie: that was just a sideeffect of initial setup testing ;) so tail is already forgotten
[21:26] <james_w> pitti: that sounds sensible. It's not so much a problem now, except that it says "CRITICAL", when it isn't particularly.
[21:27] <james_w> pitti: fixing policykit here is hard, so I think making consolekit more forgiving would be good.
[21:29] <james_w> pitti: have you spoken to Michael about it? he has a pretty good grasp of the situation. I'm wondering if we shouldn't pull consolekit apart and create shutdownkit, which would seem to avoid some of this silliness
[21:30] <directhex> not enough Kits
[21:30] <james_w> in this case it is warranted I would say :-)
[21:32] <tkamppeter> directhex, should I really rename Foomatic to PrintingKit :-)
[21:32] <slangasek> I know there's a better pun hiding somewhere behind the name "ShutdownKit"
[21:33] <directhex> tkamppeter, how much cash for such a rename?
[21:33]  * directhex continues to insist the Kit thing is shamelessly ripped off from BeOS
[21:33] <tkamppeter> Who is the copyright holder of "...Kit"?
[21:33] <james_w> DavidKit
[21:34] <directhex> tkamppeter, http://en.wikipedia.org/wiki/BeOS_API
[21:35] <directhex> translation kit, now that was awesome
[21:42] <rniamo> hi
[21:43] <rniamo> i'm under jaunty and i have no sound (maybe because i have a intel hda soundcard) but i have no sound server (alsa, oss are not present, i have only the null driver of pulseaudio)
[21:43] <calc> rniamo: which sound codec do you have?
[21:44] <rniamo> sound codec ?
[21:44] <rniamo> i'm not sure to understand
[21:44]  * calc looks for the path
[21:44] <calc> rniamo: something like /proc/asound/card0/codec#(number)
[21:45] <rniamo> i don't have /proc/asound
[21:45] <calc> oh i see :\
[21:45] <calc> you apparently don't have alsa loaded at all
[21:45] <calc> dtchen: ^ ?
[21:45] <rniamo> i only have the null driver
[21:46] <calc> i'm pretty sure even if it doesn't recognize your codec you should have that much of alsa loaded to see /proc/asound
[21:46] <calc> so i am not sure what is wrong
[21:46] <calc> TheMuso: you here? ^
[21:47] <TheMuso> rniamo: what audio devices are listed when you run lspci? Please pastebin the result of your lspci output if you don't know what you are looking for exactly.
[21:48] <rniamo> TheMuso : intel hda
[21:48] <rniamo> 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 02)
[21:48] <calc> TheMuso: thanks for taking over :) i'm busy trying to unbreak my laptop atm :\
[21:48] <TheMuso> ian_brasil: when you run lsmod, do you have snd_intel_hda loaded? Oh and what version of Ubuntu are you using?
[21:48] <TheMuso> ion_: when you run lsmod, do you have snd_intel_hda loaded? Oh and what version of Ubuntu are you using?
[21:49] <rniamo> no
[21:49] <TheMuso> ian_brasil: sorry
[21:49] <rniamo> i'm using jaunty
[21:49] <TheMuso> rniamo: So no /proc/asound, and no snd related modules loaded at all?
[21:49] <rniamo> yes
[21:50] <rniamo> libsound and alsa are installed
[21:50] <calc> rniamo: did you just now do a full jaunty install, and which *buntu did you install via?
[21:50] <Errorist> greetings!
[21:50] <TheMuso> rniamo: Could you please download http://www.alsa-project.org/alsa-info.sh, run it, and opst the URL you are given?
[21:51] <rniamo> i ran alsaupdater and afterwards no driver
[21:51] <Errorist> and what's the matter?
[21:51] <TheMuso> rniamo: But could you please download the script I referred you to, and post the URL you get?
[21:52] <rniamo> i'm doing it
[21:53] <Errorist> got troubles with audio drivers/codecs?
[21:53] <calc> Errorist: TheMuso is helping rniamo debug his system where no alsa drivers are loaded
[21:53] <calc> doh
[21:53] <rniamo> http://www.alsa-project.org/db/?f=e7fa52ff8e1582503adb189f865c39f1cdd2827 ... nothing ?
[21:53] <slangasek> pitti: are you still planning to address bug #264336 in postgresql.conf for jaunty?
[21:54] <rniamo> ah, sorry : http://www.alsa-project.org/db/?f=e7fa52ff8e1582503adb189f865c39f1cdd28274
[21:54] <TheMuso> rniamo: thanks looking
[21:55] <johanbr> rniamo: "alsaupdater" ?
[21:56] <rniamo> yes, il download tar.gz (alsa-driver/utils/ and another one) and compile it
[21:56] <TheMuso> rniamo: according to this, you have 1.0.16 of libasound2-dev installed. Is your system completely up to date?
[21:56] <calc> rniamo: oh so you mean you broke it yourself?
[21:56] <rniamo> probably
[21:56] <calc> rniamo: you get to keep both pieces ;-)
[21:56] <rniamo> yes my system is up to date
[21:57] <TheMuso> rniamo: have you built any modules against the kernel you have installed?
[21:57] <calc> rniamo: so it worked until you manually rebuilt the parts with 'alsaupdater'?
[21:57] <rniamo> TheMuso : non
[21:57] <rniamo> calc : yes
[21:57] <calc> TheMuso: is 'alsaupdater' something that is supported?
[21:58] <TheMuso> calc: I don't even know what alsadata is.
[21:58] <rniamo> i don't think
[21:58] <calc> TheMuso: it appears he is saying he updated his alsa from tarballs and it broke
[21:58] <TheMuso> Well thats not our problem.
[21:59] <TheMuso> Because according to the kernel source, his machine is supported, and even has a quirk to make sure it works properly.
[22:00] <calc> TheMuso: ok
[22:00] <rniamo> in fact i wanted to install alsa from the source because i had drivers but no sound
[22:01] <TheMuso> rniamo: Did you check your volume with alsamixer first?
[22:01] <rniamo> yes
[22:01] <rniamo> evrything was at 100% in alsamixer
[22:01] <calc> rniamo: if you can get your system back into default state then TheMuso can probably get it working... but using tarballs there is no telling what is wrong
[22:02] <rniamo> tarballs where offical alsa tarballs
[22:03] <directhex> installing from tarballs is ~unzipping into c:\windows\system32
[22:03] <calc> rniamo: yes but they probably don't match what we have kernel-wise, etc
[22:03] <rniamo> well, can i install a deb to reinstall alsa driver ?
[22:03] <rniamo> or reconfigure something ?
[22:04]  * calc has no idea, TheMuso ? :)
[22:04] <calc> well yea you can fix it but i don't know what all packages you would have to force reinstall
[22:04] <TheMuso> rniamo: Ok what directories are in /lib/modules/2.6.28-11-generic?
[22:04] <TheMuso> Its probably a matter of removing the newer modules from the kernel modules dir, running depmod -ae, and attempting to load the hda module.
[22:05] <rniamo> build              modules.ccwmap       modules.isapnpmap  modules.symbols initrd             modules.dep          modules.ofmap      modules.symbols.bin kernel             modules.dep.bin      modules.order      modules.usbmap modules.alias      modules.ieee1394map  modules.pcimap     updates modules.alias.bin  modules.inputmap     modules.seriomap   volatil
[22:05] <rniamo> initrd, kernel, updates, vlatile are directories
[22:07] <TheMuso> whAT do you have in updates?
[22:07] <rniamo> adm8211.ko       iwl3945.ko              libertas_tf.ko      rt2500usb.ko at76c50x-usb.ko  iwlagn.ko               libertas_tf_usb.ko  rt2x00lib.ko ath5k.ko         iwlcore.ko              libipw.ko           rt2x00pci.ko ath9k.ko         lbm_cw-cfg80211.ko      mac80211_hwsim.ko   rt2x00usb.ko b43.ko           lbm_cw-mac80211.ko      mwl8k.ko            rt61
[22:07] <rniamo> dkms is a directory
[22:08] <TheMuso> hrm I don't see any new alsa modules where I'd expect them to be...
[22:08] <TheMuso> do a search for snd_hda_intel.ko in /lib/modules/2.6.28-11-generic
[22:08] <TheMuso> so "find /lib/modules/2.6.28-11-generic -name snd_hda_intel.ko"
[22:08] <rniamo> ok
[22:09] <rniamo> nothing
[22:09] <calc> so it removed the alsa that was there and didn't install a new one?
[22:09] <rniamo> probably
[22:09] <TheMuso> sorry thats because i gave you the wrong name
[22:10] <TheMuso> it should be snd_hda_intel.ko
[22:10] <rniamo> what's the difference ?
[22:10] <TheMuso> that should be snd-hda-intel.ko
[22:10] <rniamo> ok
[22:10] <TheMuso> damn lsmod and using underscores, with modules having dashes in filenames.
[22:10] <directhex> why IS that?
[22:11] <directhex> i never worked out the point
[22:11] <TheMuso> directhex: me neither. :p
[22:11] <rniamo> nothing but : /lib/modules/2.6.27-9-generic/kernel/sound/pci/hda/snd-hda-intel.ko /lib/modules/2.6.27-11-generic/kernel/sound/pci/hda/snd-hda-intel.ko /lib/modules/2.6.27-7-generic/kernel/sound/pci/hda/snd-hda-intel.ko
[22:11] <calc> directhex: to confuse people better :)
[22:12] <cjwatson> you can modprobe using either style, of course
[22:12] <directhex> i see an obvious solution
[22:12] <TheMuso> rniamo: Well if you installed from the alsa-driver tarball, I don't know what the problem is, but all I can suggest is you re-install linux-image-2.6.28-11-generic: "sudo apt-get --reinstall install linux-image-2.6.28-11-generic"
[22:12] <directhex> fork "find" to match - or _ interchangably
[22:13] <rniamo> ok, i'll try
[22:13] <rniamo> do i have to reboot after or not ?
[22:14] <TheMuso> rniamo: probably not, just try "sudo modprobe snd-hda-intel"
[22:15] <rniamo> the ko is here :)
[22:15]  * calc wishes ata security erase had a way to monitor progress
[22:15] <rniamo> alsamixer is back :):)
[22:15] <TheMuso> rniamo: BUt still no sound?
[22:16] <rniamo> i'm looking for some sound
[22:16] <directhex> ehm
[22:16] <directhex> if i might make a suggestion
[22:16] <TheMuso> rniamo: try /usr/share/example-content/
[22:16] <bryce> superm1, yes, 'anholt' is on the #xorg-devel channel on this server.  I think there is also an intel X channel he's active on.
[22:16] <rniamo> ok
[22:17] <TheMuso> directhex: And your suggestion is? :)
[22:17] <directhex> in alsamixer, do you see any controls named something like "IEC958"?
[22:17] <directhex> it'll be a little toggle, i.e. have no volume knob
[22:17] <TheMuso> directhex: ah right
[22:17] <directhex> mute/unmute it (i.e. change its current value)
[22:17] <TheMuso> afaicr thats not set by default
[22:17] <bryce> superm1: sorry I'm laggy in responding; I took today off so have been afk
[22:18] <directhex> TheMuso, some mobos the default is digital
[22:18] <TheMuso> directhex: ah
[22:18] <directhex> TheMuso, hence "toggle" not "disable"
[22:18] <TheMuso> yep
[22:19] <rniamo> in alsamixer how do i save settings ?
[22:19] <rniamo> esc ?
[22:19] <directhex> yes
[22:19] <rniamo> because master is to 0%, i set it to 100 then i retype alsamixer and master is to 0
[22:21] <TheMuso> hrm
[22:21] <TheMuso> rniamo: try rebooting and changing alsamixer settings again, something is probably trying to change sound settings while you are...
[22:21] <TheMuso> c
[22:21] <rniamo> ok, i'm coming back ;)
[22:23] <TheMuso> ok
[22:26] <rniamo> re
[22:27] <rniamo> TheMuso : i reboot and everything is at 100% ... and i hear no sound
[22:31] <rniamo> http://mibbit.com/pb/rk9Lbk is my codec
[22:31] <TheMuso> rniamo: if you go into alsamixer, change the master, exit, and go back in again, is it back to 0?
[22:32] <rniamo> no
[22:32] <TheMuso> ok thats good
[22:32] <rniamo> it's work after a reboot, but i hear no sound
[22:33] <TheMuso> rniamo: ok please run http://www.alsa-project.org/alsa-info.sh again and give me a URL. I also suggest you file a bug against linux, and give me the bug number with the alsa URL included in the report.
[22:34] <rniamo> http://www.alsa-project.org/db/?f=2e77d90e8b79ab301e5c353a49e752185875f8eb
[22:34] <rniamo> file a bug ?
[22:35] <calc> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/318942
[22:35] <calc> rniamo: does headphones work for you?
[22:35] <directhex> 3stack
[22:35] <directhex> hm
[22:35] <rniamo> i'll try headphones
[22:35] <directhex> rniamo, how many audio connections do you have on the back of your motherboard?
[22:36] <calc> the only google hits i get for his audio codec are problems, heh
[22:36] <directhex> looks a bit likt eh codec on my laptop
[22:36] <rniamo> only one connection, it's a hp mini compaq
[22:37] <directhex> so it IS a laptop
[22:37] <calc> rniamo: ah so it is probably the same bug i referenced above
[22:37] <calc> the bug is about the hp mini 1000 netbook
[22:37] <calc> it appears alsa 1.0.19 might fix this issue
[22:38] <calc> according to the bug report
[22:38] <directhex> sigh, usplash depresses me
[22:38] <rniamo> ok but to install it , it must be compiled, no ?
[22:38] <calc> rniamo: that was more a comment to TheMuso :)
[22:38] <calc> rniamo: see if the headphones bit works for you
[22:38] <slangasek> calc: what's the current story for OOo on sparc?
[22:39] <slangasek> it's the only package attached to a couple of the NBS packages
[22:39] <calc> slangasek: almost always ICEs for Ubuntu... works on Debian (has been this way for years)
[22:39] <rniamo> headphones doesn't work
[22:39] <calc> slangasek: i'm not sure if it is a buildd issue or a toolchain issue though
[22:39] <directhex> my laptop has an IDT 92HD71B7X
[22:39] <directhex> close but no cigar
[22:39] <slangasek> calc: "almost always"?  So we fix this by randomly retrying until it sticks, or what?
[22:39] <slangasek> currently it's a full major version behind
[22:39] <slangasek> well, "major"
[22:40] <calc> slangasek: dunno maybe 10% of the time it seems to build
[22:40] <calc> slangasek: i probably should fix OOo to not build on sparc and then have the packages removed for it
[22:40] <slangasek> I guess so :(
[22:41] <directhex> the sad fact is, sun just don't seem to understand sparc enough for OOo to work properly ;)
[22:41] <calc> if someone with more sparc toolchain experience wants to look into it they can, it works fine on Debian so i'm not sure why it dies for us
[22:41] <calc> directhex: its either a toolchain bug or the buildd
[22:41] <calc> directhex: it works fine on Debian
[22:42] <calc> directhex: ICEs are not the software that is being compiled fault
[22:42] <rniamo> do i have to change model afterwards options snd-hda-intel ?
[22:43] <directhex> rniamo, tinkering with model= can sometimes help. what does calc's bug say?
[22:43] <slangasek> calc: what is bug #271283 a regression relative to?
[22:43] <calc> the bug i see is about 2.6.28-4 i386 that claimed at that point to work with headphones
[22:43] <slangasek> (I don't think 'regression' is one of the standard tags QA tracks; we use 'regression-potential' or 'regression-release')
[22:44] <calc> slangasek: ah i didn't know what the right tag was, it worked fine in Hardy but does not work anymore
[22:44] <slangasek> so if it was also broken in intrepid, 'regression-release' is the right tag
[22:44] <slangasek> calc: https://wiki.ubuntu.com/QATeam/RegressionTracking, for reference
[22:44] <calc> it was broken with a new upload of cairo shortly before intrepid release
[22:45] <calc> ok updated tag
[22:45] <rniamo> how could i do after changing model to load it without a reboot ?
[22:45] <TheMuso> rniamo: one more thing to try is to do "sudo apt-get --reinstall install libasound2-dev libasound2"
[22:45] <TheMuso> rniamo: since you appear to only have 1.0.16 of the libraries
[22:45] <slangasek> calc: thanks
[22:46] <TheMuso> rniamo: then try logging out and back in, to see if you get sound
[22:46] <TheMuso> rniamo: try my suggestion first, before trying the model option.
[22:46] <rniamo> ok
[22:49] <rniamo> before logging out i have a little question : why under jaunty ctrl+alt+backspace doesn't work ?
[22:49] <TheMuso> rniamo: its been disabled for jaunty. Someone else can point you to the explanation, I don't know where to find it atm.
[22:50] <rniamo> ok
[22:50] <lool> I'd love someone with a taste for python to review the proposed patch at https://bugs.launchpad.net/ubuntu/+source/python-debian/+bug/339466
[22:50] <rniamo> i'm logging out and i'm coming back
[22:52] <rniamo> re
[22:53] <rniamo> TheMuso : http://www.alsa-project.org/db/?f=528ed8b854877742974fb68716bac751a50267e3 it's better but still no sound
[22:54] <TheMuso> rniamo: ok then either add a comment to the bug calc referred you to above, or if you think your situation is different, consider filing a new bug. Also try different model options./
[22:54] <rniamo> this is strange : http://mibbit.com/pb/5mHOPc
[22:55] <dtchen> you're not in the audio group
[22:55] <dtchen> also, you should try the appropriate test kernel from http://kernel.ubuntu.com/~dtchen/
[22:55] <dtchen> i believe i've already pulled the necessary fix for the HP Minis
[22:56] <rniamo> i'm in the audio group
[22:56] <cjwatson> calc: the other thing that might differ between us and Debian is compiler flags
[22:56] <rniamo> dtchen : i don't understand what are this deb ?
[22:57] <cjwatson> though actually I think our default compiler flags are the same as Debian's, so it would just be if the openoffice.org source sets them differently
[22:58] <calc> cjwatson: i'm pretty sure we don't differ significantly there in OOo rules
[22:58] <dtchen> rniamo: you need this changeset: http://kernel.ubuntu.com/git?p=dtchen/ubuntu-jaunty.git;a=commitdiff;h=9797e05d142312ec0f4a8a0fd66d68bf4555b942 , which is in my debs. (my debs also contain hw_ptr fixes for PulseAudio, but that's a separate issue)
[22:58] <rniamo> ok, i'm trying
[22:59] <rniamo> i suppoe i have to reboot ;)
[22:59] <rniamo> suppose
[22:59] <dtchen> well, yes
[22:59] <greg-g> heh
[22:59] <rniamo> si let's reboot ;)
[23:00] <dtchen> rniamo: please follow up with me in #ubuntu+1 if you have issues, as this symptom is not specific to Ubuntu development. Thank you.
[23:03] <rniamo> re
[23:03] <rniamo> headphones work !!!!!!!!!
[23:04] <rniamo> but not front
[23:05] <cjwatson> calc: in general, the first thing to experiment with for ICEs does seem to be optimisation levels, if only because it usually significantly helps to localise the compiler bug
[23:05] <cjwatson> obviously you'd want to reduce it down to something resembling a small test case first, unless you want it to take all year
[23:05] <calc> yea
[23:06]  * calc wonders how much ubuntu sparc compiler differs from debian's
[23:06] <cjwatson> gcc-4.3 (4.3.3-5ubuntu1) jaunty; urgency=low
[23:06] <calc> its been fairly consistent at ICEing over the past couple years
[23:06] <cjwatson>   * Merge with Debian; remaining changes:
[23:06] <cjwatson>     - Built from upstream tarball, regenerate the control file.
[23:06] <cjwatson>     - On armel, configure using --with-arch=armv5t --with-tune=cortex-a8.
[23:06] <cjwatson>  -- Matthias Klose <doko@ubuntu.com>  Sun, 01 Mar 2009 17:06:09 +0100
[23:06] <cjwatson> so I would say not hugely ...
[23:07] <rniamo> dtchen : does your patch work for front speakers ?
[23:07] <cjwatson> getting a small test case will help a lot, I should think
[23:07] <calc> cjwatson: yea, i'll see if i can find a way to reduce it to a test case
[23:07] <dtchen> rniamo: depends whether you booted with or without them plugged
[23:07] <rniamo> dtchen : well, can you explain me a little bit more please ?
[23:07]  * calc hopes running the security erase helped to remap his bad sectors or fix whatever else was wrong with the drive
[23:08] <dtchen> rniamo: i'm happy to discuss in #ubuntu+1
[23:08] <rniamo> ok
[23:09] <LordKow> gnome-settings-sound.desktop from capplets-data and gnome-volume-control-settings.desktop from gnome-volume-control-pulse both have the name "Sound" :-/
[23:12] <seb128> LordKow: right they are the GNOME 2.24 and 2.26 equivalent softwares
[23:13] <seb128> LordKow: you are not meant to use both and only one is installed by default
[23:25] <LordKow> seb128, capplets-data: Candidate: 1:2.26.0-0ubuntu1, gnome-volume-control-pulse: Candidate: 2.26.0-0ubuntu2 :-/ they are not the same and provide different options/settings
[23:27] <seb128> LordKow: ...
[23:27] <seb128> LordKow: as I said they are the GNOME 2.24 and 2.26 equivalents
[23:28] <seb128> LordKow: the 2.26 variants works only on pulseaudio and pulseaudio just doesn't work for many users so we didn't want to hard depends on it
[23:28] <LordKow> ah okay.
[23:29] <seb128> LordKow: so we use the 2.24 tools which work with alsa only too and have the pulse variant available for those who really want it
[23:30] <LordKow> and with that being settled... time to boot a test kernel.
[23:30] <rniamo> dtchen : it doesn't work
[23:31] <dtchen> rniamo: remove the quirk altogether, then
[23:32] <rniamo> i try with hp-m4 and without options snd-hda-intel model=xx
[23:32] <dtchen> rniamo: i will follow up in the bug report; i'm very busy ATM
[23:33] <rniamo> it is not urgent, thanks for your help
[23:33] <rniamo> where could i look to know if it an update will correct it ?
[23:35] <dtchen> rniamo: i will follow up in the bug report named above (318942)
[23:35] <rniamo> ok, thank you very much
[23:53] <rniamo> dtchen : i've installed als-driver 1.0.19 = everything is ok :D
[23:54] <rniamo> TheMuso : will alsa-driver 1.0.19 be included in next kernel ?
[23:54] <TheMuso> rniamo: no
[23:55] <TheMuso> alsa 1.0.19, or even alsa 1.0.20 will be in Karmic.
[23:55] <rniamo> and for jaunty it will be "only" 1.0.18 ?
[23:56] <TheMuso> yes
[23:56] <TheMuso> but with some fixes pulled from 1.0.19
[23:57] <rniamo> ok. becase 1.0.19 works fine
[23:57] <rniamo> becase sorry
[23:57] <rniamo> because
[23:58] <rniamo> good night everybody, see you.