[00:03]  * stgraber still has a new ltsp, ltspfs, ldm and pastebinit to upload before FF (doing intensive testing at the moment as I'll both release and package these at the same time)
[00:03] <stgraber> (probably the most tested version of LTSP ever ;))
[00:03] <sebner> stgraber: as long as the topic isn't changed there is no FF :P
[00:03] <stgraber> sebner: can we lock it somehow ? ;)
[00:04] <sebner> stgraber: become op and kick everyone else :P
[00:04] <stgraber> I'm pretty sure it's against some part of the CoC :)
[00:05] <sebner> stgraber: it runs under the name "netsplit" ;D
[00:05] <highvoltage> rofl
[00:05] <stgraber> sebner: ok, so I need to bribe some freenode admin ? :)
[00:06] <highvoltage> stgraber: what still needs to happen with pastebinit?
[00:07] <stgraber> highvoltage: cyphermox is doing pre-release testing, then I'll release 1.0 and push it to Ubuntu
[00:07] <sebner> stgraber: no one needs to know *psssssst*
[00:07] <highvoltage> ah
[00:07] <stgraber> has been a long long time since I last released and I really want the new version in Lucid (as it brings a flexible way of adding pastebin servers and a few others long awaited features)
[00:08] <stgraber> I've been running it for a few months now without any issue and I guess some others too but I want to make sure everything works before releasing
[00:08] <cyphermox> stgraber, i swear people feel this weird need to change the way they design pastebin sites :)
[00:08]  * slangasek creates pastebin.csszengarden.com
[00:09] <stgraber> cyphermox: yeah ... that sucks :) especially the ones adding some javascript "human check" ... I had to drop quite a few pastebin websites because of that
[00:09] <stgraber> slangasek: as long as you use a supported pastebin engine, it's fine, it'll work ;)
[00:09] <persia> stgraber: Be *really, really* fast on that release, as we're technically in FeatureFreeze (although I haven't seen the mail yet)
[00:10] <stgraber> persia: yeah, for pastebinit, I'm ready to tag, just waiting on some additional testing. For LTSP, I'm waiting on LP to build PPA packages faster ;)
[00:10] <stgraber> though I guess I can already go ahead and tag ldm and ltsp, as only ltspfs is having a small issue worth fixing before releasing
[00:10] <persia> stgraber: I understand.  I've been CPU-limited for the past 12 hours for the same reasons :)
[00:18] <crimsun> sebner: uploaded
[00:19]  * sebner hugs crimsun 
[00:21] <sebner> gn8 folks
[00:47]  * Laibsch curses his computer (and karmic) for constantly overheating and shutting down at inopportune times since karmic
[00:57] <elmo> there's an opportune time to overheat and shut down?
[00:59] <Laibsch> yes
[00:59] <Laibsch> just before switching off ;-)
[02:28] <superm1> would something in universe Recommends'ing something in Multiverse cause it to FTBFS, or would that only happen from something in universe Depends'ing on something in Multiverse?
[02:38] <lifeless> is there something we should do with merge proposals to ensure main sponsors see them ?
[02:39] <Laibsch> lifeless: are they subscribed?
[02:39] <lifeless> Laibsch: are you saying thats what we should do? Note that I'm not talking about bugs.
[02:39] <lifeless> so the bug policies don't apply.
[02:39] <Laibsch> of course
[02:40] <Laibsch> ??
[02:40] <Laibsch> Do you have a patch?
[02:40] <Laibsch> something ready to apply?
[02:40] <lifeless> A merge proposal.
[02:40] <ScottK> superm1: Run time recommends can't cause FTBFS, but that would require the package to move to Multiverse.
[02:40] <Laibsch> lifeless: do the merge, open a ticket, subscribe sponsors ;-)
[02:40] <lifeless> Laibsch: I don't think you understand what I'm talking about.
[02:41] <Laibsch> maybe not
[02:41] <Laibsch> you want somebody else to do some work
[02:41] <Laibsch> correct?
[02:41] <lifeless> a merge proposal is a proposal to merge two branches in launchpad
[02:41] <Laibsch> Oh
[02:41] <lifeless> it *is* the record that the work needs to be done.
[02:41] <lifeless> its not a bug.
[02:41] <Laibsch> I thought you were talking about merge/sync kind of merge
[02:41] <Laibsch> for a package
[02:41] <lifeless> no, because for those we have procedures.
[02:41] <Laibsch> well, yes
[02:42] <lifeless> so I ask again, to the floor. "is there something we should do with merge proposals to ensure main sponsors see them ?
[02:42] <lifeless> "
[02:42] <Laibsch> I stay away from bazaar as much as possible, so I have no experience with that and can't help you
[02:44] <ajmitch> it's not even obvious where merge proposals are listed for ubuntu, from what I can see
[02:44] <ajmitch> I can find a few through ~ubuntu-main-sponsors
[02:45] <lifeless> ajmitch: most will be on ~ubuntu-branches at this point
[02:45] <lifeless> ajmitch: there is discussion on this on the udd list
[02:46] <ajmitch> right, found that thread
[02:47] <lifeless> [join the list ;P]
[02:47]  * ajmitch is on the list
[02:47] <ajmitch> but the discussion was more than 2 weeks ago :)
[02:48] <lifeless> paged out already?
[02:49] <ajmitch> yep
[03:44] <smoser> anyone here have a some spare knowledge to share on how a seed works ?
[03:44] <smoser> the reason I ask is that the uec builds have 'uec^' as a seed.
[03:45] <smoser> the install process does 'apt-get install uec^'
[03:45] <smoser> at this point in karmic, that is resolving to 2 different packages providing a kernel
[03:46] <smoser> linux-image-2.6.31-14-virtual and linux-image-2.6.31-19-virtual
[03:46] <smoser> i'm not sure when it started, but I think it might be related to a kernel being added to -updates
[03:50] <smoser> hmm... digging a bit http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.karmic/uec lists the older package
[03:54] <smoser> anyone happen to know how that is updated?
[04:24] <superm1> kirkland now that the other two builds have caught up, could you by chance release myththemes and mythplugins so tonight's media will pick em all up?  (or some other archive admin seeing this)
[04:37]  * lamont wants to stab libtool
[04:37] <lamont> -version-info 61:4:1 \
[04:37] <lamont> ...-Wl,-soname -Wl,libisc.so.60 -o .libs/libisc.so.60.1.4
[05:01] <StevenK> superm1: I'll look at that for you in a sec
[05:03] <superm1> thanks
[05:15] <StevenK> superm1: myth{themes,plugins} accepted.
[05:16] <superm1> awesome, thanks!
[05:16] <nigelb> I'm trying to apply an upstream patch to gnome-media, which is maintained in bzr.  I applied the patch, but I have no idea how to go about building the package when its maintained in bzr.  Is there some place I can see a guide for this or could someone guide me through it?
[05:37] <jdub> whoa
[05:37] <jdub> this rsyslog bug is awesome
[05:37] <jdub> https://bugs.launchpad.net/bugs/523610
[05:37] <jdub> (happening for me with the linode kernel)
[06:46] <pitti> Good morning
[06:46] <pitti> mdeslaur: yes, I don't think anyone will object against adding apport symptoms post-FF
[06:46] <pitti> mdeslaur: (FF is already in place, btw; but I'll do an upload anyway)
[06:50] <micahg> pitti: do you think an apport symptom for flash would be good?
[06:50] <pitti> micahg: what would it do more than just filing a bug against flashplugin-installer?
[06:51] <pitti> micahg: well, it could check whether you have the proprietary plugin, and not file a bug at all then
[06:56] <superm1> pitti, well good news on the gvfs/gdu pool creation crashes I was seeing... at least with the latest version it looks like it's a simple fix (bug 523634)
[06:57] <micahg> pitti: well, there are multiple flash plugins
[07:04] <pitti> micahg: right, the symptom could figure out which one you are using, and return the correct package
[07:04] <micahg> pitti: right, or ask which browser you are using if there are multiple
[07:04] <micahg> and file it against the browser
[07:05] <pitti> superm1: ah, that would be it
[07:05] <pitti> superm1: I'm glad that the original race was fixed
[07:07] <micahg> pitti: if you're ok with idea, I already filed a bug and can try to create the symptom at some point
[07:07] <pitti> micahg: sure, sounds great
[07:09] <pitti> superm1: thanks, committed
[07:10] <micahg> pitti: how late in the cycle can we get symptoms in?
[07:10] <pitti> micahg: with my release team hat on, at least until beta-2
[07:10] <micahg> pitti: k, that's what I'll set it for then, thanks
[07:10] <pitti> this helps us to improve quality, and won't break the actual system
[07:10] <pitti> but of course we'll get lots of feedback/bugs for beta-1 and beta-2
[07:10] <micahg> cool
[07:11] <pitti> so the really useful symptoms should be in before that ideally
[07:11] <pitti> so that we can actually make use of them :)
[07:11] <micahg> pitti: I just don't know if I'll get to it before then
[07:11] <micahg> there's still a lot of mozilla stuff to be done before beta 1
[07:44] <DktrKranz> leonardr: yup. packaged, uploaded to Debian and then synced. thanks!
[08:03] <dholbach> good morning
[08:03] <jdub> aha
[08:03] <jdub> hey dholbach
[08:03] <dholbach> heya jdub
[08:04] <jdub> #523610 <- rsyslog missing the dd trick now it's an upstart job
[08:10] <dholbach> james_w: can lp:~bmillemathias/ubuntu/lucid/bluez/main and its merge proposal be marked as merged?
[08:18] <pitti> zul, soren: can you guys please seed ec2-init, so that the transitional package is in main? (cleaner upgrades)
[08:18] <soren> pitti: Sure.
[08:20] <pitti> kees: I removed the obsolete devmapper source, FYI
[08:29] <soren> pitti: I don't want to put ec2-init in the uec seed, since that is a task and I don't want to install a transitional package as part of a task. It also seems odd to put in on the dvd (again, because it's a transitional package), but the top of supported suggests that everything should go on the dvd unless it's much too large to fit there.
[08:29] <pitti> soren: no no, just "supported" is enough
[08:29] <pitti> no need to install that on any medium
[08:29] <pitti> it just needs to be in main for a clean upgrade from karmic
[08:30] <soren> Yeah, that's what I thought.
[08:30] <soren> Oddly, the dvd seed has a "Transitional packages" section.
[08:30] <pitti> soren: ah, perhaps if you use the DVD as a package source for dist-upgrading?
[08:31]  * soren ponders
[08:31] <soren> pitti: Yeah, that would make sense, I suppose.
[08:32] <soren> I'll put a note in the seed explaining that use case.
[08:33] <soren> dvd seed it is.
[08:36] <soren> pitti: Done. Thanks for catching this.
[08:37] <pitti> thanks soren
[08:38] <dholbach> can somebody please sync bzr from sid? it fixes at least one ugly merge bug
[08:38] <pitti> doing
[08:38]  * dholbach hugs pitti
[08:38]  * bryceh waves
[08:39] <soren> I see rhythmbox-ubuntuone-music-store was added to the seeds, but no such package exists. Is that intentional?
[08:39] <bryceh> pitti, I got the X freeze apport hook working today :-)
[08:39] <pitti> hey bryceh
[08:39] <pitti> bryceh: ooh! you were able to produce a freeze? great!
[08:40] <bryceh> pitti, and got a *single* .crash file generated in /var/crash
[08:44] <soren> Oh, I see it's in the NEW queue. Never mind.
[08:54] <slangasek> RAOF: your most recent libdrm upload doesn't seem to be marked uploaded in the git repository?
[08:55] <RAOF> slangasek: That would probably be because I didn't upload it; bryceh did.  I can't upload libdrm, not being in ~core-dev :)
[08:56] <slangasek> RAOF: well, you have commit access to the repo at least, could you commit that?
[08:56] <RAOF> Yep.
[08:56] <slangasek> (I don't have commit access to the repo; request pending)
[08:58] <bryceh> erf
[08:58] <bryceh> we really need to decide git vs. bzr for maintaining all this stuff
[08:59] <RAOF> I'd really, really like bzr.  If only everyone else used it, too :(
[08:59] <highvoltage> I always assumed that core-dev's rights include those of motu, is my assumption wrong?
[09:00] <bryceh> RAOF, ditto
[09:00] <highvoltage> if I understand mako's comment on http://revu.ubuntuwire.com/details.py?upid=7876 correctly, he's not able to contribute to revu even though he's a core-dev
[09:01] <RAOF> If someone could spend a month or so making bzr-colocated work, I could just drop git entirely.
[09:01] <mtx_init> does ubuntu use dkms?
[09:02] <bryceh> mtx_init, yes
[09:02] <mtx_init> thx
[09:03] <slangasek> bryceh: the source package has an ubuntu version number, points at a git repo, and the git repo has an ubuntu branch, so I assumed that was official?
[09:04] <slangasek> if you're telling me I can ignore this in favor of lp:ubuntu/libdrm, I'll do a little dance :)
[09:04] <bryceh> slangasek, no your original assumption is correct
[09:04] <slangasek> drat
[09:04] <slangasek> :-)
[09:05] <bryceh> we started using git for maintaining the packaging before a lot of james_w's bzr stuff became available
[09:06] <mtx_init> whats the best way to get into kernel level development.  Ive takes OS classes before and written system calls and stuff.  Ive added ACL's to a FS and created my own message passing ipc.  But the whole thing is incredibly intimidating.  any idea on a good point to start.
[09:09] <SwedeMike> mtx_init: http://www.linuxhq.com/lkprogram.html
[09:09] <pitti> bryceh: it seems that -nouveau is still in universe; can you please add it to -video-all, so that we can promote it?
[09:10] <mtx_init> SwedeMike: thanks
[09:10] <bryceh> pitti, before I do that, we've been waiting on lbm being updated
[09:11] <RAOF> Are we getting an lbm-nouveau metapackage that x-x-v-nouveau can depend on?
[09:11] <pitti> bryceh: oh, the current linux-backports-modules-nouveau-2.6.32-13-generic is not recent enough?
[09:11] <pitti> RAOF: that would be wrong
[09:11] <pitti> we certainly don't want to pull in lbm by default
[09:11] <pitti> we need to get along with the nouveau in the default kernel
[09:11] <bryceh> pitti, actually we do
[09:11] <pitti> no, we don't
[09:11] <pitti> seriously
[09:12] <bryceh> pitti, no, the nouveau in the default kernel is not going to be good enough
[09:12] <pitti> lbm ships a lot of stuff that is prone to break machines
[09:12] <slangasek> pitti: no, linux-backports-modules-nouveau-2.6.32-13-generic, not "lbm" as a whole
[09:12] <bryceh> pitti, we need to pull the lbm nouveau binary module (and include it on the cd)
[09:12] <pitti> ah
[09:12] <pitti> but why can't we just put that one into the main kernel then?
[09:12] <bryceh> pitti, its complicated
[09:13] <pitti> slangasek: ah, ok
[09:13] <RAOF> bryceh: There *isn't* any nouveau in the default kernel :)
[09:13] <bryceh> pitti, drm is hard to pull in a per-driver fashion
[09:13] <pitti> ok, so it's _only_ shipped in lbm
[09:13] <pitti> ok, that sounds better
[09:13] <pitti> bryceh: so, current linux-backports-modules-nouveau-2.6.32-13-generic isn't recent eonugh yet?
[09:14] <bryceh> pitti, there is a (short) email thread on kernel-team@ and ubuntu-x@ you may want to look at
[09:14] <DktrKranz> pitti: thanks for syncing restfulclient! I thought it was in sync already, but I was wrong :)
[09:14] <pitti> ok, thanks; so this is blocked on pulling a new version by the kernel team?
[09:15] <RAOF> l-b-m-nouveau should be new enough; what we really need is a linux-backports-modules-nouveau metapackage that the DDX can depend on and gets updated with the kernel ABI.
[09:15]  * pitti updates work items then
[09:15] <pitti> thanks for the heads-up
[09:16] <RAOF> That reminds me! I'll file a bug against initramfs-tools to add nouveau to the framebuffer hook.
[09:17] <pitti> bryceh: ok, I updated https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-lucid-xorg-driver-selection-for-nvidia-hardware
[09:20] <directhex> hm.
[09:23] <directhex> i want to make an ubuntu1 upload of monodevelop, with moonlight support enabled. should i wait for the mozilla team to get their ff3.6 stuff (including moonlight) ready? it's a binary-only dep on a separate monodevelop-moonlight binary package (i.e. doesn't affect compilation).
[09:27] <slangasek> RAOF: I would argue that the lbm package should provide its own hook to take care of itself
[09:28] <slangasek> and presumably the in-kernel one lands in kernel/drivers/gpu like the others?
[09:29] <RAOF> It might end up in staging/
[09:29] <RAOF> But it will eventually end up in kernel/drivers/gpu like the others, yes.
[09:30] <tjaalton> bryceh: git of course ;)
[09:31] <bryceh> tjaalton: I'm thinking bzr actually
[09:31] <tjaalton> of course
[09:31] <bryceh> tjaalton: there's pros and cons each way, but I favor bazaar
[09:31] <RAOF> The problem with shipping it in lbm is that the various ABI versions should be parallel installable.  I guess the linux-backports-modules-nouveau package could ship it.
[09:32] <tjaalton> but I'm also co-maintaining it in debian, so using two toolsets to maintain stuff is suboptimal fo me
[09:32] <tjaalton> for
[09:32] <tjaalton> but your call
[09:32] <slangasek> no problem, just convince the Debian comaintainers to use bzr ;)
[09:32] <bryceh> tjaalton, yes I recognize that issue
[09:32] <tjaalton> slangasek: and upstream too?
[09:33] <slangasek> nah, just use bzr-git for that
[09:33] <tjaalton> well, that's unlikely to happen
[09:33] <slangasek> using bzr-git is?
[09:34] <tjaalton> that
[09:35] <RAOF> It's really pretty good, although it does suffer from bzr not having any way to refer to colocated branches.
[09:36] <tjaalton> I understand that it's harder for people to touch this stuff if it's in git.d.o, but is that any different from any other team? I don't think it's a good practise for random core-devs to directly touch and upload packages "owned" by some team
[09:36] <tjaalton> without discussion
[09:36] <slangasek> no, it's no different than any other team, and I regularly complain at other teams too when I can't commit to their repos as a core-dev
[09:37] <tjaalton> heh, well I don't count you as a "random" core-dev ;)
[09:38] <slangasek> :(
[09:39] <tjaalton> being the release manager and all :)
[09:40] <slangasek> I don't think the release manager should be special in that regard; all core-devs should be trusted w/ commit access, and to know when to discuss before uploading
[09:40] <tjaalton> in theory yes
[09:47] <tjaalton> no manpage for bzr-git
[09:56] <dholbach> tjaalton: bzr help <...>?
[09:57]  * hypera1r is more interested in git-bzr
[09:58] <dholbach> hypera1r: bzr git-import <...>?
[09:58] <dholbach> (from bzr-git package)
[09:58] <hypera1r> dholbach: i don't like bzr.
[09:58] <hypera1r> dholbach: to put bluntly.
[09:58] <dholbach> ah, I misunderstood you then
[09:58] <hypera1r> ;-)
[09:59] <tjaalton> yeah, it's a one-way journey, because there's no way to push
[10:00] <tjaalton> so for that there would need to be two sets of the trees, one for git and one for bzr-git
[10:04] <RAOF> It's not one-way; you can bzr dpush git+ssh://whatever
[10:04]  * sebner waves in the round
[10:04] <hypera1r> o/
[10:05] <tjaalton> RAOF: ok, that's what the launchpad page claimed though
[10:06]  * slangasek succeeds in pushing to libdrm on alioth
[10:06] <slangasek> (the hard way though, using git)
[10:07] <dholbach> slangasek: does it give you that great slightly masochistic sense of achievement? ;-)
[10:08] <slangasek> dholbach: I carefully monitor my git use to ensure I don't become too comfortable with it :)
[10:09] <RAOF> slangasek: Didn't I successfully push that?
[10:09] <slangasek> RAOF: you successfully pushed *your* commit, I was pushing /mine/ :)
[10:09] <RAOF> tjaalton: Yeah.  It technically doesn't “push” because it needs to do some rewriting of the local objects to keep the remote and local branch in sync.
[10:09] <tjaalton> jelmer: the description on https://edge.launchpad.net/bzr-git is misleading if push has been working sinec 0.3.2
[10:10] <jelmer> tjaalton, push still doesn't work
[10:10] <tjaalton> jelmer, RAOF: ok, I give up :)
[10:11] <jelmer> tjaalton: you can use the "bzr dpush" command, but that's not the same thing as push
[10:11] <RAOF> jelmer: My description of the difference above is roughly correct, right?
[10:11] <slangasek> oh, dpush wasn't a typo, heh
[10:13] <jelmer> RAOF: Basically, yeah
[10:15] <tjaalton> what's the equivalent of 'git show $hash'?
[10:15] <pitti> tjaalton: bzr diff -c revno
[10:15] <jelmer> tjaalton, "bzr log -p -r X"
[10:15] <tjaalton> eww, that's hard :)
[10:16] <RAOF> “bzr alias show=log -p -r -X”
[10:16] <tjaalton> but it accepts the hash as the revno?
[10:16] <RAOF> Let me check...
[10:16] <jelmer> tjaalton: s/X/$hash/
[10:16] <tjaalton> jelmer: ah, gotcha
[10:18] <tjaalton> -r git:$hash
[10:19] <jelmer> the git: bit is optional in newer versions of bzr
[10:19] <tjaalton> so it detects it? ok
[10:20] <pitti> meh, that's the second time that X.org freezes and goes to 100% CPU a couple of minutes after login
[10:20] <pitti> bryceh: were there any X.org/intel updates yesterday?
[10:21] <tjaalton> only libdrm
[10:21] <sebner> pitti: better than me. I just tryed out of the gdm/plymouth whatever bug is fixed but I guess no. Gdm appears, I move my mouse and it evidently crashes because mouse and keyboard don't work anymore :( --hardreset
[10:21] <pitti> I already disabled plymouht
[10:21] <pitti> this now manages to break every boot
[10:22] <sebner> oh
[10:22] <sebner> plymouth++ then
[10:22] <ttx> slangasek: should the rc-sysinit/network race bug be reopened, following up on keybuk's https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/461725/comments/15 ?
[10:22] <slangasek> cjwatson: hmmm, does the by-id stuff you were doing affect what will get written to /etc/crypttab by the installer?
[10:22] <sebner> pitti: how to disable it? apt-get remove?
[10:22] <tjaalton> hmm we already had libdrm 2.4.17 before the new merge
[10:23] <pitti> sebner: boot without splash; that won't really disable it, but disable the graphical splash
[10:23] <tjaalton> so no intel changes there
[10:23] <pitti> which is what seems to break X
[10:23] <pitti> tjaalton: currently trawling through dpkg.log to see what was new
[10:24] <sebner> pitti: aye, thanks :)
[10:24] <pitti> there are no kernel related messages in dmesg when it happens, and strace Xorg is silent - it's just spinning
[10:24] <slangasek> ttx: no, that bug is fixed; the regression has really only been confirmed on systems with a broken network config
[10:25] <ttx> slangasek: ok, just checking :)
[10:26] <sebner> pitti: ehm, stupid question .. what happened to menu.lst ^_^
[10:26] <pitti> sebner: menu.list is grub 1, which became obsolete in karmic
[10:27] <pitti> tjaalton: right, I didn't even get a new libdrm
[10:27] <slangasek> oh, would that it were actually obsolete :)
[10:27] <sebner> pitti: oh right, I haven't haXX0red anything in lucid yet. so what's the new thing?
[10:27] <pitti> tjaalton: so it must be between new libc6, new udev, or me dropping "splash" from kernel comand line
[10:28] <tjaalton> pitti: I'll try that on mine
[10:28] <pitti> tjaalton: I'll gdb X the next time it happens; thanks so far!
[10:33] <slangasek> pitti: dropping splash from the kernel commandline is a near-guaranteed way to make X hang in lucid :P
[10:34] <pitti> hmm
[10:34] <slangasek> pitti: bug #518352
[10:34] <tjaalton> hah
[10:34] <slangasek> if you don't use 'splash', then 'plymouth --show-splash' doesn't change VT
[10:34] <pitti> well, X is on vt7 now
[10:35] <slangasek> is that where it was at boot time, or did you restart it?
[10:36] <slangasek> it's only the *first* X server after boot that winds up on the wrong VT, because gdm does - if (plymouth_is_running) { get_cur_vt_for_X_args(); kill_plymouth(); }
[10:36] <pitti> I don't think I restarted it
[10:36] <jussi01> !grub2 | sebner
[10:39] <sebner> jussi01: thx but this seem to cause even more breakage *muahahha*
[10:39] <jussi01> *g*
[11:05] <mpt> mvo, hi, how is ratings+reviews? Are you blocked on anything?
[11:26] <cjwatson> slangasek: not to my knowledge - I didn't think crypttab had much to do with grub?
[11:26] <slangasek> cjwatson: I wouldn't think so, no :)
[11:26] <sebner> StevenK: regarding openal-soft, LP does support syncing .orig.bz2 now afaik?!
[11:27] <slangasek> cjwatson: just an odd bug report that came in, with someone having listed their source device as /dev/disk/by-id/fwibble in /etc/crypttab
[11:27] <directhex> asac, is debian/patches/mono-arm-thumb2-ftbfs.dpatch forwarded to upstream?
[11:37] <cjwatson> sebner: not properly
[11:37] <cjwatson> sebner: it supports the first sync.  thereafter, it is believed that subsequent syncs with the same .orig.tar.bz2 will fall over
[11:38] <cjwatson> slangasek: IIRC the installer even generates crypttab before grub-installer runs
[11:38] <slangasek> ok
[11:55] <mvo> mpt: not blocked as such, just drowned in other stuff, I plan to work on the new approach with ubuntuone today, lets see how well that goes. the old code that use launchpad will have to be replaced in parts
[11:55] <mpt> mvo, ok, best of luck :-)
[11:55] <pitti> is there an existing bug report for the plymouth failure? perhaps with some hints how to debug this? I now got 7 failures in a row
[11:56] <mvo> thanks :)
[11:56] <slangasek> pitti: hmm? other than the one I pointed to above about booting w/o splash?
[11:56] <pitti> slangasek: still the same one from the sprint
[11:56] <pitti> i. e. X starts up with a mouse cursor over VT
[11:56] <pitti> ctrl-alt-f1 > switches to VT
[11:56] <slangasek> pitti: yes; are you booting without splash?
[11:57] <pitti> crtl-alt-f7 -> back to X, but press enter -> freeze
[11:57] <pitti> slangasek: no, that's with splash
[11:57] <slangasek> oh, no, that sounds like the in-between-VTs case
[11:57] <pitti> Keybuk said taht he can't reproduce, so I'm happy to collect some data
[11:57] <pitti> but I'm afraid I don't know where to start
[11:58] <pitti> it happens on both of my machines (dell mini ssd and latitude)
[11:59] <slangasek> pitti: for starters, make sure you have libplymouth2 0.8.0~-10ubuntu1 installed and file a bug with apport, so we at least have a record of /proc/cmdline and /proc/fb
[11:59] <pitti> ah, bug 516412
[11:59] <slangasek> noooo, not that one :-P
[11:59] <pitti> that's the freeze part
[11:59] <pitti> once I switch to vt1 and back to 7
[12:00] <pitti> slangasek: ok, so there's no existing bug with suggestions/explanations what to look out for?
[12:00] <pitti> ok, I'll file a new one then
[12:00] <pitti> slangasek: (I have that version)
[12:01] <slangasek> nope - we have an explanation of *what* that behavior means, but no model for *why* it happens
[12:01] <pitti> could it be related to fsck?
[12:01] <slangasek> Keybuk might be able to give some debugging advice, but I can't
[12:01] <pitti> since obviously I need to powercycle this machine every time now
[12:01] <pitti> slangasek: ok, thanks
[12:01] <slangasek> "obviously"?
[12:01] <slangasek> Alt+SysRq+K doesn't fix it?
[12:01] <pitti> No SysRQ on the mini :/
[12:01] <slangasek> snerk
[12:02] <slangasek> plug in a USB keyboard? :)
[12:02]  * pitti will boot in rescue mode, make sure that partitions are okay
[12:02] <pitti> oh, I can login/reboot from VT1
[12:03] <pitti> (didn't help, though)
[12:03] <slangasek> anyway, relation to fsck is only distant AFAIK, in the manner of races
[12:06] <mvo> mpt: one thing we should discuss (not necessarily now) - apparently the gtk patch take make almost-fixed height mode fast is going going to be upstream and we will have a hard time getting it in as a distro patch. nzmm implemented a alternative layout that does not grow/shrink so we can have fixed_height mode
[12:06] <mpt> mvo, "going going" -> "not going"?
[12:06] <mvo> mpt: I would like you to look at it (I or he can do screenshots) and comment. without a patched gtk the user experience is going to be really bad
[12:06] <mvo> mpt: not going to
[12:07] <mvo> mpt: I'm willing to work more on the patch, but I have the feeling its a lost cause
[12:07] <pitti> slangasek: right, once I put back cups, it works again
[12:07] <pitti> slangasek: I think this machine is naturally avert to booting in 10 s; the closer you get, the more it acts up :)
[12:07] <slangasek> pitti: bwuh? cups?
[12:07] <slangasek> haha
[12:07] <pitti> slangasek: (just for testing)
[12:07] <mpt> mvo, so first, why will it not be upstream?
[12:07]  * pitti calls that "Scott's law"
[12:07]  * pitti -> supermarket
[12:07] <mpt> mvo, or if you'd prefer to discuss this later, let me know
[12:08] <mvo> mpt: I had no official reply yet in the bugreport, but the unoffical is that it makes the fixed_height mode case slower and that its a hack (both is true). the slowness should be really small
[12:08] <slangasek> pitti: perhaps annotating the gdm upstart job to run fuser -v /dev/tty7 before starting?
[12:09] <mvo> but its a hack and it does things that fixed_height is supposed to not support (namely making rows grow/shink)
[12:09] <slangasek> (stabbing the dark)
[12:10] <mpt> mvo, and why would it be hard as an Ubuntu patch? Is it because we'd be carrying it forever?
[12:12] <mvo> mpt: we would have to carry it for the full LTS time and carrying a patch that got rejected upstream will make bugreports against gtk by us handled less favorable (because it might be a side effect of our patch(es)). seb128 is the gatekeeper for this
[12:12] <mvo> (upstream reports)
[12:13] <mpt> mvo, so maybe the question for upstream is, *how* in GTK should we achieve what we want to achieve (rows changing size but being fast with long lists)
[12:13] <mvo> mpt: correct
[12:15] <mvo> and I believe at this point the answer is "you can't" - at least not without massive amounts of gtk events that infere with the webkit rendering (and other stuff)
[12:15] <mvo> but I'm happy to change my opinion if someone comes up with a good way of achieving this
[12:15] <seb128> mvo, did you get any comment on this bug?
[12:15] <mvo> I do think we shuld have a backup plan ready
[12:16] <mpt> mvo, how does Banshee do it? Do they not use fixed-height mode?
[12:16] <mpt> Or are they using a completely custom list control?
[12:16] <seb128> banshee has quite some custom widgets
[12:16] <mvo> mpt: someone told me they embedded a complete copy of the treeview
[12:16] <mvo> but I have not verifed this
[12:17] <mpt> How difficult would that be?
[12:17] <mvo> well, it would be a very big hammer
[12:18] <mvo> the question is not "is it possible" - the question is "is it sensible" (or "how much are we going to hack")
[12:18] <mvo> alternatively: "growing row design" > pain-to-make-it-happen
[12:18] <mpt> Right, that's why I was asking specifically about how difficult it would be
[12:19] <mvo> not easy, but possible
[12:19] <mpt> ok
[12:19] <mpt> What does nzmm's layout look like?
[12:20] <mvo> http://people.canonical.com/~mvo/tmp/Screenshot-Ubuntu%20Software%20Center.png
[12:20] <mvo> mpt: ---^
[12:23] <mpt> that looks quite odd
[12:23] <mpt> I suppose it would look a bit less odd if the stars and the buttons swapped places
[12:27] <seb128> crimsun, hi
[12:27] <seb128> crimsun, have you seen bug #523716?
[12:28] <crimsun> seb128: no, but I'll fix it
[12:29] <seb128> crimsun, thanks!
[12:29] <mpt> mvo, my main concern with that is if/when someone implements add-on handling for 3.0, which adds a "Choose Add-Ons…" button next to the "Install" button, so we really really do need the buttons on a separate line for them to have enough room, so we fix the variable-height issue somehow then instead of fixing it now, users will have had to go through three different row layouts in three successive USC versions.
[12:29] <crimsun> I'm currently working on alsa-plugins, so it will be a few minutes
[12:29] <seb128> crimsun, it's blocking things I want to land today and dx weekly updates so fixing it today would be appreciate if you can ;-)
[12:29] <seb128> crimsun, excellent, thank you
[12:30] <mvo> mpt: agreed, I like the visual design of the expanding thing better, we should still have a backup plan
[12:32] <mpt> mvo, ok, so in order of my personal preference: ;-) 1. Get the patch accepted upstream. 2. Copy and tweak the treeview code like Banshee does. 3. Use nzmm's layout but with the stars and buttons swapped around.
[12:33] <mvo> mpt: ok
[12:48] <zul> morning
[12:49]  * slangasek waves
[12:51] <slangasek> zul: so the bugs that were blocking samba conversion to upstart are now all fixed; is it still warranted to do the actual upstart conversion now that we're post-FF?
[12:52] <zul> slangasek: in the long run I dont think it will hurt
[12:53] <slangasek> zul: "I don't think it will hurt" isn't a FFe justification...
[12:53] <zul> slangasek: i think there will be the same issue with network manager if we remove your fix for it
[12:53] <slangasek> sorry, which issue?
[12:54] <zul> the one where you did the SRU for,,,sorry Im still trying to wake up
[12:54] <slangasek> well, I wouldn't remove the fix without adding the upstart jobs
[12:54] <slangasek> but this is going to need a FFe now, so I want to be sure the server team cares about this for lucid
[12:55] <zul> i know, i think we do lemme ask around a bit more
[12:55] <slangasek> ok
[12:57] <mdeslaur> pitti: thanks! (re: apport-symptoms)
[12:58] <pitti> mdeslaur: security.py> nice FAQ!
[12:59] <asac> directhex: nope. need to write a proper configure check rather than ifdef __thumb__
[12:59] <pitti> slangasek: right, as expected, fuser says "plymouthd"
[13:00] <slangasek> pitti: ok; that alone isn't buggy
[13:00] <slangasek> gdm takes care of detaching it
[13:02] <sebner> cjwatson: ah I see, I thought that is fixed alredy. nvm then
[13:09] <crimsun> seb128: for pulse, 0ubuntu7 in the NEW queue is rejectable; 0ubuntu8 has already built for powerpc, amd64, i386 and is just awaiting approval
[13:09] <seb128> crimsun, ok thanks, look at that now
[13:16] <crimsun> mterry: thanks much for the jack approval!
[13:16] <mterry> crimsun, np, sorry it took me so long
[13:18] <pitti> slangasek: ok, filed as bug 523788
[13:18] <pitti> I'll ask Keybuk once he's around
[13:26] <\sh> hum...sun-java6 got missing for lucid? or did kees followup with his plan to remove it completly?
[13:27] <c_korn> \sh: https://launchpad.net/ubuntu/lucid/+source/sun-java6/6-16-1
[13:28] <\sh> c_korn: DELETED: Lucid pocket Release in component multiverse and section devel
[13:28] <kklimonda> weren't there plans to move it to the -partner repository?
[13:30] <\sh> kklimonda: well, if that is, a) i didn't catch it and b) someone could update all configs for upgrades from < lucid to >= lucid ;)
[13:32] <\sh> but right now, it would make my production machines very unhappy with an evtl. removed package of sun-java6
[13:52] <pitti> it was removed from lucid, and is meant to be moved to partner
[13:59] <BenC> Good morning ubuntuers
[13:59] <Tm_T> moin
[14:01] <pitti> hey BenC, how are you?
[14:03] <zul> hey BenC
[14:03] <BenC> pitti: hey, not bad, how about yourself?
[14:04] <pitti> BenC: I'm great, thanks; again in boot speed fighting mood :)
[14:06] <BenC> pitti: fight the good fight :)
[14:08] <Laibsch> dholbach: Has the door closed for bug 420918 due to FF?  I thought that was not the case, but persia suggested yesterday my POV may be mistaken.
[14:09] <Laibsch> sistpoty|work, bdrung, ScottK: ^^
[14:13] <smoser> Hi all, last night I asked about seeds (http://irclogs.ubuntu.com/2010/02/18/%23ubuntu-devel.html).  The 'uec' seed for karmic is pulling in kernel images from the release, even though there are newer ones in updates.
[14:14] <smoser> is that expected behavior ? ie, if I do 'apt-get install uec^' I get 2 kernel images, the current one as in updates and the original release version.
[14:14] <smoser> vmbuilder does this in the uec image builds, so my built images get 2 kernels (which i could work around, but seems senseless)
[14:31] <superm1> slangasek, hmmf. according to the build log http://people.canonical.com/~ubuntu-archive/cd-build-logs/mythbuntu/lucid/daily-live-20100218.log this build was successful, yet it didnt show up on cdimage.
[14:31] <superm1> doh just refreshed, there is it
[14:31] <superm1> i guess the time the pieces that cron job is running got changed
[14:50] <sistpoty|work> Laibsch: sorry, at work atm, need to take a deeper look this evening
[14:52] <slangasek> zul: libmysqlclient16 sorted soyuz-side; barring further complications, there should be no need for the version-munging patch
[14:53] <zul> slangasek: sweet!
[14:54] <Laibsch> sistpoty|work: thank you for your response.  To save and the others some time, let me summarize the essence of the question.
[14:54] <Laibsch> My understanding is/ that feature is about new package and new upstream versions.
[14:54] <Laibsch> bug 420918 is not about a new upstream version and thus I thought I was safe.
[14:55] <sistpoty|work> Laibsch: I thought you'd have incorporated parts of upstream cvs (or new version) as part of the diff?
[14:56] <Laibsch> But it replaces a significant chunk of the code and I think it also introduces new functionality.  I believe it's 100% backward compatible, but would need to reconfirm with buzz.  I'm quite sure on this point, though.  The new code is a refactoring plus alpha.
[14:56] <Laibsch> The question is now if the replacing and the alpha mean it falls under FF and needs an FFe
[14:57] <Laibsch> plus all the other work that bitrot has necessitated now
[14:57] <slangasek> Laibsch: certainly not; the feature freeze is about /features/, new upstream versions and new packages are just examples that we single out in all the announcements because it's not necessarily obvious that those are covered by the freeze
[14:57]  * Laibsch is quite dissatisfied with the process of contributing to Ubuntu as an outsider
[14:57] <sistpoty|work> Laibsch: new functionality is a feature, so I guess a FFe is in place (besides the code change is quite huge, from what I've quickly looked at, need to dig that further when at home though)
[14:57] <slangasek> but other new features are also covered by the freeze, for sure
[14:57] <Laibsch> alright
[15:00] <Laibsch> Let me briefly say that this makes me furious, then (I guess I'm to blame for the misunderstanding).  Contributing to Ubuntu as an outsider with generally IMHO good patches failed in 3 out of three cases over a period that spanned two releases (since apparently we missed the boat again).  I think that is an indication that something is not going well.
[15:02] <Laibsch> gjots2, isdnutils and ffgtk
[15:03] <kirkland> superm1: missed your message last night
[15:03] <kirkland> superm1: did someone else get them?
[15:03] <superm1> kirkland, yeah they were gotten
[15:04] <kirkland> superm1: cool
[15:14] <pitti> kirkland: http://qa.ubuntu.com/reports/bug-fixing/lucid-fixes-report.html -> you are number #3, keep it up!
[15:15] <pitti> oh, no fair
[15:15] <pitti> I fix all the udev keymap bugs upstream, and scott gets the credit for it :)
[15:17] <davmor2> pitti: :D
[15:20] <kirkland> pitti: \o/
[15:20] <pitti> kirkland: I just declared war on seb128
[15:20] <kirkland> pitti: :-D
[15:20] <kirkland> pitti: did the algorithm change recently?  I had a 106 a few days ago
[15:20] <pitti> I don't know
[15:20] <kirkland> pitti: meh
[15:20] <pitti> just looked at it the first time during lucid
[15:20] <kirkland> pitti: i noticed it during the sprint
[15:21] <tsmithe> hi- with the latest upload of alsa-plugins, is it just me, or have libasound_module_*_pulse.so disappeared? i'm on amd64, and i've purged/reinstalled/deleted the package cache, and the disappearance persists...
[15:21] <kirkland> pitti: there's one for each of the last few releases, just mangle the url
[15:22] <pitti> kirkland: I know; last time I looked at the karmic one
[15:22] <pitti> kirkland: I meant I looked at the lucid one the first time
[15:22] <kklimonda> tsmithe: going to be fixed with the next release
[15:23] <tsmithe> kklimonda, righty. what's the cause? it seems odd that just enabling jack would destroy pulse...
[15:23] <kklimonda> tsmithe: I don't know details - you could ask crimsun probably
[15:24] <genii> Is the python-lazr.restfulclient 0.9.11-1 or so in yet?
[15:24] <tsmithe> kklimonda, i imagine he's away right now, but thanks for the info
[15:25] <tsmithe> (i'm sure i had something else to ask him, but it's slipped my mind)
[16:03] <sebner> crimsun: hrm, sound is gone :(
[16:03] <apw> anyone else seeing this nice new missing library?
[16:03] <apw> ALSA lib conf.c:3272:(snd_config_hooks_call) Cannot open shared library libasound_module_conf_pulse.so
[16:04] <sebner> apw: yeah, me too
[16:05] <apw> how does one find out where a file _used_ to be coming from
[16:05] <sebner> apw: 1:0.9.22~0.9.21+stable-queue-32-g8478-0ubuntu6 might have br0ken it?!
[16:05]  * apw cries ... pulse
[16:09] <tsmithe> sebner, apw; kklimonda said "going to be fixed with the next release", but he didn't know the exact cause. for some reason the plug-in is absent from alsa-plugins..
[16:09] <tsmithe> (although it's still in ia32-libs)
[16:09] <apw> hrm
[16:10] <jdstrand> apw: that file came from libasound2-plugins
[16:10] <kklimonda> jdstrand: but it has been build against broken libpulse-dev and because of that it's missing pulse plugin
[16:10] <sebner> jdstrand: it's gone ^^
[16:10] <sebner> kklimonda: can you specify "next release"
[16:11] <jdstrand> apw: I just filed bug #523889 on that, and then bug #523902 for the no sound. they may be dupes...
[16:11] <apw> so we'd need to downgrade pulse and alsa-plugins to get sound back
[16:11] <jdstrand> kklimonda: I see. is there a bug report about the busted libpulse-dev?
[16:11] <kklimonda> seb128: I can't - it should have been fixed with the last libasound-plugins upload but I can see that it still doesn't build pulse plugin
[16:11] <kklimonda> jdstrand: I know that crimsum has been working on that before he got to work
[16:12] <seb128> kklimonda, wrong completion?
[16:12] <jdstrand> crimsun: ^ halp with no sound :)
[16:12] <sebner> seb128: I'm sorry for my nick :P
[16:12] <kklimonda> seb128: right :)
[16:12] <kklimonda> sebner: ^
[16:14] <jdstrand> crimsun: actually, I haven't tried you new ubuntu5 yet (still have ubuntu4)-- I'll wait and see how that works
[16:15] <ogra> according to the buildlog the module is there
[16:15] <ogra> -rw-r--r-- root/root      5432 2010-02-18 15:07 ./usr/lib/alsa-lib/libasound_module_conf_pulse.so
[16:15] <ogra> its listed in the deb content on http://launchpadlibrarian.net/39366585/buildlog_ubuntu-lucid-i386.alsa-plugins_1.0.22-0ubuntu5_FULLYBUILT.txt.gz
[16:16] <sebner> ogra: yeah, I think -0ubuntu6 b0rked it
[16:16] <ccheney> mvo: bug 516727, can you look at the package info, iirc you thought it was a bug in apt when i mentioned it to you at the sprint, but i may have overlooked something in the information myself
[16:16] <ogra> seb128, 0ubuntu6 ?
[16:16] <ogra> err sebner
[16:16] <lamont> lool: valgrind - trivial workaround to the still-missing armel build would be a no-change upload of -0ubuntu3
[16:16] <sebner> ogra: oh, sorry, I thought of pulse
[16:16] <ogra> no, i'm looking at alsa-plugins :)
[16:18] <sebner> ogra: ohh, I think it's just not mirrored yet
[16:19] <ogra> ah
[16:20] <mvo> ccheney: I have a look later, it appears we have this bug every cycle
[16:20] <mvo> s/bug/problem/
[16:21] <sebner> ogra: I installed it from LP but it doesn't fix the issue for me :(
[16:22] <ogra> you still see "Cannot open shared library libasound_module_conf_pulse.so" ?
[16:22] <jdstrand> sebner: do you have ubuntu8 of pulseaudio too?
[16:22] <lamont> lool: OTOH, I apparently can cause it to happen without the upload, so don't bother unless you already have a need
[16:23] <sebner> jdstrand: yep
[16:23] <sebner> ogra: aye
[16:23] <jdstrand> I'm still wating on the download...
[16:23] <sebner> ogra: it's not present in /usr/lib/alsa though
[16:23] <sebner> ogra: *not = ''
[16:23] <ogra> should be /usr/lib/alsa-lib/libasound_module_conf_pulse.so
[16:23] <sebner> ogra: it *is* now there, yes
[16:23] <ccheney> mvo: ok
[16:24] <sebner> ogra: nah, not conf
[16:24] <sebner> ogra: libasound_module_ctl_pulse.so	
[16:24] <sebner> I have
[16:25] <ogra> hmm, the buildlog says its there, weird
[16:25] <sebner> oh and conf too
[16:25]  * sebner is confused, sorry
[16:25] <sebner> ogra: it's all there but sound is still not working with the same error message
[16:25] <lool> lamont: Ok; thanks
[16:26] <lool> lamont: So I understand you're working on scheduling it and it will start shortly
[16:27] <kklimonda> sebner: what error? I get no error messages but still no sound :/
[16:27] <lamont> lool: yes
[16:27] <lamont> watching the -n output of this run,  then I'll do it with anger. <-- lool
[16:27] <lool> lamont: great thanks again!
[16:27] <sebner> kklimonda: <ogra> you still see "Cannot open shared library libasound_module_conf_pulse.so" ?
[16:28] <sebner> kklimonda: try aplay /usr/share/sounds/alsa/Noise.wav in your terminal
[16:29] <kklimonda> sebner: I've tried already - I get no error but neither do I hear anything..
[16:29] <sebner> hmm
[16:29] <sebner> me gets
[16:29] <sebner> ALSA lib conf.c:3272:(snd_config_hooks_call) Cannot open shared library libasound_module_conf_pulse.so
[16:29] <sebner> ALSA lib pcm.c:2211:(snd_pcm_open_noupdate) Unknown PCM default
[16:29] <sebner> aplay: main:608: audio open error: No such file or directory
[16:31] <apw> ok it seems that this sound issue is meant to be fixed in libasound2-plugins 1.0.22-0ubuntu5 ... which though built is not yet available for install
[16:31] <sebner> apw: at least not for me :(
[16:31] <kklimonda> apw: I've installed it from launchpad already.. :/
[16:31] <sebner> kklimonda: ^
[16:31] <apw> kklimonda, i see so even if it were it won't help you think
[16:32] <lamont> lool: though for the documentation thing, it's "wait until  ~2PM london next day, and then do your upload, or if there is a reason to _NOT_ upload, poke ubuntu-osa to deal with it"
[16:32] <apw> well i guess we'll give it time till thats available in the archive and then bitch about it
[16:35] <jdstrand> apw, kklimonda, sebner: doesn't work for me here either. I now have ubuntu8 pulse and ubuntu5 libasound2-plugins
[16:35] <apw> bah, then you should reply on the bug that dtchen is closing you all against
[16:35] <jdstrand> ubuntu5 ships the libasound_module_conf_pulse.so
[16:35] <apw> and say you ahve that version and that ... nope its no better
[16:36] <apw> oh ... hrm... but no sound?
[16:36] <apw> ie. aplay -l works?
[16:36] <jdstrand> apw: correct no sound, but still the error that it can't find it
[16:36] <apw> oh hrm
[16:38] <jdstrand> apw, sebner, kklimonda: crimsun responded in my bug 523902
[16:38] <jdstrand> I'll be responding there-- you may want to as well
[16:40] <lamont> jdstrand: once I figure out why bind9 9.7.0 is hat{ing,ed by} libtool, do we want to get that into lucid?
[16:40] <lamont> the DNSSEC stuff in 9.7 is actually usable, from what I'm hearing - supporting 9.6 for 5.5 more years would suck, IMO
[16:41] <jdstrand> lamont: is that how debian is able to start migrating to dnssec?
[16:42] <lamont> you can migrate today, it's just that the tools to manage stuff are all roll-your-own, or crufty.  9.7 actually has tools for doing a bunch of it pretty handily, at least from the mail that's been flying by
[16:42] <sebner> jdstrand: I confirme
[16:42] <sebner> d
[16:42] <lamont> on my todo list for march is to roll one of my zones to dnssec
[16:42] <lamont> under 9.7
[16:43] <lool> lamont: So the procedure is to reupload after the next London 2pm; ok, thanks!
[16:43] <jdstrand> lamont: I think it sounds like a great idea to get 9.7 in-- sounds like it'll need an FFe though
[16:43] <mdeslaur> lamont: personally, I would try and get it in
[16:43] <lamont> who's literate enough in libtool and auto* to tell me why the 9.7 build process decides to use the wrong soname, where it didn't in 9.7rcN
[16:44] <lamont> lool: unless there's a reason to not do an upload (like you added OO.o to armel, and love your life enough to not upload it just because there's no build record for it)
[16:44] <lamont> mdeslaur, jdstrand: thanks - I'll push on it.  it would have landed last night if not for (1) yesterday's chroot cluster, and (2) the pesky build error
[16:45] <jdstrand> lamont: sounds great, thanks :)
[16:45] <mdeslaur> thanks lamont
[16:45] <lamont> so I'll include that in my handwavy FFe :-)
[16:46] <lool> lamont: Rough text https://wiki.ubuntu.com/PackagesArchSpecific
[16:47] <lamont> lool: fwiw, the script is now finally processing lucid, on -n still
[16:48] <lool> lamont: Sorry, what's "-n"?
[16:48] <lool> no do?
[16:48] <lamont> lool: the "don't really do this because I want to see what you're gonna do" flag
[16:49] <lamont> so we're nearly 50% of the way to you having build records
[16:49] <lool> Ok
[16:49] <lamont> timewise
[16:49] <lool> lamont: Thanks, what matters is that it's in progress; I was fearing Pas would be completely broken and take a while to fix
[16:49] <lamont> buildd admins won't be able to do it.  requires shell access on the buildd master, so ubuntu osa or gsa - but how to articulate that at the moment is a good question
[16:50] <lamont> "buildd admins" and having them know that it needs $PRIVS may be sufficient
[16:51] <lool> Ack, I picked buildd admin as a neutral term which is likely to stay correct over time (at least the buildd admin will figure it out  ;-)
[17:29] <Q-FUNK> https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/523716/comments/18
[17:29] <Q-FUNK> hi! would anyone have time to do what dtchen asks?
[17:30] <mathiaz> slangasek: hi - is there a way in upstart to say that a job should be run once another job (a task) has finished running?
[17:31] <mathiaz> slangasek: it seems that start on started other-job starts the job too soon
[17:33] <mathiaz> smoser: ^^
[17:34] <apw> jdstrand, although that update didn't make my sound work it did fix the aplay -l, looking at alsamixer all my output channels were muted, i have two Headphone and one Speaker channel ... unmuting and raising those fixed it
[17:34] <apw> kklimonda, ^^
[17:35]  * sebner agrees with apw
[17:35] <apw> so something else is wrong with alsa handling in something something .. pulse ?
[17:35] <apw> i wonder how i get that message to dtchen
[17:35] <jdstrand> apw: not here: http://paste.ubuntu.com/379221/
[17:35] <apw> crimsun, ^^
[17:36] <jdstrand> that is even after a reboot
[17:36] <apw> jdstrand, definatly sorted that out for me
[17:36] <apw> didi you get the whole pulse update too?
[17:36] <jdstrand> I thought so, maybe not. I can try again
[17:36] <jdstrand> I have ubuntu8 pulseaudio and ubuntu5 libasound2-plugins
[17:37]  * jdstrand tries again
[17:38] <jdstrand> all my pulseaudio* and libpulse* files are the same version
[17:39] <jdstrand> crimsun mentioned in 523716 that alsa-lib needs a change
[17:39] <kklimonda> apw: yeah - that fixed sound issue for me but I don't get any missing library errors..
[17:40] <apw> jdstrand, odder and odder.  mine works now, and syncs ok now
[17:40] <apw> i did only just get the updates with the turning of the hour that i needed
[17:41] <jdstrand> I'm totally up to date with the exception of libdrm* stuff
[17:43] <smoser> mathiaz, i tried running with debug on , to see what events we could work off of, but apparently debug output of upstart does not apply to 'task' items.
[17:44] <smoser> at least I see no occurense of 'cloud' in the output, but several jobs named 'cloud' obviously run
[17:44] <Q-FUNK> apw: crimsun is not anywhere close to his development workstation, so he's askign someone else to apply the fix and upload.
[17:45] <mathiaz> smoser: right - should the cloud-apt-update-upgrade job specifically emit an upstart event?
[17:45] <mathiaz> smoser: or may be the cloud-config-puppet should start on stopped cloud-apt-update-upgrade?
[17:45] <smoser> i was hoping it was not necessary
[17:45] <smoser> i'm testing now if 'stopped' seems to work
[17:45] <mathiaz> smoser: right
[17:45] <mathiaz> smoser: IIRC once a task has run it's in stopped status
[17:48] <sebner> jdstrand: apw kklimonda I have sound again but the volume is only changeable with alsamixer (Speakers)
[17:48] <apw> yeah my volume control icon has three sliders on the bar, only one of which moves
[17:49] <apw> and none of which change the volume
[17:49] <sebner> heh
[17:49] <jdstrand> alsamixer doesn't work here-- I think I'll wait until I am sure I have everything
[17:49] <apw> jdstrand, if aplay -l still errors you don't  have everything me thnks
[17:51] <jdstrand> zika has a similar issue in 523716
[17:51] <jdstrand> apw, sebner, kklimonda: actually a number of people do as in 523716
[17:52] <jdstrand> I can try crimsun's recommendation for alsa-lib and if it works I can upload
[17:52] <sebner> jdstrand: please :)
[17:53] <sebner> wondering if this will fix the volume issue
[17:53] <smoser> mathiaz, thats definitely true, i just didn't know if you could run on its stopped
[17:55] <smoser> mathiaz, it appears that works
[17:55] <smoser> http://paste.ubuntu.com/379230/
[17:55] <smoser> 2 jobs there, 'pre-job' and 'post-job'.  pre-job takes 10 seconds to run, post-job runs on its stopped
[17:55] <smoser> and it seems to function
[17:56] <mathiaz> smoser: great - I'll give a try with the cloud-config-puppet job then
[17:56] <lool> lamont: wee, it's needs build now!
[17:56] <mathiaz> smoser: I'll update the bug
[17:57] <smoser> mathiaz, ok. i'll put a patch into cloud-init that is going to get uploaded soon. for the other 'time not defined' bug
[17:57] <mathiaz> smoser: great - thanks
[18:07] <sebner> jdstrand: are you building it locally or will you upload it to your PPA?
[18:07] <Laibsch> mvo: If you want to get more information about that hardy-lucid update problem, I'm online
[18:08] <jdstrand> sebner: I am building it locally. if it works I will upload
[18:10] <sebner> jdstrand: yeah, just in case it doesn't work for you I could also test it /here and I'd not have to build it ^^
[18:11] <jdstrand> sebner: if it doesn't work, I'll put it in a ppa. I am avoiding that cause I can build much faster here
[18:12] <sebner> jdstrand: sure :)
[18:14] <Q-FUNK> actualy, the solution is more involved than this.  first rebuild alsa-lib, then rebuild libasound-plugins with it
[18:15] <smoser> mathiaz, if you'd like, to review and sponsor, a fix is available
[18:15] <Q-FUNK> jdstrand: ^^
[18:16] <jdstrand> Q-FUNK: I can do that. libasound2-plugins is then a no change rebuild?
[18:16] <smoser> slangasek, cjwatson sorry to ping by name, but i know one or both of you have answers and haven't got responses in previous queries.
[18:16] <smoser> Hi all, last night I asked about seeds (http://irclogs.ubuntu.com/2010/02/18/%23ubuntu-devel.html).  The 'uec' seed for karmic is pulling in kernel images from the release, even though there are newer ones in updates.
[18:17] <smoser> anyone happen to know how that is updated?
[18:17] <persia> smoser: Have you tried playing with germinate locally?
[18:17] <smoser> persia, no.
[18:18] <persia> smoser: That's often a useful first step to understanding why various packages are pulled into various tasks or images.
[18:18] <smoser> but it would seem to me that either a.) we have ot change the seed because its working as designed, or b.) we have to re-generate its output to deal with -updates
[18:18] <smoser> persia, i think its just old data
[18:18] <smoser> is that not a resonable assumption?
[18:20] <kees> kirkland: does this read okay for the VT-hardware feature?  https://wiki.ubuntu.com/Security/CPUFeatures
[18:20] <persia> smoser: I don't happen to know offhand, but I think you would be able to use germinate to validate the assumption.
[18:23] <james_w> smoser: where are the seeds actually read from by the installer? do you know?
[18:23] <kirkland> kees: sure, reads well
[18:24] <smoser> james_w, that i don't know. they're not explicitly read. 'apt-get install uec^'
[18:24] <Q-FUNK> jdstrand: as far as I can tell, it just needs a new alsa-lib with the above change to build against.
[18:24] <persia> That would be getting data from tasksel-data
[18:24] <kees> kirkland: cool, thanks
[18:24] <kirkland> kees: one more thing that might be useful ...
[18:24] <kirkland> kees: dmesg | grep -qs "kvm: disabled by bios"
[18:25] <kees> kirkland: oh, neat.  how does the kernel detect that?
[18:25] <kirkland> kees: dunno, but i've seen it on enough systems that I added that to /usr/bin/kvm-ok
[18:25] <james_w> smoser: ah yeah.
[18:26] <james_w> smoser: I think it just needs the metapackage updating then
[18:26] <smoser> the metapackage meaning the seed being re-generated, right?
[18:26] <kees> kirkland: does svm|vmx show up in flags even if it's disabled in the bios?
[18:27] <james_w> smoser: that will grab the newer dependency
[18:27] <james_w> smoser: the seed is the input, a metapackage is an output
[18:27] <smoser> right.
[18:27] <james_w> smoser: germinate reads the seeds and expands the list of packages with dependencies and the like
[18:27] <james_w> it will then stuff them in to Depends/Recommends of the metapackage
[18:27] <james_w> which is then uploaded to the archive
[18:28] <james_w> where it will be seen by apt and used when installing the uec task
[18:28] <kirkland> kees: yes, it does
[18:28] <smoser> so how do i request that get done ? and it seems that this will have to be done each time a kernel with new ABI is added to -updates
[18:28] <kirkland> kees: which aggravates people, because it looks like they have kvm, but it just won't work
[18:28] <james_w> smoser: it certainly seems like it
[18:29] <kees> kirkland: ah-ha.  this is much easier to detect than NX, then.  cool.
[18:29] <smoser> i would expect that this is not a new issue though
[18:29] <james_w> smoser: most of the other seeds don't depend on a kernel, so it's probably not part of the process
[18:30] <smoser> ok, then assuming i've found out what needs to be done, what do i need to do to have it done ?
[18:30] <persia> james_w: smoser : `apt-get install uec` would be a metapackage, `apt-get install uec^` is a task.  Look at tasksel, rather than the metapackage.
[18:30] <james_w> smoser: https://wiki.ubuntu.com/SeedManagement if you hadn't found it
[18:31] <smoser> persia, it uses the ladder
[18:31] <smoser> 'uec' is not a metapackage
[18:31] <persia> Right.  SeedManagement is stil a good link, but look at tasksel, rather than metapackages for the refresh.
[18:32] <persia> Well, sure, but the *format* of the commands is correct :)
[18:32] <smoser> there were 2 things i didn't see in SeedManagement
[18:32] <james_w> smoser: wile I remember, tasksel wants updating to not install ec2-init
[18:32] <smoser> 1.) how to run 'germinate' ... my attempts fail
[18:32] <smoser> 2.) how the bzr tree gets turned into something that is read by apt
[18:33] <smoser> james_w, i dont think i follow
[18:33] <persia> smoser: 2) exists in the source for the metapackages and tasksel
[18:34] <james_w> smoser: tasksel still lists ec2-init for uec, it should change to cloud-init now presumably
[18:34] <smoser> ah. i thought it had been changed.
[18:35] <smoser> uec in lp:~ubuntu-core-dev/ubuntu-seeds/ubuntu.lucid has only cloud-init
[18:35] <smoser> but does say
[18:35] <sebner> jdstrand: can you tell already?
[18:35] <smoser> Task-Key: ec2-init
[18:36] <kees> kirkland: ok, I've updated the VT section: https://wiki.ubuntu.com/Security/CPUFeatures
[18:37] <james_w> smoser: it seems that tasksel might need updating from the seeds then
[18:38] <jdstrand> sebner: updated alsa-lib fixes the missing lib
[18:38] <SWPadnos> I'm wondering if gphoto2 (and associated packages) can be bumped to rev 2.4.8 before everything gets frozen for Lucid today.  Is this the right place to ask for that?  :)
[18:38] <jdstrand> sebner: still no sound, so I need to rebuild alsa-plugins against it
[18:39] <sebner> jdstrand: Well, I have sound but I needed to use alsamixer and raise "Speakers" part
[18:39] <sebner> *to gain sound
[18:39] <smoser> james_w, so , my udnerstanding of this is that i need to open a bug against tasksel in karmic to resolve the dual kernels issue.
[18:39] <smoser> but are you stating that there is a problem with lucid's seed ?
[18:40] <james_w> smoser: tasksel in lucid is using the old package name still, so it needs updating to skip installing ec2-init
[18:40] <persia> smoser: Try generating the task locally with tasksel first, just so that you're requesting the right thing in the bug.  It may be awkward to discover that a tasksel update is not itself sufficient.
[18:40] <james_w> smoser: I believe this information is derived from the seeds so simply triggering the process that updates it would be enough
[18:41] <jdstrand> sebner: ah, my front speakers were muted-- the pa mixer didn't work though
[18:41] <james_w> persia: are you sure the kernel issue requires a tasksel update?
[18:41] <persia> It is derived from the seeds, although there are some hints in tasksel that might need adjustment.
[18:41] <jdstrand> sebner: so I'll still try with alsa-plugins to see if it fixes that
[18:41] <sebner> jdstrand: yeah, the volume applet is not working
[18:41] <sebner> jdstrand: aye
[18:41] <smoser> so its an semi-automated process?
[18:41] <persia> james_w: No, but I'm sure that any issues with `apt-get install uec^` are best investigated starting with tasksel.
[18:42] <james_w> persia: sure
[18:43] <james_w> but you are giving specific instructions to update tasksel
[18:43] <persia> Yes.  When I have investigated these issues in the past, I update tasksel locally, as this seems the most straightforward way to identify the seed behaviour vs. other package collisions.
[18:44] <persia> I don't think the right answer is to file a bug on tasksel, only that this is the best first step to understanding the issue.
[18:44] <james_w> fair enough
[18:44] <james_w> but given that tasksel doesn't mention the kernel anywhere related to uec that I have found so far I think it is the wrong path
[18:44] <persia> The geneated uec^ task doesn't contain a kernel dependency or recommendation?
[18:44] <Q-FUNK> jdstrand: actually, dtchen's suggestion simply has one extra $ that doesn't blong there
[18:45] <persia> If so, then the next step would be looking at the image constructor (likely either livecd-rootfs or virtual-image-builder)
[18:45] <james_w> persia: the generated might, but the source doesn't
[18:46] <persia> james_w: The source just pulls from the seeds in a special way: that's why I suggest a local update.  I have not previously successfully investigated this class of issues through source inspection.
[18:47] <james_w> yes, it pulls from the seeds to write the task description files, which for ec2 is just "Key: ec2-init\nPackages: task-fields" and description etc.
[18:48] <persia> james_w: Yes, but it's the content of the tasks that become interesting.  Mind you, my previous investigations were things like trying to understand why Ubuntu MID had gnome-panel, which is a bit different.
[18:48] <sebner> lamont: thank you very much! I'll give it a test :)
[18:50] <james_w> persia: would you be so kind as to explain where the tasks are found?
[18:50] <persia> james_w: I don't remember offhand, but I'll go update and let you know.
[18:52] <smoser> james_w,
[18:52] <smoser> /var/lib/apt/lists/us-east-1.ec2.archive.ubuntu.com_ubuntu_dists_lucid_main_binary-i386_Packages
[18:52] <smoser> is where it seems to me to live
[18:52] <james_w> smoser: in what aspect of the Packages file?
[18:52] <james_w> the Task: lines?
[18:52] <smoser> Package euca2ools has:
[18:52] <smoser> Task: eucalyptus-cloud, eucalyptus-cluster, eucalyptus-node, eucalyptus-storage, eucalyptus-walrus, uec
[18:53] <smoser> yeah, so i was assuming that that came from the archive with that in it
[18:53] <sebner> lamont: is it already deployed? At least my PPA says no
[18:53] <james_w> that's what I think too
[18:53] <james_w> persia seems to imply different
[18:54]  * persia remembers having local task definition files, and is currently building a karmic development chroot to dig into karmic tasksel more
[18:54] <smoser> well, when you run tasksel -t, it shows its going to run
[18:54] <smoser> debconf-apt-progress -- apt-get -q -y install uec^
[18:54] <james_w> yep
[18:55] <smoser> so it seems to me that either apt has the ability to turn 'uec^' into a package list or it reads that package list from somewhere else
[18:55] <kirkland> kees: looks great, thanks!
[18:55] <smoser> and i thoguth that somewhere else was Task:
[18:55] <smoser> i very much appreciate both james_w and persia help here.
[18:56] <persia> smoser: Yes, apt gets that information from the local Packages file.  What I think I remember is that tasksel generates something that informs that file.
[18:56] <chris_n> why is mysql in the karmic repo built w/o the InnoDB engine?
[18:57] <mathiaz> persia: not sure what you're trying to do, but you can modify Task file in the Package file by using an override file
[18:57] <mathiaz> persia: and regenerating the archive with apt-ftparchive
[18:57] <persia> mathiaz: That would be a very last resort :)
[18:58] <persia> mathiaz: smoser is trying to understand why uec^ is pulling two kernels.
[18:59] <mathiaz> persia: ah ok. I haven't read the backlog in great details
[18:59] <mathiaz> persia: sorry for jumping into the conversation with non-related information
[18:59] <persia> mathiaz: No worries :)
[19:12] <jdstrand> sebner: fyi-- pavucontrol still didn't work, so I am not uploading alsa-plugins
[19:13] <jdstrand> (alsa-lib is already uploaded)
[19:13] <sebner> jdstrand: grr, annoying. Wondering what's causing this issue. Have you already added a bug comment about it?
[19:13] <jdstrand> sebner: yes
[19:13] <sebner> jdstrand: kk, nothing more we can do then :(
[19:13]  * jdstrand nods
[19:15] <hyperair> sebner: what's up?
[19:16] <sebner> hyperair: sound is (partially) b0rken in lucid
[19:16] <hyperair> broken how?
[19:17] <sebner> hyperair: broken = not working, after some haXX0ring it works now but only if you adjust the volume with alsamixer
[19:17] <lamont> sebner: and should have alien-arena sync'ed sometime today, I expect
[19:18] <hyperair> sebner: that sound bad =\
[19:18] <lamont> mind you, if it's FTBFS, totally your problem. :-p <-- sebner
[19:18] <sebner> lamont: /me already prepared a FFe (I was bored) so I was just waiting for your confirmation :P
[19:18] <lamont> ah, ok
[19:19] <lamont> I did the "lalalala toolchain" dance with slangasek before FF and he said +1 for that package
[19:19] <sebner> lamont: but PPA should also be fixed by now? /me tries again
[19:19] <lamont> yes
[19:19] <lamont> sebner: the only place that should have been broken was source upload processing
[19:19] <lamont> if that fails, please scream at me here
[19:19] <sebner> lamont: exactly
[19:19] <lamont> that was deployed prior to closing the bug
[19:20] <sebner> lamont: give me 2 minutes, I just reuploaded
[19:20]  * sebner screams at lamont 
[19:23] <persia> james_w: In the ubuntu-tasks directory.
[19:23] <persia> smoser: With a local update, I now get four kernels installed installing the task :(
[19:23]  * persia looks more
[19:23] <smoser> persia, that is what i get
[19:23] <smoser> in the official builds . 4 kernels.
[19:24] <smoser> i think that the issue is that whatever process is doing this doesn't recognize that linux-image-2.6.31-304-ec2 is an update to linux-image-2.6.31-302-ec2
[19:24] <smoser> because it *is* a different binary package
[19:24] <smoser> but i really would have thought that the cd installer builds would have run into this.
[19:25] <james_w> persia: yes, but what is in ubuntu-tasks/uec just says "install ec2-init and tell apt to install Task: uec" packages
[19:25] <lamont> sebner: pastebin the error you're getting?
[19:25] <sebner> lamont: the same as in the bug (PPA section)
[19:25] <lamont> ah
[19:25] <sebner> lamont: http://pastebin.com/m636967d6
[19:27] <persia> james_w: That's what I'm seeing also: I'm guessing that the behaviour I saw before was from a very buggy task.
[19:28] <persia> smoser: So, if I'm reading tasksel/README correctly, you're stuck as long as the control files contain the Task: header, which they do.
[19:28] <smoser> james_w, are you able to make the trivial s/ec2-init/cloud-init/ in the lucid uec seed ?  the 'Task-Key:' is obsolete (http://bazaar.launchpad.net/%7Eubuntu-core-dev/ubuntu-seeds/ubuntu.lucid/annotate/head%3A/uec)
[19:28] <persia> smoser: You may want to see if you can filter it some by fiddling with the image constructor.
[19:28] <sebner> jdstrand: how do I put it ... it works magically now
[19:29] <smoser> by 'control' you mean 'Packages' ?
[19:29] <james_w> smoser: I don't have it checked out right now, persia may
[19:29] <persia> smoser: Packages is generated from the several control files.
[19:29] <lamont> sebner: can I talk you into another upload?
[19:29] <smoser> persia, i most certainly can work around htis, but i would rather not
[19:29] <persia> james_w: I can't commit there.
[19:29] <james_w> oh yeah
[19:29] <sebner> lamont: "talk"?
[19:29] <sebner> ah
[19:29] <sebner> lamont: sure
[19:29] <james_w> smoser: stick up a merge proposal then please
[19:29]  * persia plans to fix that in 2-4 weeks, but for now ...
[19:29] <sebner> lamont: I'm available the next 3 hours at least
[19:29] <james_w> I'm struggling to see where the Task is inserted
[19:30] <lamont> sebner: yeah - talk as in "please push the car back to the top of the hill and lets see how it does this time"
[19:30] <jdstrand> sebner: for me, my Front speakers were muted. If I unmute with alsamixer, all is fine. if I mute with alsamixer, I cannot unmute again
[19:30] <jdstrand> sebner: (with pavucontrol)
[19:30] <lamont> sebner: there are a number of machines...  and I think I hit them all this time
[19:30] <smoser> james_w, i dont know htat either, but for the lucid issue, getting that fixed is a requirement, so i'll put a merge proposal
[19:30] <james_w> it's surely not in the debian/CONTROL file, but Launchpad doesn't set it as an override either from what I can see
[19:30] <sebner> lamont: heh, just tell me when I should do another test-upload :)
[19:31] <sebner> jdstrand: weird
[19:31] <james_w> unless there is some behind the scenes magic going on
[19:31] <lamont> sebner: as in it just failed again, or you're waiting for me to say "go"?
[19:31]  * persia has strong suspicions of magic
[19:32] <lamont> because should be fixed from http://pastebin.com/m636967d6
[19:32] <sebner> jdstrand: Now *everything* works here, I didn't update to your alsa-lib update yet though!
[19:32] <sebner> lamont: go
[19:33] <jdstrand> weird
[19:33] <sebner> jdstrand: Ubuntu self-healing abilites are suprising me always and always ;)
[19:34] <jdstrand> heh
[19:35] <sebner> jdstrand: the only thing is that never is alright is the graphical volume slide (I usually adjust volume with my laptop keys) and the slide doesn't follow it correctly (means, I set full volume with the keyboard keys and the slide is maybe at a half)
[19:36] <smoser> james_w, ok. i proposed you as a reviewer of a merge : https://code.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.lucid/+merge/19647
[19:36] <james_w> thanks
[19:38] <sebner> lamont: still waiting on the mail ..
[19:40] <smoser> persia, james_w just so i could track what is going wrong, and to avoid this occuring in lucid i opened https://bugs.launchpad.net/ubuntu/+bug/524020
[19:41] <james_w> smoser: ok, you need to get the overrides on cocoplum updated
[19:41] <smoser> i'd appreciate if someone can accept my nomiation for lucid and karmic of that bug
[19:41] <smoser> cocoplum is a new word to me
[19:42] <james_w> it's the machine that the archive actually lives on
[19:42]  * sebner hugs lamont and showers him with cookies. You are a GENIUS!
[19:42] <james_w> what is happening is that LP is calling apt-ftparchive in such a way that it adds Task to all the packages as appropriate
[19:43] <james_w> it does that using override files
[19:43] <lamont> \o/
[19:43] <james_w> these are not generated by LP as it works
[19:43] <james_w> the files list "package-name Task foo" stuff
[19:43] <james_w> so we need those updated based on an updated germinate run
[19:43] <james_w> however, I have no idea how to do that
[19:44] <james_w> the files are owned by lp_publish, but that user doesn't have a cron job to do it or anything
[19:44] <james_w> so, I don't know if it is done manually on occasion, or LP handles it out of the path of publishing
[19:44] <sebner> lamont: let me do the FF because I won't get the chance to do many this time ;)
[19:47] <james_w> and now I must go cook dinner before I get in to trouble
[19:47] <james_w> smoser: I hope that allows you to find someone who can actually fix it
[19:47] <smoser> james_w, thanks. i'm much closer than before.
[19:47] <james_w> smoser: unfortunately the soyuz people are all Europe-based, so aren't around to help
[19:48] <smoser> it doesn't have to happen *right now*
[19:48] <smoser> its been busted since the 4th.
[19:52] <sebner> lamont: https://bugs.edge.launchpad.net/ubuntu/+source/alien-arena/+bug/523811/+index#New
[19:53] <sebner> cjwatson: KUDOS to you too! .. as stated in the bug report ;)
[20:08] <persia> sebner: All fixed now then?
[20:09] <sebner> persia: yep, Kudos to you too for your help :)
[20:09]  * persia didn't do anything 
[20:10] <sebner> persia: you helped to track it down and supported my (miss)communication :)
[20:10] <persia> The latter maybe :)
[20:10] <sebner> heh
[20:15] <tlp> hey guys. I just did a dist-upgrade of Lucid (from an earlier 'snapshot' of packages) and PulseAudio broke (no sound). Is this behavior expected? Trying to find a changelog or something.
[20:15] <sebner> tlp: it's known, yes
[20:15] <persia> tlp: Known issue, under investigation
[20:15] <tlp> k
[20:17] <tlp> oh, I see there's a 'lucid-changes' list
[20:30] <sebner> jdstrand: urgh! My sound magically disappeared as magically as it appeared! xD
[20:30]  * jdstrand shakes head
[20:33] <sebner> jdstrand: interesting! Doing "aplay /usr/share/sounds/alsa/Noise.wav" magically brought my sound (banshee, firefox) back! xD
[20:34] <jdstrand> too weird
[20:34] <tlp> that magic unfortunately didn't work for me :p
[20:35] <jdong> can a core-dev open the karmic task on https://bugs.edge.launchpad.net/ubuntu/+source/cryptsetup/+bug/474327 please?
[20:36] <jdong> (*wonders if there's a way for ubuntu-sru to be able to do this*)
[20:38] <NCommander_> doko: ping, I saw that you changed http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40860; is it possible that this regression is also responsible for the libuno breakage?
[20:40] <lifeless> mvo: do you know about --author ? (also james_w, does debcommit use --author ?)
[20:41] <mvo> lifeless: no
[20:41] <mvo> bzr --author?
[20:41] <doko> NCommander_: maybe
[20:42] <lifeless> mvo: when committing a patch from the internet, you can attribute it by doing 'commit --author 'Foo bar <foo.bar@example.com>'
[20:42] <lifeless> mvo: you can supply the field multiple times to indicate multiple authors
[20:42] <mvo> nice
[20:42] <lifeless> mvo: this is useful when doing cherrypick merges too
[20:42] <mvo> I don't know this one
[20:44] <lifeless> cherrypicks?
[21:22] <mdeslaur> Does anyone know why my locales are "utf8" instead of "UTF-8"?
[21:23] <persia> Why should they be "UTF-8"?
[21:23] <mdeslaur> well, it used to be that way, and "utf8" is causing problems with vm-builder
[21:23] <lifeless> mdeslaur: they are homophones, depends on the way locales is setup
[21:24] <persia> Isn't this a bug in vm-builder if it's relying on a specific value?
[21:24] <lifeless> mdeslaur: also some stuff in libx11 is odd and uses UTF-8 in its compose tables
[21:24] <lifeless> mdeslaur: what is the specific problem in vm-builder?
[21:25] <mdeslaur> it's calling "locale-gen en_CA.utf8" and that is failing
[21:27] <ogra> persia, it is
[21:27] <ogra> i gues vm-builder just picks up from $LANG
[21:27] <ogra> *guess
[21:28] <mdeslaur> yes, it's picking it up from $LANG, and using locale-gen to validate it
[21:28]  * ogra just helped fixing the same issue in ltsp
[21:28] <mdeslaur> but locale-gen doesn't like utf8 it appears
[21:28] <ogra> yes, its not supposed to
[21:29] <ogra> make vm-builder read /etc/default/locale or translate the utf8 to UTF-8 properly
[21:29] <lifeless> mdeslaur: it shouldn't call locale-gen anyway, locale -a is the right way to validate a locale
[21:29] <ogra> lifeless, well, it probably also wants to generate locales :)
[21:30] <lifeless> I suggest fixing locale-gen
[21:38] <mdeslaur> I suspect vm-builder just want to make sure the locale specified by the user is a valid one...and it's using locale-gen to do that (which is very wrong). locale -a will only list existing locales. Does anyone have an idea to validate a locale string?
[21:40] <lifeless> mdeslaur: define validate
[21:40] <mdeslaur> lifeless: make sure it's a locale that could be valid
[21:40] <mdeslaur> ie: not en_USS.utf8 by mistake
[21:40] <lifeless> mdeslaur: under what conditions. Sorry to be picky but its actually nontrivial.
[21:41] <mdeslaur> lifeless: it's a string that the user passes as an argument to pick which locale he wants his vm to be installed as
[21:42] <mdeslaur> if it's non-trivial, I guess it doesn't need to be validated, it could just fail if there was a mistake.
[21:42] <lifeless> so the full list of locales isn't available locally.
[21:42] <lifeless> because installing a langpack makes a locale available
[21:42] <persia> Could it be made available locally in some way?
[21:43] <mdeslaur> oh, I see
[21:43] <lifeless> e.g. look at your /var/lib/locales/supported.d/
[21:43] <persia> Or does it exist as the collection of all defined langpacks?
[21:43] <mdeslaur> then again, it would depend on the os being installed inside the vm, so even a local list doesn't really make sense
[21:43] <lifeless> persia: the language control panel figures out the installable options some how
[21:44] <lifeless> mdeslaur: and the available languages depends on the release of ubuntu - karmic doesn't have klingon
[21:44] <lifeless> [for instance]
[21:44] <persia> Ah, so vm-builder *could* know the set, and then just match to determine if it's valid, but that might bloat the chroot
[21:44] <mdeslaur> lifeless: exactly
[21:44] <mdeslaur> well, I think the sanest thing for now is to not validate the locale string supplied by the user
[21:44] <lifeless> persia: but it would have to download the set, for the target distrorelease its building the vm for
[21:44] <mdeslaur> thanks guys
[21:45] <lifeless> mdeslaur: I think you could check its well formed
[21:45] <lifeless> so not 'asdkaporqj'
[21:46] <mdeslaur> yeah
[21:46] <persia> lifeless: Sure, hence "bloat the chroot"
[21:46] <lifeless> persia: ack
[21:46] <persia> In addition to the list, it may need any number of tools to be able to assemble it.
[21:48] <kees> pitti: I adjusted the apport anonymizer to leave several specific ProcFoo files alone since they never have host/user names, and it just confuses things.
[22:01] <slangasek> mathiaz: 'start on stopped', I would think
[22:01] <mathiaz> slangasek: right - smoser investigated and found the same result
[22:02] <mathiaz> slangasek: the semantic are bit wired but in the end it works
[22:02] <smoser> mathiaz, that is checked in now.
[22:33] <sebner> slangasek: thanks for syncing but you are really killing the fun ;-P
[22:37] <slangasek> sebner: your sense of fun frightens me
[22:37] <dylanmccall> hi, everybody!
[22:37] <dylanmccall> Does anyone here happen to work on the update manager?
[22:38] <sebner> slangasek: heh, anyways. Thanks again :)
[22:38] <persia> dylanmccall: Theoretically, most of us are supposed to care about it, but several of us actually have done stuff.  Why?
[22:39] <dylanmccall> persia: I'm working on a little UI bug for it, and noticed there's both an UpdateManager.glade and UpdateManager.ui. Just wondering which one I should touch :)
[22:40] <persia> Oh.  That's not a part I've worked on, so I don't know offhand.
[22:41] <lifeless> dylanmccall: check which was changed most recently
[22:41] <persia> dylanmccall: Give it a whijle to see if someone else answers.  If not, investigate the build scripts to make sure the .ui isn't autogenerated.
[22:41] <dylanmccall> lifeless: aha, very wise
[22:42] <dylanmccall> thanks :)
[22:51] <LaserJock> hmm, is gtk+2.0 likely to be updated to 2.20 by release?
[22:52]  * sebner waves at LaserJock :)
[22:52] <LaserJock> hi sebner
[23:01] <LaserJock> robbiew: awesome news on the twitter/identi.ca status accounts? how do people submit to that?
[23:04] <robbiew> LaserJock: right now, I think we've simply setup a password that we can share...but haven't figured out exactly WHO to share it with
[23:04] <robbiew> don't want it to become a spam site
[23:05] <LaserJock> right
[23:05] <LaserJock> I wondered if the current "any messaging app crashes" thing would count, etc.
[23:05] <LaserJock> it's hard to know, but this is something I've wanted for a long time
[23:10] <robbiew> LaserJock: the intention was to use it for disastrous type situations, like when we made the move to upstart last cycle...and the buildds went down in the middle of the package upload :/
[23:10] <robbiew> there's always some inherent risk people take, who use the in-development releases....and we didn't want to have to change the status for every little thing
[23:10] <alkisg> I have 2 keyboard layouts (us/gr). When I login with an English interface, I can see a language indicator in the panel. When I login with Greek UI, I can see an empty space in that place. Which package is that, so that I can seach why the icon is missing with the Greek UI?
[23:11] <LaserJock> robbiew: maybe it could have a ramped meaning? like say pre-FF just for extreme cases and then say after Beta-freeze or something more low-level problems as more unexperienced people test?
[23:14] <robbiew> LaserJock: hmm...that might be a good point
[23:14] <LaserJock> robbiew: just a thought, maybe trying to match increasing expectations of stability
[23:15] <robbiew> LaserJock: we have a larger plan to address the problem
[23:15] <robbiew> https://blueprints.edge.launchpad.net/ubuntu/+spec/foundations-lucid-stop-the-line-for-update-manager
[23:15] <robbiew> but could not fit that into Lucid
[23:15] <robbiew> hopefully we can do something for Lucid+1
[23:16]  * persia preemptively sets --break-my-system-please
[23:16] <LaserJock> robbiew: ah, that would indeed be helpful
[23:16] <lifeless> persia: 'fu**-me-harder' ? well known hacker slang ;>
[23:16] <LaserJock> I don't regularly use IRC anymore and I find it hard to know wha tthe current state is
[23:17] <LaserJock> I was thinking of having like a "don't install things that are newer than 2 days" button
[23:17] <LaserJock> but then I figured everbody would do that and it would just move the break point
[23:17] <robbiew> heh...yeah
[23:19] <SWPadnos> hide the button, so only people who know how to look for it can postpone the breakage
[23:19] <jcastro> robbiew: are these for development releases or for everything?
[23:20] <LaserJock> it shouldn't be needed for other things should it?
[23:20] <LaserJock> stable release I mean
[23:20] <robbiew> jcastro: development...as once we release, I don't see how we could fubar the archive that much
[23:20]  * sebner thinks about throwing ubottu with bad language notice onto lifeless :P
[23:21] <sebner> +at
[23:21] <LaserJock> I could see using it for things like buildd borkage or LP issues or something
[23:21] <jcastro> robbiew: ok cool, I'll get the word out
[23:22] <persia> robbiew: We can do all sorts of things to -proposed :)  Maybe it ought cover that kind of case as well.
[23:22] <persia> (although this only affects some users)
[23:22] <lifeless> hmm
[23:22] <alkisg> Ah, got it, "gnome-settings-daemon".
[23:22] <lifeless> you could do something interesting with suites
[23:22] <lifeless> you know how debian does a waterfall with QA checks at each step
[23:23] <lifeless> imagine lucid-0 (immediately when built), lucid-1 (one day old migration, no critical bugs, no missing deps), lucid-2 (etc)
[23:23] <persia> lifeless: Don't we do that with -proposed and -updates?
[23:23] <persia> lifeless: Oh, you mean for the development release?
[23:24] <lifeless> persia: no, they are manual. Yes.
[23:24] <persia> So a no-RC-bugs+no-broken-packages repo?
[23:24] <sebner> lifeless: I thought devel release are meant to break ^_^
[23:24] <lifeless> not suggesting it seriously, its a gedanken
[23:24] <persia> Everyone would end up clamouring for that to get real support.
[23:25] <LaserJock> sebner: but at some point they move from being meant to break to being meant to be tested in a decently stable state
[23:25] <sebner> lifeless: denglish, shame on you :P
[23:25] <lifeless> sebner: huh?
[23:25] <sebner> LaserJock: we have FF and other freezes for that?!
[23:25] <jcastro> sebner: plus people are going to end up using it anyways, might as well give them a warning if we are able to
[23:25] <cjwatson> smoser: uec> I think it may be impossible to change this as stated; the Task fields in karmic's Packages file are frozen (as for all stable releases).  we'll have to think hard about this.  ask me next week ...
[23:25] <LaserJock> sebner: yeah, but post FF it's nice to know when something bad happens
[23:25] <cjwatson> smoser: all the stuff about tasksel is a red herring :)
[23:25] <lifeless> sebner: thats not why we have freezes really; we have freezes to stop adding more defects than we take out.
[23:25] <sebner> lifeless: gedanken, It thought it's only valid english with "gedanken experiment"
[23:26] <persia> sebner: gedankenexperiment is a perfectly good English word.  If nothing else, the English are excellent word thieves.
[23:26] <sebner> persia: I know but I don't think gedanken alone is valid, is it?!
[23:26] <persia> WHy not?  There was no experiment involved.
[23:26]  * persia doesn't think it's any usefully different than "sushi" in terms of word borrowing.
[23:27]  * sebner just didn't found it in his dictionary standing alone so we was curious
[23:27] <lifeless> if its literally 'mind' then its not very useful alone; I thought it was more 'thought' than mind, but a quick de dict check suggests 'mind' not 'thought
[23:27] <cjwatson> it's the past participle of denken, to think
[23:28] <sebner> cjwatson: yeah, I'm native german so I got curious
[23:28] <sebner> lifeless: it's more thought imho
[23:28] <cjwatson> as a noun it gets used for various related meanings, sort of like a gerund
[23:29] <lifeless> sebner: not according to the dict I found :P. Anyhow I meant it as 'thought'
[23:29] <sebner> lifeless: That's the reason why I got curious, you used gedanken instead of thought. /me likes seeing mixture of language :)
[23:31] <sebner> lifeless: singular is "Gedanke" btw
[23:58] <TheMuso`> any ocaml experts around could take a look at graphviz, and advise the best way to depend on ocaml-base-nox, as ocaml-base-nox-$bla via provides from ocaml doesn't work due to soyuz design.