/srv/irclogs.ubuntu.com/2013/11/21/#ubuntu-ci-eng.txt

plarslooks like devices are back up now, restarting everything on the latest build00:07
plars27 looks to have some bad problems03:04
rsalvetiplars: still around?04:47
plarsrsalveti: yep04:47
rsalvetiplars: just replied your email, can you get your /proc/last_kmsg?04:48
rsalvetiafter a crash/reboot04:48
plarsrsalveti: yes, looking now04:48
plarsI always forget about that!04:48
rsalvetiyeah, it's quite useful04:48
plarsrsalveti: http://paste.ubuntu.com/6451729/04:49
rsalveti[20678.650539] mdm_power_down_common: MDM2AP_STATUS never went low. Doing a hard reset04:49
plarswlan stuff it seems04:50
rsalvetihttps://android.googlesource.com/kernel/msm/+/3ab322a9e0a419e7f378770c9edebca17821bf6e/arch/arm/mach-msm/mdm2.c04:54
rsalvetiplars: modem driver04:54
plarshttp://forum.xda-developers.com/showthread.php?p=4491854004:55
rsalvetinow why the hell it's powering it down04:56
rsalvetiinteresting, but the fix in there is not related with the kernel04:57
plarsyeah, doesn't look plausible04:58
rsalvetilast time we had a kernel upload was at 10-1804:58
rsalvetiso wonder how this could be specific to 2704:58
rsalvetido you know if that's the same error you're getting with the devices from the lab?04:59
rsalvetiyou also got a few errors in the wlan driver05:00
rsalvetiwonder if the modem shutdown is just a consequence of another failure05:00
rsalvetiwe can investigate a bit more tomorrow, but let me know if you're getting different failures in the lab05:04
rsalvetilater!05:04
plarsrsalveti: same error in the lab05:13
Mirvmorning05:22
=== psivaa changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: psivaa | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: Some services are down (1SS move), network slowness
* didrocks uses this time for exercising (missed yesterday and tuesday: 3 days with sitting for more than 14 hours isn't good for your health)09:23
didrockswill make a longer tour then, 1h3009:23
didrocksasac: just in time for our meeting I guess ^09:23
asacdidrocks: sounds good... ttyt09:38
Mirvcihelp please investigate "misc stack is already running" http://q-jenkins.ubuntu-ci:8080/view/cu2d/view/Head/view/All/job/cu2d-build_all-head/281/console - and still happening, preventing builds from happening10:13
Mirvso it's not there visibly running at least anywhere10:13
psivaaMirv: ack will do10:13
Mirvpsivaa: thanks, and sorry I forget to check the topic whether it's ci_help or some person at the moment10:14
psivaaMirv: np, will do after a meeting10:15
=== vrruiz_ is now known as rvr
=== MacSlow is now known as MacSlow|lunch
psivaaMirv: just to give you an update.. there are some old files that needs clearing up to solve the issue. Will do that once the US side comes online12:07
* retoaded wants to let everyone know that some hardware replacement work is getting ready to start on the public jenkins server. While the work is happening the public instance will be unavailable. This is https://jenkins.qa.ubuntu.com12:34
=== alan_g is now known as alan_g|lunch
=== cjohnston changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cjohnston | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: Some services are down (1SS move), network slowness, work on public Jenkins
=== MacSlow|lunch is now known as MacSlow
psivaaogra_: http://pastebin.ubuntu.com/6453240/ is the dmesg during the failed network setup stage13:29
ogra_well, there is an OOPS13:30
ogra_hmm, actually only a warning13:30
=== alan_g|lunch is now known as alan_g
* retoaded announces that the public jenkins instance is back up and operational. And it seems to perform significantly better. Just check https://jenkins.qa.ubuntu.com/view/All/ if you want to get an idea of how much more responsive it is now.13:46
=== cjohnston changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cjohnston | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: Some services are down (1SS move), network slowness
fginthercyphermox, jibel, can one of you re-review https://code.launchpad.net/~fginther/cupstream2distro-config/update-stack_status/+merge/19595614:09
rsalvetiplars: happy birthday!14:22
plarsrsalveti: thanks :)14:22
ogra_plars, happy b-day !!!14:23
rsalvetiplars: talking about the last_kmsg from the other devices, besides the modem shutdown message, do you know if the rest is also similar?14:25
rsalvetiI wonder if this is actually a wifi bug14:25
rsalvetiwe got a change in wpa from cyphermox a few days ago, but not sure if that would cause any issue14:25
ogra_rsalveti, psivaa noted networking issues too in the utah tests ... though seems thats more affecting maguro14:25
ogra_rsalveti, i was wondering if the new udev has a new way of loading firmware so that our overrides stop working14:26
plarsrsalveti: I've seen this for sure on two devices - the mako in the lab that runs the image smoke tests, and the one sitting right next to me. They both had the same error14:26
rsalvetiogra_: right, would be nice to know the issue with maguro, to see if it's related in some way14:29
rsalvetiogra_: afaik it's using the same upstream base version, it was just a merge with debian14:30
ogra_rsalveti, http://pastebin.ubuntu.com/6453240/ there is a warning OOPS, but nothing else intresting14:30
rsalvetiwe could have issues, sure, but at least we didn't get a major version update14:30
rsalvetiplars: interesting14:30
ogra_i think it pumped a bunch of debian versions at least14:30
ogra_*bumped14:30
rsalvetitoo bad I can't reproduce it here, let me reflash from scratch14:30
ogra_5 debian revisionas actually14:31
rsalvetiI think that warning is happening at every boot14:31
rsalvetiogra_: right, but no major upstream version update, right?14:31
ogra_rsalveti, well ... https://launchpad.net/ubuntu/+source/systemd/204-5ubuntu1 thats quite a changelog14:33
rsalvetiyeah hehe14:36
=== alan_g is now known as alan_g|tea
=== alan_g|tea is now known as alan_g
sergiusensrsalveti, the only thing uploaded that was relevant to my eyes was wpa_supplicant15:50
ogra_when was that uploaded ?15:50
sergiusensogra_, on you changes 1915:51
ogra_i didnt see it in any of the changes files since image 2215:51
ogra_oh, wow15:51
ogra_how could i miss that15:51
ogra_    deinitialize the P2P context when the management interface gets removed for15:51
ogra_    whatever reason, such as a suspend/resume cycle. (LP: #1210785)15:51
ubot5Launchpad bug 1210785 in wpa (Ubuntu Saucy) "wpa_supplicant crashed with SIGSEGV" [High,In progress] https://launchpad.net/bugs/121078515:51
ogra_thats the change15:52
sergiusensplars, happy bday, here's your small token of appreciation https://code.launchpad.net/~sergiusens/phablet-tools/recovery_check/+merge/19610215:52
rsalvetisergiusens: yeah, as I said before, cyphermox's changes :-)15:52
rsalvetilet me review that one now as well15:53
plarssergiusens: cool, give me a sec and I'll take a look15:53
rsalvetiwhere is the broken recovery :-)15:53
sergiusensrsalveti, was it image 23?15:53
sergiusensor 2215:53
rsalveti25 iirc15:53
sergiusensjust phablet flash with that branch ad --revision 25 then15:54
sergiusensshould eventually timeout15:54
doanac`sergiusens: as per that MP. does the .shell method detect errors?16:00
doanac`usually you have to do that ADB_RC type hack16:00
=== doanac` changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: doanac | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: Some services are down (1SS move), network slowness
doanac`added a note to the MP. with what i *think* is needed. not verified though16:03
sergiusensdoanac`, it doesn't; if it did, I would need to add an exception catch to the loop16:07
sergiusensdoanac`, as it's polling adb 'run something' when it may not be avail16:07
doanac`sergiusens: okay. i see how it works now. /me sucks at reading diffs16:09
sergiusensdoanac`, the diff isn't that easy to read16:09
sergiusensdoanac`, either way, your proposal is still valid16:09
sergiusensbut I'd need to catch it every loop16:10
doanac`the less we use the "ignore_errors=False" the better16:10
sergiusensdoanac`, too hacky?16:10
doanac`sergiusens: it always feels that way to me. but then again, we have some amount of code that probably has no idea its ignoring errors16:12
cyphermoxrsalveti: ogra_: I very very strongly doubt this wpa change would break your stuff, whatever it is16:18
cyphermoxrsalveti: if something's broke, file a bug so I can take a look, please16:19
cyphermoxwhat the oops ogra_ posted before looks like it more an issue with bringing up the device at all, that's driver level stuff16:20
cyphermoxthere was a message about writing the mac address, which happens long before wpasupplicant gets stsarted16:20
rsalveticyphermox: the oops is not an issue, the problem seems to happen with mako16:22
rsalvetithe device is rebooting now from time to time16:22
cyphermoxso how would this be related to wpa?16:22
rsalveticyphermox: http://paste.ubuntu.com/6451729/16:22
rsalvetibecause it seems the wireless driver is causing the crash16:23
rsalvetithe last message, which causes the reboot, is just the modem doing shutdown16:23
rsalvetibut not the issue itself16:23
cyphermoxI see nothing there that points to wifi being broken16:24
cyphermoxif you feel like it, downgrade wpa, but then there's still a bug that really needs to be fixed in that commit16:25
cyphermoxI mean, downgrade as a test, not in the distro16:25
rsalveticyphermox: right, no clue exactly to what is happening, all we know is that we got a bunch of messages related with the mako's wifi driver16:25
cyphermoxright16:25
cyphermoxbut those are all just info, not errors16:25
rsalvetiplars: which image was the last one we know that was working fine?16:26
cyphermoxon the contrary, it tells me that wifi should have properly disconnected16:26
rsalvetiright16:26
plarsrsalveti: looking at http://reports.qa.ubuntu.com/smokeng/trusty/touch/ 23 and 24 looked pretty good. iirc 24 didn't get a lot of reruns because of timing so it might have done slightly better with a little love16:27
plarsrsalveti: but then we had this adb issue in the lab, and the image 25 stuff, and devices were down for most of yesterday16:28
plarsrsalveti: so 26 didn't happen before 27 came out16:28
rsalvetiplars: can we give 26 a try/run?16:30
rsalvetinot sure how hard would be that16:30
rsalvetiso at least for this issue specifically we believe it's something between 24-2716:30
plarsrsalveti: we're not well set up for it, but I'm sure we could pull it off somehow. The other problem is that psivaa isn't seeing the issue happen this morning, and even last night it was pretty random for me. I saw it lots of times within minutes of boot both at home and in the lab, then my phone at home was up for a long time with no crash (it's been up for 13 hours now)16:33
plarsrsalveti: so I don't think we have a deterministic test for it at the moment16:34
rsalvetiplars: heisenbug?16:34
rsalveti:-)16:34
plarsrsalveti: seems so, yes16:35
plarsrsalveti: but at least I had logs with proof that something bad was going on - from 2 different makos even16:35
rsalvetiyeah16:35
cyphermoxfginther: think we're good for just about everything soon to update all the jobs and all of that17:40
fginthercyphermox, thanks, when that MP is merged, can you deploy the updates?17:42
cyphermoxfginther: once your cupstream2distro-config branch gets merged I'll deploy everything, yeah17:42
cyphermoxI already disabled all the build_all jobs to avoid it starting in 20 min17:42
didrockscyphermox: you need to redeploy saucy as well :)17:44
cyphermoxyep17:49
fginthercyphermox, the MP is merged now17:55
dobeyfginther: hey. quick question about the PPA usage for upstream merger 2.0. what's the specific reasoning behind using dput directly instead of using recipes there?17:59
cjwatsonrecipes have a cap on how many builds per day you get18:02
cjwatsonI wouldn't advise using them for this18:02
fgintherdobey, mainly because that is what our tools currently do, is there advantages to using recipes?18:02
dobeycjwatson: it depends on exactly what the goals of the PPA builds are18:04
dobeyfginther: i'm just curious because tarmac already has existing support for triggering recipe builds on launchpad, after the successful merger of branches in a target18:04
fgintherthe goal is to create a builds of MPs to be tested18:05
=== plars changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: plars | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: Some services are down (1SS move), network slowness
fgintherso prior to merging to trunk18:05
dobeyfginther: so the "custom rotated PPAs for testing MPs" part of the CI Airline stuff?18:06
fgintherdobey, right, they are just build slaves18:06
dobeyyeah, recipes would be problematic to use for that18:07
dobeyi didn't realize it was for that purpose. i thought it was for the post-merge builds into the daily PPA, as upstream merger is doing currently18:08
dobeywasn't clear in the session :)18:08
=== alan_g is now known as alan_g|EOD
fgintherdobey, sorry about that, thanks for the question though, there may be a use case for that functionality18:10
cyphermoxfginther: didrocks: deploying head now18:10
didrocks\o/ deploying THE head please! ;)18:10
fginthercyphermox, thank18:10
cyphermoxalright didrocks. deploying TEH head.18:11
didrocks;)18:11
fgintherdobey, upstream merger does dput sources on merge of specific projects, a recipe might be a better way to handle this in the future18:12
fgintherthese dputs are based on specific needs of the project owners, recipe might give them more control over that18:12
dobeyfginther: right. we're using recipes extensively with the u1 tarmac setup18:12
cyphermoxdobey: depends if you mean launchpad recipes or bzr builder recipes, I guess.18:13
dobeycyphermox: they are the same thing, but i mean recipes hosted on launchpad of course :)18:15
cyphermoxwell, you could get the best of both worlds and use bzr builder recipes, but just dput the built source package after..18:15
cjwatsonI'd still caution against it for anything that might be high-volume for a single recipe.  you might not be running into that with tarmac right now, but ...18:15
cjwatson(the limit is IIRC five a day, and if we wanted to unhardcode that we'd need to very carefully consider the impact on the build farm as some users abuse recipes to the maximum extent possible and our build farm is already oversubscribed)18:16
cyphermoxdidrocks: fginther: deploying TEH sauce now.18:17
fginthercjwatson, noted18:18
didrocks!18:24
cyphermoxsaucy done..18:26
didrockssweet!18:27
cyphermoxso you're saying not to bother with raring?18:28
fginthercyphermox, we should be ok to start a build18:29
cyphermoxyup, thatś the next step, I'll start QA now18:30
fgintherdoh~18:31
fgintherdoh!18:31
fgintherfixing18:31
fginthercyphermox, https://code.launchpad.net/~fginther/cupstream2distro/fix-missing-paren/+merge/19618018:34
cyphermoxfginther: so since I mentioned a symlink before, and all the paths are supposed to be up to date, if you added a symlink it would be best to remove it, to avoid keeping old crap working by chance18:35
fginthercyphermox, there is no symlink at the moment, I'm also going to hide the old /var/lib/jenkins18:36
cyphermoxok18:37
cyphermoxat least I don't need to redeploy everything for this fix :)18:37
fginthercyphermox, :-), just waiting for the MP to merge18:38
fginthercyphermox, is lp:cupstream2distro merged by hand?18:40
cyphermoxno, it should also be under ci... didrocks?18:41
fginthercyphermox, ack, I'll merge then18:42
didrockscyphermox: it's by hand IIRC18:42
cyphermoxoh ok18:42
fginthercyphermox, ready again18:44
cyphermoxok18:45
cyphermoxwell, crap.18:47
cyphermoxBuilding on master in workspace /iSCSI/jenkins/jobs/cu2d-qa-head/workspace18:47
cyphermox[workspace] $ /bin/bash -eu /tmp/hudson3259210953020072847.sh18:47
cyphermoxonly one instance of a stack can be queued for building18:47
cyphermoxnot sure what to do with this18:48
fginthercyphermox, are these just stale files?18:48
cyphermoxno idea18:49
cyphermoxhttp://q-jenkins.ubuntu-ci:8080/view/cu2d/view/Head/view/QA/job/cu2d-qa-head/435/console18:49
cyphermoxoh wait18:49
cyphermoxyeah just stale files18:49
cyphermoxI don't have access to remove them though18:50
fgintheris it safe to remove ALL the stack.status files (I can do that)?18:50
cyphermoxsee /iSCSI/jenkins/cu2d/work/head/qa18:50
fgintherI'll remove that first18:50
cyphermoxbtw (pending - daily-release-executor is offline )18:52
fginthercyphermox, ugh18:52
dobeycjwatson: i'm not sure what the limit for recipe builds is, but it is per-user, and i'm sure we could get an increase in the limit for the necessary bots, if needed. tarmac also works on multiple MPs before triggering the recipe, not single MPs one-at-a-time as j-l-p currently does18:53
cjwatsondobey: like I say, it's five a day and there is no provision right now for any kind of configurability18:56
cjwatson    def isOverQuota(self, requester, distroseries):18:56
cjwatson        """See `ISourcePackageRecipe`."""18:56
cjwatson        return SourcePackageRecipeBuild.getRecentBuilds(18:56
cjwatson            requester, self, distroseries).count() >= 518:56
cjwatsonrecipes aren't really meant for this kind of use case AIUI, but you'd have to talk to a real LP developer rather than a stunt one :-)18:57
cjwatson(i.e. that's per[C per-requester per-recipe per-series)18:58
cjwatsonmodulo lag18:58
dobeyright18:59
dobeyit's also something we could improve in launhpad itself, as well19:00
cjwatsonmaybe, though as I say there are other considerations and dput should be perfectly functional already19:02
cjwatsonwithout any of these limitations19:02
cjwatsonone great thing about it being hardcoded is that there's no temptation for admins to allow 10 chromium recipe builds a day if somebody is really annoying about it :-)19:02
cyphermoxahah :)19:04
dobeycjwatson: and yet, it's also easy enough to work around and build chromium 10 times a day :)19:05
cjwatsontrue, though there were many and various reasons why I put effort this year into making build cancellation reliable :-)19:06
cjwatsonit's much more of a pain to deal with when recipes are generating the builds as you're trying to get queues clear enough for other people's builds to happen19:06
cjwatsonbut shrug19:06
fginthercyphermox, \o/ daily-release-executor is online19:06
cyphermoxyay19:07
cyphermoxthinks look pretty good so far19:09
=== bfiller is now known as bfiller_afk
fginthercyphermox, http://q-jenkins.ubuntu-ci:8080/job/cu2d-qa-head-1.1prepare-autopilot-gtk/418/console19:12
cyphermoxfginther:19:14
cyphermoxdpkg-source: error: can't build with source format '3.0 (native)': native package version may not have a revision19:14
cyphermoxdpkg-buildpackage: error: dpkg-source -b autopilot-gtk-1.4+14.04.20131121 gave error exit status 25519:14
cyphermoxdebuild: fatal error at line 1361:19:14
cyphermoxdpkg-buildpackage -rfakeroot -d -us -uc -v1.4+14.04.20131106.1-0ubuntu1 -S failed19:14
cyphermoxbzr: ERROR: The build failed.19:14
cyphermoxI don't think that's your fault19:14
fginthercyphermox, what about the "prepare-package", line 193, traceback?19:15
fgintherwas that caused by the bzr failure?19:15
cyphermoxafaik yes19:16
cjwatsonyou need pristine-tar information in the branch so that bzr-build{er,deb} can reconstruct an .orig.tar.gz19:16
cjwatsondpkg-source got stricter about this in trusty19:16
cjwatsoni.e. if you declare 3.0 (quilt) it actually wants this to be possible and won't just silently fall back to 3.0 (native)19:16
cjwatson  * Catch mismatches between version strings and format versions in19:16
cjwatson    dpkg-source. Ensure that a 3.0 (quilt) package has a non-native version19:16
cjwatson    and that a 3.0 (native) package has a native version. Closes: #70017719:16
cjwatson    Thanks to Bernhard R. Link <brlink@debian.org>.19:16
cyphermoxthis is in time going to break each of the packages19:17
fginther\o/19:17
cyphermoxcjwatson: ack, makes sense19:17
cjwatsonthere's some support for pristine-tar information as a bzr property somewhere but I don't remember the details19:18
cjwatsoninfinity: ^- I wonder if we should consider temporarily reverting that change; it's been causing trouble for people showing up in #launchpad too19:18
infinitycjwatson: pristine-tar, or people can stop using non-native versions for their recipes.19:19
infinitycjwatson: But I could revert the dpkg strictness too...19:19
cyphermoxcjwatson: don't revert that for us though. I've been kind of against using native for non-native packages.19:19
cyphermoxunless didrocks says otherwise, it's his baby after all19:20
cyphermoxbut none of this really needs to be native packages19:20
cjwatsonthe pristine-tar bit is kind of cumbersome and non-obvious19:20
cjwatsonthere's "bzr import-upstream" according to https://answers.launchpad.net/launchpad/+question/20308319:20
didrocksit doesn't seem straightforward indeed19:21
didrockscyphermox: we should just use 1.0 package for those as we are in split bzr mode19:21
cjwatson"bzr help import-upstream" actually looks pretty easy to run19:21
cjwatsoncould you try that before changing the source format?19:21
cyphermoxoh, you're right, they should be 1.0 anyway19:21
cyphermoxif the import-upstream bits work I'd be all for moving to 3.0 though19:22
cyphermoxprovided there wan't another such strictness that we chose 1.0 for19:22
cyphermoxI'll look at import-upstream19:23
didrockscjwatson: import-upstream is to import an upstream tarball19:23
didrockswe don't have upstream releases19:23
cjwatsonoh, then you should be native in some way, indeed19:24
cyphermoxright19:24
cjwatsonI'd suggest changing the version number scheme and using 3.0 (native) then, if possible19:24
cjwatsonit would be a better reflection of reality19:25
cjwatsonthat said: you *do* seem to have upstream tarballs19:25
cjwatsonin that e.g. "apt-cache showsrc unity8" shows me .orig.tar.gz19:25
cjwatsonbut I guess it's cumbersome to import those in advance of "releases"?19:25
didrockscjwatson: we create them19:28
didrockswith bzr bd, split mode19:28
didrocksfor other distro if they want to use it, one day…19:28
didrocksand bzr bd is then, getting this 3.0 conflict now, even in split mode ^19:29
cyphermoxdidrocks: autopilot-gtk19:29
cjwatson1.0 probably isn't terrible for that, but this seems like a bunch of work for now when we could revert the dpkg change and get moving again19:29
cyphermoxbecause it's in 3.0... but most other pacakges should be 1.0 as per the wiki19:30
cyphermoxdidrocks: couldn't cu2d import-upstream as it goes to do the package build?19:30
didrockscjwatson: if you can revert it, then, we can have a task to update everything for 1.019:30
didrockscyphermox: well, it's a chicken and egg problem19:30
cjwatsonthough it would be pretty rubbish to end up in a place where the CI infrastructure can't deal with packages that *do* have a separate upstream existence19:30
didrocksyou need import-upstream for running bzr bd now19:31
cjwatsondidrocks: I'm out of time for this week, but if infinity wants to do it ...19:31
didrocksand you need to run bzr bd to get an upstream image19:31
didrockscjwatson: previously, I was doing it myself, without bzr bd19:31
didrocksbut it's hackish19:31
didrockscyphermox: maybe we can use --export-upstream=19:32
didrocksthat maybe won't run debian/rules and get into this dpkg change19:33
cyphermoxyeah... that or some for of bzr export as the get-orig-source rule, or whatever it is that creates a tarball19:33
didrockscyphermox: do you have some time to investigate today?19:34
cyphermoxdidrocks: already done19:34
cyphermoxwell, kindof19:34
cyphermoxhold on a second :)19:34
didrocksoh nice! it's working?19:34
didrocksok ;)19:34
cyphermoxwell itś working and you don't have to run bzr bd twice...19:34
didrocksexcellent!19:35
cyphermoxlet me make sure19:35
didrockscyphermox: feel free to MP against cupstream2distro once confirmed :)19:35
dobeyfginther: btw, did you get to make any progress on the u1 branches in tarmac with daily-release support stuff?19:37
fgintherdobey, ah, yes. forget to send you the infos19:37
cyphermoxdidrocks: we'll still need to make it (quilt) instead of (native)19:39
didrocksso, it's a change either way19:39
didrocksbut in even more packages19:39
fgintherdobey, https://code.launchpad.net/~fginther/cupstream2distro-config/ubuntuone-no-upstream-merger/+merge/19618919:40
didrockswe should maybe revert the dpkg change and transition then to (quilt)19:40
didrockswith your change19:40
didrocksinfinity: ^19:40
cyphermoxdidrocks: why do we need to revert the dpkg strictness then?19:40
cjwatsonoh, I got it backwards, you're 3.0 (native) right now not 3.0 (quilt)19:40
dobeyfginther: i don't really understand what that does exactly19:40
infinityIf they're 3.0 (native), just fix the version number.19:40
cjwatsonwell having 3.0 (native) with a revision number is just unambiguously wrong :-)19:40
cyphermoxyes19:41
infinityI *can* revert the dpkg change, but I don't want that to be an excuse for people to keep being wrong. :P19:41
didrockscyphermox: well, because evrything will fail?19:41
cyphermoxdidrocks: well we have the occasion of fixing it by fixing the source format where necessary?19:42
didrocksinfinity: they are not native, but bzr bd doesn't know how to split the package correctly…19:42
sergiusensagree, fix version number to match what you are doing19:42
infinitydidrocks: If the format is 3.0 (native), they're native...19:42
cyphermoxdidrocks: actually, that particular pacakge does specify 3.0 (native)19:42
didrockscyphermox: is debian/source says natives?19:42
didrocksah19:42
infinitydidrocks: If they have orig tarballs, stop calling them native, and import the tarballs.19:42
didrocksso please drop that19:42
infinitydidrocks: There's not really an in between here, is there?19:42
didrockscyphermox: that should be enough right?19:42
cjwatsonjust to clarify, if we're reverting the dpkg change then that should IMO be primarily because it's a support cost for #launchpad (if that can't be handled some other way)19:42
didrocksinfinity: well, I didn't set it to native, clearly19:42
cjwatsonin terms of recipes in general19:42
cyphermoxright. the 3.0 (native) is absolutely wrong, and that's it19:42
didrocksinfinity: I agree :)19:42
fgintherdobey, sorry, it's not well explained. Essentially this will allow ubuntuone-client-data and ubuntuone-credentials to be picked up by the daily-release process when they are ready19:43
didrockscyphermox: so, please change that :)19:43
didrocksand be done19:43
cyphermoxdidrocks: as far as I know it's enough yeah19:43
cjwatsonhowever, the next couple of people who come into #launchpad with this problem, I'll point them at bzr import-upstream now that I've found it19:43
fgintherdobey, but it will not do any upstream-merger on them19:43
cjwatsonand we'll see if that helps, and FAQify or whatever19:43
dobeyfginther: does that change mean ps jenkins bot won't run the tests in ps jenkins, as is currently happening?19:44
fgintherdobey, yes, ps jenkins will ignore these19:45
dobeyfginther: i don't think we want/need to stop that happening. is that required to make daily-release possible, while using tarmac?19:45
cyphermoxhttps://code.launchpad.net/~mathieu-tl/autopilot-gtk/source-format/+merge/19619019:46
infinitycyphermox: Of course, 3.0 (quilt) might *still* fail because you lack an orig...19:47
infinitycyphermox: Unless you're also going to fix that.19:48
infinity(Or does this have an orig?)19:48
fgintherdobey, I can revisit it, but I don't have time to spend on it right now. I thought that disabling upstream merger might be a viable short term solution, but it appears to not be the case19:50
fgintherdobey, my other thought would be to make some change to tarmac to operate on specific branches19:51
sergiusensinfinity, cyphermox looking at the history, it was initially 3.0 (native), when added to daily release switched to 1.0 then someone changed it to 3.0 (native) again19:51
sergiusensmeaning that maybe some general communication on this would help19:51
dobeyfginther: it would be possible and very easy to add such a feature to tarmac, if it's necessary. it doesn't really fit with the general design of how tarmac works, but it's very simple for me to implement.19:52
cyphermoxinfinity: AFAICS bzr bd in split mode should be writing the orig anyway... and it seems to on my system19:52
infinitycyphermox: Ahh, cool.  So, that's a solved problem for you guys, just don't call those native. :P19:53
fgintherdobey, ok. let me create a bug with what I think would help19:53
infinityNon-split recipes run into dpkg whining at them, and importing the actual upstream tarball is the solution there.19:53
cyphermoxI've always said those weren't supposed to be considered native packages in any way, since they have a debian rev19:53
dobeyfginther: could you enumerate in an e-mail ro something for me, what exactly is required for daily-release to work with the current setup, on a purely technical level (must be specific branch merge, must have debian/ in-tree, etc… sort of stuff)?19:53
fgintherdobey, sure19:54
infinitycjwatson: I guess we could make lp-buildd try to spit out a useful "hey, maybe you need to bzr import-upstream" message on failed recipe-derived builds of that sort?  I dunno.19:55
dobeyfginther: thanks. that should make it clearer as to what we need to exactly to make it work and fit tarmac in for doing the merges19:55
cyphermoxbrb19:55
dobeyfginther: and i voted disapprove on that MP as it doesn't seem to facilitate what we want to do there. :)19:59
fgintherdobey, agreed19:59
thomididrocks: still around?20:03
fgintherdobey, https://bugs.launchpad.net/tarmac/+bug/125377020:17
ubot5Ubuntu bug 1253770 in Tarmac "Feature request: provide API to use raw tarmac features without the workflow" [Undecided,New]20:17
retoadedall, I am starting to mark the various jenkins instances as "prepare to shutdown" so no additional jobs start before we have to take things down for the (hopeful) network fix.20:27
=== bfiller_ is now known as bfiller
=== plars changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cihelp | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: Some services are down (1SS move), network slowness

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!