[00:00] <kirkland> slangasek: i just plucked this crap out of the init script
[00:00] <slangasek> (we don't reverse that when stopping the job, so not sure why it should be here)
[00:00] <Keybuk> kirkland: it wasn't boot speed per se. more than it's easy to trip over upstart bugs
[00:00] <slangasek> kirkland: well the init script wasn't very good ;)
[00:01] <slangasek> gratuitous use of cat; 4 sed commands where 1 would do; and why are we preallocating /dev/loop nodes here?
[00:01] <kirkland> slangasek: will fix the sed
[00:01] <kirkland> slangasek: will ditch cat
[00:02] <slangasek> ah, but those are the minor things, it's the mknods that have me scratching my head :)
[00:02] <kirkland> slangasek: the loop devices are necessary for mounting storage for the instances
[00:02] <kirkland> slangasek: let me find the bug number with the background
[00:03] <slangasek> and "32" just happens to be the right number of loop devices to preallocate? :)
[00:03] <kirkland> bug #430846
[00:03]  * kirkland screams at launchpad
[00:05] <kirkland> slangasek: http://74.125.47.132/search?q=cache:rSm0ihZxdXQJ:https://launchpad.net/bugs/430846+430846&cd=4&hl=en&ct=clnk&gl=us
[00:05] <kirkland> google cache FTW
[00:05] <slangasek> heh
[00:05] <wgrant> kirkland: edge is working in read only mode, FWIW.
[00:06] <kirkland> wgrant: thanks
[00:06] <kirkland> slangasek: so there you go .... I asked the kernel team if we could increase the ubuntu default
[00:06] <kirkland> slangasek: they told me go make them myself
[00:06] <kirkland> slangasek: seems easy enough to do safely at boot
[00:07] <slangasek> kirkland: right - I guess I'm just a little wary of the preallocation of a fixed, magic number of loopback devices
[00:07] <slangasek> not a bug now, might be a bug later
[00:07] <slangasek> :)
[00:07] <kirkland> slangasek: and apparently this is something only eucalyptus needs, as the kernel team didn't want to increase it arbitrarily for everyone
[00:07] <Keybuk> we need to fix loop
[00:07] <Keybuk> so that it allocates on demand
[00:07] <Keybuk> every one created at boot costs boot time
[00:07] <Keybuk> it should be more like /dev/pts
[00:07] <kirkland> jebus
[00:08] <Keybuk> that's upstreamy though
[00:09] <kirkland> Keybuk: i do not disagree :-)
[00:10] <kirkland> slangasek: what does this mean:
         echo -n 1 > /proc/sys/net/ipv4/ip_forward
 not /etc/sysctl.d?
