| === robbiew is now known as robbiew_ | ||
| broder | kees: is liberal application of polkit not sufficient for solving the apport issue? | 00:50 |
|---|---|---|
| kees | broder: dunno, frankly. pkexec is kinda crazy | 00:51 |
| broder | (it seems like polkit is less of an awful hack than gksu and friends) | 00:51 |
| broder | 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 |
| Keybuk | isn't polkit going away? | 00:55 |
| Keybuk | I can't remember | 00:55 |
| broder | it is? | 00:55 |
| broder | that's news to me, but i could be underinformed | 00:55 |
| micahg | the only think I heard about it going away was being folded into systemd | 00:56 |
| ScottK | 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 |
| slangasek | heh | 00:56 |
| james_w | consolekit is going away | 00:58 |
| slangasek | well, no | 00:58 |
| slangasek | that's yet to be seen | 00:58 |
| james_w | ok, some people want it to go away :-) | 00:59 |
| slangasek | it's not going to be used in Fedora, but Ubuntu isn't going to switch to systemd any time soon | 00:59 |
| broder | that makes a bit more sense, at least | 00:59 |
| broder | consolekit always seemed like a bit of a solution looking for a grand vision that wasn't materializing | 00:59 |
| ScottK | 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:00 |
| broder | i'm still waiting for KitKit :-P | 01:01 |
| Keybuk | KitKit does exist | 01:01 |
| broder | ...wait, seriously? | 01:01 |
| micahg | ScottK: wkhtml2pdf? | 01:01 |
| ScottK | You've got to have one kit to rule them all. | 01:01 |
| Keybuk | it was what Lennart was going to write to replace libnih | 01:01 |
| Keybuk | but he seems to just copy&paste | 01:01 |
| SpamapS | kitkit was created by the Department of Redundancy Dept. | 01:01 |
| ScottK | micahg: Sounds right. | 01:01 |
| ScottK | micahg: Have you used it? | 01:02 |
| Keybuk | ScottK: to be fair, if I was rendering content, I would probably use webkit for layout too | 01:02 |
| ScottK | Keybuk: Sure. I just don't like having such a steaming heap of security vulnerabilities even installed on an internet facing server. | 01:02 |
| micahg | 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:02 |
| Keybuk | ScottK: I would not describe WebKit as such | 01:03 |
| slangasek | cjwatson: is bug #425979 tractable? | 01:03 |
| ubottu | Launchpad bug 425979 in grub2 (Ubuntu) "Holding shift fails to display grub2 menu" [Undecided,Confirmed] https://launchpad.net/bugs/425979 | 01:03 |
| ScottK | Keybuk: It's entirely possible I am being unfair. | 01:03 |
| Keybuk | it's had roughly the same number of CVEs in recent history as TeX, for example | 01:03 |
| ScottK | 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 |
| kees | Keybuk: did you just imply that webkit has as many CVEs as TeX? | 01:05 |
| * kees can't tell if that's intentional trolling or not :) (270 vs 19) | 01:07 | |
| Keybuk | kees: in recent history ;) | 01:08 |
| cjwatson | 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 | |
| cjwatson | slangasek: but didn't quite finish that off | 01:08 |
| Keybuk | kees: though webkit is cross-platform, and I was just looking at LWN | 01:09 |
| ScottK | Kind of interesting in a not really, but they're talking about us, way. | 01:09 |
| cjwatson | slangasek: I doubt it's tractable otherwise | 01:09 |
| slangasek | cjwatson: ok | 01:10 |
| cjwatson | 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:11 |
| slangasek | heh | 01:12 |
| kees | Keybuk: in recent history. 5 months. webkit: 64. TeX: 1 | 01:14 |
| Keybuk | kees: clearly webkit is better maintained ;-) | 01:15 |
| kees | ScottK: yeah, I had a chat with Jeff Jones when he first published that | 01:15 |
| kees | Keybuk: that's one way to look at it ;) | 01:16 |
| === bryceh is now known as bryce | ||
| andersk | 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:18 |
| slangasek | so I wonder why binfmt-misc + suid seems to fail | 01:21 |
| TheMuso | 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:23 |
| andersk | slangasek: Did you use the 'C' flag? See bug 519228. | 01:24 |
| ubottu | Launchpad bug 519228 in binfmt-support (Ubuntu) "Support for C flag" [Undecided,Fix released] https://launchpad.net/bugs/519228 | 01:24 |
| slangasek | andersk: I used the qemu flag | 01:24 |
| micahg | andersk: yeah, I just asked in -desktop if anyone wants to fix it | 01:25 |
| slangasek | andersk: /usr/share/binfmts/qemu-arm does have flags: OC | 01:25 |
| === rickspencer3_ is now known as rickspencer3 | ||
| psusi | 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:38 |
| micahg | slangasek: we should be migrating away from non-multiarch paths instead of suppressing errors about the dir not found, right? | 01:45 |
| andersk | (Where “migrating away” means “dropping support now even though some packages still use the old paths”?) | 01:47 |
| slangasek | micahg: I don't understand what errors you're referring to | 01:48 |
| micahg | 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:49 |
| slangasek | micahg: ah, no, we definitely need to look in both the old and new dirs on a transitional basis | 01:51 |
| micahg | slangasek: and suppress errors if the old dir doesn't exist? | 01:51 |
| slangasek | that would be reasonable | 01:52 |
| slangasek | I hadn't bothered to do that with glib2.0 or gdk-pixbuf, for instance | 01:52 |
| slangasek | so upgrades are a little noisier right now... but suppressing those would also be fine | 01:52 |
| micahg | 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:55 |
| slangasek | micahg: also perfectly reasonable | 01:56 |
| slangasek | provided the cache is line-based and you can do an append | 01:56 |
| micahg | appears to be so | 01:56 |
| broder | maco: the link in your blog post doesn't seem to work for me | 01:57 |
| broder | i get a 404 | 01:57 |
| maco | crap | 01:58 |
| maco | thanks | 01:58 |
| maco | broder: what about https://spreadsheets.google.com/spreadsheet/viewform?formkey=dGRLSmxTQ05VYzh6NmdBN3BsakhpM3c6MQ#gid=0 ? | 01:58 |
| broder | maco: wfm | 01:58 |
| maco | ok thanks | 01:58 |
| broder | 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 |
| micahg | slangasek: thanks, I think we'll go with andersk's solution as it matches the other package (gdk-pixbuf) | 01:59 |
| maco | bradm: haha | 01:59 |
| maco | er? | 02:00 |
| maco | broder: haha | 02:00 |
| maco | bradm: not you | 02:00 |
| slangasek | 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 |
| broder | maco: (i'm pretty sure i've installed ubuntu in all of the ways you list at one point or another) | 02:00 |
| maco | broder: its there so that on the "rate the ubuntu installer" part, its possible to tell which one they're referring to | 02:00 |
| maco | surveys have textboxes for a reason ;) | 02:01 |
| broder | 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:01 |
| micahg | slangasek: ok, maybe later, thanks | 02:03 |
| TheMuso | c | 02:08 |
| hallyn | 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:13 |
| persia | 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:34 |
| hallyn | persia: thanks (in that case i guess i'll do that tomorrow) | 02:40 |
| === asac_ is now known as asac | ||
| === hallyn is now known as hallyn_afk | ||
| === nigelb_ is now known as nigelb | ||
| qchn | Happy Towelday! \o/ | 05:24 |
| pitti | Good morning | 05:28 |
| SpamapS | pitti: I did some more sru-release's .. all > 7 days and verification-done .. | 05:41 |
| SpamapS | pitti: and I did sru-release -d natty fwts just now to copy it to oneiric | 05:41 |
| pitti | SpamapS: ah, good; working well for you then? | 05:42 |
| SpamapS | pitti: yes, its perfect. :) | 05:42 |
| pitti | SpamapS: it tends to time out for big packages | 05:42 |
| pitti | well, not the script, but Launchpad | 05:42 |
| pitti | those will need to be done on cocoplum | 05:43 |
| pitti | but for the majority it should work indeed | 05:43 |
| SpamapS | pitti: is there a bug open for launchpad then? Thats one time where a timeout exception should be made. | 05:44 |
| StevenK | pitti: Still? | 05:45 |
| pitti | SpamapS: I asked for bumping the timeout for this as well as the +queue page, but they didn't like that | 05:45 |
| pitti | StevenK: have you used the +queue pages? | 05:46 |
| pitti | sometimes you have to try and binNEW or accept from unapproved four times, and for some it just never works | 05:46 |
| SpamapS | pitti: the other option would be to make it asynchronous | 05:46 |
| pitti | AFAIR the primary problem that has a linear or higher time behaviour is the closing of the bugs | 05:47 |
| pitti | that should indeed happen async | 05:47 |
| pitti | well, that, or the timeout should scale with the number of bugs | 05:47 |
| SpamapS | I think the former is simpler | 05:47 |
| StevenK | pitti: I keep cheating and using q on cocoplum | 05:48 |
| SpamapS | time is abused constantly in programming IMO | 05:48 |
| StevenK | pitti: https://launchpad.net/ubuntu/natty/+queue or some other page? | 05:52 |
| pitti | StevenK: yes | 05:52 |
| StevenK | I suspect it could benefit from some pre-loading | 05:53 |
| StevenK | pitti: It looks okay with 9 -- when does it start timing out? | 05:54 |
| pitti | StevenK: feels like 10 seconds, yes | 05:55 |
| StevenK | pitti: Sorry, let me be clearer. It looks okay here with 9 items in unapproved. | 05:56 |
| pitti | StevenK: oh, displaying is fine | 05:56 |
| pitti | StevenK: it often times out when you accept stuff | 05:56 |
| pitti | like override in NEW and accept | 05:56 |
| pitti | and sometimes even UNAPPROVED and accept SRUs, but that's less common | 05:57 |
| StevenK | pitti: Ah, right | 05:57 |
| StevenK | Indeed, bug closure is a bugger, there | 05:58 |
| pitti | sync bug closure and fixed timeouts just don't work well together | 05:58 |
| StevenK | Bug closure should be faster | 05:59 |
| pitti | it should be async, or the timeout should disappear | 05:59 |
| pitti | or be set to something like 5 minutes | 05:59 |
| StevenK | pitti: 5 minutes?! | 05:59 |
| StevenK | pitti: Your browser will give up long before then | 05:59 |
| pitti | StevenK: launchpadlib won't? | 06:00 |
| StevenK | Doesn't that use curl? | 06:00 |
| pitti | StevenK: I've seen copy-packge taking a minute for some packages like kernel, ubuntuone, etc. | 06:00 |
| StevenK | Which might, I'm not sure | 06:00 |
| pitti | making closing bugs twice as fast won't help | 06:00 |
| StevenK | pitti: In the general case -- let me hand wave and say it should always work and not timeout | 06:01 |
| StevenK | Larger packages may present other issues, but for the small package and one or two bugs, it should be snappy. | 06:01 |
| StevenK | pitti: I'm not arguing that we're there right now -- but we *should be* | 06:02 |
| pitti | it's just that we tend to SRU the kernel more often than any other package :) | 06:02 |
| StevenK | Seeing an OOPS would be helpful | 06:02 |
| StevenK | I think there is a bug about this | 06:02 |
| SpamapS | async seems the way to go... | 06:02 |
| StevenK | lifeless: ^ | 06:02 |
| SpamapS | a job handle should be returned.. "Ok, I'll do that, you can check status via this job ID:" | 06:03 |
| StevenK | SpamapS: async inside Launchpad is a *lot* of work | 06:03 |
| SpamapS | Thats changing is it not? | 06:03 |
| SpamapS | "The rabbit has landed" | 06:03 |
| StevenK | Slowly | 06:03 |
| lifeless | StevenK: context? | 06:03 |
| SpamapS | One more pebble on the scale.. eventually it will tip. ;) | 06:04 |
| StevenK | lifeless: We have a bug for accepting/rejecting packages from +queue timing out? | 06:04 |
| lifeless | https://bugs.launchpad.net/launchpad-project/+bugs?field.tag=timeout | 06:04 |
| pitti | or correspondingly, launchnpadlib syncSource() timing out for the same reason | 06:04 |
| lifeless | bug 745799 | 06:04 |
| ubottu | Launchpad bug 745799 in Launchpad itself "DistroSeries:+queue Timeout accepting packages (bug structural subscriptions)" [Critical,Triaged] https://launchpad.net/bugs/745799 | 06:04 |
| lifeless | bug 641338 | 06:04 |
| ubottu | Launchpad bug 641338 in Launchpad itself "Archive:EntryResource:syncSource timeouts" [Critical,Triaged] https://launchpad.net/bugs/641338 | 06:04 |
| lifeless | pitti: patches accepted! | 06:04 |
| lifeless | SpamapS: rabbit makes async lower latency | 06:05 |
| pitti | "bump timeout to 1 minute"? :-) | 06:05 |
| lifeless | pitti: on POSTS, thats a recipe to make other requests timeout | 06:05 |
| === _LibertyZero is now known as LibertyZero | ||
| lifeless | pitti: due to lock contention, increased DB bloat and greater request backlogs | 06:05 |
| pitti | lifeless: but the shell tools on cocoplum take just as long anyway? | 06:06 |
| lifeless | pitti: and cause problems. | 06:06 |
| lifeless | pitti: they will be turned off as soon as we can | 06:06 |
| pitti | 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 |
| StevenK | If we fix the root cause they should both be quick | 06:06 |
| pitti | lifeless: right, but that's a chicken-egg problem; we desperately need them as long as we have the timeouts | 06:06 |
| SpamapS | lifeless: so even doing it "the old way" is hard? | 06:06 |
| StevenK | 1,200 queries looks like death-by-SQL to me | 06:07 |
| lifeless | pitti: and thus those bugs are critical | 06:07 |
| SpamapS | I'd have thought by now there's be a nice architecture for anything one wants to do asynchronously. | 06:07 |
| lifeless | SpamapS: there is a tolerable one yes. | 06:07 |
| lifeless | SpamapS: and StevenK's team is working on making package copies be async | 06:08 |
| StevenK | Read as: "I want to commit harikari every time I use it." | 06:08 |
| lifeless | SpamapS: but backend things still have to have timeouts | 06:08 |
| StevenK | Not my team :-P | 06:08 |
| lifeless | StevenK: well, you're seconded, so gnar gnar gnar :P | 06:08 |
| StevenK | lifeless: For another 2.2 days | 06:08 |
| lifeless | oh? cool. | 06:09 |
| lifeless | StevenK: you'll be on timeout patrol then ? | 06:09 |
| StevenK | lifeless: No, disclosure | 06:09 |
| lifeless | StevenK: or disclosure? | 06:09 |
| lifeless | ah, cool | 06:09 |
| StevenK | With the rest of Teal | 06:09 |
| SpamapS | 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 |
| SpamapS | lifeless: and the fact that one can control just how much impact one will have at any one time | 06:17 |
| lifeless | SpamapS: sure, we have that | 06:21 |
| lifeless | SpamapS: but any timeout that is substantially longer than the lowest timeout we have /will/ cause operational problems. | 06:21 |
| lifeless | SpamapS: so we won't do that. | 06:21 |
| lifeless | we need to fix these problems. | 06:22 |
| didrocks | good morning | 07:19 |
| === smb` is now known as smb | ||
| smb | @pilot out | 07:59 |
| === 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: | ||
| Tm_T | hi dbarth, have a moment? | 08:09 |
| lucidfox | Hmm | 08:29 |
| lucidfox | why wasn't tomcat7 autosynced from unstable? | 08:29 |
| StevenK | Because it's a new package, that's a seperate process | 08:30 |
| dpm | 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 |
| dpm | ept universe translation tarballs, would it not just import anything pkgbinarymangler feeds it? | 09:03 |
| pitti | dpm: but we already build/import all translation tarballs | 09:03 |
| pitti | dpm: we could of course stop doing so for universe packages | 09:04 |
| pitti | and only build a translation tar for the whitelisted ones | 09:04 |
| dpm | pitti, ok, I got you now, I had not taken into account that we're already importing universe translations tarballs | 09:05 |
| dpm | pitti, "only build a translation tar for the whitelisted ones" <-- yes, that's what I was thinking of | 09:05 |
| pitti | dpm: WFM | 09:06 |
| pitti | dpm: followed up with that proposal | 09:10 |
| dpm | pitti, ah, right, thanks. I'm just writing a reply, let me read yours first... | 09:11 |
| === hunger_ is now known as hunger | ||
| === chrisccoulson_ is now known as chrisccoulson | ||
| cjwatson | lucidfox: synced now | 09:23 |
| === tkamppeter_ is now known as tkamppeter | ||
| cjwatson | micahg: are you working on the sslsniff FTBFS? | 10:06 |
| lucidfox | cjwatson, thanks | 10:14 |
| apw | 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:17 |
| pitti | apw: what is the "udev handoff"? I thought it'd just rebind the /dev mount from initramfs into /root? | 10:19 |
| apw | pitti, no i am wondering about how udevd gets replaced by the one in / | 10:20 |
| apw | pitti, will go look no worries | 10:20 |
| pitti | # Move /dev to the real filesystem | 10:20 |
| pitti | mount -n -o move /dev ${rootmnt}/dev | 10:20 |
| apw | # Stop udevd, we'll miss a few events while we run init, but we catch up | 10:20 |
| apw | pkill udevd | 10:20 |
| apw | t'is that bit i was wondering about, found it now ... basically hoping we hand off in a sensible way, seems not | 10:21 |
| pitti | I wonder why we need the pkill there | 10:21 |
| pitti | we basically start it in initramfs, kill it, then start it again from upstart, and do a coldplug trigger | 10:22 |
| pitti | but can't we reuse the original instance here? | 10:22 |
| apw | well the reasoning is that we should get a nice fresh one from / in case it has been updated | 10:23 |
| pitti | ah, I guess we couldn't atomically do the move mount and tell the udevd process about it | 10:23 |
| ogra_ | 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 |
| apw | though we could bind mount it | 10:23 |
| cjwatson | pitti: if you keep the old process, you can never free the initramfs memory | 10:24 |
| apw | pitti, cjwatson typically noone else does this as it is exposing an issue with address reuse on the udev control socket | 10:24 |
| apw | with the new 170 version | 10:24 |
| cjwatson | 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 |
| cjwatson | I can give it a try | 10:25 |
| ogra_ | i think that would be nicer than having jasper hardcoded in the build system | 10:27 |
| cjwatson | ok, this is why I cced you :-) | 10:27 |
| ogra_ | :) | 10:27 |
| pitti | 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:08 |
| dpm | 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 |
| dpm | 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 |
| pitti | dpm: ah, thanks | 11:16 |
| dpm | pitti, so I'll just summarize your feedback and danilo's, put it in the whiteboard now and mark it as done | 11:17 |
| persia | 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 | |
| cjwatson | http://people.canonical.com/~cjwatson/tmp/oneiric.png - new desktop style? :-) | 11:18 |
| dpm | 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 |
| cjwatson | (I assume this is partly the lack of either a classic session or unity-2d) | 11:19 |
| geser | cjwatson: is your gdk-pixbuf loaders.cache empty (0 size)? (do you get messages about unknown image formats?) | 11:20 |
| pitti | cjwatson: welcome to gnome 3: ) | 11:20 |
| persia | dpm, Thanks. Everything I've heard before was along those lines: I just get worried when people start talking about "universe" foo. | 11:20 |
| pitti | cjwatson: right, gnome-session-fallback needs to be seeded | 11:20 |
| cjwatson | geser: already killed the vm | 11:21 |
| pitti | seb128: ^ btw, there was nothing wrong with my upgrade; it's currently a suggests: of gnome-session, not a recommends | 11:21 |
| pitti | geser: that got fixed last night, and with that bug you didn't even get to nautilus | 11:21 |
| pitti | cjwatson: so you got an oneiric live CD to build? nice! | 11:21 |
| pitti | cjwatson: let me seed it, and rebuild u-meta | 11:21 |
| geser | pitti: I managed somehow | 11:21 |
| dpm | 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 |
| cjwatson | pitti: last night | 11:22 |
| pitti | didrocks, seb128: hm, so do we want gnome-session to pull in -fallback, or explicitly seed it? | 11:22 |
| didrocks | pitti: so, for alpha1, we will have gnome-session pulling in -fallback | 11:22 |
| pitti | cjwatson: ok, so the next rebuild should also pick up the pixbuf fix | 11:22 |
| pitti | didrocks: ok; do you want to do the g-session upload for this, or want me to? | 11:23 |
| didrocks | pitti: so, once gnome-panel is transitionned, it recommends -fallback, and we will remove the dep from gnome-session on -fallback | 11:23 |
| didrocks | pitti: will do it today, once I've managed unity-2d | 11:23 |
| seb128 | pitti, what didrocks says | 11:23 |
| pitti | hm, that sounds backwards | 11:23 |
| seb128 | pitti, gnome-panel should bring the session corresponding to it in | 11:23 |
| pitti | shouldn't -fallback depend on gnome-panel, not the other way round? | 11:23 |
| didrocks | pitti: we won't install gnome-panel on oneiric | 11:23 |
| seb128 | but we can't build gnome-panel now that e-d-s is on gtk3 | 11:23 |
| seb128 | sounds like a circular depends indeed | 11:24 |
| didrocks | pitti: that was what we discuss with mvo yesterday on #ubuntu-desktop, we only want gnome-panel for upgrade, not new install | 11:24 |
| didrocks | gnome-session-fallback dep on gnome-panel, but gnome-panel recommends -fallback | 11:24 |
| pitti | didrocks: ah, I see; and we wouldn't install -fallback, just unity-2d | 11:24 |
| didrocks | pitti: exactly | 11:25 |
| pitti | ok, then we shouldn't seed it either | 11:25 |
| didrocks | just not possible for alpha1 as gnome-panel (with the new recommends on -fallback) is build-dep waiting | 11:25 |
| didrocks | right | 11:25 |
| seb128 | didrocks, pitti: that's still sort of a circular depends,recommends not sure if that's an issue or not | 11:41 |
| seb128 | the other option would be to ship the session file in gnome-panel | 11:41 |
| didrocks | seb128: hence the fact I asked yesterday with mvo. IIRC, we already have tons of deps <-> recommends relationship like that | 11:42 |
| seb128 | didrocks, ok, great, less work then ;-) | 11:42 |
| didrocks | seb128: yeah, less divergence :-) | 11:42 |
| === 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 | ||
| doko | barry: why does virtualenv point to /usr/share/pyshared at all? | 15:21 |
| ev | 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 |
| ev | so is there another reason to demote cheese? | 15:45 |
| seb128 | ev, why is it in main? | 15:45 |
| ev | seb128 what, cheese? | 15:45 |
| seb128 | yes | 15:45 |
| seb128 | I'm never clean what's the point to have things which are not on the CD in main | 15:45 |
| ev | well, if I dig back up the python bindings and integrate it into the installer, for that :) | 15:45 |
| kirkland | can anyone point me to some good documentation on po-debconf and dh7 ? | 15:46 |
| === dendro-afk is now known as dendrobates | ||
| seb128 | 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 |
| cjwatson | kirkland: I've generally found the man pages fine | 15:46 |
| kirkland | or, perhaps a source package that does this well already? | 15:46 |
| ev | seb128: sure thing, I just wanted to be sure it wasn't going away for some other reason | 15:46 |
| kirkland | cjwatson: interesting approach :-) | 15:47 |
| kirkland | cjwatson: let me dig there | 15:47 |
| seb128 | 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 |
| ev | okay, cool | 15:47 |
| cjwatson | kirkland: generally you only need to make sure translatable text is marked properly, create debian/po/POTFILES.in, and run debconf-updatepo | 15:47 |
| cjwatson | kirkland: you could try e.g. man-db | 15:47 |
| kirkland | cjwatson: yeah, looks like i've been overengineering this | 15:48 |
| kirkland | cjwatson: thanks, manpg.es/po-debconf has what i need ;-) | 15:48 |
| tkamppeter | pitti, ping | 15:51 |
| pitti | hey tkamppeter | 15:52 |
| kirkland | cjwatson: do you run debconf-updatepo manually when something changes? or do you do it at build time? release time? | 15:53 |
| kirkland | cjwatson: i don't see a call to debconf-updatepo in your man-db sample, so I presume you run that manually? | 15:53 |
| tkamppeter | 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:53 |
| tkamppeter | pitti, looks all doable for Oneiric. | 15:54 |
| hallyn | 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:54 |
| hallyn | mdeslaur: it looks like so much fun, but i can't responsibly commit to it | 15:55 |
| hallyn | mdeslaur: you were suggesting asking dholbach and who else? | 15:55 |
| mdeslaur | hallyn: well, let's start with dholbach to see if he has any ideas | 15:55 |
| cjwatson | kirkland: manually | 15:56 |
| hallyn | mdeslaur: ok, thanks. he's not in right now it appears, drat. | 15:56 |
| cjwatson | kirkland: changes are rare so I don't find it a problem | 15:56 |
| cjwatson | 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:56 |
| cjwatson | kirkland: (there's a lintian warning for if I forget to run it) | 15:57 |
| kirkland | cjwatson: okay, cool, thanks | 15:57 |
| kirkland | cjwatson: appreciate the advice | 15:57 |
| pitti | tkamppeter: ah, good; do you want to work on this (i. e. packaging the missing bits, etc.)? | 15:57 |
| mdeslaur | hallyn: I wonder why the netcf page says networkmanager uses it...AFAICT, it doesn't | 15:59 |
| hrw | hi | 16:00 |
| hrw | did someone tested upgrade from evolution 2.32 to 3.x? | 16:00 |
| hallyn | mdeslaur: fedora might have custom patches that aren't upstream? | 16:00 |
| hallyn | or they're lying | 16:00 |
| hallyn | did you know every distro is using.... nm | 16:01 |
| pitti | hrw: I'm using evo 3 now, yes | 16:01 |
| tkamppeter | pitti, I will at least allpy all patches to the printing-related packages. | 16:01 |
| hrw | pitti: I had to move ~/.local/share/evolution to not make it crash | 16:01 |
| hrw | pitti: now fetching back 1GB of mails | 16:02 |
| pitti | hrw: my calendars etc. still work; I only have local mail in evo (using offlineimap and mutt) | 16:02 |
| tkamppeter | 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 |
| hrw | pitti: migration from mbox -> maildir was asked once and then died. no question anymore - just crash | 16:02 |
| pitti | tkamppeter: ah, sure; the linked bugs should be assigned to persons then (like g-color-manager to Robert, foomatic to you, etc.) | 16:03 |
| tkamppeter | 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:03 |
| pitti | tkamppeter: ok, let's wait for Robert to come back (he's sick with ubuflu right now) | 16:06 |
| tkamppeter | pitti, what is ubuflu? | 16:07 |
| pitti | tkamppeter: the illness which half of the people get at UDS :) | 16:07 |
| tkamppeter | pitti, so one week of UDS makes him going away for two weeks, not very efficient ... | 16:08 |
| hrw | shit. evo is crashing like crazy | 16:09 |
| tkamppeter | 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 |
| pitti | tkamppeter: ah, leave that one unassigned then | 16:11 |
| hrw | cyphermox: is it normal that any ~/.local/share/evolution/ contents == crash of evolution in oneiric? | 16:12 |
| cyphermox | no | 16:12 |
| seb128 | pitti, robert_ancell is not likely wanting to maintain those | 16:12 |
| cyphermox | hrw, any time you have anything in evo you should have stuff in that directory | 16:12 |
| hrw | cyphermox: I know | 16:13 |
| seb128 | 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 | |
| hrw | 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 |
| seb128 | he's also not maintaining those component because he's interested, he just did some updates because they were updated | 16:13 |
| seb128 | we shouldn't do it if we have nobody interested to maintain the stack | 16:14 |
| seb128 | we have enough other things to deal with already this cycle... | 16:14 |
| pitti | yeah, we already have 30% more WIs than in natty even without this :/ | 16:14 |
| cyphermox | hrw: if you start evo from the command-line, it should probably list what's wrong. something must have not migrated properly | 16:14 |
| hrw | cyphermox: https://pastebin.linaro.org/95/ | 16:15 |
| pitti | 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 |
| pitti | when we don't have a gnome 3 and lightdm transition to do? | 16:15 |
| hrw | cyphermox: thats backtrace with evolution-dbg | 16:15 |
| hrw | cyphermox: http://paste.ubuntu.com/612796/ is whole output of crashing evo | 16:16 |
| cyphermox | hrw: can you re-paste what you put in pastebin.linaro.org, I don't have access to that | 16:17 |
| hrw | oops | 16:17 |
| tkamppeter | 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 |
| hrw | cyphermox: http://paste.ubuntu.com/612797/ | 16:17 |
| pitti | tkamppeter: right, seems this can be done one step at a time indeed | 16:18 |
| cyphermox | 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:20 |
| hrw | cyphermox: xfce | 16:22 |
| hrw | cyphermox: I avoid unity as it does not fits me | 16:22 |
| hrw | cyphermox: I did 815MB upgrade today and did not restarted x11 session since that | 16:22 |
| cyphermox | ok | 16:23 |
| hrw | but it should not crash just because of that | 16:24 |
| cyphermox | well, the gdk-pixbuf loaders missing do crash evolution :) | 16:25 |
| cyphermox | 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:28 |
| hrw | -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 |
| seb128 | 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 |
| seb128 | that seems smaller than it should be | 16:29 |
| hrw | cyphermox: so it is empty | 16:30 |
| hrw | only comments inside | 16:30 |
| hrw | and 17:30 hrw@home:build$ sudo gdk-pixbuf-query-loaders |wc -l | 16:31 |
| hrw | 139 | 16:31 |
| cjwatson | seb128: uh, is this a runtime package? | 16:31 |
| seb128 | cjwatson, it's a postinst | 16:31 |
| hrw | no update-gdk-pixbufs command anymore? | 16:31 |
| cjwatson | seb128: runtime packages need to not depend on dpkg-dev | 16:31 |
| cyphermox | hrw: no, that's what gdk-pixbuf-query-loaders does | 16:32 |
| seb128 | how do we get the multiarch dir without that? | 16:32 |
| cjwatson | seb128: you could substitute in the output of dpkg-architecture at build time instead | 16:32 |
| cjwatson | assuming you're not arch all | 16:32 |
| hrw | 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 |
| hrw | and then evo works | 16:32 |
| tkamppeter | pitti, all bugs of the ICC Blueprint are assigned to me now, so now everything on this Blueprint should be OK now. | 16:33 |
| cjwatson | a runtime dependency on dpkg-dev is a multi-megabyte CD size penalty (or will be once I get lintian adjusted) | 16:33 |
| seb128 | cjwatson, can we get something in the standard install that gives you the multiarch directory? | 16:35 |
| seb128 | 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 |
| cjwatson | seb128: -> slangasek | 16:35 |
| seb128 | slangasek, ^ | 16:35 |
| cjwatson | (I believe there was some discussion of that in the context of the FHS/LSB) | 16:36 |
| seb128 | cjwatson, but noted, no dpkg-dev depends | 16:36 |
| === dendrobates is now known as dendro-afk | ||
| apw | can anyone remind me what determines which architectures a source package will attempt to build. i am naievly expecting it to be the union of all of the Architecture: lines | 16:48 |
| Laney | I believe it is for all archictures, unless overridden by the Packages-arch-specific file | 16:48 |
| slangasek | seb128: yeah, no good solution for that yet :( as cjwatson says, we want to avoid a runtime dep on dpkg-dev for dpkg-architecture | 16:49 |
| seb128 | slangasek, can you fix librsvg then to use something at build time when you have some time then? ;-) | 16:49 |
| slangasek | seb128: is this in an arch: all package, or is the problem the maintenance inconvenience of having to postprocess the maintainer scripts? | 16:50 |
| slangasek | yeah | 16:50 |
| tkamppeter | pitti, still there? | 16:51 |
| seb128 | slangasek, not, it's just that I went for what was easy to do since that was late yesterday evening and I wanted to fix the issue of the empty cache breaking loaders before going to bed | 16:51 |
| slangasek | yep | 16:51 |
| seb128 | slangasek, I'm not sure what the's best way to do it dynamically at build time so if you have a clue please do it ;-) | 16:51 |
| slangasek | will fix it up today | 16:51 |
| pitti | tkamppeter: yes (was typing a long email sermon) | 16:51 |
| slangasek | I have an example or two of this on my hard drive at the moment :P | 16:52 |
| tkamppeter | pitti, is all OK with the ICC Blueprint now? | 16:52 |
| pitti | tkamppeter: should be, yes; I'll accept it, but as we discussed don't worry if you don't get to it; it's still a target of opportunity | 16:53 |
| apw | Laney, is that file available somewhere for viewing? | 16:57 |
| tkamppeter | pitti, OK and thanks for your help. | 16:57 |
| === steveire_ is now known as steveire | ||
| Laney | apw: http://anonscm.debian.org/gitweb/?p=mirror/packages-arch-specific.git;a=blob_plain;f=Packages-arch-specific;h=f654079cf2f07e7a7b6253d3762ee13c9b92380e;hb=HEAD | 17:00 |
| persia | Don't we have a separate copy of that in Launchpad now? I thought there was some kerfluffle in 2009 about it. | 17:02 |
| apw | yeah we seem to have a bzr branch for it | 17:02 |
| Laney | I thought it was a mirror | 17:02 |
| Laney | and git.d.o happened to be handier to retrieve, but ymmv :-) | 17:03 |
| cjwatson | https://code.launchpad.net/~ubuntu-core-dev/packages-arch-specific/ubuntu is what's actually deployed for Ubuntu | 17:04 |
| cjwatson | it's a (not very large) branch | 17:04 |
| cjwatson | off a bzr mirror of the Debian git branch, of course | 17:04 |
| apw | cjwatson, is that the only thing which defines which arches build things, as i don't see anything for linux-lts-backports-maverick and that builds on amd64 i386 and all only | 17:05 |
| persia | apw: There's also the Architecture: bit in the packages, and some oddities if one uploads to a virtualised PPA and pocket-copies | 17:06 |
| cjwatson | yeah, it's basically because you have Architecture: amd64 i386 | 17:06 |
| apw | so that makes sense, a new package in the ckt PPA (the natty lts backport) has errored on all the other architectures and i'd not expect it to have done so | 17:07 |
| cjwatson | if it's failing on architectures you don't care about, just ignore it | 17:07 |
| cjwatson | not worth worrying about | 17:08 |
| apw | it seems identicle in Architecture: configuration to the other and yet behaving different | 17:08 |
| apw | ok | 17:08 |
| Daviey | I know last year there was an issue with linux-any | 17:13 |
| cjwatson | apw: yeah, probably tedious differences between real archive and PPAs | 17:13 |
| cjwatson | Daviey: I believe that to be sorted | 17:13 |
| Daviey | yeah, it is now | 17:13 |
| === bregma_ is now known as bregma|break | ||
| === dendro-afk is now known as dendrobates | ||
| rsalveti | is there a way to get notifications for new ftbfs entries? | 17:32 |
| rsalveti | I'll be helping filling and triaging ftbfs bugs for arm | 17:32 |
| === dendrobates is now known as dendro-afk | ||
| dmart | doko, barry: Hi there ... I've been looking into an "exceptions bootstrapping error" which occurs when libpython is used to embed an interpreter in another application -- specifically, this causes adonthell to ftbfs | 17:47 |
| dmart | I've tracked this down to a failed sanity check in PyType_Ready, called from _PyExc_Init | 17:48 |
| stgraber | @pilot in | 17:49 |
| === 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: stgraber | ||
| dmart | The failure happens on the call PRE_INIT(BaseException) at Objects/exceptions.c:2080 | 17:50 |
| dmart | (in python2.6-2.6.6) | 17:50 |
| stgraber | cjwatson: hey, while I think of it. Remember the edubuntu-live package at UDS? I uploaded it in Oneiric but can't find it available for translation on LP, did I forget to do something so that it shows up there? | 17:50 |
| dmart | doko, barry: ^ any thoughts about what's going on / what I should be looking at? AFAIK this failure has only been seen on armel, but that may be incorrect | 17:51 |
| === dendro-afk is now known as dendrobates | ||
| tkamppeter | sabdfl, hi | 17:56 |
| sabdfl | hi till | 17:56 |
| === dendrobates is now known as dendro-afk | ||
| === dendro-afk is now known as dendrobates | ||
| === hallyn is now known as hallyn_afk | ||
| === dendrobates is now known as dendro-afk | ||
| dmart | james_w: removed the series goal and milestone target from that blueprint. I'll follow up with the platform guys to see whether this needs to get rescheduled. | 18:35 |
| barry | dmart: hi, i was at lunch | 18:37 |
| barry | dmart: no idea. i've never seen that before. could it be a memory problem? it's been a while since i've read through PyType_Ready but i think if you were memory constrained, it could fail | 18:41 |
| === bregma|break is now known as bregma | ||
| === dendro-afk is now known as dendrobates | ||
| === kklimonda is now known as Guest62081 | ||
| tkamppeter | sabdfl, ping | 19:10 |
| SpamapS | hm, is sbuild confused by Build-Dependencies like " locales-all | language-pack-de" ? | 19:10 |
| SpamapS | where locales-all doesn't exist... | 19:10 |
| persia | Yes. | 19:10 |
| SpamapS | is the answer pbuilder? | 19:11 |
| persia | When generating alternative Dependencies, Recommendations, and Build-Dependencies, one needs to choose a real package followed by others. | 19:11 |
| persia | No, because if it happens to work with pbuilder, it will FTBFS when you upload it and LP runs sbuild. | 19:11 |
| SpamapS | This is the debian maintainer for PHP wanting to make the package easier to merge... | 19:11 |
| persia | That's doing it wrong. Debian also uses sbuild for the wanna-build network. | 19:12 |
| slangasek | persia: your comments are a significant departure from historical practice in Ubuntu | 19:13 |
| persia | slangasek, Hrm? How do? We've always needed to put real packages before virtual packages in | constructs. | 19:13 |
| slangasek | Build-Depends: $not_in_main_in_ubuntu | $ubuntu_preferred_package has been a standard technique for quite a while | 19:13 |
| SpamapS | In this case its $not_in_ubuntu_at_all | $not_in_debian_at_all | 19:14 |
| slangasek | and sbuild as used in Ubuntu has been specially trained to consider non-default alternatives for this reason | 19:14 |
| === dendrobates is now known as dendro-afk | ||
| persia | Ah, yes, and I suppose $not_in_main_in_ubuntu ~= $does_not_exist | 19:14 |
| SpamapS | aha | 19:15 |
| === dendro-afk is now known as dendrobates | ||
| SpamapS | --check-depends-algorithm | 19:15 |
| SpamapS | =alternatives .. lets try that | 19:15 |
| slangasek | yeah, no idea how you get this behavior out of the current /packaged/ version of sbuild, I'm afraid; I don't think the LP one runs from a package | 19:16 |
| persia | It doesn't. The remaining differences are small though, and mostly related to build-harness stuff. | 19:17 |
| persia | OK. I'm confused. Policy 7.1 clearly states that anything is fine, but I'm sure I've previously been told on many occasions to have the first in a | list be some real package. | 19:18 |
| SpamapS | damn.. -C alternatives didn't work | 19:19 |
| slangasek | persia: I think this may have been a recent policy clarification. In general, you don't want to have listed as the first alternative a virtual package that's provided by multiple real packages, because it causes nonintuitive behavior | 19:20 |
| slangasek | and if the first alternative isn't available in Debian, the package will FTBFS in Debian | 19:21 |
| slangasek | but otherwise, it should work no matter what you do | 19:21 |
| persia | Ah, so the recommendation once matched what I've said, but in practice the only case where one needs to worry is when the first alternative is virtual and multiply-provided? | 19:21 |
| persia | If the first alternative isn't available in Debian, it will certainly FTBFS? | 19:22 |
| slangasek | yes, and yes | 19:22 |
| maco | persia: dontcha love it when the rules change under your feet? | 19:22 |
| Laney | Currently, although there was some talk about switching resolver. | 19:23 |
| SpamapS | So the issue is, php's test suites needs either locales-all or language-pack-de ... both of which are unique to Debian and Ubuntu respectively. | 19:24 |
| persia | SpamapS, I don't believe you can usefully locally build-test that construction: send it to a PPA. | 19:24 |
| === Guest62081 is now known as kklimonda^ | ||
| persia | SpamapS, Also, please file a bug against sbuild for that: there's been talk about switching LP to distro sbuild, and this change is one that isn't in the patches-needed-for-sbuild I was given last week. | 19:25 |
| SpamapS | I'm trying it w/ build-dep-resolver=aptitude too | 19:25 |
| SpamapS | Will do on the bug | 19:25 |
| slangasek | so I think that using the apt, aptitude resolvers will actually work for your purposes in Ubuntu | 19:25 |
| persia | maco, Actually, yes, because this tends to mean 1) I learn and 2) the world is a better place | 19:25 |
| slangasek | ... unless rleigh has since patched them to be more Debian-like :) | 19:26 |
| slangasek | SpamapS: btw, it is possible to generate a locale at package build-time, spit it out to a local directory, and point a package at that, er, local locale... in the grand scheme of things that seems more sensible to me than build-depending on locales-all | 19:27 |
| slangasek | but that's probably out of scope for what you're trying to accomplish right now :) | 19:28 |
| persia | slangasek, There's definitely talk about switching the default resolver away from the internal sbuild one. I thought I saw a clear statement in my oneiric NEWS.Debian.gz file, but my Oneiric system isn't responding to pings right now, so I'll be a bit confirming. | 19:29 |
| persia | I suspect that if it's intentional that first-alternative-unavailable causes FTBFS, the aptitude resolver is likely to support that model. | 19:29 |
| slangasek | it was discussed at length on debian-devel, anyway | 19:30 |
| slangasek | I don't know what's been implemented to date | 19:30 |
| SpamapS | slangasek: I believe the tests specifically require de | 19:31 |
| slangasek | yes, and you can generate a de locale using this method | 19:31 |
| persia | One could generate de locally | 19:31 |
| SpamapS | Ah interesting | 19:31 |
| slangasek | because the source data is always available under /usr/share/i18n | 19:31 |
| SpamapS | so just the tool is necessary then? Where would the locale information come from? | 19:32 |
| SpamapS | ah | 19:32 |
| slangasek | you could look at /usr/sbin/locale-gen, if you really want to go down that rat hole :) | 19:32 |
| SpamapS | I'm hesitant to even care since we will *always* have a delta w/ Debian on PHP .. | 19:33 |
| SpamapS | I mean unless 4 or 5 upstreams get their act together and start being main-worthy | 19:33 |
| SpamapS | btw aptitude did resolve this issue, there are other issues now w/ the libdb transition | 19:34 |
| SpamapS | slangasek: looks like db4.8's merge is blocking libdb-dev from working properly | 19:37 |
| slangasek | really? | 19:37 |
| SpamapS | libdb-dev: Conflicts: libdb4.8-dev but 4.8.30-5ubuntu2 is to be installed. | 19:37 |
| SpamapS | libdb5.1-dev: Conflicts: libdb4.8-dev but 4.8.30-5ubuntu2 is to be installed. | 19:37 |
| slangasek | nah, that's not the merge that's blocking | 19:38 |
| slangasek | something in your build-dep chain needs to transition to the newer version | 19:38 |
| slangasek | libdb4.8-dev and libdb5.1-dev aren't coinstallable | 19:38 |
| SpamapS | everything in libdb4.8 has to be migrated I take it? | 19:39 |
| SpamapS | rather, all of the rdepends ? | 19:39 |
| slangasek | eventually they all do | 19:39 |
| slangasek | for your purposes, you probably just need apache / apr to do so | 19:39 |
| stgraber | jhunt: hey! is https://code.launchpad.net/~jamesodhunt/ubuntu/natty/upstart/fix-for-770532/+merge/59348 already in Oneiric's upstart? | 19:40 |
| SpamapS | slangasek: yeah, apr-util | 19:41 |
| SpamapS | slangasek: I requested sync on apr-util .. the delta was applied upstream.. if you could maybe make that sync happen that would help quite a bit. :) | 19:47 |
| SpamapS | I know I have aa rights, but I don't have permission just yet. ;) | 19:47 |
| SpamapS | anyway, bbl | 19:48 |
| === nixNcode is now known as nNc | ||
| stgraber | jhunt: ok, apparently not. Do you want me to apply that diff to Oneiric, upload it and then upload the same as SRU in natty-proposed? | 19:49 |
| * micahg thought the build dep alternative issue was only for versioned build-deps | 19:50 | |
| slangasek | SpamapS: done-ish | 19:51 |
| jhunt | stgraber: that would be great, thanks. | 19:51 |
| micahg | would some type of helper like dh_multiarch be useful that does substitution? | 19:52 |
| stgraber | jhunt: ok, working on that now then. | 19:52 |
| jhunt | stgraber: FYI - http://package-import.ubuntu.com/status/upstart.html - does that affect what you'll be doing? | 19:52 |
| stgraber | jhunt: oh, thanks for the warning. Yes it'd have :) | 19:53 |
| stgraber | jhunt: I'm going to do it as a good-old upload then (without UDD) | 19:53 |
| stgraber | or can try to fix the branch, if that's just one missing tag. | 19:54 |
| jhunt | stgraber: you might want to discuss with SpamapS. I'm still not clear if I should have created that tag as the proposer (?) | 19:56 |
| * micahg of the opinion the tag should be created by the uploader in cases of sponsorship unless it has been previously discussed | 19:57 | |
| slangasek | isn't the issue here that the branch didn't use merge-upstream? | 20:05 |
| stgraber | yep, that was the issue. I'm going to manually add the tag, that should help | 20:05 |
| slangasek | manually add it to what? I don't think you have a commit on there you can add it to that matches what's expected | 20:05 |
| stgraber | slangasek: r1311 is what bumped configure.ac from 0.9.6 to 0.9.7 | 20:06 |
| slangasek | "upstream-0.9.7" should point to a commit that contains the entire upstream *tarball* | 20:06 |
| slangasek | there is no such commit in the current history | 20:07 |
| stgraber | hmm, right | 20:08 |
| stgraber | slangasek: suggestions? should I just go with non-UDD upload until the branch is fixed somehow? SpamapS commited 0.9.7-2 to the branch but apparently didn't use debcommit as the 0.9.7-2 tag is missing, so it's not clear what to do with the branch :) | 20:11 |
| slangasek | stgraber: I was going to poke the missing bits in now with merge-upstream | 20:11 |
| slangasek | but I can't find the source branch that maps to what I see merged in the history | 20:12 |
| slangasek | jhunt: is there an upstream upstart branch that maps to what shows up as 0.9.7 in the lp:ubuntu/upstart history? | 20:12 |
| slangasek | lp:~jamesodhunt/upstart/0.9 specifically does not appear to be it | 20:12 |
| slangasek | oh, lp:~upstart-devel/upstart/0.9, here we go | 20:13 |
| jhunt | slangasek: right. | 20:13 |
| slangasek | stgraber, jhunt: FYI: bzr merge-upstream --last-version=0.6.7 --version 0.9.7 /mirror/ubuntu/pool/main/u/upstart/upstart_0.9.7.orig.tar.gz | 20:17 |
| === dendrobates is now known as dendro-afk | ||
| jhunt | SpamapS: could you take a look at the work items on https://blueprints.launchpad.net/ubuntu/+spec/foundations-o-upstart-for-admins/ when you get a chance to make sure I haven't missed anything. | 20:19 |
| SpamapS | jhunt: sure, I'll give it a closer look tonight | 20:21 |
| * SpamapS is running out the door for an appointment | 20:21 | |
| highvoltage | don't run with laptops! | 20:21 |
| Bert_2 | Is this channel suitable for questions concerning licenses on certain ubuntu packages ? | 20:24 |
| slangasek | stgraber: branch should be more or less cleaned up now for you to work against | 20:26 |
| stgraber | slangasek: thanks! | 20:27 |
| === yofel_ is now known as yofel | ||
| barry | okay, here's a package version numbering question for you: i'm manually merging debian's python-numpy 1:1.5.1-2 to our 1:1.5.1-1ubuntu2. we still need to carry one extra ubuntu-specific patch. bzr merge-package succeeded with no conflicts but leaves me with a version number 1:1.5.1-2, however because of the ubuntu-specific patch, this is not identical to the debian version. i think i should change our version to 1:1.5.1-2ubuntu1 | 20:36 |
| barry | before i commit the merge and uplload. is that correct? | 20:36 |
| slangasek | yes | 20:36 |
| micahg | barry: yes, and there should be tags for both | 20:37 |
| slangasek | bzr merge-package doesn't autoincrement the changelog, AFAIK | 20:37 |
| slangasek | well, the 1:1.5.1-2 tag should already be there courtesy of UDD | 20:37 |
| micahg | right | 20:37 |
| seb128 | seems like a bug in the merge tools I was about to say | 20:37 |
| barry | it doesn't autoinc the changelog but it does merge changelog entry from the debian package | 20:37 |
| slangasek | yep | 20:37 |
| seb128 | slangasek, why is the version not updated? | 20:37 |
| seb128 | (just curious) | 20:37 |
| slangasek | seb128: I didn't write any of the code in question, perhaps no one thought of it yet :) | 20:38 |
| === dendro-afk is now known as dendrobates | ||
| barry | indeed, after bzr merge-package the 1:1.5.1-2 tag is there (uncommitted as of yet) | 20:38 |
| slangasek | honestly, I usually use 'bzr merge' instead of 'bzr merge-package' | 20:38 |
| barry | and the bzr mark-uploaded will add the 2ubuntu1 tag | 20:38 |
| barry | or at least *should* ;) | 20:38 |
| slangasek | but 'bzr merge-upstream' *does* kick off a new debian/changelog entry, so it seems merge-package ought to as well | 20:38 |
| seb128 | slangasek, that's still better than us desktopers, we just keep our debian dir in the vcs and do merges the good old way ;-) | 20:39 |
| barry | so just to be clear, i do not need both changelog entries, right? and i should probably include the fact that we're still carrying an ubuntu-specific patch in the 2ubuntu1 changelog entry, right? | 20:39 |
| slangasek | oh, here's a question | 20:39 |
| james_w | yeah, it needs both changelog entries | 20:39 |
| slangasek | bzr merge-package isn't specific to Debian->Ubuntu merges... what should it auto-increment the changelog entry to, and how should it decide? | 20:39 |
| james_w | so it's whether it should add dch -i at the end | 20:40 |
| james_w | I didn't because you may not be doing that | 20:40 |
| seb128 | barry, so seem weird questions ;-) usually a merge is "take what is in debian and add the ubuntu changes with an entry listing those" | 20:40 |
| barry | james_w: ah, so my commit should contain two changelog entries, one from the merge-package (i.e. copied from the top debian changelog) and another with the ubuntu-specific patch mentioned | 20:40 |
| slangasek | barry: yes, the changelog for a merge should document the remaining delta | 20:40 |
| james_w | we could add a flag for it, and a --distribution option | 20:40 |
| seb128 | james_w, hey | 20:40 |
| * micahg thinks it shouldn't add anything on top since you could just be merging in the current version | 20:41 | |
| james_w | hi seb128 | 20:41 |
| seb128 | james_w, do you know why http://reports.qa.ubuntu.com/reports/sponsoring/ got quite some merge requests from you on series going back to edgy? | 20:41 |
| barry | seb128: hi, yeah i know it seems a bit weird. i think common case would be where we could drop the ubuntu-specific change (but i don't have enough data oints to know for sure). in this case, we can't | 20:41 |
| seb128 | james_w, it seems pretty weird old series like edgy get activity now | 20:42 |
| slangasek | barry: common case> heh, not hardly, I'm afraid | 20:42 |
| barry | ;) | 20:42 |
| barry | slangasek: okay, maybe i'll do a merge proposal and have you take a quick look for sanity? | 20:42 |
| seb128 | barry, well, I would rather think that things we have a diff on the diff is there for a reason ;-) | 20:42 |
| james_w | seb128, iz james_w bog | 20:44 |
| slangasek | seb128: I think he means that the next merge from Debian would commonly include the changes from Ubuntu and we would be back in sync... wishful thinking though :) | 20:44 |
| slangasek | barry: can do | 20:44 |
| james_w | the importer gets thoroughly confused and thinks someone uploaded something there that conflicts with what is in the branch, when obviously they didn't | 20:44 |
| james_w | the reason it sees uploads now is that it has failed in the past, and so hadn't finished importing edgy | 20:45 |
| james_w | I haven't had chance to go through and investigate and file appropriate bugs yet | 20:45 |
| seb128 | slangasek, indeed ;-) | 20:48 |
| seb128 | james_w, ok | 20:49 |
| barry | slangasek: right, that was my hope, false as it is ;) | 20:50 |
| barry | slangasek: https://code.launchpad.net/~barry/ubuntu/oneiric/python-numpy/merge-deb-1_1.5.1-2/+merge/62367 | 20:59 |
| slangasek | barry: grabbing | 21:01 |
| slangasek | barry: the convention for the changelog entry on a merge from Debian is to declare something like "merge from Debian unstable, remaining changes:" so it's clear from context that this isn't a new change you're introducing | 21:04 |
| barry | slangasek: would that be on the first changelog entry or the second? | 21:04 |
| slangasek | also, some of us changelog addicts will go so far as to document why each other bit of the delta has gone away ("merge upstream", "merged in Debian", "no longer relevant", etc) | 21:04 |
| seb128 | slangasek, btw I assigned bug #788115 to you (that's about changing the dpkg-architecture call in the librsvg postinst by a build time generation) | 21:04 |
| ubottu | Launchpad bug 788115 in librsvg (Ubuntu) "[Oneiric] dpkg error when upgrading librsvg (2.34.0-0ubuntu4)" [Undecided,Confirmed] https://launchpad.net/bugs/788115 | 21:05 |
| slangasek | barry: the top one; you only want to modify the changelog entry for the Ubuntu upload you're doing | 21:05 |
| slangasek | not for the Debian upload you've merged | 21:05 |
| slangasek | seb128: ack, thanks | 21:05 |
| barry | slangasek: ack, thanks | 21:05 |
| seb128 | slangasek, thank *you* for working on it ;-) | 21:05 |
| === hallyn_afk is now known as hallyn | ||
| barry | slangasek: update pushed, but no need to review it if you don't want. thanks again for the advice | 21:14 |
| slangasek | no prob :) | 21:14 |
| barry | come back launchpad, we still love you | 21:18 |
| cjwatson | stgraber: edubuntu-live> hmm, not sure - I'd suggest asking dpm to check it out, as I'm pretty rusty on that stuff | 21:47 |
| stgraber | ok, will poke him tomorrow | 21:49 |
| === dendrobates is now known as dendro-afk | ||
| stgraber | @pilot out | 22:51 |
| === 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: | ||
| Darxus | What determines what section a man page generated from pod ends up in? For spamd.raw, it's ending up in 8 for Debian, and apparently 1 for others: http://svn.apache.org/viewvc/spamassassin/trunk/spamd/spamd.raw?view=markup | 22:55 |
| Darxus | (Debian and Ubuntu). | 22:55 |
| === micahg_ is now known as micahg | ||
| slangasek | Darxus: see man(1) :) | 22:56 |
| slangasek | er, no | 22:56 |
| slangasek | sorry, I misread your question | 22:56 |
| slangasek | well, pod2man takes a --section option | 22:56 |
| cjwatson | kirkland: when you last uploaded a bug-fix to newpki-server, you set yourself as the Maintainer. Now it needs to be rebuilt for the OpenSSL 1.0.0 transition, but it's unbuildable because newpki-lib has been removed. Upon investigation I found that all the newpki-* packages have been removed from Debian, and newpki-server is the only one left (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=572740). Do you care enough ... | 23:01 |
| ubottu | Debian bug 572740 in ftp.debian.org "RM: newpki-server -- RoQA; orphaned, dead upstream, rc" [Normal,Open] | 23:01 |
| cjwatson | ... about this to stop me removing newpki-server from Oneiric? | 23:01 |
| cjwatson | (I probably wouldn't have asked except that you'd set yourself as Maintainer rather than ubuntu-devel-discuss) | 23:01 |
| kirkland | cjwatson: hmm, let me refresh my memory, grabbing sources now.... | 23:02 |
| Darxus | Ah, I found the change, the man page got renamed in debian/rules. | 23:02 |
| cjwatson | kirkland: if you care, you'll need to at least track back to why newpki-lib was removed, fix those problems, and reintroduce that package | 23:03 |
| bdmurray | I see there are no pilots but perhaps someone would sponsor my upload? | 23:03 |
| bdmurray | its in bug 781874 | 23:03 |
| ubottu | Launchpad bug 781874 in aptdaemon (Ubuntu Natty) "<type 'exceptions.TypeError'>: __init__() takes exactly 2 arguments (1 given)" [High,In progress] https://launchpad.net/bugs/781874 | 23:03 |
| kirkland | cjwatson: that was a drive by patch; i fixed a one-liner papercut bug | 23:03 |
| kirkland | cjwatson: must have inadvertently set myself as maintainer | 23:04 |
| kirkland | cjwatson: https://bugs.launchpad.net/ubuntu/+source/newpki-server/+bug/598027 | 23:04 |
| ubottu | Ubuntu bug 598027 in Ubuntu Server papercuts "newpki-server should not recommend newpki-client" [Medium,Fix released] | 23:04 |
| cjwatson | yeah, I read that bug but wasn't clear how much interest it implied | 23:04 |
| kirkland | cjwatson: i have no vested interest whatsoever | 23:04 |
| micahg | it sets the maintainer to debemail if there's no internet connectivity (at least it used to) | 23:04 |
| cjwatson | OK, I'll just remove it then. Thanks for checking | 23:04 |
| kirkland | ttx filed the bug ... | 23:04 |
| kirkland | cjwatson: no problem, thanks! | 23:04 |
| slangasek | micahg: doh, how suboptimal | 23:05 |
| micahg | slangasek: might have been fixed in a later version of u-d-t | 23:05 |
| slangasek | bdmurray: I can take a look a little later this afternoon if no one else jumps on it | 23:05 |
| hallyn | isn't lsb-base supposed to always be installed? | 23:11 |
| slangasek | hallyn: lsb-release is, but not lsb-base | 23:12 |
| cjwatson | they both have the same status | 23:12 |
| cjwatson | both are Priority: required and in ubuntu-minimal; neither is Essential: yes | 23:13 |
| hallyn | my more immediate q, i guess, is whether it should be sane for a system to not have sed :) | 23:13 |
| cjwatson | so in practice almost certainly installed, but you must still depend on them if you're using them directly | 23:13 |
| cjwatson | hallyn: sed is different - it's Essential: yes, and you do not need to depend on it | 23:13 |
| hallyn | apache-common needs sed but doesn't call it out in its dependencies | 23:13 |
| hallyn | hm | 23:13 |
| hallyn | this box failed bc sed was not found :) | 23:14 |
| hallyn | bug 788348 | 23:14 |
| ubottu | Launchpad bug 788348 in samba (Ubuntu) "package samba-common 2:3.5.8~dfsg-1ubuntu2.2 failed to install/upgrade: subprocess installed post-installation script returned error exit status 127" [Undecided,New] https://launchpad.net/bugs/788348 | 23:14 |
| cjwatson | in fact, policy says you should not depend on essential packages unless you need a specific version | 23:14 |
| hallyn | good to know. | 23:14 |
| cjwatson | hallyn: invalid state, samba isn't required to work around that situation | 23:14 |
| hallyn | ok thanks | 23:14 |
| cjwatson | and if you look through that log, all sorts of stuff is breaking | 23:15 |
| cjwatson | either filesystem corruption, or the user ignored a REALLY BIG WARNING from the package management system | 23:15 |
| * hallyn taps his fingers | 23:15 | |
| cjwatson | I suspect the former TBH | 23:15 |
| hallyn | all due to sed missing though, that i see | 23:18 |
| === dendro-afk is now known as dendrobates | ||
| === dendrobates is now known as dendro-afk | ||
| * micahg hugs the creators of the transition tracker | 23:37 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
