[01:11] <cjwatson> teward: The canonical way to determine whether systemd is pid 1 is os.path.isdir("/run/systemd/system") or per-language equivalent
[01:12] <cjwatson> teward: For Upstart, you want the init_is_upstart function from /lib/lsb/init-functions (or, again, per-language equivalent)
[01:14] <teward> cjwatson: i really only need the systemd test/check - the apport hooks i'm writing for nginx (because of the appalling bug helpfulness quality since 15.04 and systemd) i'm trying to make sure is catchable.  plans were to only land it in 15.04 and up, and since I know someone has a wildly custom setup where they got rid of systemd... *shrugs*
[01:14] <teward> cjwatson: thanks thoug
[01:14] <cjwatson> Sure
[01:14] <cjwatson> At least the systemd check is pretty trivial
[01:14] <teward> i'm more concerned with why when i try and get the apport hooks to request whether hte user wants to include certain files or not it then asks TWICE before doing anything
[01:15] <teward> three questions coded, six questions asked (the three questions, 1 2 3, then again, 1 2 3)
[01:15]  * teward shrugs
[01:15] <cjwatson> You want pitti or bdmurray for that kind of thing
[01:15] <teward> indeed
[01:15] <teward> i'm going to poke pitti tomorrow
[01:16] <teward> bare minimum is to get the systemd check
[01:16] <teward> (tomorrow my time, as in the morning about 10 - 12 hours from now)
[01:20] <teward> cjwatson: given only a day, though, thanks to pitti's guidance this morning my time, i've already got the gist of what i need to have done down, at the very least to fix  the reason that sarnold and I want to smack the nginx package around in 15.o4
[01:20] <teward> 15.04*
[01:20] <teward> so a big thanks to pitti is definitely due :)
[01:26] <psusi> is 15.10 going to switch to systemd either in the initramfs or user session?
[02:49] <teward> cjwatson: follow-up: thanks for the guidance.  Finding systemd was easy.  I had to essentially write an init_is_upstart function in python, using init-functions's init_is_upstart as a partial guide for what to do.  And I've replicated the command set to check if it's upstart or sysvinit (the old one)
[02:50] <teward> s/for what to do/for what to do to check if upstart/
[02:54] <hich-em_> sabdfl,
[04:03] <pitti> Good morning
[04:08] <pitti> teward: asks twice> at this point I'd need to see your hook and what you do exactly to test/call it; normaly it's run once
[04:09] <pitti> teward: os.path.isdir('/run/systemd/system/') -> running systemd
[04:09] <pitti> teward: detecting upstart is harder, but on Ubuntu you can assume that it's upstart if it's not systemd
[04:09] <pitti> nah, don't readlink  /proc/1/exe, that's wrong
[04:09] <pitti> tarpman: ^ FYI
[04:10] <sarnold> hey pitti :) teward said he'd like something that can work with debian sysvinit too
[04:10] <infinity> I think he cargo-culted from init-functions and got what he wanted.
[04:10] <infinity> At least, backscroll with cjwatson seems to imply that.
[04:10] <pitti> "initctl --system list" should work under upstart, but I'm not sure whether it needs root
[04:11] <pitti> it fails under systemd with "Name "com.ubuntu.Upstart" does not exist" as expected
[04:11] <pitti> teward: global hook> you mean general-hooks/, not a package specific one? you can do that too, yes
[04:11] <infinity> pitti: The is_upstart function from init-functions is the canonical way.
[04:12] <pitti> teward: logs> rsyslog's logs have everything too, so in general you can get it there; but filtering stuff that you are interested in from the journal is magnitudes easier than fishing it out of syslog
[04:13] <pitti> teward: no, hooks must never collect private/sensitive stuff,  please obfuscate that with post-processing
[04:15] <pitti> teward: ok, I think I've caught up with your questions, but at this point just show me the hook for review?
[04:44] <opiwahn> I still need help creating an initram script while a remastering process.  This is the way I put my "script" to initram: http://pastebin.com/RmNivmvX   The script simply should do "blockdev --setro /dev/sd*"   on the live-system I can find the script under /usr/share/initramfs/scripts/local-top/ but it did not have any effect. running it manually blocks the harddisk. someone could help me?
[04:45] <sarnold> why two sudo calls per line?
[04:46] <sarnold> opiwahn: I think I'd remove every 'sudo' from this script, and run this script via sudo manually
[04:50] <opiwahn> sarnold: hi.. you mean the "sudo" before the blockdev, right? not from my remastering-part, right?
[04:52] <sarnold> opiwahn: well... lets take this line here:
[04:52] <sarnold> sudo chroot "${WORK}/new" sudo chmod +x usr/share/initramfs-tools/scripts/local-top/initramblockdev
[04:53] <opiwahn> the 2nd sudo I need to chmod or not?
[04:53] <sarnold> opiwahn: that'll execute the system's sudo, then the system's chroot, then the usr/bin/sudo from within the chroot, then the bin/chmod executable from inside the chroot
[04:53] <sarnold> opiwahn: the entire thing could be replaced with sudo chmod +x ${WORK}/new/usr/share/initramfs-tools/scripts/local-top/initramblockdev
[04:53] <sarnold> opiwahn: .. that'd remove the dependency on a sudo and chmod from inside the chroot...
[04:53] <opiwahn> ok I understand
[04:55] <opiwahn> do you think thats the problem? because .. the script IS on the live medium.. executable.. and works when executing it manually after boot...   while the remaster process stout say me "blockdev: /dev/sd*" device not found.. could be the problem but I dont know why
[04:56] <pitti> opiwahn: you already asked that yesterday -- apparently you are calling it too early and /dev/sd* does not exist yet
[04:58] <opiwahn> ok.. I tried to put it on every subdirectory.. according to "man initramfs-tools"...
[04:58] <opiwahn> I also tried "Init-bottom" what is, according to manpage, the last scripts that are executed.. even here it was the same error message
[04:59] <pitti> /usr/share/initramfs-tools/scripts/local waits for the root file system to appear
[04:59] <pitti> opiwahn: perhaps you simply don't have any /dev/sd* then? maybe it's /dev/vd* from QEMU or whatnt
[04:59] <pitti> whatnot
[05:00] <opiwahn> no, its really sda and sdb from virtualbox
[05:01] <opiwahn> am I right that putting it in init-bottom.. just for testing.. is the latest possibility to put the script in.. and so that /dev/sd* should already exist?
[05:02] <opiwahn> or could it be possible that - at this stage - the "*" could not work??
[05:02] <pitti> it's still not guaranteed to work, but I'd say in most cases it should
[05:02] <pitti> the only way to reliably wait for a device to appear is with an udev rule
[05:03] <pitti> if it's a shell script, the * works
[05:13] <opiwahn> I also put a udev role on the live system.. this works.. for the "late stage" and plugging new devices.. but there is this "early stage"... e.g. told me ubuntu "unsafe ntfs filesystem.. fixing" . This is only one example why I want to prevent the live system from writing to the disks via a init script
[05:14] <opiwahn> ok.. I am sorry :-)  but my question again.. is "init-bottom" the "latest stage" where I can sure /dev/sd* should be ready??
[05:27] <pitti> opiwahn: as I said, you can *never* be sure in the initramfs that all devices got detected
[05:27] <pitti> opiwahn: you can certainly try and applying it  for those that are already there, with the /dev/sd* globbing, but it might be that new devices are detected later on
[05:30] <opiwahn> pitti: just detected.. that I use #!/bin/bash in my script... should this be "sh" instead of "bash" *shame*
[05:33] <pitti> opiwahn: /bin/sh is faster, otherwise it makes not much difference
[05:34] <opiwahn> pitti: oh.. hoped this was the problem. thanks pitti..
[05:34] <opiwahn> pitti: pitti.. how would YOU solve this? generally like I am trying it?
[05:34] <pitti> opiwahn: it seems to me you just want something like
[05:35] <pitti> KERNEL="sd*", RUN+="/sbin/blockdev --setro $devnode"
[05:35] <pitti> put that into /lib/udev/rules.d/50-block-ro.rules and copy it into the initramfs
[05:36] <pitti> opiwahn: oh, another thing -- does /sbin/blockdev really exist in your initramfs? I wonder if your error message from above was really correct
[05:37] <pitti> if it says "device not found" that suggests that blockdev exists, but if it says "file not found" it might very well be that blockdev itself is missing
[05:37] <pitti> $ lsinitramfs /initrd.img |grep blockdev
[05:37] <pitti> sbin/blockdev
[05:37] <pitti> seems alright
[05:39] <opiwahn> pitti: are you german?
[05:39] <pitti> yes, does my writing have an accent too? :-)
[05:39] <pitti> zat is ze problem!
[05:40] <opiwahn> pitti: sure.. is it "allowed" to write in not-english in privat messages like this?
[05:40] <pitti> sure, just talk English on the public channels; what happens in priv messages stays in priv messages
[05:41] <opiwahn> pitti: ok.. na denn. mein remastering script läuft gerade durch, ist aber gleich fertig, dann geb ich dir nochmal den genauen wortlaut der fehlermeldung.. wobei mich schon wundert, dass das beim remastern im stdout erscheint.. da wird ja nix ausgeführt hinsichtlich des block-dev-scriptes..
[05:42] <pitti> opiwahn: err, this is *not* a private message, it's the channel
[05:42] <opiwahn> pitti: ups.. I am really new to irc chats.. sorry..
[05:42] <pitti> opiwahn: yeah, during remastering there shouldn't be a run of blockdev
[05:43] <opiwahn> pitti: thats my error message: http://pastebin.com/TCpUSZRk
[05:44] <opiwahn> pitti: dont understand why this appears in the remastering-stdout
[05:44] <pitti> opiwahn: what's the script right now?
[05:44] <opiwahn> pitti: you mean the init-script?
[05:45] <pitti> opiwahn: your remastering script
[05:45]  * pitti restarted IRC some minutes ago, I don't have earlier scrollback
[05:46] <opiwahn> pitti: oh... thats big.. :-)    or do you just want the part where I copy the script and the initram-part?
[05:46] <pitti> yes
[05:46] <pitti> where it shows that error message
[05:46] <pitti> I suspect you have some missing quoting there
[05:46] <opiwahn> pitti: http://pastebin.com/PT6Ymb8y
[05:46] <pitti> so that it expands /dev/sd* while you run the script, not while you boot the image
[05:47] <pitti> sudo chroot "${WORK}/new" sudo update-initramfs -u -k all
[05:47] <opiwahn> pitti: this is the initram-part.. but dont know if this causes it
[05:47] <pitti> ah, this probably runs it
[05:47] <pitti> and please drop all those sudos
[05:48] <pitti> not sure why update-initramfs would run scripts/
[05:48] <opiwahn> pitti: really ALL sudos? need them to chmod and update-initramfs or not?
[05:48] <pitti> opiwahn: you ought to run the remastering script as root; it's never good to call sudo in scripts
[05:48] <pitti> but nevermind, different issue
[05:49] <pitti> opiwahn: did you run your script with -x to confirm where that error message comes from?
[05:49] <pitti> I'm not sure it's from http://pastebin.com/PT6Ymb8y
[05:49] <pitti> anyway, sorry, I really need to get to do something else, bbl
[05:49] <opiwahn> pitti: ok I drop all sudos at the beginning of these lines...
[05:50] <opiwahn> pitti: no problem.. what do u mean by running with -x ?
[05:50] <pitti> nevermind the sudos now, those are not *that* bug; they are just utterly wrong
[05:50] <pitti> opiwahn: bash -x yourremasteringscript
[05:52] <opiwahn> pitti: ok..trying bash-x   thank you pitti.. sorry for taking you so much time.. but I am a little closer to the solution
[05:55] <opiwahn> pitti: really one last beginners question: how can I complete write the output of bash -x myscript also to text-file?
[05:55] <pitti> command 2>&1 | tee output.txt
[05:57] <opiwahn> pitti: thank you. really. thank you very much. and have a really good day
[05:57] <pitti> good luck!
[05:57] <opiwahn> pitti: thanks
[06:22] <opiwahn> if I start a bashscript as root/su is another script that is invoked by the first also automatically run as root, or not?
[06:23] <sarnold> they all run as root
[06:23] <sarnold> which is why you can remove every 'sudo' from the script and run it as root :)
[06:25] <opiwahn> thats why my question :-)  thank you guys !
[06:47] <dholbach> good morning
[07:30] <pitti> Laney: can you please remove your upstart test override? bug 1429756 is fixed in wily's kernel now
[07:30] <ubottu> bug 1429756 in linux (Ubuntu Vivid) "FTBFS: upstart test_job_process fails in majority of cases / Kernel returning unexpected EIO at end of file" [High,Confirmed] https://launchpad.net/bugs/1429756
[07:31] <pitti> http://d-jenkins.ubuntu-ci:8080/view/Wily/view/AutoPkgTest/job/wily-adt-upstart/ succeeded, I restarted it to see that it survives two runs in a row
[08:04] <Laney> pitti: yay!
[08:04] <pitti> Laney: yep, survived four tests in a row
=== dbarth_ is now known as dbarth
[08:47] <doko> Laney, could you merge pcre3?
=== anthonyf is now known as Guest97002
[08:48] <Laney> doko: hmmmmm, I guess so
[08:48] <pitti> wow, we have a delta in prce?
[08:49] <Laney> stupid delta
[08:49] <Laney> will fwd it if it's not already
[08:49] <pitti> hm, unmangled C++ symbols?
[08:49] <seb128> wgrant, cjwatson, do you know why templates on e.g https://translations.launchpad.net/ubuntu/wily/+source/dialer-app/+imports are "approved" but not "imported"?
[08:49] <pitti> I mean "mangled", i. e. "not demangled"
[08:50] <doko> Laney, and then upload a follow-up version to the ci-train 16 PPA?
[08:50] <pitti> I thought they'd cause more trouble than they would help
[08:50] <wgrant> seb128: Translation imports have not yet been activated for wily.
[08:51] <Laney> pitti: are you doing this merge? :)
[08:51] <seb128> wgrant, thanks
[08:51] <seb128> wgrant, when is that planned?
[08:51] <pitti> Laney: no, I was just curious what we could possibly have changed in pcr3
[08:51] <wgrant> seb128: Someone Ubuntuy (pitti?) would enable them at https://translations.launchpad.net/ubuntu/wily/+translations-admin once the state of the series was verified.
[08:51] <seb128> wgrant, it sort of created a fail for ota5 touch langpack updates
[08:51] <Laney> they have only exported the right symbols
[08:51] <Laney> sanity
[08:52] <wgrant> seb128: ... OTA5 is based on wily?
[08:52] <pitti> wgrant: this currently has "hide" and "defer" enabled, is that intended?
[08:52] <seb128> wgrant, no, but ppas don't have translation template, so they copied the wily .po over
[08:52] <seb128> wgrant, assuming that the strings would be the same in their overlay and wily since they dual land
[08:52] <pitti> wgrant: (sorry, never saw that page)
[08:52] <wgrant> pitti: Oh, we don't normally enable those, so I assumed you did.
[08:53] <wgrant> There's nothing blocking it.
[08:53] <pitti> wgrant: no, certainly not; maybe that's just the default state until we actually get wily translations?
[08:53] <Laney> doko: no-change rebuild?
[08:53] <pitti> wgrant: so want me to uncheck these two?
[08:54] <wgrant> pitti: Oh, I mean having those two checked is the default, and I assume you normally unchecked them.
[08:54] <wgrant> (yay for having negative checkboxes...)
[08:54] <wgrant> Yep, I see no reason not to.
[08:54] <doko> Laney, yes, but with higher version number
[08:54] <pitti> wgrant: I suppose so far it was done by you or cjwatson or possibly dpm?
[08:54] <pitti> wgrant: done
[08:54] <wgrant> pitti: dpm makes sense, maybe.
[08:55] <pitti> https://translations.launchpad.net/ubuntu/wily/+imports is full of stars now
[08:57] <Laney> doko: are you going to dump all of the no-change rebuilds into the silo as they can be done?
[08:57] <Laney> would be good to have a transition tracker which looks at that too I guess ...
[08:58] <sil2100> pitti: does this mean we can have an another export with updated translations soonish?
[08:58] <doko> Laney, transition tracker for a ppa doesn't yet exist. but infinity is supposed to work on this ...
[08:58] <pitti> seb128: ah, the one on https://translations.launchpad.net/ubuntu/wily/+language-packs is no good because of the above?
[08:58] <pitti> I mean sil2100 ^
[08:58] <doko> for now, I just upload things what need to fix bugs
[08:59] <seb128> pitti, well, template imports didn't work
[08:59] <pitti> right
[08:59] <seb128> so the templates are outdated
[08:59] <seb128> so the langpack content doesn't match the current code
[08:59] <seb128> so strings are missing
[08:59] <pitti> seb128, sil2100, wgrant: so I guess we have to wait until https://translations.launchpad.net/ubuntu/wily/+imports clears up, and then do another full export?
[08:59] <seb128> yes
[08:59] <seb128> but that's going to take days righT?
[09:00] <pitti>  14190 templates to import AFAICS
[09:00] <seb128> which might be too much for the ota update
[09:00] <wgrant> Yes, the translation importer is slow beyond belief.
[09:00] <wgrant> We can, er, expedite certain templates, though, with a bit of hackery.
[09:00] <wgrant> That is, unapprove all of the imports that are boring.
[09:01] <sil2100> wgrant: would that require a lot of work?
[09:02] <sil2100> Since I suppose if we could get properly updated touch translations imported and then do an export, that would be sweet
[09:02] <pitti> wgrant: how long would that take roughly? poking 14000 strings into a DB doesn't sound like a lot?
[09:04] <wgrant> sil2100, pitti: I would probably just use SQL to set all Approved import queue entries in wily to Needs Information. Then you can approve interesting ones as necessary.
[09:04] <wgrant> And once the deadline has passed we can set them all back to Approved.
[09:05] <cjwatson> seb128: We'll have proper translations for the overlay PPA soon, BTW.
[09:05] <cjwatson> (Not OTA5 soon, but soon)
[09:05] <seb128> cjwatson, ah, that's good news ;-)
[09:07] <sil2100> wgrant: that could work... although my experience with handling LP translations is a bit weak
[09:08] <sil2100> wgrant: so I would need some help with that probably
[09:08] <sil2100> pitti: could you help me out here?
[09:09] <pitti> sil2100: err, we are supposed to manually set several hundred templates to "approved"?
[09:09] <pitti> can't we do this with SQL again?
[09:09] <seb128> I guess it's just a matter of going to https://translations.launchpad.net/ubuntu/wily/+source/<template>/+imports and change the status to approved, for every package that needs an update template
[09:09] <pitti> set all of them to needsinfo, then set the ones from touch packages back to approved?
[09:10] <seb128> but yeah, need to have a list of those that need an update
[09:10] <pitti> it's a hilarious amount of work to change the status of 50 projects times 5 arches on the web UI
[09:10] <sil2100> I don't know how that works - wouldn't it be like simply approving the top most version of the .po file?
[09:11] <sil2100> Indeed, 65 .po files are in our langpacks...
[09:11] <pitti> sil2100: sounds okay; it *should* be enough to approve it on one architecture only (but I'm not sure)
[09:12] <seb128> those are not by arch afaik
[09:13] <pitti> hm, I thought they were
[09:13] <pitti> but even if not, 65 projects times 50~is languages is still "OMGlots" for a human
[09:13] <seb128> https://translations.launchpad.net/ubuntu/wily/+source/nautilus/+imports
[09:13] <sil2100> http://paste.ubuntu.com/11847166/
[09:13] <seb128> we are speaking about templates no?
[09:13] <Laney> is it not scriptable via the API?
[09:13] <pitti> NB you need the po files too, not just the pots
[09:13] <seb128> not languages
[09:14] <pitti> ah, po files get auto-approved then?
[09:14] <sil2100> We have .po's for these packages
[09:14] <dpm> Laney, there is no API
[09:14] <dpm> for translations
[09:14] <pitti> ah, so it's not the 14000 files from https://translations.launchpad.net/ubuntu/wily/+imports?field.filter_status=APPROVED
[09:14] <doko> mvo, please could you merge snappy, and then do a follow-up upload to the ci-train 16 PPA ?
[09:15] <dpm> actually, there is a bit for templates
[09:15] <seb128> well, outdated ones, since they are based on the outdate templates
[09:15] <pitti> but just the 425 from https://translations.launchpad.net/ubuntu/wily/+imports?field.filter_status=APPROVED&field.filter_extension=pot
[09:15]  * dpm reads scrollback
[09:15] <pitti> sil2100, seb128: I'm confused -- if you already have the .po's, what's blocking you?
[09:15] <pitti> the *.po are all we care about in langpacks/exports
[09:16] <seb128> pitti, the po they have are outdated as just written
[09:16] <pitti> the *.pot is "just" for LP itself to know which strings to put into *.po files and to translate the strings
[09:16] <pitti> seb128: so we *do* need the po files, not just the pots
[09:16] <seb128> they are based on wrong templates
[09:16] <sil2100> pitti: I don't know too much about that, but those .po files haven't been updated with new translations, which didn't get imported
[09:16] <pitti> right
[09:16] <sil2100> pitti: but we'll get the .po files from the export
[09:16] <seb128> well I expect once the template are updated things are good
[09:16] <pitti> so I misinterpreted
[09:16] <pitti> sil2100 | We have .po's for these packages
[09:16] <seb128> the translations are shared with trunk
[09:16] <pitti> seb128 | we are speaking about templates no?
[09:17] <sil2100> pitti: I said for the list above
[09:17] <pitti> we *do* need LP to import all *.pot *and* *.po files from wily then
[09:17] <sil2100> pitti: I pasted http://paste.ubuntu.com/11847166/ and said that these are the apps we have in the langpack
[09:17] <pitti> ok
[09:17] <pitti> sorry for the confusion
[09:17] <seb128> pitti, I'm unsure the .po *import* are needed
[09:17] <sil2100> I think I caused some confusion here ;)
[09:17] <seb128> the strings come from trunk
[09:17] <pitti> seb128: how could they not be needed?
[09:17] <seb128> ^
[09:17] <pitti> if the current po files are outdated, we need to import the current ones
[09:17] <seb128> because translation sharing with trunk is active
[09:18] <pitti> ah
[09:18] <mvo> doko: you mean upload the latest snappy into ppa-16? sure, I can do that
[09:18] <mvo> doko: I guess a PPA copy with rebuild is also ok?
[09:18] <mvo> doko: from our daily build snappy ppa?
[09:18] <pitti> 3 templates out of 425 imported in teh last 3 minutes
[09:18] <doko> mvo, but first merge it to wily. I'm talking about https://tracker.debian.org/pkg/snappy
[09:19] <doko> mvo, no, different upload with a higher version number
[09:19] <pitti> from that we could estimate that it imports all 425 in ~ 8 h?
[09:20] <mvo> doko: oh, that snappy, sorry, I was confused
[09:20] <pitti> seb128, sil2100, wgrant: so did I get this right: we don't care (right now) about the 14000 *.po imports, just the 425 *.pot -> thus we could set all *.po to "needsinfo", and just let it import the pot
[09:20] <pitti> and once that's done, put the *.po back to approved to import them too?
[09:20] <seb128> wfm
[09:20] <pitti> and let message sharing take care of actually providing translations for wily?
[09:20] <sil2100> If you guys think that would work, +1 from me ;)
[09:21] <pitti> it's a theory based on what I learned in the last 5 minutes, don't take it for granted -- it needs to be wgranted
[09:21]  * pitti chips in 5 bucks into the "bad pun" cash savings box
[09:21] <seb128> :-)
[09:21] <dpm> assuming message sharing works as we expect, yes, it should work
[09:22] <sil2100> I just want the latest strings imported to the translations for wily so I can request an export and get properly updated .po files ;)
[09:22] <sil2100> pitti: ;)
[09:22] <sil2100> wgrant: what do you think about pitti's idea ^ ? :)
[09:22] <dpm> i.e. the templates would be up-to-date in LP once imported, and the export would put the translations from the DB into the final .po files, without needing to wait for the *.po import
[09:23] <pitti> it should import 400 pots in the course of minutes, based on the progress on seb128 | we are speaking about templates no?
[09:23] <pitti> eww, x c&p buffer!
[09:23] <pitti> ... on the progress on https://translations.launchpad.net/ubuntu/wily/+imports?field.filter_status=APPROVED
[09:23] <pitti> X c&p is seriously broken from firefox
[09:24] <dpm> actually, wgrant, do the PO imports need to be set to Needs Review at all? I.e. if the export is not blocking on the po imports, we can just trigger an export after the 425 templates have been imported, without further action
[09:25] <pitti> right, but we need to do the pots first, not 100 po files in between each pot
[09:25] <pitti> apparently it' just one big shuffled blob right now, the *.pot don't get prioritized
[09:26] <dpm> pitti, I think templates are imported first, but we'd need confirmation from the LP guys
[09:27] <pitti> dpm: no, demonstrably not
[09:27] <pitti> dpm: it imported several hundred *.po files but only 3 pot files during this talk
[09:27] <pitti> dpm: compare progress on https://translations.launchpad.net/ubuntu/wily/+imports?field.filter_status=APPROVED with https://translations.launchpad.net/ubuntu/wily/+imports?field.filter_status=APPROVED&field.filter_extension=pot
[09:27] <dpm> were the imported .po files corresponding to the 3 pot templates?
[09:28]  * dpm looks
[09:28] <pitti> importing pot first -> few minutes; import everything in that semi-random order: -> 8 hours
[09:29] <mvo> doko: snappy is uplaoded
[09:29] <wgrant> sil2100, pitti, dpm: Sorry, was eating. I think that POT-only approach sounds reasonable.
[09:31] <doko> mvo, hmm, ok, but that version number looks odd when copied to the archive
[09:31] <sil2100> pitti, wgrant, dpm: who can do this magic then?
[09:33] <dpm> wgrant, pitti, seb128, one thing to bear in mind is that not all templates are set up to message share with upstream trunk, but I think we might be able to assume that most if not all the packages for the phone are set up this way
[09:34] <seb128> dpm, we basically think we need update to dialer/messaging/browser
[09:34] <mvo> doko: uh, sorry, let me remove and upload again
[09:34] <seb128> so I think it should be ok
[09:34] <dpm> seb128, in that case, yes, these should be set up like that, but let me check
[09:34] <seb128> k
[09:35] <seb128> thanks
[09:36] <sil2100> And ubuntu-system-settings too
[09:36] <dpm> seb128, ok, I can confirm those 3 from https://translations.launchpad.net/ubuntu/vivid/+templates (the wily page is not yet up while templates are being imported, but the sharing configuration is copied over)
[09:36] <seb128> dpm, thanks
[09:36] <seb128> dpm, u-s-s as well?
[09:36] <dpm> sil2100, that one is sharing with trunk too, confirmed
[09:36] <sil2100> And unity8 I suppose?
[09:36] <dpm> lol
[09:36] <sil2100> ;)
[09:36]  * dpm checks
[09:37]  * sil2100 looks at the list before saying anything more
[09:37] <doko> siretart, ping on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777781
[09:37] <ubottu> Debian bug 777781 in src:aspectc++ "aspectc++: ftbfs with GCC-5" [Serious,Open]
[09:38] <dpm> sil2100, unity8 shares translations with trunk too
[09:38] <sil2100> dpm: could you also check address-book-app, indicator-network, indicator-sound, indicator-bluetooth, indicator-transfer, indicator-messages and mediaplayer-app?
[09:39] <sil2100> Not sure if we had any changes in the indicators, besides the network one...
[09:42]  * dpm checks
[09:44] <dpm> indicator-transfer and indicator-display are not set up for sharing
[09:45] <dpm> indicator-network and indicator-location are set up for sharing, but I'm not sure if with the right branch (they're using indicator-network/14.10 and indicator-location/14.04)
[09:45] <dpm> seb128, sil2100 ^
[09:50] <dpm> sil2100, seb128, in summary, it seems some of the indicators need to be set up for sharing: http://pastebin.ubuntu.com/11847330/
[09:51] <dpm> the problem is that for some of them translations are not enabled on the upstream project :/
[09:51] <sil2100> dpm: ok, but if that's the case, then it didn't have that in the past as well...
[09:52] <wgrant> dpm: We can use the API to approve the POs selectively relatively easily.
[09:52] <wgrant> (there is an API for one part of Translations: the import queue)
[09:52] <dpm> aha!
[09:53] <wgrant> To start, I intend to set all non-POT Approved wily imports to Blocked.
[09:54] <wgrant> The POTs will import relatively quickly, and we can import POs as required.
[09:54] <wgrant> When things are sorted out, we can re-approve the rest.
[09:54] <wgrant> Any objections, or shall I carry out the first step?
[09:54] <pitti> sounds good to me
[09:54] <pitti> importing the pots should only be a few minutes
[09:55] <dpm> great
[10:02] <hjd> Laney: Hi, I saw the discussion above. If you do end up merging pcre3, could you leave a comment at and/or close bug 1457964? :) It should be fixed in Debian, so I believe it's simply waiting for a merge.
[10:02] <ubottu> bug 1457964 in pcre3 (Ubuntu) "pcre3: enable jit again on ppc64el" [Low,Confirmed] https://launchpad.net/bugs/1457964
[10:02] <Laney> hjd: hi, ok
[10:03] <hjd> Thank you :)
[10:05] <sil2100> dpm, pitti, wgrant: is anyone doing all the dirty work for that? :)
[10:05] <pitti> I thought it required SQL? can't do that
[10:05] <wgrant> sil2100: Yep, waiting for sysadmins.
=== dholbach_ is now known as dholbach
[10:07] <doko> mvo, snappy failed to upload
[10:08] <sil2100> wgrant: thank you!
[10:08] <sil2100> seb128: so in the meantime I won't be reverting the langpacks that I uploaded since we're not having another image now anyway... QA can test translations later, once we have proper .po files
[10:08] <sil2100> seb128: I'll prepare then once we have the right export
[10:09] <sil2100> seb128: thanks for bringing this up and sorry for the mess-up, seems I didn't have enough data about the state of the translations
=== greyback__ is now known as greyback
[10:14] <smb> pitti, I think I found some explanation for bug 1466790. Not sure my "fix" is reasonable or makes systemd people run away screaming...
[10:14] <ubottu> bug 1466790 in ifupdown (Ubuntu) "dhclient does not remain running on boot" [Undecided,New] https://launchpad.net/bugs/1466790
[10:17] <dpm> seb128, howcome we're grabbing translations from wily for ota5?
[10:17] <pitti> smb: looking in a bit; still having infinite fun with more broken swap partitions and ecryptfs-setup-swap..
[10:18] <pitti> kirkland, cyphermox: did we ever start a discussion on some "official" place (blueprint/bug) about stopping configuring swap partitions in the installer?
[10:18] <dpm> seb128, ah, I get it, messaging-app & co are .debs and depend on newer templates on vivid, right?
[10:18] <sil2100> dpm: since we don't have the infra set-up for overlay translations yet
[10:18] <sil2100> dpm: but since we're using dual landing for most packages, wily and vivid have the same sources
[10:18] <smb> pitti, sounds like a tar pit of fun...
[10:18] <pitti> err, WTF
[10:18] <pitti> $ dpkg -L libecryptfs0
[10:19] <sil2100> So temporarily, as a quick workaround, we're using the wily ones
[10:19] <pitti> /usr/lib/libecryptfs.so.1
[10:19] <pitti> kirkland, tyhicks: ^ noooo
[10:19] <sil2100> dpm: as this is the only thing we can do this time
[10:19] <dpm> thanks sil2100
[10:20] <dpm> sil2100, once the overlay is set up, where will translations be done?
[10:22] <sil2100> dpm: the proposed solution is to use the ubuntu-rtm distro for those
[10:27] <mvo> doko: yeah, I'm fixing, thanks
[10:29] <dpm> sil2100, oh I see, so should we then point translators to https://translations.launchpad.net/ubuntu-rtm once it's all set up?
[10:29] <sil2100> dpm: yes, I suppose that's how it'll look like - there will be a proper announcement once that happens
[10:30] <dpm> sil2100, ok, thanks. Another question: are there going to be series too, or will basically ubuntu-rtm be used effectively as rolling?
[10:31] <wgrant> dpm: https://launchpad.net/ubuntu-rtm/15.04/+imports
[10:31] <wgrant> Not active yet, so don't try to poke anything.
[10:31] <wgrant> But translations from the vivid overlay PPA go there.
[10:31] <dpm> wgrant, ah, cool, that answers it then, thanks!
[10:31] <sil2100> :)
[10:36] <pitti> smb: ah, are you using open-iscsi or something?
[10:37] <pitti> smb: there are only two things that bring up /e/n/interfaces normally: /etc/init.d/networking and ifup@.service via udev
[10:37] <pitti> smb: open-iscsi kind of hooks into that
[10:37] <smb> pitti, Not really. I think MAAS deployments may include it. Oh... for bare-metal... yeah I may have installed open-iscsi to try something else
[10:38] <smb> for reasons usually long forgotten because those were... err last week
[10:39] <pitti> smb: so it could be that I don't see it because in my case init.d/networking already brought up everything, and thus ifup@eth0.service didn't really do anything ("interfacae is already up")
[10:39] <Mirv> what's up with armhf builders btw? builds taking roughly double the time compared to June.
[10:39] <Mirv> so qtbase takes 8+ hours instead of <=4
[10:39] <smb> pitti, Right. Same with normal desktop as there network manager handles things
[10:49] <mvo> doko: should be good now
[11:01] <opiwahn> I have still no luck in booting in text mode in 15.04
=== MacSlow is now known as MacSlow|lunch
=== _salem is now known as salem_
=== MacSlow|lunch is now known as MacSlow
[13:13] <sil2100> pitti: hey! Do you know if there's any progress regarding translations?
[13:15] <pitti> sil2100: apparently so - https://translations.launchpad.net/ubuntu/wily/+imports?field.filter_status=APPROVED is becoming smaller and just has POTs now
[13:15] <sil2100> \o/
[13:16] <cjwatson> Yeah, admins did the DB change for us
[13:16] <sil2100> So once this queue gets empty, I can request a new export with the proper translations, right?
[13:18] <pitti> I already requested a full export on https://translations.launchpad.net/ubuntu/wily/+language-packs
[13:18] <teward> pitti: can I pick your brain again when you're a little less busy?
[13:18] <pitti> so once the POTs are imported, the wily langpack cronjob needs to be restarted (by wgrant or cjwatson), then we should have an export after some hours
[13:18] <pitti> teward: just ask, there's no better or worse time :)
[13:19] <teward> pitti: so, three things.  First, i've got working apport hooks, plus code-checking to verify that the init system is actually systemd and not upstart (sicne I know someone who uses Upstart and not SystemD on a highly irregular 15.04 box).  There's two issues, though.
[13:20] <teward> pitti: firstly, when pulling `systemctl -l status nginx-service` it says "Error: Exited with code 3" which is the error code systemd returns from the command - which in turn makes its way into the output file
[13:20] <teward> secondly, i'd like to expand it to prompt the user for certain report types (Crash, Bug) if they want to include the error.log, nginx.conf file, and enabled site configs.
[13:21] <teward> AFAICT those work fine, but the prompts run twice
[13:21] <teward> such that P1 P2 P3 are asked, then it repeats the cycle
[13:21] <teward> before going and finishing collection
[13:21] <pitti> teward: that's from the command_output() wrapper; if you call a program which is expected to fail, then I suggest calling subprocess.getstatusoutput() directly
[13:22] <teward> pitti: ok.  that's what I thought, i was hoping there was an easier method but ehh.
[13:22] <pitti> teward: as I wrote this morning, I'd need to see the hook and where you put it
[13:22] <pitti> teward: how could it be easier?
[13:22] <teward> pitti: i didn't see that, sorry, my scrollback is limited on my bouncer :/
[13:23] <pitti> teward: out = subprocess.getstatusoutput('meh')[1]
[13:23] <teward> wow, i need coffee, I thougth i'd have to import another module, forgot I had to import subprocess for another function >.<
[13:23] <pitti> quite possibly you only want to know whether it's running, then just check the return code instead
[13:23] <teward> i hate mornings sometimes :P
[13:23] <teward> pitti: actually the opposite - we want the information from `systemctl status nginx.service` because it actually spits the errors into there
[13:24] <pitti> teward: ah
[13:24] <teward> rather than "Is It Running" we need to know "Why Did It Fail To Start"
[13:24] <teward> i'm hesitant to include the error.log because that could have sensitive information.  but the systemd status logs *would* tell us what happened
[13:24] <teward> (whereas `journalctl -xe --unit=nginx.service` doesn't always show it)
[13:25] <teward> i'm content to let it keep the "Error code 3" stuff in the message, since nginx *did* fail to start or isn't running.  but if there's a way to remove it that'd be even better
[13:25] <teward> I have the two variant scripts stored in a VM, give me 3 seconds to pull them off there
[13:26] <teward> (since my primary system is Trusty)
[13:26] <pitti> teward: well, command_output()'s sole reason to exist is to provide exactly that functinoality; if you don't want it, just call getstatusoutput directly()
[13:27] <teward> pitti: ack.  i'll use getstatusoutput in place of it
[13:28] <teward> assuming the VM wants to actually start
[13:28]  * teward hates VMs sometimes
[13:28] <pitti> teward: actually, even easier: out = subprocess.getoutput('your command')
[13:28] <pitti> (if you don't care about the exit code)
[13:28] <cjwatson> check_output if you do
[13:29] <cjwatson> subprocess.getoutput doesn't exist anyway :)
[13:29] <pitti> not in this case, don't want to fail on exit code 3 (which is expected)
[13:29] <pitti> cjwatson: err, what?
[13:29] <teward> cjwatson: it works fine in python 3
[13:30] <cjwatson> oh right
[13:30] <cjwatson> stuck in the past
[13:30] <pitti> I know, shell and all, but *shrug*, it's just a static commannd
[13:30] <cjwatson> marked as legacy though :)
[13:30] <teward> http://paste.ubuntu.com/11848412/  <--
[13:30] <teward> cjwatson: 'tis fine :)
[13:30] <cjwatson> I usually prefer subprocess.Popen([...], stdout=subprocess.PIPE).communicate()[0]
[13:31] <cjwatson> or try: subprocess.check_output() except subprocess.CalledProcessException: re-raise anything with an unexpected exit code
[13:31] <pitti> cjwatson: yeah, I feel that's a rather big omission in the subprocess API
[13:31] <cjwatson> latter could be wrapped up easily
[13:32] <pitti> that there's no argv method for "give me the output of a program which is allowed to exit non-zero"
[13:32] <pitti> except for the complicated one you mentioned
[13:33] <pitti> anyway, bikeshed → green
[13:33] <cjwatson> something like http://paste.ubuntu.com/11848429/
[13:33] <teward> pitti: if you had a choice, would you use the Popen method or the getoutput method?
[13:33] <cjwatson> untested, literally just typed into pastebin
[13:33] <teward> i.e. which is less likely to explode in our faces five python revisions down the road :P
[13:33] <cjwatson> I'd use the thing I just pasted :)
[13:33] <pitti> cjwatson: does that actually give you the output on failure?
[13:34] <pitti> teward: I usually use Popen()...communciate()[0]
[13:34] <cjwatson> pitti: "The CalledProcessError object will have the return code in the returncode attribute and any output in the output attribute."
[13:35] <pitti> cjwatson: ok, that's too contrived for my taste; I'm with communicate() :)
[13:35] <cjwatson> pitti: ah, sorry, should also have a return e.output in the else case there
[13:36] <pitti> barry: please just give us a subprocess.get_output(). love, pitti
[13:36] <pitti> :)
[13:36] <teward> heh
[13:36] <barry> pitti: what's up? :)
[13:36] <pitti> barry: bikeshedding above -- pythonic way to get the output of a program which is expected to return nonzero
[13:37] <pitti> barry: i. e. the non-exceptionary variant of check_output()
[13:37] <pitti> barry: nvm, it was just meant as a joke, but the API is oddly asymmetrical there
[13:38] <pitti> teward: anyway, all this probably confused you more than it helped :/
[13:38] <pitti> teward: cjwatson | I usually prefer subprocess.Popen([...], stdout=subprocess.PIPE).communicate()[0]
[13:38] <pitti> teward: that'll do fine
[13:38] <teward> i was going to use that anyways
[13:38] <teward> i'm just currently debugging why sftp is blowing up in my face
[13:38] <barry> pitti: ah :) i see you suggest Popen() directly, and yeah i'd agree.  i see what you mean, but non-zero exits are probably not handled because they *are* exceptional :)
[13:39] <pitti> barry: right, it's just that subprocess.getoutput() is so darn convenient, if it wasn't for the shell/no argv
[13:40] <barry> pitti: ah, yeah.  those are legacy apis after all
[13:42] <teward> pitti: in that command you just stated, where [...] exists, that's the same syntax as command_output(['array','of','command','and','args']) ?
[13:42] <teward> (i.e. just drop in the [ ] array?)
[13:42] <pitti> teward: right, it's an argv
[13:42] <teward> ack
[13:45] <barry> of course 'array of command and arg'.split() works too
[13:46] <Daviey> Be careful if using Popen.wait() for checking return codes, the logic was changed in 2.7 which can cause unexpected exit codes.. (due to the fix in http://bugs.python.org/issue14396)
[13:52] <cjwatson> I basically think any non-argv process execution mechanism is a timebomb, if not due to underlying library changes, then a timebomb for future developers
[13:57] <teward> pitti: and whoever else wants to spotcheck me: This is the bare minimum that should be in the hooks for now:  https://github.com/teward/nginx-apport-hooks/blob/master/no-config-prompts/source_nginx.py
[13:57] <teward> and yes it's at github because version tracking is nice so I know what i did xD
[13:57] <teward> and it's a bad thing i make a lot of helper functions, yes.  that's how i was taught coding though :/
[13:57]  * teward needs to break that habit
[13:58] <cjwatson> "github because version tracking is nice" -> logic does not follow :P
[13:59] <barry> zyga: you're a "checkbox" guy right?  have a few moments for some questions?
[13:59] <pitti> teward: the init system check is a bit broken -- it won't work right after you switch init systems, like after a dist-upgrade
[13:59] <Daviey> teward: pep8! screen width isn't free you know!
[13:59] <pitti> teward: os.path.isdir('/run/systemd/system') is the only tried and true, foolproof, and simple way to assert that
[13:59] <cjwatson> teward: seriously, os.path.isdir("/run/systemd/system")
[13:59] <cjwatson> I gave you that code last night :)
[13:59] <pitti> teward: also, procps doesn't need to be installed
[13:59] <cjwatson> and it's *shorter* than what you're doing
[14:00] <cjwatson> teward: it's also the algorithm recommended in http://www.freedesktop.org/software/systemd/man/sd_booted.html
[14:00] <cjwatson> ("A simple check like this can also ..." etc.)
[14:00] <pitti> teward: if it's not systemd, it's upstart, no need to check for that
[14:01] <teward> ok
[14:01] <teward> cjwatson: i'm tired, my logic is slightly borked.
[14:01] <pitti> teward: I'd eliminate the two def _systemd_*() and just fold them into add_info(), but that's a matter of taste; looks good aside from the init system check
[14:01] <teward> got called to a 6AM "Emergency Fix It" thing :/
[14:01] <teward> and i only had 3 hours sleep >.<
[14:01] <teward> i shouldn't be awake
[14:02] <pitti> (there's lots of other style issues, but I'll try to restrain myself :) )
[14:02] <teward> :P
[14:02] <pitti> i. e. the whole thing should be 5 lines tops
=== vrruiz_ is now known as rvr
[14:03] <teward> pitti: heh, yeah i tend to be overly verbose
[14:03] <cjwatson> I don't think you should apologise for helper functions if they're well structured
[14:05] <teward> Daviey: yes, i wanted something functional before making it look pretty
[14:05] <Daviey> teward: fair enough :)
[14:05] <zyga> barry: yes
[14:05] <zyga> barry: absolutely
[14:05] <zyga> barry: hangout or locally?
[14:06] <pitti> cjwatson: right, I meant the True/False returns, nested ifs, and overly split single-use functions; but *argh* restrain myself harder *argh*
[14:06] <barry> zyga: shouldn't take long, i'll pvtmsg you
[14:06] <zyga> barry: thanks
[14:06] <pitti> if report['ProblemType'] == 'Package' and os.path.exists('/run/systemd/system'):
[14:07] <pitti>    <call journalctl and systemctl>
[14:07] <pitti> that's really all it is
[14:13] <teward> so then you want something like this then:  https://github.com/teward/nginx-apport-hooks/blob/master/no-config-prompts/source_nginx.py  (this is updated)
[14:14] <rbasak> bdmurray: looking at the samba phasing stop with rharper, I don't really understand how to interpret the page your notice linked to.
[14:14] <teward> pitti: ^
[14:14] <rbasak> bdmurray: I can't see the data that suggests the error rate has increased
[14:14] <rbasak> bdmurray: it looks like a constant stream of errors that has always been present. Is there a graph that'll actually show me the increase please?
[14:16] <pitti> teward: heh, yes; os.path.isdir() would be a bit "more correct", but good enough like that
[14:17] <teward> pitti: mmm yep i remembered that just now, lemme fix, then this is 'done' for now
[14:22] <pitti> sil2100, cjwatson: https://translations.launchpad.net/ubuntu/wily/+imports?field.filter_status=APPROVED&field.filter_extension=all -> done!
[14:22] <pitti> wgrant: so we can now revert that SQL magic and let the other po files get imported
[14:22] <pitti> cjwatson: as wgrant is probably/hopefully asleep now, could you start the wily langpack export cronjob?
[14:23] <cjwatson> pitti: I really have to go out for a bit, can it wait an hour?
[14:24] <pitti> cjwatson: sure, I'm not waiting for it; sil2100 is
[14:24] <cjwatson> pitti: is the langpack export useful without the po import?
[14:24] <pitti> cjwatson: wgrant/seb128 believed so, due to translation sharing with trunks
[14:29] <teward> pitti: cjwatson: Daviey: thanks to all of you for your help :)
[14:30] <teward> i'll circle back later when i start stabbing the 'prompt to include other files' stuff
[14:32] <sil2100> \o/
[14:32]  * sil2100 needs the updated .po files
[14:34] <kirkland> pitti: well, I filed a blueprint about it, in like...jaunty?
[14:34] <kirkland> pitti: does that count?
[14:34] <pitti> kirkland: apparently it wasn't implemented :)
[14:35] <kirkland> pitti: :-)  let's get rid of it, and promote swapspace package to main
[14:35] <kirkland> pitti: with some sane defaults
[14:35] <pitti> kirkland: anyway, I piled up two patches for ecryptfs-setup-swap (second patch from today in wily), and some postinst (not sure if that is also in the upstream trunk)
[14:35] <kirkland> pitti: interesting, I'll have a look
[14:35] <kirkland> pitti: I have a flight tomorrow, I'll check it out
[14:35] <kirkland> pitti: have you played with swapspace yet?
[14:36] <kirkland> pitti: maybe try it out on your machine
[14:36] <pitti> kirkland: no, I haven't yet; it's been ages since I wanted/needed swap
[14:36] <kirkland> pitti: before I added 16GB of mem to my x250, I ran with 8GB and swapspace for a few weeks
[14:36] <kirkland> pitti: agreed--me either, but I decided to give it a try
[14:36] <kirkland> pitti: byobu monitors swap usage
[14:36] <kirkland> pitti: it seemed to do the right thing
[14:36] <kirkland> pitti: on a related note, G+ Hangouts are MEMORY HOGS
[14:37] <teward> um... i forgot, so if someone would be willing to refresh my memory... if two releases of Ubuntu have the same package version number, and I need to fix in Wily and also in Vivid, what do I do with the version strings?
[14:37] <sil2100> cjwatson: I can wait a bit if needed, just hope the export won't take as long as previously
[14:37] <pitti> teward: normal increment for devel series (wily), and add 0.1 for SRUs
[14:37] <kirkland> pitti: but I agree -- swap in general is as bad as subprime mortgages
[14:38] <pitti> teward: that has been a common pattern for a long time; or just the wily version and append ~vivid1
[14:38] <kirkland> pitti: you're loaning someone something that's ultimately going to make their life worse
[14:38] <pitti> kirkland: hah, good one
[14:38] <kirkland> pitti: I gotta go, customer meetings
[14:38] <pitti> kirkland: yeah, I've now spent too many hours cleaning up after ecryptfs-setup-swap and we've shipped broken systems for years
[14:38] <kirkland> pitti: could you drop me an email with a pointer to the patches?
[14:38] <pitti> kirkland: o/
[14:38] <teward> pitti: given that this is, of course, the nginx package and we have a pending plan of action (provided TB approves, once we send in), it won't remain the case going forward, but I think i'll do the .1 method
[14:38] <pitti> kirkland: sure
[14:39] <teward> pitti: i thought that was the case but I wasn't sure, thanks for confirming :)
=== soee_ is now known as soee
[14:59] <pitti> kirkland: mailed
[15:26] <sil2100> cjwatson: could you simply give me a poke once the new, perfect and flawless LP translation export is ready? :)
[15:26] <sil2100> Would be grateful
[15:40] <om26er> pitti, Hi!
[15:40] <om26er> pitti, is there a way to run a command *after* adt-run executes the tests ?
[15:44] <pitti> om26er: a counterpart of --setup-commands? not right now
[15:45] <om26er> pitti, yes and :/
[15:45] <om26er> pitti, I kind of apt-mark hold a few packages and would like to unhold them after tests run
[15:45] <pitti> om26er: it never came up yet
[15:46] <pitti> om26er: hm, for most testbeds (ephemeral) that's pointless, and for non-ephemeral testbeds you can just do that after the adt-run call?
[15:47] <om26er> pitti, hmm, I could change my test runner script to unhold packages after adt-run hmm.
[15:47] <teward> anyone able to provide any insight to why an sbuild run would be 'attempted' but fail?
[15:47] <teward> if i provide sbuild logs that is
[15:47] <teward> (assuming it fails again)
[15:48] <om26er> thanks pitti, let me see how far I can get with that.
[15:48] <om26er> pitti, you might want to consider that feature for future releases, though.
[15:48] <teward> (brb thoug ha moment)
[16:01] <om26er> pitti, at what stage does adt-run installs dependencies ? I am looking inside run-system-tests script and can't see where it actually installs the debs.
[17:26] <teward> I'm either blind or can't figure it out, anyone know why this is failing?  http://paste.ubuntu.com/11849975/
[17:27] <teward> (it's an sbuild log)
[17:34] <zyga> barry: hey, how can I build against python3.5?
[17:34] <zyga> barry: can I add a PPA to my wily schroot?
[17:34] <zyga> barry: or should I use sid?
[17:34] <zyga> barry: I have a patch that test builds in both places but I'm unsure if that's with 3.5 now
[17:35] <barry> zyga: easiest right now is to add the pythoneers/py35asdefault ppa
[17:35] <barry> zyga: or
[17:35] <zyga> deb http://ppa.launchpad.net/pythoneers/py35asdefault/ubuntu wily main  ?
[17:36] <barry> zyga: that should work.  i always use add-apt-repository from software-properties-common
[17:36] <zyga> ah
[17:37] <barry> add-apt-repository ppa:pythoneers/py35asdefault should do it
[17:37] <barry> (there's also a purge-ppa which mostly undoes that)
[17:40] <teward> barry: what do you know about diagnosing sbuild failures, if anything
[17:40] <teward> sorry, i'm just kinda scratchin my head here tryin to solve this 'fail'
[17:40] <barry> teward: a bit.  i use sbuild all the time
[17:40] <teward> barry: http://paste.ubuntu.com/11849975/  <-- can't wrap my head around this
[17:40]  * zyga tries with 
[17:40] <teward> it shows 'attempted'
[17:40] <zyga> sbuild -d wily --chroot-setup-commands='apt-key adv --keyserver keyserver.ubuntu.com --recv-key 224D9D15EE176F89' --extra-repository 'deb http://ppa.launchpad.net/pythoneers/py35asdefault/ubuntu wily main' --extra-repository 'deb http://archive.ubuntu.com/ubuntu wily universe'
[17:41] <teward> but it's not a code break, barry
[17:41] <teward> at least not afaict
[17:41] <barry> teward: is the build failure on line 4074 you're wondering about or something else?
[17:42] <teward> barry: that's the only failure i can find
[17:42] <teward> so it goes 'attempted' not 'failed'
[17:42] <teward> but it's equivalent
[17:42] <zyga> barry: hmmm, I'm doing something wrong because...
[17:42] <zyga> I see this:
[17:42] <teward> barry: same package doesn't have the problem in vivid
[17:42] <teward> (vivid and wily have the same code, and the same changes except for debian/changelog entires, with my sbuild runs today)
[17:43] <barry> teward: that's some problem with the package's d/rules i guess.  but the nice thing is you can now do `schroot -u root -rc <session-id>` and then drop into the chroot and poke around at the errors, retry the build, etc
[17:43] <zyga> http://pastebin.ubuntu.com/11850070/
[17:43] <barry> teward: sbuild is great at giving you a debuggable environment when the builds fail
[17:43] <teward> barry: i'm not sure where to check next :/
[17:44] <barry> teward: sorry, i can't help much with that right now; i don't know much about the nginx packaging
[17:44] <barry> zyga: hang on, i have a script that helps
[17:44]  * teward grumbles
[17:44] <zyga> barry: why doesn't it see all those deps? are they not in wily now (they must be, they were in vivid)
[17:44] <teward> this is a pain, it builds FINE in Vivid, fails in Wily
[17:44] <barry> teward: likely toolchain or dependents differences
[17:45] <teward> then how the heck did the thing build :/
[17:45]  * teward grumbles
[17:45] <zyga> barry: and this is the patch I'm test-building http://paste.ubuntu.com/11850085/
[17:46] <barry> teward: if there have been no changes since vivid, it probably hasn't been rebuilt since then
[17:46] <barry> zyga: bzr branch lp:~barry/+junk/repotools
[17:46] <barry> then:
[17:46] <barry> sbuild ... --chroot-setup-commands="/repo/sbuildppa.sh" ....dcs
[17:46] <barry> *dsc
[17:47] <barry> zyga: but also look at: https://wiki.ubuntu.com/SimpleSbuild#Local_packages
[17:47] <barry> zyga: anyway, that's the recipe i use
[17:47] <zyga> thanks
[17:48] <teward> i should probably try the merge from debian then locally and see if THAT builds
[17:48] <teward> because if it doesn't i fear the package will fall out of the repos
[17:48] <barry> teward: take a look at the upload history.  maybe there's another dev around that has more immediate experince w/nginx
[17:48] <teward> barry: mmm... that'd be me
[17:48] <teward> :/
[17:48] <barry> teward: oh ;)
[17:48] <teward> i've never seen this type of failure
[17:49] <barry> teward: looks to me like debian/tmp/use is nonexistent in the chroot
[17:50] <teward> barry: what would even cause that to be created though... I've grep'd everywhere and there's no reference to it, the only thing I can think of is the build process has been changed
[17:50] <teward> and if it has, i need documentation on that to try and debug
[17:50] <barry> teward: maybe a debhelper change?
[17:51]  * barry is just guessing tho
[17:51] <teward> barry: i'm guessing too
[17:51] <teward> who's in charge of the debhelper changes if any
[17:51] <barry> that's mostly inherited from debian
[17:51] <teward> so I should go to #debian and throw things at them, then... *shrugs*
[17:51] <barry> tho i'm sure there are ubuntu deltas, i doubt this is the cause of your pain
[17:52] <teward> well then i'm going to have to stab rbasak and get him to priority 1 the TB email
[17:52] <teward> since my GUESS is that there's changes between 1.6.x to 1.9.x which fix the build fails
[17:52] <tarpman> no stabbing rbasak. i might still need him alive
[17:52] <teward> and any merge to Wily is dependent on an X-series TB exemption approval
[17:53] <zyga> barry: weird
[17:53] <zyga>  sbuild -d wily --chroot-setup-commands='apt-key adv --keyserver keyserver.ubuntu.com --recv-key 224D9D15EE176F89' --extra-repository 'deb http://ppa.launchpad.net/pythoneers/py35asdefault/ubuntu wily main' --extra-repository 'deb http://archive.ubuntu.com/ubuntu wily main universe'
[17:53] <zyga> this builds for me
[17:53] <zyga> so I had to add wily into the ... wily schroot?
[17:53] <teward> god I hate my computer
[17:53] <zyga> teward: hey, want to see mine ;)
[17:54] <teward> zyga: can i light it aflame out of spite?
[17:54] <teward> (loljk)
[17:54] <teward> sorry i've been bashing my head against nginx for too long the past 3 days
[17:54] <zyga> teward: GPU burned, keyboard stopped working on the left side, got new GPU, won't fit case, got new case, wont ship for a week (holidays)
[17:54]  * teward mumbles something about apport hooks
[17:54] <teward> heheheh
[17:55] <zyga> now I'm computing with all the guts out, on the desk
[17:55] <zyga> oh and today morning I had to take out 3 ram sticks or it would not boot
[17:55] <zyga> I guess summer isn't healthy for hardware
[17:56] <teward> and three hours sleep isn't healthy for maintainers
[17:56]  * teward grumbles
[17:56] <zyga> barry: built and tested fine, I'll commit to debian and ask for upload
[17:56] <barry> zyga: +1
[18:01] <pitti> om26er: you see it in the logs; it opens testbed, runs --setup-command / apt-get upgrade, copies the test into the testbed, reads test deps there, and installs them, then runs the test
[18:01] <zyga> barry: sent, CCd
[18:01]  * zyga -> off
[18:01] <barry> zyga: thanks
[18:19] <teward> when using udd / bzr to merge from Debian, how would one resolve this caused by Debian removing the file?  Contents conflict in debian/index.html
[18:23] <teward> nevermind
[19:33] <teward> barry: how can i drop into the failing schroot
[19:44] <barry> teward: grab the id of the schroot from the sbuild output at the bottom and: schroot -u root -rc <id>
[19:44] <teward> thanks
[20:19] <teward> who here knows the most about how debhelper and package building has changed for Wily
[20:19] <teward> (i.e. debhelper, etc.)
[21:58] <teward> barry: you wouldn't happen to have any scripts lying around that would take in a list of releases and sequentially build multiple arch's schroots for sbuild, would you?  Just curious, if not i'll write one
[22:02] <sarnold> teward: there's a little tiny copypaste on https://wiki.ubuntu.com/SecurityTeam/BuildEnvironment -- search for "finally"
[22:05] <teward> aha!
[22:05] <teward> sarnold: thank you kindly :)
[22:11] <barry> teward: glad sarnold pointed you to the script.  i have a bunch of little doodads in lp:~barry/+junk/repotools
[22:15] <teward> barry: i might steal xD
[22:15] <teward> or borrow :)
[22:15] <barry> teward: enjoy! :)
[22:16] <mwhudson> so um er is the powerpc64le abi documented anywhere? <- infinity you'll know this?
[22:25] <mwhudson> nm, found it
[23:16] <teward> so, new question.  For installing .apport files, the package needs to build-dep on dh-apport right?  And do I need to call dh_installapport in the debian/rules ?
[23:20] <teward> wait i think i figured it out...
[23:50] <teward> mmm... nope
[23:50] <teward> anyone got any guidance on actually getting the .apport files installed with the given binary package?
[23:50] <teward> (E: No Documentation)