[00:10]  * Keybuk wonders why there's no /sys/module/loop/parameters/max_loop
[00:11] <slangasek> kirkland: we already have /etc/init/procps.conf, which will do sysctl tweaks for anything defined in /etc/sysctl.conf and /etc/sysctl.d; should eucalyptus-nc not just drop a conffile there?
[00:11] <Keybuk> slangasek: I think that kirkland hasn't realised that's a sysctl ;)
[00:11] <slangasek> I'm not saying one or the other is right, I'm just pointing out what I thought was the standard mechanism
[00:12] <Keybuk> kirkland: your echo is equivalent to putting "net.ipv4.ip_forward = 1" in /etc/sysctl.d
[00:12] <kirkland> Keybuk: cool, thanks, i can do that
[00:12] <Keybuk> yeah that's probably right
[00:12] <Keybuk> since then all the documentation applies
[00:13] <kirkland> slangasek: Keybuk: right well, as i said, this was a straight port of a crappy init script to a crappy upstart script;  we're just now trying to clean it up
[00:14] <kirkland> Keybuk: slangasek: what about /proc/sys/net/bridge/bridge-nf-call-iptables ?
[00:14] <kirkland> Keybuk: slangasek: is that sysctl-able too?
[00:14] <slangasek> yes
[00:14] <slangasek> anything under /proc/sys
[00:15] <kirkland> slangasek: okay, where do i find the docs to look up the var name?
[00:15] <slangasek> kirkland: it's straight s,/,./g on the filename
[00:15] <slangasek> er
[00:15] <slangasek> s,/,.,g
[00:15] <kirkland> net.bridge.bridge-nf-call-iptables = 1
[00:15] <kirkland> slangasek: ?
[00:15] <Keybuk> yup
[00:16]  * slangasek nods
[00:16] <kirkland> 30-eucalyptus-nc.conf
[00:16] <kirkland> that look about right?
[00:17] <slangasek> sure
[00:18] <kirkland> slangasek: is there a better way to get aoe modprobed?
[00:18] <slangasek> apparently not :)
[00:18] <kirkland> slangasek: the loops will need to stay for now, until there's a better way to do this
[00:19] <slangasek> yep
[00:19] <kirkland> kirkland@x200:/local/source/eucalyptus/lucid.public/ubuntu$ pastebinit debian/eucalyptus-nc.upstart
[00:19] <kirkland> http://paste.ubuntu.com/343123/
[00:19] <kirkland> kirkland@x200:/local/source/eucalyptus/lucid.public/ubuntu$ pastebinit debian/30-eucalyptus-nc.conf
[00:19] <kirkland> http://paste.ubuntu.com/343124/
[00:20] <slangasek> kirkland: looks sane to me
[00:20] <kirkland> slangasek: cheers, thanks
[00:20] <kirkland> Keybuk: i'll send you an email with a pointer to the bzr branch with all of the eucalyptus upstart scripts, for your leisurely review ;-)
[00:22] <Keybuk> sure
[05:44] <pitti> Good morning
[05:44] <StevenK> Morning pitti
[05:46] <Hobbsee> heya pitti!
[05:46] <pitti> Whoopie: just 481448> uload then
[05:47]  * slangasek waves to pitti
[05:48] <pitti> slangasek: daemon.log> hm, it seems full of debugging spew; but yes, we can certainly also downgrade the debugging level of apps
[05:48] <slangasek> debugging spew - really?
[05:48] <slangasek> ah, wpa_supplicant
[05:49] <slangasek> oh, wait
[05:49] <slangasek> pitti: daemon.log, or auth.log?  daemon.log doesn't appear to be synchronous by default
[05:49] <slangasek> auth.log is, and is the one I'm concerned about :)
[05:49] <pitti> slangasek: oh, and I was really talking about daemon.log
[05:49] <pitti> powertop regularly complains about stuff writing there
[05:50] <slangasek> powertop doesn't seem to distinguish between synchronous and asynchronous writes
[05:50] <pitti> ah, then I misunderstood your comment, sorry
[05:51] <slangasek> you probably didn't misunderstand, I was probably just confused :)
[05:51] <pitti> hey StevenK, morning Hobbsee!
[05:51] <slangasek> since AFAIK the only log we write synchronously by default is one that we /should/, I assumed that was the one your comment in the whiteboard was referring to
[05:52] <slangasek> without noticing that auth != daemon :)
[06:02] <slangasek> pitti: btw, if you're going near SRUs today, hold off for a few hours on the cryptsetup one; I've confirmed the report that 475936 isn't fully fixed in lucid, and am going to track that down today
[06:03] <pitti> slangasek: cryptsetup> ack
[06:06]  * dtchen wonders if there's a faster way to test-build for armel
[06:06] <dtchen> (I'm kinda surprised that upstream PA hasn't encountered these issues)
[07:18] <pitti> with the new LP rollout, do we have 3.0 source format now?
[07:19] <pitti> at least sync-source.py still fails
[07:19] <pitti> but that could be due to cocoplum having a too old dpkg
[07:19] <pitti> wgrant: ^ do you know?
[07:28] <ttx> slangasek: looks like we'll need to keep cglib2.1 for the moment.
[07:31] <pitti> james_w: thanks for your "distributed dev" summary!
[07:31] <pitti> james_w: how often are these branches imported? I just tried lp:debian/cdbs, and it's behind by more than 4 months (there were > 5 uploads afterwards)
[07:35] <pitti> james_w: another question, what would happen if I did "bzr push lp:ubuntu/pm-utils-powersave-policy --force-overwrite" so that I can get my native bzr over the auto-import? from what I remember, people can commit individual changes to an auto-import, and they won't get overwritten as long as they are consistent with the .dsc?
[07:43] <dholbach> good morning
[07:47] <persia> pitti: Do you know where I might find powerpc ddebs for lucid?
[07:49] <pitti> persia: funny you should ask; we have collected them for years and hardly used them, and I removed them last week because macaroni went out of space
[07:49] <persia> Heh.  And it was last weekend that I went looking :)
[07:49] <pitti> persia: if you need them for a recent build, they can still be retrieved from the buildds, though
[07:50] <pitti> persia: are you looking for a particular package?
[07:50] <persia> Is that something I can do on a per-build basis?  I rarely need them (my powerpc box mostly just works), but when I do, it's only one or two at a time.
[07:50] <pitti> the build log should tell you on which buildd it was done
[07:50] <pitti> persia: sure, just install pkg-create-dbgsym locally
[07:50] <persia> binutils 2.20-4ubuntu3
[07:50] <pitti> then it just happens
[07:51] <persia> I do that, but that's only for packages I build :)
[07:51] <pitti> persia: sorry, that was built a month ago already; they are gone, I'm afraid
[07:52] <wgrant> pitti: It's waiting on an upgraded dpkg on the various Soyuz machines. Once that's done, a LOSA needs to run some SQL magic to enable 3.0 uploads to Lucid.
[07:52] <persia> Ah, so they don't get stored in +archive :(
[07:52] <pitti> persia: not yet; however, wgrant was working on that
[07:52] <pitti> so, I hope it'll happen "soon"
[07:52] <persia> That would meet my use case.
[07:52] <wgrant> pitti: RT #36873, if you want to watch it.
[07:53] <persia> On a separate note, if you've removed all the binaries, please also remove the (now invalid) Packages and Release files.
[07:53] <wgrant> Most of the ddebs-in-soyuz work is done. I'm nearly there. But then there's the issue of librarian bloat.
[07:53] <persia> (it's confusing to have things work and then get 404s for difficult to understand reasons)
[07:54] <pitti> persia: well, there's still tons of powerpc ddebs
[07:54] <persia> Oh, so I just picked an unlucky package?  Oh well.
[07:54] <pitti> I just stopped collecting them
[07:54] <pitti> but yeah, I'll remove them for lucid
[07:55] <persia> wgrant: How much bloat are we talking about?  Is it something that could be contained by only tracking a subset of packages or something?
[07:55]  * persia is just unsure how to proceed with a segfault in ld
[07:57] <mneptok> pitti: "Macaroni Went Out Of Space" sounds like a Hunter S. Thompson book title, or an album by a 1960s psychedelic band.
[07:57] <pitti> you are so right
[07:57] <pitti> sometimes I don't even read what I wrote any more :)
[07:58] <wgrant> persia: pitti can you probably tell us approximately how much bloat we're talking about.
[07:58] <wgrant> But it's not an insignificant volume :(
[07:58] <pitti> right, they are huuuuuuuuuuuuge
[07:58] <pitti> I'd estimate some 300 GB on macaroni right now
[07:59] <persia> Ah, that is large.
[07:59] <pitti> expect some (elf portion of packages)%5
[07:59] <pitti> erm, *5
[07:59] <wgrant> Plus I suspect that you have a more aggressive binary removal policy than LP.
[07:59] <persia> I don't know about other people, but I tend to find that most classes of crashes can be replicated on an arbitrary architecture (excepting endian issues, word length issues, and silly assumptions about alignment).
[07:59] <pitti> yeah, I only keep the latest
[07:59] <pitti> it explodes otherwise
[08:00] <pitti> so please let's not keep all of them for ia64 :)
[08:00] <persia> So I wonder if it might be possible to get away with just the packages that are used as build dependencies for other packages (mostly libraries and toolchain)
[08:00] <wgrant> So it needs an Awful Lot of disk space on both cocoplum and mizuho.
[08:02] <persia> And I presume that me running to the shop and shipping disks isn't the solution, because there are chassis limitations, etc.
[08:05] <pitti> we could only keep supported arches, and only for current lts, current stable, and development release
[08:05] <pitti> plus ports for dev release perhaps
[08:06] <persia> That's a set that matches all my use cases :)
[08:06] <wgrant> Actually, thinking about it, we could safely enough purge ddebs early.
[08:06] <slangasek> ttx: wah; ok
[08:07] <ttx> slangasek: proxool needs asm2, cglib (2.2) needs asm3, cglib2.1 needs asm2
[08:08] <ttx> slangasek: and asm2 and asm3 don't live well together in the same classpath
[08:08] <ttx> so I'd say that debian adding "Provides: libcglib2.1-java" to libcglib-java is somewhat optimistic
[08:09] <slangasek> pitti: cdbs import failure info: http://package-import.ubuntu.com/failures/.bzr/failures/cdbs
[08:09] <ttx> (and eucalyptus needs proxool and cglib)
[08:10] <pitti> slangasek: ah, thanks
[08:10] <pitti> slangasek: btw, do you have sata disks? my laptop doesn't even have sata power link management
[08:10] <pitti> slangasek: I'm changing the heuristics to be a little more clever, not just looking at total RAM, but at active RAM, too
[08:11] <pitti> I'm just curious how it feels like when enabling it
[08:11] <slangasek> pitti: yes, I have sata, with the intel chipset needed to use this
[08:11] <slangasek> I have 3GB RAM today, which is enough that SLPM doesn't hurt me
[08:11] <slangasek> (SLPM? SPLM?)
[08:12] <slangasek> when I had 1GB of RAM, it was bad :)
[08:12] <pitti> I now use "min_power" if inactive/total > 15%, and medium_power if inactive/total > 5%
[08:12] <pitti> and if it's even less, I don't touch it
[08:12] <pitti> since it seems dangerously close to swapping
[08:12] <pitti> I'm not entirely sure if this is a better heuristics, I'll send out a call for testing
[08:13] <slangasek> I think it would be fine to just check the amount of RAM; after all, mem usage will change over time, much more rapidly than the pm-utils hook will be triggered
[08:14] <pitti> so perhaps just bump it to 2 GB?
[08:14] <pitti> GiB
[08:14]  * pitti tries to teach himself to use correct units, in light of the month-long units policy TB topic
[08:14]  * slangasek grins
[08:14] <slangasek> fine with me; maybe it should be varied by architecture, also?
[08:15] <slangasek> 1GB might be enough on 32-bit, isn't enough on 64-bit
[08:15] <pitti> does it make such a difference actually?
[08:15] <pitti> I had expected most things to just use ints
[08:15] <pitti> pointers do, of course
[08:16] <slangasek> everything python approximately doubles in size
[08:16] <pitti> how much RAM do netbooks have these days? They are prone to have i386
[08:16] <persia> They vary from 512MB to 3GB
[08:17] <persia> (at least that's what I saw last time I looked in a shop about 3 weeks ago)
[08:17] <pitti> so, let's say 1 GiB on i386, and 2 on AMD64?
[08:17] <slangasek> sounds reasonable to me
[08:23] <pitti> james_w: btw, do you ignore language-pack-* for auto-imports? it'd be a waste, and people really shouldn't change the packages directly anyway
[08:28] <slangasek> tseliot: hmm, did you change anything that should have fixed the input-dropping bug in plymouth?  I don't see any recent upgrades on anything except initramfs-tools, but my passphrase entering is now reliable
[08:29] <tseliot> slangasek: no, but that happened to me too once and I don't know what made it more reliable
[08:32] <slangasek> tseliot: should I close my bug, or leave it open?
[08:32] <tseliot> slangasek: please leave it open, I think it's something we should investigate
[08:32] <slangasek> ok
[08:36] <slangasek> pitti: cryptsetup checks out, the problem I'm seeing is mountall+fstab interaction and not a bug in the cryptsetup fix itself
[08:37] <pitti> nice, so good to go to -proposed then?
[08:37] <slangasek> pitti: IMHO yes; I'll update the test case based on my latest findings
[08:50] <slangasek> pitti: test case updated
[09:11] <pitti> ogra_: did you ever happen to test lucid alpha-1 on your touchscreen? was there a major regression due to the udevification?
[09:11] <pitti> (of x.org)
[09:27] <ogra_> pitti, i'm currently not running lucid on my laptop, will tell you once i do
[09:27] <pitti> ogra_: thanks
[10:09] <james_w> pitti: they are imported continuously, but there was a bug meaning Debian was missed, so some of them are out of date. An LP bug is hampering my effort to get all of Debian up to date.
[10:10] <james_w> pitti: you could push --overwrite pm-utils-powersave-policy. I would have some fallout to deal with, but that's not a problem.
[10:10] <james_w> and I do not currently ignore language-pack-*
[10:11] <pitti> james_w: so is the --overwrite considered a hack or a semiofficial method to move the real-world bzr branches to their preferred naming scheme?
[10:11] <james_w> both :-)
[10:11] <pitti> james_w: if it's sanctioned, I'd like to do it for apport, jockey, pm-utils-powersave-policy (since those have full source)
[10:11] <james_w> it works fine
[10:11]  * slangasek grins
[10:11] <james_w> I can do it by changing the links, which is perhaps a little more elegant
[10:11] <pitti> I keep getting bad merge requests for apport, and just pushing the real branch to lp:ubuntu/apport would help a lot
[10:11] <james_w> there's a bug I need to fix before I do that though
[10:12] <slangasek> if the package also exists in debian, though, that will lose us some of the history I guess?
[10:12] <pitti> for those three that's not the case
[10:12] <james_w> yeah
[10:12] <pitti> I guess for the merge case it might be better to just throw away our old branch, merge with Debian, and push the merge to the auto-import branch?
[10:12] <james_w> I have to make it re-import taking in to account what is already there, after adding some tags
[10:13] <james_w> I would prefer to do it all properly, but I understand that it must be frustrating waiting for me
[10:14] <pitti> james_w: if it's causing you extra work, I'll leave it as it is for nwo
[10:14] <EsatYuce> i m member one of the Launchpad team which name is https://launchpad.net/~ubuntu-l10n-tr, i want to release translated's package. How?
[10:14] <james_w> by doing a push --overwrite you force the issue
[10:14] <pitti> james_w: I was just wondering because you said that we can actually commit individual changes to those branches, upload, and the importer would see that it's already there and not clobber it
[10:15] <james_w> pitti: you theorised correctly
[10:15] <james_w> there are just a couple of implications for the backend
[10:15] <james_w> the code hasn't quite caught up with reality yet
[10:21] <EsatYuce> is this right channel to ask about Launchpad??
[10:21] <slangasek> EsatYuce: #launchpad is probably a better channel for questions about Launchpad
[11:12] <dpm> EsatYuce, I'd recommend you to ask at #ubuntu-translators, but in general, you might have to get in touch with the developers of the package you have translated
[11:23] <pitti> tjaalton, tseliot, bryce: FYI, I documented the udev X.org bits on https://wiki.ubuntu.com/X/InputConfiguration
[11:23] <mdz> anyone else see this in current lucid?
[11:23] <mdz> rm: cannot remove `/tmp/mkinitramfs_cLvNRp/lib/modules/2.6.32-8-generic/modules.*map': No such file or directory
[11:23] <tseliot> pitti: it looks good, thanks for working on this
[11:25] <pitti> tjaalton, tseliot, bryce: (I also linked it from /X)
[11:25] <tseliot> pitti: ah, for quick access from X, nice. Thanks again
[11:27] <persia> pitti: You report that joysticks have ID_INPUT_KEY : is this for joysticks that actually include a keyboard map, or ones that just provide buttons as well?
[11:27] <tjaalton> pitti: thanks. it's possible that device configuration will not be allowed from the backend, but moved back to the ddx
[11:27] <tjaalton> pitti: even for lucid
[11:27] <tjaalton> patches upstream
[11:27] <pitti> persia: hm, let me check
[11:28] <pitti> persia: right, current input_id indeed does't assign _KEYS, fixing
[11:28] <pitti> tjaalton: would that mean that it stops using udev altogether then?
[11:29] <persia> pitti: Well, that was an accident on my part :)  is there another resource I should look at that for deeper grounding (or would that be source)?
[11:29] <jelmer> subunit
[11:30] <tjaalton> pitti: no, it just wouldn't be possible to pass x11_options from it. the xorg.conf format will become far more flexible to handle this
[11:30] <pitti> persia: well, I wrote input_id, so if you have a good reason why ID_INPUT_JOYSTICK (and the like) should also have _KEYS=1, I'm happy to add it
[11:30] <tjaalton> pitti: and also support for xorg.conf.d
[11:30] <slangasek> mdz: yes, Keybuk said he was going to fix that today
[11:30] <pitti> tjaalton: ah, I see; well, the doc can always be updated then
[11:30] <tjaalton> pitti: which packages can use to ship conf snippets
[11:30] <mdz> slangasek, ok, thanks (and what on earth are you doing awake?)
[11:30] <tjaalton> pitti: of course
[11:30] <slangasek> mdz: I work odd hours on Thursday in order to stay in touch with Europe :)
[11:30] <mdz> ah
[11:31] <persia> pitti: For the general case, they shouldn't.  Oddities like the Saitek Cyborg Command Unit probably should.
[11:31] <persia> (where the joystick is just asking to be remapped to send keyboard events)
[11:33] <pitti> persia: if the device event mask claims that it can produce EV_KEY, input_id will report that
[11:33] <persia> Ah, that makes sense.  OK.
[11:33]  * persia will go read the input_id source this weekend to actually understand
[11:34] <pitti> it by and large just tests the bitmasks in /sys/class/input/*/capabilities/{ev,abs,rel,key}
[11:34] <pitti> using the flags in /usr/include/linux/input.h
[11:34] <tjaalton> pitti: there are bugs where evdev grabs joysticks, and that makes the cursor jump to the middle of the screen when the joystick is touched
[11:34] <pitti> but this bit mask testing is horrible/impossible in pure udev rules, which is why we need the callout
[11:35] <pitti> tjaalton: right, I have that when I attach my joystick
[11:35] <persia> tjaalton: actually, that depends on the joystick: not all of them are either absolute or autocentering.
[11:35] <tjaalton> pitti: it also happens for hw accelerometers, so tap your laptop.. :)
[11:35] <tjaalton> persia: ah, ok
[11:36] <pitti> tjaalton: I was never quite sure whether plugging in a joystick is supposed to behave like a mouse, or whether that was an unintended side effect
[11:36] <tjaalton> pitti: I'd say not. there's a -joystick driver for that
[11:36] <pitti> we can of course easily ignore joysticks as X input devices
[11:36] <persia> There are definitely two schools of thought by users.
[11:36] <tjaalton> yes, but the last time this happened with hal, there were a bunch of users upset :)
[11:36] <tseliot> james_w: can you join #ubuntu-x, please?
[11:37] <pitti> tjaalton: ... which we don't install by default?
[11:37] <persia> I think there should be an (optional) way to enable/disable that easily.  Used to be xf86-input-joystick
[11:37] <tjaalton> pitti: right
[11:37] <pitti> tjaalton: so xserver-xorg-input-joystick should ship an udev rule which sets ENV{ID_INPUT_JOYSTICK}==1, ENV{x11_driver}="joystick"
[11:37] <tjaalton> pitti: that's already in git, just not released yet
[11:37] <pitti> ah, sweet
[11:38] <persia> A related question: with HAL it was possible to remap stuff, so for instance one could enable a fake mouse somewhere on one of the monster 15-axis 40-button joysticks and still use the joystick in games.
[11:39] <persia> Is there a way to do that without HAL?  Should descriptor files be shipped somewhere?
[11:39] <persia> (e.g. in the x52pro package)
[11:40] <persia> Or does that now require custom input drivers?
[11:40] <tjaalton> hal was just the backend
[11:41] <pitti> persia: hal itself didn't really add new devices (and wasn't able to)
[11:41] <tjaalton> if it was possible with x11_options, it'll still be possible
[11:41] <pitti> persia: you should be able to set configuration in udev just as well as in hal
[11:41] <persia> OK, so that's just constructing the right ENV(x11_options.foo) entries?
[11:44] <persia> e.g. ENV(x11_options.event_key_remap)="464=118" and the like?
[11:45] <pitti> persia: if that worked in hal, it'll work with udev rules
[11:45] <pitti> it's just the messenger
[11:45] <pitti> persia: above wiki page has a migration guide
[11:45] <persia> Cool.  Thanks.
[11:45]  * persia was reading that, but hadn't looked at input stuff much since intrepid or so, and was catching up slowly
[12:58] <LucidFox> seb128, regarding xchat-gnome - my patch for the git version is in the upstream bug report.
[12:59] <seb128> LucidFox, the current patch still change .glade files there
[13:00] <seb128> LucidFox, they named the files .glade rather than .ui?
[13:00] <seb128> seems buggy...
[13:01] <LucidFox> Yes - the git version uses these .glade files.
[13:01] <seb128> ok, I will check that later
[13:02] <seb128> that seems wrong
[13:02] <seb128> gtkbuilder files are named .ui usually
[13:03] <LucidFox> Actually... the git version seems to still use libglade. o_O
[13:04] <seb128> weird, http://git.gnome.org/cgit/xchat-gnome/commit/?id=8ba28cb15d6bb365891a495130aed49145a7a2b5
[13:04] <LucidFox> Only the preferences dialog is converted to GtkBuilder.
[13:04] <seb128> I think they rather didn't rename their .glade to .ui
[13:04] <LucidFox> The rest still use libglade
[13:04] <seb128> oh ok
[13:05] <LucidFox> yet even for the preferences dialog. they didn't rename .glade to .ui.
[13:35] <lool> persia: Latest binary package built wins
[13:36] <lool> Last one to build that is
[13:36] <persia> Nope.
[13:36] <persia> Highest version wins.
[13:36] <persia> (for those seeking context, see #launchpad)
[13:39] <qense> In the upstream conversation about bug 487937 it became clear that Nautilus already has PackageKit integration for unknown file formats, Fedora 11 advertised it in its release notes. Now I'm not sure how Nautilus' PackageKit support in Ubuntu is. It's disabled, isn't it?
[13:46] <seb128> qense, we don't use packagekit but have a nautilus patch using gnome-app-install for installing things too...
[13:47] <seb128> qense, the issue is not a nautilus one though
[13:47] <qense> it is a share-mime-info issue?
[13:47] <seb128> it's likely that file-roller claims handling those in its desktop entry
[13:47] <seb128> well I would guess that file-roller is used
[13:47] <seb128> but it fails
[13:48] <qense> the error message just says no suitable application can be found
[13:48] <seb128> there is a bug on file-roller asking for smart install already though
[13:48] <qense> really? I couldn't find any
[13:48] <seb128> qense, bug #148084
[13:49] <qense> ah, I see
[13:49] <qense> but that's for inside file-roller
[13:49] <seb128> qense, but if file-roller is not open it might be because the mimetype is not listed
[13:49] <seb128> what mimetype are those which give you the error using?
[13:50] <qense> I can confirm it with CAB, which is in packages/freedesktop.xml -- a file of shared-mime-info, the only .xml one -- the reporter talked about lzma and 7zip.
[13:53] <seb128> qense, cab = application/vnd.ms-cab-compressed?
[13:53] <seb128> qense, no .desktop lists those in their .desktop in /usr/share/applications
[13:54] <seb128> nautilus can't guess from nowhere what application could be able to open those
[13:54] <seb128> the .desktop need to list the mimetype for that to work
[13:54] <qense> ah
[13:54] <seb128> lzma and 7z should work
[13:54] <qense> ah
[13:54] <qense> a lot of ahs here ;)
[13:54] <seb128> since those are listed in the file-roller .desktop list
[13:55] <qense> I see CAB isn'tin .desktop indeed
[13:55] <seb128> I'm not sure file-roller handle those
[13:55] <seb128> I'm not sure we have any gui to handle those
[13:55] <seb128> it's a somewhat specific format
[13:55] <qense> yes
[13:56] <qense> must have been my memory playing a trick on me, confusing a terminal command with a GUI action
[13:56]  * persia comments that it's possible for plugin packages to add special mime-handler-only .desktop files that end up calling into the executable into which they plug if that helps with non-default formats
[13:56] <seb128> it's listing application/x-cabinet though
[13:57] <qense> that's strange
[13:57] <seb128> could be a .desktop bug
[13:57] <qense> or an inconsistency from MS
[13:57] <seb128> in any case it's not a nautilus issue
[13:57] <qense> indeed
[13:57] <seb128> it just matches mimetype and .desktop lists
[13:59] <qense> I'll check if application/vnd.ms-cab-compressed can be processed the same as application/x-cabinet and mark the LP bug as a dup of the bug you named. The upstream report could be turned into a bug about the .cab archive handling.
[13:59] <qense> Thanks for your help, seb128! (and for your suggestion, persia)
[14:01] <Mez> Hmm, it seems my automount stuff has stopped working in karmic.
[14:01] <Mez> Is this a known issue?
[14:01] <seb128> Mez, no
[14:01] <seb128> qense, you're welcome
[14:02] <Mez> seb128: any idea of how to "debug"
[14:02] <seb128> use ubuntu-bug storage
[14:03] <seb128> it will get gvfs, devicekit-disks etc logs
[14:03] <Mez> "Package storage does not exist"
[14:04] <seb128> install apport-symptoms
[14:05]  * Mez waits for upgrade to finish
[14:05] <Mez> hmm... new apport version ?
[14:12] <Mez> seb128: #369067
[14:12] <seb128> bug #369067
[14:12] <seb128> Mez, doesn't seem right
[14:12] <Mez> bug #36906749
[14:13] <Mez> ah, crud
[14:13] <Mez> bug #497771
[14:14] <Mez> hmm, looks - sane enough to me.
[14:15] <seb128> I think it's a dup
[14:15] <seb128> the device has no type
[14:19] <Mez> seb128: a reboot seems to have fixed this.
[14:19] <seb128> weird
[14:20] <seb128> is that karmic uptodate?
[14:20] <Mez> maybe some process got killed off at a point i hit high memory or something
[14:20] <seb128> there was a fd leak in udev earlier in the cycle
[14:20] <Mez> yeah, up to date.
[14:20] <seb128> but that got fixed in a stable update
[14:20] <Mez> oh, when?
[14:20] <seb128> that's fixed for a least one month
[14:20] <Mez> oh, it's been updated at the end of last week at least
[14:20] <seb128> some similar bugs are due to devicekit processes crashing too
[14:21] <seb128> so it might be one of those
[14:21] <seb128> could you comment on the bug saying that a reboot fixed it?
[14:21] <Mez> already in the process of doing so
[14:21] <seb128> thank you
[14:22] <Mez> worth marking as invalid too?
[14:22] <seb128> you can yes or you can wait for pitti to triage it
[14:22] <seb128> I expect he will need some extra log though
[14:22] <seb128> so if you can't get the issue now...
[14:22] <Mez> well, it's working now, so I won't really be able to reproduce
[14:22] <seb128> close it and reopen if you get it again
[14:23]  * Mez has no access to
[14:23] <seb128> and maybe check your system logs for asserts or crashes
[14:23] <Mez> wait, wtf
[14:23] <Mez> I'm part of bug control
[14:23] <seb128> you should be able to close your own bug in any case
[14:23] <Mez> yeah, missed the "double login" stuff :)
[14:24] <Mez> damn edge :D
[15:17] <Mez> afternoon sabdfl
[15:17] <sivang> sabdfl is here ? :)
[15:17] <Mez> his IRC nick is :)
[15:18] <sabdfl> hello all
[15:20] <ion> Howdy
[15:51] <hwilde> anybody know what is holding up libjsw for 9.10?
[15:57] <persia> hwilde: How do you mean "holding up".
[15:58] <slangasek> it's turtles all the way down
[15:58] <hwilde> persia, everything else seems to work but no joystick support so what are we waiting for
[15:59] <persia> hwilde: Ah.  Well, since about 7.10 joystick support was *less good* with libjsw installed.
[15:59] <hwilde> but we need jscalibrator
[15:59] <persia> Um no.
[15:59] <persia> That just broke stuff.
[15:59] <ebroder> Hey persia - could you add me to u-u-s?
[15:59] <hwilde> persia, jscalibrator is the only way the logitech rumble pad works
[16:00] <hwilde> (the playstation looking controller)
[16:00] <persia> hwilde: Anyway, join me in #ubuntu, and I'll talk to you about joysticks :)
[16:00] <ion> It’s teenage mutant ninja turtles all the way down.
[16:18] <pitti> seb128, Mez: I'll have a look
[16:24] <jelmer_> beuno, ping
[16:34] <kirkland> pitti: hmm, looks like something just regressed in the burndown-chart scripts
[16:34] <kirkland> pitti: i had some items marked as DONE, that were picked as DONE by your scripts, but now, they're back in the TODO range
[16:35] <pitti> hmm
[16:35] <pitti> kirkland: do you have bugs linked to blueprints?
[16:35] <pitti> kirkland: today we landed a feature to use bugs as work items
[16:36] <pitti> which are now counted as todo (open) or done (fix released)
[16:36] <kirkland> pitti: ah, yeah, i have a few in "fix committed"
[16:36] <kirkland> pitti: okay, thanks, that's it
[16:36] <pitti> kirkland: would that be a plausible cause?
[16:36] <kirkland> pitti: i think so
[16:36] <pitti> kirkland: so you should probably just remove the WIs from the whiteboard which duplicate the bugs
[16:36] <kirkland> pitti: cool, i like the feature
[16:37] <kirkland> pitti: i'd like each work item to be a bug, actually ;-)
[16:37] <pitti> kirkland: https://wiki.ubuntu.com/WorkItemsHowto#Work%20items%20as%20linked%20bugs
[16:37] <pitti> kirkland: well, for some it's great (e. g. "MIR for foo"), for some not so ("test X", "write documentation")
[16:38] <kirkland> pitti: meh :-)
[16:38] <pitti> kirkland: but the whiteboard stuff won't go away, so it's just another option now
[16:38] <kirkland> pitti: i like that bugs have priorities, state, owners, history, etc.
[16:38] <kirkland> pitti: cool, thanks
[16:44] <kees> pitti: so, if we have a workitem that reads  "support backingstore (LP: #470636)"  this is now counted twice?
[16:44] <pitti> kees: if you linked that bug to the BP, yes
[16:45] <pitti> this seems to confuse enough people that this warrants an announcement
[16:45]  * pitti mails platform
[16:45] <kees> how are bugs linked to bps?  :P
[16:45] <kees> becuase our todo chart jumped a lot more than just 1 item.
[16:46] <smoser> Keybuk, do you a minute for a mountall question?
[16:46] <Keybuk> smoser: sure
[16:46] <smoser> on ec2, the root= is going to say 'root=/dev/sda1'
[16:46] <kees> pitti: or at least those bugs should be explicitly listed in the "Status by work item" section
[16:47] <Keybuk> ok
[16:47] <smoser> i'd like to label the filesystem and use "LABEL=" in /etc/fstab
[16:47] <pitti> mailed
[16:47] <Keybuk> smoser: do you have an initramfs?
[16:47] <joaopinto> dtchen, without apparent reasons my sound got muted, I stated getting flood with the volume muted notificatoin and PA was using 100% of one of the cores, is there a PA specific log I can check ?
[16:47] <pitti> kees: they should, in the database it's all the same
[16:47] <Keybuk> (I would assume not, it doesn't make much sense)
[16:47] <smoser> i do not
[16:47] <Keybuk> right, then you're basically limited ;)
[16:47] <smoser> well, wait
[16:48] <Keybuk> you can put whatever you like in fstab
[16:48] <Keybuk> but it doesn't make any difference - since the kernel is what mounts the root <g>
[16:48] <kees> pitti: how are they distinguished between "from a white board" and "from a bug" ?
[16:48] <smoser> i do when running in UEC, but not when running in ec2
[16:48] <pitti> kees: how do you mean? the DB doesn't care whether it comes from whiteboard, bug, or a wiki page
[16:48] <smoser> Keybuk, thats fine. i'm good with that.
[16:48] <Keybuk> smoser: only the options part of the fstab entry for the root are actually used
[16:48] <Keybuk> ie. what mount options to use, whether to fsck, etc.
[16:48] <smoser> but will mountall figure out that my LABEL=myroot is the same as sda1 that was on the command line ?
[16:49] <Keybuk> smoser: mountall just ignores the LABEL=myroot
[16:49] <kees> pitti: I'm trying to understand which items are "bugs", since we never planned to track work items with bug reports.  Our todo list jumped, and I want to eliminate all the non-whiteboard work items.
[16:49] <Keybuk> smoser: information present in mountinfo when mountall starts overrides all fstab files
[16:49] <pitti> kees: just unlink them from the blueprint then
[16:49] <kees> pitti: right now, everything is listed by bp name, so I can't tell which are bugs and which are bp whiteboard workitems.
[16:49] <Keybuk> if in fstab you have /dev/sda2 / defaults 0 0
[16:49] <Keybuk> but you boot with root=/dev/sda1
[16:49] <pitti> kees: oh, I see
[16:49] <kees> pitti: I don't know which are the bugs to do the unlinking.  :P
[16:49] <pitti> slangasek: hm, how did you solve this?
[16:50] <beuno> jelmer, pong
[16:50] <Keybuk> mountall will see "/dev/sda1" as the device name for /
[16:50] <smoser> Keybuk, ok. i think thats actually what i want.
[16:50] <pitti> slangasek: i. e. do you have an use case for linking a bug which isn't a WI?
[16:50] <Keybuk> (but remount -o rw,defaults and not check because that's what fstab says)
[16:50] <pitti> slangasek, kees: I guess it might help if the WI description includes the bug #
[16:50] <smoser> i want to trust cmdline
[16:51] <kees> pitti: yes, that would help.  a prefix maybe.    LP: #nnnnn: [workitem text]
[16:51] <Keybuk> smoser: you'll hit a bug with 2.6.32 of course
[16:51] <Keybuk> mountall will fail because it can't mount /dev/pts or /dev/shm
[16:51] <Keybuk> due to the underlying same problem <g>
[16:51] <Keybuk> 2.6.32 will *also* mount a devtmpfs filesystem on /dev
[16:51] <smoser> the kernel does that?
[16:51] <Keybuk> (tangent: kernel really should mount /proc and /sys automatically too - I think there even patches for it)
[16:51] <Keybuk> yes
[16:52] <Keybuk> if you don't use an initramfs, the kernel gives you devtmpfs on /dev now
[16:52] <Keybuk> which is good
[16:52] <smoser> wow. i didn't realize that.
[16:52] <Keybuk> but mountall has a bug where it doesn't mkdir the mountpoint in that situation
[16:52] <smoser> so, next question
[16:52] <Keybuk> so it'll fail to mount /dev/pts and /dev/shm because the empty directories don't exist in the devtmpfs
[16:52] <smoser> if i want to modify /etc/fstab during boot (add entries)
[16:52] <jelmer> beuno: hi
[16:52] <smoser> will mountall "just notice" ? does it watch /etc/fstab  ?
[16:52] <jelmer> beuno: I was talking to somebody about gtk imports yesterday. Do you remember who that was?
[16:52] <Keybuk> (mountall behaves the same way as root here; kernel put devtmpfs on /dev, so it obeys the kernel - overriding its internal fstab)
[16:53] <jelmer> beuno: FWIW I've fixed the import.
[16:53] <Keybuk> smoser: it will not notice
[16:53] <smoser> ok. thats fine.
[16:53] <Keybuk> that would be insane
[16:53] <smoser> yeah
[16:53] <smoser> thats fine
[16:53] <Keybuk> if you deleted a line of a mount point that mountall had already mounted, what should it do? :p
[16:53] <smoser> so i just add an entry and then issue a mount command for it.
[16:53] <Keybuk> right
[16:53] <Keybuk> you can do that
[16:53] <smoser> i agree, insane.
[16:53] <smoser> sweet
[16:53] <Keybuk> (and mountall will actually issue a mounted event for that too <g>)
[16:53] <smoser> thank you Keybuk
[16:53] <beuno> jelmer, yes, it was jjardon
[16:54] <Keybuk> because it *does* watch mountinfo
[16:54] <smoser> oh, that last tidbit is nice.
[16:54] <Keybuk> so it'll see your mount command adding to mountinfo
[16:54] <ion> keybuk: Random thoughts: hypothetically, there could be a number of simultaneous input/progress items, a number of simultaneous UIs and a tiny daemon that contains the logic to delegate everything between all of them. Plymouth with a plain virtual console fallback could be the initial UI, then gdm could take over (displaying any active items under the login area) and even the desktop session could have indicators/notifications for them.
[16:55] <Keybuk> ion: we settled on using Plymouth to do the delegation
[16:55] <Keybuk> (since it already does)
[16:55] <pitti> kees: I need to leave in 5 (sorry), so please feel free to commit; should be a simple patch
[16:55] <kees> pitti: ok, I'll test it
[16:57] <ion> keybuk: How about gdm/desktop interaction? For instance, Upstart warn about jobs that failed to start, there would be a way to readd deferred fscks with the user being able to see the progress at all times etc.
[16:58] <Keybuk> ion: why should Upstart bother a user with such things?
[16:58] <Keybuk> if the system can't recover from a failed service start by itself, my 8yo niece is also unlikely to be able to
[16:58] <Keybuk> deferred fsck -> we're not going to do this
[16:59] <Keybuk> gdm won't start all the time filesystems are being checked
[16:59] <Keybuk> any filesystem with passno>0 will hold up gdm
[17:00] <ion> Your niece would be immediately able to say “it says cups failed to start” and read the error message it printed just before dying straight from the screen instead of saying “printing doesn’t work” and taking 45 minutes of phone call time just to figure out the information. ;-)
[17:00] <Keybuk> disagree
[17:00] <Keybuk> if there's a problem with printing, the message should go in the print dialog
[17:01] <Keybuk> a popup that went past while she was concentrating onto facebook to harvest her crops is not going to stick in her mind
[17:02] <ion> True
[17:02] <Keybuk> you could even do some fun adaptaive UI
[17:03] <Keybuk> like if the print server is down, the print icon on the toolbar has a line through it
[17:03] <Keybuk> clicking it explains what went wrong, and gives you a button to try and restart it, etc.
[17:03] <Keybuk> then you could do things like check for an update, etc.
[17:08] <ion> Speaking of plymouth, is it planned to implement graphics support for vga16fb, or is there just going to be a text fallback for the input/progress items?
[17:09] <ion> In my VirtualBox VM with ~ubuntu-boot packages, any fscks seem to be cancelled almost immediately, probably since plymouth is unable to show anything.
[17:14] <Keybuk> ion: that is the plan
[17:14] <Keybuk> it should be mostly just porting code from bogl to deal with the colourspace
[17:14] <Keybuk> . o O { if you get bored ... :p }
[17:15] <ion> keybuk: Yeah, i was considering taking a look at it some day.
[17:23] <Keybuk> ion: obviously the plymouth framebuffer renderer is the appropriate one
[17:23] <Keybuk> (you may have to move drm.so out of the way, as there might be a bug with the fallback in our package :p)
[17:28] <fta> stgraber, do you have a fix for pastebinit to support openid?
[17:43] <mathiaz> Keybuk: hi - I was trying to modify the hostname.conf upstart job with this: http://paste.ubuntu.com/343531/
[17:44] <mathiaz> Keybuk: the goal is that I want to run the hostname.conf job when /etc/vm_config/ has been mounted
[17:44] <mathiaz> Keybuk: it's a local block device
[17:44] <Keybuk> you're not uploading that to the real distribution, right? :p
[17:44] <mathiaz> Keybuk: no :D
[17:45] <Keybuk> that won't work today
[17:45] <Keybuk> but it will work some point before alpha 2
[17:45] <mathiaz> Keybuk: ah ok.
[17:45] <Keybuk> you want "start on mounted" ;)
[17:45] <mathiaz> Keybuk: that would work today?
[17:45] <Keybuk> no
[17:45] <Keybuk> neither works today
[17:45] <Keybuk> mount happened *before* the given mountpoint is mounted, and blocks it from mounting
[17:46] <Keybuk> which is definitely not what you want :p
[17:46] <Keybuk> in mountall 2.0, mount is replaced by mounting - and a new mounted gets added which is what you want
[17:46] <mathiaz> Keybuk: great!
[17:46] <mathiaz> Keybuk: thanks
[17:47] <blackxored> hello, since lucid is lts and syncing from testing, I should wait my package to migrate to testing to get it into ubuntu, right?
[17:48] <persia> blackxored: Unless you're *really* confident and need it as a dependency for something else.
[17:48] <blackxored> persia, as a matter of fact, both apply for me :P
[17:50] <mathiaz> Keybuk: would "start on (mount MOUNTPOINT=/ and net-device-up IFACE=eth0)" work today?
[17:52] <mathiaz> smoser: ^^ - I was looking into some ec2-config and run into the issue above
[17:52] <blackxored> I suppose I'll wait
[17:52] <blackxored> persia, ^^^^
[17:53] <ion> keybuk: Now that i think of it, perhaps we should only set iopriority instead of both it and niceness for low-priority fscks. The iopriority should prevent thrashing, and equal CPU priorities could utilize multiple processors better.
[17:59] <smoser> mathiaz, it doesn't work today
[18:00] <mathiaz> smoser: right - I noticed that
[18:00] <smoser> needs update to new mountall, and also needs to say "mounted MOUNTPOINT=/"
[18:00] <smoser> heres what i have right now for "early boot"
[18:00] <smoser> start on (local-filesystems and net-device-up IFACE=eth0)
[18:01] <smoser> i believe thats generally functional, but i've been playing with a lot of workarounds
[18:01] <kirkland> what is tileblit and bitblit?
[18:01] <kirkland> these are dragging in the fbcon module on the Lucid ubuntu-server installs
[18:01] <kirkland> which is definitely not desired (by me anyway)
[18:01] <kirkland> blacklisting isn't working either
[18:02] <geser> where do I file bugs against manpages.ubuntu.com?
[18:03] <kirkland> geser: lp:ubuntu-manage-repository
[18:03] <kirkland> geser: if it's a bug with the generation
[18:03] <kirkland> geser: bugs against manpage content should go against the supplying package
[18:04] <geser> kirkland: it's a bug with converting the printf.3 manpage. it stumbles about the \0 inside the manpage
[18:04] <kirkland> geser: okay, sure, file a bug
[18:04] <kirkland> geser: send a patch, that would be great ;-)
[18:05] <kirkland> geser: i don't spend much time working on manpages.ubuntu.com any more
[18:05] <kirkland> geser: usually just a day or two per cycle, to get it working with the new code name
[18:05] <kirkland> geser: and i'll scrub a few bugs while i'm at it
[18:05] <kirkland> geser: fwiw, that has already happened for this cycle, so it might be a while
[18:06] <geser> no hurry, I just found this today and want to file it before I forget about it
[18:39] <geser> james_w: I was trying to do a bzr merge of perl (I've already submitted a debdiff for sponsoring) but got stuck as the debian branch is pretty old and perl is also listed at http://package-import.ubuntu.com/failures/.bzr/failures/. Do I need to do something about it?
[18:40] <james_w> geser: that's a bug I need to fix
[18:42] <geser> james_w: so I can only wait on someone looking at the u-m-s queue and sponsoring the debdiff?
[18:42] <james_w> geser: unfortunately so
[18:44] <geser> no problem, I justed wanted to be sure with several processes getting updated this cycle
[19:03] <ebroder> Can anybody add me to ubuntu-universe-sponsors?
[19:07] <geser> persia: ^^
[19:08]  * persia fiddles with LP a bit
[19:10] <mathiaz> kirkland: hey
[19:11] <mathiaz> kirkland: is bridge networking working correctly on NCs?
[19:11] <mathiaz> kirkland: this is on lucid
[19:11] <persia> ebroder: What's your LP ID?  LP is being annoying.
[19:11] <ebroder> broder
[19:13] <kirkland> mathiaz: i can't say yet
[19:13] <kirkland> mathiaz: i'm just getting the eucalyptus 1.6.2 packages tested now
[19:13] <ebroder> persia: \o/ Thanks!
[19:40] <ebroder> Do new packages in Debian automatically sync to Ubuntu?
[19:40] <ebroder> Or do they need to be manually approved the first time?
[19:41] <james_w> it's a semi-automatic process
[19:41] <james_w> the autosyncer pulls them in
[19:41] <james_w> but that's not being run very frequently at the moment
[19:42] <ebroder> Ok, sounds good
[20:05] <kirkland> is bzr pull from LP hanging for anyone else?
[20:09]  * kirkland found the #launchpad topic
[20:09] <mathiaz> kirkland: yop
[20:32] <JontheEchidna> asac: ping
[20:49] <Keybuk> mathiaz: no
[20:50] <Keybuk> mathiaz: you'd block any filesystems from mounting until a network device came up
[20:50] <Keybuk> ion: sounds right to me
[21:06] <Keybuk> ion: I'm increasingly convinced *that* behaviour of Upstart is wrong too :p
[21:13] <ion> keybuk: Sorry, what behavior of Upstart? It does priority manipulation?
[21:13] <Keybuk> ion: no, that "on foo and bar" blocks foo until bar happens
[21:13] <Keybuk> it seemed like a good idea at the time
[21:13] <Keybuk> it still does have useful effects
[21:14] <Keybuk> but it's susprising everyone :p
[21:14] <sebnerr> Keybuck: The magic of opensource, Hmm? hoia BTW :)
[21:16] <ion> keybuk: Ah
[21:57] <slangasek> pitti: hmm, didn't solve that because I didn't realize it needed solving :)  Had thought about including the bug # in the WI description, but then thought it might be better to extend the database first to include other structure :)
[22:14] <ebroder> If I have a pre-Karmic (site-local) package that's shipping an upstart event.d file, what's the best way to start it in the postinst? Just use initctl?
[22:27] <nixternal> anyone able to use bzr+lp right now?
[22:28] <Guest50176> i am using ver 8.04, is there a utility to check the health of the hard drive?
[22:28] <persia> nixternal: /topic in #launchpad implies not
[22:30] <persia> Guest50176: #ubuntu for support
[22:33] <nixternal> thanks persia
[22:36] <superm1> is bzr+ssh different than bzr+lp?
[22:36] <superm1> i didn't realize there was a bzr+lp
[22:38] <LaserJoc1> I thought they were the same thing, just bzr+lp does like the lp:<branch> stuff
[22:55] <wgrant> superm1: 'bzr+lp' doesn't exist. I suspect nixternal just meant bzr and LP.
[22:58] <nixternal> wgrant: it is a new feature silly, you didn't know about it? :p
[23:01] <elmo> james_w: ping
[23:01] <LaserJock> hmm, I swear I've seen bzr+lp URLs
[23:01] <elmo> james_w: (urgently)
[23:01] <james_w> hi elmo
[23:01] <LaserJock> maybe I've finally fallen of the deep end
[23:01] <elmo> james_w: can you look at jubany?  I think you're DOS-ing bzr.lp.net
[23:02] <elmo> it's OOMKed itself twice in as many hours, and you have a scary number of bzr processes on there; could be random coincidence
[23:02] <james_w> yeah, something looks odd
[23:02] <james_w> lots of hung ssh processes
[23:02] <james_w> I'll stop it and investigate
[23:02] <sebnerr> nixternal: another k3b update waiting for you :p
[23:06] <sebnerr> james_w: buh a lot of discussion going on now about bzr :/
[23:06] <james_w> hi sebnerr
[23:06] <james_w> is it talk like a pirate day?
[23:08] <sebnerr> james_w: haha. nah I suppose I can't use my bouncer on my iPod
[23:08] <sebnerr> and _ is boring :p
[23:10] <dtchen> joaopinto: user.log for starters, but you'll want to use wiki/PulseAudio/Log
[23:11] <dtchen> joaopinto: that's normally a sign of a badly behaved client not the daemon itself.
[23:11] <joaopinto> dtchen, ok, i will try to get it next time, i had a new event, but this time it was going to max sound
[23:11] <dtchen> (though of course there's a bug in that the daemon shouldn't belly-up)
[23:12] <joaopinto> I was wondering if could something realted to the volume changing keys instead
[23:12] <joaopinto> related
[23:13] <joaopinto> since it was providing the visual hint when you press the keys
[23:15] <dtchen> joaopinto: are you using PULSE_NO_SIMD=1 ?
[23:16] <dtchen> joaopinto: also, we should move this to +1