[00:29] <psusi> Keybuk, last night my testing showed some improvement on ureadahead after the defrag, but still not as good as I think it should be... today I've been working on an idea that I think could punch it up another level... right now it calls readahead() on each file, but this stalls on indirect blocks, and can't be done on the directories, which is where the open() loop waits a lot
[00:30] <psusi> Keybuk, so what if instead when generating the pack file, we first, add the directories on the paths to the files to the list of files, then translate the block addresses to absolute block addresses, use e2fslibs to look up any indirect blocks and add them tot he list, then merge the list into a series of extents of raw block addresses
[00:30] <psusi> then readahead() that list on the raw block device
[00:34] <psusi> in theory that could result in a single massive read
[01:12] <Caesar> ScottK: you're captain backports, aren't you?
[01:22] <smoser> hggdh, you there ?
[01:47] <ScottK> Caesar: I'm involved in them.
[01:48] <kees> hm, LP doesn't like my src-format-3 package..
[01:48] <kees>   dpkg-source: info: applying networkmanager.patch
[01:48] <kees>   1 out of 8 hunks FAILED -- saving rejects to file
[01:48] <kees> policy/modules/services/networkmanager.te.rej]
[01:48] <kees> this doesn't happen for me locally...
[01:51] <hggdh> smoser: I am here
[01:57] <Keybuk> psusi: no idea, try it :-)
[01:57] <Keybuk> YokoZar: hello?
[01:58] <YokoZar> Keybuk: There was some discussion in #ubuntu-motu earlier about using invoke-rc.d procps start || true   instead of start procps || true  in postinst scripts
[01:58] <Keybuk> YokoZar: since procps is an Upstart job, that would be wrong
[01:59] <YokoZar> Keybuk: Well let me link to you what lool said: https://bugs.launchpad.net/ubuntu/+source/wine/+bug/447197/comments/52
[01:59] <kees> YokoZar: the "|| true" will fix that.
[02:00] <YokoZar> kees: the || true fixed that in the bug report, yes, but we're talking about the first part (start procps vs invoke-rc.d procps start)
[02:00] <kees> YokoZar: it must be "start".
[02:01] <kees> YokoZar: using invoke-rc.d for an upstart job is wrong.
[02:01] <Keybuk> lool is wrong
[02:01] <Keybuk> any new code should be written to use the native Upstart interfaces
[02:01] <Keybuk> the /etc/init.d/procps symlink is only there to teach humans to use the new interface
[02:01] <YokoZar> Keybuk: kees: what about policy-rc.d ?
[02:02] <Keybuk> using that for Upstart jobs is also wrong
[02:02] <Keybuk> anything *-rc.d is wrong for Upstart
[02:02] <Keybuk> those are sysvinit tools
[02:03] <YokoZar> So people who have made one should migrate configuration to upstart?  Does upstart cover everything in 10.04 now?
[02:03] <Keybuk> no, not yet
[02:04] <YokoZar> So how do we handle the mixed case then?
[02:04] <Keybuk> we are migrating from one system to another
[02:04] <kees> YokoZar: procps moved to upstart, therefore it should use "start" instead of the *-rc.d commands
[02:04] <Keybuk> things migrated to the new system should use the new interfaces
[02:04] <YokoZar> ok that makes sense
[02:04] <Keybuk> otherwise what is the point of spending years writing a new init system if everyone carries on pretending it's still the old one?!
[02:05] <jdong> is KDE4 going to spend another year writing an init system abstraction layer wrapper?
[02:05] <jdong> *ducks*
[02:06] <Keybuk> KDE4 will probably write an abstraction layer to an init system abstraction layer
[02:06] <jdong> :)
[02:06] <Keybuk> in case they want to change init system abstraction layers later on
[02:06] <jdong> I can totally see that happening though :)
[02:06] <YokoZar> Keybuk: well one option is to keep using the old one as compatibility until everything is in upstart and then deprecate it
[02:07] <Keybuk> YokoZar: if we do that, we'll have a great big flag day
[02:07] <Keybuk> and realise that the Upstart interface isn't up to the job
[02:07] <YokoZar> Yeah
[02:07] <jdong> on a slightly related note, what's the purpose of the "service" command
[02:07] <YokoZar> red hat compatibility I think
[02:07] <kees> YokoZar: so now we'll have wine back in the archive?  did you test all the conffile transitions?
[02:07] <Keybuk> jdong: compatibility with RHEL
[02:07] <jdong> Keybuk: ah. so we're not supposed to use it as the replacement for invoke-rc.d
[02:08]  * Keybuk wonders whether the RHEL 6 "service" command knows about Upstart
[02:08] <Keybuk> jdong: no
[02:08] <jdong> *nods*
[02:08] <YokoZar> kees: Yes that was working before it disappeared from the archive (it's the same as the wine1.2 code too)
[02:08] <YokoZar> kees: actually technically it didn't disappear so much as have source but no binary
[02:09] <kees> YokoZar: okay.  I guess it's okay to have two binary packages fiddling with the same debconf value.
[02:09] <Keybuk> YokoZar: Upstart is still being developed
[02:09] <YokoZar> kees: two conflicting binary packages at that
[02:09] <Keybuk> and I want it to not just be "good enough" but *perfect*
[02:09] <Keybuk> so the whole point of using its interfaces now is to discover where they're not good enough, let along not perfect
[02:09] <Keybuk> something to do with eating dog food ;)
[02:09] <YokoZar> That's fair
[02:09] <kees> YokoZar: oh! they conflict? excellent, that makes me worry much less.
[02:11] <jdong> kees: btw, when is Ubuntu planning to issue a patch for that fun reiserfs xattr root exploit?
[02:11] <Keybuk> +CONFIG_FS_REISERFS=y
[02:11] <Keybuk> -CONFIG_FS_REISERFS=n
[02:11] <jdong> hahaha :)
[02:11] <YokoZar> Keybuk: This whole discussion tells me we need to document this somewhere official-sounding, preferably debian-inclusive (policy manual?)
[02:11] <ion> I was under the impression the point of the service command was to run init scripts under a consistent environment, i.e. with / as the pwd and no crap in environment variables, in case the scripts/daemons are written poorly and shit themselves in the wrong environment. And they are, and they do.
[02:12] <Keybuk> YokoZar: feel free to include it in the Ubuntu policy manual
[02:12] <Keybuk> ion: it doesn't really do that though, does it?
[02:12] <YokoZar> Keybuk: if I do that will you write a lintian test that complains about rc.d?
[02:13] <Keybuk> YokoZar: no, lintian is written in a programming language I do not write
[02:13] <kees> jdong: it's in progress; I'm waiting on the kernel team for an update.  http://people.canonical.com/~ubuntu-security/cve/2010/CVE-2010-1146.html
[02:13] <ion> keybuk: It does cd / and env -i ...
[02:14] <Keybuk> ion: that's nowhere near a "sane environment"
[02:14] <jdong> kees: ah, cool. We don't mount -o user_xattr by default if a user installs onto reiserfs... right? *cringe*
[02:14] <Keybuk> ion: e.g. where's the code to reset the process mark and clear pending signals currently masked?
[02:14] <kees> jdong: no, user_xattr is highly non-default
[02:14] <jdong> kees: ok, *whew*, that's at least... better :)
[02:14] <Keybuk> mark? mask!
[02:14] <ion> keybuk: I never said sane. ;-)
[02:14] <YokoZar> kees: while I have your ear can I talk about cautious-launcher?
[02:14] <kees> YokoZar: sure thing
[02:15] <YokoZar> kees: If I remember our UDS discussions, it's supposed to permit removable media (CDs, sticks) correct?  Is this handled through the gvfs mount options?
[02:16] <ajmitch> jdong: that's a rather special bug there for reiserfs :)
[02:16] <Keybuk> in fact
[02:16] <Keybuk> I'm going to be mean
[02:16] <kees> YokoZar: it follows the filesystem markings, so if an external device has been mounted without execute, that's a bug with the mounting process.
[02:16] <jdong> ajmitch: oh it's a really fun one. (1) make your own biinary, (2) mark it suid root, (3) profit!
[02:16] <Keybuk> I'm going to add code to initctl to refuse to run if called from invoke-rc.d ;-)
[02:16] <jdong> ajmitch: let's hope there's no hapless reiserfs+beagle users that decided to mount -o user_xattr ;-)
[02:17] <kees> Keybuk: please don't do that for lucid.
[02:17] <ajmitch> first upload to maverick will be upstart with that change?
[02:17] <YokoZar> agree 100% with kees here ;)
[02:17] <Keybuk> kees: no, not for lucid
[02:17] <Keybuk> for maverick
[02:17] <YokoZar> If you do that we don't need the lintian test since the package will fail to install
[02:17] <ajmitch> I wonder how many universe packages would need to be updated for that
[02:17] <YokoZar> ajmitch: I'm guessing it's on the order of 10
[02:18] <ajmitch> YokoZar: all ones you've been touching?
[02:18] <kees> Keybuk: maverick, yes, +1.  :)
[02:18] <YokoZar> ajmitch: I've touched about 3 so far, and they're all "weird" compared with most universe stuff.  Init script stuff seems like something main packages are far more likely to deal with
[02:19] <ajmitch> having lots of nice intentioanl breakage is what maverick's all about, isn't it?
[02:20] <jdong> ajmitch: can't we just rely on a pulseaudio upload to do that?
[02:20] <YokoZar> Maverick will take the "light" theme to a new level by continually increasing the gamma correction as you use the computer
[02:20] <jdong> YokoZar: and maybe it'll finally be completely impossible to tell which window is in the foreground!
[02:20] <ajmitch> jdong: it isn't yet?
[02:20] <jdong> ajmitch: it's pretty close to.
[02:20] <jdong> but if you sit around scratching your head and alt-tabbing a few times, you'll eventually figure it out
[02:21] <jdong> or realize it's time for an eye exam
[02:21] <YokoZar> There will be an innovative solution to that using the empty upper right of the window jdong
[02:22] <YokoZar> jdong: it will say "I am your window, use me!"
[02:22] <ajmitch> or the active window title will have <blink>
[02:22] <Keybuk> huh?
[02:22] <Keybuk> it's easy to tell which one is active
[02:22] <jdong> YokoZar: awesome! Now I can click the magical orb thing when I mean to close the window.
[02:22] <jdong> Keybuk: well maybe Santa needs to buy me an IPS panel but they look like very similar shades of cream to me.
[02:22] <Keybuk> jdong: I tell by whether the window controls are lit
[02:23] <YokoZar> I'm going to be at UDS using the Human theme and feel like a total curmudgeon it's gonna be fantastic
[02:23] <jdong> Keybuk: oh I guess that works if I retrain myself to take my cue from there.
[02:23] <ajmitch> YokoZar: or you could install that scary fvwm95
[02:23] <ajmitch> that screenshot just looked ugly on planet
[02:23] <jdong> but I've likekd the ability to just look at the center of the bar where the title is.
[02:24] <YokoZar> More likely is you were looking at color unless you were using the dark theme
[02:24]  * ajmitch was using clearlooks with its glorious blue
[02:43] <Caesar> ScottK: I'd like to get the latest upstream rsyslog 4.6 into lucid-backports and hardy-backports
[02:43] <Caesar> I'll do the legwork
[02:50] <ScottK> Caesar: First it needs to be in Maverick.  We only backport from later Ubuntu releases.
[02:50] <ScottK> But it'll need testing in any case, that can start now.
[04:30]  * ccheney sees Jono's post and wonders if he can manage to install his first Linux distro in vmware still
[04:31]  * ccheney has no idea what it even looked like anymore
[04:33]  * ccheney isn't sure if ide cdrom even existed back then
[04:49] <ccheney> seems even older than bootable cds
[04:51] <jdong> psusi: haha http://jdong.mit.edu/~jdong/fragraph.svg
[04:51] <jdong> psusi: whenever your defragger is ready to have a UI ;-)
[04:51] <jdong> psusi: (we hacked a quick graphing library to output those cliche Windows defragger ring-block graphs)
[04:52] <ccheney> yuck installing this in vmware will actually be harder than installing it originally 15+ years ago
[04:54] <psusi> jdong, hrm... I've been wanting a graph like that of the ureadahead pack file lately ;)
[04:54] <psusi> jdong, though defrag already has a super sexy ncurses ascii gui, hehehe
[04:54] <ccheney> whee, got the Slackware 2.1.0 bootloader to show up :)
[04:55] <jdong> psusi: haha some perverse part of me wants to quickly hack together a script that visualizes what my current disk looks like.
[04:56] <psusi> jdong, :)
[05:28] <ccheney> hmm virtualbox doesn't support old enough either, qemu might be but its only back to ppro
[05:46] <jdong> is there a magical pulseaudio way of redirecting audio output to microphone input?
[05:46] <jdong> i.e. if you're voiceconferencing with someone and want to play a bit of music?
[05:47] <persia> Yes, but.
[05:48] <persia> So, pulse operates on the idea of sources and sinks, and you can connect any arbitrary source to any arbitrary sink, at any arbitrary gain, and it does the right thing.
[05:48] <persia> But this complexity is painfully comfusing to users, so there's no UI for doing it.
[05:49] <persia> If you're crafty, you can do things with pacat and named pipes.  There might be a less baroque way to do it.  The API is fairly powerful.
[05:50] <persia> But you probably don't want to redirect to microphone input anyway (as sending to a source doesn't make sense), but rather to the audio sink for your application.
[05:51] <jdong> right, I guess I meant audio sink for application
[05:51] <jdong> I'll look at pacat then
[05:51] <persia> If you have a sound file, `pacat -d ${SINK}` should work, assuming you know the sink identifier.
[05:52] <jdong> where can i get the sink identifier?
[05:52] <persia> If you need to redirect the output of one program into the input of another, that's harder.
[05:52] <persia> Extra points for a nifty routing tool for complex routing maps that everyone can use :)
[05:52]  * persia doesn't know pulse well enough to know
[05:53] <jdong> yeah, I'd love to learn more pulse tricks as well
[05:59] <TheMuso> I think pulse allows you to record what you hear out your speakers, i.e it will directly monitor the output sink.
[06:00] <persia> That's pamon, isn't it?
[06:00] <TheMuso> Not sure what paman has to do with it, I have seen the option I talked about in pavucontrol.
[06:00] <TheMuso> pamon even
[06:01] <persia> I thought pamon was PulseAudioMonitor
[06:01] <persia> I may be wrong.
[06:01] <TheMuso> never used it personally, and I thought it was deprecated.
[06:02] <persia> You're probably more up-to-date than I.
[06:03] <persia> The only feature that doesn't "just work" for me is the ability to automatically route different applications to different audio interfaces.  I'd like something like patchage for those special times I want to do something fancy, but for now all my fancy stuff can be done with alternate applications.
[07:07] <persia> Anyone have a PS3?  I worry that https://launchpad.net/ubuntu/+source/ps3-kboot/1.6-2build1/+build/1517259 might make it hard to support any issues with PS3 for lucid.  Perhaps not as hard as the recent firmware update, but ...
[07:12] <bilalakhtar> Has the memory leak problem been solved?
[07:24] <pitti> directhex: right, I checked before that the package was in depwait, so it should have built by now
[07:24] <pitti> good morning
[07:25] <directhex> pitti, it has indeed!
[07:25] <pitti> jdong: SRU versioning> I don't have a strong preference either way; 0.1 style is safer for avoiding future conflicts, but then again we'll just copy lucid-proposed SRUs to maverick, so for those cases it doesn't matter
[07:25] <persia> And it fixes the bug
[07:25] <directhex>  Depends: banshee (>= 1.6.0), banshee-extensions-common (= 1.6.0-1ubuntu4), libappindicator0.0-cil (>= 0.0.19), libglib2.0-cil (>= 2.12.9), libgtk2.0-cil (>= 2.12.9), libmono-addins0.2-cil (>= 0.4), libmono-corlib2.0-cil (>= 1.2.2.1), libnotify0.4-cil (>= 0.4.0~r2998)
[07:25] <directhex> deps! sweet sweet deps!
[07:25] <directhex> just like momma used to make!
[07:26] <pitti> :-)
[07:26]  * pitti puts some ice cream on top
[07:28] <directhex> cdbs is incredibly poor at dealing with library packages containing both arch and indep pieces, if left to its own devices. the trick is binary-predeb/someindeppackage:: binary-fixup/archpackageitneeds
[07:42] <ArneGoetje> slangasek, pitti: uploading final langpacks.
[07:53] <joaopinto> good morning
[07:55] <pitti> ArneGoetje: thanks, I'll shepherd them through the queue
[07:58] <pitti> apw: linux-headers-2.6.32-21-versatile wants to go back to universe, but I think it would be much easier to have it in main, so that all linux binaries are in main; WDYT?
[08:00] <pitti> apw: it just seems that this should be depended on by some metapackage?
[08:07] <persia> pitti: Why should it be in main?  It's only useful for folks running qemu against armel targets, and isn't used for any images or in any flavours.
[08:08] <persia> And the armel board it supports fails to match any of the boards for which there are images.
[08:08] <pitti> persia: the source is in main, so that binary might just as well be
[08:08] <persia> There's a substantial list of packages where source is in main and binary is in universe.
[08:09] <pitti> persia: the entirely selfish concern is that it's about 20 times easier to NEW a package which has all binaries in the same component :)
[08:09] <pitti> and due to changing the ABI very often, NEWing happens frequently in stable updates
[08:09] <persia> Oh, then stick it in the "supported" seed (or whatever it's called).  You guys have to NEW linux *far* too often to fiddle about with it.
[08:09] <pitti> that was my idea, but I was interested in (1) why it doesn't have a metapackage, and (2) whether there are particular reasons why we don't even want to show it in main
[08:10] <persia> Because archive-admin-convenience is the only decent reason to have that kernel in main, but that's indeed a decent reason.
[08:10] <persia> It's useless for nearly everyone.
[08:10] <persia> It works fine, but it's not tested heavily or anything.
[08:10] <pitti> ok, so that explains the lack of an rdepends; thanks
[08:10] <persia> And I think mostly lool supports it/.
[08:11] <dholbach> good morning
[08:11] <pitti> persia: I'm a bit hesitant to seed it, though, again because the ABI changes so often
[08:11] <pitti> hey dholbach! *hug*
[08:11] <dholbach> hey pitti
[08:11]  * dholbach hugs pitti back
[08:11] <pitti> persia: (but there's a trick to catch all binaries of a source, so that's not a big problem)
[08:12] <persia> Use the trick.   A new linux-meta upload to create an rdepends would be annoying :)
[08:13] <dholbach> if an archive admin could have a look at bug 567208 I'd appreciate it
[08:13] <dholbach> it wouldn't surprise me if all the tools are currently broken in that package
[08:19] <pitti> apw, persia: seed change committed, thanks
[08:32] <apw> pitti, are you saying that the linux-headers for versatile are not depended on by a meta package?
[08:33] <pitti> apw: right; persia gave some clarification about that above
[08:34] <apw> pitti, i am a little supprised, i thought i was linked to linux-meta
[08:35] <apw> pitti, yeah there is a linux-headers-versatile <version> package built by linux-meta ?  would that not be the link we are expecting?
[08:35] <pitti> indeed
[08:36] <apw>  Depends: linux-headers-2.6.32-21-versatile
[08:36] <pitti> Depends: linux-headers-2.6.28-18-versatile
[08:36] <apw> and it does have a dep of the form i was expecting
[08:36] <pitti> oh, I see -- linux-headers-versatile itself is in universe
[08:37] <apw> so would the thing to be to promote that?
[08:37] <pitti> I don't know
[08:37] <apw> where is linux-image-versatile ?
[08:38]  * pitti looks a little confused and points archivewards?
[08:38] <apw> htm thats is universe too, i wonder why you don't have the same issue with the linux-image
[08:39] <slangasek> jdstrand: no, not everything in main is in a seed file; many things are in main as /dependencies/ of things in seeds
[08:39] <slangasek> jdstrand: but I see that was already answered :)
[08:39] <pitti> apw: no, linux-image-2.6.32-21-versatile is in main
[08:40] <pitti> indeed, but the metapackage is universe
[08:40] <slangasek> ArneGoetje: yay langpacks
[08:40] <apw> stranger and stranger
[08:40] <pitti> apw: so I guess for any kind of consistency we should either seed linux-{image,headers}-versatile, or drop the entire thing to universe?
[08:40] <pitti> and go back to this kernel-overrides script
[08:41] <pitti> persia: ^
[08:41] <apw> pitti, i have often wondered whether the package could supply the defaults ... so once you are happy they are right in the package you can just say 'do what the package says'
[08:42] <pitti> apw: they can: Section: restricted/linux
[08:42] <pitti> or universe, etc.
[08:43] <apw> so is that the error, that we are not and we should be
[08:43] <pitti> at least they could in the past; not sure if these days soyuz tries to be more clever
[08:43] <apw> if there is something i can do to make this work without lots of pain
[08:43] <apw> even if its just so that your script doesn't need a list, just can take the contents of those fields in the packages
[08:43] <pitti> apw: for now I'm primarily interested in where versatile should be; right now it's half-main/universe
[08:43]  * persia doesn't like the idea of components, but doesn't think there are enough versatile users to justify being in "main" as long as we have them, but prefers to make archive-admins lives easy, making main a reasonable choice.
[08:44] <pitti> apw: we have a "kernel-overrides" script which copies the sections from a previous ABI
[08:44] <pitti> so once we get it right in final, we can just use that for SRUs
[08:44] <apw> ahh right
[08:44] <pitti> persia: the thing that I'm puzzled about is why linux-image-2.6.32-21-versatile is in main without http://people.canonical.com/~ubuntu-archive/component-mismatches.txt complaining
[08:45] <pitti> (note that versatile just went away due to my explicit seeding)
[08:45]  * persia tries to find a reason
[08:45] <pitti> but that seeding is still inconsistent
[08:46] <pitti> we have linux-{image,headers}-2.6.32-21-versatile in main, and linux-{image,headers}-versatile metapacakges in universe now
[08:46] <pitti> ooh
[08:46] <pitti> ./platform.lucid/installer: * Kernel-Version: 2.6.31-607-imx51 2.6.32-204-dove 2.6.33-500-omap 2.6.31-800-st1-5 2.6.32-21-iop32x 2.6.32-21-ixp4xx 2.6.32-21-orion5x 2.6.32-21-versatile
[08:46] <pitti> persia: ^ got it
[08:46] <persia> Right.  netboot images.
[08:46] <apw> heh was just going suggest netboot
[08:47] <pitti> persia, apw: so with that I suggest to just seed the versatile metapackages, too; ok?
[08:47] <persia> So if that's going to happen anyway, may as well toss the linux-meta versatile stuff in supported to avoid archive-admin work.
[08:47] <apw> pitti, yeah seems reasonable they should be in the same place to me
[08:48] <persia> They may have a 2-digit userbase, but it's simply not worth the extra archive-admin work to have them in universe.
[08:48] <baptistemm> good morning ladies & gentlemen
[08:48] <pitti> persia: it's not that big of a deal, but kernel in main and metapackage in universe doesn't make sense
[08:49] <slangasek> ogra: what makes bug #568736 "higH"?
[08:50] <ogra> slangasek, waste of space and ram ?
[08:50] <persia> asac: Maybe you can help out slangasek there?
[08:50] <pitti> persia: hey, that's one digit more than hppa! *duck*
[08:50] <ogra> slangasek, along with the duplication of apps
[08:50] <slangasek> ogra: yeah, I'm not letting you make a seed change a week before release for that
[08:50] <ogra> slangasek, SRU ok ?
[08:51] <persia> pitti: Right: the only reason we care more about versatile than hppa is that there's like 4 devices anyone can buy that can actually run Ubuntu armel.
[08:51] <pitti> ScottK, Riddell: should kigo just drop the gnugo recommends at this point?
[08:51] <persia> ogra: SRU is pointless, because it doesn't change images.
[08:51] <ogra> persia, hmm, and u-m wouldnt uninstall the package anyway
[08:52] <persia> Right.
[08:52] <ogra> right
[08:52] <persia> So it ought be wontfixed for lucid and opened for maverick.  Unfortunately, the UI doesn't actually support that.
[09:13] <lool> pitti: linux-versatile > we could add it to supported-kernel
[09:14] <lool> pitti: Just like kexec, it's used in some use cases
[09:14] <lool> pitti: versatile being mostly for qemu
[09:14] <pitti> lool: ok, thanks; I seeded the metapackages now
[09:20] <lool> Keybuk, YokoZar, kees: When I uploaded my last qemu-kvm uploads, slangasek noticed the use of "start procps" in the maintainer scripts and requested that I use invoke-rc.d instead to be nicer to the chroot use case (policy-rc.d I assume); he referred to a discussion which had just taken place on #ubuntu-devel; I think we need to have a public discussion on the pros and cons of each approach in the short term, and how to address the concerns in ...
[09:20] <lool> ... upstart on the long term; there is a bug about chroots support in upstart covering the issues as well; let's move this to ubuntu-devel@
[09:39] <dholbach> asac: HAPPY BIRTHDAY! :)
[09:39] <slangasek> YokoZar: contrary to Keybuk's statements, start/stop do not provide a sane interface for use in maintainer scripts (and I believe he knows well what's not sane about this interface, he and I have talked about the problems before and he's said he plans to fix them).  It's fine that Keybuk wants to get rid of invoke-rc.d, but there needs to be a robust and publically-vetted interface, with sane error handling, available *first* before mand
[09:39] <slangasek> ... people *not* use the thing that actually works.
[09:40] <YokoZar> slangasek: All right then, I'll leave the invoke-rc.d using packages there ;)
[09:42] <asac> dholbach: \o/
[09:43] <sebner> asac: happy birthday from me too \o/ :D
[09:44] <asac> alll this public mentioning of a day ;)
[09:46] <RAOF> Happy birthday asac!
[09:46] <pitti> asac: happy birthday, man!
[09:46]  * pitti hugs asac
[09:46] <asac> man ;)
[09:46]  * asac hugs all
[09:46]  * sebner thinks about sending a mail to -ubuntu-devel about asac *hrhrhr*
[10:22]  * cjwatson scratches head over sbeattie's d-i resizing bug
[10:23] <cjwatson> AFAICT, tune2fs is just lying
[10:24] <sbeattie> lol
[10:25] <sbeattie> cjwatson: I still have that vm up if you want me to grab any more diagnostic info from it.
[10:26] <cjwatson> it's saying block count 2497791, block size 4096.  that's about 10GB - on a partition around 250MB long
[10:27] <cjwatson> sbeattie: currently trying to work out what I would need, and if I can reproduce it locally instead
[10:30] <sbeattie> cjwatson: well, tune2fs isn't lying; I just tried manually mounting the partition and the kernel wouldn't mount it, saying the same thing (the block count exceeds the size of the device)
[10:31] <cjwatson> oh!
[10:31] <cjwatson> so the fs there is bogus?  do you know why?
[10:31] <cjwatson> if it's genuinely bogus, I can certainly make d-i safe against that
[10:31] <cjwatson> I just didn't want to do so when the effect would be hiding some other problem
[10:32] <sbeattie> cjwatson: I don't know why it's bogus.
[10:32] <Riddell> pitti: hmm, if gnugo isn't installed kigo just complains that it needs to be installed
[10:33] <cjwatson> would you agree that it would be best to just guard against this, and otherwise write the underlying problem off as probably transient until reproduced?
[10:33] <cjwatson> or is the bogus fs reproducible by some sequence of installation steps?
[10:33] <pitti> Riddell: well, we need a MIR or a lowering of the dependency
[10:34] <pitti> Riddell: do you have kigo on the CDs? (gnugo is 1.7 MB)
[10:34] <Riddell> pitti: no it's not on the CD
[10:34] <Riddell> pitti: let me look into gnugo and see if it's an easy MIR
[10:35] <sbeattie> cjwatson: writing it off as a transient is fine by me; I don't recall how I got it into this state.
[10:40] <cjwatson> so then I'll just error out if the size reported by ntfsresize or tune2fs is outside [minsize, cursize] as per the partition constraints
[10:40] <cjwatson> which would result in that partition just not being resizable, which I think is the correct response here
[10:43] <sbeattie> cjwatson: that seems sensible. Thanks.
[10:57] <cjwatson> sbeattie: are you still awake enough to be able to do a test run with a candidate patch for me?
[10:58] <sbeattie> cjwatson: yes
[10:59] <cjwatson> sbeattie: so, there are two patches here; I need you to apply http://paste.ubuntu.com/420942/ to /lib/partman/lib/resize.sh, and http://paste.ubuntu.com/420943/ to /lib/partman/automatically_partition/10resize_use_free/choices
[10:59] <cjwatson> sbeattie: if you like, you can apt-get source partman-partitioning and partman-auto respectively, apply the patch there, and then scp in the result - that's probably quicker than typing it in by hand
[10:59] <cjwatson> sbeattie: I'd like you to keep the 'set -x' at the top of /lib/partman/lib/resize.sh to speed debugging of further problems, too
[11:00] <cjwatson> again, best to do all of this while it's sat at the hostname prompt
[11:03] <sbeattie> cjwatson:  sure thing, give me a few minutes.
[11:04] <cjwatson> sbeattie: np, thanks
[11:04]  * ogra wonders what we need to make a PAS change take effect ... apparently libx86 was added to PAS for armel but i still see it on http://qa.ubuntuwire.org/ftbfs/
[11:06] <persia> ogra: The only thing that clears that is a working build: it's based on the build records from LP.  A P-a-s change would make it not build for maverick.
[11:06] <ogra> ah
[11:06] <ogra> i guess an upload/sync/merge would clear it up too, right ?
[11:07] <ogra> well, i'll live with the uglyness on the list then
[11:07] <persia> ogra: An upload might.  I'm not sure.
[11:09] <persia> ogra: But I doubt the RMs would accept an upload just to make the FTBFS list look pretty :)
[11:09] <persia> (actually fixing a FTBFS is another thing)
[11:10] <ogra> you really think so ? :P
[11:10]  * ogra wasnt planning any upload indeed :)
[11:11] <ogra> i just wanted to know why i still see it on the list ... the explanation was good enough
[11:11] <ogra> it bites my eyes that we still have one red bar ... even though its moot
[11:12] <ogra> its just the german in me :)
[11:13] <persia> One?
[11:13] <persia> There's *lots* of red on that page.
[11:33] <slangasek> ArneGoetje: I find a certain irony that Hungarian users need the hunspell dictionaries symlinked into the myspell directory
[11:35] <sbeattie> cjwatson: okay, with those patches applied, I'm not getting offered the option to resize the partitions (which is probably correct). /var/log/syslog output at http://paste.ubuntu.com/420957/ and /var/log/partman at http://paste.ubuntu.com/420958/
[11:37] <sbeattie> cjwatson: note that I have a snapshot of the vm's disk state taken when I initially ran in to this, so I can do destructive things to the image like mke2fs /dev/sda5 (which doesn't appear to currently be a valid partition) if you'd like me to exercise different conditions.
[11:37] <sbeattie> s/partition/fs/
[11:40] <cjwatson> sbeattie: that's fine now - the shell trace is exactly as I'd expect
[11:40] <cjwatson> and I see it doesn't offer auto-resize because there isn't enough free space
[11:40] <cjwatson> /lib/partman/automatically_partition/10resize_use_free/choices: Found resizable partition '/var/lib/partman/devices/=dev=sda//5757730816-10462691327' (/dev/sda6), but not offering because only 2299432960 bytes free
[11:41] <cjwatson> sbeattie: so thanks, I think that's all!  I'll go ahead and upload that, with just a correction to the ntfsresize-case error messages
[11:43] <sbeattie> cjwatson: okay, cool.
[11:46] <apw> is there is standard way to access package dependancy information in a debian/rules context?
[11:46] <cjwatson> what sort of information?
[11:46] <apw> i have a package with a dependancy on linux-source but i would like to know which package linux-source points to
[11:47] <baptistemm> apt-cache rdepends
[11:47] <apw> or indeed the version number of linux-source
[11:47] <baptistemm> ah I misunderstood
[11:47] <apw> and i can use apt-cache in deban/rules
[11:47] <cjwatson> what are you trying to do with this information?  plug it into some other dependency?
[11:47] <apw> cjwatson, the build rules need to know the name of the directory whihc will be in existance as a result of installing linux-source
[11:47] <cjwatson> anyway, Depends is run-time, you can't generally validly analyse it at build time
[11:48] <apw> which depends on linux-source-2.6.NN and it needs the 2.6.NN information
[11:48] <cjwatson> sounds like it would need to depend on an explicit linux-source-2.6.NN anyway
[11:48] <cjwatson> because when linux-source changes to point to a new version, this package will need to be rebuilt
[11:49] <apw> i was hoping to avoid that, but you are indeed correct
[11:49] <cjwatson> the other way to do it would require the package detecting things at run-time, rather than in debian/rules
[11:49] <apw> yeah ... it would, and so this is a bust, thanks for the advice
[12:00] <slangasek> apw: any chance of us getting that kernel-lucid-kernel-config-review report to ubuntu-devel this week? :)
[12:00] <apw> slangasek, yeah thats on my todo for today (though i has been for two weeks)
[12:00] <slangasek> k
[12:01] <apw> slangasek, i am leaning towards putting all of the configurations on my people page
[12:01] <apw> and only including the i386 generic one
[12:01] <slangasek> hmm
[12:01] <apw> as to include them all there are about 8
[12:02] <slangasek> I dunno, seems to me that the "lvm support not built in on ports" bug is exactly the kind of thing that could have been caught by having more eyeballs directly on this stuff earlier
[12:02] <apw> slangasek, well some actual testing of any of the ports kernels before release would have caught that
[12:03] <persia> I did catch it a couple weeks ago.
[12:03] <persia> (admittedly not early enough, but)
[12:03] <slangasek> apw: only the users who were testing with LVM and knew to look for a kernel problem amid all the reports of mountall being broken
[12:05] <apw> slangasek, though do you really think that anyone would read the all the ports configs and 1) detect that BLK_DEV_DM was not =y, and 2) realise the significance of that
[12:05] <slangasek> apw: I would have looked over the differences in the configs, yes
[12:06] <apw> slangasek, hrm i had not considered it would be possible to do that kind of comparison
[12:06] <slangasek> would probably have taken a bit of work, but it was work I was intending to do :)
[12:07] <apw> the problem to my eye is that the arch configs are all different so there is masses of delta which is expected and a small nuggest which is
[12:07] <apw>   64543  101937 1440383 total
[12:07]  * slangasek nods
[12:08] <apw> for all the normal and all the ports configs (ie only for master branch) you are talking about 1.4MB of configs
[12:08] <apw> slangasek, would a delta from karmic make more sense?
[12:09] <slangasek> apw: well, if you post them to your people page, that's better than nothing (i.e., better than me trying to dig them out of the git repo) - at least if they're *somewhere* that I can look at them without hunting them down, I can give a good think to the problem of generating meaningful diffs
[12:09] <slangasek> a delta from karmic is probably also useful, but not to the exclusion of the other bit
[12:10] <apw> slangasek, ok i can cirtainly do that, i'l see if i can get the karmic ones up as well
[12:10] <apw> so there is a pair to compare that way too
[12:10] <slangasek> great, thanks
[12:10] <apw> and sorry its been on my list for too long really
[12:10] <apw> for M we'll put an earlier task to get it out
[12:10] <apw> if you could think about whats actually useful as a reviewer as well that would be great
[12:11] <slangasek> will do
[12:13] <apw> slangasek, one major thing we are doing now, is that when we have an option which has to be set is to record that and enforce it at build time so it is harder for it to become lost
[12:14]  * slangasek nods
[12:14] <apw> slangasek, it would probabally make sense to publish these somewhere which is not 'apw', i think i will put them in the kernel-ppa user, which can then persist forever
[12:14] <slangasek> ok
[12:19] <apw> slangasek, is there a release meeting today?  i don't see an agenda
[12:19] <slangasek> apw: will have it out within the hour
[12:20] <slangasek> (it was the agenda that reminded me of the outstanding WI ;)
[12:20] <apw> yeah i'll get it out today
[12:23] <ogra> sigh, whats up with wiki.u.c ?
[12:36] <slangasek> chrisccoulson: reviewing thunderbird - it's not clear to me why the thunderbird-gnome-support maint scripts have been removed without this moving elsewhere
[12:37] <chrisccoulson> slangasek - the maintainer scripts were just used to touch /usr/lib/thunderbird-3.0.4/.autoreg
[12:37] <chrisccoulson> which is not needed anymore
[12:37] <slangasek> chrisccoulson: what's .autoreg for?
[12:38] <pitti> free: the current landscape-client SRU mentions bug 522688  which is for libvirt, and 503384 and 542215 are private; also, since there are two uploads stacked on each other, can you please fix the changelog and reupload one with -v1.4.4-0ubuntu0.9.04 (jaunty), respectively -v1.4.4-0ubuntu0.9.10 (karmic) so  that the .changes will have both changelogs?
[12:38] <pitti> free: I'll sort out the task approval etc. now, and reject the two older uploads
[12:38] <pitti> free: oh, 567515 is private, too
[12:38] <free> pitti: yeah, we spotted a couple of bugs in the process
[12:39] <chrisccoulson_> wow, my laptop just crashed big time there
[12:39] <free> pitti: turned to public, thanks
[12:39] <chrisccoulson_> slangasek - i'm not sure how much of my response you got
[12:39] <slangasek> chrisccoulson_: "which is not needed anymore"
[12:40] <slangasek> then I asked what it was for
[12:40] <chrisccoulson_> because thunderbird-gnome-support doesn't actually ship any components any more
[12:40] <chrisccoulson_> the autoreg file is to tell thunderbird to re-register all the components on the system, so that it picks up newly installed/removed ones
[12:40] <slangasek> ok
[12:42] <pitti> free: so I guess the reference to #522688 is just wrong?
[12:42] <free> pitti: so you're suggesting to make a new upload, whose last changelog entry would be the merge for the last two changelog entries?
[12:42] <free> pitti: yeah, likely a typo
[12:42] <pitti> free: right, either merge the changelogs into one record, or use -v to include the last two changelogs into the .changes file
[12:43] <pitti> free: (the former would be even less confusing indeed)
[12:43] <pitti> plus fix that bug reference
[12:44] <pitti> free: I sorted out the tasks and nominations for all bugs now
[12:44] <free> pitti: thanks, if I use -v do I need a new revision or can I just re-upload? (actually zul will have to sponsor)
[12:44] <pitti> free: just reupload (i. e. no new version number) in both cases
[12:45] <free> pitti: fine, thanks
[12:45] <pitti> free: (well, with the bug ref typo fix, of course)
[12:45] <free> pitti: sure
[12:45] <pitti> free: thanks!
[12:47] <slangasek> chrisccoulson_: why is this added code in thunderbird.postinst needed?  The only package in the archive using this directory is thunderbird itself
[12:48] <chrisccoulson_> slangasek - dpkg doesn't replace the existing directory with the symlink on upgrade
[12:48] <slangasek> chrisccoulson_: the directory shouldn't exist on upgrade
[12:48] <chrisccoulson_> slangasek - the current lucid package has a directory there, and we want to replace it with a symlink
[12:49] <slangasek> chrisccoulson_: oh, yes - sorry, was misremembering the upgrade rules on this
[12:49] <chrisccoulson_> yeah, i'd forgotten about it too ;)
[12:50] <chrisccoulson_> we can actually drop that when we update to the next upstream version, as the install location changes anyway
[12:50] <slangasek> heh, ok
[12:50] <chrisccoulson_> it's only needed because we want to fix it with the current version
[12:53] <ArneGoetje> slangasek: well, it seems that certain applications look only in one directory and that's the myspell one.
[12:54] <ArneGoetje> slangasek: I'm planning to have a roundtable session about writing aids at UDS. I found it to be quite messy.
[12:57] <slangasek> chrisccoulson_: since a fix for bug #543064 wasn't in this upload, can I safely conclude that this should be deferred to -updates?
[12:58] <slangasek> ArneGoetje: are they using libhunspell when they look there, or something else? :)
[12:58] <apw> pitti, something odd occuring with the WI graphs today, http://people.canonical.com/~pitti/workitems/canonical-kernel-team.html, is showing some green and yellow bits just sticking out from behind
[12:58] <chrisccoulson_> slangasek - i don't think that's really needed now. the change just uploaded mitigates that by moving the gnome component to the main package
[12:58] <ArneGoetje> slangasek: not sure, need to investigate. Will do that when I feel better
[12:59] <chrisccoulson_> we can probably just defer that to next cycle
[13:00] <ArneGoetje> slangasek: but since the myspell and hunspell dictionary packages conflict on each other, it's definetely something we need to take a look at, IMHO.
[13:01] <pitti> apw: the bright yellow ones are WIs from persons which aren't member of kernel-team, but are assigned to WIs of kernel-team specs
[13:01] <pitti> but yes, the rendering looks broken
[13:01] <apw> something odd has happened cause the green seems to be on the top in some cases
[13:02] <seb128> slangasek, not sure what the discussion is but we should be using the hunspell dictionaries according to the debian maintainer but we didn't rebuild enchant for example with that dir in lucid
[13:03] <seb128> slangasek, debian did it already and we will follow next cycle I guess
[13:03] <slangasek> seb128: ah
[13:05] <dholbach> if an archive admin could have a look at bug 567208 I'd appreciate it
[13:05] <ArneGoetje> seb128: let's have a roundtable at UDS to figure out what problems still remain, shall we?
[13:07] <seb128> slangasek, ArneGoetje: we can discuss that at UDS if you want but the debian maintainer has been pretty clear the dictionnaries are in the hunspell dir now and that the other dirs are only there for compatibility reason but should be dropped, Debian apparently has migrated everything to use hunspell now, we didn't because you didn't sync some of the work they did yet
[13:08] <ArneGoetje> seb128: are all the applications using libhunspell?
[13:08] <seb128> not sure I didn't check
[13:09] <seb128> we can discuss it at UDS if you want but it seems rather a question of having somebody to do the work of checking what needs to still be changed
[13:09] <seb128> rather than a topic for discussion at uds
[13:11] <Riddell> pitti: bug 566520 if you're in a MIR mood
[13:11] <pitti> Riddell: thanks, will have a look soon
[13:12] <ArneGoetje> seb128: there are still other problems: e.g. oo.o seems to contain static language lists, so adding a language which is not in that list, is not trivial. And mozilla products also need some additional magic to use the hunspell dictionaries.
[13:12] <seb128> hum, k
[13:12] <seb128> your call if you think we will have people who know enough about this at UDS to have a discussion
[13:13] <ArneGoetje> seb128: I don't know if we will have... but I think it's surely a topic to raise.
[13:20] <persia> slangasek: Are the image builders going back to daily for a few days, or are they staying manual until release?
[13:20] <slangasek> persia: manual until release
[13:22] <persia> Would it be possible to do a kubuntu-netbook-armel+omap build?  It apparently needs a flash-installer fix that landed after the most recent build.
[13:22] <persia> ogra: Do you have the reference bug for that handy?
[13:22] <ogra> (flash-kernel )
[13:23]  * ogra doesnt rememebr if there was a bug open ... its the compcache issue 
[13:24] <ogra> persia, bug 568038
[13:44] <pitti> ttx: would you mind having a look at http://people.canonical.com/~ubuntu-archive/component-mismatches.txt, in particular the moin -> wsgi dependency? (the rest is just noise)
[13:44] <ttx> pitti: looking
[13:48] <Riddell> ev: what do you think about bug 568890 ?   I could have a go at fixing it but it's not easily tested since it would need a full install to test
[13:52] <ev> Riddell: it looks fairly straightforward, at least for adding the other device nodes to the list.  I'll give it a quick go.
[13:53]  * ttx grumbles about the moin branch not being up to date
[14:08] <ttx> pitti: python-moinmoin Recommends: libapache2-mod-wsgi | httpd-cgi. At that point I suggest we pick another httpd-cgi provider as the recommended one, and push wsgi to suggests. Would that work for you ?
[14:09] <pitti> ttx: yes, if libapache2-mod-wsgi isn't appropriate for main (in general|at this point)
[14:09] <pitti> ttx: but I don't know whether moin will work with just general apache
[14:10] <ttx> it should, since the recommends would also be satisfied in that case
[14:10] <ttx> plain CGI is alright, just slower
[14:10] <ttx> pitti: "Recommends: libapache2-mod-wsgi | httpd-cgi" is staisfied if you just have plain apache2
[14:11]  * ttx checks again
[14:16] <ttx> pitti: right, it's working well without that wsgi module, just by following instructions in README.debian
[14:17] <pitti> ttx: thanks for checking; mind uploading a fix? then I can review it quickly (four-eyes principle)
[14:17] <ttx> pitti: sure, I'm on it... in a few
[14:17] <pitti> merci
[14:17] <pitti> this is the last item on component-mismatches then
[14:17] <pitti> we're ready for prime time!!! :-)
[14:42] <bigon> is a bug that cause some partition to not be mounted on boot already known?
[15:01] <joaopinto> bigon, LVM ?
[15:19] <dholbach> ScottK: is syncing bug 567208 fine for you?
[15:19] <dholbach> ScottK: if you don't have time - should I ask somebody else?
[15:23] <joaopinto> shouldn't bug 558378 get some importance ?
[15:29] <ScottK> dholbach: I've been reviewing the sync requests that ubuntu-archive is subscribed to, so as long as the normal process is followed, I'll look at it.
[15:43] <ccheney> slangasek: thanks the conflicts somehow slipped my mind
[15:50] <doko_> pitti: sun-java6 6.20 already is in lucid/partner
[15:50] <pitti> doko_: yep, noticed my error, I set the bug to fixed again
[15:56] <bigon> joaopinto: yep
[15:57] <bigon> it ask if I want to skip mount or doing manual recovery
[16:02] <dholbach> ScottK: yeah, you reviewed it already, I just gave more info
[16:03] <ScottK> OK
[16:06] <joaopinto> bigon, check bug 561390
[16:11] <\sh> stgraber, ping https://blueprints.edge.launchpad.net/ubuntu/+spec/improve-netbooting-with-udhcp <- it seems nobody was interested during karmic...I would push that again for lucid+1
[16:12] <stgraber> \sh: we are using udhcpc in ltsp since karmic
[16:12] <stgraber> \sh: udhcpc was promoted to main for that, though it seems the spec wasn't updated accordingly
[16:13] <\sh> stgraber, did you test it with multiple nics (e.g. /etc/initramfs-tools/initramfs.conf: set DEVICE= and not to eth0)?
[16:13] <bigon> joaopinto: thx
[16:13] <stgraber> \sh: I don't have any thin client with multiple-NICs around
[16:14] <\sh> stgraber, hmm..so only ltsp benfits from that..it seems
[16:15] <\sh> plain initramfs-tools/scripts/function uses still ipconfig
[16:15] <stgraber> yep, the ltsp_nbd script is using but it wasn't changed in scripts/function as AFAIK that one comes from Debian so the change should probably happen there
[16:19] <Laibsch> ArneGoetje: If you have a minute, I'd appreciate some input on the changes to Japanese fonts.  I may be doing something wrong but the Takao font looks vastly inferior to the VL-PGothic.  Is that the same for you?  My understanding for making Takao the default is merely a question of size (1MB saving) or is there anything else?
[16:32] <pitti> ev: "(LP 536673)" -> please try to use the official syntax (LP: #536673) to auto-close bugs
[16:32] <ev> pitti: that was purposeful
[16:32] <ev> I don't want to close that just yet
[16:32] <pitti> ah, ok
[16:32] <ev> as I'm not entirely convinced that it fixes everything that's breaking there
[16:32] <ev> just most of it
[16:33] <pitti> understodd, thanks
[16:37] <\sh> micahg, why do we need xulrunner in chouchdb? it brings us a full fledged X and half of gnome
[16:37] <micahg> \sh: for the javscript engine
[16:38] <micahg> \sh: we'll look into a no-x version for Maverick possibly
[16:38] <\sh> micahg, do we need it really why not back to moz-js
[16:39]  * \sh is sorry about "I don't have the no-clue about that" ;)
[16:39] <micahg> \sh: mozjs is not guaranteed to be have a stable API even across minor releases
[16:39]  * micahg really can't type today
[16:39] <micahg> \sh: there are a few bugs already on the topic
[16:41] <\sh> micahg, yeah..it's really useless to have a server only setup but with a full bloated X setup because of a db server ;)
[16:41]  * pitti reads about ppa-purge -- what a gem! thanks Sarvatt
[16:45] <Nafai> very nice thing to have automated!
[16:45] <seb128> slangasek, pitti: can we sync http://packages.qa.debian.org/g/gtk-smooth-engine/news/20100411T104208Z.html ?
[16:46] <seb128> slangasek, pitti: the only change we have now was to fix some depreciation issues but new gtk added new issues so it's easier to take the debian way
[16:46] <micahg> \sh: the bug is bug 286906
[16:49] <pitti> seb128: seems okay, please go ahead
[16:50] <seb128> pitti, thanks
[16:52] <Sarvatt> no worries, it's pretty much required to use xorg-edgers since you need to downgrade at least 50 packages at some point to be able to upgrade a release since the packages in the PPA are newer than the next release's and the world will be broken just disabling the PPA :) I need to have a very large amount of packages in that PPA because all of the drivers require rebuilding every xserver release (and weekly just about during development)
[16:54] <ccheney> ArneGoetje: added comment to bug 568760 to you
[16:59] <ev> pitti: if you have any spare cycles, I would appreciate knowing any thoughts you how on what might be causing udisks --inhibit to time out in bug 567899
[16:59] <ev> have*
[17:01] <pitti> ev: I opened a tab for it; still in the release meeting, and I have to run after that, but I'll have a look later tonight or tomorrow in the train
[17:02] <ev> pitti: no rush, I'm going to keep chipping away at it
[17:02] <ev> thanks!
[17:02] <pitti> ev: this rather looks like an udisks-daemon crash, though
[17:02] <pitti> that's at least the usual cause of that message ("no reply")
[17:04] <ev> okay
[17:04] <pitti> might be worth asking him to check /var/log/apport.log and /var/crash/ ?
[17:04] <pitti> ev: can you reproduce it?
[17:05] <ev> pitti: unfortunately not
[17:05] <pitti> i. e. the effect can probably be reproduced with calling udisks --inhibit [...] and then sudo killall udisks-daemon
[17:06] <ev> given that apport is still enabled, surely there'd be something in /var/crash, right?
[17:06] <ev> noted
[17:06] <pitti> ev: it's disabled in the release, but I think casper enables it
[17:06] <pitti> ev: hm; sudo udisks --inhibit sleep 10, and then a killall udisks-daemon doesn't actually reproduce it
[17:07] <pitti> but there's no inherent timeout
[17:07] <pitti> ev: so it seems to have crashed right in the inhibit method, not when just waiting for the subprogram to terminate
[17:09] <ev> hmm
[17:10] <mvo> slangasek, Riddell: the support time for kubuntu is in the process of getting fixed, it needs a LP cherry pick that just got approved
[17:10] <ev> not exactly a complicated bit of code
[17:11] <pitti> ev: so, the inhibit stuff isn't really hw specific in udisks, so either it was a weird one-off error, or he hits a weird d-bus race condition on his machine
[17:11] <ev> it's two people
[17:11] <ev> I'm leaning towards the race
[17:12] <ev> especially as one of them has a quad core machine
[17:12] <ev> and this is happening at boot
[17:12] <pitti> ev: I'm afraid I don't currently have an obvious idea what could have gone wrong; if that guy can reproduce it, I suggest that he should try the sudo udisks --inhibit sleep 60 thing and see whether that works
[17:12] <Riddell> mvo: lovely thanks
[17:12] <ev> pitti: thanks for the help, I think you've got me on the right track now
[17:12] <pitti> ev: also, it's worth checking pidof udisks-daemon after that happens; if it's gone, it most probably crashed
[17:13] <ev> indeed, thanks
[17:14] <mvo> Riddell: you can review the status here http://archive.dogfood.launchpad.net/ubuntu-misc/more-extra.override.lucid.main.supported
[17:14] <mvo> Riddell: and use supported-desktop-extra in your seed to bump sutff more
[17:14] <mvo> Riddell: it will do 3y for kubuntu-desktop and dvd and dvd-live currently
[17:31] <LLStarks> hi. quick question. was audacious-plugins-extra dumped after karmic?
[17:31] <LLStarks> it's not in the lucid repos.
[17:32] <LLStarks> and that leaves timidity as the only way to listen to midi on ubuntu
[17:32] <ScottK> bdrung would be the expert on that.
[17:33] <LLStarks> thanks.
[17:33] <bdrung> LLStarks: audacious-plugins-extra was merged into audacious-plugins
[17:33] <LLStarks> oh okay.
[17:34] <LLStarks> the description should be updated then
[17:34] <bdrung> and one buggy module was disabled
[17:34] <bdrung> LLStarks: patches are welcome ;)
[17:39] <bryceh> slangasek, you had a question on the xserver upload?
[17:47] <seb128> slangasek, I sponsored a gnome-settings-daemon change from chrisccoulson now, the debdiff drops a change not listed in the changelog but that was a leftover not in series
[17:47] <seb128> not an actual code change or error there
[17:56] <blackxored> Hi guys, I was wondering, is grub2 on lucid compiled with LUKS support?
[18:00] <slangasek> bryceh: was just the question about the first change and whether it was intended to go to lucid; looked fine to me, it was more pitti's question
[18:01] <slangasek> seb128: ack
[18:01] <bryceh> slangasek, well I can redo the package to exclude it if it is causing concern
[18:01] <bryceh> one sec
[18:02] <seb128> bryceh, don't
[18:02] <bryceh> slangasek, ok xorg-server uploaded with that dropped
[18:02] <seb128> bryceh, it was pitti double checking not really a concern
[18:02] <bryceh> hrm
[18:02] <slangasek> bryceh: no, I prefer the one with this change :)
[18:03] <seb128> well both are in the queue now
[18:03] <seb128> so slangasek can do what he wants ;-)
[18:04] <bryceh> let me know which is taken so I can fix up git accordingly
[18:09] <psusi> oh wow, just found a link to this on the forums.. this sounds like a really retarded bug in blkid: http://sourceforge.net/apps/mediawiki/bootinfoscript/index.php?title=Boot_Problems:minix
[18:16] <blackxored> hi guys, anyone knows if grub2 for lucid is LUKS-enabled?
[18:18] <blackxored> anyone guys?
[18:20] <bryceh> slangasek, procedural question for SRUs
[18:21] <bryceh> slangasek, I've got a couple changes to do to xserver as SRUs
[18:21] <bryceh> slangasek, is it preferred to combine them in one upload, or to have individual uploads?
[18:22] <slangasek> bryceh: combine, please - and the first xorg-server is the one I accepted
[18:22] <bryceh> slangasek, if the latter, my concern is with the numbering
[18:22] <blackxored> ActionParsnip: I was wondering if grub2 for lucid has LUKS support compiled, and whether if I need to setup a proxy server or NAT if I have access by ssh to a machine which "seems" the outside world, and I don't
[18:22] <bryceh> slangasek, ok great
[18:22] <slangasek> bryceh: combining them is preferred, though if you think the SRU is going to get dragged down because one fix will be hard to get validated, then it's reasonable to split them
[18:24] <bryceh> slangasek, alright good to know
[18:25] <bryceh> slangasek, the ones I have in mind are pretty widely tested and the fixes are established upstream from us so I think they should be really straightforward srus
[18:25]  * slangasek nods
[18:26] <bryceh> but I do think they could benefit from the usual -proposed testing and are not emergencies for including in the release, so SRUing seems best
[18:26] <slangasek> right
[18:26] <bryceh> having them in one package definitely will make things easier
[18:46] <ccheney> debian.org domains (other than www.debian.org) seem mostly dead today, already report to #debian-devel
[18:46] <slangasek> oh, is that why I couldn't raise bugs.d.o earlier
[18:48] <Keybuk> KEYBOARD = YAY!
[18:48] <ccheney> slangasek: yea i can't get to packages.qa, incoming, bugs, debian.org without www, etc
[18:49] <ccheney> slangasek: "weasel is fixing them." so hopefully they will be back up soon
[18:51] <Keybuk> I like the "⌨ ⟹ ⚘" screen
[18:59] <slangasek> mathiaz: bug #529686> not before release
[19:02] <Keybuk> mathiaz: have you tried cheering the power button up instead of depressing it?
[19:14] <mathiaz> Keybuk: I haven't run into that bug
[19:15] <mathiaz> slangasek: It was assigned to me by random person
[19:16] <ScottK> Right, but it's Ubuntu custom that when you get bugs randomly assigned to you right before release you're morally obligated to fix them.
[19:23] <mathiaz> ScottK: hu?
[19:26] <Keybuk> tedg: random question; if I wanted to disable just the "messaging" indicator, is there a way I could do that?
[19:26] <tedg> Keybuk: Without just removing the package?
[19:26] <Keybuk> tedg: can I remove the package without losing most of ubuntu-desktop?
[19:27] <Keybuk> I like the other indicators - that one just takes up screen space and never shows anything
[19:27] <tedg> Keybuk: Yes.  It's very independent.
[19:27] <tedg> Keybuk: kenvandine wrote an xchat indicator plugin, if that works for you (don't know what you use)
[19:28] <Keybuk> I use xchat
[19:29] <Keybuk> though I have a custom notifications patch of my own that I should probably port to be an indicator
[19:29] <Keybuk> or merge with kevandines's
[19:29] <tedg> Keybuk: You've got until 11.04 ;)
[19:29] <tedg> (assuming you use the notification area)
[19:29] <Keybuk> yeah
[19:29] <Keybuk> basically it's just a hack
[19:30] <Keybuk> unlike the built-in one, it doesn't remove the icon as long as there are unread notifications
[19:30] <Keybuk> so if I miss an unread message in one channel, the icon stays
[19:30] <tedg> Ah, that seems like an important feature.  Surprised the original didn't do that.
[19:30] <Keybuk> so what will happen with e.g. empathy?
[19:30] <Keybuk> right now that uses a notification area icon, right?
[19:30] <tedg> Empathy?  It already has a patch to use the Messaging Menu.
[19:31] <Keybuk> then I'm confused
[19:31] <Keybuk> the messaging menu never changes
[19:31] <Keybuk> it just shows that envelope all the time
[19:31] <tedg> Yes, unless someone pings you, and then it turns green.
[19:31] <Keybuk> no?
[19:31] <Keybuk> when someone messages me on empathy, the little green bubble icon turns into a flashing ! icon
[19:32] <tedg> Hmm, that's odd.  I thought that was patched out as part of the Empathy patch.
[19:32] <tedg> Are you running the distro version?
[19:32] <Keybuk> yes afaik
[19:33] <Keybuk> right, just got ev to test both with a chat window open and with one closed
[19:33] <Keybuk> didn't go green
[19:33] <Keybuk> I must admit, I assumed the envelope was open because "I had new mail"
[19:33] <Keybuk> and that was hiding all other notifications
[19:34] <tedg> Yes, the icon is an issue.  But one that I claim no ownership on :)
[19:34] <Keybuk> ;-)
[19:34] <seb128> Keybuk, empathy has a preference option to use the indicator or not
[19:34]  * Keybuk always has new mail
[19:34] <tedg> In your Empathy preferences is there "Show incoming messages in the messaging menu" ?
[19:34] <Keybuk> tedg: yes, it's ticked
[19:34] <Keybuk> I did uncheck the bubble crap
[19:35] <tedg> Keybuk: Hmm, did you uninstall the messaging menu?
[19:35] <Keybuk> tedg: no
[19:35] <Keybuk> it's still there
[19:36] <tedg> And there's a indicator-messages-service running on your system?
[19:36] <Keybuk> scott     1504  0.0  0.1  17612  2544 ?        S    Apr22   0:00 /usr/lib/indicator-messages/indicator-messages-service
[19:36] <Keybuk> yup
[19:36] <seb128> Keybuk, what icon theme do you use?
[19:37] <Keybuk> seb128: no idea, the black one
[19:37] <seb128> you get empathy messages going in the menu if you don't have a conversation dialog open?
[19:37] <Keybuk> err, white icons, black windows
[19:37] <Keybuk> seb128: no
[19:39] <Keybuk> am going to reinstall in a few hours, so will see if this still happens
[19:39] <Keybuk> could be just an upgrade issue
[19:39] <tedg> Hmm, I thought that listen-and-print was in a package somewhere?
[19:39] <Keybuk> this laptop was installed with karmic RC and has been upgraded all the way through lucid
[19:40] <tedg> Doesn't seem like it.  Keybuk, if you grab lp:libindicate there's a little tool called "listen-and-print" that'll dump what libindicate is doing on dbus.
[19:41] <Keybuk> tedg: k, will do that after reinstall if still having issues
[20:09] <slangasek> Keybuk: regarding bug #561390 and /var/log/udev - I've been noticing that my own /var/log/udev doesn't show any entries for LVs that were initialized in the initramfs; is this expected?
[20:10] <Keybuk> slangasek: no, that should certainly not be the case
[20:10] <Keybuk> and implies some kind of issue
[20:10] <Keybuk> (indeed, that *may* be *the* issue here)
[20:15] <slangasek> Keybuk: all of my LVs are seen by mountall, device nodes are there, and everything is mounted - so I'm not sure how it's related to the bug people are reporting
[20:15] <Keybuk> weird then
[21:04] <Tm_Tester> ScottK: all seems to be ok, I'll go thru some logs to see if there's been anything
[21:05] <ScottK> Cool
[21:05] <Tm_Tester> some apps already tested in method "launch, do something, quit"
[21:14] <Tm_Tester> ScottK: all seem ok, though knetworkmanager fails to see my wlan
[21:14] <ScottK> OK.
[21:15] <ScottK> That probably merits some troubleshooting.
[21:15] <ScottK> Fortunately for me, I'm completely unqualified to help.
[21:15] <ScottK> maco is an expert though.
[21:15] <Tm_Tester> I'll try something
[21:15] <maco> what?
[21:15] <maco> lies!
[21:16] <maco> ScottK: im not a network manager expert...
[21:16] <Tm_T> (:
[21:16] <ScottK> No, but you taught me the underlying runes to get WPA working without it
[21:16] <maco> thatd be asac
[21:16] <maco> ahh
[21:16] <Tm_T> ... and I though I were in k-devel
[21:16] <ScottK> So you can probably help with seeing where in the stack the problem is
[21:16] <maco> gotcha
[21:17] <maco> Tm_T: was that you?
[21:18] <maco> possibly you just need to "sudo ifconfig wlan0 up"
[21:18] <Tm_T> maco: yes, was me
[21:18] <maco> i have to manually do that sometimes. not sure why.
[21:18] <Tm_T> maco: I was from livecd (:)
[21:18] <maco> ah
[21:18] <maco> you can sudo on a livecd :P
[21:19] <maco> woah CNN is talking about a dog going all Lassie and luring a cop to a burning house
[21:20] <ScottK> maco: It's not clear from the information you provided if that's a good dog or bad dog story.
[21:21] <maco> ScottK: good dog. the dog went to get help
[21:22] <ScottK> OK.  Luring people into burning buildings isn't inherently a good thing.
[21:22] <rafiyr> Um, what a note upon which to enter a room.
[21:23] <maco> ScottK: "to" not "into" :P
[21:23] <ScottK> OK
[21:23] <sebner> ScottK: depending on much you like those people :P
[21:23] <maco> rafiyr: i mentioned the news talking about a dog acting like the one in the show Lassie and luring a police officer to a burning house
[21:24] <maco> rafiyr: and ScottK asked if that was good or bad, and i said good because the dog went to get help
[21:26] <sistpoty> huhu sebner
[21:26]  * sebner hugs sistpoty :D
[21:27] <rafiyr> I see, so not the result of developers under stress just before a major release....
[21:27] <maco> heh no
[21:34] <Tm_T> ScottK: my bad, forgot that I need closed drivers/firmware/something
[21:34] <ScottK> Ah.  OK.
[21:37] <Tm_T> ScottK: but jockey fails with it, hrrr, I'll pastebin the log
[21:46] <Tm_T> ScottK: works eventually, so all good
[21:47] <ScottK> Tm_T: No Jockey problem?
[21:48] <Tm_T> ScottK: other than no clear error when it doesn't have network connection, no
[21:48] <ScottK> OK
[21:48] <Tm_T> had to replug wire to get connection up properly
[21:50] <ScottK> Might be worth a bug.  That doesn't sound idea.
[21:50] <ScottK> idea/ideal
[21:51] <Tm_T> ye, jockey just says "failed, see log" and log doesn't say "hey I don't have connection" either (:)
[22:25] <Keybus> tedg: so, err, the envelope icon changed after a reinstall
[22:26] <Keybus> it's a closed envelope now, not an open one
[22:26] <Keybus> but it's still white
[22:27] <tedg> Keybus: Changed from open to closed on getting a message?
[22:27] <Keybus> no, just closed now
[22:27] <Keybus> before it was always an open envelope
[22:27] <Keybus> does that mean anything?
[22:29] <tedg> Keybus: I don't think so.  Mine is open, but it seems it might have changed in the theme.
[22:30] <tedg> Keybus: It's toggled several times throughout Lucid.
[22:31] <Keybus> heh
[22:31] <Keybus> bit of luck we have UI freezes
[22:31] <Keybus> oh, wait
[22:32] <tedg> Yeah, I am an icon them version behind...  :-/
[22:32] <tedg> Keybus: You live closer to Millbank than I do.  I'll send you with the foam bat ;)
[22:32] <Keybus> whoah, empathy has a totally different theme now
[22:32] <Keybus> it looks like someone copied the iphone
[22:34] <Keybus> but yay, it does go green
[22:34] <tedg> Woot!
[22:34] <tedg> I think that OMG! Ubuntu described it as "puke green" but yes ;)
[22:34] <Keybus> I don't seem to have the extra empathy icon now either
[22:38] <Keybus> so whatever it was must have been an upgrade issue
[22:39] <tedg> Keybus: Cool, thanks for checking.
[22:40] <slangasek> Keybus: envelope> ubuntu-mono 0.0.18, I suppose
[22:40] <Keybus> oh, I thought that was something to do with Mono
[22:48] <ccheney> anyone happen to know the difference (or why) between dictionary files named eg de_DE vs de-DE ?
[22:48] <micahg> ccheney: files or symlinks?
[22:49] <ccheney> seems a lot of our upstream dictionaries aren't named uniformly and didn't know if it would cause a problem
[22:49] <ccheney> micahg: some might be symlinks, looking in Contents file right not to spot any other bugs before release
[22:49] <ccheney> s/not/now/
[22:50] <ccheney> micahg: enchant didn't get migrated for lucid so we need to make sure they are correct so they can be used
[22:50] <ccheney> some dictionaries have it both ways - _ but others only have it one way or other
[22:50] <micahg> ccheney: idk the whole story, but that's part of what I was discussing with you the other night
[22:51] <ccheney> micahg: yea
[22:54] <ccheney> micahg: i found the information, it should always be _ as - used to be needed for old mozilla but not anymore
[22:55] <micahg> ccheney: right, but what about other apps
[22:55] <ccheney> micahg: apparently other apps use _
[22:55] <ccheney> "For better mozilla integration, xx-XX.{dic,aff}->xx_XX.{dic,aff} symlinks were previously needed. Mozilla* now understands both variants, so this is no longer the case."
[22:56] <micahg> ccheney: so should it be cleaned up for Lucid or wait till Maverick?
[22:56] <ccheney> micahg: wait for maverick, but now i know that i need to make sure there are _ symlinks for all dictionaries in myspell/dicts
[22:56] <micahg> ccheney: kk
[22:56] <ccheney> so i don't have to worry about the -'s being missing
[22:57] <ccheney> it looks like they might not be missing actually just a bug with my sorting
[23:00]  * ccheney bbiab getting food, then back to more testing
[23:10] <psusi> Keybus, is there a mailing list for discussion of e2fslibs?  I wrote a patch today to ureadahead that changes preload_inode_group() so that instead of calling ext2fs_get_next_inode to synchronously read inodes until it gets one not from the desired group, to instead look into the opaque e2fslibs structures to find the block bitmap, inode bitmap, and inode table for the bg and readahead() those blocks on the raw block device, but I feel l
[23:10] <psusi> ike I should be using e2fslibs functions instead of looking into the opaque structures to do this
[23:11] <Keybus> psusi: the usual linux-ext4 mailing list
[23:12] <psusi> cool... I'll have to find that and sign up... want to find out if I can do what I did in a more proper way
[23:12] <psusi> but so far, looks like it does increase performance a bit
[23:12] <Keybus> linux-ext4@vger.linux.org  iirc
[23:12] <psusi> and is relatively simple
[23:12] <Keybus> it might be -ext2 :p
[23:16] <psusi> Keybus, if you care to take a look at it I made a bzr branch in lp:~psusi/ubuntu/lucid/ureadahead/mine... it turned out to be fairly simple... half a dozen lines or so
[23:16] <Keybus> psusi: mid-reinstall at the moment, can you e-mail me and I'll take a look in a bit
[23:17] <psusi> Keybus, just send a reminder, take a look at url:?
[23:18] <Keybus> ?
[23:18] <Keybus> well, include the URL and stuff :p
[23:18] <psusi> yuo just want me to send a mail saying reminder, check url://blah to scott@zelda.netsplit.com?
[23:18] <Keybus> yes
[23:19] <psusi> sure
[23:19] <Keybus> otherwise I won't remember
[23:24] <psusi> think I'll see about fixing defrag to change the height of the extent tree now when required/beneficial
[23:56] <kees> jdong: where is Debian's vlc 1.0.6-1 ?  I only see 1.0.5-2