=== salem_ is now known as _salem === _salem is now known as salem_ === salem_ is now known as _salem [05:19] Good morning [05:20] Howdy. [05:20] hey Unit193 [05:20] Say, while it's quiet, know why utopic wouldn't like init=/bin/systemd while trusty was fine with it? [05:20] that never worked [05:21] you mean init=/lib/systemd/systemd [05:21] oh, there's a symlink [05:21] I never tried that [05:22] so, no off-hand idea [05:22] Cool, works for me. [05:23] Not that it matters much, but I've narrowed it to the initrd, but didn't really look much into it. [05:25] Unit193: yeah, this shoudl really only apply after the initrd [05:27] Yes, I say it's initrd because an old kernel worked, but after update-initramfs -c -k all it no longer did. Also from what I remember of the error message, it can't find the file it's looking for. Anywho, it works, and you've got better things to look at. :) [05:37] pitti: Good morning! Is there a way to arch- [05:37] RAOF: hey [05:37] arch-? [05:37] Premature . It's a curse :) [05:37] aaaarch [05:39] pitti: good morning [05:39] ...arch-restrict autopkgtests? Say if I wanted to test that you can install apitrace-gl-tracer:i386 and apitrace-gl-tracer:amd64 and then run “apitrace trace glxgears” with glxgears:i386 installed and “apitrace trace glxgears” with glxgears:amd64 installed? [05:39] pitti: I would need an ack on this landing https://ci-train.ubuntu.com/job/landing-019-2-publish/lastSuccessfulBuild/artifact/packaging_changes_qtcreator-plugin-ubuntu_3.0.1+14.10.20140516-0ubuntu1.diff [05:39] RAOF: you can use the full arch dpkg dependency syntax [05:39] pitti: it is a single line fix in the .desktop file [05:40] RAOF: so e. g. Depends: apitrace-gl-tracer:i386 [amd64], apitrace-gl-tracer:amd64 [amd64], ... [05:40] bzoltan1: hey [05:41] pitti: Ah, funky! And that'll ensure the test gets run on an amd64 box? [05:41] bzoltan1: it could certainly do with a justification in the changelog ("got dropped in X.Z.Y", "it's the default now", etc.) [05:41] RAOF: no, they'll still run everywhere, but that means that those packages will only get installed on amd64 [05:41] So the test will fail everywhere but amd64? [05:42] RAOF: your test can just query uname -m or dpkg --print-architecture or whatever to do arch specific stuff [05:42] pitti: this -client was introduced in the previous release, before that it did not exist. Eventually I overlooked that it causes problem [05:42] Yeah, about to say that :) [05:42] or just test if a particular command is available with "which" or so [05:42] Cool. I'll see about hooking up some tests. [05:42] RAOF: so at the moment there's no "Architecture:" field there [05:43] bzoltan1: so the general change is trivial and fine of course, and you know much better whether it's right than me [05:43] pitti: it brakes the Ubuntu SDK desktop file when there is no QtC instance running ... would be cool to publish this revert before the rest of the world wakes up and does upgrade [05:45] RAOF: and for the "just :i386 installed" vs. "just :amd64 installed" you should create two tests which just depend on one of those; you'll get a clean test bed for each test [05:45] hmm, lp:ubuntu/mutter and lp:ubuntu/gnome-shell branches are way out of date! [05:49] RAOF: and you want to run xvfb-run -s '-screen 0 1024x768x24' glxgears ? [05:50] pitti: Yeah, something like that. I think I'll actually need to run it under a proper Xorg with dummy drivers, though; does xvfb do GLX nowadays? [05:50] RAOF: yes, with above -screen option [05:50] Sweet. That's even easier! [05:50] RAOF: the only reason why "xvfb-run glxgears" doesn't work is because xvfb still defaults to an 8bpp screen [05:50] RAOF: but GLX swrast needs 24bpp [05:50] RAOF: yeah, took me a while to find that out [05:51] RAOF: (that command works, just tried in a chroot) [05:52] llvmpipe for the win (I think) [05:52] Presumably :) === rww is now known as Arstotzka === Arstotzka is now known as rww [07:11] good morning [07:46] pitti, xnox, all image builds failed tonight with what looks like an invoke-rc.d issue ... seems everything that has an init script (or rather an upstart job burt no init script) fails to install [07:54] invoke-rc.d: unknown initscript, /etc/init.d/whoopsie not found. (and a lot of other packages on touch) [07:54] xnox, pitti ^^^^ [07:55] ouch, that smells like yesterday's sysvinit upload indeed [07:56] yeah, i just see the lxc upload from xnox [07:56] i guess we need to do that for a lot more packages [07:56] ogra_: that was just a followup for the sysvinit one [07:56] no, that was a special casea [07:56] $ sudo initctl status whoopsie [07:56] that works [07:56] the LXC issue was that "sudo initctl status lxc-instance" does not work [07:57] well [07:57] - dh_installinit --no-restart-on-upgrade --name=lxc-instance [07:58] + dh_installinit --no-start --no-restart-on-upgrade --name=lxc-instance [07:58] right [07:58] it just adds --no-start [07:58] yes, because lxc-instance isn't meant to be started during boot or on package install [07:58] oh [07:58] but whoopsie and friends are [07:58] k [07:59] ogra_: if you try above status command, you'll see "initctl: Unknown parameter: NAME" [07:59] ogra_: that's a "template" job which can be instantiated, it's not a standalone job by itself [07:59] hence the special case [07:59] ok ... so not the image build issue then [07:59] so, apt-get install whoopsie works in a schroot [08:00] ogra_: do you have an URL for an affected log? [08:00] http://people.canonical.com/~ubuntu-archive/livefs-build-logs/utopic/ubuntu/20140515/ ? [08:00] ubuntu daily only has the one whoopsie issue above ... touch has a lot more: http://people.canonical.com/~ubuntu-archive/livefs-build-logs/utopic/ubuntu-touch/20140516/livecd-armhf.out [08:01] ack [08:01] I see it there [08:01] ogra_: is that actually a failure? [08:01] the "All runlevel operations denied by policy" is fine, due to policy-rc.d [08:01] dpkg thinks so at least [08:02] the "invoke-rc.d: unknown initscript, /etc/init.d/whoopsie not found." is certainly ugly [08:02] ogra_: hm, I don't see an actual failure in above log [08:03] oh, I was looking at http://people.canonical.com/~ubuntu-archive/livefs-build-logs/utopic/ubuntu/20140515/livecd-amd64.out [08:03] which is fine [08:03] pitti, look at the touch log ... seems /20140516 was not mirrored yet for desktop [08:03] (failed only 20min ago) [08:04] oh, I have an idea [08:04] the new update-rc.d calls initctl status [08:04] but that wouldn't actually work if upstart isn't running [08:04] Processing triggers for libreoffice-common (1:4.2.3~rc3-0ubuntu3) ... [08:04] Errors were encountered while processing: [08:04] modemmanager [08:04] whoopsie [08:04] E: Sub-process /usr/bin/dpkg returned an error code (1) [08:04] so it would consider this as "no such upstart job" and fall back to init.d [08:05] this is how desktops 0516 ends in the mail [08:05] *nod* [08:05] and in my schroot it can talk to the "outside" upstart and thus succeed [08:05] ah [08:05] I bet if I boot with systemd I can reproduce it in a schroot, brb [08:06] do our chroots use systemd ? [08:07] ogra_: schroots don't have a pid 1 (that's not a container) [08:07] well, they just use the "outside" pid 1, they don't have a separate process NS [08:07] well, i was talking about the build ... that uses plain chroots [08:08] ogra_: yeah, so apparently these schroot builds either don't have upstart "visible" in the schroot (unlikely) [08:08] ogra_: or, which is more likely, they don't run whoopsie [08:08] thus "status whoopsie" in the chroot fails as the host doesn't have a whoopsie job [08:09] etting up whoopsie (0.2.26) ... [08:09] invoke-rc.d: unknown initscript, /etc/init.d/whoopsie not found. [08:09] dpkg: error processing package whoopsie (--configure): [08:09] subprocess installed post-installation script returned error exit status 100 [08:09] bingo [08:09] xnox: AYT? [08:10] hmm i think we simply inherited debians policy here ... while we allowed upstart only they dont ... isnt it like that ? [08:11] ogra_: that too [08:11] ah, I think it's even a bit different in my schroot now and the livefs builders [08:11] they do have upstart running, but no whoopsie job [08:11] on touch it is like 30 packages that fail [08:11] while I now don't upstart running [08:12] i. e. "initctl version" should succeed on the livefs builders, but fail for me [08:13] ogra_: it seems xnox is still not awake; I think I know what to revert, I just wonder if we should wait a bit for him to get online, or upload right now [08:13] * service & invoke-rc.d: unset UPSTART_SESSION environment variable to [08:13] make sure all upstart initctl commands are executed against system [08:13] init and not the session one. (Closes: #745505) [08:13] no, it's the other one [08:13] * ogra_ glares at this changelog entry in sysvinit ... what ?!? [08:13] - && [ -e "$UPSTARTDIR/${INITSCRIPTID}.conf" ] [08:13] + && initctl status ${INITSCRIPTID} 1>/dev/null 2>/dev/null [08:14] still [08:14] ogra_: that one is right and harmless [08:14] why would you run a session job against the system process ? === yofel_ is now known as yofel [08:14] ogra_: no, if you run "initctl status whoopsie" as user, it will look for a session job [08:14] ogra_: while that is always wanting the system job [08:15] i. e. "initctl --system status whoopsie" [08:16] the "service" change also looks ok to me as it's guarded with initctl version [08:16] ah no, same problem [08:18] about half of the failed jobs on touch are session ones ... [08:18] and i dont think the code above matches for that [08:20] * pitti needs to reboot with upstart again to completely verify the fix, brb [08:20] ah, looks like all the session ones i see fail are somehow depending on a package with a system job ... so all is fine [08:22] pitti: ogra_: hello, what's up? [08:22] xnox: so, sysvinit broke live fs builds [08:23] xnox: I think I understand the problem now: [08:23] xnox: the live fs builder's host is running upstart, so initctl version will succeed [08:23] xnox: the live fs builder is not running whoopsie, so initctl status whoopsie will *fail* [08:23] xnox: but we use that now to decide whether $INITSCRIPTID has an upstart job, instead of [ -e "$UPSTARTDIR/${INITSCRIPTID}.conf" ] [08:24] pitti: *sigh* [08:24] xnox: thus it tries to fall back to an init.d/whoopsie script, which doesn't exist [08:24] and then it throws up its arms [08:24] pitti: (a) shroots shouldn't be running or trying to start an upstart session by default [08:24] xnox: xnox they don't [08:24] xnox: its' the *host's* upstart they are talking to [08:24] xnox: remember, it's a simple chroot, not a container; no separate process NS [08:25] what's the version of upstart on the host? [08:25] it doesn't matter [08:25] (and I don't know) [08:25] pitti: it does matter - you could potentially boot the host init with sessions disabled [08:25] upstart used to have chroot session, which should be fine. and i thought invoke-rc.d was diverted during package builds. [08:25] jodh: well, perhaps it does, but not for this bug [08:26] the builds happen in a triple stacked chroot setup ... iirc [08:26] pitti: upstart has ability to load and start /etc/init/ jobs in the chroot. [08:26] xnox: no, it installs policy-rc.d to just disable jobs [08:26] I can reproduce the problem just fine [08:26] not sure what version the uplevel one has ... perhaps it is trusty ... [08:26] pitti: oh, only policy-rc.d. hm =( [08:26] "sudo dpkg -P whoopsie" on your workstation [08:26] *toplevel [08:26] schroot -c utopic -u root [08:26] apt-get install whoopsie [08:28] (but could well be precise) [08:29] xnox, ogra_: tested fix/revert: http://paste.ubuntu.com/7471889/ [08:29] certainly not ideal and this will need refinement, but it reverts to a known-working state for n ow [08:29] pitti: how is policy-rc.d preventing upstart jobs to be started? [08:29] xnox: invoke-rc.d checks policy-rc.d, and exit code "104" means "disable this job" [08:30] pitti: right, yeah, go ahead and upload that. [08:30] err, 101 [08:30] pitti: ok, and that is not happening here, and we still go and invoke start?! [08:30] it's in man invoke-rc.d; that has been the standard way to build chroots for decades in Debian, and every init system implements it [08:30] xnox: what is not happening here? [08:31] ah, my reproducer was missing "rm /usr/sbin/policy-rc.d" [08:31] i want to know how that check is implemented against upstart jobs. [08:31] pitti: so you cannot modify the hosts init options? If it's precise, you could boot with --no-sessions to fix this issue. To be clear that option is referring to *chroot* sessions - nothing to do with upstart users sessions [08:31] jodh: right, this has nothign to do with user sessions [08:31] jodh: well, ultimately, package installation in a chroot should not start the jobs in the chroot. [08:32] jodh: it's about "initctl status" in a chroot talking to the host's pid 1 (as there is nothing else to talk to really) [08:32] (as per distro/debian policies) [08:32] correct [08:32] pitti: I know - please re-read what I just wrote! :) [08:32] pitti: =)))) i'll show you in malta how initctl in the chroot, can talk to host's pid 1 and control it's own jobs in chroot =)))) [08:32] jodh: well, I did; I might have misunderstood it [08:33] xnox: can we do that in invoke-rc.d instead of the simple "initctl status"? [08:33] pitti: upstart is "chroot-aware" - so if an initctl command is run in a chroot (or schroot), the init *outside* the chroot *will* respond to those requests... unless you boot the outer init with --no-sessions (precise). This is the default with upstart in utopic. [08:34] jodh: ah, then I did misunderstand it [08:34] jodh: right, I suppose the livefs build host is running precise [08:34] pitti: but we should be, as per policy-rc.d, not even reach doing the "start" action. [08:35] xnox: yeah; as I said, I think in spirit your change is good; we just need to make it work with chroots [08:35] this revert is certainly not the "right" solution, it just unbreaks our live fs builds for the moment [08:35] pitti: i did $ schroot -u root -c utopic-amd64; did apt-get install whoopsie, and that installed fine. [08:35] xnox: did you purge whoopsie on your host? [08:37] ah, need update to latest / broken initscripts. [08:37] :) [08:37] man, my whoopsie highlight is going ca-razy === ev_ is now known as ev [08:37] whoopsie, I didn't mean to highlight you that often :) (SCNR) [08:37] lol [08:37] well played [08:37] it's kind of appropriate to use whoopsie to debug failures though :) [08:37] 'tis :) [08:44] pitti: i wonder if chroot's initctl can control system jobs =) [08:44] pitti: totally can.... [08:44] infinity: ^ [08:44] jodh: FTR, I reproduced that with current utopic on current utopic; I didn't enable chroot sessions anywyere, but you said that shoudl be the default now? [08:44] xnox: well, it's not like chroots were any kind of a security boundary :) [08:44] pitti: ignore the version of upstart in the chroot - it's the version of the one outside that matters [08:44] infinity: togging off chroot session, gives us a side effect that all upstart commands now control hosts system upstart =) and see hosts jobs, etc. [08:44] jodh: i'm thinking if initctl & friends should somehow figure out if they are in a chroot, and host's upstart has chroots not enabled, and then like error out and not return anything in $ initctl list, show-config, etc. [08:44] xnox: perhaps we could do "initctl status $job || [ -e /etc/init/$job.conf ]"? [08:44] that would still go wrong in a chroot where initctl fails and the job is not in /etc/init/ but someplace else [08:44] * xnox ponders why i see + [ ! -e /whoopsie.conf ] [08:44] exit 100 [08:44] but I'm not sure whether the situations where the job is someplace else would be relevant in a chroot build [08:44] xnox: did you forget to put "UPSTARTDIR=/etc/init/" back? [08:44] xnox: I assume you just changed initctl status to [ -e ] [08:44] pitti: i think i see what's wrong. [08:46] $UPSTARTDIR was removed, but used in the fallback path of the "failed to run job in chroot" [08:47] add back the variable or replace that last instance with /etc/init/ [08:48] pitti: so actually just adding UPSTARTDIR=/etc/init in your upload whould have fixed it. [08:49] pitti: see lines 281-292 [09:03] pitti: hm, after your upload reaches release pocket, i'll upload http://paste.ubuntu.com/7472003/ [09:03] xnox: hm, won't that exit with 100 then? [09:03] ah no [09:03] =) [09:03] '!' matters :) [09:03] xnox: nice, that's much better, thanks! [09:07] xnox: That seems to be exactly what you'd want without chroot sessions, yes. [09:09] infinity: you are probably right. chroots should be anything special. [09:33] hmm [09:34] since when do we not have "lo" defined in /e/n/i anymore ? [09:34] is that part of the systemd transition ? [09:37] ogra_: we do, but i thought installer defines that, no? [09:37] (i see where you are going with that....) [09:37] xnox, well, the file looks different to trusty ... i have lo up and running (this is indeed on a tablet with ubuntu touch as you might guess) [09:38] it is just the entry thats missing [09:40] lo was always done by netcfg, which obviously isn't run in ubuntu-touch [09:40] doesnt seem to do any harm ... just looks odd [09:40] /etc/init/network-interface.conf sets it up anyway [09:42] yeah and I believe ifupdown also has it hardcoded so it's pretty hard to get a system without lo [09:42] right [09:43] i was just wondering about /e/n/i [09:43] (well, i was always wondering before why we put it there ... since we have enough mechanisms to bring it up anyway) [09:43] We almost certainly didn't when that code was added [09:44] i have it on trusty [09:44] auto lo [09:44] iface lo inet loopback [09:44] stgraber, would you accept patches for ppa support in the sbuild-launchpad stuff? [09:44] Sure, but I don't actually spend most of my time looking for old code to remove ;-) [09:44] heh [09:45] darkxst: sure [09:51] stgraber, ok I will clean up my hacks, the general idea is to pass in a ppa when creating the chroot and it will create a bunch more alias' [09:51] (though they end up being really long alias'! [09:59] no answer on #ubuntu-phone so hoping for better luck here - no network indicator on ubuntu-touch image 32? [09:59] nmcli reports: [09:59] GENERAL.STATE: 20 (unavailable) [09:59] GENERAL.REASON: 2 (Device is now managed) [10:01] darkxst: that sounds like how I'd have implemented it, so great! === MacSlow is now known as MacSlow|lunch === seb128_ is now known as seb128 [11:44] come on sysvinit ... migrate faster ... [11:45] Hm, linux autopkgtest failed [11:45] pitti: ^- was that a testbed failure? [11:46] for syvinit ? excuses shows it still in progress [11:46] I'm looking at the backend [11:46] ah [11:46] :( [11:46] excuses is updating at the moment [11:47] yeah, i dont want to reload :P what i see currently at least left some hope :P [11:55] cjwatson: kind of; I guess we need to bump the timeout for the copying a bit higher :/ [11:56] cjwatson: feel free to temp override this as it's blocking live images [11:57] \o/ [11:57] :) [12:03] pitti,ogra_: forced [12:03] thx [12:13] sil2100: hi! [12:13] sil2100: sorry to ask, where is that spreadsheet again to list the landers for a project? I'm looking to land https://code.launchpad.net/~pitti/ubuntu-system-settings-online-accounts/fix-autopkgtest/+merge/219819 [12:14] sil2100: or can I just add it to https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0Au6idq7TkpUUdGNWb0tTVmJLVzFZd0doV3dVOGpWemc#gid=1 ?? [12:16] pitti: hi! [12:17] pitti: so, we don't use that spreadsheet anymore ;) We have a different one, but let me find you the list of landers - but from the branch I see it's either dbarth or mardy [12:17] https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0Au6idq7TkpUUdC05a2ZQSmgwU2NFYnJQOE9qMDRYa3c&usp=sharing#gid=1 <- here's the list of landers for each component [12:18] But I don't see that component there [12:18] pitti: let me poke dbarth about that one [12:18] sil2100: ah right, sorry (found it from https://wiki.ubuntu.com/citrain now) [12:19] mardy: hi! [12:19] mardy: could you take a look at pitti's merge request and, if +1, be the lander for it? [12:19] mardy: ^ [12:20] so for system-settings it would be seb128, but there's no name for s-s-online-accounts [12:20] does that mean "whoever gets to it"? [12:20] pitti, landers are not strict assignement, anyone can land anything [12:20] ack [12:20] it's just "usual contact point" [12:20] ah, ok [12:21] I think dbarth is handling the online account ones [12:21] but I'm happy to put a landing up for you [12:21] yeah, just coordinate with the team owning the upstream branch i gues [12:21] sorry, so far Mirv or sil2100 have been so kind of doing landings for me; need to learn that stuff some day [12:21] asac: I looked, but the owner is pretty much "everyone" (111 members) [12:21] right. [12:22] so if that component never landed, there might be no testplan in wiki yet [12:22] pitti, you want mardy for online account [12:22] pitti, asac: this one is from dbarth and mardy so that's why I poked him [12:22] usually we would like to see that happen before the first landing [12:22] ack [12:22] pitti: you could be the lander as well but we would have to ci-train train you ;) [12:22] asac: in that regard it shoudl be easy -- it's fixing a test, not the actual code :) [12:22] * asac levaes it to sil [12:23] sil2100: well, if I coudl self-approve/self-land, I could just JFDI dput it :) [12:23] pitti: right, but someone should create a testplan - even if very simple - for that tree; check with upstream team owning so they do that (if not now, at least after) [12:23] pitti: ok, since mardy is not around, let me be your lander :) [12:23] thought pitti wanted to learn it by doing now :) [12:23] hehe [12:23] sil2100: thanks; I verified it with adt-run .// --- qemu adt-utopic-amd64-cloud.img [12:24] sil2100: that builds the package, installs the built binaries, and runs the autopkgtest against it, and it succeeds now [12:24] and it's changing nothing else [12:24] the fixed AP test gets skipped on the phone (that's why it wasn't noticed before) [12:24] pitti: that's good enough for me :) Do you need someone to also look at that merge request? Not sure if there's someone in upstream who could have more experience in autopkgtesting than you anyway ;p [12:25] sil2100: not me personally; might be that upstream wants to look at it, of course [12:26] we're canonical, we dont care about upstreams :P [12:26] so yes, looks like mardy has poked it recently [12:26] ogra_: ;p [12:26] ogra_: ah, right of course -- TOSS IT IN! :) [12:26] haha [12:27] (merci dieu c'est vendredi) [12:27] yeah :) [12:27] Whatever that means! [12:27] sil2100: TGIF [12:27] sil2100, polish your french [12:27] oh the pun :) [12:27] ogra_: I prefer to french my polish :D [12:27] TGIF² [12:27] haha [12:28] hah ;) === MacSlow|lunch is now known as MacSlow === michagogo|cloud is now known as michagogo [12:31] pitti: sorry, was afk [12:31] pitti: just approved [12:32] mardy: no worries; thanks, that was fast! [12:34] sil2100: maybe you can put pitti's branch in dbarth's silo? (row 25) [12:34] * pitti goes to fix autopilot-gtk for the recent ap py3 change [12:34] mardy: right, but since it's a standalone change, and row 25 is still blocked on unity-mir [12:36] mardy: I think we can quickly land this before unity-mir is freed and before we can assign a silo for 25... [12:36] mardy, sil2100: it's not that urgent really, I just came across it; so no extra efforts please [12:36] sil2100: ok, but then maybe it's better to take https://code.launchpad.net/~mardy/ubuntu-system-settings-online-accounts/autopilot/+merge/218777 away from row 25 and make it land together with pitti's [12:36] pitti: does https://code.launchpad.net/~mardy/ubuntu-system-settings-online-accounts/autopilot/+merge/218777 look OK to you? [12:36] Oh [12:36] Ok [12:37] mardy: ok :) Can I make you the lander for those then? :) [12:37] mardy: ah, I didn't see that; but my branch supersedes that [12:37] mardy: or rather, it won't be enough [12:37] mardy: autopilot-desktop is py3 now, and there's still that broken test [12:37] pitti: yes, so we need both, right? [12:37] mardy: no, we don't [12:38] mardy: my branch also adds a dependency to autopilot-desktop-legacy [12:38] It seems to be a Friday of confusion for me ;p === lubko is now known as teliatko [12:38] pitti: ah, didn't see that [12:38] mardy: but as a test depends, not as a pacakge depends; if you prefer a package depends that works too; but it's unnecessary on the phone [12:38] sil2100: sorry, then please just delete https://code.launchpad.net/~mardy/ubuntu-system-settings-online-accounts/autopilot/+merge/218777 from dbarth's request [12:38] mardy: ok ;) [12:39] sil2100: about being the lander, what does that mean in practice? [12:39] mardy: in practice being a lander means the responsibility for building the package, resolving merge conflicts, testing the merge and setting it to 'ready' when it's OK to land [12:39] *merges [12:40] mardy: in case of this one, I guess not much testing is needed though [12:40] mardy: I'll do this one if anything [12:40] sil2100: I could do all of that, except setting the "ready" bit, as the spreadsheet is view only for me [12:41] mardy: it is? Weren't you a lander already ? :O [12:41] sil2100: no [12:41] sil2100: mmm, actually, I don't even know how to start the build; maybe it's better to wait for dbarth, we'll be back later [12:41] s/we/he/ [12:42] mardy: no problem, I already started the build and will lead this one till the end - but it would be nice if you could be a lander as well anyway [12:42] sil2100: +1 [13:14] hi [13:15] hey hrw [13:17] ogra_: can you remind me what is ubuntu way of dealing with software tests? [13:17] depends on what level ... [13:17] we have autopkgtests for packaging ... we have autopilot for UI tests [13:18] ogra_: I went to another package where testsuite was not built at all [13:18] hrw: and unit tests are build & executed at build-time. [13:18] then there are unit tests ... and there are CI tests that run in jenkins for each merge proposal on LP === ted is now known as tedg [13:19] hrw: by default equivalent of $ make check test, is run at build time. Unless disabled, or the test target is somthing funky. [13:19] mkey [13:20] * hrw -> figure out how to run openbabel tests in ubuntu [13:32] hrw: maybe there is simply a typo? http://paste.ubuntu.com/7473039/ [13:33] hrw: building now. [13:33] xnox: thanks [13:34] test targets are getting built.... [13:37] xnox: now arm64 will fail [13:37] hrw: tests are getting executed. [13:37] hrw: well such is life then. [13:38] xnox: sure. but now I know that fedora and ubuntu share results === doko_ is now known as doko [14:39] bdmurray: ping [14:39] shadeslayer: hi [14:40] xnox: bdmurray ScottK do you reckon I can apply for MOTU on the meeting on the 19th if I send in my application today [14:43] I think we have at least two applications to review as it is [14:44] ah hm, ok [14:44] and three days to review the application seems a bit short to me, but I'm the new guy [14:44] We ask for a week for that reason [14:44] bdmurray: MOTU applications : 1 [14:45] sure, just wanted to ask if it was possible, if not, that's fine by me :) [14:49] shadeslayer: it's 2 in total applications, not 2 per type. [14:49]