[00:29] <GrueMaster> Not sure if this is an ubuntu repo issue or a moblin image creator issue, but creating a project target with "crownbeach-with-proprietary" hangs while trying to find either the marvel 8686 wireless firmware or the helix-cip-codecs.
[06:38] <persia> StevenK: I'm playing with the daily, and still getting a hard system hang in KVM whenever I run apt-get update.  apt-get install seems to work fine.  Any ideas as to what might be happening?
[06:39] <StevenK> persia: It locks up?
[06:40] <persia> Yes.  I can't seem to escape with any of the usual suspects (^c ^d ^z)
[06:41] <persia> Further, once this happens, I can't seem to change virtual terminals.  I'm not sure how to collect debug information, as I'm not getting a crash, and don't have access to the system post-hang for forensics.
[06:44] <StevenK> That's odd. Only update hangs?
[06:44] <StevenK> What about something requiring network access?
[06:44] <persia> No problem.  apt-get install downloads and installs anything I want.
[06:44] <persia> I'm using kvm -hda ubuntu-mid.img -hdb disk.img -m 512M -net nic -net user
[06:44] <StevenK> Okay, install strace and strace apt-get update?
[06:44] <persia> disk.img is a pristine 4G qcow2 image.
[06:46] <persia> Hmm.  Seems something related to Release.gpg
[06:47] <persia> Last call is rename("/var/lib/apt/lists/ports.ubuntu.com_ubuntu-ports_disks_intrepid_Release.gpg", "/var/lib/apt/lists/partial/ports.ubuntu.com_ubuntu-ports_dists_intrepid_Release.gpg.reverify"
[06:47] <persia> There's no close parenthesis or return code.
[06:49] <persia> This is with the 20080829 image, although I had a similar (less investigated) hang with 20080828.10
[06:49] <persia> Any ideas why this might happen in the live session?
[06:51] <StevenK> None :-(
[06:52] <persia> Right.  Have you tried the image on your hardware?  Does this happen there as well?
[06:55] <persia> Also, any ideas as to what layer this might occur at?  Generally I don't do much at this level, but I don't know if this is a filesystem issue or a libc issue, or something else.
[06:56] <persia> A simple mv seems to work, although I've not tried it on that file.
[06:59] <StevenK> Hm. Is gpg installed?
[06:59] <StevenK> Does gpg hang the VM?
[07:00] <persia> gpg is installed.  I'll download the release file, and try verification.
[07:00] <persia> gpg --verify Release.gpg Release works fine as the ubuntu user.
[07:01] <StevenK> Odd
[07:01] <persia> It can't find the public key for 437D05B5, but that's unrelated.
[07:01] <StevenK> Feed the no verify option to apt-get update and see?
[07:02] <persia> Calling mv to repeat the move file seems to work.
[07:03] <StevenK> I'm rsync'ing todays image to try the image on real hardware
[07:03] <StevenK> And see if X starts
[07:03] <persia> X doesn't start.
[07:03]  * StevenK hands persia back the pin he just used
[07:03] <persia> There's some issue with /etc/event.d/session: it respawns too quickly to get started.
[07:04] <StevenK> X doesn't start quick enough for upstart?
[07:05] <persia> Maybe, or maybe there's something else.  That's the second thing I want to fix, but not being able to run apt-get update seems to be the thing that is causing ubiquity to hang, and having ubiquity not hang is my first priority.
[07:06] <StevenK> Yeah, I'll poke at apt on real hardware when I have the image downloaded
[07:06] <persia> Running `startx -- -br` brings up the right session, so I'm not feeling the pain as much as for yesterday.
[07:06] <persia> Australia needs more fiber.
[07:06] <StevenK> Feel free to run it, I'll wait.
[07:07] <StevenK> :-P
[07:07] <persia> Probably faster for you to move somewhere with better bandwidth.
[07:08] <StevenK> That has its own complications
[07:08] <StevenK> Anyway, it's 80% done
[07:09] <persia> So how do I turn off GPG verification in apt again?  I know it's very likely with -o, but I don't see the relevant apt.conf option.
[07:14] <StevenK> Hmmmm.
[07:31] <StevenK> persia: Reproduced.
[07:31] <StevenK> It's strange, the terminal doesn't die, but it isn't so happy
[07:31] <persia> StevenK: Well, at least that means it's not just me.
[07:32] <persia> The terminal doesn't die?  How do you mean?
[07:32] <persia> The process doesn't end?
[07:32] <persia> Or that it still echoes keystrokes, and just ignores them (which is what I see)
[07:32] <StevenK> Yes
[07:33]  * persia learns not to ask "or" questions
[07:34] <StevenK> persia: It still echoes the keystrokes and does nothing about them.
[07:34] <StevenK> Which is odd
[07:36] <persia> Is it?  There's lots of conditions that generate that, including a non-terminating while loop.
[07:36] <persia> Mind you, CPU usage seems very low in this case, which confuses me.
[07:36] <StevenK> It should still listen to a SIGINT
[07:37] <persia> True.  That part is odd.  Can you also not change virtual terminals?
[07:39] <StevenK> No keyboard connected. Was about to fetch it
[07:42] <StevenK> persia: Please review maximus 0.3 on REVU at your leisure.
[07:42] <persia> Beats trying to understand why apt is hanging :)
[07:44]  * persia pokes REVU to find out why there isn't any maximus there
[07:45] <persia> StevenK: Where is it?  I don't see it either in the accepted packages or the rejected packages.
[07:45] <StevenK> persia: It's probably there now.
[07:45] <StevenK> persia: It was still uploading when I asked.
[07:45] <persia> Oh :)
[07:46] <StevenK> apt-get install doesn't work for me either
[07:46] <StevenK> They both hang in D
[07:46] <persia> Odd.  I can do apt-get install.
[07:47] <persia> You're using the 20080829 image?
[07:47] <StevenK> Yes
[07:47] <persia> Can you run apt-get install in KVM?
[07:47] <StevenK> Nope, because I can't run KVM
[07:48] <persia> Right.  Never mind.  Even with the kqemu modules, qemu is too slow
[07:51] <persia> More oddly, it works in a chroot.
[07:51]  * persia downloads the alternate install image to see if the problem is ubuntu-mid specific or architecture-specific
[08:06] <persia> StevenK: Do you really want to be the maintainer for this package?  Why not MOTU?  It's not in our seeds.
[08:12] <persia> Right.  Rescue-mode doesn't support apt-get until one executes a chroot into the target system.
[08:20] <StevenK> persia: MOTU works
[08:20] <StevenK> persia: I suspect I wasn't thinking
[08:20] <persia> Could be leftover fatigue from the pre-FF rush.
[08:21] <persia> I've some other comments, I'll send you the URL when I finish the compilation.
[08:21] <persia> Mostly issues with debian/copyright
[08:26] <persia> StevenK: http://revu.ubuntuwire.com/details.py?package=maximus commented
[08:38] <ogra> persia, you are aware that 2.6.26 has issues (mainly kernel oopses) with virtualization ? 
[08:39] <persia> ogra: For running within virtualised environments?  Also, that doesn't really explain that the problem could be replicated on real HW.
[08:39] <StevenK> persia: I tried to find the excerpt for GPLv3, and couldn't
[08:39] <ogra> oh, i didnt read the full backlog ... i just know that at least or kvm/quemu .27 solves that
[08:40] <ogra> *for
[08:40] <ogra> sadly not for vbox ... so i'm standing in the rain here
[08:42] <persia> ogra: .27 in the client, or in the host?
[08:42] <ogra> .27 isnt the improvement i hoped for at all :/ ... the wireless in the Q1 still doesnt work without madwifi ... the cam still doesnt work ...
[08:42] <ogra> client
[08:43] <ogra> bt at least the usplash progressbar isnt broken anymore on my laptop ... thats the only actual improvement i see over .26 for now
[08:43] <persia> StevenK: Starts on line 635 of /usr/share/common-licenses/GPL-3
[08:44] <persia> ogra: You're using GDM for session management, right?
[08:45] <persia> And yeah: I retested all my bugs against the kernel against .27 today, and none appear to be resolved.
[08:45] <ogra> yep
[08:50] <persia> ogra: And you're running lpia, right?
[08:52] <ogra> nope
[08:52] <ogra> my laptop is a core2duo ... why should i run lpia
[08:52] <persia> I meant for ubuntu-mobile on your smaller device.
[08:53]  * StevenK grumbles about get-orig-source
[08:53] <ogra> the Q1 ? its a celeron, why should i run lpia there ?
[08:53] <persia> StevenK: Well, it's one thing to be absent.  It's quite another thing to have one that is broken :)
[08:53] <ogra> or "generic intel" :)
[08:53] <persia> The Q1 is a celeron?  I thought it was an A100
[08:54] <ogra> well, its not really clear
[08:54] <ogra> its an 800MHz intel *something*
[08:54] <ogra> saying "generic intel" as type
[08:54] <persia> RIght.  That's the second generation lpia chips.  It's probably an A110
[08:54] <ogra> it uses the lpiacompat in your image 
[08:55]  * StevenK reuploads maximus
[08:55] <ogra> i use generic here atm and dont realy see difference in battery time 
[08:55] <persia> Well, it's an lpia.  Mind you, I'm running i386 on my lpia device just now as well.
[08:56] <ogra> i really dont think its lpia
[08:56] <persia> If you happened to be running lpia, I'd want another check of the apt-get issue, but doesn't really matter.
[08:56] <persia> Yes, lpia is A100, A110, Atom, and future chips.
[08:56] <ogra> right
[08:56] <ogra> and i really dont think it is one :)
[08:57] <persia> The A100 is usually 600MHz, and the A100 usually 800MHz.  Atoms seem to come in a wide variety of clockspeeds.
[08:58] <ogra> dmidecode says Pentium M
[08:58] <persia> Sure, but it's still lpia.
[08:59] <ogra> i havent seen any Atome reporting pentuim M ever
[08:59] <persia> You can run i386 on it the same way you can run i386 on an amd64.  Actually, lpia is *lots* closer to i386 than amd64.
[08:59] <persia> What do they report to dmidecode?
[08:59] <ogra> no idea, they usually report Atom in /proc/cpuinfo already so i dont bother to look
[09:00] <ogra> this CPU only shows GenuineIntel
[09:00] <ogra> but dmidecode shows pentium M properly
[09:00] <persia> Ah.  I think the main differences between the A100/A110 and a Celeron is that they are slightly more parallel and they have a hard limit of 1G RAM.
[09:51] <persia> StevenK: As I try to track down why X isn't starting, I suddenly wonder why I am already logged in when I boot.
[09:52] <persia> Is it perhaps that a special boot sequence is happening that is not driven by the contents of /etc/event.d/ ?
[09:53] <StevenK> persia: casper logs you in
[09:53] <persia> StevenK: That's what I thought, but I didn't see where in /etc/casper.conf that was enforced.
[09:53]  * persia reads more documentation
[11:48] <lool> We should change the battery icon with a logout one
[11:51] <persia> Why?  What's the use case for logout?
[11:51] <lool> I was just jokng because clicking the battery applet crashes hildon
[11:52] <persia> I see.  In that case, I agree.  While I'll argue against the use case for logout, as long as we have a logout button, it ought be labeled correctly.
[11:52] <persia> Are you running the daily?  Any ideas why apt-get update doesn't work?
[11:52] <lool> For some reason network didn't work on startup here
[11:52] <lool> So I'm chasing why startx isn't run
[11:53] <lool> persia: Unless you solved that alraedy?
[11:53] <persia> No.  The event doesn't seem to be triggering, but I've yet to discover why.
[11:53] <lool> persia: The even probably triggers
[11:53] <lool> But it doesn't start properly from udev
[11:53] <lool> err upstart
[11:53] <persia> What?  The "session" event isn't triggered on boot.
[11:54] <lool> persia: If you "start session" explicitely, nothing happens
[11:54] <persia> Mind you, when it triggers it also doesn't work, but when it triggers, it at least reports that it doesn't work to the logs.
[11:54] <lool> There's no session event, session starts on "runlevel 2" event
[11:54] <persia> There are two distinct problems.
[11:54] <persia> There is a session event.  That's why sudo start session ought work.
[11:55] <persia> Each entry in /etc/event.d is called an "event".  That there isn't anything listening for the session event isn't important.
[11:55] <lool> Don't you mean "job"?
[11:55] <persia> No, I mean event.
[11:55] <lool> start takes a job as parameter
[11:55] <lool> tty1 isn't an event
[11:55] <persia> Grumble.
[11:56] <lool> the event in /etc/event.d/tty1 is that it will triggerred when "stopped rc2" happens
[11:56] <persia> Right.  The terminology got rationalised for newer versions of upstart, and now upstream has a meaningful distinction between event and job.  That distinction doesn't really exist for the version in intrepid.
[11:57] <persia> That said, yes, "job" is more accurate.
[11:58] <lool> Anyway, if you "start session", it wont work; but if you run the command it does
[11:58] <persia> Yes.
[11:58] <persia> I'm currently chasing that, although if you want to chase it, that's fine too.
[11:58] <lool> persia: I'm happy if you chase it; I wonder what's happening
[11:59] <persia> I'm blocked on installing anything, as ubiquity is hanging.  I think it's the same hang as for apt-get update, but I don't understand that problem at all.
[11:59]  * persia goes to the MOTU Release meeting to put in good words for mobile stuff
[12:00] <lool> Haha
[12:00] <persia> (and probably other motives, yet unexamined)
[12:00] <lool> "X: user not authorized to run the X server, aborting"
[12:00] <ogra> lool, well, the more complicated way of logut is open pidgin, go on IRc, join a channel, close window ... 
[12:00] <ogra> same result
[12:00] <lool> ogra: I like the one clock logout
[12:01] <ogra> heh
[12:01] <ogra> they peobably use the same backend :P
[12:01] <ogra> *probably
[12:14] <lool> persia: Solved here
[12:14] <persia> lool: What did you do differently?
[12:14] <persia> And what did you solve?
[12:14] <lool> So either we need to allow ubuntu to start Xorg unconditionally or we need to own a new tty
[12:15] <lool> It works with "console owner\n respawn\n exec su -l ubuntu "startx..." </dev/tty7 >/dev/tty7 2>&1
[12:16] <ogra> do we want to be handled as subdistro by the universe team ? 
[12:16] <lool> I'd like to not hardcode tty7 naturally
[12:16] <persia> Ah.  Interesting.  I'll look at the casper scripts again.  I think there's a way to make that work with a minor change.
[12:16] <ogra> seems thats just being discussed next door
[12:16]  * ogra thinks mobile/mid might qualify
[12:16] <persia> ogra: We are already a universe flavour.  I'm just trying to make sure we don't need special permission to change things.
[12:17] <ogra> ah, good
[12:17] <ogra> thats what i was asking next :) (whats the advantage)
[12:17] <lool> "console owner" might not be necessary; it works after I remove it, but I need to check whether it's a side effect of the first session
[12:18] <lool> It's not
[12:18] <lool> So the only thing which is required is </dev/ttyN >/dev/ttyN 2>&1
[12:18] <lool> I tried with /dev/tty in prior tests, but it wasn't enough
[12:20] <lool> persia: I'm not sure casper is relevant; I checked it in the beginning but it defers to starting gdm in autologin
[12:21] <lool> Hmm even gdm hardcodes 7
[12:21] <persia> Yeah, there's no easy way around hardcoding.  Can do it in ubuntu-mid-settings then.
[12:22] <lool> I'm afraid upstart doesn't care about ttys
[12:22] <lool> So we have nobody to ask for a new one
[12:22] <lool> It's all done by config right now
[12:23] <lool> We could of course code something like for tty in 1 .. 20: try_tty
[12:23] <persia> Right.  Annoying that startx requires a tty, but we can just grab tty7, as that's where we'll be putting X anyway.
[12:23] <lool> It requires a VT, that's normal
[12:24] <lool> Let's try with openvt
[12:31] <lool> Works standalone
[12:31] <lool> openvt -s -- su -l ubuntu -c startx
[12:32] <lool> Works in event.d
[12:33] <persia> Nice discovery.  bzr is up-to-date for ubuntu-mid-default-settings if you want to make the adjustment.
[12:33] <lool> Let me confirm with a reboot first
[12:33] <persia> Did you update the change inside the squashfs?
[12:34] <lool> Hmm shutdown prompts to eject the disk *cough*
[12:35] <persia> Yeah, well, the effort to generate USB-based installers didn't complete pre-FF, so there was no need to change that.
[12:39] <persia> lool: Any objections to having authority to approve freeze exceptions for ubuntu-mid?  If not, please speak up in ubuntu-meeting in a couple minutes.
[12:40] <lool> Anyone has access to a recent system not running kbd?
[12:40] <lool> It's like to depend on kbd | console-tools, but not sure it's the correct alternative
[12:40] <persia> lool: You're up for discussion, if you've a minute.
[12:41] <lool> I should be having lunch
[12:41] <lool> But it looks like I wont anyway
[12:42] <persia> lool: No worries.  You were approved.  That ought make things easier if we need universe exceptions.
[12:43] <lool> Indeed
[12:43] <ogra> lool, whats your prob with kbd exactly ? 
[12:43] <lool> persia: pushed
[12:43] <ogra> i think console-tools is abandoned now
[12:43] <lool> ogra: No "problem", I just don't want to hardcode a dep on it if openvt is provided by the console -tools alternative
[12:43] <persia> lool: Cool.  Tomorrow ought bring up X.  apt-get update still doesn't work :(
[12:44] <lool> persia: Might check this later
[12:44] <ogra> (which actually only means its in universe so we can still make use of it)
[12:49] <ogra> persia, is there a doc about the stuff i just accepted (i.e. what power do i have being ubuntu-mobile release manager ... do i still need ubuntu-motu approval for decisions etc ?)
[12:50] <persia> ogra: Just follow the rest of the meeting.  At first blush, I believe it means you can grant freeze exceptions for some packages without further review.  I don't know which packages yet.
[12:50] <ogra> ah, good ...
[12:50] <ogra> well, i guess that will be the unr stuff :) 
[12:50] <ogra> or all things in the seed
[13:01] <lool> Grr bzr: ERROR: Invalid url supplied to transport: "lp:~ubuntu-mobile/ubuntu-mid-default-settings": No such project: ~ubuntu-mobile
[13:01] <lool> The branch seems to be in ~ubuntu-mobile/ubuntu-mobile/ubuntu-mid-default-settings instead
[13:02] <persia> Indeed.  We've no special ubuntu-mid project (and don't really want one, I think)
[13:02] <lool> But "/ubuntu-mid-default-settings" is usually branch codename
[13:10] <persia> Yeah, but one isn't permitted to attach branches to teams.  Blame LP, or wait until it permits branches associated with the disro.
[13:19] <lool> persia: In the mean time, we could register the project
[13:20] <persia> lool: I don't see any benefit having such a project
[14:03] <lool> persia: Well we could get a clean branch name for one
[14:04] <persia> lool: But that's the only advantage, and we then have to dal with managemnt of a product.
[14:04] <persia> Seriously, the package is maybe 20 lines of code.  it doesn't represent a project.
[14:04] <lool> It's the same thing each time you want to forward bugs to an upstream project; it's just Launchpad pain I live with
[14:04] <persia> I'd rather just not use BZR than bother doing it that way.
[14:05] <persia> See, I don't see any value to taking on extra pain.  We've a perfectly good project already.
[14:07] <lool> The problem is with stuffing branck nicks below the same project
[14:07] <lool> I wouldn't mind using subprojects
[14:07] <lool> But it's not one
[14:07] <persia> Why is it a problem to do that?  I work in several other projects with multiple branches for multiple packages.
[14:08] <lool> You wouldn't merge ubuntu-mobile-defaults-settings with ubuntu-mobile-artwork
[14:09] <lool> They should be namespaced
[14:09] <persia> Yes, but LP is broken, so we do it with multiple never-merging branches for now.
[14:09] <persia> Fixing LP is on the roadmap, and when it gets fixed, we can do it right.
[14:09] <lool> Or LP is broken that it requires you to file projects even for trivial stuff
[14:10] <persia> Otherwise we end up with a mess of projects we need to delete later.
[14:10] <persia> Yes, precisely.
[14:10] <lool> Yup, precisely!
[14:10] <persia> There is a spec to allow packages to be managed in BZR.  While I happen to think there's no point whatsoever in doing this, it is the appropriate solution for the use case.
[14:11] <persia> That said, it doesn't make sense to me to abuse LP as a workaround when a perfectly good workaround that doesn't require an extra project registration exists.
[14:11] <persia> Also, by using multiple branches against the same project, it means that we don't get more projects to collect bugs, which then confuses people less, which is a good thing.
[14:11] <lool> So where I to develop a new version of ubuntu-mid-default-settings with a new feature, where would I put it exactly in ~ubuntu-mobile?
[14:12] <persia> lp:~ubuntu-mobile/ubuntu-mobile/ubuntu-mid-default-settings
[14:12] <lool> A new feature which isn't ready for trunk, you know a feature branch
[14:12] <persia> After release, we also create a lp:~ubuntu-mobile/ubuntu-mobile/ubuntu-mid-default-settings.Intrepid branch to use for SRUs.
[14:13] <persia> Oh, just stick it in lp:~lool/ubuntu-mobile/ubuntu-mid-default-settings-gdm or something
[14:13] <persia> Doesn't really matter, as long as it can be collected or merged.
[14:13] <lool> Which is why I mentionned in ~ubuntu-mobile :)
[14:13] <persia> What's the use case that wants that?
[14:14] <lool> Working with other people on the feature?
[14:14] <persia> And why can't you each just merge from each other's trunks?
[14:14] <lool> Of course I could start the ubuntu-mobile-ubuntu-mid-default-settings-gdm team
[14:14] <lool> persia: Because you want a trunk for the feature branch as well?
[14:15] <persia> And now we get down to where conventional thoughts on how to manage DVCS break down.
[14:15] <lool> My point is you're effectively changing the expected Launchpad bzr/code workflow
[14:16] <persia> Then use lp:~ubuntu-mobile/ubuntu-mobile/ubuntu-mid-default-settings-gdm, but I still think that any management model that encourages that results in lots of useless branching.  I'd rather see it done in trunk.
[14:16] <persia> Was this actually a project with a significant codebase, I may feel otherwise.
[14:16] <persia> Yes, I think that the expected LP/bzr workflow is inherently broken.
[14:16] <persia> IT doesn't make sense to have 1000 trunks.
[14:16] <lool> I don't want to change my workflow per package or project I'm working on; there are enough special cases that I have to keep in mind already
[14:17] <persia> It makes sense to have maybe a couple of trunks for a big project, but generally to have just one trunk.
[14:17] <lool> My point is that we should avoid exceptions
[14:17] <persia> Feature branches are interesting, but there's no reason one can't merge against another feature branch, and trunks for feature branches don't scale well.
[14:18] <persia> Sure, but this would change the workflow for me for just this project.  Every other project for which I must use bzr follows the named-branches under a single project workaround whilst waiting for LP to become unbroken.
[14:19] <persia> As a result, I don't see changing it as avoiding exceptions.
[14:19] <persia> Mind you, if you *really* want to manage another project, I won't stop you, I just think it's useless.
[15:47] <persia> StevenK: http://revu.ubuntuwire.com/details.py?package=maximus (and no, I'm not staying up to hear your response to my comments)
[15:49] <lool> persia: I can reproduce the apt-get issue now that network works
[15:49] <lool> I'm afraid I can't even apt-get install to diagnose
[15:49] <lool> I suspect it's purely some kvm/kernel bug
[15:50] <persia> lool: Great.  It's a little beyond what I know how to even properly describe, but it's blocking me.
[15:51] <persia> On the other hand, I'm sure it's not just KVM, because StevenK reproduced on real HW.
[15:51] <lool> persia: Hmm do you think you could pick up rebuilding python-hildon without hildon-fm support?
[15:51] <lool> It currently prevents update-manager-hildon to startup
[15:51] <persia> Then let's drop update-manager-hildon :)
[15:52] <persia> Actually, I'll take another look: from using update-manager in intrepid, I think it's not required anymore.
[15:52] <persia> But I'll take a look at python-hildon / hildon-fm on Monday, if it still needs attention.
[15:53] <persia> Mind you, if apt-get worked, I'd be more interested in other things.
[16:00] <davidm> I think Bug #230691 is related to users not knowing that they need to bring up the file browser to remove the USB stick and when they don't "correctly" remove the stick it keeps incrementing.
[16:01] <lool> Ok, but I don't think there's any constraint that /media be properly cleaned up when users don't unmount key properly
[16:01] <lool> Or that's very minor wishlist for faster cleanup
[16:02] <lool> persia: Doesn't happen with the daily amd64 live CD
[16:02] <lool> Could very well be kernel though
[19:50] <Celtiore> hi from france
[19:51] <Celtiore> who have try to put ubuntu mobile on mid aigo p8860 ?
[22:07] <nxvl> \o/
[23:33] <mgolisch> eah
[23:33] <mgolisch> ups