=== robbiew is now known as robbiew_ [00:50] kees: is liberal application of polkit not sufficient for solving the apport issue? [00:51] broder: dunno, frankly. pkexec is kinda crazy [00:51] (it seems like polkit is less of an awful hack than gksu and friends) [00:55] hmm...i'd probably have a dbus backend so you could group all of the "gather some file" actions under a single polkit permission [00:55] isn't polkit going away? [00:55] I can't remember [00:55] it is? [00:55] that's news to me, but i could be underinformed [00:56] the only think I heard about it going away was being folded into systemd [00:56] SpamapS: re pushing low pri changes to a UDD branch. I hope you noticed slangasek said he endorses the practice. He didn't claim it was a good idea. [00:56] heh [00:58] consolekit is going away [00:58] well, no [00:58] that's yet to be seen [00:59] ok, some people want it to go away :-) [00:59] it's not going to be used in Fedora, but Ubuntu isn't going to switch to systemd any time soon [00:59] that makes a bit more sense, at least [00:59] consolekit always seemed like a bit of a solution looking for a grand vision that wasn't materializing [01:00] Someone wanted me to install webkit on a server the other day for some kind of PDF generation tool. I suggested the internet facing box wasn't the place. These kits are definitely out of control. [01:01] i'm still waiting for KitKit :-P [01:01] KitKit does exist [01:01] ...wait, seriously? [01:01] ScottK: wkhtml2pdf? [01:01] You've got to have one kit to rule them all. [01:01] it was what Lennart was going to write to replace libnih [01:01] but he seems to just copy&paste [01:01] kitkit was created by the Department of Redundancy Dept. [01:01] micahg: Sounds right. [01:02] micahg: Have you used it? [01:02] ScottK: to be fair, if I was rendering content, I would probably use webkit for layout too [01:02] Keybuk: Sure. I just don't like having such a steaming heap of security vulnerabilities even installed on an internet facing server. [01:02] ScottK: yeah, I actually created a wrapper that used it to rip some web pages to PDF, it seems to be pretty good (wouldn't put it on a web facing server though :)) [01:03] ScottK: I would not describe WebKit as such [01:03] cjwatson: is bug #425979 tractable? [01:03] Launchpad bug 425979 in grub2 (Ubuntu) "Holding shift fails to display grub2 menu" [Undecided,Confirmed] https://launchpad.net/bugs/425979 [01:03] Keybuk: It's entirely possible I am being unfair. [01:03] it's had roughly the same number of CVEs in recent history as TeX, for example [01:05] In this particular case there wasn't a need to do it on that box. It was just simpler. Fortunately it was an ancient BSD version and there were issues. [01:05] Keybuk: did you just imply that webkit has as many CVEs as TeX? [01:07] * kees can't tell if that's intentional trolling or not :) (270 vs 19) [01:08] kees: in recent history ;) [01:08] slangasek: I think I mostly got agreement last-but-one UDS that if we could get the post-GRUB experience really smooth then we could reintroduce a short delay and drop the hold-shift requirement [01:08] * ScottK just noticed http://blogs.technet.com/b/security/archive/2010/03/09/ubuntu-cve-tracker.aspx [01:08] slangasek: but didn't quite finish that off [01:09] kees: though webkit is cross-platform, and I was just looking at LWN [01:09] Kind of interesting in a not really, but they're talking about us, way. [01:09] slangasek: I doubt it's tractable otherwise [01:10] cjwatson: ok [01:11] slangasek: (well, aside from UEFI systems, where we seem to be failing to notice that modifier detection isn't currently available judging from one bug I've seen, but I doubt that's what's at issue here) [01:12] heh [01:14] Keybuk: in recent history. 5 months. webkit: 64. TeX: 1 [01:15] kees: clearly webkit is better maintained ;-) [01:15] ScottK: yeah, I had a chat with Jeff Jones when he first published that [01:16] Keybuk: that's one way to look at it ;) === bryceh is now known as bryce [01:18] seb128: librsvg2-common.postinst still uses the wrong path in 2.34.0-0ubuntu3, so things break if librsvg2-common was configured more recently than libgdk-pixbuf2.0-0. [01:21] so I wonder why binfmt-misc + suid seems to fail [01:23] I just wish the underlying parts of the desktop infrastructure would stop changing. i.e we have consolekit, if it has flaws, lets improve it. If we have policykit, lets just improve it etc. [01:24] slangasek: Did you use the 'C' flag? See bug 519228. [01:24] Launchpad bug 519228 in binfmt-support (Ubuntu) "Support for C flag" [Undecided,Fix released] https://launchpad.net/bugs/519228 [01:24] andersk: I used the qemu flag [01:25] andersk: yeah, I just asked in -desktop if anyone wants to fix it [01:25] andersk: /usr/share/binfmts/qemu-arm does have flags: OC === rickspencer3_ is now known as rickspencer3 [01:38] so I can reliably cause unity-window-decorator to crash after it prints several GLib-GObject errors... what is the function that prints these so I can set a breakpoint and see what's going on? [01:45] slangasek: we should be migrating away from non-multiarch paths instead of suppressing errors about the dir not found, right? [01:47] (Where “migrating away” means “dropping support now even though some packages still use the old paths”?) [01:48] micahg: I don't understand what errors you're referring to [01:49] slangasek: something like this: http://web.mit.edu/andersk/Public/ubuntu/librsvg_2.34.0-0ubuntu3_multiarch.debdiff as opposed to http://paste.ubuntu.com/612527/ [01:51] micahg: ah, no, we definitely need to look in both the old and new dirs on a transitional basis [01:51] slangasek: and suppress errors if the old dir doesn't exist? [01:52] that would be reasonable [01:52] I hadn't bothered to do that with glib2.0 or gdk-pixbuf, for instance [01:52] so upgrades are a little noisier right now... but suppressing those would also be fine [01:55] slangasek: would it be better to do an optional check on the non-multiarch dir and append to the loaders.cache if it exists? [01:56] micahg: also perfectly reasonable [01:56] provided the cache is line-based and you can do an append [01:56] appears to be so [01:57] maco: the link in your blog post doesn't seem to work for me [01:57] i get a 404 [01:58] crap [01:58] thanks [01:58] broder: what about https://spreadsheets.google.com/spreadsheet/viewform?formkey=dGRLSmxTQ05VYzh6NmdBN3BsakhpM3c6MQ#gid=0 ? [01:58] maco: wfm [01:58] ok thanks [01:59] maco: the second question is totally unfair to all of the developers who have installed ubuntu dozens of times in dozens of ways :-P [01:59] slangasek: thanks, I think we'll go with andersk's solution as it matches the other package (gdk-pixbuf) [01:59] bradm: haha [02:00] er? [02:00] broder: haha [02:00] bradm: not you [02:00] micahg: given that I wrote the gdk-pixbuf bit and had a bug in it in the first pass, you should feel free to change both of them if you think it can be improved :) [02:00] maco: (i'm pretty sure i've installed ubuntu in all of the ways you list at one point or another) [02:00] broder: its there so that on the "rate the ubuntu installer" part, its possible to tell which one they're referring to [02:01] surveys have textboxes for a reason ;) [02:01] maco: some clarification in that section (e.g. "if you've installed ubuntu in multiple ways, rate the one you selected above", or something) [02:03] slangasek: ok, maybe later, thanks [02:08] c [02:13] ogra_: hey, I was told I should ask you about install ubuntu on the ARM AC-100/Dynabook AZ. Is there a url where to get directions? Do I just follow linaro directions, or is that different? [02:34] hallyn, Stop by #ubuntu-arm: there are a number of folk who can answer that (I'd be happy to, but it's long). [02:40] persia: thanks (in that case i guess i'll do that tomorrow) === asac_ is now known as asac === hallyn is now known as hallyn_afk === nigelb_ is now known as nigelb [05:24] Happy Towelday! \o/ [05:28] Good morning [05:41] pitti: I did some more sru-release's .. all > 7 days and verification-done .. [05:41] pitti: and I did sru-release -d natty fwts just now to copy it to oneiric [05:42] SpamapS: ah, good; working well for you then? [05:42] pitti: yes, its perfect. :) [05:42] SpamapS: it tends to time out for big packages [05:42] well, not the script, but Launchpad [05:43] those will need to be done on cocoplum [05:43] but for the majority it should work indeed [05:44] pitti: is there a bug open for launchpad then? Thats one time where a timeout exception should be made. [05:45] pitti: Still? [05:45] SpamapS: I asked for bumping the timeout for this as well as the +queue page, but they didn't like that [05:46] StevenK: have you used the +queue pages? [05:46] sometimes you have to try and binNEW or accept from unapproved four times, and for some it just never works [05:46] pitti: the other option would be to make it asynchronous [05:47] AFAIR the primary problem that has a linear or higher time behaviour is the closing of the bugs [05:47] that should indeed happen async [05:47] well, that, or the timeout should scale with the number of bugs [05:47] I think the former is simpler [05:48] pitti: I keep cheating and using q on cocoplum [05:48] time is abused constantly in programming IMO [05:52] pitti: https://launchpad.net/ubuntu/natty/+queue or some other page? [05:52] StevenK: yes [05:53] I suspect it could benefit from some pre-loading [05:54] pitti: It looks okay with 9 -- when does it start timing out? [05:55] StevenK: feels like 10 seconds, yes [05:56] pitti: Sorry, let me be clearer. It looks okay here with 9 items in unapproved. [05:56] StevenK: oh, displaying is fine [05:56] StevenK: it often times out when you accept stuff [05:56] like override in NEW and accept [05:57] and sometimes even UNAPPROVED and accept SRUs, but that's less common [05:57] pitti: Ah, right [05:58] Indeed, bug closure is a bugger, there [05:58] sync bug closure and fixed timeouts just don't work well together [05:59] Bug closure should be faster [05:59] it should be async, or the timeout should disappear [05:59] or be set to something like 5 minutes [05:59] pitti: 5 minutes?! [05:59] pitti: Your browser will give up long before then [06:00] StevenK: launchpadlib won't? [06:00] Doesn't that use curl? [06:00] StevenK: I've seen copy-packge taking a minute for some packages like kernel, ubuntuone, etc. [06:00] Which might, I'm not sure [06:00] making closing bugs twice as fast won't help [06:01] pitti: In the general case -- let me hand wave and say it should always work and not timeout [06:01] Larger packages may present other issues, but for the small package and one or two bugs, it should be snappy. [06:02] pitti: I'm not arguing that we're there right now -- but we *should be* [06:02] it's just that we tend to SRU the kernel more often than any other package :) [06:02] Seeing an OOPS would be helpful [06:02] I think there is a bug about this [06:02] async seems the way to go... [06:02] lifeless: ^ [06:03] a job handle should be returned.. "Ok, I'll do that, you can check status via this job ID:" [06:03] SpamapS: async inside Launchpad is a *lot* of work [06:03] Thats changing is it not? [06:03] "The rabbit has landed" [06:03] Slowly [06:03] StevenK: context? [06:04] One more pebble on the scale.. eventually it will tip. ;) [06:04] lifeless: We have a bug for accepting/rejecting packages from +queue timing out? [06:04] https://bugs.launchpad.net/launchpad-project/+bugs?field.tag=timeout [06:04] or correspondingly, launchnpadlib syncSource() timing out for the same reason [06:04] bug 745799 [06:04] Launchpad bug 745799 in Launchpad itself "DistroSeries:+queue Timeout accepting packages (bug structural subscriptions)" [Critical,Triaged] https://launchpad.net/bugs/745799 [06:04] bug 641338 [06:04] Launchpad bug 641338 in Launchpad itself "Archive:EntryResource:syncSource timeouts" [Critical,Triaged] https://launchpad.net/bugs/641338 [06:04] pitti: patches accepted! [06:05] SpamapS: rabbit makes async lower latency [06:05] "bump timeout to 1 minute"? :-) [06:05] pitti: on POSTS, thats a recipe to make other requests timeout === _LibertyZero is now known as LibertyZero [06:05] pitti: due to lock contention, increased DB bloat and greater request backlogs [06:06] lifeless: but the shell tools on cocoplum take just as long anyway? [06:06] pitti: and cause problems. [06:06] pitti: they will be turned off as soon as we can [06:06] so we usually try a couple of times with +queue or syncSource() and then ssh in and have the command take a minute there [06:06] If we fix the root cause they should both be quick [06:06] lifeless: right, but that's a chicken-egg problem; we desperately need them as long as we have the timeouts [06:06] lifeless: so even doing it "the old way" is hard? [06:07] 1,200 queries looks like death-by-SQL to me [06:07] pitti: and thus those bugs are critical [06:07] I'd have thought by now there's be a nice architecture for anything one wants to do asynchronously. [06:07] SpamapS: there is a tolerable one yes. [06:08] SpamapS: and StevenK's team is working on making package copies be async [06:08] Read as: "I want to commit harikari every time I use it." [06:08] SpamapS: but backend things still have to have timeouts [06:08] Not my team :-P [06:08] StevenK: well, you're seconded, so gnar gnar gnar :P [06:08] lifeless: For another 2.2 days [06:09] oh? cool. [06:09] StevenK: you'll be on timeout patrol then ? [06:09] lifeless: No, disclosure [06:09] StevenK: or disclosure? [06:09] ah, cool [06:09] With the rest of Teal [06:17] lifeless: sure they should have timeouts. I think backend things can justify finer grained timeouts due to the fact that there's no browser spinning waiting on them. [06:17] lifeless: and the fact that one can control just how much impact one will have at any one time [06:21] SpamapS: sure, we have that [06:21] SpamapS: but any timeout that is substantially longer than the lowest timeout we have /will/ cause operational problems. [06:21] SpamapS: so we won't do that. [06:22] we need to fix these problems. [07:19] good morning === smb` is now known as smb [07:59] @pilot out === udevbot_ changed the topic of #ubuntu-devel to: Oneiric Archive: OPEN | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> natty | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: [08:09] hi dbarth, have a moment? [08:29] Hmm [08:29] why wasn't tomcat7 autosynced from unstable? [08:30] Because it's a new package, that's a seperate process [09:03] hey pitti, good morning, thanks for the feedback on universe translations. I've got one last question: one of the approaches we were talking about was whitelisting (either a list within pkgbinarymangler or on the packages themselves using something like "XS-Ubuntu-Use-Langpack"). On the first approach (a list in pkgbinarymangler) you're mentioning that we'd need to maintain the list in Launchpad as well. Why is that? Assuming LP would be modified to acc [09:03] ept universe translation tarballs, would it not just import anything pkgbinarymangler feeds it? [09:03] dpm: but we already build/import all translation tarballs [09:04] dpm: we could of course stop doing so for universe packages [09:04] and only build a translation tar for the whitelisted ones [09:05] pitti, ok, I got you now, I had not taken into account that we're already importing universe translations tarballs [09:05] pitti, "only build a translation tar for the whitelisted ones" <-- yes, that's what I was thinking of [09:06] dpm: WFM [09:10] dpm: followed up with that proposal [09:11] pitti, ah, right, thanks. I'm just writing a reply, let me read yours first... === hunger_ is now known as hunger === chrisccoulson_ is now known as chrisccoulson [09:23] lucidfox: synced now === tkamppeter_ is now known as tkamppeter [10:06] micahg: are you working on the sslsniff FTBFS? [10:14] cjwatson, thanks [10:17] pitti, do you know (off the top of your head) how the udev handoff from initramfs to / is done, i will go look if not [10:19] apw: what is the "udev handoff"? I thought it'd just rebind the /dev mount from initramfs into /root? [10:20] pitti, no i am wondering about how udevd gets replaced by the one in / [10:20] pitti, will go look no worries [10:20] # Move /dev to the real filesystem [10:20] mount -n -o move /dev ${rootmnt}/dev [10:20] # Stop udevd, we'll miss a few events while we run init, but we catch up [10:20] pkill udevd [10:21] t'is that bit i was wondering about, found it now ... basically hoping we hand off in a sensible way, seems not [10:21] I wonder why we need the pkill there [10:22] we basically start it in initramfs, kill it, then start it again from upstart, and do a coldplug trigger [10:22] but can't we reuse the original instance here? [10:23] well the reasoning is that we should get a nice fresh one from / in case it has been updated [10:23] ah, I guess we couldn't atomically do the move mount and tell the udevd process about it [10:23] cjwatson, hmm, do we actually need changes to live-build for jasper ? is there no mode where it just rolls a default initrd and we could have jasper through a seed ? [10:23] though we could bind mount it [10:24] pitti: if you keep the old process, you can never free the initramfs memory [10:24] pitti, cjwatson typically noone else does this as it is exposing an issue with address reuse on the udev control socket [10:24] with the new 170 version [10:25] ogra_: well, there is --initramfs none I guess, though I suspect it will still need some of the same changes as otherwise you end up with boot=none (though I know we aren't currently using the modes where live-build's ideas of kernel parameters matter, but still) [10:25] I can give it a try [10:27] i think that would be nicer than having jasper hardcoded in the build system [10:27] ok, this is why I cced you :-) [10:27] :) [11:08] dpm: is there a separate spec for universe translations? you have three WIs on https://blueprints.launchpad.net/ubuntu/+spec/desktop-o-qin-ubuntu-china which don't seem directly related [11:16] pitti, there isn't a separate spec for universe translations. I put the universe WI there after someone in the UDS discussion mentioned that OEM would like to have more control over the translations they ship for selected universe packages and complete them in langpacks. The discussion then went on on whether these packages should just be promoted to main, or if we don't/can't promote them to main, whether its translations could be imported regardless o [11:16] f them being in universe. I put the WI there as a reminder for me to do the research and provide the results, as an aid to whoever is making the decision or either doing a MIR for those packages or get their translations imported into LP [11:16] dpm: ah, thanks [11:17] pitti, so I'll just summarize your feedback and danilo's, put it in the whiteboard now and mark it as done [11:18] Unless it makes things incredibly more complicated, it would be convenient if a future-looking solution allowed one to provide translations for arbitrary batches of packages (that happen to be in universe), rather than specifically being related to the packages being in universe. [11:18] * cjwatson boots oneiric in a VM [11:18] http://people.canonical.com/~cjwatson/tmp/oneiric.png - new desktop style? :-) [11:19] persia, let me paste the options we've been discussing on the whiteboard in some minutes. We've been discussing something along these lines. [11:19] (I assume this is partly the lack of either a classic session or unity-2d) [11:20] cjwatson: is your gdk-pixbuf loaders.cache empty (0 size)? (do you get messages about unknown image formats?) [11:20] cjwatson: welcome to gnome 3: ) [11:20] dpm, Thanks. Everything I've heard before was along those lines: I just get worried when people start talking about "universe" foo. [11:20] cjwatson: right, gnome-session-fallback needs to be seeded [11:21] geser: already killed the vm [11:21] seb128: ^ btw, there was nothing wrong with my upgrade; it's currently a suggests: of gnome-session, not a recommends [11:21] geser: that got fixed last night, and with that bug you didn't even get to nautilus [11:21] cjwatson: so you got an oneiric live CD to build? nice! [11:21] cjwatson: let me seed it, and rebuild u-meta [11:21] pitti: I managed somehow [11:22] pitti, as per the other 2 WIs, they are basically the same thing: someone asked how we track and fix translations bugs, and how we can improve that. Colin asked me something similar a while ago (to have some guidelines for the bugsquad -or anyone else- on how to report and triage translations bugs), so I added it as an action for me, so I get it done this cycle [11:22] pitti: last night [11:22] didrocks, seb128: hm, so do we want gnome-session to pull in -fallback, or explicitly seed it? [11:22] pitti: so, for alpha1, we will have gnome-session pulling in -fallback [11:22] cjwatson: ok, so the next rebuild should also pick up the pixbuf fix [11:23] didrocks: ok; do you want to do the g-session upload for this, or want me to? [11:23] pitti: so, once gnome-panel is transitionned, it recommends -fallback, and we will remove the dep from gnome-session on -fallback [11:23] pitti: will do it today, once I've managed unity-2d [11:23] pitti, what didrocks says [11:23] hm, that sounds backwards [11:23] pitti, gnome-panel should bring the session corresponding to it in [11:23] shouldn't -fallback depend on gnome-panel, not the other way round? [11:23] pitti: we won't install gnome-panel on oneiric [11:23] but we can't build gnome-panel now that e-d-s is on gtk3 [11:24] sounds like a circular depends indeed [11:24] pitti: that was what we discuss with mvo yesterday on #ubuntu-desktop, we only want gnome-panel for upgrade, not new install [11:24] gnome-session-fallback dep on gnome-panel, but gnome-panel recommends -fallback [11:24] didrocks: ah, I see; and we wouldn't install -fallback, just unity-2d [11:25] pitti: exactly [11:25] ok, then we shouldn't seed it either [11:25] just not possible for alpha1 as gnome-panel (with the new recommends on -fallback) is build-dep waiting [11:25] right [11:41] didrocks, pitti: that's still sort of a circular depends,recommends not sure if that's an issue or not [11:41] the other option would be to ship the session file in gnome-panel [11:42] seb128: hence the fact I asked yesterday with mvo. IIRC, we already have tons of deps <-> recommends relationship like that [11:42] didrocks, ok, great, less work then ;-) [11:42] seb128: yeah, less divergence :-) === MacSlow is now known as MacSlow|lunch === doko_ is now known as doko === MacSlow|lunch is now known as MacSlow === dendro-afk is now known as dendrobates === hallyn_afk is now known as hallyn === dendrobates is now known as dendro-afk [15:21] barry: why does virtualenv point to /usr/share/pyshared at all? [15:45] pitti, seb128: there's a workitem in https://launchpad.net/ubuntu/+spec/desktop-o-gtk3-gnome3 for demoting cheese or writing an MIR for gnome-video-effects. As I understand it, the latter is *just* the effects. [15:45] so is there another reason to demote cheese? [15:45] ev, why is it in main? [15:45] seb128 what, cheese? [15:45] yes [15:45] I'm never clean what's the point to have things which are not on the CD in main [15:45] well, if I dig back up the python bindings and integrate it into the installer, for that :) [15:46] can anyone point me to some good documentation on po-debconf and dh7 ? === dendro-afk is now known as dendrobates [15:46] ok, fine to keep it there, I just figured it would be easier for contributors to work on it if it was in universe [15:46] kirkland: I've generally found the man pages fine [15:46] or, perhaps a source package that does this well already? [15:46] seb128: sure thing, I just wanted to be sure it wasn't going away for some other reason [15:47] cjwatson: interesting approach :-) [15:47] cjwatson: let me dig there [15:47] ev, no, didrocks mentioned that empathy is going to use libcheese as well I think so we will need to keep it in main anyway [15:47] okay, cool [15:47] kirkland: generally you only need to make sure translatable text is marked properly, create debian/po/POTFILES.in, and run debconf-updatepo [15:47] kirkland: you could try e.g. man-db [15:48] cjwatson: yeah, looks like i've been overengineering this [15:48] cjwatson: thanks, manpg.es/po-debconf has what i need ;-) [15:51] pitti, ping [15:52] hey tkamppeter [15:53] cjwatson: do you run debconf-updatepo manually when something changes? or do you do it at build time? release time? [15:53] cjwatson: i don't see a call to debconf-updatepo in your man-db sample, so I presume you run that manually? [15:53] pitti, I have now set up the WIs for the color management Bleuprint, https://blueprints.launchpad.net/ubuntu/+spec/desktop-o-icc-color-management [15:54] pitti, looks all doable for Oneiric. [15:54] mdeslaur: all right, so i think it's time to call in the big guns to try and coax the community into being interseted in implementing netcf for debian :) [15:55] mdeslaur: it looks like so much fun, but i can't responsibly commit to it [15:55] mdeslaur: you were suggesting asking dholbach and who else? [15:55] hallyn: well, let's start with dholbach to see if he has any ideas [15:56] kirkland: manually [15:56] mdeslaur: ok, thanks. he's not in right now it appears, drat. [15:56] kirkland: changes are rare so I don't find it a problem [15:56] kirkland: some packages run it on clean - I find this irritating personally as it keeps resulting in minor changes that cause desync from revision control [15:57] kirkland: (there's a lintian warning for if I forget to run it) [15:57] cjwatson: okay, cool, thanks [15:57] cjwatson: appreciate the advice [15:57] tkamppeter: ah, good; do you want to work on this (i. e. packaging the missing bits, etc.)? [15:59] hallyn: I wonder why the netcf page says networkmanager uses it...AFAICT, it doesn't [16:00] hi [16:00] did someone tested upgrade from evolution 2.32 to 3.x? [16:00] mdeslaur: fedora might have custom patches that aren't upstream? [16:00] or they're lying [16:01] did you know every distro is using.... nm [16:01] hrw: I'm using evo 3 now, yes [16:01] pitti, I will at least allpy all patches to the printing-related packages. [16:01] pitti: I had to move ~/.local/share/evolution to not make it crash [16:02] pitti: now fetching back 1GB of mails [16:02] hrw: my calendars etc. still work; I only have local mail in evo (using offlineimap and mutt) [16:02] pitti, gnome-color-manager seems to be well maintained by Robert Ancell, so he should continue maintaining it also after it got transferred to Main. [16:02] pitti: migration from mbox -> maildir was asked once and then died. no question anymore - just crash [16:03] tkamppeter: ah, sure; the linked bugs should be assigned to persons then (like g-color-manager to Robert, foomatic to you, etc.) [16:03] pitti, I do not know, but perhaps Robert has knowledge about color management and so it could be good if he would also take maintainership on Argyll and colord. [16:06] tkamppeter: ok, let's wait for Robert to come back (he's sick with ubuflu right now) [16:07] pitti, what is ubuflu? [16:07] tkamppeter: the illness which half of the people get at UDS :) [16:08] pitti, so one week of UDS makes him going away for two weeks, not very efficient ... [16:09] shit. evo is crashing like crazy [16:11] pitti, the instructions for MIRs tell to not assign the MIR to anyone, is there any problem then with having a MIR as a WI? [16:11] tkamppeter: ah, leave that one unassigned then [16:12] cyphermox: is it normal that any ~/.local/share/evolution/ contents == crash of evolution in oneiric? [16:12] no [16:12] pitti, robert_ancell is not likely wanting to maintain those [16:12] hrw, any time you have anything in evo you should have stuff in that directory [16:13] cyphermox: I know [16:13] pitti, he didn't want to take on that previous cycles when the topic was discussed and said he would focus on lightdm and step away from maintaining things this cycle [16:13] * pitti nods [16:13] cyphermox: when it is empty then evo starts, asks me to accept ssl cert of my private mail and fetches mails. if I quit and start evo then it crashes [16:13] he's also not maintaining those component because he's interested, he just did some updates because they were updated [16:14] we shouldn't do it if we have nobody interested to maintain the stack [16:14] we have enough other things to deal with already this cycle... [16:14] yeah, we already have 30% more WIs than in natty even without this :/ [16:14] hrw: if you start evo from the command-line, it should probably list what's wrong. something must have not migrated properly [16:15] cyphermox: https://pastebin.linaro.org/95/ [16:15] tkamppeter: if you have time and want to work on it, sounds fine; otherwise it's probably something for the next cycle then [16:15] when we don't have a gnome 3 and lightdm transition to do? [16:15] cyphermox: thats backtrace with evolution-dbg [16:16] cyphermox: http://paste.ubuntu.com/612796/ is whole output of crashing evo [16:17] hrw: can you re-paste what you put in pastebin.linaro.org, I don't have access to that [16:17] oops [16:17] pitti, only problem is that next cycle is LTS. So I will look into starting color management support and if it is not too complex start it and look for distributing maintainership on UDS-P. [16:17] cyphermox: http://paste.ubuntu.com/612797/ [16:18] tkamppeter: right, seems this can be done one step at a time indeed [16:20] hrw: do you use unity? I'm curious if you're not seeing this crash due to the issues we had with gdkpixbuf loaders yesterday? [16:22] cyphermox: xfce [16:22] cyphermox: I avoid unity as it does not fits me [16:22] cyphermox: I did 815MB upgrade today and did not restarted x11 session since that [16:23] ok [16:24] but it should not crash just because of that [16:25] well, the gdk-pixbuf loaders missing do crash evolution :) [16:28] hrw: just to make sure, check that /usr/lib/$(dpkg-architecture -qDEB_HOST_MULTIARCH)/gdk-pixbuf-2.0/2.10.0/loaders.cache isn't zero size [16:29] -rw-r--r-- 1 root root 146 2011-05-25 15:28 /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache [16:29] there is a bug in the package, it lacks a depends on dpkg-dev for dpkg-architecture, I will fix that in a bit [16:29] that seems smaller than it should be [16:30] cyphermox: so it is empty [16:30] only comments inside [16:31] and 17:30 hrw@home:build$ sudo gdk-pixbuf-query-loaders |wc -l [16:31] 139 [16:31] seb128: uh, is this a runtime package? [16:31] cjwatson, it's a postinst [16:31] no update-gdk-pixbufs command anymore? [16:31] seb128: runtime packages need to not depend on dpkg-dev [16:32] hrw: no, that's what gdk-pixbuf-query-loaders does [16:32] how do we get the multiarch dir without that? [16:32] seb128: you could substitute in the output of dpkg-architecture at build time instead [16:32] assuming you're not arch all [16:32] 17:32 root@home:build# gdk-pixbuf-query-loaders >/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache [16:32] and then evo works [16:33] pitti, all bugs of the ICC Blueprint are assigned to me now, so now everything on this Blueprint should be OK now. [16:33] a runtime dependency on dpkg-dev is a multi-megabyte CD size penalty (or will be once I get lintian adjusted) [16:35] cjwatson, can we get something in the standard install that gives you the multiarch directory? [16:35] having to sed .in files during the build for that is annoying and as you pointed doesn't work in arch all cases [16:35] seb128: -> slangasek [16:35]