[04:48] <Mirv> robru: now here
[04:48] <robru> Mirv: too late!
[04:50] <Mirv> robru: I thought so :
[04:50] <Mirv> )
[07:07] <oSoMoN> ubuntu-qa: can I get someone to validate silo 5 pretty please? This is a prerequisite for other webbrowser-app landings that I hope can make it before FF for ota6, so rather urgent.
[07:59] <morphis> sil2100: I created a new request for landing to vivid (syncing a package from wily) and got a silo assigned, is there anything else I have to do other than waiting to get the package synced into the silo?
[08:03] <Mirv> morphis: a sync silo syncs when you hit the 'build'
[08:04] <morphis> ah good to know
[08:04] <morphis> Mirv: do I have to specify and specific options when starting the build job?
[08:04] <Mirv> morphis: I don't think so
[08:05] <morphis> looks like it works
[08:05] <morphis> Mirv: thanks
[08:11] <morphis> Mirv: hm, looks what I tried doesn't work
[08:11] <morphis> seems like this needs to be a manual upload again
[08:13] <Mirv> morphis: ah, right, it's not CI Train handled package so... :(
[08:13] <morphis> hm
[08:13] <Mirv> morphis: you can't escape the manual uploads as long as you hack on those low lervel bits :)
[08:13] <morphis> hehe
[08:14] <morphis> Mirv: should I reuse this silo now for the manual upload or get a new one?
[08:14] <Mirv> or maybe we could ask google to have android building as part of CI Train, in Launchpad bzr
[08:14] <Mirv> morphis: just reuse it
[08:14] <morphis> Mirv: :D
[08:47] <sil2100> ogra_: hey! Do you know if infinity had any luck in finding out what's the problem? Since I see the recent 2 tarballs have the same issue still
[08:47] <ogra_> sil2100, no, he didnt say anything in this channel after you left
[08:48] <ogra_> sil2100, my first suggestion would be to add --verbose to the apparmor profile generation in livecd-rootfs and do a test build, the log is rather quiet at the point where the files with the wrong stamps get created
[09:23] <ogra_> sil2100, http://paste.ubuntu.com/12054467/
[09:24] <ogra_> bah, damn ... slangasek didnt push his change to the branch
[09:25]  * ogra_ merges first
[09:29] <sil2100> What change did slangasek make?
[09:29] <sil2100> ogra_: thanks!
[09:30] <ogra_> tasks to metapackages ...
[09:38] <sil2100> ogra_: if you find a moment of free time, could you also take a look at a low-prio branch https://code.launchpad.net/~sil2100/livecd-rootfs/deb-src_for_extra_ppas/+merge/267375 here?
[09:43] <sil2100> ogra_: did you release livecd-rootfs already?
[09:45] <ogra_> sil2100, yup
[09:45] <sil2100> Can I kick a new rootfs build?
[09:46] <ogra_> https://launchpad.net/ubuntu/+source/livecd-rootfs/2.336 still in proposed
[09:51] <oSoMoN> jibel, thanks for validating silo 5 :)
[09:52] <sil2100> o/
[09:53] <oSoMoN> trainguards: silo 5 is ready for publication, I’m unsure whether I can pull the trigger myself or if I still need one of you guys to do it for me?
[09:53] <jibel> oSoMoN, np
[09:53] <sil2100> oSoMoN: hey! We still do the publishing as normal users don't have the power
[09:54] <sil2100> ogra_: hey, could you review this? Looks sane, and the dep changes are mentioned in the changelog: https://ci-train.ubuntu.com/job/ubuntu-landing-005-2-publish/65/artifact/webbrowser-app_packaging_changes.diff
[09:54] <sil2100> ogra_: which is a + I suppose
[09:54]  * sil2100 still isn't a core-dev so he has no power here
[09:54] <ogra_> ACK
[09:57] <oSoMoN> thanks ogra_
[09:59] <sil2100> oSoMoN: thanks!
[10:16] <oSoMoN> trainguards: it is possible to merge changes to trunk while a package is awaiting in wily-proposed, right?
[10:20] <sil2100> oSoMoN: yes
[10:20] <sil2100> oSoMoN: do you expect webbrowser-app to be stuck in -proposed because of gcc-5?
[10:21] <oSoMoN> sil2100, I don’t expect that, no, but I want to speed things up as I have several other landings lined up for today, and I need to rebuild silos, so I need trunk to be up-to-date
[10:25] <sil2100> wgrant: ping! Hey, do you know if cjwatson was able to perform the translation batch copy from wily to the overlay 15.04 series?
[10:28] <oSoMoN> sil2100, so for the manual merge, I just click the "clean" link in the dashboard, check "force", press "build" and that’s it?
[10:29] <sil2100> oSoMoN: wait, hm, are you sure it'll migrate fine?
[10:30] <sil2100> Actually, nevermind, I suppose having changes in trunk under control without migrating should be fine
[10:30] <sil2100> Just be sure to watch the excuses page
[10:30] <sil2100> oSoMoN: yes, clean and 'FORCE'
[10:30] <oSoMoN> sil2100, I don’t see any reason for it not to migrate fine, it’s gcc5 compliant and all :)
[10:30] <oSoMoN> ok
[10:31] <sil2100> Well, you know, proposed migration is a safety net, so we always prefer to see it migrate and everything
[10:31] <sil2100> ;)
[10:34]  * sil2100 can't wait for livecd-rootfs to migrate
[10:37] <ogra_> sil2100, bah, i just noticed i had checked the wrong log ... wily builds actually use -proposed (vivid ones don't)
[10:37] <ogra_> sil2100, just kick it
[10:38] <sil2100> Yeah, they do, but for building - will the build system use the wily-proposed too?
[10:38] <sil2100> I wasn't sure if it would pick up the right livecd-rootfs to prepare the build itself
[10:38] <ogra_> building ?
[10:38] <ogra_> yes, it will
[10:39] <sil2100> Kicking in that case
[10:44] <wgrant> sil2100: It's ready to run, just needed to recheck with you that it was OK to do so.
[10:45] <sil2100> wgrant: excellent, green light from my side - thanks!
[10:51] <greyback> trainguards: I could do with a hand with silo19, vivid+o only, stuck in proposed, boottest failing
[10:55] <oSoMoN> trainguards: I just edited a landing request (#119, in silo 54), replacing one MR by another, how do I reconfigure the silo?
[10:58] <Mirv> greyback: looking
[10:58] <ogra_> sil2100, hmm, i386 already exploded with dependency errors
[10:59] <greyback> oSoMoN: just click the "assign" link, that will reconfigure too
[10:59] <oSoMoN> ah, thanks greyback
[10:59] <wgrant> sil2100: It appears done, though the list of templates is shorter than one might perhaps expect. Do you have a list of things that were missing?
[11:01] <Mirv> greyback: vivid+o packages seem correctly all in the PPA. the wily packages are stuck in proposed (like many are) - do you need the trunk to be up-to-date so you can continue working? I can merge&clean manually.
[11:02] <Mirv> I can I also restarted the boottest now, but it won't help in migration since the landing depends on gcc-5 migrating first
[11:02] <greyback> Mirv: I'd appreciate the trunks being up to date yes
[11:04] <Mirv> greyback: trunks are now up-to-date
[11:04] <greyback> Mirv: many thanks good sir
[11:04]  * Mirv sees tag fun, lp:qtmir has "742 tags updated." <3
[11:04] <Mirv> yw
[11:27] <sil2100> wgrant: hey, how can I check that? https://translations.launchpad.net/ubuntu-rtm/15.04 doesn't seem to work
[11:27] <wgrant> sil2100: Ah, try now.
[11:29] <sil2100> wgrant: ok, checking now if everything looks fine - but so far it seems okayish
[11:35] <sil2100> wgrant: ok, I see some applications missing from the list
[11:35] <sil2100> wgrant: I'll prepare which
[11:35] <wgrant> sil2100: Thanks.
[11:36] <ogra_> infinity, sil2100 http://paste.ubuntu.com/12054992/ ... so the broken timestamp is already there when the apparmor profiles get generated
[11:36] <ogra_> May  8  1959
[11:37] <ogra_> (snippet from https://launchpadlibrarian.net/214158968/buildlog_ubuntu_wily_armhf_ubuntu-touch_BUILDING.txt.gz)
[11:38] <sil2100> wgrant: the few missing ones that I found are here: http://paste.ubuntu.com/12055000/ - could you somehow copy those over as well? :)
[11:38] <sil2100> ogra_: ugh
[11:39] <ogra_> not sure what to make out of that ...
[11:39] <wgrant> sil2100: ciborium isn't in the overlay PPA.
[11:40] <ogra_> there are ls calls bevore and after and they show proper timestamps
[11:40] <wgrant> Nor are the others.
[11:44] <sil2100> wgrant: hmm, I was sure we had releases of those... but anyway, we have those in our images - will the translation export have their .po files after generation?
[11:45] <wgrant> sil2100: They won't be included in ubuntu-rtm/15.04 langpack exports. But they are in ubuntu/vivid ones.
[11:45] <sil2100> wgrant: so during creation of the langpack packages we'll have to merge vivid and the overlay translations?
[11:47] <wgrant> sil2100: Unless we want to maintain the entire set of packages' translations in ubuntu-rtm/15.04, which is possible though somewhat onerous and awkward.
[11:47] <sil2100> wgrant: I would have to poke pitti if he's could do that when generating the overlay packages
[11:47] <sil2100> I'm a bit worried that translators might get also a bit confused too, with having to translate in two different places
[11:50] <sil2100> Two different places for one thing that is
[11:51] <sil2100> Ok, 14 is getting near, I was told there might be an internet outage then - don't be surprised if I drop off
[11:53] <ogra_> sil2100, so while we could loop over these files and touch them to get a proper timestamp, i'm not sure what that could break ... and indeed it would only be an interim workaround til jdstrand is back and can take a look at the cause
[11:55] <Mirv> \o/
[12:02] <sil2100> Well, either way I go for lunch now
[12:02] <sil2100> ogra_: let me get back to you after lunch
[12:02] <ogra_> yeah
[12:16] <Mirv> boiko: not top-approved branch https://code.launchpad.net/~tiagosh/telephony-service/use-libphonenumber/+merge/264906
[12:16] <boiko> Mirv: oups, my mistake, I approved but forgot the top approval, sorry, fixed now
[12:16] <Mirv> boiko: ok, thanks!
[12:18] <boiko> Mirv: it would be nice to have the not-approved branches to show a "needs review" or similar status on the dashboard
[12:22] <Mirv> boiko: ack, this is a repetitive thing that could be improved, filed bug #1483684 about it
[12:23] <boiko> Mirv: nice!
[12:24]  * jibel votes for this feature
[12:25] <jibel> It shouldn't be possible to mark something ready for QA that has not been top approved first
[13:48] <ogra_> jdstrand, are you back from vacation ? we see some weird behavior of apparmor_partser in the wily touch image builds
[13:49]  * ogra_ just saw uploads from you landing, you cant hide ;)
[13:54] <tyhicks> ogra_: what odd behavior are you seeing?
[13:55] <ogra_> tyhicks, http://paste.ubuntu.com/12054992/ ... (full image build log is at https://launchpadlibrarian.net/214158968/buildlog_ubuntu_wily_armhf_ubuntu-touch_BUILDING.txt.gz) ... see the timestamps
[13:55] <ogra_> i'm pretty sure the click packages are not older than me :)
[13:55] <tyhicks> :)
[13:56] <ogra_> http://paste.ubuntu.com/12055614/ is the script from the livecd-rootfs package that generates these files
[13:57] <tyhicks> thanks
[13:57] <tyhicks> we did upload apparmor 2.10 (new upstream release) last week
[13:57] <tyhicks> I'll see if we're doing anything differently with the policy timestamps in 2.10
[13:58] <ogra_> thanks ... i could easily work around it by simply have the script touch all files in that dir ... but finding the cause would be better :)
[13:58] <ogra_> (the timestamps make the diff tarball generation fall over on system-image)
[14:03] <slangasek> ogra_: ah, sorry, apparently that was staged locally
[14:03] <ogra_> slangasek, np ... all sorted
[14:05] <oSoMoN> ubuntu-qa: any realistic chance silo 54 can get validated today? its contents are scheduled for ota6, and there are other branches that go on top of this that I’d like to try and land later today, too…
[14:07] <jdstrand> ogra_: I am back from vacation
[14:07] <ogra_> :)
[14:07] <ogra_> jdstrand, tyler picked up the issue, thanks :)
[14:07] <jdstrand> ogra_: I'm not sure why the timestamps would be different (thanks tyhicks for checking what changed in 2.10)
[14:08] <jdstrand> ogra_: this is only on wily?
[14:08] <ogra_> jdstrand, yeah, it is weird, though we build in an onion model, there are 3 chroots wrapping each other ...
[14:08] <ogra_> yes, only wily
[14:09] <ogra_> sil2100 had more interesting timestamps yesterday ... dating from 1936 ... :)
[14:09] <davmor2> oSoMoN: there is a chance yes there are some silos ahead of it so I guess it depends how long they take
[14:09] <oSoMoN> davmor2, thanks, that’s good news :)
[14:40] <jibel> oSoMoN, it must be installed on top of 5?
[14:42] <oSoMoN> jibel, well, yes, because there will be merge conflicts with silo 5 (and I don’t want to put them all in one big silo, too risky, I’d rather have silo 5 land first)
[15:25] <john-mcaleely> sil2100, here's where that question belongs...
[15:29] <sil2100> john-mcaleely: let me check something
[15:30] <john-mcaleely> ack
[15:30] <ogra_> sil2100, FYI ... while you were away tyhicks showed up and is taking a look at the timestamp issue ... seemingly we got a new apparmor upstream a few days ago, so this coould be related
[15:30] <sil2100> Oh! We did? I checked wily-changes and didn't see anything recent
[15:31] <ogra_> on the 3rd
[15:31] <ogra_> not sure how long it stuck in proposed ...
[15:31] <pstolowski> davmor2, i've rebuilt some stuff in silo 27. also flashed my phone and installed it, no reboots
[15:31] <ogra_> wily is "dokos madhouse" so it could have well hung for a few days before migrating :)
[15:31] <pstolowski> davmor2, note, citrain tool did't install the latest versions from the silo, i had to install them manually
[15:34] <sil2100> john-mcaleely: sooo, a few useful links for you
[15:35] <sil2100> john-mcaleely: once you add your landing to bileto, you can then check if it got signed off here: https://requests.ci-train.ubuntu.com/#?q=john <- this shows all your landings submitted, and if a landing has 'QA Granted', this means it's good to go
[15:36] <sil2100> john-mcaleely: you can also use the public API to get info about all device tarball landings that got QA Granted  here:
[15:36] <sil2100> https://requests.ci-train.ubuntu.com/v1/tickets?description=device%20tarball&qa_signoff=QA%20Granted
[15:36] <sil2100> You can use that to maybe even make a small script that would inform you once a new one pops up there, as it's all nicely parsable json
[15:36] <john-mcaleely> aha, ok, makes sense
[15:37] <sil2100> Anyway, you're good to go :)
[15:37] <john-mcaleely> excellent
[15:38] <tyhicks> ogra_: I'm having trouble reproducing the timestamp issue locally but I see a suspect commit that I'll need to track down
[15:38] <ogra_> tyhicks, i think infinity wanted to try to repro it as well in chroots yesterday ... not sure where he got with that though
[15:39] <ogra_> perhaps he has some more info
[15:39] <tyhicks> ogra_: would all of the profiles that apparmor_parser is parsing have sane timestamps in that environment?
[15:40] <ogra_> well, they used to
[15:41] <tyhicks> it is the cache files (apparmor_parser output) that have the odd timestamps - I'm curious if the profiles (apparmor_parser input) have sane timestamps
[15:41] <ogra_> oh, that i dont know
[15:42] <ogra_> they should come from the respective click packages i guess
[15:42] <sil2100> The last apparmor seems to have happened on the 31th, but we had correct custom tarballs then
[15:42] <jdstrand> sil2100: when did custom tarballs start having bad timestamps?
[15:42] <sil2100> jdstrand: during the weekend, the first one was the nightly image on the 9th of August
[15:43] <tyhicks> 2.10 migrated from -proposed last tuesday, IIRC
[15:43] <ogra_> sil2100, not sure where you find that info about 31st ... https://launchpad.net/ubuntu/+source/apparmor/2.10-0ubuntu2 says it migrated on the 4th
[15:43] <tyhicks> let me double check
[15:43] <tyhicks> ah, thanks ogra_
[15:44] <john-mcaleely> sil2100, new krillin & vegeta tarballs pushed
[15:44] <sil2100> ogra_: ok, checked wrongly, but it anyway got uploaded on the 3rd to -proposed
[15:44] <jdstrand> what is the time on the server generating these at the time apparmor_parser runs?
[15:44] <sil2100> Still meaning it was running fine for almost a week
[15:44] <jdstrand> yes, this seems like an infrastructure issue to me
[15:45] <ogra_> hmm, so perhaps the store
[15:45] <sil2100> https://launchpadlibrarian.net/214030280/buildlog_ubuntu_wily_armhf_ubuntu-touch_BUILDING.txt.gz <- here's the build log, it says a correct date it seems and even ntpdate succeeded
[15:45] <ogra_> sil2100, and that did produce a good tarball ?
[15:46] <sil2100> No
[15:46] <sil2100> jdstrand: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/wily/ubuntu-touch/+build/34732 <- here's today's build with ogra_'s additional verbosity
[15:46] <sil2100> -rw------- 1 root root 182915 May  8  1959 click_com.ubuntu.developer.webapps.webapp-amazon_webapp-amazon_1.0.10 <- with fishy dates
[15:46] <ogra_> sil2100, so when did we get the first beoken one ?
[15:46] <sil2100> On the 9th
[15:46] <ogra_> *broken
[15:47] <ogra_> ok
[15:47] <tyhicks> did we have a good build between the 4th and the 9th?
[15:48] <sil2100> tyhicks: yes, we do daily builds, and all those before the 9th were good
[15:48] <sil2100> ogra_: btw. I see now why LP doesn't show the built files
[15:48] <ogra_> oh ?
[15:48] <sil2100> It seems it only shows that for the recent builds and cleans it for older
[15:48] <ogra_> ah !
[15:48] <tyhicks> sil2100: can you link to one of those builds, say, from the 7th so that we can see if apparmor 2.10-0ubuntu2 was used?
[15:48] <sil2100> tyhicks: let me check that
[15:49] <sil2100> https://launchpadlibrarian.net/213817480/buildlog_ubuntu_wily_armhf_ubuntu-touch_BUILDING.txt.gz <- this one was good for instance
[15:49] <jdstrand> Get:22 http://ftpmaster.internal/ubuntu/ wily/main libapparmor1 armhf 2.10-0ubuntu2 [26.4 kB]
[15:50] <ogra_> http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-touch/wily/daily-preinstalled-20150808.log from the 8th
[15:50] <ogra_> bah
[15:50] <ogra_> seems we dont mirror the livefs logs anymore :/
[15:51] <tyhicks> yeah, apparmor 2.10-0ubuntu2 was used in that successful build on the 7th
[15:51] <ogra_> right
[15:52] <jdstrand> 1959
[15:52] <jdstrand> how does ls output give a date before the epoch?
[15:52]  * tyhicks was confused about that too
[15:53] <tyhicks> you can't set a system date to that
[15:53] <balloons> cihelp, ping. Can I get generic-mediumtests-utopic removed from reminders-app-ci and reminders-app-ci-autolanding on core app jenkins?
[15:53] <psivaa> balloons: i'll take a look
[15:54] <jdstrand> I'm not sure what else to suggest at this point. apparmor 2.10 was seen to have produced valid cache files (I'm assuming that the ls output is for the cache files)
[15:54] <sil2100> jdstrand: I have no idea... the tarballs give warnings out when you try to extract them and the python tarfile just dies when trying to extract those
[15:55] <jdstrand> what are the timestamps on other files in the custom tarball?
[15:55] <jdstrand> what is the script that generates the custom tarball doing?
[15:55] <ogra_> jdstrand, but if it *produces* them how can the timestamps not be recent
[15:55] <jdstrand> did it change?
[15:55] <ogra_> jdstrand, no
[15:56] <ogra_> jdstrand, http://paste.ubuntu.com/12055614/
[15:56] <jdstrand> ogra_: perhaps something turned around and tried to adjust the timestamps?
[15:56] <ogra_> (i added the -v and the last ls -l line today)
[15:56] <jdstrand> (after the cache files were generated)
[15:57] <jhodapp> sil2100, can you please dput qtmultimedia from ppa:jhodapp/ubuntu/ppa to silo 48?
[15:57] <sil2100> jhodapp: sure :)
[15:57] <ogra_> jdstrand, no, see the log http://paste.ubuntu.com/12054992/
[15:57] <tyhicks> you can set a file timestamp to that date
[15:58] <ogra_> the ls -l runs directly after the cache generation
[15:58] <jhodapp> sil2100, thanks, need a new silo instead of silo 38 because it had a wily version of media-hub in it and assigned my vivid media-hub build a 4.0 version :(
[15:58] <ogra_> tyhicks, sure i could also just loop over the dir and touch the files ... the workaround is easy
[15:58] <ogra_> but i think we want to find the cause :)
[15:58] <tyhicks> right, that's not the point I was making
[15:58] <tyhicks> we said that you can't set a system date to 1959
[15:59] <tyhicks> but you can set the file timestamp to 1959
[15:59] <ogra_> ah
[15:59] <tyhicks> $ touch -mt 195905080000 foo
[15:59] <jdstrand> ogra_: can you add more debugging? eg, there is a cp -a. it would be good to see the timestamps for everyhing: /var/lib/apparmor/clicks/, /var/lib/apparmor/profiles/, /var/cache/apparmor/, /custom/cache/apparmor/, /custom/lib/apparmor/profiles/, etc
[16:00] <ogra_> sure, i can add a -v to the cp too
[16:00] <ogra_> and more ls -l's
[16:00] <sil2100> jhodapp: ok, copying now
[16:00] <jhodapp> awesome thanks sil2100
[16:01] <jdstrand> ogra_: also, this is only the script for the apparmor bits of the custom tarball generation. what of the other scripts?
[16:01] <sil2100> ogra_: debug all code o/ !
[16:01] <jdstrand> ogra_: can you add a 'date' at the top of the file too
[16:01] <ogra_> jdstrand, sure, i can add all debugging you want ... that script runs immediately after the clicks get installed, so there is nothing inbetween thogh
[16:02] <jdstrand> I was more concerned with after
[16:02] <ogra_> well, afterwards the only thing touching that dir is:
[16:02] <jdstrand> oh but the timestamps are already wrong
[16:03] <ogra_> if [ "$PROJECT" = "ubuntu-touch" ]; then
[16:03] <ogra_>         (cd "binary/$INITFS/custom.dir/" && tar -c *) | \
[16:03] <ogra_>                 gzip -9 --rsyncable > "$PREFIX.custom.tar.gz"
[16:03] <ogra_>         chmod 644 "$PREFIX.custom.tar.gz"
[16:03] <ogra_> fi
[16:03] <jdstrand> based on the ls you have
[16:03] <ogra_> so nothing that would alter the timestamps anymore
[16:03] <ogra_> right
[16:03] <jdstrand> right, but I was wrong anyway based on current debug output
[16:04] <ogra_> either the stamps in the click are wrong when we get them from the store and apparmor simply keeps them for the output files ... or apparmor itself mangles them to my uncles birth date :)
[16:04] <sil2100> I was scratching my head on that one the whole afternoon
[16:05] <josepht> balloons: your staging instance should be accessible again
[16:05] <jdstrand> well, or the system time is weird, or an fs issue
[16:05] <jhodapp> davmor2, as soon as silo 48 builds (had to move to there from silo 38 for a PPA version issue), it'll be ready for you to test (MRs are all approved now)
[16:05] <balloons> josepht, indeed. Thanks
[16:06] <ogra_> jdstrand, oh, and if you want the full log the apparmor snippet is from https://launchpadlibrarian.net/214158968/buildlog_ubuntu_wily_armhf_ubuntu-touch_BUILDING.txt.gz ... there are timestamps all around, the system time itself is surely correct
[16:06] <ogra_> (i only did the pastebin snippet to make it easier to read the apparmor specific bits)
[16:06] <jdstrand> ogra_: are we using bind mounts? (bug #1425704)
[16:07] <ogra_> jdstrand, not during builds, no
[16:07] <ogra_> at least not that i know :)
[16:07] <jdstrand> alright, I guess we'll have to wait for the debug output
[16:08] <jdstrand> ogra_: can you also: touch /custom/cache/apparmor/
[16:08] <jdstrand> ogra_: err
[16:08] <tyhicks> jdstrand: fyi, I already tested setting the profile atime, ctime, and mtime to 1980 and then generating a cache file - the resulting cache file is the current date
[16:08] <jdstrand> touch /custom/cache/apparmor/test-timestamp
[16:09] <ogra_> jdstrand, before or after generation ?
[16:09] <jdstrand> ogra_: let's do test-timestamp.before and test-timestamp.after
[16:09] <ogra_> k
[16:09] <jdstrand> so, both, with 2 files
[16:10] <jdstrand> ogra_: actually, since you're there, how about ls -lR /custom
[16:10] <ogra_> before and after ?
[16:10] <jdstrand> I think that is basically everything and the kitchen sink
[16:10] <ogra_> ok
[16:10] <jdstrand> heh, sure
[16:11] <jdstrand> since it takes awhile to see the output we might as well put as much in there as we can think of now
[16:11] <sil2100> ;p
[16:12] <sil2100> Let's remember to revert that afterwards
[16:12] <jdstrand> ogra_: not sure if you are using echos to say what is happening or set -x, but it would be easier to read to have one or the other
[16:12] <jdstrand> sil2100: oh yes, with the 'touch' commands we are creating a couple of empty files
[16:13] <ogra_> http://paste.ubuntu.com/12056352/
[16:13] <ogra_> jdstrand, ^^^
[16:13] <ogra_> anything else you want ?
[16:14] <jdstrand> ogra_: yes, ls -lR on /var/lib/apparmor and /var/cache apparmor before and after
[16:14] <ogra_> ok
[16:14] <jdstrand> ogra_: oh, and 'date' at the top
[16:14] <jdstrand> tyhicks: can you think of anything else?
[16:14] <jdstrand> ^
[16:15] <jdstrand> ogra_: actually, also the ls -lRs you have at the end would be good
[16:16] <ogra_> http://paste.ubuntu.com/12056367/
[16:16]  * tyhicks looks
[16:16] <jdstrand> to see if the cp in the loop did anything weird
[16:17] <ogra_> http://paste.ubuntu.com/12056377/
[16:17] <ogra_> our log will grow by 5MB :P
[16:18] <jdstrand> ogra_: just one more at the top: echo "date is: `date`"
[16:18] <ogra_> anything missing ? else i'll upload livecd-rootfs
[16:18] <ogra_> ok
[16:18] <jdstrand> unless tyhicks has something else
[16:18] <sil2100> ogra_, jdstrand, tyhicks: thanks guys ;)
[16:18] <tyhicks> jdstrand, ogra_: I think that's good
[16:20] <ogra_> ok,. uploading
[16:22] <ogra_> done ... now !patience :)
[16:22] <ogra_> sil2100, your deb-src chaneg is included in this upload btw (i had pushed it to the branch earlier already)
[16:24] <sil2100> YYaaaay
[16:24] <sil2100> ogra_: thanks :)
[16:36] <robru> good god every single silo is in use
[16:42] <sil2100> ugh
[16:42] <sil2100> robru: yeah, feature freeze for OTA-6 ;)
[16:42] <sil2100> slangasek: can we free up the gcc-5 silos already or are those still in use?
[16:44] <sil2100> dbarth: hey! You remember the oxide-qt gcc-5 rebuild we were doing in silo 26?
[16:44] <dbarth> sil2100: yes
[16:44] <dbarth> any issues?
[16:44] <robru> sil2100: I'll also write an email highlighting the stalest silos
[16:47] <davmor2> sil2100: robru: that's because the silos are being used as test playgrounds rather than landing pods, pretty sure we've had this discussion a lot ;)
[16:48] <robru> dbarth: we're out of silos, can you free it if you're not using it? ;-)
[16:51] <psivaa> balloons: reminders-app ci and autolanding should now be free of generic-mediumtests-utopic
[16:52] <seb128> hum
[16:52] <seb128> https://ci-train.ubuntu.com/job/prepare-silo/5726/console
[16:52] <seb128> what does that mean?
[16:53] <seb128> "FileNotFoundError: [Errno 2] No such file or directory: '/var/lib/jenkins/silos/ubuntu/landing-014/config'"
[16:54] <jhodapp> sil2100, silo 21 can be reclaimed...don't need it anymore
[16:54] <sil2100> jhodapp: oh, thanks :)
[16:55] <sil2100> dbarth: do you think we can just land that?
[16:55] <sil2100> dbarth: since it has built and was waiting
[16:57] <dbarth> sil2100: uh, i thought it was already landed; it doesn't show up on my dashboard anymore
[16:59] <dbarth> hmm, let me re-test realy quick then; but i will need some time to refresh my wily phone
[16:59] <seb128> bah
[16:59] <dbarth> sil2100: is there a good image rev. i should target specifically?
[16:59] <sil2100> dbarth: oh, I already released that :)
[16:59] <seb128> how are sync from wily to the vivid ppa declared in the requests.c-t.u.c?
[16:59] <sil2100> It was a no-change rebuild so should be safe
[17:00] <sil2100> seb128: using source syncs?
[17:00] <seb128> sil2100, yes
[17:00] <seb128> I've a feeling my l141 is boggus
[17:00] <sil2100> seb128: use the Sync Source field to mention the place you sync from and list the packages in the Manual Source Packages
[17:01] <sil2100> https://wiki.ubuntu.com/citrain/SyncSilos <- as per this, but without mentioning the package names next to the sync
[17:01] <sil2100> (need to update this for bileto)
[17:01] <seb128> sil2100, so 141 is correct?
[17:02] <sil2100> Let me check
[17:02] <seb128> also the ppa destination entry is confusing
[17:02] <seb128> like I usually try to copy the ppa:team/name info
[17:02] <seb128> but that doesn't work
[17:02] <sil2100> hm, looks fineish - that's  the one that's failin, right?
[17:02] <seb128> then the url, which doesn't work
[17:03] <seb128> well, it failed because I had the wrong ppa syntax I think
[17:03] <dbarth> sil2100: doing some quick sanity checks again on arale
[17:03] <seb128> the system just take anything without giving you any feedback on invalid syntax
[17:03] <dbarth> (that's all i have for vivid right now)
[17:03] <sil2100> dbarth: thanks
[17:03] <seb128> there must be a better way ;-)
[17:03] <sil2100> seb128: use the drop down there ;)
[17:04] <sil2100> seb128: I don't know the format too so I just click on the field and use the auto-complete there
[17:04] <sil2100> seb128: I assigned the silo for you
[17:04] <seb128> dropdown?
[17:04] <seb128> it's an entry
[17:04] <seb128> thanks
[17:04] <sil2100> You know, auto-correct
[17:04] <seb128> oh, I didn't even notice it was doing that
[17:04] <sil2100> Double click and you get a drop-down of propositions
[17:04] <sil2100> Yeah, not entirely obvious
[17:04] <seb128> whoever working on the ui needs to talk to a designer ;-)
[17:04] <seb128> also the "don't edit" entries
[17:04] <seb128> wth are you making entries if they shouldn't be used
[17:04] <sil2100> Well, we need to have a redesign at some point, but at least it works right now ;p
[17:05] <seb128> "work"
[17:05] <seb128> but yeah :-)
[17:05] <slangasek> sil2100: the gcc-5 silos can be freed I think, yes
[17:05] <seb128> sil2100, thanks!
[17:05] <sil2100> seb128: yw!
[17:06]  * ogra_ tickles the publisher 
[17:06] <seb128> sil2100, https://ci-train.ubuntu.com/job/ubuntu-landing-014-1-build/192/console ? :-(
[17:06] <ogra_> slow thing today :(
[17:06] <seb128> what's the issue?
[17:07]  * ogra_ waits for that livecd-rootfs upload to at least hit proposed
[17:11] <sil2100> slangasek: ok, cleaning the silos then
[17:18] <ogra_> sil2100, jdstrand, wily touch build kicked
[17:19] <jibel> oSoMoN, is 'find in page' supposed to work for bookmarks?
[17:19] <ogra_> for progress -> https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/wily/ubuntu-touch
[17:19] <oSoMoN> jibel, it’s supposed to work for all pages, including those that are bookmarked, if that’s your question
[17:21] <jibel> oSoMoN, I mean when you open a new tab, there is a list of bookmarks and there you can open the menu and select 'find in page'
[17:22] <jibel> oSoMoN, which doesn't work. But I suppose find in page shouldn't be displayed
[17:23] <oSoMoN> jibel, that’s a very good point
[17:23] <oSoMoN> this is something we never tested, good catch
[17:24] <oSoMoN> jibel, if that’s the only issue, would it be ok to go ahead with the landing provided we file a bug to track the issue and address it right away?
[17:24] <jibel> oSoMoN, it's the only minor issue I found. I propose to land it so we an export the new strings and land a fix later this week. what do you tinhk?
[17:24] <oSoMoN> great minds think alike :)
[17:24] <jibel> oSoMoN, okay, we agree :)
[17:26] <dbarth> sil2100: i miss libmedia-hub-client4, but i'm not sure of my install anymore
[17:26] <dbarth> :/
[17:26] <dbarth> i'll need to factory reset the phone, as usb is broken on that device
[17:29] <oSoMoN> trainguards: can you publish silo 54, please?
[17:29] <robru> sure
[17:33] <robru> seb128: syncing packages is only supported for packages that have train-controller version numbers, it doesn't work for any arbitrary package. you'll have to do a manual upload for that one
[17:33] <seb128> robru, k, thanks
[17:34] <robru> you're welcome
[17:41] <robru> jhodapp: what are you doing with silos 38 and 48? they have the same MPs, both targetting vivid+overlay, one is in the QA queue and one is building...
[17:42] <jhodapp> robru, after 48 builds, I won't need 38 anymore
[17:42] <jhodapp> robru, i don't need 21 anymore right now
[17:42] <robru> jhodapp: thanks
[17:42] <jhodapp> np
[17:43] <dbarth> sil2100. jhodapp: where do i find libmedia-hub-client4 for wily? i'm on devel-proposed
[17:44] <jhodapp> dbarth, you'll have to check with tvoss, he did the bump to gcc5 for media-hub
[17:44] <dbarth> that´s blocking oxide on a clean/fresh wily image
[17:44] <jibel> robru, jhodapp silo 25 failed in may and hasn't move since then. It's 'Ready for QA' because there was no state 'Failed QA' in the spreadsheet
[17:44] <dbarth> is tvoss around?
[17:44] <jhodapp> I think so
[17:44] <jhodapp> jibel, 24/25 can be freed
[17:45] <robru> oh goodie
[17:45] <jibel> card corresponding to this landing https://trello.com/c/oH2fuDqy/1695-ubuntu-landing-025-media-hub-jhodapp
[17:47] <sil2100> dbarth: it might be in -proposed
[17:47] <sil2100> dbarth: devel-proposed is outdated...
[17:47] <sil2100> dbarth: there is a specific gcc-5 channel set up with wily images
[17:47] <dbarth> uh
[17:47]  * jhodapp bbiab
[17:47] <sil2100> dbarth: ubuntu-touch/devel-proposed-g++5/ubuntu
[17:47] <dbarth> ah
[17:47] <dbarth> thanks
[17:48] <sil2100> dbarth: thanks for testing :)!
[17:49] <dbarth> it's doing something, so i guess it's upgrading; may take a while; i'll report back later
[17:52] <robru> great, 11 free silos with another on the way
[17:54] <tvoss> dbarth, yup
[17:54] <tvoss> dbarth, what's the issue?
[18:03] <dbarth> tvoss: find libmedia-hub-client4
[18:03] <dbarth> but sil2100 told me where to find it
[18:04] <dbarth> unfortunately, now ssh dies after 10s on that device :/
[18:04] <dbarth> or the network link
[18:04] <tvoss> dbarth, ah okay
[18:04] <tvoss> dbarth, need anything from my side?
[18:05] <dbarth> tvoss: i hope not anymore :) thanks
[18:06] <tvoss> dbarth, I'll be around for a bit, just give me a ping
[18:06] <dbarth> ok
[18:06] <dbarth> need to reboot this vm
[18:11] <oSoMoN> jibel, I filed bug #1483847 to track the issue you found with find in page, nerochiaro will be working on a fix this week
[18:26] <infinity> ogra_: Hahaha.  Your stamps time-travelled to the future this time.
[18:26] <ogra_> lol, lovely
[18:27] <ogra_> sigh, but it didnt use the livecd-rootfs it was supposed to use
[18:27] <infinity> ogra_: Was it in the release pocket?
[18:27] <ogra_> i made sure rmadison showed it in proposed when hitting "build" ...
[18:28] <ogra_> no, wiily uses proposed
[18:28] <ogra_> on touch at least
[18:28] <infinity> Oh, the build used proposed.
[18:28] <ogra_> but seems i was to quick or rmadison lied
[18:28]  * ogra_ re-starts a new build
[18:29] <infinity> It's literally impossible for something to show in rmadison but not be on ftpmaster (and, thus, not in a build).
[18:29] <infinity> Maybe you just dyslexified 6 and 8?
[18:30] <ogra_> i looked for -proposed ;)
[18:31] <ogra_> would be interesting to know if this is an armhf-only issue, to bad i386 doesnt build at all :/
[18:32] <infinity> ogra_: If it's armhf-only, I would guess only by chance.
[18:32] <infinity> ogra_: As in, whatever it is, I'm sure it's buggy code, but it could be one of those "$arch makes the bug more obvious for reason $x" things.
[18:33] <ogra_> yeah
[18:33] <infinity> Like bad char/int handling, for instance.
[18:34] <infinity> Which it may well be.
[18:34] <infinity> Given the signed/unsignd char thing.
[18:34] <infinity> And those dates in the distant past would be easily represented by accidental negatives.
[18:34] <ogra_> well, it is either apparmor or the click store ...
[18:34] <infinity> (negative UNIX timestamps do exactly what you'd expect)
[18:35] <ogra_> i think it is pretty unlikely it is the environment or some such
[18:35] <infinity> No, it's software.
[18:35] <infinity> It's probably been buggy forever, but if it had a chance at past or future stamps, we might have just been getting lucky and getting future ones before.
[18:35] <infinity> Which no one would have noticed.
[18:36] <infinity> Cause tar complains about future stamps, but nothing will error.
[18:36] <ogra_> hmm, the builder is arm64 running arm32, right ?
[18:36] <infinity> Nope.
[18:36] <infinity> armv7.
[18:36] <infinity> Highbanks.
[18:36] <ogra_> ah, i thought the HW was 64 ...
[18:37] <infinity> That'll change soon, but hasn't yet.  These are the same buildds we've been using since just after precise.
[18:37] <ogra_> yeah
[18:37] <infinity> Best 25k of someone else's money I've ever spent, IMO.
[18:37] <ogra_> heh
[18:38] <ogra_> didnt save the company though
[18:38] <ogra_> but hey, at keast i got a rare t-shirt now :)
[18:38] <sil2100> ogra_: so another build will be required to get the new debugging? ;)
[18:38] <ogra_> *least
[18:38] <ogra_> sil2100, already running
[18:38] <sil2100> ACK ;)
[18:40] <dbarth> sil2100: well, there are some bugs with cordova but not related to oxide itself, still trying to have CTR installed (without ssh support :/)
[18:40] <jdstrand> ogra_: fyi, https://launchpadlibrarian.net/214187360/buildlog_ubuntu_wily_armhf_ubuntu-touch_BUILDING.txt.gz is new but doesn't have the debugging changes
[18:40] <dbarth> sil2100: but i feel like this could land, ie the browser/youtube do work and i see no rendering or obvious regressions elsewhere
[18:40] <jdstrand> ogra_: interestingly, it has timestamps of 2024 instead of 1959
[18:40] <ogra_> jdstrand, yes, see backlog ... apparently i was to fast
[18:41] <jdstrand> ok
[18:41] <jdstrand> tyhicks: fyi ^
[18:41] <ogra_> jdstrand, infinity has an interesting theory about signed/unsigned ints and timestamps being negative and all :)
[18:41] <infinity> jdstrand: It definitely reeks of bad int handling, but why would apparmor be writing its own timestamps in the first place?  Doesn't trust the filesystem to do it?
[18:42] <jdstrand> infinity: I had the same questions
[18:42] <infinity> jdstrand: Cause looking at everything else in the tarball (ie: all the files that are just copied), the filesystem is behaving fine.
[18:52] <bregma> trainguards, my silo 43 is languishing in -proposed and may do so for some time yet (gcc-5 blockificationage) but I do not forsee any further changes to it, would it be kosher to go ahead and publish and clean (or whatever the final procedure is)?
[18:52] <robru> bregma: yeah no worries
[18:52] <bregma> I don;t want to unnecessarily hog a silo, and I have follow-on landings to get started through the process
[18:52] <robru> bregma: you can do that yourself, just click 'Clean' and check FORCE
[18:53] <bregma> robru, just the one step?
[18:53] <robru> bregma: well click 'Clean' in dashboard, click FORCE, then click 'Build' button, so really 3 clicks to make it happen
[18:54] <robru> bregma: but yeah, it will skip the check that says "this didn't land yet" and then do the merge, and free the silo
[18:54] <bregma> that's just one step with 3 parts to it...  this is going to make my day
[18:54] <robru> heh
[18:56] <jhodapp> robru, silo 38 can be freed up now
[18:57]  * bregma likes a dirty silo
[18:57]  * ogra_ hands bregma mop and bucket
[18:59] <robru> jhodapp: thanks
[18:59] <jhodapp> np
[19:05] <tyhicks> infinity, jdstrand: apparmor_parser sets its own timestamps on the cache files that it generates in order to know when to consider those cache files as stale
[19:06] <tyhicks> infinity, jdstrand: the cache file's mtime is set to the newest mtime seen while processing all of the profile and abstraction files used to compile the cache file
[19:07] <infinity> tyhicks: Okay, so if you're setting your own timestamps, odds are you've got a bad char->int conversion going on somewhere.
[19:07] <infinity> tyhicks: ie: using a char where you should have used an int.
[19:07] <dbarth> sil2100 or robru: silo26/oxide in -proposed can go ahead, i re-did some sanity checks earlier, if you missed it
[19:07] <infinity> tyhicks: That's my guess just from the symptoms, anyway.
[19:08] <tyhicks> infinity: a possibility for sure - I'll look over the tstamp handling code while we're waiting for the debugging build output
[19:08] <infinity> tyhicks: This looks like the sort of thing that might want a testsuite to validate it's working as designed. ;)
[19:09] <robru> dbarth: what do you mean by "go ahead"?
[19:09] <robru> dbarth: you mean you want the branches merged?
[19:11] <tyhicks> infinity: agreed - I don't see any tests for this
[19:11] <tyhicks> uhhh
[19:12] <tyhicks> I think I found the problem
[19:12] <ogra_> yay
[19:14] <tyhicks> http://bazaar.launchpad.net/~apparmor-dev/apparmor/master/view/head:/parser/policy_cache.c#L169
[19:14] <tyhicks> utimes(2) is being used to set the cache file timestamp
[19:14] <tyhicks> from the man page:
[19:14] <tyhicks> "times[0]  specifies  the  new  access  time, and times[1] specifies the new modification time."
[19:15] <tyhicks> passing an array of one times element probably doesn't do what was intended there :)
[19:15] <ogra_> haha, yeah
[19:16] <tyhicks> infinity, jdstrand: ^
[19:16] <tyhicks> though I wonder why I can't reproduce that bug
[19:17] <dbarth> robru: there are no branches, just free the package in -proposed and/or free the accompanying silo
[19:17] <robru> dbarth: free the package in proposed? you mean remove it from proposed so it doesn't land in distro?
[19:18] <dbarth> robru: no, it *can* land ;)
[19:18] <dbarth> ie, this is the same 1.8.4 update, and we were just fearing some compiler hiccups, but the build is ok
[19:18] <robru> dbarth: ok well it's stuck on boottest, will need somebody to look at that
[19:18] <dbarth> ah, what's the link to that?
[19:18] <robru> cihelp: can somebody investigate this boottest? http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#oxide-qt might need to retry, thanks
[19:19] <robru> dbarth: ^
[19:20] <dbarth> yup, but nothing in the logs i could decipher
[19:20] <jdstrand> tyhicks: oh, huh. interesting that ever worked. that is new in 2.10?
[19:22] <robru> cihelp: yeah this is really weird and wrong: https://jenkins.qa.ubuntu.com/job/wily-boottest-oxide-qt/lastBuild/console
[19:22] <fginther> robru, I've retrigered it. The device it was running on was taken offline, I'll have to retrigger a couple of more builds too.
[19:22] <robru> fginther: ah ok, thanks
[19:22] <tyhicks> jdstrand: yes, the patch hit trunk on Jun 6
[19:23] <ogra_> sil2100, ^^ issue found (but at least we have *really* informative image build logs now :) )
[19:24] <infinity> tyhicks: If I had to guess as to why it "works" on some arches sometimes, I'd bet your pointed to your non-array is evaluating to zero, and just setting all the times to now().
[19:24] <infinity> s/pointed/pointer/
[19:25] <infinity> tyhicks: It's more curious why it explodes so spectacularly on armhf, but fixing it to actually by an array does seem like it'd do the job.
[19:25] <tyhicks> infinity: I think so too
[19:26] <tyhicks> but I'm not sure that the author of that bit of code meant to set atime
[19:26] <tyhicks> I'll figure that out and get a fix out
[19:26] <ogra_> infinity, well, that cache hackery we do on touch is very special ... if the cache files would just be wrong and land in an image (without the re-packing of the tarball the system-image server does) you wouldnt even notice
[19:26] <ogra_> they would just get re-generated on boot
[19:27] <ogra_> so i doubt you would really notice it on anything but touch
[19:27] <infinity> tyhicks: Setting atime and mtime to the same thing seems like it would do what you're after if it's about stale caches.
[19:28] <infinity> ogra_: Oh, I think only touch directly explodes because of it, but tyhicks was implying he can't reproduce on x86 either, which I think is just pure luck.
[19:28] <tyhicks> infinity: yeah, I can't think how setting atime would negatively mess with the cache design
[19:28] <infinity> Feeding bad input to utimes could certainly evaluate in a way that it would interpret as "set all the times to now".
[19:29] <infinity> Still super curious how it's evaluating to "set the times to prehistoric" on ARM, mind you.
[19:29] <infinity> But also not deep with the caring, if we can fix it and validate it s.
[19:34] <tyhicks> heh
[19:35] <tyhicks> utimes() is actually failing because the second element is gibberish and setting errno to EINVAL (undocumented in the man page)
[19:35] <infinity> tyhicks: Anyhow, thanks from the bottom of my heart for not taking the usual knee-jerk "blame the builders" approach and actually reading your own code. ;)
[19:35] <tyhicks> the return value is incorrectly being ignored so the failing isn't detected
[19:36] <tyhicks> infinity: any time :)
[19:38] <tyhicks> it just so happens that on armhf, the gibberish is sometimes valid gibberish and results in a bad timestamp
[19:38] <tyhicks> (could happen on any arch0
[20:26] <kgunn> slangasek: am i reading this right? https://requests.ci-train.ubuntu.com/static/dashboard.html#?q=ubuntu%2Flanding-035
[20:27] <kgunn> unity-api should flow thru to wily like any minute.... (and unity8 already did)
[20:33] <slangasek> kgunn: hmm, which part are you looking at?  All I see there is that it's in proposed
[20:34] <kgunn> slangasek: i was just looking at the excuses for it
[20:34] <slangasek> kgunn: ok. clicking through to http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#unity-api shows it's a "valid candidate" but that just means it doesn't have any blockers itself... it still has to go through installability checks after that
[20:34] <kgunn> ah
[20:35] <kgunn> slangasek: but i noticed unity8 isn't listed there as "in proposed" either and it's not in excuses (based on grepping)
[20:35] <kgunn> so it's actually released...
[20:36] <slangasek> ah; correct.  did unity8 not have dependencies on any packages with C++ ABI changes?
[20:36] <slangasek> we didn't add any artificial blocks for phone packages, so if unity8 was installable and passed its tests, it was let through
[20:37] <slangasek> kgunn: I do see on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt that unity-api was also accepted now, however
[20:37] <slangasek> so yes, both packages are in wily
[20:38] <kgunn> sweet!
[20:56] <robru> fginther: thanks for the retry, looks good now
[21:27] <josepht> dobey: what are your thoughts on this MP?  We're thinking we may be able to use some of it for our work but don't want to use something that hasn't got a chance of being merged.  The addmergeignore bits won't be needed.
[21:27] <josepht> dobey: https://code.launchpad.net/~didrocks/tarmac/jenkins-plugins/+merge/83163
[21:30] <dobey> josepht: well, it's a plug-in, which is good. i just did a quick skim, and didn't read the code, but i'm guessing that dealing with jenkins is going to turn out roughly the same, no matter how youw write it
[21:32] <josepht> dobey: okay, thanks for looking.