| YokoZar | We try to use "12.04" instead of "precise" in all user-facing communication, correct? | 00:00 |
|---|---|---|
| * YokoZar just noticed Ubiquity still says things like "overwrite Ubuntu Precise" | 00:01 | |
| barry | @pilot out | 00:15 |
| === udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal A2 released! | Archive: open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: | ||
| === apachelogger__ is now known as apachelogger___ | ||
| === Quintasan_ is now known as Quintasan | ||
| TheMuso | @pilot in | 01:07 |
| === udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal A2 released! | Archive: open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: TheMuso | ||
| TheMuso | bryceh, RAOF, who should I be subscribing to take care of this patch, given you need to put it in debian git? https://bugs.launchpad.net/ubuntu-omap4-extras-graphics/+bug/1015292 | 01:08 |
| ubottu | Launchpad bug 1015292 in xorg-server (Ubuntu) "QT5 based applications fails with a segmentation fault with Pandaboard and the SGX driver" [High,In progress] | 01:08 |
| TheMuso | ...or is it on your radar already? | 01:08 |
| RAOF | TheMuso: You can subscribe me if you like. That wouldn't be on one of our lists, because ricardo has it assigned to himself. | 01:14 |
| TheMuso | Right, and you wouldn't see it anyway since the package is not set to xorg... | 01:15 |
| TheMuso | RAOF: Thanks, will do. | 01:15 |
| === cpg is now known as cpg|away | ||
| === nigelb_ is now known as nigelb | ||
| === cpg|away is now known as cpg | ||
| nigelb | Laney: Congrats on core-dev! :) | 02:08 |
| infinity | It was fixed. | 02:08 |
| TheMuso | Given Debian is now frozen, what are other pilots doing if they encounter new upstream releases in the queue? I'm enclined to query the contributor why they think it should be updated, but other than that, I might just let through. THoughts? | 02:50 |
| === Pendulum_ is now known as Pendulum | ||
| RAOF | TheMuso: I'd probably tend towards updating it, as long as the packaging isn't significantly divergent to Debian. | 03:05 |
| TheMuso | RAOF: Thanks for the advice, thats what I've been thinking too. | 03:05 |
| === rsalveti` is now known as rsalveti | ||
| killown | sudo apt-get install libfreetype6-dev:i386 makes remove the follow packages build-essential dkms g++ gcc gcc-multilib libcairo2-dev libfontconfig1-dev libfreetype6-dev libgtk2.0-dev libimlib2-dev libpango1.0-dev libxft-dev nvidia-current tk-dev tk8.5-dev virtualbox-dkms, what's going on with ubuntu¿ same problem here https://bugs.launchpad.net/ubuntu/+source/wine1.4/+bug/944321/comments/19 | 04:11 |
| ubottu | Launchpad bug 944321 in wine1.4 (Ubuntu) "apt-get build-dep script for wine missing xorg and " [Undecided,Confirmed] | 04:11 |
| pitti | Good morning | 05:04 |
| TheMuso | @pilot out | 05:07 |
| === udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal A2 released! | Archive: open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: | ||
| pitti | cjwatson: seems queue is stumbling over accepting checkbox: http://paste.ubuntu.com/1097785/ | 05:17 |
| pitti | cjwatson: it's a standard LP timeout | 05:18 |
| StevenK | pitti: It timed out in close_bugs_for_sourcepackagerelease, how many bugs does it reference? | 05:21 |
| pitti | http://launchpadlibrarian.net/110354354/checkbox_0.14.2_source.changes | 05:23 |
| pitti | 8 bugs | 05:23 |
| pitti | that was the case that cjwatson already mentioned in his post | 05:23 |
| StevenK | Right | 05:24 |
| pitti | the workaround would be to upload that to -proposed, accept, let it build, and copy it over, i. e. what we are about to do automatically anyway | 05:24 |
| pitti | but at least we now know it's a definitive issue | 05:24 |
| StevenK | Bug closing during accept has always been an issue, TBH | 05:25 |
| pitti | yeah, of course | 05:25 |
| pitti | StevenK: I guess it's not trivial to make it use the same async bug closing as syncPackage()? | 05:25 |
| StevenK | pitti: syncPackage() is not a LP method that I can see | 05:29 |
| pitti | StevenK: ah, I mean copyPackage() | 05:38 |
| pitti | I keep mixing up the two | 05:38 |
| pitti | syncPackage was the older one | 05:38 |
| pitti | (but probably still exists) | 05:38 |
| StevenK | pitti: Right, so copyPackage() creates a job that does the copy -- no, it's not trivial. | 05:39 |
| alazare619 | anyone here familiar with livecd-rootfs | 05:43 |
| alazare619 | im trying to add a ppa to the building phase but its not getting added | 05:43 |
| pitti | alazare619: it's easier to use ubuntu-defaults-image from the ubuntu-defaults-builder package; see the manpage | 05:48 |
| pitti | it directly supports building a live CD with an extra PPA/package | 05:49 |
| alazare619 | meh | 05:53 |
| alazare619 | :P | 05:53 |
| alazare619 | manpage ubuntu-defaults-image? | 05:53 |
| pitti | alazare619: http://manpages.ubuntu.com/ubuntu-defaults-image | 05:55 |
| infinity | StevenK / cjwatson: So, if we're timing out with only 8 bug closures, I'd say that's a resounding failure for the "can we remove queue from cocoplum before we try a real release freeze" test, at least until we can beef that up... | 05:57 |
| StevenK | infinity: The function in question is close_bugs_for_sourcepackagerelease, and it's been horrid for a long while. | 05:58 |
| infinity | cjwatson: (Unless we really want to live with the "upload somewhere that doesn't process bug closures and then copy" workaround during a release crunch, but that seems like a silly amount of self-imposed pain) | 05:58 |
| infinity | StevenK: Yes, we're well aware of how horrid it is, it's specifically why we were doing the fake freeze test. | 05:58 |
| StevenK | for bug in bugs_to_close: <work out target> bug.newMessage() ; for more than two bugs is not full of puppies of rainbows | 05:58 |
| infinity | StevenK: And if it's performing THAT badly, I'd say the test failed. | 05:58 |
| pitti | well, is there a dramatic urgency of removing the cocoplum shell tool? | 05:58 |
| pitti | I thought the main point was that everyone in ~u-archive can now process the queue | 05:59 |
| infinity | pitti: IMO, no, but others seem to think differently. ;) | 05:59 |
| cjwatson | pitti: interesting; it accepted it fine for me | 05:59 |
| pitti | I don't see why we can't keep the shell tool until the "all uploads to to -proposed" machinery is in place | 05:59 |
| cjwatson | pitti: FWIW sync*Source* was the older method :) | 06:00 |
| pitti | cjwatson: hm, I tried two times, but I guess 8 bugs is close to the magic bounardy | 06:00 |
| pitti | cjwatson: ah :) | 06:00 |
| infinity | pitti: Trying two times probably primed the caches juuuust enough. :) | 06:00 |
| pitti | heh | 06:00 |
| cjwatson | I wanted to remove the shell tool because it's something like 2000 lines of code that *almost* doesn't need to be there | 06:01 |
| infinity | cjwatson: I'm all for it being removed as soon as we can, but I'm not sure that's today, if 8 bugs is our limit. | 06:01 |
| cjwatson | Yeah, doesn't sound ideal. Disappointing. | 06:02 |
| pitti | cjwatson: I guess we can at least start with severely trimming the list of people with ssh access? | 06:02 |
| infinity | (Perhaps it's time for someone to actually think about profiling that there leviathan of a webapp) | 06:02 |
| infinity | Or, make bug closures async. | 06:02 |
| cjwatson | infinity: lifeless has been talking about making a notification service for a while | 06:03 |
| pitti | cjwatson: (I don't mind having mine revoked, FTR) | 06:03 |
| cjwatson | pitti: There's a little while yet before I start on that kind of thing | 06:03 |
| infinity | cjwatson: In fact, pitti volunteered on behalf of others to revoke theirs too! ;) | 06:03 |
| infinity | 00:01 <pitti> if cjwatson, you, and slangasek keep access, there should always be one person available for emergency accepts | 06:04 |
| infinity | ^--- | 06:04 |
| pitti | the only reason for sshing there recently has been checkrdepends; but that in no way requires cocoplum access, just me getting out of old habits :) | 06:04 |
| infinity | 00:02 <pitti> also, I think you're by far the most attractive archive admin | 06:04 |
| * pitti files a bug against weechat about its string rewriting | 06:05 | |
| * infinity whistles. | 06:05 | |
| pitti | getting a towel to wipe clean my screen now | 06:05 |
| infinity | pitti: I mostly use reverse-depends(1) now, but I don't trust it fully. I should look into why that is and file bugs. | 06:05 |
| pitti | infinity: the next best thing woudl be to run it on people, which also has a local mirror | 06:06 |
| infinity | pitti: And, conveniently, a checkout of ubuntu-archive-tools. | 06:06 |
| cjwatson | So turning bug closures into a job mightn't necessarily be *horribly* hard; one reason I haven't is that it seems to overlap with this notification service thing | 06:06 |
| StevenK | cjwatson: I think it might be worthwhile to investigate a better API for that first, rather than just clammoring for a job. | 06:07 |
| pitti | is there an estimate when we'll likely have the "everything into -proposed" machinery? because that would circumvent the problem, wouldn't it? | 06:07 |
| cjwatson | StevenK: as in internal API? | 06:08 |
| StevenK | cjwatson: Yes. | 06:08 |
| infinity | pitti: I'm hoping I can make it go vaguely "soon", but then I'd also want to fix/change accepts into -proposed to automagically twiddle bugs to Fix Committed, which will hit the same wall. | 06:08 |
| StevenK | cjwatson: The current code does a for loop over each bug, using BugTaskFlat we could fetch the relevant tasks in one fast query, feed the list of tasks and a message into BugSet.something, win | 06:08 |
| infinity | pitti: Right now, we do that by hand with sru-accept, which is silly. | 06:09 |
| pitti | infinity: *nod* | 06:09 |
| infinity | Anyhow, I think I'm going to have an uncharacteristically early night. | 06:10 |
| StevenK | infinity: Who are you, and what have you done with the real Adam? | 06:10 |
| infinity | StevenK: I didn't say I'd succeed at it. I'm just going to try. | 06:10 |
| infinity | Fingers crossed. | 06:10 |
| cjwatson | StevenK: there is a possibility that I may have a go | 06:11 |
| cjwatson | if I can understand it | 06:11 |
| StevenK | cjwatson: I'm certain both wgrant and I would be happy to have a pre-implementation call with you | 06:11 |
| cjwatson | not to mention figuring out how to QA it ... | 06:11 |
| StevenK | cjwatson: It may end up having to be a job, but maybe not | 06:11 |
| infinity | cjwatson: File a bunch of bugs, write a tool that uses the new API to mangle them over and over, time it? | 06:11 |
| cjwatson | infinity: caching | 06:12 |
| infinity | cjwatson: Doesn't really need to be hooked up to accepts. | 06:12 |
| infinity | cjwatson: File more bugs! | 06:12 |
| cjwatson | for testing, StormStatementRecorder is probably more useful. | 06:12 |
| StevenK | Yeah | 06:12 |
| StevenK | Call close_bugs_for_spr and see if the statement count makes you sob or not. | 06:13 |
| StevenK | If there are no tears, the test passes. | 06:13 |
| cjwatson | The other problem is that it isn't just the target computation; doesn't it take time to notify each recipient too? | 06:14 |
| StevenK | I'm not sure about that, but maybe | 06:15 |
| wgrant | StevenK, cjwatson: Yes, the main problem is usually notifications. | 06:16 |
| wgrant | cjwatson: Of course, the proper way to fix this is to make accepts async like copies | 06:19 |
| cjwatson | Move the whole thing to jobs rather than just the bug closures? | 06:22 |
| cjwatson | The problem there is that errors in the acceptance are more likely and more important than errors in bug closures, and making the whole thing async would complicate error notifications. | 06:22 |
| wgrant | cjwatson: It would, but acceptance should really be the same code as copying. | 06:23 |
| wgrant | Treating them differently is... odd | 06:23 |
| infinity | cjwatson: It already notifies by mail (and I certainly get mail when a copy goes kablooey) | 06:24 |
| cjwatson | infinity: There's no mail notification when an attempt to accept a package fails | 06:24 |
| infinity | cjwatson: If we just augment that service to also mail the person who initiates the job (ie: the AA driving) on anything !accept. | 06:24 |
| cjwatson | But OK, it's certainly *possible* for failed jobs to mail error notifications | 06:25 |
| cjwatson | I'm not convinced the resulting UI is good | 06:25 |
| wgrant | Well | 06:25 |
| wgrant | It may not be good | 06:25 |
| wgrant | But it will work | 06:25 |
| infinity | Well, as wgrant points out, it's the same UI as copies. | 06:25 |
| wgrant | Whereas what we have now does not work | 06:25 |
| infinity | So, either it's all bad or all good. Half bad seems weird. | 06:25 |
| cjwatson | What we have now works about (from raw data during this experiment) 95%+ of the time | 06:25 |
| infinity | And, if the copy experience isn't ideal, we should probably look at sorting that. | 06:26 |
| infinity | Cause, frankly, except in freeze periods, I bet we copy almost as much as we accept directly. | 06:26 |
| infinity | Okay, and not counting autosync stuff, but that could use an overhaul too. | 06:26 |
| cjwatson | autosync just had an overhaul :P | 06:26 |
| cjwatson | Once we get to the point of copying things, failures are rather less likely, and we guard against a lot of the plausible ones in the sru-report stage | 06:27 |
| infinity | Define "failure" here? | 06:27 |
| infinity | You mean genuinely broken packages that somehow explode the machinery in unpredicted ways? | 06:27 |
| infinity | Or rejects? | 06:27 |
| infinity | Cause we get rejects on copies. | 06:27 |
| cjwatson | I mean QueueInconsistentStateError | 06:28 |
| infinity | Kay. Can't remember the last time I ever saw that on an accept either. But you have accepted a lot more packages than I in the last few years. | 06:29 |
| cjwatson | Looks like basically version clashes, file overlaps, and invalid components. Maybe that's not so bad. | 06:30 |
| infinity | Those should all be rejects. | 06:30 |
| infinity | How are they not? | 06:30 |
| cjwatson | Possibly these are last-ditch guards and they're supposed to be rejected earlier. I forget. | 06:32 |
| infinity | Well, I would assume the first two are trying to guard against some race whereby you could land clashes in the queue somehow. But given that that should all happen serially with locking and such, well done if we still haven't fixed getting to that state. | 06:33 |
| infinity | The latter, I have no idea how it would "slip in". | 06:33 |
| infinity | (Except maybe a guard against a bug in the old queue tool allowing you to override something into oblivion?) | 06:33 |
| infinity | Or a bug in rewriting of components from Debian. | 06:34 |
| cjwatson | You know what would help? A job runner that ran continuously watching for stuff to do, rather than running every minute | 06:34 |
| cjwatson | infinity: Resurrecting rejections comes to mind | 06:34 |
| cjwatson | (For the first two) | 06:34 |
| infinity | cjwatson: Those should then pass through the same accepty machinery (that's not historically been true, but it really should be now, if it's not...) | 06:34 |
| cjwatson | They do, but if they fail, you get QueueInconsistentStateError. | 06:35 |
| infinity | Special. | 06:35 |
| cjwatson | Which leaves them in rejected so in fact this is fine. | 06:35 |
| cjwatson | I do think that the up-to-a-minute-or-so delay you get for copies would be Very Very Annoying for accepts. | 06:35 |
| cjwatson | It's merely Annoying for copies, perhaps because we're used to it. | 06:36 |
| infinity | cjwatson: Actually, for accepts, I'd find it less annoying. | 06:36 |
| cjwatson | Really? | 06:36 |
| infinity | cjwatson: I find it annoying for copies, because of the pile-on bug that copies often then need an accept. | 06:36 |
| cjwatson | Well, OK | 06:36 |
| infinity | cjwatson: I don't often need to follow-up an accept. | 06:36 |
| cjwatson | But imagine you're iteratively processing the queue | 06:36 |
| cjwatson | You'll often be going back and looking at what else is there right afterwards | 06:37 |
| infinity | Accepts are fire-and-forget, until they produce something later (via a buildd). | 06:37 |
| cjwatson | Frequent source of WTF moments | 06:37 |
| infinity | Oh, I suppose there's that. | 06:37 |
| infinity | DB addition to mark accepts as "accepting", so that UIs can choose not to display in-progress jobs, and twiddle then back if the async job fails? | 06:38 |
| infinity | s/then/them/ | 06:38 |
| cjwatson | That'd be a new upload status (effectively another "queue", as we choose to see it) | 06:38 |
| cjwatson | Well, not quite, because it would need to remember the old status | 06:38 |
| infinity | Yeah. | 06:38 |
| infinity | I didn't mean it as a status change, but just a flag. | 06:39 |
| infinity | It would still be in its queue until the job finished and moved it to accepted. | 06:39 |
| infinity | Just marked as "don't show up in high level UIs, I'm thinking". | 06:39 |
| cjwatson | Maybe. Kind of sounds like solving the problem by adding more data. | 06:39 |
| infinity | Which then also gives you a "--show-in-progress" option to queue, if you want to see what's going on. | 06:39 |
| infinity | Well, you can add a column, or you can AND the previous queue (I assume they're ints?) with some magic number to create a superqueue. :P | 06:40 |
| infinity | But either way is adding data. I don't know of a way to track state without doing so. | 06:41 |
| infinity | Midgets, I suppose. | 06:41 |
| infinity | We could hire midgets. | 06:41 |
| infinity | To sit in the appservers. | 06:41 |
| infinity | And keep watch. | 06:41 |
| infinity | It miiiiight be bedtime. | 06:41 |
| RAOF | I suggest pixies; they're cheaper. | 06:42 |
| scientes | dpkg-shlibdeps: error: invalid dependency got generated: liblzma_private_symbols | 06:45 |
| scientes | havn't gotten that one before | 06:45 |
| alazare619 | ok is the ubuntu-image-defaults a minimal iso? | 06:52 |
| alazare619 | or is it gnome? | 06:52 |
| pitti | alazare619: it's an ubuntu desktop CD, i. e. with unity/gnome | 06:52 |
| alazare619 | is there a way to get image-defaults without gnome? | 06:53 |
| alazare619 | or am i just going to go the route of livecd-rootfs? | 06:53 |
| pitti | not right now | 06:53 |
| cjwatson | StevenK: Can you help me read https://oops.canonical.com/?oopsid=OOPS-010486e682dfae5a2594aa81edcedc98 ? I assume times are in ms - does the fact that there's nothing going on >142ms, and not even any repeated statement occupying >156ms, mean that this is death-by-a-thousand-cuts? | 06:53 |
| cjwatson | It would help if there were fewer blank lines :P | 06:54 |
| lifeless | cjwatson: they aren't blanks | 06:54 |
| lifeless | cjwatson: scroll to the right | 06:54 |
| cjwatson | Oh, not blanks, insane indenting | 06:54 |
| cjwatson | Right | 06:54 |
| lifeless | backtraces | 06:54 |
| cjwatson | Not quite sure why they're so ridiculously far over. | 06:55 |
| lifeless | one of the queries has pushed the column width out | 06:55 |
| lifeless | anyhow | 06:55 |
| lifeless | key things: | 06:55 |
| lifeless | Statement Count: 518 | 06:55 |
| lifeless | ^ thats way too many | 06:55 |
| lifeless | min time is 1-2ms for a query | 06:56 |
| lifeless | you need to aim for 15-20, and accept up to 50 | 06:56 |
| lifeless | if you click on repeated querys | 06:56 |
| lifeless | and scroll far left | 06:56 |
| lifeless | you see: | 06:56 |
| lifeless | 34 reps of | 06:56 |
| lifeless | SELECT Person.account, | 06:56 |
| lifeless | Person.creation_comment, | 06:56 |
| lifeless | Person.creation_rationale, | 06:56 |
| lifeless | .. | 06:56 |
| === darkdevil_ is now known as dArKd3ViL | ||
| lifeless | 32 of bugsubscription lookups | 06:56 |
| lifeless | 21 of sourcepackage id lookups | 06:57 |
| lifeless | cjwatson: is +upload doing email notifications ? | 06:57 |
| lifeless | cjwatson: oh, I see | 06:57 |
| lifeless | this has been thoroughly analyzed already | 06:57 |
| lifeless | bug 745799 | 06:58 |
| ubottu | Launchpad bug 745799 in Launchpad itself "DistroSeries:+queue Timeout accepting packages (bug structural subscriptions)" [Critical,Triaged] https://launchpad.net/bugs/745799 | 06:58 |
| lifeless | https://bugs.launchpad.net/launchpad-project/+bugs?field.tag=timeout and look for queue ;) | 06:58 |
| StevenK | And then sob quietly | 06:58 |
| alazare619 | is there a livecd-rootfs irc? | 07:00 |
| cjwatson | lifeless: So I would love pointers to general strategies for fixing this kind of thing within LP. Is bulk-loading an appropriate hammer for this kind of nail? | 07:05 |
| cjwatson | (Assuming for a moment that this is fixable without going async) | 07:06 |
| === dArKd3ViL is now known as darkdevil_ | ||
| lifeless | so, there are a few strategies | 07:09 |
| lifeless | first is to look for places that aren't bulk loading already and do so | 07:09 |
| lifeless | there is a person helper, for instance | 07:09 |
| lifeless | however, all the bug helper code is notify-per-bug | 07:09 |
| lifeless | so a loop on bug will be bulk loading internally but not globally. | 07:09 |
| lifeless | you basically need to drive the cost of notifying a bug down to (say) 10ms. | 07:10 |
| lifeless | which my proposed notification service would do | 07:10 |
| cjwatson | StevenK suggested a BugSet method for that, so that we can bulk-load things for a set of jobs without having to have Soyuz code know about the bugs DB - right? | 07:10 |
| lifeless | alternative, go async. | 07:10 |
| lifeless | soyuz code is allowed to know about bugs stuff | 07:10 |
| lifeless | its in the same DB | 07:10 |
| xclaesse | after today's Quantal upgrade, evolution is showing lots of black areas :( | 07:10 |
| lifeless | the different 'apps' aren't. | 07:10 |
| cjwatson | Well, yes, but it's not necessarily elegant for it to do so :) | 07:10 |
| lifeless | There are horrible contortions in place to avoid direct use of facilities in other modules. this is an antipattern. | 07:11 |
| lifeless | it evolved due to siloed teams. | 07:11 |
| lifeless | Long term we want a bunch of small elegant services | 07:11 |
| lifeless | some of which will be domain specific | 07:11 |
| lifeless | many others will be task specific but generic and cross domains | 07:11 |
| cjwatson | Sure, but I don't think having soyuz/scripts/processaccepted.py manually reimplement bug notification in order to get global bulk loading is going to be nice | 07:12 |
| lifeless | indeed, I wouldn't do that. | 07:12 |
| cjwatson | That seems like something future developers would swear at | 07:12 |
| lifeless | The problem here as I see is that you have N different notifications | 07:12 |
| lifeless | not that global bulk loading is mising | 07:12 |
| lifeless | you can either decide that you want one notification to N bugs. | 07:12 |
| cjwatson | Well, N bugs are being closed in the same way | 07:12 |
| lifeless | or go async (through a few different strategies) | 07:12 |
| lifeless | N bugs on M packages :) | 07:13 |
| cjwatson | This is accepting one package - M=1 | 07:13 |
| cjwatson | The notifications at present are only different in their subject line; the message chunks are identical | 07:14 |
| chu | .28 | 07:15 |
| lifeless | the cheapest thing to develop would be async | 07:15 |
| lifeless | I suspect. | 07:15 |
| cjwatson | I can see where your suspicion arises. Due to the (I think) inevitable UI warts of asynchrony, I'd like to spend a little time seeing if the cost of the synchronous approach can be brought down first | 07:16 |
| lifeless | be my guest :) | 07:16 |
| cjwatson | It's not like being faster will ultimately go to waste, since an async approach would probably involve some of the same code | 07:16 |
| lifeless | note that one of the async strategies is to implement out of band notifications only | 07:16 |
| lifeless | bug notifications are *already* that most of the time | 07:16 |
| lifeless | so implementing a mechanism where only transient data is captured and spooled | 07:17 |
| lifeless | would have a big payoff and no noticable UI difference. | 07:17 |
| lifeless | an example of transient data being the assignee if its being *unset* | 07:17 |
| cjwatson | Sorry, I think I'm failing to understand that | 07:18 |
| lifeless | say you have a private bug | 07:18 |
| lifeless | and you unassign and remove grants from the assignee so they can't see it anymore. | 07:19 |
| lifeless | We would normally notify them that they are not the assignee anymore. | 07:19 |
| lifeless | today, we capture *all* the recipients to a Job, and the Job just does some minor processing and per-recipient customisation. | 07:20 |
| lifeless | If you don't capture all the recipients to the Job, the person being unassigned and ungranted would not be found when the Job scans for recipients. | 07:20 |
| lifeless | So you need to capture data which is sensitive to the async processing, and merge it with the observed data when the Job runs. | 07:21 |
| === darkdevil_ is now known as dArKd3ViL | ||
| cjwatson | What I'm saying is that converting the core "do we accept or not" logic to a Job *at all* results in problematic UI; I care less about whether the notifications happen immediately | 07:22 |
| cjwatson | The actual acceptance itself is relatively fast | 07:22 |
| cjwatson | Maybe more queries involved in creating builds than is strictly ideal, but it's dwarfed by the notification time | 07:23 |
| lifeless | cjwatson: I'm not suggesting that the core logic moves to a Job | 07:23 |
| cjwatson | So if we were making anything async, it would be "please get round to closing these bugs when you have a minute" | 07:23 |
| lifeless | cjwatson: I'm talking about the needed machinery to move all the heavy lifting of notifications to a Job | 07:23 |
| lifeless | or yes, you could slice it there too | 07:24 |
| lifeless | I'm all for making the existing code more efficient though :) | 07:24 |
| cjwatson | IOW one strategy for this is to have a domain-specific job rather than trying to tackle the general notifications problem immediately - basically just moving close_bugs_for_sourcepackagerelease out | 07:24 |
| lifeless | yah | 07:25 |
| cjwatson | I think we could help a fair bit if we discarded the (implicit) requirement that the closure message for each bug have a "Re: <bug title>" subject, and just made it "Fixed by <name> <version>" or similar | 07:25 |
| lifeless | thats not where the overhead is going | 07:26 |
| cjwatson | Then we could create a single message and link it to every bug; and then it's a "bulk setStatus+newMessage" | 07:26 |
| cjwatson | er linkMessage | 07:26 |
| lifeless | its determining who to send to | 07:26 |
| lifeless | its not sending the messages inline | 07:26 |
| lifeless | thats already async | 07:26 |
| lifeless | the late evaluation that is killing you is person and subscription loading, per-bug. | 07:27 |
| lifeless | I have to run, sorry. | 07:30 |
| lifeless | feel free to mail me and demand more rationale and detailed bits | 07:30 |
| lifeless | after you've had a poke around | 07:30 |
| cjwatson | OK, thanks | 07:32 |
| cjwatson | quantal now open again | 07:51 |
| * pitti looks at the weird ubuntu-drivers-common FTBFS, WTH? regression from last night's python3.2 upload? | 07:53 | |
| pitti | indeed, after dist-upgrading I now get this locally | 07:57 |
| pitti | dear python, if you would at least be so kind to tell me which file you suddenly don't like any more | 07:59 |
| didrocks | I'm afraid your good to add some print on your system :/ | 07:59 |
| pitti | why would copy_scripts() call detect_encoding()? | 08:00 |
| pitti | ah, this now fails to copy an ELF file | 08:01 |
| pitti | didrocks: filed as bug 1026016 | 08:04 |
| ubottu | Launchpad bug 1026016 in python3.2 (Ubuntu) "3.2.3-3 regression: copy_scripts crashes with UnicodeDecodeError" [Undecided,New] https://launchpad.net/bugs/1026016 | 08:04 |
| * pitti changes setup.py to work around this | 08:04 | |
| didrocks | pitti: thanks :) | 08:07 |
| jamespage | is there a standard suffix that should be used with an upstream version number if a orig.tar.gz needs to be re-created due to over-zealous purging of files? | 08:44 |
| jamespage | like +dfsg but the other way round - I was going to go for +repack | 08:44 |
| OdyX | no standard afaik. but +repack is used here and there (see usb-modeswitch e.g.) | 08:46 |
| arand | jamespage: +ds (debian source) is also used sometimes, I've never heard of +us though... | 08:58 |
| cjwatson | I thought +ds was conventionally for tarball-in-tarball packaging | 08:59 |
| cjwatson | (which is mostly obsolete now) | 08:59 |
| OdyX | (or really should be obsolete) | 09:00 |
| arand | I think it can be used for both, and I've seen tarball-in-tarballs that doesn't have that siffix... | 09:00 |
| jamespage | think I'll go with +repack then | 09:06 |
| cjwatson | arand: oh, yeah, anything can be used for anything :) I was just speaking of usual convention. +ds IME was used when people were converting straightforward-tarball packaging into tarball-in-tarball without an upstream version bump. | 09:08 |
| Sweetsha1k | jamespage: ping? | 09:28 |
| Sweetsha1k | jamespage: If you want you have the new LO in main, can you help with this MIR galore needed by the (reenabled) reportbuilder: http://pastebin.ubuntu.com/1097967/ | 09:30 |
| Sweetsha1k | jamespage: that would be swell | 09:30 |
| hrw | does someone had situation when Chromium browser stopped accepting keyboard input? other apps take it fine, chromium is acceptint only mouse | 09:32 |
| jamespage | Sweetsha1k, oh my - http://people.canonical.com/~ubuntu-archive/component-mismatches.svg | 09:35 |
| jamespage | maven explosion.... | 09:36 |
| Sweetsha1k | yikes. | 09:37 |
| Sweetsha1k | can that be demavenfied? | 09:37 |
| seb128 | lol | 09:37 |
| seb128 | nice graph | 09:37 |
| seb128 | where nice is in fact "crazy" | 09:37 |
| jamespage | Sweetsha1k, yes - we need to look at libbtm-java | 09:38 |
| Sweetsha1k | I can disable this for this upload, but if we dont get reportbuilder back in main on quantal, the guys of bug 992232 are already grepping for their forks and torches .... | 09:38 |
| ubottu | Launchpad bug 992232 in libreoffice (Ubuntu) "no libreoffice-report-builder in precise" [Undecided,Fix released] https://launchpad.net/bugs/992232 | 09:38 |
| jamespage | Sweetsha1k, either disable its testsuite or build objenesis with maven-ant-helper | 09:39 |
| jamespage | but there are still 17 additional pkgs for MIR.... | 09:39 |
| jamespage | Sweetsha1k, I can help but not today - have to get something finished this morning and I'm on pilot duty this afternoon (allready postponed once...) | 09:40 |
| === zyga is now known as zyga-afk | ||
| cjwatson | OMG. Well done to whatever it was for managing to render that remotely coherently | 09:41 |
| cjwatson | I've never seen component-mismatches.svg need to render upward-pointing arrows before | 09:41 |
| * pitti could hear graphviz' gears scream | 09:41 | |
| pitti | "Build-Depends: universe" | 09:42 |
| tumbleweed | "Build-Depends: ${reverse-dependencies}" | 09:43 |
| Sweetsha1k | jamespage: since you already isolated the 17 MIR that are still needed, could you drop them here? I would need to file one bug for each (or can we have one bug affecting multiple pkgs for this)? | 10:09 |
| pitti | Sweetsha1k: you can do some grouping, especially for packages that are closely related | 10:15 |
| pitti | but perhaps not just one bug with 17 tasks, that's too hard to track for MIR review | 10:16 |
| pitti | perhaps "5 trivial java libs" in one bug, another one for a different kind of package, etc. | 10:16 |
| cjwatson | Also Launchpad doesn't really deal particularly well with bugs with enormous numbers of tasks | 10:17 |
| Sweetsha1k | pitti: <grumpie-old-man-voice>for me they are all in the java crap required by reportbuilder group</> | 10:17 |
| pitti | heh | 10:18 |
| pitti | Sweetsha1k: it seems this is coming up over and over again -- does the disabling of reportbuilder keeps getting accidentally reverted, or is that another deliberate attempt to enalbe it again? | 10:18 |
| Sweetsha1k | pitti, cjwatson: I will go the 5 pkg per bug suggestion ... note that most of these MIR shouldnt be to heavy discussed. | 10:19 |
| Sweetsha1k | pitti: reportbuilder was disabling in early in precise because of the maven-include-all-universeness of it and not reenabled for timing restraints. Some of the maveness is gone, but it seems some is still left. | 10:21 |
| Sweetsha1k | s/it/its deps/ | 10:21 |
| mpt | Is there a way to upgrade from 12.04 to Q for testing without using update-manager? The update-manager -d method crashed (bug 1026068) | 10:42 |
| ubottu | Launchpad bug 1026068 in update-manager (Ubuntu) "Quantal Crashes as upgrade starts" [Undecided,New] https://launchpad.net/bugs/1026068 | 10:42 |
| jamespage | Sweetsha1k, sorry - have my head in unpicking minified javascript from a new package - did not want to lose my place! | 10:43 |
| brendand | mpt - sed /precise/quantal/ in sources.list and apt-get update/upgrade :/ | 10:45 |
| brendand | mpt, probably dodgy | 10:45 |
| mpt | brendand, yeah, that misses out on the special upgrade scripts | 10:46 |
| cjwatson | Not much in the way of quirks for quantal anyway | 10:47 |
| mpt | ok, we'll do that then, thanks | 10:49 |
| === zyga-afk is now known as zyga | ||
| mpt | (For the benefit of anyone reading the logs later, the proper terminal way is apparently "sudo do-release-upgrade -d") | 10:54 |
| Sweetsha1k | seb128: building 3.6.0~rc2 without reportbuilder right now. (yes, rc2 -- hopefully nothing too bad happened since rc1) | 11:02 |
| seb128 | Sweetsha1k, great | 11:02 |
| === cpg is now known as cpg|away | ||
| === MacSlow is now known as MacSlow|lunch | ||
| Sweetsha1k | every time i am annoyed by lp being slow or timing out, I remember myself about the great mass of obsolete junk(https://launchpad.net/obsolete-junk) in it ... | 11:44 |
| pitti | Sweetsha1k: WTH.. | 11:47 |
| Sweetsha1k | pitti: explains quite a bit, doesnt it ;) | 11:48 |
| Sweetsha1k | pitti: I think we are including that project in LibreOffice too though, I guess. However, it is called binfilter at LibreOffice. | 11:49 |
| pitti | haha | 11:49 |
| seb128 | cjwatson, hey, bash-completion needs to be merged with Debian, do you plan to do it (asking because it has your name next to it on merges.u.c) or would you welcome somebody else doing it? | 12:36 |
| seb128 | cjwatson, "needs to" is because the new version uses /usr rather than /etc for completion snippets and some GNOME packages (e.g glib) started to install to the new location, which doesn't work on quantal with our outdated version | 12:37 |
| cjwatson | I've been failing to get round to that and would welcome somebody else doing it | 12:37 |
| seb128 | cjwatson, ok, I will do it, thanks | 12:37 |
| cjwatson | Thanks | 12:38 |
| killown | ubuntu developers can you fix this https://bugs.launchpad.net/ubuntu/+source/wine1.4/+bug/944321/comments/21 | 12:42 |
| ubottu | Launchpad bug 944321 in wine1.4 (Ubuntu) "apt-get build-dep script for wine missing xorg and " [Undecided,Confirmed] | 12:42 |
| === _salem is now known as salem_ | ||
| pitti | ev: followed up to your apport MP | 13:06 |
| jamespage | @pilot in | 13:06 |
| === udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal A2 released! | Archive: open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: jamespage | ||
| ev | thanks, looking into it now | 13:06 |
| === MacSlow|lunch is now known as MacSlow | ||
| === masACC is now known as maswan | ||
| rbasak | cyphermox: could I have your comment on bug 1024408 please? | 13:48 |
| ubottu | Launchpad bug 1024408 in ubuntu-meta (Ubuntu) "Quantal installs do not include software-properties-common by default" [Undecided,Confirmed] https://launchpad.net/bugs/1024408 | 13:48 |
| cyphermox | rbasak: yeah, it didn't come default | 13:49 |
| rbasak | cyphermox: is there any other bug here apart from that it isn't default? | 13:49 |
| cyphermox | but Javier is correct, there is a missing depends on python3-software-properties | 13:50 |
| rbasak | cyphermox: wouldn't the dependency be the other way round? Usually other packages depend on the -common package | 13:50 |
| cyphermox | python3-software-properties doesn't currently depend on it, and afaik doesn't need it for anything | 13:51 |
| cyphermox | OTOH, software-properties-common needs some of the python libraries in python3-sotware-properties for add-apt-repository to work properly | 13:51 |
| rbasak | I see, OK. So the bug is entirely valid. | 13:51 |
| cyphermox | yes | 13:52 |
| rbasak | (and in addition, if I want -common in the server seed, I should open another bug on that) | 13:52 |
| cyphermox | yeah | 13:52 |
| cyphermox | I can fix the depends now | 13:52 |
| rbasak | OK, thanks! I guess it's not worth me doing a debdiff only for you to sponsor it :) | 13:53 |
| cyphermox | well, nm, it's already there | 13:53 |
| rbasak | Oh. So it is | 13:54 |
| pitti | bdmurray: ah, I was about to upload apport 2.0.1-0ubuntu12 to precise-proposed when I saw that you already uploaded one | 13:55 |
| pitti | bdmurray: can you please commit stuff to the bzr branch, so that we avoid stepping on each other's toes? thanks! | 13:55 |
| pitti | bdmurray: I'll merge your upload there | 13:55 |
| pitti | bdmurray: done, and reuploaded | 13:59 |
| pitti | ev: do you still need https://code.launchpad.net/~ev/apport/native-package-field/+merge/115542 then? | 14:01 |
| ev | ah no, deleting now | 14:02 |
| pitti | ev: or is the existing tag sufficient? | 14:02 |
| pitti | ev: ah, ok; I really appreciate that you discussed in a MP first, thanks! | 14:02 |
| ev | sure thing - always best to check with these things, minor as they may initially seem | 14:02 |
| tkamppeter | Anyone around who can help me on getting syncpackage working? | 14:04 |
| tkamppeter | It gives a Python Backtrace with gnomekeyring.IOError | 14:06 |
| tumbleweed | tkamppeter: see the entry for 0.199 in /usr/share/doc/ubuntu-dev-tools/NEWS.Debian.gz | 14:08 |
| cjwatson | tkamppeter: 0.119 | 14:09 |
| cjwatson | err | 14:09 |
| cjwatson | tumbleweed: 0.119 | 14:09 |
| tumbleweed | yes, that | 14:09 |
| tkamppeter | tumbleweed, thanks, but it does not work for me. I am not SSHed in, but simply in a terminal window in both Precise and Quantal cases. Doing "export `dbus-launch`" anyway does not help, uninstalling python-gnomekeyring does not work as system-config-printer needs it. | 14:24 |
| tumbleweed | tkamppeter: a normal gnome session? | 14:24 |
| tumbleweed | does gnome keyring work for other things? | 14:25 |
| tkamppeter | tumbleweed, a Unity session. | 14:25 |
| tumbleweed | erm, yes that :) | 14:25 |
| tkamppeter | tumbleweed, what else uses gnome-keyring, how can I quickly test? | 14:26 |
| tumbleweed | network manager | 14:27 |
| tkamppeter | tumbleweed, what works in both cases is apport-collect, but I am not sure whether it uses gnome-keyring (pitti?). | 14:27 |
| pitti | launchpadlib does | 14:28 |
| tkamppeter | tumbleweed, I have internet access on both machines (wired) and the Precise also wireless, this should come from network-manager or do I need to test something else? | 14:28 |
| tkamppeter | pitti, so this means that gnome-keyrinmg works for me as I have apport-collected for both systems in bug 1026146. | 14:29 |
| ubottu | Launchpad bug 1026146 in ubuntu-dev-tools (Ubuntu) "syncpackage gives Python traceback on gnomekeyring.IOError" [Undecided,New] https://launchpad.net/bugs/1026146 | 14:29 |
| tkamppeter | tumbleweed, I have reported bug 1026146 for the syncpackage problem. | 14:29 |
| tumbleweed | if you fire up seahorse, can you see the contents of your keyring? | 14:30 |
| agoradf | helo ther are som one spech italian? | 14:43 |
| tkamppeter | tumbleweed, I have 2 PGP keys and 2 SSH keys, one of tne PGP keys I use also for dput. One SSH key is to log in on remote servers and another one to commit to Fedora repos. | 14:44 |
| ogra_ | agoradf, i think there is an #ubuntu-it channel | 14:44 |
| agoradf | yes but have 0 user ok tanks | 14:45 |
| tkamppeter | tumbleweed, seahorse, though it seems to work, writes the following on the console where I started it: | 14:48 |
| tkamppeter | Gkr-Message: secret service operation failed: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. | 14:49 |
| tumbleweed | same thing we see from launchpadlib | 14:49 |
| tumbleweed | sounds very much like you don't have a running gnome-keyring-d | 14:49 |
| tumbleweed | *daemon | 14:50 |
| tkamppeter | tumbleweed, this was on Quantal, on Precise I have seahorse not displaying my keys and in addition a | 14:50 |
| tkamppeter | ** Message: failed to refresh: Couldn't communicate with key ring daemon | 14:50 |
| tumbleweed | sounds like the same problem | 14:50 |
| tkamppeter | tumbleweed, I have started gnome-keyring-daemon manually on Precise and now syncpackage and seahorse work. | 14:52 |
| tumbleweed | it should start at login. Don't know why it isn't | 14:53 |
| * tumbleweed disclaims all knowledge of the desktop | 14:53 | |
| tkamppeter | tumbleweed, same on Quantal, whereas seahorse already worked before, but now it shows more keys/passwords. | 14:54 |
| tkamppeter | tumbleweed, thanks. I will add a comment to the bug report. | 14:54 |
| davmor2 | kenvandine: Hey dude, just thought I'd give you a quick headsup the updated empathy in Quantals call/ dial into conference feature is working, so it is just a precise issue :) | 14:55 |
| davmor2 | kenvandine: also I've written a bug for the app in Quantal the dial pad button is missing an icon, other than that it seem way better :) | 14:56 |
| tkamppeter | Any Perl expert around? How do I determine whether File::Temp is in perl-base or whether it requires full perl? | 15:00 |
| mdeslaur | tkamppeter: it's not, it's in perl-modules | 15:01 |
| kenvandine | davmor2, thx | 15:02 |
| mdeslaur | tkamppeter: just look at the package contents: /usr/share/perl/5.14.2/File/Temp.pm | 15:02 |
| tkamppeter | mdeslaur, so it needs perl-base, perl, and perl-modules? | 15:02 |
| mdeslaur | tkamppeter: just 'perl' should be sufficient to pull perl-modules in | 15:03 |
| mdeslaur | but 'perl-base' isn't | 15:03 |
| cjwatson | Yeah, you should not normally depend on perl-modules directly; depend on perl if you need something in there | 15:06 |
| cjwatson | Be careful not to rely on perl/perl-modules for anything that might run with perl unconfigured during upgrades though (particularly anything run from a dpkg trigger); in such cases you may need to add code to fall back to calling tempfile or mktemp or similar | 15:07 |
| mdeslaur | also, we don't have perl-modules on the desktop cd, so don't rely on that for stuff that needs to ship on it | 15:08 |
| tkamppeter | mdeslaur, cjwatson, thank you very much. | 15:14 |
| killown | also apt-get install build-essential:i386 is broken on 64bits | 15:21 |
| === Sweetsha1k is now known as Sweetshark | ||
| diwic | Either xargs is broken, or I'm completely stupid. If I do ' ls | xargs echo "Hi " ', that should say "Hi Documents", "Hi Downloads" etc, right? | 15:30 |
| diwic | I get "Hi Documents Downloads"... | 15:31 |
| ion | That’s exactly how it is supposed to behave. | 15:32 |
| micahg | diwic: ls | xargs --I{} echo "Hi " {} | 15:32 |
| micahg | diwic: -I, not --I | 15:33 |
| cjwatson | diwic: or xargs -n1 | 15:33 |
| diwic | micahg, cjwatson, ion thanks all and sorry for asking a support question in the wrong channel | 15:33 |
| diwic | xargs -n1 seems indeed the simplest option | 15:34 |
| stgraber | Laney: did you file/find a bug for that hang on shutdown/reboot of containers? | 15:47 |
| stgraber | Laney: I started seeing it on my quantal machines here so I'm going to make sure it's properly escalated and fixed ASAP as it's likely to affect quite a bit more than just lxc | 15:48 |
| jamespage | is there any general coordination around gcc updates? there is a sensible MP for gcc-4.7 in the sponsorship queue but I see that doko appears to be the sole changelog author for as far back as I can see.... | 15:51 |
| ogra_ | jamespage, doko maintains it in debian as well ... | 15:54 |
| === Ursinha` is now known as Ursinha | ||
| ogra_ | while teher is coordination (and likely even other occasional uploaders) he is definitely the central person for it | 15:55 |
| jamespage | ogra_, any idea where he is? I've not seem him since last week on irc | 15:55 |
| ogra_ | vacation | 15:55 |
| ogra_ | and debconf before | 15:56 |
| jamespage | ogra_, thats what I thought | 15:56 |
| ogra_ | probably infinity can help you if you ask nicely :) | 15:56 |
| jamespage | ogra_, I think I'll leave it until doko is back - it looks like the transition needs to happen for most core tooling | 15:58 |
| jamespage | insanely its for ia64 architectures only AFAICT | 15:59 |
| ogra_ | that still exists ? | 15:59 |
| jamespage | anyway | 15:59 |
| jamespage | @pilot out | 15:59 |
| === udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal A2 released! | Archive: open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: | ||
| jamespage | ogra_, it does in Debian - unless that is actually a false positive in the NBS report and can be ignored. | 16:00 |
| ogra_ | ah, debian, yeah ... | 16:00 |
| infinity | jamespage: Which MP is this? | 16:02 |
| infinity | jamespage: I'm playing fake doko while he's on vacation. | 16:03 |
| ogra_ | infinity, including the limping ? | 16:03 |
| infinity | ogra_: He's stopped doing that. | 16:04 |
| ogra_ | ah | 16:04 |
| === i23 is now known as py_can | ||
| psivaa | rbasak, i have added a comment on bug 1024408 to the effect the original bug is not still fixed | 16:42 |
| ubottu | Launchpad bug 1024408 in software-properties (Ubuntu) "Quantal installs do not include software-properties-common by default" [Undecided,Confirmed] https://launchpad.net/bugs/1024408 | 16:42 |
| rbasak | psivaa: the "not in server seed" bug is bug 439566. add-apt-repository has never been pulled in by the server seed | 16:43 |
| ubottu | Launchpad bug 439566 in ubuntu-meta (Ubuntu) "add python-software-properties to ubuntu-standard" [Wishlist,Triaged] https://launchpad.net/bugs/439566 | 16:43 |
| psivaa | rbasak, this is not about apt-add-repository it was about software-properties-common | 16:44 |
| micahg | rbasak: it could be seeded directly in the server seed if it doesn't need to be in standard | 16:44 |
| rbasak | micahg: I think it should be in standard. Lots of places use it. Eg. on an LP PPA page, the instructions are to use it. | 16:45 |
| rbasak | micahg: on desktop it happens to be installed, but this may not necessarily be the case in future. I think we should seed it directly | 16:45 |
| rbasak | psivaa: why should software-properties-common be in the server seed? | 16:45 |
| micahg | rbasak: a server without network services wouldn't need it | 16:45 |
| rbasak | micahg: so your vote is against add-apt-repository being in a default server install? | 16:46 |
| micahg | err...I mean internet access ;) | 16:46 |
| micahg | rbasak: no, I'm against it being in standard | 16:46 |
| psivaa | rbasak, shouldn't it? i think pitti thought it should and i think you have commented in this bug "I'll open a separate bug to add software-properties-common to the server seed." | 16:47 |
| rbasak | psivaa: add-apt-respository is inside software-properties-common | 16:47 |
| micahg | rbasak: here's the definition of standard: https://wiki.ubuntu.com/SeedManagement#Standard | 16:47 |
| rbasak | psivaa: to add add-apt-repository to a default server install, it must be added to some seed | 16:47 |
| rbasak | micahg: "a variety of networking clients and tools" | 16:48 |
| psivaa | rbasak, yes but as i said this is not about apt-add-repository its about software-properties-common not being in the server seed | 16:48 |
| rbasak | micahg: It's a stretch, but I think that makes add-apt-repository fair game | 16:48 |
| rbasak | psivaa: so why should software-properties-common be in a server seed? | 16:48 |
| psivaa | rbasak, shouldn't it? i think pitti thought it should and i think you have commented in this bug "I'll open a separate bug to add software-properties-common to the server seed." | 16:49 |
| rbasak | psivaa: the reason I say it should is for add-apt-repository, and this is bug 439566 | 16:49 |
| ubottu | Launchpad bug 439566 in ubuntu-meta (Ubuntu) "add python-software-properties to ubuntu-standard" [Wishlist,Triaged] https://launchpad.net/bugs/439566 | 16:49 |
| rbasak | psivaa: you identified a separate dependency problem which has since been fixed | 16:49 |
| rbasak | psivaa: there are two issues identified here, and there are two bugs | 16:49 |
| micahg | rbasak: hrm, it can be used for local repos as well, so I guess it would be ok | 16:49 |
| psivaa | rbasak, yes the dependency issue is fixed but that was not the original intention of the bug | 16:50 |
| rbasak | psivaa: never mind what anyone else said. You reported this bug. Why did you report it? What do you want? What's the justification for what you want? | 16:50 |
| rbasak | micahg: ok, thanks | 16:51 |
| micahg | rbasak: you'll want to check the dependency chain though to make sure that it doesn't bloat standard | 16:51 |
| rbasak | micahg: I'll update bug 439556 and submit a MP | 16:51 |
| ubottu | Error: Launchpad bug 439556 could not be found | 16:51 |
| rbasak | micahg: sure | 16:51 |
| rbasak | bug 439566 | 16:51 |
| ubottu | Launchpad bug 439566 in ubuntu-meta (Ubuntu) "add python-software-properties to ubuntu-standard" [Wishlist,Triaged] https://launchpad.net/bugs/439566 | 16:51 |
| micahg | rbasak: and definitely a recommends, not a depends | 16:52 |
| rbasak | psivaa: if the original intention of your bug is to have add-apt-repository by default, then you have a dupe of 439566. If it is for some other reason, then please say why | 16:53 |
| rbasak | micahg: ack | 16:53 |
| psivaa | rbasak, well, no one can have a definite reason for any package to be included in the default install, i agreed with pitti that *software-properties-common* should be included in the server seed | 16:54 |
| rbasak | pitti: did you want software-properties-common seeded for add-apt-repository or something else? | 16:55 |
| rbasak | psivaa: OK, I'll mark your bug as a dupe of 439566. | 16:55 |
| psivaa | rbasak, ok go ahead, ill need to talk to pitti about that too and see if we need a separate bug for that | 16:57 |
| rbasak | psivaa: hold on a moment | 16:57 |
| rbasak | psivaa: do you realise that add-apt-repository is now *in* software-properties-common? | 16:57 |
| rbasak | psivaa: sorry I should have mentioned that | 16:57 |
| psivaa | rbasak, yes that i realise | 16:58 |
| rbasak | To resolve 439566, which is really about adding add-apt-repository by default, I'll be seeding software-properties-common | 16:58 |
| rbasak | So why do you want another bug? | 16:58 |
| psivaa | rbasak, do you have a bug to seed software-properties-common | 16:59 |
| rbasak | psivaa: it's 439566. I haven't changed the subject line | 16:59 |
| rbasak | I'll do that now | 16:59 |
| psivaa | rbasak, the bug i raised is for that | 17:00 |
| rbasak | psivaa: so you have a dupe of bug 439566 then (which I've just renamed) | 17:01 |
| psivaa | rbasak, the bug 102448 is i thought for the seeding of software-properties-common | 17:01 |
| ubottu | Launchpad bug 439566 in ubuntu-meta (Ubuntu) "add software-properties-common to ubuntu-standard" [Wishlist,Triaged] https://launchpad.net/bugs/439566 | 17:01 |
| ubottu | Launchpad bug 102448 in Ubuntu "Netgear wpn511 does not activate properly" [Undecided,Fix released] https://launchpad.net/bugs/102448 | 17:01 |
| psivaa | rbasak, ok now i see | 17:03 |
| psivaa | rbasak, I agree to mark 1024408 dupe now | 17:05 |
| rbasak | psivaa: cool, thanks. Sorry, I could have communicated what I was trying to say better. | 17:06 |
| psivaa | rbasak, that's ok :) me being (kind of) new did not help either :) | 17:07 |
| === cpg|away is now known as cpg | ||
| === cpg is now known as cpg|away | ||
| alazare619 | hey im having a issue | 17:41 |
| alazare619 | with livecd-rootfs i have package live set to ubiquity-frontend-kde | 17:41 |
| alazare619 | how do i call it? | 17:41 |
| cjwatson | Call what? | 17:42 |
| alazare619 | ubiquit-frontend-kde | 17:42 |
| cjwatson | You mean when you're building the image, or when you boot the live image? | 17:42 |
| alazare619 | both | 17:42 |
| alazare619 | iso-hybrid image | 17:42 |
| alazare619 | when it boots it wont post to ubiquity | 17:43 |
| cjwatson | Sorry, I'm really having trouble making sense of this question | 17:43 |
| alazare619 | ok, i built a image all the way through with livecd-rootfs | 17:43 |
| alazare619 | but when i go to load the image | 17:43 |
| cjwatson | You can run just the "ubiquity" command to start the installere | 17:43 |
| cjwatson | *installer | 17:43 |
| alazare619 | it wont default to ubiquity-installer-kde | 17:43 |
| alazare619 | should ubiquity-installer be put into chroot? | 17:43 |
| alazare619 | or binary? | 17:43 |
| cjwatson | Uh, neither really. "add_package live ubiquity-frontend-kde" | 17:44 |
| cjwatson | It should end up in the squashfs | 17:44 |
| cjwatson | What the image boots into is controlled by kernel parameters | 17:44 |
| SpamapS | bryceh: http://launchpadlibrarian.net/109793324/mesa_8.0.2-0ubuntu3.1_8.0.3-0ubuntu0.1.diff.gz .. did you accidentally base your SRU upload to precise-proposed off quantal instead of precise-updates ? | 17:47 |
| alazare619 | cjwatson, ok is there a ubiquity that doesnt use just kde or gtk libs | 17:48 |
| alazare619 | like is there a way to incorp a alternate installer? | 17:48 |
| cjwatson | Those are two quite different questions. | 17:49 |
| cjwatson | There is a text frontend for ubiquity, but it's not desperately well used or tested. | 17:49 |
| cjwatson | (ubiquity-frontend-debconf) | 17:49 |
| alazare619 | ok what about using the alternate installer method | 17:49 |
| alazare619 | that is offered for say xubuntu etc | 17:50 |
| alazare619 | the "debian based" installer | 17:50 |
| cjwatson | Alternate installers aren't built using live-build. | 17:50 |
| alazare619 | i understand that | 17:50 |
| alazare619 | other then that is there a ubiquity that doesnt depend on kde or gtk im trying to build a iso with only qt apps | 17:50 |
| cjwatson | You can do it with our cdimage branch plus debian-cd; the entry point is bin/cron.daily. Considerable setup required. It needs a full local mirror. | 17:50 |
| cjwatson | The "KDE" ubiquity frontend doesn't use that much of KDE. | 17:50 |
| bryceh | Spads, nope | 17:51 |
| cjwatson | It's just kdecore and kdeui. | 17:51 |
| bryceh | SpamapS, nope, all the changes which were on the precise-updates tree are cherrypicks from 8.0.3 | 17:51 |
| cjwatson | And if a patch to make it pure Qt weren't too unreasonable, we'd probably take it. | 17:52 |
| alazare619 | ok and last question i have before i dive back into this is what would be needed to use livecd-rootfs /live-build with a ppa | 17:52 |
| SpamapS | bryceh: its rather confusing to have a published version disappear from the changelog though. | 17:52 |
| bryceh | SpamapS, well, all being "one" | 17:52 |
| cjwatson | alazare619: You could crib the add_ppa function from ubuntu-defaults-image. | 17:52 |
| alazare619 | i added a file with somerepo.list.chroot to archives (with the repo deb http://whatever) and somerepo.key.chroot with its signing key but its not picking it up | 17:52 |
| SpamapS | bryceh: consider the case where somebody has 8.0.2-0ubuntu3.1 and wants to see what changed since then | 17:52 |
| cjwatson | If that doesn't work you'll have to debug it locally, I expect. | 17:53 |
| SpamapS | bryceh: I'm not saying its wrong, but I've not ever seen it done, nor do I feel comfortable with it. | 17:53 |
| cjwatson | Maybe turn on shell tracing (set -x) in /usr/share/live/build/scripts/build/lb_chroot_archives and see what it thinks it's doing. | 17:53 |
| bryceh | SpamapS, so it would make you feel better if I s/(8.0.2-0ubuntu4) quantal/(8.0.2-0ubuntu3.1) precise-proposed/ ? | 17:56 |
| SpamapS | bryceh: actually yes, that would be perfect. :) | 17:58 |
| alazare619 | cjwatson, i discovered i could do a hook its dirty bbut works for apt-get install python-software-properties then add the ppa at the end and pull the package i want from it | 17:59 |
| alazare619 | is there any way to sort the order hooks run in? | 17:59 |
| bryceh | SpamapS, on bug #1013881 I don't think you should be blocking it. The change is to remove a patch which failed SRU, so really it's irrelevant what the status of it is in quantal. The patch can't be backported because it causes breakage, thus should be dropped. | 17:59 |
| ubottu | Launchpad bug 1013881 in xkeyboard-config (Ubuntu) "Right-Ctrl key broken on French OSS keyboard" [High,In progress] https://launchpad.net/bugs/1013881 | 17:59 |
| alazare619 | if i name the hook file name 001_somename.sh and 002_somename.sh will 001 run before 002? | 17:59 |
| SpamapS | bryceh: not sure what you mean. It can't be fixed in quantal? Wouldn't that be 'Invalid' or 'Won't Fix' then, not 'In Progress' ? | 18:00 |
| SpamapS | bryceh: the point is just to make sure the issue is handled in the dev release.. not that it is directly backported. | 18:01 |
| SpamapS | bryceh: I can of course waive that need if there's something preventing the fix from landing in quantal | 18:01 |
| SpamapS | like "I'm really busy and I promise I'll do it before October" | 18:02 |
| slangasek | barry: ah, thanks for the quick turnaround on the apturl bug- | 18:03 |
| SpamapS | anyway, time for a quick wrist break | 18:03 |
| slangasek | SpamapS: so I've just followed up on that bug report. 1013881 was a report *against* a previous precise-proposed version of the package; the patch in question has been backed out of the SRU as a result of this bug report; quantal should not hold up the SRU for this bug | 18:04 |
| slangasek | because in effect, that bug is already "fix released" in precise | 18:04 |
| slangasek | by virtue of the SRU itself | 18:05 |
| bryceh | SpamapS, let me rephrase. A fix from quantal was backported to precise, and proposed as an SRU. The SRU failed verification, thus it should not be present in precise. However it was accidentally uploaded to precise anyway. I'm saying it should be removed from precise, regardless of its status in quantal. | 18:05 |
| bryceh | SpamapS, what to do in quantal is still sort of up to various upstream discussions that are still on-going. | 18:06 |
| cjwatson | alazare619: They're run in shell pattern expansion order, so yes, 001 will come before 002. | 18:08 |
| cjwatson | Or just alphabetical order if you like. | 18:08 |
| alazare619 | alpha-numerical order | 18:08 |
| alazare619 | yea | 18:08 |
| bryceh | SpamapS, mesa_8.0.3-0ubuntu0.1_source.changes uploaded with resync'd changelog | 18:08 |
| cjwatson | Technically the order probably depends on the locale. LC_COLLATE=C if you care. | 18:09 |
| barry | slangasek: no worries. an api got changed incompatibly out from underneath it | 18:10 |
| SpamapS | bryceh: AHH ok so the bug is to remove it, so quantal is irrelevant. Got it. I have to run but I'll review your mesa upload again and take a second look at xkb when I get back | 18:13 |
| slangasek | SpamapS: fwiw I'm surprised this issue is coming up at -updates promotion time, since the SRU procedure says that's all supposed to be sorted before accepting into -proposed | 18:15 |
| slangasek | (and in this case it was, it just wasn't obvious how) | 18:16 |
| slangasek | SpamapS: I'm satisfied that xkeyboard-config is correct, I'll just promote it now and save you any further trouble :) | 18:17 |
| dobey | when was C.UTF-8 enabled as a locale in Ubuntu? | 18:25 |
| bryceh | slangasek, thanks | 18:41 |
| slangasek | n/p | 18:42 |
| mterry | SpamapS, ping about gem2deb MIR | 18:49 |
| mterry | SpamapS, any ideas about the circular dependency with ruby-rspec? | 18:54 |
| dobey | anyone know about C.UTF-8 locale at all? | 18:55 |
| sladen | dobey: I don't. Was it perhaps a machine in "C", with the actions of a script doing sed -e s/.*/.UTF-8/ during the script in ~2005 (IIRC 4.10 was not UTF-8) | 18:59 |
| dobey | sladen: afaict, 10.04 and 11.04 don't have C.UTF-8 either | 19:00 |
| sladen | dobey: or is the question when the default was switched? (from iso8859-15 -> UTF-8, which IIRC was 5.04) | 19:01 |
| dobey | sladen: the default for C was never iso8859-15 afaik. it would have been us-ascii before | 19:01 |
| sladen | dobey: either way, pitti appears in the changelogs. pitti: ^^ ? | 19:04 |
| bdmurray | @pilot in | 19:04 |
| === udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal A2 released! | Archive: open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: bdmurray | ||
| dobey | or well, not us-ascii exactly i guess | 19:05 |
| dobey | LC_ALL=C python -c "import sys; print sys.getfilesystemencoding()" | 19:06 |
| dobey | ANSI_X3.4-1968 | 19:06 |
| infinity | dobey: C.UTF-8 showed up in precise. | 19:10 |
| infinity | dobey: Well, it might have showed up earlier (I'd have to check changelogs), but it didn't work correctly until precise. :P | 19:11 |
| dobey | ah | 19:12 |
| infinity | dobey: Which reminds me, I need to petition for us to switch the default system locale some day. That'll be a heated and fun discussion. | 19:12 |
| dobey | well i think it works in oneiric | 19:13 |
| infinity | dobey: FSVO "works". It's not correct. | 19:13 |
| infinity | Though, I suppose it mostly behaves. | 19:14 |
| infinity | dobey: Were you actually hoping to rely on it in some fashion, or just exercising curiosity? | 19:15 |
| dobey | also, it seems pretty obvious that "tlh" should be the default. no reason there needs to be a heated discussion about that. | 19:15 |
| infinity | Real nerds don't speak tlh, they just make fun of those who do. | 19:16 |
| dobey | infinity: i need UTF-8, and I thought C.UTF-8 was working on everything I am required to care about; but as it's not the case I guess I'll just switch to using en_US.UTF-8 for the places where I need to tweak | 19:16 |
| dobey | infinity: exactly (sarcasm isn't easily visible via IRC). :) | 19:18 |
| infinity | dobey: From precise on, C.UTF-8 should be fairly sane. It *might* be sane for oneiric, depending on what you need. | 19:18 |
| infinity | dobey: Where it fails sanity in oneiric might be in collation of characters over 255, and a few other odd corner cases, which you might not give a crap about. | 19:18 |
| dobey | mostly i just need the UTF-8 part, because ANSI_X3.4-1968 == insanity | 19:18 |
| dobey | yeah i probably don't care about those corner cases. but i do have to care about lucid for another 9 months | 19:19 |
| === roaksoax_ is now known as roak | ||
| === roak is now known as andreserl | ||
| === andreserl is now known as roaksoax_ | ||
| === barry` is now known as barry | ||
| === Daviey_ is now known as Daviey | ||
| === Bluefoxicy_ is now known as Bluefoxicy | ||
| === roaksoax_ is now known as roaksoax | ||
| === RainCT_ is now known as RainCT | ||
| SpamapS | hm, seems diffs linked to from +queue are getting the wrong host: 'lplibrarian-private-download.internal:8000' | 20:14 |
| infinity | SpamapS: Known bug. | 20:15 |
| SpamapS | ah ok | 20:15 |
| SpamapS | kind of kills my ability to efficiently do SRU reviews for the day though. :-( | 20:16 |
| infinity | Yeah, I was just fetching sources and diffing old skool. | 20:16 |
| SpamapS | infinity: known "omg we have to fix this now" bug, or "when we get to it" ? | 20:16 |
| infinity | You could also try a DC host that has access to that URL. | 20:16 |
| infinity | Bug #1025515 | 20:17 |
| ubottu | Launchpad bug 1025515 in Launchpad itself "LP diffs are being linked at http://lplibrarian-private-download.internal:8000" [Critical,Fix committed] https://launchpad.net/bugs/1025515 | 20:17 |
| SpamapS | like people.c.c ? | 20:17 |
| infinity | Possibly. | 20:17 |
| SpamapS | cause diffing manually is pretty ridiculously painful ;) | 20:18 |
| stgraber | I'm getting 403 from lillypilly | 20:18 |
| infinity | SpamapS: Oh, and try to avoid the highbank-related SRUs. I need to go over those with a fine-toothed comb. | 20:19 |
| SpamapS | I wouldn't touch those anyway :) | 20:19 |
| lifeless | SpamapS: infinity: that url bypasses acls, only LP hosts themselves have access to it | 20:22 |
| SpamapS | yeah and without ssh -X'ing, its also not useful | 20:22 |
| SpamapS | and I doubt any DC hosts have a decent browser :) | 20:23 |
| SpamapS | trying to review SRU's w/ 5+ bugs is pretty ridiculous w/o queuediff | 20:23 |
| * SpamapS will just shut it down until LP is fixed | 20:23 | |
| lifeless | SpamapS: bug 1025515 | 20:26 |
| ubottu | Launchpad bug 1025515 in Launchpad itself "LP diffs are being linked at http://lplibrarian-private-download.internal:8000" [Critical,Fix committed] https://launchpad.net/bugs/1025515 | 20:26 |
| SpamapS | lifeless: yes I'm subscribed. Will return to SRU processing when that lands. | 20:26 |
| infinity | Sweetshark: Uhm, build-conflicting against the default compiler (which libreoffice does on !x86) isn'ta terribly winning strategy. | 20:27 |
| infinity | lifeless: Your bug link was about 20 lines too late. | 20:28 |
| lifeless | infinity: doh | 20:28 |
| === Riddelll is now known as Riddell | ||
| * penguin42 wonders if libwebkitgtk-1.0's debug .so being 1.1GB is expected or actually a bug | 20:42 | |
| === cjwatson_ is now known as cjwatson | ||
| === jvw_ is now known as jvw | ||
| Laney | stgraber: bug 1021471 | 21:06 |
| ubottu | Launchpad bug 1021471 in linux (Ubuntu) "stuck on mutex_lock creating a new network namespace when starting a container" [Medium,Incomplete] https://launchpad.net/bugs/1021471 | 21:06 |
| stgraber | Laney: thanks | 21:06 |
| Laney | I haven't been using it heavily enough recently to trigger it | 21:07 |
| stgraber | I can reproduce it really easily here, so I'll try the scheduler change and see if I still get it | 21:08 |
| Laney | how? | 21:08 |
| Laney | after I reboot I can't repro on demand | 21:08 |
| stgraber | lxc-start -n <container> => reboot in the container | 21:08 |
| stgraber | happens 50% of the time here | 21:08 |
| Laney | aha | 21:08 |
| * Laney tries that | 21:08 | |
| stgraber | but the test machine is a slow atom single core, so that might explain why it's easy to reproduce here ;) | 21:09 |
| Laney | nah, no good | 21:12 |
| === salem_` is now known as _salem | ||
| === cpg|away is now known as cpg | ||
| === TheMuso` is now known as TheMuso | ||
| bdmurray | @pilot out | 23:01 |
| === udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal A2 released! | Archive: open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: | ||
| === wgrant_ is now known as wgrant | ||
| BenC | The build failure for libreoffice makes me unhappy | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
