[00:00] slangasek: i just plucked this crap out of the init script [00:00] (we don't reverse that when stopping the job, so not sure why it should be here) [00:00] kirkland: it wasn't boot speed per se. more than it's easy to trip over upstart bugs [00:00] kirkland: well the init script wasn't very good ;) [00:01] gratuitous use of cat; 4 sed commands where 1 would do; and why are we preallocating /dev/loop nodes here? [00:01] slangasek: will fix the sed [00:01] slangasek: will ditch cat [00:02] ah, but those are the minor things, it's the mknods that have me scratching my head :) [00:02] slangasek: the loop devices are necessary for mounting storage for the instances [00:02] slangasek: let me find the bug number with the background [00:03] and "32" just happens to be the right number of loop devices to preallocate? :) [00:03] bug #430846 [00:03] Error: Could not parse data returned by Launchpad: HTTP Error 500: Internal Server Error (https://launchpad.net/bugs/430846) [00:03] * kirkland screams at launchpad [00:05] 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] google cache FTW [00:05] heh [00:05] kirkland: edge is working in read only mode, FWIW. [00:06] wgrant: thanks [00:06] slangasek: so there you go .... I asked the kernel team if we could increase the ubuntu default [00:06] slangasek: they told me go make them myself [00:06] slangasek: seems easy enough to do safely at boot [00:07] kirkland: right - I guess I'm just a little wary of the preallocation of a fixed, magic number of loopback devices [00:07] not a bug now, might be a bug later [00:07] :) [00:07] slangasek: and apparently this is something only eucalyptus needs, as the kernel team didn't want to increase it arbitrarily for everyone [00:07] we need to fix loop [00:07] so that it allocates on demand [00:07] every one created at boot costs boot time [00:07] it should be more like /dev/pts [00:07] jebus [00:08] that's upstreamy though [00:09] Keybuk: i do not disagree :-) [00:10] slangasek: what does this mean: [00:10] echo -n 1 > /proc/sys/net/ipv4/ip_forward [00:10] not /etc/sysctl.d? [00:10] * Keybuk wonders why there's no /sys/module/loop/parameters/max_loop [00:11] 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] slangasek: I think that kirkland hasn't realised that's a sysctl ;) [00:11] I'm not saying one or the other is right, I'm just pointing out what I thought was the standard mechanism [00:12] kirkland: your echo is equivalent to putting "net.ipv4.ip_forward = 1" in /etc/sysctl.d [00:12] Keybuk: cool, thanks, i can do that [00:12] yeah that's probably right [00:12] since then all the documentation applies [00:13] 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] Keybuk: slangasek: what about /proc/sys/net/bridge/bridge-nf-call-iptables ? [00:14] Keybuk: slangasek: is that sysctl-able too? [00:14] yes [00:14] anything under /proc/sys [00:15] slangasek: okay, where do i find the docs to look up the var name? [00:15] kirkland: it's straight s,/,./g on the filename [00:15] er [00:15] s,/,.,g [00:15] net.bridge.bridge-nf-call-iptables = 1 [00:15] slangasek: ? [00:15] yup [00:16] * slangasek nods [00:16] 30-eucalyptus-nc.conf [00:16] that look about right? [00:17] sure [00:18] slangasek: is there a better way to get aoe modprobed? [00:18] apparently not :) [00:18] slangasek: the loops will need to stay for now, until there's a better way to do this [00:19] yep [00:19] kirkland@x200:/local/source/eucalyptus/lucid.public/ubuntu$ pastebinit debian/eucalyptus-nc.upstart [00:19] http://paste.ubuntu.com/343123/ [00:19] kirkland@x200:/local/source/eucalyptus/lucid.public/ubuntu$ pastebinit debian/30-eucalyptus-nc.conf [00:19] http://paste.ubuntu.com/343124/ [00:20] kirkland: looks sane to me [00:20] slangasek: cheers, thanks [00:20] 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] sure === dendrobates is now known as dendro-afk === dendro-afk is now known as dendrobates === bdefreese2 is now known as bddebian === NCommander is now known as Guest48610 === spm changed the topic of #ubuntu-devel to: Lucid Alpha 1 released | Archive: open | MoM running (but use bzr!) | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-karmic | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithB === Guest48610 is now known as NCommander === spm changed the topic of #ubuntu-devel to: Lucid Alpha 1 released | Archive: open | MoM running (but use bzr!) | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-karmic | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs === NCommander is now known as Guest88322 === nhandler_ is now known as nhandler === Whoopie_ is now known as Whoopie === Guest88322 is now known as NCommander === asac_ is now known as asac [05:44] Good morning [05:44] Morning pitti [05:46] heya pitti! [05:46] Whoopie: just 481448> uload then [05:47] * slangasek waves to pitti [05:48] slangasek: daemon.log> hm, it seems full of debugging spew; but yes, we can certainly also downgrade the debugging level of apps [05:48] debugging spew - really? [05:48] ah, wpa_supplicant [05:49] oh, wait [05:49] pitti: daemon.log, or auth.log? daemon.log doesn't appear to be synchronous by default [05:49] auth.log is, and is the one I'm concerned about :) [05:49] slangasek: oh, and I was really talking about daemon.log [05:49] powertop regularly complains about stuff writing there [05:50] powertop doesn't seem to distinguish between synchronous and asynchronous writes [05:50] ah, then I misunderstood your comment, sorry [05:51] you probably didn't misunderstand, I was probably just confused :) [05:51] hey StevenK, morning Hobbsee! [05:51] 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] without noticing that auth != daemon :) [06:02] 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] slangasek: cryptsetup> ack [06:06] * dtchen wonders if there's a faster way to test-build for armel [06:06] (I'm kinda surprised that upstream PA hasn't encountered these issues) [07:18] with the new LP rollout, do we have 3.0 source format now? [07:19] at least sync-source.py still fails [07:19] but that could be due to cocoplum having a too old dpkg [07:19] wgrant: ^ do you know? [07:28] slangasek: looks like we'll need to keep cglib2.1 for the moment. [07:31] james_w: thanks for your "distributed dev" summary! [07:31] 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] 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] good morning [07:47] pitti: Do you know where I might find powerpc ddebs for lucid? === ara_ is now known as ara [07:49] 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] Heh. And it was last weekend that I went looking :) [07:49] persia: if you need them for a recent build, they can still be retrieved from the buildds, though [07:50] persia: are you looking for a particular package? [07:50] 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] the build log should tell you on which buildd it was done [07:50] persia: sure, just install pkg-create-dbgsym locally [07:50] binutils 2.20-4ubuntu3 [07:50] then it just happens [07:51] I do that, but that's only for packages I build :) [07:51] persia: sorry, that was built a month ago already; they are gone, I'm afraid [07:52] 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] Ah, so they don't get stored in +archive :( [07:52] persia: not yet; however, wgrant was working on that [07:52] so, I hope it'll happen "soon" [07:52] That would meet my use case. [07:52] pitti: RT #36873, if you want to watch it. [07:53] On a separate note, if you've removed all the binaries, please also remove the (now invalid) Packages and Release files. [07:53] Most of the ddebs-in-soyuz work is done. I'm nearly there. But then there's the issue of librarian bloat. [07:53] (it's confusing to have things work and then get 404s for difficult to understand reasons) [07:54] persia: well, there's still tons of powerpc ddebs [07:54] Oh, so I just picked an unlucky package? Oh well. [07:54] I just stopped collecting them [07:54] but yeah, I'll remove them for lucid [07:55] 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] pitti: "Macaroni Went Out Of Space" sounds like a Hunter S. Thompson book title, or an album by a 1960s psychedelic band. [07:57] you are so right [07:57] sometimes I don't even read what I wrote any more :) [07:58] persia: pitti can you probably tell us approximately how much bloat we're talking about. [07:58] But it's not an insignificant volume :( [07:58] right, they are huuuuuuuuuuuuge [07:58] I'd estimate some 300 GB on macaroni right now [07:59] Ah, that is large. [07:59] expect some (elf portion of packages)%5 [07:59] erm, *5 [07:59] Plus I suspect that you have a more aggressive binary removal policy than LP. [07:59] 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] yeah, I only keep the latest [07:59] it explodes otherwise [08:00] so please let's not keep all of them for ia64 :) [08:00] 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] So it needs an Awful Lot of disk space on both cocoplum and mizuho. [08:02] And I presume that me running to the shop and shipping disks isn't the solution, because there are chassis limitations, etc. [08:05] we could only keep supported arches, and only for current lts, current stable, and development release [08:05] plus ports for dev release perhaps [08:06] That's a set that matches all my use cases :) [08:06] Actually, thinking about it, we could safely enough purge ddebs early. [08:06] ttx: wah; ok [08:07] slangasek: proxool needs asm2, cglib (2.2) needs asm3, cglib2.1 needs asm2 [08:08] slangasek: and asm2 and asm3 don't live well together in the same classpath [08:08] so I'd say that debian adding "Provides: libcglib2.1-java" to libcglib-java is somewhat optimistic [08:09] pitti: cdbs import failure info: http://package-import.ubuntu.com/failures/.bzr/failures/cdbs [08:09] (and eucalyptus needs proxool and cglib) [08:10] slangasek: ah, thanks [08:10] slangasek: btw, do you have sata disks? my laptop doesn't even have sata power link management === Adri2000` is now known as Adri2000 [08:10] 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] I'm just curious how it feels like when enabling it [08:11] pitti: yes, I have sata, with the intel chipset needed to use this [08:11] I have 3GB RAM today, which is enough that SLPM doesn't hurt me [08:11] (SLPM? SPLM?) [08:12] when I had 1GB of RAM, it was bad :) [08:12] I now use "min_power" if inactive/total > 15%, and medium_power if inactive/total > 5% [08:12] and if it's even less, I don't touch it [08:12] since it seems dangerously close to swapping [08:12] I'm not entirely sure if this is a better heuristics, I'll send out a call for testing [08:13] 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] so perhaps just bump it to 2 GB? [08:14] 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] fine with me; maybe it should be varied by architecture, also? [08:15] 1GB might be enough on 32-bit, isn't enough on 64-bit [08:15] does it make such a difference actually? [08:15] I had expected most things to just use ints [08:15] pointers do, of course [08:16] everything python approximately doubles in size [08:16] how much RAM do netbooks have these days? They are prone to have i386 [08:16] They vary from 512MB to 3GB [08:17] (at least that's what I saw last time I looked in a shop about 3 weeks ago) [08:17] so, let's say 1 GiB on i386, and 2 on AMD64? [08:17] sounds reasonable to me [08:23] 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] 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] slangasek: no, but that happened to me too once and I don't know what made it more reliable [08:32] tseliot: should I close my bug, or leave it open? [08:32] slangasek: please leave it open, I think it's something we should investigate [08:32] ok [08:36] pitti: cryptsetup checks out, the problem I'm seeing is mountall+fstab interaction and not a bug in the cryptsetup fix itself [08:37] nice, so good to go to -proposed then? [08:37] pitti: IMHO yes; I'll update the test case based on my latest findings [08:50] pitti: test case updated [09:11] ogra_: did you ever happen to test lucid alpha-1 on your touchscreen? was there a major regression due to the udevification? [09:11] (of x.org) [09:27] pitti, i'm currently not running lucid on my laptop, will tell you once i do [09:27] ogra_: thanks === tkamppeter_ is now known as tkamppeter [10:09] 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] 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] and I do not currently ignore language-pack-* [10:11] 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] both :-) [10:11] 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] it works fine [10:11] * slangasek grins [10:11] I can do it by changing the links, which is perhaps a little more elegant [10:11] I keep getting bad merge requests for apport, and just pushing the real branch to lp:ubuntu/apport would help a lot [10:11] there's a bug I need to fix before I do that though [10:12] if the package also exists in debian, though, that will lose us some of the history I guess? [10:12] for those three that's not the case [10:12] yeah [10:12] 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] I have to make it re-import taking in to account what is already there, after adding some tags [10:13] I would prefer to do it all properly, but I understand that it must be frustrating waiting for me [10:14] james_w: if it's causing you extra work, I'll leave it as it is for nwo [10:14] 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] by doing a push --overwrite you force the issue [10:14] 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] pitti: you theorised correctly [10:15] there are just a couple of implications for the backend [10:15] the code hasn't quite caught up with reality yet === ogra_ is now known as ogra [10:21] is this right channel to ask about Launchpad?? [10:21] EsatYuce: #launchpad is probably a better channel for questions about Launchpad === mac_v is now known as _ === _ is now known as _7hills === _7hills is now known as mac_v === jelmer__ is now known as jelmer === jelmer is now known as Guest85315 === Guest85315 is now known as jelmer === c0p3rn1c is now known as copernic [11:12] 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] tjaalton, tseliot, bryce: FYI, I documented the udev X.org bits on https://wiki.ubuntu.com/X/InputConfiguration [11:23] anyone else see this in current lucid? [11:23] rm: cannot remove `/tmp/mkinitramfs_cLvNRp/lib/modules/2.6.32-8-generic/modules.*map': No such file or directory [11:23] pitti: it looks good, thanks for working on this [11:25] tjaalton, tseliot, bryce: (I also linked it from /X) [11:25] pitti: ah, for quick access from X, nice. Thanks again [11:27] 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] pitti: thanks. it's possible that device configuration will not be allowed from the backend, but moved back to the ddx [11:27] pitti: even for lucid [11:27] patches upstream [11:27] persia: hm, let me check [11:28] persia: right, current input_id indeed does't assign _KEYS, fixing [11:28] tjaalton: would that mean that it stops using udev altogether then? [11:29] 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] subunit [11:30] 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] 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] pitti: and also support for xorg.conf.d [11:30] mdz: yes, Keybuk said he was going to fix that today [11:30] tjaalton: ah, I see; well, the doc can always be updated then [11:30] pitti: which packages can use to ship conf snippets [11:30] slangasek, ok, thanks (and what on earth are you doing awake?) [11:30] pitti: of course [11:30] mdz: I work odd hours on Thursday in order to stay in touch with Europe :) [11:30] ah [11:31] pitti: For the general case, they shouldn't. Oddities like the Saitek Cyborg Command Unit probably should. [11:31] (where the joystick is just asking to be remapped to send keyboard events) [11:33] persia: if the device event mask claims that it can produce EV_KEY, input_id will report that [11:33] Ah, that makes sense. OK. [11:33] * persia will go read the input_id source this weekend to actually understand [11:34] it by and large just tests the bitmasks in /sys/class/input/*/capabilities/{ev,abs,rel,key} [11:34] using the flags in /usr/include/linux/input.h [11:34] 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] but this bit mask testing is horrible/impossible in pure udev rules, which is why we need the callout [11:35] tjaalton: right, I have that when I attach my joystick [11:35] tjaalton: actually, that depends on the joystick: not all of them are either absolute or autocentering. [11:35] pitti: it also happens for hw accelerometers, so tap your laptop.. :) [11:35] persia: ah, ok [11:36] 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] pitti: I'd say not. there's a -joystick driver for that [11:36] we can of course easily ignore joysticks as X input devices [11:36] There are definitely two schools of thought by users. [11:36] yes, but the last time this happened with hal, there were a bunch of users upset :) [11:36] james_w: can you join #ubuntu-x, please? [11:37] tjaalton: ... which we don't install by default? [11:37] I think there should be an (optional) way to enable/disable that easily. Used to be xf86-input-joystick [11:37] pitti: right [11:37] tjaalton: so xserver-xorg-input-joystick should ship an udev rule which sets ENV{ID_INPUT_JOYSTICK}==1, ENV{x11_driver}="joystick" [11:37] pitti: that's already in git, just not released yet [11:37] ah, sweet [11:38] 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] Is there a way to do that without HAL? Should descriptor files be shipped somewhere? [11:39] (e.g. in the x52pro package) [11:40] Or does that now require custom input drivers? [11:40] hal was just the backend [11:41] persia: hal itself didn't really add new devices (and wasn't able to) [11:41] if it was possible with x11_options, it'll still be possible [11:41] persia: you should be able to set configuration in udev just as well as in hal [11:41] OK, so that's just constructing the right ENV(x11_options.foo) entries? [11:44] e.g. ENV(x11_options.event_key_remap)="464=118" and the like? [11:45] persia: if that worked in hal, it'll work with udev rules [11:45] it's just the messenger [11:45] persia: above wiki page has a migration guide [11:45] 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 === ara__ is now known as ara [12:58] seb128, regarding xchat-gnome - my patch for the git version is in the upstream bug report. [12:59] LucidFox, the current patch still change .glade files there [13:00] LucidFox, they named the files .glade rather than .ui? [13:00] seems buggy... [13:01] Yes - the git version uses these .glade files. [13:01] ok, I will check that later [13:02] that seems wrong [13:02] gtkbuilder files are named .ui usually [13:03] Actually... the git version seems to still use libglade. o_O [13:04] weird, http://git.gnome.org/cgit/xchat-gnome/commit/?id=8ba28cb15d6bb365891a495130aed49145a7a2b5 [13:04] Only the preferences dialog is converted to GtkBuilder. [13:04] I think they rather didn't rename their .glade to .ui [13:04] The rest still use libglade [13:04] oh ok [13:05] yet even for the preferences dialog. they didn't rename .glade to .ui. === ikonia_ is now known as ikonia [13:35] persia: Latest binary package built wins [13:36] Last one to build that is [13:36] Nope. [13:36] Highest version wins. [13:36] (for those seeking context, see #launchpad) [13:39] 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:39] Launchpad bug 487937 in hundredpapercuts "open up of compressed filetypes should request to install proper extractor" [Undecided,Confirmed] https://launchpad.net/bugs/487937 [13:46] qense, we don't use packagekit but have a nautilus patch using gnome-app-install for installing things too... [13:47] qense, the issue is not a nautilus one though [13:47] it is a share-mime-info issue? [13:47] it's likely that file-roller claims handling those in its desktop entry [13:47] well I would guess that file-roller is used [13:47] but it fails [13:48] the error message just says no suitable application can be found [13:48] there is a bug on file-roller asking for smart install already though [13:48] really? I couldn't find any [13:48] qense, bug #148084 [13:48] Launchpad bug 148084 in file-roller "totem-like/firefox-like plugin installer for file-roller" [Wishlist,Triaged] https://launchpad.net/bugs/148084 [13:49] ah, I see [13:49] but that's for inside file-roller [13:49] qense, but if file-roller is not open it might be because the mimetype is not listed [13:49] what mimetype are those which give you the error using? [13:50] 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] qense, cab = application/vnd.ms-cab-compressed? [13:53] qense, no .desktop lists those in their .desktop in /usr/share/applications [13:54] nautilus can't guess from nowhere what application could be able to open those [13:54] the .desktop need to list the mimetype for that to work [13:54] ah [13:54] lzma and 7z should work [13:54] ah [13:54] a lot of ahs here ;) [13:54] since those are listed in the file-roller .desktop list [13:55] I see CAB isn'tin .desktop indeed [13:55] I'm not sure file-roller handle those [13:55] I'm not sure we have any gui to handle those [13:55] it's a somewhat specific format [13:55] yes [13:56] 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] it's listing application/x-cabinet though [13:57] that's strange [13:57] could be a .desktop bug [13:57] or an inconsistency from MS [13:57] in any case it's not a nautilus issue [13:57] indeed [13:57] it just matches mimetype and .desktop lists [13:59] 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] Thanks for your help, seb128! (and for your suggestion, persia) [14:01] Hmm, it seems my automount stuff has stopped working in karmic. [14:01] Is this a known issue? [14:01] Mez, no [14:01] qense, you're welcome [14:02] seb128: any idea of how to "debug" [14:02] use ubuntu-bug storage [14:03] it will get gvfs, devicekit-disks etc logs [14:03] "Package storage does not exist" [14:04] install apport-symptoms [14:05] * Mez waits for upgrade to finish [14:05] hmm... new apport version ? [14:12] seb128: #369067 [14:12] bug #369067 [14:12] Launchpad bug 369067 in pidgin "pidgin crashed with SIGSEGV" [Medium,Invalid] https://launchpad.net/bugs/369067 [14:12] Mez, doesn't seem right [14:12] bug #36906749 [14:12] Error: Launchpad bug 36906749 could not be found [14:13] ah, crud [14:13] bug #497771 [14:13] Launchpad bug 497771 in devicekit-disks "Discs not automounting in Karmic." [Undecided,New] https://launchpad.net/bugs/497771 === rmcbride_ is now known as rmcbride [14:14] hmm, looks - sane enough to me. [14:15] I think it's a dup [14:15] the device has no type [14:19] seb128: a reboot seems to have fixed this. [14:19] weird [14:20] is that karmic uptodate? [14:20] maybe some process got killed off at a point i hit high memory or something [14:20] there was a fd leak in udev earlier in the cycle [14:20] yeah, up to date. [14:20] but that got fixed in a stable update [14:20] oh, when? [14:20] that's fixed for a least one month [14:20] oh, it's been updated at the end of last week at least [14:20] some similar bugs are due to devicekit processes crashing too [14:21] so it might be one of those [14:21] could you comment on the bug saying that a reboot fixed it? [14:21] already in the process of doing so [14:21] thank you [14:22] worth marking as invalid too? [14:22] you can yes or you can wait for pitti to triage it [14:22] I expect he will need some extra log though [14:22] so if you can't get the issue now... [14:22] well, it's working now, so I won't really be able to reproduce [14:22] close it and reopen if you get it again [14:23] * Mez has no access to [14:23] and maybe check your system logs for asserts or crashes [14:23] wait, wtf [14:23] I'm part of bug control [14:23] you should be able to close your own bug in any case [14:23] yeah, missed the "double login" stuff :) [14:24] damn edge :D [15:17] afternoon sabdfl [15:17] sabdfl is here ? :) [15:17] his IRC nick is :) === kklimonda_ is now known as kklimonda [15:18] hello all [15:20] Howdy === Lutin is now known as Guest3058 === Caesar_ is now known as Caesar [15:51]