| === vorian is now known as v | ||
| === racarr is now known as racarr|themanbur | ||
| === racarr|themanbur is now known as racarr | ||
| xnox | kirkland: did you mean to upload +byobu (5.46) released; urgency=low into raring? that's like even ahead of saucy =) | 00:51 |
|---|---|---|
| cjwatson | xnox: drizzle's latest build failure looks like it could be improved by a merge from Debian - do you think you could do the honours as TIL? | 00:57 |
| xnox | cjwatson: looking. | 00:58 |
| sergiusens | cjwatson: hey, any idea how to solve this? http://pastebin.ubuntu.com/5882703/ | 01:25 |
| sergiusens | that's during lb | 01:26 |
| cjwatson | sergiusens: looks like the .click file is somewhere not readable by the clickpkg user | 01:26 |
| cjwatson | like a mode 700 directory owned by some other user or something | 01:27 |
| sergiusens | cjwatson: a good, let me check, thanks | 01:27 |
| cjwatson | BTW I think you should lose the -app suffix there | 01:28 |
| cjwatson | Makes sense for the .deb packaging, not so much for click | 01:28 |
| * cjwatson -> bed, again | 01:28 | |
| sergiusens | cjwatson: ok, I'm just grabbing whatever was in debian/control ... I'll strip it | 01:28 |
| xnox | cjwatson: pushed the merge to lp:~xnox/ubuntu/saucy/drizzle/merge, will sleep and upload tomorrow. | 01:51 |
| * xnox Zzzzzzz | 01:52 | |
| === salem_ is now known as _salem | ||
| Snow-Man | argghh.. why are the ipv6 addresses busted again? :( | 02:33 |
| === _salem is now known as salem_ | ||
| === salem_ is now known as _salem | ||
| pitti | Good morning | 04:15 |
| pitti | barry: did you happen to request syncing of codespeak-lib? | 04:28 |
| pitti | the sync dropped our dep-8 tests, but I cannot figure out from https://launchpad.net/ubuntu/+source/codespeak-lib/1.4.15-1 who requested the sync, and there is no bug report for the sycn either | 04:29 |
| * pitti removes the package from -proposed again, as that's our only delta | 04:29 | |
| ScottK | pitti: https://launchpad.net/ubuntu/saucy/+source/codespeak-lib/1.4.15-1 does make me think it was barry. | 04:35 |
| pitti | ScottK: aah, thanks | 04:35 |
| ScottK | I think it's an LP bug that you only get that from the series specific page, but it's not like it'll ever get fixed ... | 04:36 |
| pitti | dobey: ubuntuone-client's autopkgtest needs its stderr suppressed or redirected to stdout or a file | 04:53 |
| pitti | dobey: are you on this already? want me to upload this? in the latter case, is there any hidden bzr branch I should use, or just apt-get source/dput? | 04:53 |
| === broder_ is now known as broder | ||
| pitti | ev: I think the noninteractive UI needs some more thought | 05:42 |
| pitti | ev: I don't think we should set this in /etc/default/apport, as (1) that's always difficult to change, but more importantly (2) don't we want the UI for "apport-bug", i. e. for bug reports? I thought the intention for this was to send crash reports silently? | 05:43 |
| ev | pitti: difficult to change in what sense? We do want the crash reports to send silently, yes. Is that not the case here? | 06:57 |
| pitti | ev: it's a conffile which people often change; we need to add the new option to the conffile, and it's difficult to have different values of it for desktop and phone builds | 06:58 |
| pitti | ev: I meant that if you file a bug report (apport-bug package) you might actually want the UI | 06:59 |
| pitti | ev: and that update-notifier or whatever sends the crashes on the phone should perhaps directly call apport-noui instead of apport-bug | 06:59 |
| ev | pitti: right, but we're leaving it up to them to change. I can't see why we would ever change the value for it? Or am I misunderstanding conffiles? | 07:00 |
| pitti | ev: we used to change the value of enabled regularly, and peopel still do it manually | 07:01 |
| ev | I have no problem with directly calling apport-noui on the phone. Happy to create an upstart job for that which cargo cults the one bdmurray made for update-notifier | 07:01 |
| pitti | ev: but anyway, aside from the conffile issue I think the different default for it in desktop and phone builds makes this impractical | 07:01 |
| ev | ah, very good point | 07:02 |
| pitti | ev: e. g. update-notifier directly calls /usr/share/apport/apport-gtk | 07:02 |
| === bigon_ is now known as bigon | ||
| pitti | ev: so that option wouldn't work there | 07:02 |
| pitti | ev: and conversely calling apport-bug manually ought to give some UI, even on a server (-cli) | 07:02 |
| ev | well it now calls apport-collect in saucy | 07:02 |
| ev | but yeah | 07:02 |
| pitti | ev: oh? I just did apt-get source update-notifier, and it still calls apport-gtk | 07:02 |
| pitti | ev: nothing is ever supposed to call apport-collect automatically | 07:03 |
| ev | update-notifier 0.140 | 07:03 |
| ev | why? It's just a "pick the right UI" layer | 07:03 |
| pitti | ev: you mean -bug, not -collect? | 07:04 |
| pitti | ev: ah, so bdmurray didn't remove all the bits in ./src/update-notifier.h and src/crashh.c, and we instead just use the upstart job? | 07:05 |
| pitti | (nice to have a job for this now!) | 07:05 |
| ev | pitti: is there a difference? -collect is a symlink | 07:05 |
| ev | iknowright! | 07:06 |
| pitti | ev: oh yes, it checks argv[0] for what to do | 07:06 |
| pitti | -collect -> update an existing bug, needs launchpadlib, python2, and LP credentials | 07:07 |
| pitti | otherwise, "report a new bug" | 07:07 |
| ev | ah, I missed that entirely | 07:07 |
| ev | so not collect then | 07:07 |
| pitti | ev: perhaps we can make apport-bug check $APPORT_UI instead? then update-notifier would set "gtk", or not set it at all, and our phone job would set "noui"? | 07:08 |
| ev | okay, so to summarise: fix update-notifier to call apport-bug. Call apport-noui directly from an upstart job on the phone. Store the configuration for automatic reporting somewhere else? | 07:08 |
| ev | works for me | 07:08 |
| pitti | or call -ui directly, sure | 07:08 |
| ev | any preference on where the configuration option should live? | 07:09 |
| pitti | ev: u-n was already fixed, it's calling apport-bug | 07:09 |
| ev | ah right | 07:09 |
| dholbach | good morning! :) | 07:09 |
| pitti | ev: do we need one at all? | 07:09 |
| ev | pitti: so we could just use the apport enabled= toggle | 07:10 |
| pitti | ev: phone upstart job would set $APPORT_UI, and otherwise calling apport-bug should DTRT? | 07:10 |
| ev | we need to point this at something: https://wiki.ubuntu.com/ErrorTracker#Privacy_settings | 07:10 |
| ev | do keep in mind that we'll want to provide UI on the desktop for automatic reporting as well | 07:11 |
| pitti | ev: the "collect app crashes and errors"? that sounds like "enable"? | 07:11 |
| ev | the developer "I know what these are, just send them" | 07:11 |
| ev | yes | 07:11 |
| ev | it's definitely enable/disable | 07:11 |
| pitti | ah, for that | 07:11 |
| ev | but the tricky bit is the developer on the desktop | 07:11 |
| ev | yeah | 07:11 |
| pitti | ev: that's a per-user setting, right? | 07:12 |
| pitti | or does the admin set it globally? | 07:12 |
| ev | I think it makes more sense as an admin setting, and we definitely want it that way on the phone | 07:12 |
| ev | I think :) | 07:13 |
| pitti | ev: then I don't mind adding that to /e/d/apport, as we don't change that file regularly any more | 07:14 |
| ev | okay | 07:14 |
| pitti | ev: except if you want this at automatic=1 at phone builds, which we can't do | 07:14 |
| pitti | as it's a conffile | 07:14 |
| ev | oh hm | 07:14 |
| ev | I do want that :) | 07:14 |
| pitti | if the phone cronjob will take care of it, and automatic=0 is fine there, the we can do it | 07:14 |
| pitti | ev: how about a non-conffile /etc/apport/automatic flag file? | 07:15 |
| ev | works for me | 07:15 |
| pitti | phone builds/images can then create this, and no conffile conflicts | 07:15 |
| ev | sounds good | 07:15 |
| pitti | ev: http://paste.ubuntu.com/5883292/ ? | 07:19 |
| ev | yup, perfect | 07:20 |
| pitti | ev: still feels a bit strange for apport-bug (non-crash bug reports), but let's use this for now | 07:21 |
| ev | okay | 07:23 |
| pitti | ev: ok, committed | 07:24 |
| pitti | ev: I'll do a new upstream release now and upload, unless you have something else? | 07:24 |
| ev | thank you muchly | 07:24 |
| ev | nope, please proceed | 07:24 |
| pitti | ev: FYI, new feature, bumping to 2.11 (for your next NEWS entry) | 07:25 |
| * ev nods | 07:25 | |
| pitti | ev: thanks for the discussion | 07:27 |
| ev | thank you for discovering the problems with this | 07:28 |
| pitti | start on (file FILE=/var/crash/*.crash EVENT=create) | 07:34 |
| pitti | OMG that's so great; I've waited for this since 2005 or so :) | 07:34 |
| pitti | jodh: ^ thanks! | 07:34 |
| jodh | pitti: errm, np. | 07:42 |
| * jodh waits for irclogs.u.c to update to see what he's done... :) | 07:42 | |
| pitti | jodh: adding support for start on (file FILE=/var/crash/*.crash EVENT=create) | 07:46 |
| === iulian_ is now known as iulian | ||
| pitti | with that we should be able to eventually drop update-notifier | 07:46 |
| jodh | pitti: ah - team effort: bdmurray actually wrote the job :) | 07:47 |
| xnox | pitti: ev: if update-notifier declares a variable for "APPORT_UI" then on the phone, we can add "echo APPORT_UI=apport-no-gui > /etc/init/update-notifier.override" to set the default there. There are many things that are "tweaked" for the phone like this at the moment. | 08:38 |
| ev | xnox: the problem comes with this not just being an option for phone | 08:39 |
| ev | it's going to be an option on the desktop as well | 08:39 |
| ev | so apw and infinity can say "just send the damn things. stop bugging me!" | 08:39 |
| apw | oh please yes | 08:40 |
| apw | ev, was it a deliberate decision that teh default for that dialog is cancel btw ? | 08:41 |
| ev | what dialog? | 08:41 |
| xnox | ev: i'd put my faith apw/infinity would manage to copy&paste one line of upstart override for that =) I mean the productivity boost and incentives are there =)))))) | 08:41 |
| apw | ev, your 'do you want to send this error to ubuntu' thingy | 08:41 |
| pitti | apw: yes, in case it steals your focus or you don't read it all before (accidentally) pressing Enter | 08:41 |
| xnox | apw: gtk+ deficiency, as by design there shouldn't be a default action, yet gtk+ forces one. | 08:41 |
| ev | xnox: I never want to utter the words, "it's easy. Just open up a terminal and" | 08:42 |
| apw | pitti, that is not a solution the solution is to _not_ steal my focus ever | 08:42 |
| xnox | ev: upstart has dbus API..... | 08:42 |
| ev | xnox: because DBus is easy | 08:42 |
| ev | xnox: next you'll tell me that problems like these can be quickly solved in lisp | 08:42 |
| pitti | apw: let's hope that unity8 fixes that :) it seems compiz doesn't | 08:43 |
| ev | all you need are a few parenthesis. Simples. | 08:43 |
| lifeless | snaaaake! | 08:43 |
| ev | :D | 08:44 |
| apw | pitti, fingers crossed ... though there is a simple solution i suspect, make the dialog a box with OK only and have it have a radio box on it, 'discard', 'send to ubuntu', 'thinking' and default that to thinking, and make the box just come back if you have 'thinking' set | 08:44 |
| ev | yeah, the specification mentions the default action stuff: "The Esc and Enter keys should not do anything in an error alert, because you may have been just about to press one of those in the program that has the problem." | 08:44 |
| ev | but I take it GTK+ doesn't let us do that? | 08:44 |
| apw | pitti, obviosuly you can think of better words :) | 08:44 |
| apw | pitti, then if you hit enter it just reappears | 08:45 |
| ev | lifeless: good evening. Not sure if your new adventures involve a lot of big data, but if you still find that sort of thing interesting, I've really been enjoying the talks from Cassandra Summit '13 and Cassandra NYC '13: http://www.youtube.com/user/PlanetCassandra/videos?sort=dd&view=1&shelf_index=2 | 08:47 |
| ev | quite a bit of distributed systems stuff in there too | 08:47 |
| ev | Adrian Cockcroft's talk on Netflix OSS in particular | 08:47 |
| lifeless | ev: My new adventures are all to do with deploying clouds @ at scale. | 08:48 |
| lifeless | ev: so big data enabling rather than big data doing; but I am definitely still interested! | 08:48 |
| lifeless | ev: thank you for the link! | 08:48 |
| ev | excellent :) | 08:48 |
| ev | anytime | 08:48 |
| xnox | ev: since you are not on #ubuntu-quality, replaying here: to allow admins with foreground session, execute actions without prompts, you can do so via pkla as shown here: /var/lib/polkit-1/localauthority/10-vendor.d/com.ubuntu.desktop.pkla | 09:10 |
| ev | xnox: perfect, that's exactly what I'm already doing locally | 09:10 |
| ev | I'd give you a pastebin, but I'm on a different computer | 09:11 |
| pitti | however, caution applies | 09:11 |
| ev | oh? | 09:11 |
| pitti | xnox: please not; having any firefox plugin be able to format your internal hard drives or changing the boot sector is evil | 09:11 |
| pitti | ev: ^ my response to "so that's what I need to change to make usb-creator stop asking questions again" | 09:11 |
| xnox | pitti: would above be at all suitable for like - to stop apport asking for my password 16 times in a row? | 09:12 |
| pitti | xnox: that'd be a badly written apport hook | 09:12 |
| * xnox would have thought apport would at least cache the password, unless it's killed and spawned for each error..... | 09:12 | |
| ev | pitti: yes, this is something I'd only want set on the phone | 09:12 |
| pitti | xnox: apport can't cache it as it doesn't know it, but it has an API to run several root commands in one go (and thus with one password) | 09:12 |
| ev | I think the password prompt still makes sense for changing anything under com.ubuntu.WhoopsiePreferences on the desktop | 09:12 |
| xnox | pitti: on the phone, with readonly rootfs, only "blessed" hooks are in.... | 09:13 |
| pitti | xnox: we need to disable one of (1) send bug reports noninteractively, (2) ask for password for root commands, or (3) be able to point to an arbitrary hook dir, otherwise we have a "full root access" hole for any user | 09:14 |
| pitti | xnox: as the apport API is essentially a "run anything as root", it probably needs to stay password protected | 09:14 |
| pitti | but we wouldn't see these on the phone as ev just disabled all these prompts in apport with the noninteractive UI :) | 09:15 |
| xnox | pitti: plus, i'm not sure I understand the "badly written apport hook" argument, since at the moment i'm not protected against it and I don't buy "we asked you for a password, without telling you which hooks we will run, so it's your fault if it was a rotten hook, Haha kthnxbye" | 09:15 |
| ev | just doing my part to make apport webscale | 09:15 |
| pitti | xnox: I meant that it calls the "root_command_output()" function 16 times instead of using attach_root_command_outputs() | 09:16 |
| lifeless | ev: does that involve throwing away 90% of errors? | 09:17 |
| pitti | xnox: well, I never said I was particularly fond of these, as they don't tell you what they do -- but I bowed to several people demanding it | 09:17 |
| pitti | (X.org or kernel bug reports, etc.) | 09:17 |
| xnox | yeah =/ | 09:17 |
| pitti | of course these will just break again with the non-interactive UI | 09:17 |
| ev | lifeless: I have not yet made the leap to deleting to increase all sorts of performance areas | 09:18 |
| lifeless | :P | 09:18 |
| ev | mostly because we're still learning, still going back and building indexes out of the entire data set | 09:18 |
| pitti | but ev and I discussed some "need more information" flag on errors.u.c. for bug reports where we really need those, so we can refine that eventually | 09:18 |
| ev | if I was really confident in our data model, then yes :-P | 09:18 |
| tvoss_ | pitti, ping | 09:26 |
| pitti | tvoss_: pong | 09:31 |
| ricotz | pitti, hi :), if you have time please take a look at http://paste.debian.net/plain/16505 | 09:31 |
| pitti | ricotz: oh, I thought make install forgot to install them | 09:32 |
| ricotz | pitti, not really ;) | 09:32 |
| pitti | ricotz: thanks, uploading | 09:32 |
| ricotz | pitti, yw | 09:33 |
| cjwatson | rbasak: Looks like I just need to fix dacs, and then everything not dependent on your php5 merge is probably safe to temporarily remove | 09:35 |
| * cjwatson demotes/removes some packages for that transiiton | 09:42 | |
| cjwatson | *transition | 09:42 |
| === doko_ is now known as doko | ||
| rbasak | cjwatson: OK, thanks. I just noticed that merges.u.c is using php5 5.4.15-1 as the base. It seems blind to saucy-proposed. Is this a bug? | 09:50 |
| rbasak | I can work around it easily enough. | 09:50 |
| * xnox ponders about using cjwatson's net-retriever deduplicator for transition-tracker & merges.u.c =)))))) | 09:51 | |
| xnox | ... decides against it. | 09:52 |
| cjwatson | xnox: There's a perfectly good (fast) one in the transition tracker, and merges shouldn't need it | 09:56 |
| cjwatson | rbasak: Will check | 09:57 |
| cjwatson | Oh, indeed, I think I never got round to making merges look at -proposed | 09:58 |
| cjwatson | rbasak: Could you file a bug on merge-o-matic about this? I'm not going to have time to sort it out just now | 09:59 |
| rbasak | cjwatson: sure. | 10:02 |
| cjwatson | xnox: (What I mean is that merges already has code to pick the newest source of several, ever since Debian started having multiple versions in Sources; all it should need is to concatenate saucy and saucy-proposed | 10:02 |
| cjwatson | ) | 10:02 |
| * rbasak has filed bug 1202142 | 10:06 | |
| ubottu | bug 1202142 in Merge-o-Matic "Blind to new development release -proposed pocket" [Undecided,New] https://launchpad.net/bugs/1202142 | 10:06 |
| cjwatson | Ta | 10:07 |
| xnox | cjwatson: yet on people.canonical.com i see deduplicate-packages python script, which i don't have locally. So out of the box our "junk" branch doesn't do that =( | 10:07 |
| cjwatson | xnox: Yeah, I think Laney wrote that and didn't commit, originally ... | 10:08 |
| Laney | Seems possible | 10:08 |
| Laney | feel free to do it | 10:08 |
| xnox | Laney: is there way to run saucy & saucy-proposed locally without fiddling, as upstream? | 10:08 |
| xnox | Laney: ah =) ok, patches welcomed ;-) | 10:08 |
| Laney | The multiple suites thing is all local | 10:09 |
| Laney | it skips the 'downloading' part of ben | 10:09 |
| Laney | So that's why I didn't commit it | 10:09 |
| xnox | Laney: i guess one day we will upgrade to newer ben?! =) | 10:09 |
| Laney | I don't know if newer ben even handles this | 10:10 |
| Laney | but yes - some time ago I started writing a charm to get it off lillypilly | 10:11 |
| Laney | Then we don't need to block on IS and chroots and stuff | 10:11 |
| cjwatson | Well | 10:11 |
| cjwatson | Having it not tied into the archive-reports infrastructure would be problematic | 10:11 |
| cjwatson | But we're getting a new machine to offload the archive jobs from lillypilly | 10:12 |
| Laney | because of lag? | 10:12 |
| cjwatson | Just because all the stuff on there is too much for one machine | 10:12 |
| Laney | to the former | 10:12 |
| * xnox thinks drizzle is amd64 only software.... | 10:12 | |
| cjwatson | Right, it needs to be guaranteed up-to-date with the archive and update as quickly as possible | 10:12 |
| cjwatson | I specifically put a fair amount of work into making it update as fast as it can, so that you can go round multiple layers more efficiently | 10:13 |
| Laney | Ah, I was assuming that *stack had access to ftpmaster so it'd be the same | 10:16 |
| Laney | Anyway, I think that precise is new enough for new ben so this new machine might be OK | 10:16 |
| Laney | not that there's a huge need to move forward anyway | 10:16 |
| cjwatson | Direct access to ftpmaster is heavily restricted | 10:18 |
| cjwatson | And if it were on some other machine we'd need to figure out a way to trigger it from archive-reports | 10:18 |
| cjwatson | Also, lillypilly is on precise | 10:19 |
| Laney | the chroot is lucid though | 10:19 |
| cjwatson | It's not so much the version of the host, as that IS were uncomfortable with installing -dev packages in the root | 10:19 |
| Laney | but I'm sure that could be updated separately | 10:19 |
| cjwatson | It might be worth seeing if fakechroot is good enough | 10:19 |
| cjwatson | It certainly good | 10:19 |
| cjwatson | er, could | 10:19 |
| Laney | Yeah, seems I can ping ftpmaster but not rsync the dists tree | 10:20 |
| Laney | oh well | 10:20 |
| cjwatson | Wouldn't surprise me if fakechroot were good enough. I don't think I tried that | 10:21 |
| Laney | Would be useful to be able to self manage it | 10:23 |
| === Sweetsha1k is now known as Sweetshark | ||
| xnox | Laney: ftpmaster seems to be http only even from lillypilly. no rsync there. | 10:31 |
| cjwatson | xnox: Untrue | 10:33 |
| cjwatson | xnox: We have special arrangements | 10:33 |
| cjwatson | xnox: There are ubuntu-dists and ubuntu-germinate modules which lillypilly can access; it doesn't have blanket access, that's all | 10:35 |
| cjwatson | xnox: See (internal) RT#47981 and RT#49414 | 10:36 |
| xnox | cjwatson: is ubuntu-dists module publicly accessible? (prefferable merged tree), at the moment I do rsync ubuntu's module dists directory, and then ubuntu-ports dists directory on top, without deletes.... | 10:36 |
| cjwatson | xnox: No. | 10:37 |
| cjwatson | xnox: We're not going to open public rsync direct from ftpmaster. | 10:37 |
| cjwatson | This is a very special-purpose deal. | 10:38 |
| Laney | Ah, so I investigated. | 10:42 |
| Laney | dose-distcheck has a --latest option - if ben migrates to this then we can stop deduping | 10:44 |
| Laney | I still don't think it has multiple suite support though | 10:44 |
| infinity | cjwatson: "we're getting a new machine to offload the archive jobs" -- Is that on again? Is there an RT I can subscribe to? | 10:45 |
| cjwatson | infinity: RT#63122 | 10:46 |
| infinity | cjwatson: \o/ | 10:50 |
| infinity | cjwatson: A mod_proxy or mod_rewrite passthrough of some sort is probably saner than shuffling things around via rsync every few minutes. | 10:50 |
| infinity | I suppose I should tell the ticket this. | 10:50 |
| Laney | I'll make some time to see if fakechroot works for ben | 10:51 |
| Laney | If we're shuffling it anyway, might as well move then | 10:51 |
| cjwatson | infinity: Yeah, particularly for the things with lots of inodes (germinate output et al) | 10:53 |
| cjwatson | Laney: Cool | 10:53 |
| infinity | cjwatson: rsync-over-ssh isn't particularly CPU friendly, apache proxies are a lot less angry, and the goal here is to make lillypilly happy, so yeah. | 10:54 |
| tvoss_ | ogra_, ping | 10:54 |
| infinity | cjwatson: Commented on the ticket, anyway. Up to IS if they want rewrite/proxy rules they have to manage. | 10:54 |
| cjwatson | Ta | 10:54 |
| cjwatson | infinity: The alternative would be exposing newmachine's http port directly and then having a redirect rule | 10:55 |
| infinity | cjwatson: Yeah, which is even more CPU friendly, but client hostile. | 10:55 |
| infinity | cjwatson: But worth noting as a third option. | 10:56 |
| cjwatson | Will do | 10:56 |
| ogra_ | tvoss_, yo | 10:56 |
| infinity | Oh, FFS, I can't add myself as a CC to a ticket? | 10:57 |
| tvoss_ | ogra_, do you happen to know if we have a perf build for the touch image? | 10:57 |
| ogra_ | tvoss_, i think we do, for deatils ask #ubuntu-kernel though, i never used it | 10:57 |
| Laney | infinity: I think you have to ask for that, yeah :/ | 10:57 |
| doko | yolanda, when you touch graphviz for the lua update, could you have a look at building with ruby1.9 as well? | 11:17 |
| yolanda | doko, just focused on rrdtool now, but we could add ruby to the list | 11:18 |
| doko | ohh, rrdtool too | 11:19 |
| yolanda | doko i'm finding that liblua isn't copying the libraries anyway... do you know about it? | 11:19 |
| doko | no, I just did see that we were pulling 5.2 in main, without discarding 5.1 | 11:19 |
| cjwatson | yolanda: Could you leave graphviz until Apache 2.4 has landed in saucy, please? | 11:20 |
| yolanda | cjwatson, yes, not touched graphviz still | 11:20 |
| cjwatson | yolanda: You can see from http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt that it's a fiendishly complex transition already, and I don't want to complicate it further :) | 11:21 |
| yolanda | i think that there is some problem with liblua, no libraries copied anywhere | 11:21 |
| xnox | yolanda: recently with python3.3 transition in debian, multiple packages were spotted to compile and link bindings against libpython3.3*so yet not install or copy them anywhere..... | 11:23 |
| xnox | could be similar, where upstream builds them, yet packaging didn't actually install them properly. | 11:23 |
| yolanda | i'll take a look now | 11:24 |
| === MacSlow is now known as MacSlow|lunch | ||
| yolanda | xnox, i found that libraries are copied into /usr/lib/x86_64-linux-gnu, instead of /usr/lib/lua | 11:28 |
| yolanda | path should be /usr/lib/lua/5.2/, right? | 11:28 |
| xnox | not sure. depends how lua operates, and whether it started using multi arched or not. | 11:29 |
| cjwatson | Could also be an accident from higher debhelper compat levels. | 11:29 |
| xnox | doko: ^ maybe you know correct paths for lua? | 11:29 |
| doko | xnox, didn't look. lua itself is multiarch, didn't look at the layout for the modules and extensions | 11:33 |
| yolanda | doko, xnox, it's multi arched, but something is wrong, just copying the files to /usr/lib/x86_64-linux-gnu/liblua5.2.so | 11:41 |
| === Evpok_ is now known as Evpok | ||
| infinity | yolanda: Certainly sounds like that should be in a lower-level plugin directory like /usr/lib/x86_64-linux-gnu/lua/something, yeah. | 11:59 |
| infinity | yolanda: But you'd have to look at what pre-multiarch lua did, and then logically twiddle that. | 12:00 |
| rbasak | Having more issues with php5 including a build failure with my new merge. I'm working on it. | 12:00 |
| doko | infinity, please could you merge eglibc? | 12:08 |
| infinity | doko: Yes. Is there a specific fix you're urgently waiting on, or do you just hate outdated version numbers? :) | 12:09 |
| === jdstrand_ is now known as jdstrand | ||
| infinity | doko: (The merge is sitting here on my laptop, I'll get it up after another test or three) | 12:10 |
| doko | infinity, I need a stable cross chroot, and would like to avoid to have it rebuilt soonish again | 12:11 |
| dholbach | can somebody please reject https://code.launchpad.net/~logan/ubuntu/saucy/json-c/0.11-2ubuntu1/+merge/174910? | 12:11 |
| doko | infinity, and yes, the reverted error code change causing some issues with python modules would be good to have too | 12:12 |
| cjwatson | dholbach: done | 12:12 |
| dholbach | thanks | 12:13 |
| infinity | doko: Oh, the getaddrinfo() fix? Yeah, fair enough. I'll finish up testing. | 12:14 |
| doko | yes | 12:14 |
| === MacSlow|lunch is now known as MacSlow | ||
| === stub` is now known as stub | ||
| === _salem is now known as salem_ | ||
| caribou | smoser: I have a request for help from the Pilot | 12:44 |
| caribou | smoser: I have a pending SRU and apparently I forgot to subscribe ubuntu-sru so it doesn't seem to appear in the queue | 12:44 |
| caribou | smoser: LP: #1005901 | 12:45 |
| ubottu | Launchpad bug 1005901 in duplicity (Ubuntu Precise) "cannot change temp dir" [Undecided,In progress] https://launchpad.net/bugs/1005901 | 12:45 |
| barry | pitti: yes, i was going to restore the dep 8 tests once the sync cleared proposed, and i filed a pull request for the debian package to add the tests | 12:46 |
| caribou | hmm this sponsor-patch script seems interesting... | 12:47 |
| pitti | barry: ah, ok; well, the only delta was the dropping of the test, so I removed the sync from -proposed (it wouldn't propagate anyway) | 12:48 |
| barry | pitti: in that case, i won't do anything until the debian bug gets closed. once that's got the tests, i'll resync | 12:49 |
| dobey | pitti: why does it need the redirection? | 13:00 |
| pitti | dobey: stderr output counts as failure; useful to guard against unexpected warnings/criticals/etc., but of course rather useless if you do expect all that spewage on stderr | 13:02 |
| pitti | so in that case a 2>&1 is the usual fix | 13:02 |
| dobey | pitti: that sounds like a bug in autopkgtest if it's counting stderr output as failure | 13:04 |
| pitti | it's the currently defined behaviour | 13:04 |
| pitti | i. e. it doesn't happen accidentaly | 13:04 |
| smoser | @pilot out | 13:04 |
| === udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: | ||
| infinity | This has been argued in the past as a misfeature, yes, but it's the way it is. | 13:04 |
| smoser | caribou, i'm not pilot, but i'll take a quick look and see if i cna't help | 13:05 |
| caribou | smoser: the topic did say you were, sorry 'bout the noise | 13:06 |
| caribou | smoser: it's a small backport that's already in quantal. sponsor-patch doesn't report anything I could see | 13:06 |
| === tlyu_ is now known as tlyu | ||
| smoser | yeah, not your fault :) | 13:07 |
| smoser | caribou, did you figure it out ? | 13:08 |
| rbasak | I filed bug 1197005 about it | 13:08 |
| ubottu | bug 1197005 in autopkgtest (Ubuntu) "Printing to stderr should not be considered a test failure" [Undecided,New] https://launchpad.net/bugs/1197005 | 13:08 |
| rbasak | It's a pain when developing tests, since eg. "set -x" writes to stderr. | 13:08 |
| dobey | pitti: i think autopkgtest either needs to be fixed to not count stderr output as a failure, or to have a feature flag one can put in d/tests/control to redirect/ignore stderr | 13:08 |
| caribou | smoser: I was able to figure out how to reproduce it & did test the fix from Quantal | 13:08 |
| pitti | dobey: we generally want stderr failure; the feature flag is a nice idea | 13:09 |
| rbasak | dobey: +1. I'd even go further. A test that needs stderr to be treated as a failure should flag it as such in debian/tests/control. | 13:09 |
| rbasak | pitti: I disagree, for server packages at least. The way I've been writing tests, I explicitly check for the expected behaviour only right at the end of a long setup. | 13:10 |
| smoser | caribou, so you want htat debdiff sponsored. is that it? | 13:10 |
| caribou | smoser: yes, indeed | 13:10 |
| barry | pitti: i'm a little perplexed at the lack of automatic notification for the package not clearing proposed, or getting dropped from it. not saying *you* should have done the notification, but that the system should have. or maybe it did and i missed it? | 13:10 |
| rbasak | The long setup will fail due to "set -e", and even if a command doesn't correctly return exit status, then the behaviour check at the end of the test will notice and flag it. | 13:10 |
| dobey | pitti: the problem of course is, if a completely unrelated thing dumps something to stderr, such as a gtk+ theme, it counts as a failure | 13:10 |
| rbasak | OTOH, the stderr causing a test failure has severely harmed my test development velocity. | 13:10 |
| pitti | barry: I don't think LP notifies you, that's why I pinged you explicitly | 13:10 |
| infinity | barry: There's no notification when packages are removed. It would be a lot of noise for routine removals. | 13:11 |
| pitti | dobey: right, that's what we want it for -- new CRITICALs, for example | 13:11 |
| barry | pitti: yeah, for which... thanks! :) | 13:11 |
| dobey | pitti: yes, but i shouldn't get a failure in ubuntuone because the theme broke :) | 13:11 |
| barry | infinity: would it be a lot of noise for proposed migration "failures"? | 13:12 |
| dobey | or because twisted is using deprecated API | 13:12 |
| infinity | barry: What failure was there? pitti removed a package, that's not a failure, it's an explicit action. | 13:12 |
| pitti | infinity: codespeak-lib's autopkgtest failed because the autopkgtest was dropped from the sync | 13:13 |
| pitti | infinity: now, if the removal was legitimate we'd just remove the job, but we actually want it, so I removed the sync from -proposed again | 13:13 |
| barry | infinity: what i mean by "failures" is any disruption in the normal migration pattern | 13:14 |
| infinity | barry: I suspect uploaders being told every time something is stuck in proposed (on every britney run, how often do you want to get told?) would be an insane amount of noise. | 13:14 |
| infinity | This particular case seemse to be a bit of a special case. | 13:15 |
| infinity | And a direct ping seemed appropriate, since one would also want to expand on "why did you remove that?" | 13:15 |
| dobey | infinity: well, getting a single notification that the autopkgtests failed in my upload, would be nice. | 13:16 |
| infinity | dobey: That's meant to be happening (or maybe has already happened?) | 13:16 |
| infinity | jibel: ^ | 13:17 |
| barry | infinity: maybe. i'm not saying anything *needs* to be done, i'm just wondering out loud whether some notification, or possibly even status on a launchpad page wouldn't be better. | 13:17 |
| kirkland | xnox: no... sorry, let me see what went wront with my release script... | 13:17 |
| cjwatson | dobey: I get e-mail notifications when my uploads' autopkgtests fail, and have done for a couple of weeks now. | 13:18 |
| infinity | barry: I suspect push notifications of continued failure to migrate would be a non-starter. A nicer pull mechanism than "learn to read excuses/output" might be pleasant. | 13:18 |
| cjwatson | (Along with notifications when they go back to passing.) | 13:18 |
| jibel | dobey, barry you should have received a notification on 1rst failure, then when the test pass again. If you didn't that's a bug I must fix. | 13:18 |
| infinity | I wonder how painful it would be to mangle packages.qa.d.o to work for Ubuntu. | 13:19 |
| cjwatson | jibel: Perhaps this is a case where the test has always failed ... | 13:19 |
| dobey | jibel: i haven't seen any e-mail | 13:19 |
| cjwatson | Although https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-ubuntuone-client/ was apparently only introduced recently | 13:19 |
| infinity | dobey: Oh, is this on an upload YOU are doing, or something autolanded by a bot that bins email? | 13:19 |
| jibel | cjwatson, no it was codespeak-lib that used to pass | 13:19 |
| barry | jibel: i did not get anything | 13:19 |
| dobey | infinity: uploads i made | 13:20 |
| jibel | anyway, I'll have look | 13:20 |
| infinity | Kay. | 13:20 |
| Laney | The software-center pyflakes failure amuses me | 13:20 |
| cjwatson | packages.qa.d.o is very useful. It has a lot of parts though | 13:20 |
| kirkland | xnox: doh. I see what went wrong. thanks. I'm fixing it up now | 13:20 |
| Laney | It's picking up bad syntax in .pc/ | 13:20 |
| dobey | Laney: oh, fun | 13:21 |
| Laney | dobey: There's also ones which try to access the internets and fail | 13:21 |
| infinity | cjwatson: Yeah, I'm not convinced it would be easy to "port" to launchpad, but we really don't have a better "package portal" than +source/<source> right now, which lacks a lot of useful info. | 13:21 |
| infinity | cjwatson: Well, it lacks anything we don't do directly in launchpad. So, proposed-migration, adt, pending merges, etc. A p.qa.d.o-style portal could be handy. | 13:22 |
| dobey | Laney: from pyflakes? | 13:22 |
| Laney | no, other tests | 13:22 |
| cjwatson | Laney: I'm sure I remember fixing something like that in some other package recently-ish | 13:22 |
| cjwatson | (pyflakes vs. .pc) | 13:22 |
| Laney | https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-software-center/47/ARCH=amd64,label=adt/console | 13:22 |
| dobey | Laney: i knew i should have just done rm -rf debian/tests :) | 13:22 |
| cjwatson | Easy enough to do anyway | 13:23 |
| cjwatson | infinity: Yep | 13:23 |
| cjwatson | infinity: I think it mostly takes a load of data sources scraped from elsewhere, so it's just a matter of coming up with a bazillion scrapers | 13:23 |
| infinity | cjwatson: Indeed. It might actually prove to not be much effort at all. Upload history is easy, bug scraping should be simple enough, etc. | 13:23 |
| infinity | (In fact, doesn't it cheat on upload history by just being subscribed to -changes, rather than scraping anything there?) | 13:24 |
| infinity | Anyhow. Food for thought for a less busy day. | 13:24 |
| infinity | So, 2017. | 13:24 |
| barry | infinity: i find this page interesting: https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-codespeak-lib/10/ARCH=amd64,label=adt/ | 13:27 |
| barry | infinity: the big red dot seems to tell me there's a problem, but the (no failures) and other data there doesn't seem to tell me why i got a big red dot | 13:27 |
| Laney | dobey: I'll leave it with you now ;-) | 13:28 |
| infinity | barry: You're not alone in finding jenkins output unnavigable. | 13:33 |
| cjwatson | I'm not sure that's unnavigable Jenkins; I think perhaps that's something getting confused with a package going from (has tests) to (has no tests) | 13:37 |
| pitti | yes, if you look at the console output or full "log" file you'll see the problem | 13:37 |
| cjwatson | pitti: In this case the log basically just says no tests were run | 13:39 |
| pitti | right, as they got dropped | 13:40 |
| cjwatson | 2013-07-16 16:33:33: Failure: adt-run exited with status 8. | 13:40 |
| cjwatson | Which is the documented "no tests" exit code | 13:40 |
| pitti | yes, but we don't want this to silently pass | 13:40 |
| cjwatson | So perhaps that's a bug in adt-britney or similar for running them in the first place | 13:40 |
| pitti | it's actually quite deliberate | 13:41 |
| pitti | I look at all failures (in case it's test machinery) | 13:41 |
| cjwatson | From adt-run's point of view it's obviously correct | 13:41 |
| pitti | cjwatson: if that was a deliberate removal, I had just removed the jenkins job | 13:41 |
| cjwatson | From adt-britney's point of view, I disagree (if indeed that's what ran the job here) | 13:41 |
| pitti | s/had/would have/ | 13:41 |
| pitti | but like that we can spot if a new upload damages debian/tests/; with counting 8 as success we wouldn't catch that | 13:42 |
| cjwatson | There are a bazillion other ways for a developer to disable or neuter tests if they want to; there's no point in making this one difficult by having it require manual intervention | 13:42 |
| cjwatson | Like I say, I'm not saying that the infrastructure shouldn't have failed on exit code 8 | 13:42 |
| cjwatson | I'm saying that this job shouldn't have been run in the first place - unless the package still had XS-Testsuite: autopkgtest? | 13:43 |
| pitti | cjwatson: right, I think that gets picked up because it takes all packages in release and proposed which have XS-Testsuite: | 13:43 |
| pitti | cjwatson: and as the saucy version still had it, it ran the codespeak-lib test in -proposed | 13:43 |
| pitti | so, it's certainly arguable if this is a bug | 13:44 |
| pitti | but the only effect is that jibel or me will confirm that the removal is legit and remove the job manually | 13:44 |
| pitti | that shouldn't happen very often (in fact it never did so far), so I'm happy to take that extra review | 13:44 |
| barry | pitti: exit code 8 was because the saucy version had autopkgtests but the proposed version did not? | 13:48 |
| barry | (sorry, i got bumped off of irc for a bit) | 13:48 |
| pitti | barry: right | 13:48 |
| cjwatson | pitti: mm. I'm concerned that our whole system is coming near to hitting cognitive overload for me, and I wrote a chunk of it, so I'm hoping to find things that are easier to simplify for developers | 13:49 |
| pitti | barry: while this is a kind of success for adt-run, we don't count it as such in jenkins (quite deliberately, see above) | 13:49 |
| barry | pitti: right, it seems reasonable to fail. i think it's just a bug that the failure did not lead to a notification | 13:49 |
| pitti | barry: it did, it sent out an email (that's why I looked into it, after all) | 13:50 |
| pitti | barry: but it wasn't sent to you because it was a sync; I think that's a bug that we need to fix | 13:50 |
| pitti | (I think.. I already deleted the email) | 13:50 |
| barry | pitti: ah. so archive admins got the email? | 13:50 |
| pitti | barry: jibel and me get all adt failure emails, plus archive@u.c. (i. e. whoever appears as the uploader) | 13:51 |
| pitti | but sending it to archive@u.c. is quite bogus | 13:51 |
| pitti | it's not that easy to find out the actual requestor, but certainly possible | 13:51 |
| cjwatson | archive@u.c doesn't actually go to anyone | 13:51 |
| barry | pitti: and that happened because it was a sync. okay, i think i got it now. :) agreed that the sync requester should get notified. | 13:51 |
| cjwatson | pitti: it's "creator" on the SPPH | 13:52 |
| cjwatson | archive@u.c> at least as far as I know | 13:52 |
| pitti | yes, confusingly the requestor isn't mentioned on https://launchpad.net/ubuntu/+source/codespeak-lib/1.4.15-1 (where I usually look) | 13:52 |
| pitti | but it is on https://launchpad.net/ubuntu/saucy/+source/codespeak-lib/1.4.15-1 | 13:52 |
| pitti | so somewhere in LP's and lplib's guts it's stored | 13:53 |
| cjwatson | Right, like I say, it's SourcePackagePublishingHistory.creator | 13:53 |
| cjwatson | >>> lp.distributions["ubuntu"].main_archive.getPublishedSources(source_name="codespeak-lib", version="1.4.15-1", exact_match=True)[0].creator | 13:54 |
| cjwatson | <person at https://api.launchpad.net/1.0/~barry> | 13:54 |
| pitti | cjwatson: thanks; added to bug 1202208 | 13:56 |
| ubottu | bug 1202208 in Auto Package Testing "Wrong test failure notification for syncs" [Undecided,Triaged] https://launchpad.net/bugs/1202208 | 13:56 |
| pitti | jibel: ^ FYI | 13:56 |
| barry | pitti, jibel, cjwatson thanks! | 13:57 |
| jibel | barry, 2013-07-16 16:30:18,110 WARNING No public email address for barry. Falling back to changelog | 13:58 |
| jibel | 2013-07-16 16:30:18,566 WARNING No changes files URL! | 13:58 |
| jibel | barry, no public address, no notifications | 13:59 |
| pitti | jibel: oh, so you already do look at this | 13:59 |
| barry | jibel: nice | 13:59 |
| pitti | jibel: (closed the bug) | 14:02 |
| jibel | pitti, but there is a bug still, dobey should have receive a notification for ubuntuone-client | 14:02 |
| dobey | jibel: checked all possible spam folders and didn't see a mail there either | 14:08 |
| dobey | nor a notification for software-center | 14:09 |
| rbasak | I've got a dpkg-gensymbols error in php5 because I'm dropping symbols that are defined in packages in universe: http://paste.ubuntu.com/5884368/. Do I: 1) patch debian/libphp5-embed.symbols to drop symbols that won't be available in the Ubuntu build; 2) Bump the warning/error level so that missing symbols won't result in a dpkg-gensymbols error; or 3) something else? | 14:14 |
| infinity | rbasak: The qdbm stuff? | 14:16 |
| rbasak | infinity: yes, and onig too | 14:17 |
| infinity | rbasak: Well, the Onig is going the other direction. Those are added, not dropped. | 14:17 |
| infinity | rbasak: Bug in the Debian packaging, or have you done something odd in the merge? | 14:17 |
| rbasak | I don't think I've done anything odd. | 14:17 |
| rbasak | dpkg-gensymbols(1) says that by default disappearing symbols is treated as an error | 14:18 |
| infinity | And rightly so. | 14:18 |
| rbasak | Ah yes. So I think the qdbm stuff is causing the problem, not onig. | 14:18 |
| infinity | rbasak: That's easier to deal with, but the Onig thing is more curious. Where is that coming from? | 14:19 |
| rbasak | Debian packaging defines qdbm symbols. We drop qdbm-dev, so those symbols are defined and appear to be missing. | 14:19 |
| infinity | rbasak: A Debian build log doesn't show those popping up. | 14:19 |
| jibel | dobey, don't waste your time the system didn't find your preferred email address | 14:20 |
| rbasak | My full build log is http://paste.ubuntu.com/5884355/, but warning: it's big. | 14:20 |
| jibel | despite there is one on LP | 14:20 |
| dobey | jibel: why wouldn't it use the address in the debian changelog though? | 14:20 |
| dobey | jibel: it should be using the changelog address for everyone, i think | 14:21 |
| infinity | rbasak: Oh, Debian build logs don't show it because I'm looking at the next version that removes the symbols file again. :P | 14:21 |
| infinity | rbasak: You might want to just merge -14 and forget the question for now. | 14:22 |
| rbasak | Gah | 14:23 |
| rbasak | Looks like -14 appeared in the last few hours :-/ | 14:23 |
| rbasak | Thanks | 14:23 |
| infinity | Should be a trivial delta to slap on top of your current work. | 14:23 |
| rbasak | Yep | 14:24 |
| sergiusens | cjwatson: got this for the first time ever (for the first package installed on a vanilla system) http://pastebin.ubuntu.com/5884435/ | 14:35 |
| sergiusens | I can try and reproduce that later | 14:35 |
| cjwatson | Haha | 14:35 |
| cjwatson | Um | 14:35 |
| cjwatson | Oh, duh | 14:35 |
| cjwatson | sergiusens: Apply http://paste.ubuntu.com/5884438/ | 14:35 |
| sergiusens | heh | 14:36 |
| dobey | Laney: hrmm, if s-c tests failed, how did it end up in release? | 14:36 |
| cjwatson | It was probably forced since it's never worked | 14:37 |
| dobey | ah ok | 14:37 |
| dobey | gah. and branch import for s-c broke again | 14:49 |
| dobey | why does it keep breaking :( | 14:49 |
| cjwatson | sergiusens: just uploaded click 0.1.5 to fix that | 14:52 |
| sergiusens | thanks | 14:52 |
| hallyn | all right i seemt o have confused myself again. if i need to run a setfacl in $package.postinst, does the acl package need to be in $package's pre-depends, or only in depends? | 15:01 |
| yolanda | hi, anyone can guide me on ac_cv_search command? i'm trying to debug why a call isn't found on a library, in a configure script, but i'd like to debug that manually | 15:02 |
| rbasak | -14 hasn't hit packages.qa.debian.org or packages.debian.org yet. Any idea where I can get the source package, or should I just wait? | 15:02 |
| yolanda | is there any way that i can use it from shell? | 15:02 |
| rbasak | hallyn: IIRC, the postinst is fine, unless you have a circular dependency. | 15:02 |
| hallyn | rbasak: you mean in Depends: is fine right? | 15:03 |
| rbasak | "all postinst scripts are run with their dependencies properly configured if this is possible." - http://www.debian.org/doc/debian-policy/ch-relationships.html | 15:03 |
| cjwatson | yolanda: config.log usually has details. No, you can't run it separately. ac_cv_search is likely to be a variable not a command, in any case - perhaps you're thinking of AC_SEARCH_LIBS | 15:03 |
| rbasak | hallyn: sorry, yes. | 15:03 |
| hallyn | rbasak: that's the page i'm waiting to finish loading :) | 15:03 |
| rbasak | hallyn: how are you connected? Carrier pigeon? :) | 15:04 |
| cjwatson | rbasak: incoming.debian.org and check the uploader's sig by hand | 15:04 |
| hallyn | rbasak: not ont he first hop, but not sure what's going on downstraem | 15:04 |
| rbasak | cjwatson: brilliant. Thanks! | 15:05 |
| infinity | rbasak: incoming.debian.org | 15:06 |
| cjwatson | Too slow, old man | 15:06 |
| infinity | cjwatson: Oh. | 15:06 |
| infinity | rbasak: I wouldn't bother with checking the sig if the diff it auditably small, mind you. :P | 15:06 |
| cjwatson | Yeah | 15:06 |
| infinity | cjwatson: Say, feel like vomiting today? | 15:06 |
| cjwatson | yolanda: You can also generally run the configure script under 'sh -x', for ginormous amounts of output. Looking at config.log first is usually wise. :) | 15:07 |
| infinity | cjwatson: I don't think I can sink lower than this for the week: http://paste.ubuntu.com/5884525/ | 15:07 |
| rbasak | dget ran dscverify (says the manpage), which appears happy. Is that sufficient? | 15:07 |
| cjwatson | infinity: But next week you'll be ready to go lower, right? | 15:07 |
| cjwatson | rbasak: Yep | 15:07 |
| yolanda | cjwatson, looked at the log, it isn't finding a "lua_call" function, that should be contained in lua libraries | 15:07 |
| infinity | rbasak: Sure, but like i said, you'll be applying the -13 -> -14 delta by hand anyway, so you get to verify the change regardless. Who uploaded it is then less relevant. | 15:07 |
| rbasak | infinity: yeah, I'll end up looking at the delta anyway | 15:07 |
| rbasak | Thanks all | 15:07 |
| infinity | cjwatson: I can never predict just how awful my hacks will get in my old age. | 15:07 |
| hallyn | rbasak: thanks | 15:08 |
| cjwatson | infinity: Fixing su might be a better plan. :) | 15:08 |
| infinity | cjwatson: I'm slowly becoming lamont. | 15:08 |
| yolanda | cjwatson, lua library is installed on that path: /usr/lib/x86_64-linux-gnu/liblua5.2.so | 15:08 |
| infinity | cjwatson: The su fix would still lead to that 2-minute build spinning buildds until the sbuild timeout. | 15:08 |
| cjwatson | yolanda: It might then be worth using sh -x to find the exact sequence of commands that it's running to determine that | 15:08 |
| lamont | infinity: meh | 15:08 |
| cjwatson | yolanda: It's probably missing a dependent library or something | 15:08 |
| infinity | lamont: Feh. | 15:09 |
| lamont | heh | 15:09 |
| lamont | infinity: I acknowledge that you are becoming more awesome. | 15:09 |
| infinity | lamont: You may be the only person who sees it that way, but I can't help but acknowledge your suprerior point of view on the matter. | 15:10 |
| cjwatson | infinity: I think I'd have build-depended on procps and used pgrep, not that that improves the concept much. :) | 15:10 |
| lamont | lol | 15:10 |
| cjwatson | If only because the output is less nasty. | 15:11 |
| infinity | cjwatson: pgrep effectively does the same thing, no? "Find processes that match pattern, but exlude myelf, cause that's lolz"? | 15:11 |
| cjwatson | Yeah, but less pain with awk. | 15:11 |
| yolanda | mm, nm shows that the method is called now "lua_callk", not "lua_call" | 15:11 |
| yolanda | some patch should be needed | 15:11 |
| cjwatson | yolanda: lua_call is a macro now | 15:12 |
| yolanda | cjwatson, the point is that configure script for rrdtools is trying to detect lua_call for building lua bindings | 15:12 |
| yolanda | it doesn't find lua_call function and fails | 15:12 |
| cjwatson | yolanda: That would normally still work even for a macro, I think, but it depends. What's the configure.ac line in question? | 15:13 |
| yolanda | i patched the configure.ac file, updated the call for lua_callk and works | 15:13 |
| cjwatson | Usually autoconf tries to actually compile and link, rather than poking at the library with nm. | 15:13 |
| cjwatson | Sure, but I'm not sure that's the right fix ... | 15:13 |
| yolanda | i know... | 15:13 |
| cjwatson | What's the configure.ac line in question? | 15:13 |
| yolanda | let me pastebin my file | 15:13 |
| cjwatson | I just need one line :) | 15:13 |
| lamont | cjwatson: I don't think infinity finds any pain with awk... but that's how he is, maybe? | 15:14 |
| yolanda | http://paste.ubuntu.com/5884566/ | 15:14 |
| yolanda | look at line 748, i patched that | 15:14 |
| yolanda | now that bit works, but it fails on luaL_register, luaL_module and luaL_openlib | 15:15 |
| cjwatson | I think that's missing the point. | 15:15 |
| cjwatson | The problem may be that the macro requires certain arguments which autoconf's default macro expansion doesn't provide | 15:16 |
| cjwatson | (But I'm in a meeting. Give me half an hour) | 15:16 |
| yolanda | cjwatson, i grabbed that patch from a fedora fix, just for guide: http://pkgs.fedoraproject.org/cgit/rrdtool.git/tree/rrdtool-1.4.7-lua-5.2.patch | 15:16 |
| yolanda | let's talk later | 15:16 |
| cjwatson | Sure, I understand the fix perfectly well, I'm just fairly sure it's possible to do better | 15:17 |
| cjwatson | Fedora aren't always right :) | 15:17 |
| dobey | what was the command to pull arbitrary dpkg source off launchpad? | 15:18 |
| cjwatson | pull-lp-source | 15:20 |
| xnox | stokachu: bdmurray: commented on https://code.launchpad.net/~hopem/ubuntu/raring/python-eventlet/lp1199037/+merge/175107 | 15:30 |
| stokachu | xnox: thanks ill work with dosaboy to get that updated | 15:30 |
| xnox | the patch itself looks straight forward, so a sponsor could rewrite a changelog entry to fit SRU (version, bug ref, a sentence description) but it would be best for original submitter do a quick fix up of the version and LP: # as a learning excercise. | 15:31 |
| xnox | stokachu: cool thanks. | 15:31 |
| stokachu | xnox: definately, also do you guys have any automated tools for checking for a "bug closes" and version scheme? | 15:32 |
| xnox | stokachu: oh, and the bug description impact / test case / bug description all look very good. | 15:32 |
| stokachu | i'd like to be able to do a quick verification on an sru before bringing it up in the meeting | 15:32 |
| stokachu | as a lot of the bugs come to me last minute | 15:32 |
| xnox | stokachu: not really, especially since the checks must go against .changes file (check that here is LP closes bugs header and the bug is sensible, e.g. has sru task) | 15:33 |
| xnox | stokachu: and similarly there is no way to offline check the correct version, it needs to be compared against what's in the other suites. | 15:34 |
| stokachu | xnox: ok so this portion is still a manual process | 15:34 |
| infinity | Note that there'd be nothing wrong with the original proposed version string in that upload. | 15:34 |
| infinity | Given that it was never used, and it's << saucy. | 15:34 |
| xnox | infinity: hm. ok. =) | 15:35 |
| infinity | However, the bug ref is an absolute must for every SRU. | 15:35 |
| infinity | Version rules are a bit more fluid. :P | 15:35 |
| xnox | stokachu: but it's not a by-default recommended one as per https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging | 15:35 |
| xnox | =)))) | 15:35 |
| stokachu | xnox: yea thats the one i go by | 15:35 |
| infinity | Do we link that from the SRU process wiki page? Probably should. | 15:37 |
| cjwatson | Believe so | 15:37 |
| infinity | Still, I'm not anal about versions conforming to a perfect table of perfection, just that they are sensibly correct and not nutty. | 15:38 |
| rbasak | I think it's easier for newcomers when there's a strict set of rules to follow and everyone follows them. Less variation makes it easier to learn by example. | 15:39 |
| xnox | infinity: cjwatson: we do. I wonder if it should be magically included as a snippet in both though. | 15:39 |
| xnox | cause adding a ready to copy&paste template for bug report improved the bug descriptions as lot! | 15:40 |
| infinity | rbasak: Absolutely, hence the table. | 15:40 |
| cjwatson | rbasak: The other side is that it's better not to force extra round-trips for things that don't really matter. | 15:40 |
| cjwatson | So I'm all for prescriptive documentation, but also all for SRU admins having discretion. | 15:40 |
| rbasak | cjwatson: absolutely agree. I more meant for experienced devs to lead with a consistent example, not for sponsors to create round trips for newcomers. | 15:41 |
| rbasak | So I would still like uploaders to tweak uploads as necessary to conform to a perfect table of perfection :) | 15:43 |
| infinity | rbasak: I break that table's rules with my own packages on a near-regular basis. But there are some special packages in play here. | 15:47 |
| infinity | rbasak: Anyhow, I think we're in violent agreement. Pointing people to the table is good. | 15:48 |
| rbasak | Yeah, exceptions are always exceptional :) | 15:49 |
| === GridCube is now known as GridCube_netbook | ||
| brendand | is python coverage restricted to running things that end with .py? | 16:05 |
| brendand | never mind... | 16:07 |
| cjwatson | yolanda: So, maybe this isn't any better (it's rather longer but I think more accurate); I ended up with http://paste.ubuntu.com/5884705/ | 16:13 |
| cjwatson | yolanda: But luaL_register is a case where the API has genuinely changed in Lua 5.2. If I were you I would be strongly inclined to punt this to upstream and let them sort it out :-) | 16:13 |
| cjwatson | See e.g. http://lua-users.org/lists/lua-l/2013-05/msg00209.html | 16:14 |
| cjwatson | Or compare https://github.com/keplerproject/luafilesystem/pull/17 | 16:15 |
| === chuck_ is now known as zul | ||
| yolanda | cjwatson, let me check | 16:18 |
| === wendar_ is now known as wendar | ||
| === dosaboy__ is now known as dosaboy | ||
| mdeslaur | @pilot in | 17:34 |
| === udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mdeslaur | ||
| bdmurray | pitti: still about? | 17:36 |
| rbasak | cjwatson: apache2 isn't in the server packageset too. Do you think this is also appropriate for an exception? | 18:05 |
| rbasak | s/too/either/ | 18:05 |
| rbasak | This is for bug 1199318. | 18:09 |
| ubottu | bug 1199318 in apache2 (Ubuntu Saucy) "package apache2-utils 2.2.22-6ubuntu5 failed to install/upgrade: trying to overwrite '/usr/share/apport/package-hooks/apache2.py', which is also in package apache2.2-common 2.2.22-6ubuntu5" [High,Confirmed] https://launchpad.net/bugs/1199318 | 18:09 |
| === racarr is now known as racarr|lunch | ||
| === Guest99716 is now known as balloons_ | ||
| === racarr|lunch is now known as racarr | ||
| cjwatson | rbasak: I do, yes. Done. | 20:17 |
| hallyn | lifeless: hey - i've had a vm under virt-manager in raring running for most of today, no hint of memory leak yet. Anything more I should do, like reload something a bunch of times? Can you paste the .xml for th evms you had running to the bug? | 20:19 |
| lifeless | hallyn: I can | 20:19 |
| lifeless | mine is at 2601 root 20 0 934m 18m 7696 S 0.0 0.1 0:22.04 libvirtd | 20:20 |
| lifeless | ah, virt-manager wasn't connected, reconnecting it. [it d/c'd when libvirtd hit that high ram...] | 20:21 |
| lifeless | hallyn: configs uploaded | 20:23 |
| mdeslaur | @pilot out | 20:23 |
| === udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: | ||
| hallyn | lifeless: thanks | 20:24 |
| lifeless | hallyn: 2601 root 20 0 934m 21m 8352 S 8.6 0.1 0:50.80 libvirtd | 20:29 |
| lifeless | hallyn: 3MB in 8 minutes; 1MB was immediate when I connected virt-manager. | 20:29 |
| lifeless | 2601 root 20 0 934m 22m 8352 S 7.7 0.1 0:53.51 libvirtd | 20:29 |
| lifeless | and another MB | 20:30 |
| hallyn | what on eatth | 20:32 |
| hallyn | earth | 20:32 |
| lifeless | 2601 root 20 0 934m 24m 8352 S 4.6 0.2 1:03.86 libvirtd | 20:32 |
| lifeless | hallyn: well yeah, this is why I filed a bug :) | 20:32 |
| hallyn | but why am i not seeing it | 20:32 |
| lifeless | hallyn: what columns are you showing per VM ? | 20:32 |
| hallyn | ? | 20:33 |
| lifeless | hallyn: I have VM, CPU usage and "Host CPU usage' all shown. | 20:33 |
| lifeless | hallyn: just wondering if turning on the host cpu usage column might be triggering a different codepath in the daemon | 20:33 |
| hallyn | trying that | 20:34 |
| hallyn | nothing yet, will keep it running for awhile | 20:37 |
| cjwatson | doko: Could you steer clear of apache2 and its stack, just until I ram it all into -proposed? | 20:38 |
| cjwatson | I really hope adding lua5.2 hasn't attached some other transition to it | 20:39 |
| lifeless | slangasek: "the aikido is strong in this one" | 20:40 |
| lifeless | hallyn: 2601 root 20 0 934m 32m 8352 S 8.9 0.2 1:34.10 libvirtd | 20:40 |
| slangasek | lifeless: reading d-devel? :) | 20:40 |
| lifeless | slangasek: how *did* you guess? | 20:40 |
| hallyn | i had to work so hard not to jump in at the repsonse about fedora.vs.ubuntu obPA | 20:42 |
| slangasek | heh | 20:42 |
| hallyn | "it's ubuntu's fault they bought our line last time. so it only makes sense you should believe us this time" | 20:43 |
| hallyn | lifeless: what exactly is that the output of | 20:43 |
| hallyn | ps i assume, what options? (I'm jst grepping for RSS in /proc/$$/status) | 20:44 |
| hallyn | I'm up by 200k after a few minutes. may or may not be onto something... | 20:44 |
| hallyn | it's no 3M/s though | 20:44 |
| lifeless | hallyn: top | 20:50 |
| hallyn | oh, ok - libvirt isn't on the first page on my top :) | 20:51 |
| lifeless | hallyn: press M :) | 20:51 |
| hallyn | ok :) | 20:51 |
| hallyn | thanks - wasn't thinking. wel lit's not going up. i'll have to try a few more things tonight | 20:52 |
| lifeless | hallyn: clearly I can reproduce it at the moment :) | 20:52 |
| lifeless | 2601 root 20 0 934m 43m 8352 S 6.3 0.3 2:27.94 libvirtd | 20:52 |
| hallyn | lifeless: i notice you have two nics, that might be related | 20:53 |
| hallyn | but, i'll look back through changelog and compare to your setup | 20:53 |
| lifeless | pleia2 is running basically the same setup as I | 20:55 |
| lifeless | we're dev/testing OpenStack stuff | 20:55 |
| hallyn | say are you using openvswitch bridges for your vms? | 20:57 |
| lifeless | yup | 21:00 |
| doko | cjwatson, I checked that before the upload, that it doesn't interfer with it | 21:00 |
| lifeless | hallyn: https://github.com/tripleo/incubator/blob/master/devtest.md covers the workflow we're working through/automating/polishing. | 21:01 |
| lifeless | hallyn: I don't expect the content of the vm's to matter, so you can ignore all the diskimage-builder stuff etc, just climb through the setup-network, boot-seed-vm and create-nodes code. | 21:01 |
| hallyn | thx | 21:03 |
| lifeless | hallyn: also its a bit inconsistent in growth rate: 2601 root 20 0 934m 119m 8356 S 0.0 0.7 8:11.20 libvirtd | 22:14 |
| === salem_ is now known as _salem | ||
| === Zic is now known as Guest81623 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!