=== vorian is now known as v === racarr is now known as racarr|themanbur === racarr|themanbur is now known as racarr [00:51] kirkland: did you mean to upload +byobu (5.46) released; urgency=low into raring? that's like even ahead of saucy =) [00:57] 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:58] cjwatson: looking. [01:25] cjwatson: hey, any idea how to solve this? http://pastebin.ubuntu.com/5882703/ [01:26] that's during lb [01:26] sergiusens: looks like the .click file is somewhere not readable by the clickpkg user [01:27] like a mode 700 directory owned by some other user or something [01:27] cjwatson: a good, let me check, thanks [01:28] BTW I think you should lose the -app suffix there [01:28] Makes sense for the .deb packaging, not so much for click [01:28] * cjwatson -> bed, again [01:28] cjwatson: ok, I'm just grabbing whatever was in debian/control ... I'll strip it [01:51] cjwatson: pushed the merge to lp:~xnox/ubuntu/saucy/drizzle/merge, will sleep and upload tomorrow. [01:52] * xnox Zzzzzzz === salem_ is now known as _salem [02:33] argghh.. why are the ipv6 addresses busted again? :( === _salem is now known as salem_ === salem_ is now known as _salem [04:15] Good morning [04:28] barry: did you happen to request syncing of codespeak-lib? [04:29] 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:35] pitti: https://launchpad.net/ubuntu/saucy/+source/codespeak-lib/1.4.15-1 does make me think it was barry. [04:35] ScottK: aah, thanks [04:36] 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:53] dobey: ubuntuone-client's autopkgtest needs its stderr suppressed or redirected to stdout or a file [04:53] 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? === broder_ is now known as broder [05:42] ev: I think the noninteractive UI needs some more thought [05:43] 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? [06:57] pitti: difficult to change in what sense? We do want the crash reports to send silently, yes. Is that not the case here? [06:58] 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:59] ev: I meant that if you file a bug report (apport-bug package) you might actually want the UI [06:59] ev: and that update-notifier or whatever sends the crashes on the phone should perhaps directly call apport-noui instead of apport-bug [07:00] 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:01] ev: we used to change the value of enabled regularly, and peopel still do it manually [07:01] 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] ev: but anyway, aside from the conffile issue I think the different default for it in desktop and phone builds makes this impractical [07:02] ah, very good point [07:02] ev: e. g. update-notifier directly calls /usr/share/apport/apport-gtk === bigon_ is now known as bigon [07:02] ev: so that option wouldn't work there [07:02] ev: and conversely calling apport-bug manually ought to give some UI, even on a server (-cli) [07:02] well it now calls apport-collect in saucy [07:02] but yeah [07:02] ev: oh? I just did apt-get source update-notifier, and it still calls apport-gtk [07:03] ev: nothing is ever supposed to call apport-collect automatically [07:03] update-notifier 0.140 [07:03] why? It's just a "pick the right UI" layer [07:04] ev: you mean -bug, not -collect? [07:05] 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] (nice to have a job for this now!) [07:05] pitti: is there a difference? -collect is a symlink [07:06] iknowright! [07:06] ev: oh yes, it checks argv[0] for what to do [07:07] -collect -> update an existing bug, needs launchpadlib, python2, and LP credentials [07:07] otherwise, "report a new bug" [07:07] ah, I missed that entirely [07:07] so not collect then [07:08] 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] 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] works for me [07:08] or call -ui directly, sure [07:09] any preference on where the configuration option should live? [07:09] ev: u-n was already fixed, it's calling apport-bug [07:09] ah right [07:09] good morning! :) [07:09] ev: do we need one at all? [07:10] pitti: so we could just use the apport enabled= toggle [07:10] ev: phone upstart job would set $APPORT_UI, and otherwise calling apport-bug should DTRT? [07:10] we need to point this at something: https://wiki.ubuntu.com/ErrorTracker#Privacy_settings [07:11] do keep in mind that we'll want to provide UI on the desktop for automatic reporting as well [07:11] ev: the "collect app crashes and errors"? that sounds like "enable"? [07:11] the developer "I know what these are, just send them" [07:11] yes [07:11] it's definitely enable/disable [07:11] ah, for that [07:11] but the tricky bit is the developer on the desktop [07:11] yeah [07:12] ev: that's a per-user setting, right? [07:12] or does the admin set it globally? [07:12] I think it makes more sense as an admin setting, and we definitely want it that way on the phone [07:13] I think :) [07:14] ev: then I don't mind adding that to /e/d/apport, as we don't change that file regularly any more [07:14] okay [07:14] ev: except if you want this at automatic=1 at phone builds, which we can't do [07:14] as it's a conffile [07:14] oh hm [07:14] I do want that :) [07:14] if the phone cronjob will take care of it, and automatic=0 is fine there, the we can do it [07:15] ev: how about a non-conffile /etc/apport/automatic flag file? [07:15] works for me [07:15] phone builds/images can then create this, and no conffile conflicts [07:15] sounds good [07:19] ev: http://paste.ubuntu.com/5883292/ ? [07:20] yup, perfect [07:21] ev: still feels a bit strange for apport-bug (non-crash bug reports), but let's use this for now [07:23] okay [07:24] ev: ok, committed [07:24] ev: I'll do a new upstream release now and upload, unless you have something else? [07:24] thank you muchly [07:24] nope, please proceed [07:25] ev: FYI, new feature, bumping to 2.11 (for your next NEWS entry) [07:25] * ev nods [07:27] ev: thanks for the discussion [07:28] thank you for discovering the problems with this [07:34] start on (file FILE=/var/crash/*.crash EVENT=create) [07:34] OMG that's so great; I've waited for this since 2005 or so :) [07:34] jodh: ^ thanks! [07:42] pitti: errm, np. [07:42] * jodh waits for irclogs.u.c to update to see what he's done... :) [07:46] jodh: adding support for start on (file FILE=/var/crash/*.crash EVENT=create) === iulian_ is now known as iulian [07:46] with that we should be able to eventually drop update-notifier [07:47] pitti: ah - team effort: bdmurray actually wrote the job :) [08:38] 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:39] xnox: the problem comes with this not just being an option for phone [08:39] it's going to be an option on the desktop as well [08:39] so apw and infinity can say "just send the damn things. stop bugging me!" [08:40] oh please yes [08:41] ev, was it a deliberate decision that teh default for that dialog is cancel btw ? [08:41] what dialog? [08:41] 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] ev, your 'do you want to send this error to ubuntu' thingy [08:41] apw: yes, in case it steals your focus or you don't read it all before (accidentally) pressing Enter [08:41] apw: gtk+ deficiency, as by design there shouldn't be a default action, yet gtk+ forces one. [08:42] xnox: I never want to utter the words, "it's easy. Just open up a terminal and" [08:42] pitti, that is not a solution the solution is to _not_ steal my focus ever [08:42] ev: upstart has dbus API..... [08:42] xnox: because DBus is easy [08:42] xnox: next you'll tell me that problems like these can be quickly solved in lisp [08:43] apw: let's hope that unity8 fixes that :) it seems compiz doesn't [08:43] all you need are a few parenthesis. Simples. [08:43] snaaaake! [08:44] :D [08:44] 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] 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] but I take it GTK+ doesn't let us do that? [08:44] pitti, obviosuly you can think of better words :) [08:45] pitti, then if you hit enter it just reappears [08:47] 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] quite a bit of distributed systems stuff in there too [08:47] Adrian Cockcroft's talk on Netflix OSS in particular [08:48] ev: My new adventures are all to do with deploying clouds @ at scale. [08:48] ev: so big data enabling rather than big data doing; but I am definitely still interested! [08:48] ev: thank you for the link! [08:48] excellent :) [08:48] anytime [09:10] 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] xnox: perfect, that's exactly what I'm already doing locally [09:11] I'd give you a pastebin, but I'm on a different computer [09:11] however, caution applies [09:11] oh? [09:11] xnox: please not; having any firefox plugin be able to format your internal hard drives or changing the boot sector is evil [09:11] ev: ^ my response to "so that's what I need to change to make usb-creator stop asking questions again" [09:12] pitti: would above be at all suitable for like - to stop apport asking for my password 16 times in a row? [09:12] 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] pitti: yes, this is something I'd only want set on the phone [09:12] 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] I think the password prompt still makes sense for changing anything under com.ubuntu.WhoopsiePreferences on the desktop [09:13] pitti: on the phone, with readonly rootfs, only "blessed" hooks are in.... [09:14] 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] xnox: as the apport API is essentially a "run anything as root", it probably needs to stay password protected [09:15] but we wouldn't see these on the phone as ev just disabled all these prompts in apport with the noninteractive UI :) [09:15] 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] just doing my part to make apport webscale [09:16] xnox: I meant that it calls the "root_command_output()" function 16 times instead of using attach_root_command_outputs() [09:17] ev: does that involve throwing away 90% of errors? [09:17] 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] (X.org or kernel bug reports, etc.) [09:17] yeah =/ [09:17] of course these will just break again with the non-interactive UI [09:18] lifeless: I have not yet made the leap to deleting to increase all sorts of performance areas [09:18] :P [09:18] mostly because we're still learning, still going back and building indexes out of the entire data set [09:18] 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] if I was really confident in our data model, then yes :-P [09:26] pitti, ping [09:31] tvoss_: pong [09:31] pitti, hi :), if you have time please take a look at http://paste.debian.net/plain/16505 [09:32] ricotz: oh, I thought make install forgot to install them [09:32] pitti, not really ;) [09:32] ricotz: thanks, uploading [09:33] pitti, yw [09:35] 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:42] * cjwatson demotes/removes some packages for that transiiton [09:42] *transition === doko_ is now known as doko [09:50] 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] I can work around it easily enough. [09:51] * xnox ponders about using cjwatson's net-retriever deduplicator for transition-tracker & merges.u.c =)))))) [09:52] ... decides against it. [09:56] xnox: There's a perfectly good (fast) one in the transition tracker, and merges shouldn't need it [09:57] rbasak: Will check [09:58] Oh, indeed, I think I never got round to making merges look at -proposed [09:59] 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 [10:02] cjwatson: sure. [10:02] 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] ) [10:06] * rbasak has filed bug 1202142 [10:06] bug 1202142 in Merge-o-Matic "Blind to new development release -proposed pocket" [Undecided,New] https://launchpad.net/bugs/1202142 [10:07] Ta [10:07] 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:08] xnox: Yeah, I think Laney wrote that and didn't commit, originally ... [10:08] Seems possible [10:08] feel free to do it [10:08] Laney: is there way to run saucy & saucy-proposed locally without fiddling, as upstream? [10:08] Laney: ah =) ok, patches welcomed ;-) [10:09] The multiple suites thing is all local [10:09] it skips the 'downloading' part of ben [10:09] So that's why I didn't commit it [10:09] Laney: i guess one day we will upgrade to newer ben?! =) [10:10] I don't know if newer ben even handles this [10:11] but yes - some time ago I started writing a charm to get it off lillypilly [10:11] Then we don't need to block on IS and chroots and stuff [10:11] Well [10:11] Having it not tied into the archive-reports infrastructure would be problematic [10:12] But we're getting a new machine to offload the archive jobs from lillypilly [10:12] because of lag? [10:12] Just because all the stuff on there is too much for one machine [10:12] to the former [10:12] * xnox thinks drizzle is amd64 only software.... [10:12] Right, it needs to be guaranteed up-to-date with the archive and update as quickly as possible [10:13] 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:16] Ah, I was assuming that *stack had access to ftpmaster so it'd be the same [10:16] Anyway, I think that precise is new enough for new ben so this new machine might be OK [10:16] not that there's a huge need to move forward anyway [10:18] Direct access to ftpmaster is heavily restricted [10:18] And if it were on some other machine we'd need to figure out a way to trigger it from archive-reports [10:19] Also, lillypilly is on precise [10:19] the chroot is lucid though [10:19] It's not so much the version of the host, as that IS were uncomfortable with installing -dev packages in the root [10:19] but I'm sure that could be updated separately [10:19] It might be worth seeing if fakechroot is good enough [10:19] It certainly good [10:19] er, could [10:20] Yeah, seems I can ping ftpmaster but not rsync the dists tree [10:20] oh well [10:21] Wouldn't surprise me if fakechroot were good enough. I don't think I tried that [10:23] Would be useful to be able to self manage it === Sweetsha1k is now known as Sweetshark [10:31] Laney: ftpmaster seems to be http only even from lillypilly. no rsync there. [10:33] xnox: Untrue [10:33] xnox: We have special arrangements [10:35] xnox: There are ubuntu-dists and ubuntu-germinate modules which lillypilly can access; it doesn't have blanket access, that's all [10:36] xnox: See (internal) RT#47981 and RT#49414 [10:36] 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:37] xnox: No. [10:37] xnox: We're not going to open public rsync direct from ftpmaster. [10:38] This is a very special-purpose deal. [10:42] Ah, so I investigated. [10:44] dose-distcheck has a --latest option - if ben migrates to this then we can stop deduping [10:44] I still don't think it has multiple suite support though [10:45] 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:46] infinity: RT#63122 [10:50] cjwatson: \o/ [10:50] 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] I suppose I should tell the ticket this. [10:51] I'll make some time to see if fakechroot works for ben [10:51] If we're shuffling it anyway, might as well move then [10:53] infinity: Yeah, particularly for the things with lots of inodes (germinate output et al) [10:53] Laney: Cool [10:54] 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] ogra_, ping [10:54] cjwatson: Commented on the ticket, anyway. Up to IS if they want rewrite/proxy rules they have to manage. [10:54] Ta [10:55] infinity: The alternative would be exposing newmachine's http port directly and then having a redirect rule [10:55] cjwatson: Yeah, which is even more CPU friendly, but client hostile. [10:56] cjwatson: But worth noting as a third option. [10:56] Will do [10:56] tvoss_, yo [10:57] Oh, FFS, I can't add myself as a CC to a ticket? [10:57] ogra_, do you happen to know if we have a perf build for the touch image? [10:57] tvoss_, i think we do, for deatils ask #ubuntu-kernel though, i never used it [10:57] infinity: I think you have to ask for that, yeah :/ [11:17] yolanda, when you touch graphviz for the lua update, could you have a look at building with ruby1.9 as well? [11:18] doko, just focused on rrdtool now, but we could add ruby to the list [11:19] ohh, rrdtool too [11:19] doko i'm finding that liblua isn't copying the libraries anyway... do you know about it? [11:19] no, I just did see that we were pulling 5.2 in main, without discarding 5.1 [11:20] yolanda: Could you leave graphviz until Apache 2.4 has landed in saucy, please? [11:20] cjwatson, yes, not touched graphviz still [11:21] 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] i think that there is some problem with liblua, no libraries copied anywhere [11:23] 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] could be similar, where upstream builds them, yet packaging didn't actually install them properly. [11:24] i'll take a look now === MacSlow is now known as MacSlow|lunch [11:28] xnox, i found that libraries are copied into /usr/lib/x86_64-linux-gnu, instead of /usr/lib/lua [11:28] path should be /usr/lib/lua/5.2/, right? [11:29] not sure. depends how lua operates, and whether it started using multi arched or not. [11:29] Could also be an accident from higher debhelper compat levels. [11:29] doko: ^ maybe you know correct paths for lua? [11:33] xnox, didn't look. lua itself is multiarch, didn't look at the layout for the modules and extensions [11:41] doko, xnox, it's multi arched, but something is wrong, just copying the files to /usr/lib/x86_64-linux-gnu/liblua5.2.so === Evpok_ is now known as Evpok [11:59] yolanda: Certainly sounds like that should be in a lower-level plugin directory like /usr/lib/x86_64-linux-gnu/lua/something, yeah. [12:00] yolanda: But you'd have to look at what pre-multiarch lua did, and then logically twiddle that. [12:00] Having more issues with php5 including a build failure with my new merge. I'm working on it. [12:08] infinity, please could you merge eglibc? [12:09] doko: Yes. Is there a specific fix you're urgently waiting on, or do you just hate outdated version numbers? :) === jdstrand_ is now known as jdstrand [12:10] doko: (The merge is sitting here on my laptop, I'll get it up after another test or three) [12:11] infinity, I need a stable cross chroot, and would like to avoid to have it rebuilt soonish again [12:11] can somebody please reject https://code.launchpad.net/~logan/ubuntu/saucy/json-c/0.11-2ubuntu1/+merge/174910? [12:12] infinity, and yes, the reverted error code change causing some issues with python modules would be good to have too [12:12] dholbach: done [12:13] thanks [12:14] doko: Oh, the getaddrinfo() fix? Yeah, fair enough. I'll finish up testing. [12:14] yes === MacSlow|lunch is now known as MacSlow === stub` is now known as stub === _salem is now known as salem_ [12:44] smoser: I have a request for help from the Pilot [12:44] 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:45] smoser: LP: #1005901 [12:45] Launchpad bug 1005901 in duplicity (Ubuntu Precise) "cannot change temp dir" [Undecided,In progress] https://launchpad.net/bugs/1005901 [12:46] 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:47] hmm this sponsor-patch script seems interesting... [12:48] 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:49] pitti: in that case, i won't do anything until the debian bug gets closed. once that's got the tests, i'll resync [13:00] pitti: why does it need the redirection? [13:02] 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] so in that case a 2>&1 is the usual fix [13:04] pitti: that sounds like a bug in autopkgtest if it's counting stderr output as failure [13:04] it's the currently defined behaviour [13:04] i. e. it doesn't happen accidentaly [13:04] @pilot out === 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: [13:04] This has been argued in the past as a misfeature, yes, but it's the way it is. [13:05] caribou, i'm not pilot, but i'll take a quick look and see if i cna't help [13:06] smoser: the topic did say you were, sorry 'bout the noise [13:06] smoser: it's a small backport that's already in quantal. sponsor-patch doesn't report anything I could see === tlyu_ is now known as tlyu [13:07] yeah, not your fault :) [13:08] caribou, did you figure it out ? [13:08] I filed bug 1197005 about it [13:08] bug 1197005 in autopkgtest (Ubuntu) "Printing to stderr should not be considered a test failure" [Undecided,New] https://launchpad.net/bugs/1197005 [13:08] It's a pain when developing tests, since eg. "set -x" writes to stderr. [13:08] 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] smoser: I was able to figure out how to reproduce it & did test the fix from Quantal [13:09] dobey: we generally want stderr failure; the feature flag is a nice idea [13:09] 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:10] 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] caribou, so you want htat debdiff sponsored. is that it? [13:10] smoser: yes, indeed [13:10] 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] 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] 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] OTOH, the stderr causing a test failure has severely harmed my test development velocity. [13:10] barry: I don't think LP notifies you, that's why I pinged you explicitly [13:11] barry: There's no notification when packages are removed. It would be a lot of noise for routine removals. [13:11] dobey: right, that's what we want it for -- new CRITICALs, for example [13:11] pitti: yeah, for which... thanks! :) [13:11] pitti: yes, but i shouldn't get a failure in ubuntuone because the theme broke :) [13:12] infinity: would it be a lot of noise for proposed migration "failures"? [13:12] or because twisted is using deprecated API [13:12] barry: What failure was there? pitti removed a package, that's not a failure, it's an explicit action. [13:13] infinity: codespeak-lib's autopkgtest failed because the autopkgtest was dropped from the sync [13:13] 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:14] infinity: what i mean by "failures" is any disruption in the normal migration pattern [13:14] 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:15] This particular case seemse to be a bit of a special case. [13:15] And a direct ping seemed appropriate, since one would also want to expand on "why did you remove that?" [13:16] infinity: well, getting a single notification that the autopkgtests failed in my upload, would be nice. [13:16] dobey: That's meant to be happening (or maybe has already happened?) [13:17] jibel: ^ [13:17] 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] xnox: no... sorry, let me see what went wront with my release script... [13:18] dobey: I get e-mail notifications when my uploads' autopkgtests fail, and have done for a couple of weeks now. [13:18] 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] (Along with notifications when they go back to passing.) [13:18] 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:19] I wonder how painful it would be to mangle packages.qa.d.o to work for Ubuntu. [13:19] jibel: Perhaps this is a case where the test has always failed ... [13:19] jibel: i haven't seen any e-mail [13:19] Although https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-ubuntuone-client/ was apparently only introduced recently [13:19] dobey: Oh, is this on an upload YOU are doing, or something autolanded by a bot that bins email? [13:19] cjwatson, no it was codespeak-lib that used to pass [13:19] jibel: i did not get anything [13:20] infinity: uploads i made [13:20] anyway, I'll have look [13:20] Kay. [13:20] The software-center pyflakes failure amuses me [13:20] packages.qa.d.o is very useful. It has a lot of parts though [13:20] xnox: doh. I see what went wrong. thanks. I'm fixing it up now [13:20] It's picking up bad syntax in .pc/ [13:21] Laney: oh, fun [13:21] dobey: There's also ones which try to access the internets and fail [13:21] 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/ right now, which lacks a lot of useful info. [13:22] 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] Laney: from pyflakes? [13:22] no, other tests [13:22] Laney: I'm sure I remember fixing something like that in some other package recently-ish [13:22] (pyflakes vs. .pc) [13:22] https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-software-center/47/ARCH=amd64,label=adt/console [13:22] Laney: i knew i should have just done rm -rf debian/tests :) [13:23] Easy enough to do anyway [13:23] infinity: Yep [13:23] 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] 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:24] (In fact, doesn't it cheat on upload history by just being subscribed to -changes, rather than scraping anything there?) [13:24] Anyhow. Food for thought for a less busy day. [13:24] So, 2017. [13:27] 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] 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:28] dobey: I'll leave it with you now ;-) [13:33] barry: You're not alone in finding jenkins output unnavigable. [13:37] 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] yes, if you look at the console output or full "log" file you'll see the problem [13:39] pitti: In this case the log basically just says no tests were run [13:40] right, as they got dropped [13:40] 2013-07-16 16:33:33: Failure: adt-run exited with status 8. [13:40] Which is the documented "no tests" exit code [13:40] yes, but we don't want this to silently pass [13:40] So perhaps that's a bug in adt-britney or similar for running them in the first place [13:41] it's actually quite deliberate [13:41] I look at all failures (in case it's test machinery) [13:41] From adt-run's point of view it's obviously correct [13:41] cjwatson: if that was a deliberate removal, I had just removed the jenkins job [13:41] From adt-britney's point of view, I disagree (if indeed that's what ran the job here) [13:41] s/had/would have/ [13:42] 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] 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] Like I say, I'm not saying that the infrastructure shouldn't have failed on exit code 8 [13:43]