=== rcj` is now known as rcj
[03:58] <pitti> Good morning
[04:04] <Unit193> Heya.
=== G_ is now known as G
[05:00] <Unit193> sbeattie: Hello!  In apparmor you have  Depends: initramfs-tools  when it'd be better to have  Depends: initramfs-tools | linux-initramfs-tool  and will close bug 1109029 for apparmor.  (Biggest reason to do this would be the experimental dracut utility, I did this change locally with success.)
[05:00] <ubottu> bug 1109029 in udev (Ubuntu) "Depend on linux-initramfs-tools" [Wishlist,Confirmed] https://launchpad.net/bugs/1109029
=== marcusto_ is now known as marcustomlinson
[07:13] <dholbach> good morning
[07:22] <infinity> pitti: *nudge*
[07:22] <pitti> infinity: *eek*
[07:22] <infinity> pitti: Feel like debugging ddeb-retriever a bit?
[07:23] <pitti> infinity: still the linux ddebs?
[07:23] <pitti> infinity: debugging britney ATM, but I can append it to my ever-growing pre-holiday TODO :)
[07:23] <infinity> pitti: Yes.  Missing all the amd64 ddebs for 4.0.0-4.7, and half (??) the ddebs for armhf.
[07:23] <infinity> pitti: And no amount of fudging dates and trying to force the issue got any of the missing ones to show up in --verbose output at all, so I'm a bit stumped.
[07:24] <pitti> if the combined brain power of cjwatson (as the author of this) and you didn't figure it out quickly, I suppose it'll take me a good half day at least; I made a note of it, but I'd really like to fix britney first
[07:25] <infinity> pitti: Well, Colin didn't really have time to dig deeply, he just suggested "run it with verbose and have a look". :P
[07:25] <pitti> heh, ok :) here's hope that it's simpler then
[07:25] <infinity> pitti: And my python is much worse than yours, so I figured it made more sense to ask you to look than to muddle through.
[07:26] <pitti> yep, absolutely; I'll see to doing that today
[07:28] <pitti> Laney: ah, two workers died with some "Authorization Failure" error; want to practice restarting them?
[07:29] <pitti> Laney: I can't make much sense of that, it looks like a transient error
[07:32] <pitti> Laney: (worker-9 shouldn't be restarted, as that was my manual one and it tends to hit the quota, but the other one should be)
[08:08] <Laney> hey pitti
[08:08] <Laney> do they exit on that kind of error?
[08:09] <Laney> i.e. just start a new instance manually?
[08:10] <pitti> Laney: yes; I have a couple of retries in the code, but not for this kind of failed swift login yet
[08:10] <pitti> Laney: you see which worker crashed?
[08:10] <pitti> Laney: (grep -r Traceback log)
[08:10] <Laney> pitti: Yeah, I did "tail *.log" to see the exception
[08:11] <pitti> ah, good
[08:11] <pitti> Laney: so you can just start a new one like launch-workers would:
[08:11] <pitti> autopkgtest-cloud/worker/worker --config worker.conf > log/worker-2.txt 2>&1 &
[08:12] <pitti> Laney: again, sorry for the bare-bones handling, but I want to see what it's crashing on before adding lots of (possibly endless-loopy-) auto-retries
[08:13] <Laney> pitti: no worries - seems to be running now
[08:13] <pitti> Laney: filed as bug 1474729
[08:13] <ubottu> bug 1474729 in Auto Package Testing "worker failed on transient swift login exception" [Medium,Triaged] https://launchpad.net/bugs/1474729
[08:14] <pitti> Laney: thanks; back to 8 workers
[08:16] <pitti> Laney: I'll send an RT to open up SMTP, so that we can get cron (or other) notification mails
[08:32] <Laney> pitti: good idea - can you rig it up so the workers mail when they bail out?
[08:32] <pitti> Laney: yes, that was the intent
[08:33] <Laney> ack
[08:33] <pitti> Laney: tracked as bug 1474734
[08:33] <ubottu> bug 1474734 in Auto Package Testing "Robustify against transient worker failures" [Medium,Triaged] https://launchpad.net/bugs/1474734
[08:34] <pitti> Laney: if you encounter bugs, please keep filing them against auto-package-testing
[08:44] <pragomer> Did remastering of ubuntu. For beeing able to use wireshark as non-root, I use this http://pastebin.com/CguX7sik    as an init-script. The script is under /usr/share/initramfs-tools/scripts/init-bottom/ , but it has no effect. When executing the script manually in live-system, it works.. but does not automatically. any ideas?
[08:45] <cjwatson> pragomer: I did specifically say casper-bottom
[08:45] <cjwatson> Also it would need to chroot
[08:46] <cjwatson> Look at the other casper-bottom scripts for patterns to follow
[08:46] <cjwatson> But basically you'll need "chroot /root" before each of those lines
[08:46] <pragomer> hi.. I tried casper-bottom, did not work. thats why I took the latest stage (according to manpage of initramfs-tools last is init-bottom)
[08:46] <pragomer> its an init script.. so I do not need any chroot, right?
[08:47] <cjwatson> pragomer: No, wrong :)
[08:47] <cjwatson> It's not an init script
[08:47] <cjwatson> You fixed it in the wrong way by moving it out of casper-bottom to init-bottom, and the stuff in init-bottom is NOT init scripts
[08:47] <cjwatson> Move it back to casper-bottom and add the "chroot /root" bits
[08:48] <cjwatson> And what's its file name?
[08:48] <pragomer> please look. I use it like that: http://pastebin.com/pVamXHwZ
[08:48] <cjwatson> 27, OK
[08:48] <cjwatson> But please listen to me otherwise
[08:48] <pragomer> ok.. putting it back to casper-bottom
[08:49] <cjwatson> I'd also suggest making it 27wireshark rather than 27-wireshark - none of the other files there have that dash
[08:50] <cjwatson> The reason to be picky about it being in casper-bottom is that if you put it there then you can clean up your stuff by making it be in a package that ships the file there
[08:50] <cjwatson> And then that package is harmless when installed on non-live systems
[08:50] <cjwatson> Since casper-bottom is only used on live systems
[08:51] <cjwatson> Anyway, in either case, all of the stuff in initramfs-tools scripts is run in the initramfs context, with the real root filesystem on /root at that point
[08:52] <pragomer> ok.. please wait.. I am trying it
[08:53] <doko> Laney, https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-016/+build/7654349  could you fix this and upload to the silo?
[08:53] <pragomer> cjwatson: so you mean I have to put an chroot /root in front of every line of the "27wireshark" script?
[08:54] <cjwatson> pragomer: yes, because all of those commands must be executed in the real root filesystem
[08:54] <pragomer> cjwatson: oh.. learned something.. I thought that at this stage "I would be in the real system"
[08:54] <cjwatson> pragomer: also, pretty sure you mean addgroup --system not addgroup -system
[08:54] <cjwatson> pragomer: you are not, no
[08:55] <pragomer> cjwatson: but I works with only "- system".. becaus the script as it works (when executing it manually)
[08:55] <cjwatson> pragomer: don't you prefer to follow the documented correct form?
[08:55] <pragomer> sure :-)
[08:55] <cjwatson> If -system works, you are lucky, but have no right to expect to remain lucky
[08:56] <pragomer> ok.. remastering runs.. have to be 30min afk.. reporting to you later . thank you so much until here..
[08:59] <Laney> doko: yes, but not immediately - could you file a bug in debian too please?
[08:59] <doko> Laney, sure.
=== greyback__ is now known as greyback
[09:53] <pragomer> cjwatson: you said these scripts in casper-bottom are no "init-scripts".. how should I call them? boot-scripts?
[09:54] <cjwatson> pragomer: initramfs boot scripts
[09:59] <pragomer> cjwatson: jippie. it worked.. main fault was the chroot I think.. thank you so much for you help
[09:59] <cjwatson> cool
[10:01] <pragomer> just if you want.. another small problem.. when doing the remaster via chroot everything runs automatically to the end, except the question about if wireshark should create this wiresharkgroupe (its dpkg-reconfigure wireshark).. this I always have to accept manually..
[10:01] <pragomer> I mean when installing via chroot apt-get install wireshark
[10:02] <cjwatson> pragomer: DEBIAN_FRONTEND=noninteractive, probably
[10:02] <pragomer> cjwatson: cool.. never heard this.. how do I use this? with apt-get install?
[10:03] <pitti> just put it in front of apt-get install, yes
[10:03] <cjwatson> it's an environment variable that controls the operation of debconf.  you'd set it ... that
[10:05] <cjwatson> if you want a non-default answer to the question it asks, you'll need to preseed that, probably using debconf-set-selections
[10:06] <pragomer> cjwatson: very cool.. thank you so much
[10:19] <pragomer> cjwatson: sorry.. I used it like that : http://pastebin.com/BSbixgM7   And it did not work. Doing it wrong?
[10:30] <pitti> pragomer: no, not a separate command -- put it *right in front* of the apt-get, like chroot ... DEBIAN_FRONTEND=noninteractive apt-get
[10:30] <pitti> your's is a no-op
[10:30] <pitti> well, it works if you would add an "export" before it
[10:30] <pitti> (seriously, this is really basic shell knowledge..)
[10:32] <pragomer> you are right.. sorry.. I never really needed to export shell environment.. but now I remember.. thank you pitti
[10:34] <cjwatson> It wouldn't even work with export, since chroot starts a new shell
[10:34] <cjwatson> but yes, please look up shell syntax before asking
[10:42] <pitti> arges: when you said "unblock ddebs.u.c.", you only meant the new/informational cloud test runs, right? (http://autopkgtest.ubuntu.com/packages/c/crash/wily/amd64/)
[10:42] <pitti> arges: as the ones on the (still) production infra fail for a different reason (WARNING: /usr/lib/debug/boot/vmlinux-4.0.0-4-generic and /proc/version do not match!)
[10:42] <pitti> like in http://d-jenkins.ubuntu-ci:8080/job/wily-adt-crash/12/ARCH=amd64,label=adt/console
[10:43] <pitti> arges: looks like some weird parsing error, or perhaps /proc/version has changed with the new kernel or so?
=== MacSlow is now known as MacSlow|lunch
[11:17] <infinity> pitti: Eh?  The crash autopkgtest failure is because of the missing ddebs thing I was complaining about.
[11:18] <pitti> infinity: ah, ok
[11:18] <infinity> pitti: Installed kernel is -4.7, but ddebs for -4.7 are missing, so it installs -4.6
[11:18] <pitti> infinity: it sounded like arges meant the "can't access ddebs.u.c." error which we saw on the cloud tests
[11:18] <pitti> (which I'm also fixing)
[11:19] <pitti> infinity: I'm through with the worst britney stuff, will look at kernel ddebs after lunch
[11:19] <infinity> pitti: crash also has a bug in its autopkgtest where it fails to check -proposed for ddebs if the installed kernel is from -proposed, but that's not your fault. :P
[12:14] <doko> Laney, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=792494
[12:14] <ubottu> Debian bug 792494 in src:evolution-data-server "evolution-data-server fails to build with GCC 5 from experimental" [Important,Open]
[12:16] <Laney> doko: is it okay to just change the symbols file like that?
[12:16] <Laney> (thanks for the bug)
[12:17] <doko> Laney, are the symbols part of the library API?
[12:17] <pitti> cjwatson, infinity: FYI, the date argument ("today", "yesterday" or "YYYYMMDD" is obsolete now, this just applied to apache-based downloads; I'll drop it for clarity
[12:18] <Laney> doko: I would guess not, seem leaked from icu, but didn't check thoroughly
[12:18] <doko> Laney, have a look if these are weak symbols
[12:21] <Laney> doko: seems so
[12:21] <doko> then you can probably skip these
[12:22] <Laney> is a good patch to add old and new with optional?
[12:22] <doko> wouldn't hurt. but if you sync/merge, please update the ci-train ppa as well
[12:23] <Laney> ok, will do, waiting for a bugfix before updating to 3.16
=== MacSlow|lunch is now known as MacSlow
=== _salem is now known as salem_
[12:49] <pragomer> Hi... whats wrong about: for i in $(find . -type f); do ls -l "$i"; done     Has problems with "space character"
=== Mirv_ is now known as Mirv
[12:56] <TJ-> pragomer: "find . -type f -ls"
[12:57] <TJ-> pragomer: What you currently do is assign the space-separated output of the find command to i, so any files with spaces in their paths will get split up in different iterations of i
[12:59] <cjwatson> And if you're doing something more complicated than ls, then either use -print0 | xargs -0 or use one of the -exec variants (preferably -exec command {} + or -execdir command {} +)
[13:02] <mdeslaur> slangasek: patch for sbsigntool in bug 1474541
[13:02] <ubottu> bug 1474541 in sbsigntool (Ubuntu Wily) "sbsigntool broken by update to openssl 1.0.2c" [High,New] https://launchpad.net/bugs/1474541
[13:13] <pragomer> TJ-: Cant I get the complete folder path - included space characters - into $i ??
[13:15] <pragomer> print0 | xargs -0 is great I know... but I need the file-path in a variable to specifiy an output path
[13:16] <doko> TJ-, do you still want to backport openjdk-8?
[13:16] <pitti> cjwatson, infinity: bazinga! http://bazaar.launchpad.net/~ubuntu-archive/ddeb-retriever/trunk/revision/159
[13:17] <pitti> the old test saw that -4.7 was already there, but failed to realize that it only had armhf/i386/ppc binaries; it didn't look at the ddeb's architecture
[13:18] <pitti> so anything which would build several hours before or after other architectures would be affected
[13:18] <pitti> I'll re-run the thing from Mid-April on (thanks Launchpad for keepign all ddebs!)
[13:18] <pitti> I also committed http://bazaar.launchpad.net/~ubuntu-archive/ddeb-retriever/trunk/revision/160 to make this a bit less painful exercise
[13:19] <cjwatson> pragomer: find -print0 gives you the full path from the start directory, just as your earlier broken command was trying to do
[13:19] <infinity> pitti: <3!
[13:19] <pitti> http://ddebs.ubuntu.com/pool/main/l/linux/ has the ddebs now, just not indexed yet (as I was running with --download-only)
[13:20] <infinity> pitti: I'm going to quit ~we-love-pitti, just so I can rejoin.
[13:20] <pitti> lol
[13:22] <cjwatson> pragomer: there are ways to get it into a variable for further processing, but doing it safely in the presence of unusual characters in file names requires very careful use of shell and if you're having difficulty with setting environment variables correctly then I think that would be a bit much!  You might be better off with a more powerful language at this point.
[13:23] <cjwatson> pitti: ah, excellent, thanks for that!
[13:23] <cjwatson> my bad
[13:24] <cjwatson> pitti: 160> you'll lose out on Pending, but maybe that's OK as you'll probably get them later anyway
[13:24] <pragomer> cjwatson: find . -type f | while read i; do vcs "$i" -n 4 -o "$i.png"; done
[13:24] <pragomer> find . -type f | while read i; do vcs "$i" -n 4 -o "$i.png"; done
[13:24] <cjwatson> and you can't match those directly either
[13:24] <pitti> cjwatson: yeah, that's what I thought; I just saw an awful lot of Deleted (from -proposed) and superseded scroll by
[13:25] <pragomer> vcs is a script to get images out of videos... and it expects -o output path
[13:25] <pitti> cjwatson: so I don't think it's a net delay, as we match them against Packages.gz anyway
[13:25] <pragomer> in this case it only handles the first file found
[13:25] <pitti> cjwatson: if someone wants to use that without apt, they can just as well grab the ddeb directly from LP
[13:28] <infinity> pragomer: find | while read; seems to work for me?
[13:29] <cjwatson> pragomer: find . -type f -print0 | xargs -0r -I{} vcs {} -n 4 -o {}.png
[13:29] <infinity> That's more foolproof, sure.
[13:29] <infinity> But while read is working fine too.
[13:29] <infinity> $ find . -type f | while read i; do echo "$i"; done
[13:29] <infinity> ./bar baz/file2
[13:29] <infinity> ./foo/file1
[13:29] <cjwatson> while read works as long as your filenames do not contain newlines, indeed.
[13:29]  * infinity nods.
[13:30] <cjwatson> Which is pretty rare and breaks lots of other stuff, but you never know.  I prefer to write code that won't break even in that case, if I can.
[13:30] <cjwatson> pitti: Right
[13:30] <infinity> Newlines in filenames really should have been banned by POSIX.  Such pure evil.
[13:31] <cjwatson> Also, | while read can be useful, but it also has pretty surprising behaviour with variables set inside the loop
[13:33] <cjwatson> Oh, while I'm here, this works fine too:   find -type f -execdir vcs '{}' -n 4 -o '{}.png' \;
[13:35] <pragomer> cjwatson: thank you so much: worked fine with xargs.. didn know how to get the input in the variable {}
[13:36] <infinity> cjwatson: execdir.  That's a new one to me.  I assume {} is basedir()ed, despite the manpage leaving that detail out? :P
[13:36] <infinity> Err, basename()d.
[13:36] <pragomer> thank you @LL !!
[13:37] <cjwatson> infinity: Yes.  The info docs clarify, although even then only if you read the section on -exec as well.
[13:38] <infinity> cjwatson: Well, that's super handy.  Now to figure out how to etch that in a bit of brain mush that survives more than a few minutes, so I never use -exec again.
[13:40] <caribou> Question regarding rsyslog merge : in the pre-merge version (7.4.4) there is no test being run on package build
[13:40] <caribou> in the Debian version (8.9.0) tests are introduced
[13:41] <caribou> but a few tests, according to the upstream dev, may be racy and cause false negative.
[13:41] <caribou> There is a few I hit regularly when I build but most of them run fine.
[13:41] <infinity> caribou: If it turns out that those racy tests are problematic, disable just the broken ones?
[13:41] <caribou> infinity: that's the question I was about to ask
[13:41] <infinity> caribou: Really, if a test is known-racy, it's not much of a test at all, and upstream should be skipping them until they're fixed. :/
[13:42] <infinity> caribou: But we can skip them if they won't.
[13:42] <caribou> infinity: well, according to rainer, they only work in very specific controlled environment
[13:42] <caribou> infinity: ok, I'll disable them. Thanks!
[13:42] <infinity> caribou: Anyhow, baby and bathwater, la la la, don't disable the whole testuite just cause a few tests are crap, figure out how to disable the crap ones.
[13:43] <caribou> indeed, especially since there are quite a bunch of them that run fine
[13:43] <infinity> caribou: If upstream knows what these controlled environments are, they should be checking for them, and skipping the tests if they're not in said env.  Many packages conditionally run some tests that way.
[13:43] <caribou> true
[13:44] <infinity> ie: python skipping a whackload of tests of there's no network, coreutils skipping some tests if it doesn't find certain types of files (my favoutite one being "found no files in /tmp that aren't owned by you -- skipping")
[13:44] <caribou> btw, https://merges.ubuntu.com/main.html seems to be borked
=== __bjf is now known as bjf
[13:48] <cjwatson> [Wed Jul 15 13:48:21 2015] [error] [client 10.172.192.14] OSError: [Errno 13] Permission denied: '/var/www/.launchpadlib'
[13:48] <cjwatson> sigh
[13:48]  * cjwatson goes to fix
[13:52] <cjwatson> caribou: fixed, thanks
[13:52] <caribou> cjwatson: thank to you !
[14:00] <TJ-> doko: openjdk-8 has been working fine for me so far but I'm not familiar with any test-suite that should be run through to detect regressions against existing packages
=== bjf is now known as _jfb
=== _jfb is now known as _fjb
[15:44] <slangasek> mdeslaur: thanks!
[15:58] <infinity> pitti: That ddeb-retriever is taking an impressive amount of time. :)
[16:05] <doko> Mirv, looks like slangasek uploaded some more qt packages to the silo. do you consider these part of qt5?
[16:18] <doko> On 7 July, Matthias mentioned that he's also planning the GCC 5 transition,
[16:18] <doko> and we don't want to do both transitions at the same time, so Python 3.5 is up
[16:18] <doko> first.
[16:18] <doko> barry, slangasek: I didn't say that python3.5 is first ... this is cowboying ...
[16:19] <doko> we'll do the GCC change around July 30, so maybe add it as a supported version before, but don't change the default
[16:29] <slangasek> doko: the mail says specifically that he's uploading today to add python3.5 as supported, not default
[16:34] <barry> doko, slangasek right.  only supported as of today
[17:01] <pitti> infinity: yeah, mopping up all ddebs since April :) I suppose that'll take a full day or so
[17:01] <pitti> infinity: I thought we should bite the bullet, as this probably affects a lot more debs
[17:01]  * pitti -> badminton, cu tomorrow
[17:19] <slangasek> tyhicks: hey, the bug log on bug #1430557 says you were working on this issue... are you still working on it?  the current behavior is truly hateful :)
[17:19] <ubottu> bug 1430557 in schroot (Ubuntu) "sbuild / schroot unmounted encrypted home directory" [High,Triaged] https://launchpad.net/bugs/1430557
[17:31] <tyhicks> slangasek: I was working on a different bug, which may be a dupe of that bug
[17:31] <tyhicks> let me get "my" bug
[17:32] <tyhicks> slangasek: https://launchpad.net/bugs/1427264
[17:32] <ubottu> Launchpad bug 1427264 in schroot (Ubuntu) "using ecryptfs, creating frameworks fail to bind mount issues" [High,In progress]
[17:33] <tyhicks> slangasek: I submitted a patch to upstream but they haven't commented
[17:33] <tyhicks> slangasek: I'll poke the bug again
[17:33] <slangasek> ok
[18:05] <doko> tjaalton, could you have a look at https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-016/+sourcepub/5214294/+listing-archive-extra ?
[18:34] <doko> tjaalton, nm, found it
=== davmor2_ is now known as davmor2
[20:34] <ari-tczew> bdmurray: thank you for your efforts for making Merge-o-Matic better! \o/
[20:38] <ari-tczew> bdmurray: could you in a bit free time take a look on bug 681375 ? I guess it'd easy to fix for you :-)
[20:38] <ubottu> bug 681375 in Merge-o-Matic "Adding unnecessary blank line at the end of debian/changelog" [Undecided,New] https://launchpad.net/bugs/681375
[21:14] <pitti> slangasek: FYI, I set up a second autopkgtest worker on the other scalingstack region, so I now have 20 instances max
[21:15] <pitti> slangasek: with that the performance looks like roughly on par with the current infrastructure
[21:15] <pitti> slangasek: counting the number of "in progress" on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html (also on trusty/vivid) it even seems to be a tad faster
[21:16] <pitti> slangasek: so, yay :)
[21:21] <slangasek> pitti: nice!  do we have the capacity on scalingstack today to cut over?
[21:21] <pitti> slangasek: given the above, I'd say yes
[21:22] <slangasek> pitti: unless the launchpad team is going to come yell at you for using 20 instances? :)
[21:22] <pitti> slangasek: it still needs some handholding and analyzing the tmpfails, but yesterday and today I was doing mostly just that
[21:22] <pitti> slangasek: yeah, I still hope I'm not stepping on wgrant's feet with that, I asked on the RTs several times
[21:23] <pitti> slangasek: anyway, IS said they are going to add a new beefy box to each of the regions RSN, so we can get some more power
[21:23] <pitti> slangasek: e. g. today with doko's python3.5 enablement I'm using the full steam; but on most days it's not running on max capacity
[21:24] <pitti> slangasek: so, I think I'll continue to sort out problems this week, Laney volunteered to keep an eye on it next week while I'm on holiday
[21:24] <pitti> slangasek: and after that I think we should be good to switch over
[21:24] <pitti> slangasek: still need to teach britney to take these results into account instead of the old adt-britney ones of course, but that should be easy
[21:24] <slangasek> pitti: awesome!
[21:25] <pitti> slangasek: I sent an RT for opening access to armhf and ppc64el boxes FYI, let's see how that goes
[21:25] <pitti> we can use that as an example of how we're going to AMQPify and de-jenkins-ify e. g. boottest, and add real iron testing to this
[21:25] <pitti> I'd really like to get rid of this 'orrible duplication of boottest.py in britney
[21:26] <pitti> PSA: taking down autopkgtest.ubuntu.com and re-deploying from scratch
[21:26] <pitti> because I can :)
[21:26] <pitti> (I simplified/moved some bits, want to test the charm)
[21:27] <slangasek> pitti: ok, you've decided it's worth wiring this up to the existing armhf and ppc64el boxes, rather than waiting for scalingstack on those?
[21:28] <pitti> slangasek: well, it's not much work really, and having a worker which talks to LXC or e. g. adb which isn't in the cloud is useful IMHO
[21:28] <slangasek> ok
[21:28] <pitti> if it's not too much trouble for IS to open up the firewall holes, that is
[21:29] <pitti> I explained the general intent, and hope we can discuss this now
[21:29] <pitti> so that when we need it for e. g. boot test, or real iron testing of snappy or whatnot, we've been through that procedure once
[21:32] <pitti> hah, and http://autopkgtest.ubuntu.com/ is back (syncing results in a few mins)
[21:32]  * pitti fell in love with juju
[21:39] <cjwatson> slangasek: I don't think our quotas are going to magically deflate or anything just because pitti's using his quota - our number of virt builders doesn't decrease.  There might be overcommit, I don't know
[21:41] <cjwatson> slangasek: but I have a ticket in for turning brownie and comet into scalingstack compute nodes, and if IS are planning to add another couple, that would be great
[21:41] <pitti> cjwatson: I don't know whether there's overcommit, but given that both buildd and test VM workloads tend to come in peaks, it would make sense to have it
[21:42] <pitti> I added some logic to retry after 5 mins if nova fails due to hitting the limit
[21:42] <cjwatson> pitti: I assume that the new beefy boxes are independent of the existing buildds we're reusing, since as far as I know all the ex-buildds are going into lgw01 (otherwise they'd have to be physically moved)
[21:42] <cjwatson> pitti: yeah.  shouldn't be too much of a problem
[21:42] <pitti> cjwatson: ok; please let me know if it does impact you, then I'll dial it back a bit
[21:42] <cjwatson> pitti: TBH, our metrics aren't great, we might not notice for quite a while *cough*
[21:42] <pitti> ATM I'm using 16 instances (8 on each region) max in parallel (I didn't want to max it out yet)
[21:43] <cjwatson> I think we'd basically just start caring if the virt queue started growing
[21:43] <pitti> cjwatson: well, do you get some error if nova boot fails with a quota issue?
[21:43] <cjwatson> pitti: it would probably cause builders to fail to reset.  that does happen occasionally
[21:44] <cjwatson> I rather suspect that it would be a ridiculously opaque failure mode of some kind
[21:45] <cjwatson> aren't the quotas in terms of number of instances though?
[21:46] <cjwatson> we don't scale our number of instances dynamically, any adjustments there would be done by IS
[21:47] <pitti> cjwatson: there's quotas for #instances, #cpus, #mem, and #disk, all independelty
[21:47] <pitti> cjwatson: e. g. I hit a quota with my 8th instance when I allocate 3 m1.large
[21:47] <pitti> (some tests need an m1.large, most use m1.small)
[21:48] <pitti> cjwatson: "nova absolute-limits" FYI
[21:51] <cjwatson> pitti: our use is static though, we just reboot lots (effectively)
[21:51] <pitti> cjwatson: ah, that would help; so I can't "steal" capacity from buildds then
[21:52] <pitti> I keep creating and destroying images
[21:52] <pitti> err, instances
[21:54]  * pitti waves good night
=== _fjb is now known as bjf
[22:31] <bdmurray> barry: does python-apt need to be rebuilt with python3.5?
=== salem_ is now known as _salem
=== mbiebl_ is now known as mbiebl