=== chihchun_afk is now known as chihchun [04:49] fginther, robru: can I see the logs from boottest? [04:50] anpok_: if you're looking at http://people.canonical.com/~platform/citrain_dashboard/#?q=ubuntu%2Flanding-004 you can click on "x is in the proposed pocket" and then from there it'll say "boottest regression" and you can click on "public" to get the log [04:51] i see [04:51] I know what is causing this [04:51] anpok_: excellent! good luck ;-) [04:52] mir libraries do not depend on any particular driver package [04:52] bootest only updates the involved mir libraries .. and not the driver package.. === marcusto_ is now known as marcustomlinson [07:24] robru: boottest for usc should work now.. now trying bootest for mir [07:29] anpok_: OK, please ask sil2100 to publish when you're ready, it's midnight here ;-) [07:34] veebers, hey [07:34] veebers, what's the status of the fix for bug #1477233 ? [07:34] bug 1477233 in autopilot (Ubuntu) "autopilot now depends on "/usr/bin/gsettings" and ubuntu-keyboard" [Undecided,New] https://launchpad.net/bugs/1477233 [07:35] that's making tests fail and blocking things [07:35] seb128: hey, I have an MP sitting there that needs ack & approve then we'll release [07:35] veebers, who does autopilot reviews? [07:35] the original MP that kenvandine proposed was marked needs fixing [07:35] did you ping people? [07:36] seb128: well, for this I need kenvandine and Laney to ack [07:36] seb128: I have emailed [07:36] k [07:36] well, they are not part of the autopilot team [07:36] you have nobody in your team to do reviews? [07:36] also ken's change was easy to review/just packaging, yours has more [07:36] seb128: I do, but they raised specific concerns which need to be OK'd [07:37] k [07:37] seb128: right, Laney had concerns that the packaging was too much for everyone to shoulder as well as point out that using the gsetting binary was heavyweight. Hence the extra code [07:38] k [07:38] I also notice that you self reviewed the change that created the issue [07:38] we don't have anyone to do peer reviews on that project? [07:38] seb128: Not as many as I would like. [07:39] seb128: although that was a little odd as I had acks from other people, just not via the MP (which is in bad taste, I know) [07:41] hum, k [07:41] seb128: so to follow up, I've pinged the people to approve/whatever the MP and I plan to have someone in the qateam to do the release when that happens (i.e. during my night) [07:41] veebers, anyway having something to land today would be nice, since that bugs tests and block things to migrate [07:42] k, good to read [07:42] can you give a qa person name to nag? [07:42] I don't want that to block things for another full day [07:42] seb128: sure, ping jibel or nuclearbob [07:42] k [07:42] thanks [07:43] seb128: no worries. Sorry it was an issue, I wasn't aware until this morn that it was an issue and blocking things [07:43] no worry, bugs happen [07:43] tz also don't make it easy to have quick resolutions sometime :-/ [07:44] yeah :-\ [07:47] do we have a 'get started with silos' doc? :S [07:47] seb128, sorry there was a bus factor of 1 on autopilot releases. We'll use this release to share the knowledge. [07:47] jibel, no worry, thanks [07:48] jgdx, https://wiki.ubuntu.com/citrain/LandingProcess [07:53] seb128, right.. how about a 'installing my first silo' :P [07:59] jgdx, installing? [08:00] jgdx, silos builds in ppa, are you asking how to enable a ppa? [08:00] jgdx, https://help.launchpad.net/Packaging/PPA [08:01] Wellark, not as straight forward on a phone [08:02] seb128, well… ^ [08:02] :) [08:03] just add-apt-repository [08:03] to add it to your sources [08:03] then apt-get update & install [08:04] seb128, before then, enable developer mode, download and install phablet-tools, make the device writable [08:05] easy to forget [08:23] sil2100, do you no anyone who could approve the following => https://code.launchpad.net/~mandel/unity-scope-click/recompile-new-udm-client/+merge/257959 [08:23] sil2100, is just a rebuild [08:31] mandel: I can force it I suppose, you can self-approve it if you have the permissions [08:32] sil2100, did so [08:32] sil2100, let me rebuild the silo and we can publish [08:32] Rebuild? [08:32] sil2100, added a new version of udm with --unchanged but linking to a bug [08:33] ah, ok [08:33] sil2100, I'm a little anal, but I like to have the --fixes comment in th ehistory ;) [08:34] anpok_: is it cool to publish 004 again? [08:35] sil2100: no [08:59] jibel: can you/someone (review and) approve https://code.launchpad.net/~canonical-platform-qa/autopilot/depends_for_gsettings/+merge/265621 ? [09:00] mandel: hmmm [09:01] sil2100, what? [09:08] sil2100, the suspense is killing me... ;) [09:09] sil2100, oh, is it due to this => Can't publish: Packaging changes need manual ACKing [09:09] weird [09:09] mandel: one moment, in a meeting [09:09] sorry [09:18] Laney, done [09:19] ta [09:19] I'm scared about uploading this [09:20] I don't know about the dual rules [09:20] can someone help? [09:22] mandel: ok ;p [09:23] mandel: sooooo, I know you're already getting really irritated because of this landing [09:24] mandel: but looking at the packaging changes, I see two things: [09:25] mandel: first: uh oh the commit/changelog message of the ubuntu-download-manager is "Test build" <- is this really a test build? We're releasing a test build to the archive ;p ? [09:25] mandel: second: I see some symbols changed, won't this break the ABI/API? [09:25] https://ci-train.ubuntu.com/job/ubuntu-landing-009-2-publish/102/artifact/ubuntu-download-manager_packaging_changes.diff [09:25] Here's the list of changes [09:26] Laney, dual rules? dual landing you mean? [09:26] yeah [09:26] mandel: are those symbols that got changed used somewhere besides in u-d-m itself? [09:26] Laney, what do you want to know? basically it does 2 sources packages/uploads in the ppa, one targetting to vivid and one to wily [09:27] seb128: Like if you're allowed to just do it or who needs to sign off [09:27] well, I think vivid needs qa signoff [09:27] jibel can help I'm sure [09:35] sil2100, really? I did not see the test build comment, ups! [09:35] sil2100, the symbols are just changed in udm client lib, used by the other projects [09:36] sil2100, updated the changelog to not have that test comment [09:38] mandel: it will require a rebuild... but regarding the symbols - so those symbols are not used anywhere outside of the library, right? [09:38] mandel: since if they are used, then we need to bump the so-name too [09:39] sil2100, you are right, we do need to bump the version numbers, good catch, I'll take care [09:40] mandel: sorry for that, I know you'd like to just land it already [09:40] sil2100, no no no, things have to be done right the first time [09:40] sil2100, mea culpa [09:41] sil2100, I prefer to land 5 times all of them correct than 20 wrong ones [09:41] mandel: you'll have to bump the lib name to libudm-common1 probably, do a major version bump etc. [09:41] mandel: indeed! Less trouble then [09:41] Thanks! [09:41] sil2100, ouch, I reach 1 already bummer :-/ [09:41] sil2100, I wanted to be like emacs.. [09:42] hah ;) [10:11] Laney, did you plan to put that autopilot fix in a silo? [10:13] seb128: hoped jibel would respond to your ping ... [10:13] I guess I can build it now at least? [10:17] * Laney cries [10:20] I guess https://code.launchpad.net/~ci-train-bot/autopilot/autopilot-ubuntu-wily-proposed needs merging in [10:20] or add this MP to the original silo [10:21] * Laney does that instead [10:22] seb128, Laney sorry I missed your ping. [10:22] Laney, right, qa validation is needed beofre publishing, not before building [10:22] * Laney screms again [10:23] https://ci-train.ubuntu.com/job/prepare-silo/5485/console [10:23] Laney, seb128 yes vivid needs sign off if it was the question [10:24] hum [10:24] unsure if we should dual land [10:24] or just land to wily to unblock proposed [10:25] and let qa deal with vivid [10:25] Laney, ^ opinion? [10:25] I don't want wily to be blocked on qa to have to valid vivid updates [10:25] seb128, yes do that, and nuclearbob will deal with the landing in vivid [10:25] seb128: is it easy to fix that up later? [10:26] don't want to give someone a hard time if possible [10:27] Laney, unsure, I'm close from suggesting we just dput the fix in wily and let them deal with vcs and landings [10:28] I messed the silo config up a bit already [10:29] trainguards should be able to help [10:33] Laney, the other alternative is that I deleted the version currently in wily-proposed and we let qa deal with the dual landing [10:34] seb128: either thing wfm but I think that the fix was needed for some tests [10:34] maybe not wily autopkgtests though [10:35] right, I think it's more for some CI on mps issues [10:36] do it [10:36] deleting? [10:36] ya [10:36] It should be ok for nuclearbob or whoever to fix it later on I think [10:36] right [10:38] Laney, jibel, done ^ (deleted the autopilot update in wily-proposed since it was buggy, so we can wait for the new fixes to be dual landed and validated by qa the way it should be) [10:39] ty [10:39] yw [10:39] next to unblock is mir [10:47] sil2100, whenever you have some time, can you confirm this is correct => http://paste.ubuntu.com/11924616/ [10:48] sil2100, the other packages do not use the new symbols so they do not need to change the dep AFAIK, right? [10:55] seb128, thanks [10:55] jibel, yw! [11:08] mandel: one moment [11:25] mandel: looks okayish to me [11:25] But it would certainly need some testing after it's built [11:45] pmcgowan: davmor2 has passed clock app to upload to the store. do I need a +1 from you also to upload it? https://trello.com/c/FFDKp0Qm/2074-click-ubuntu-clock-app-popey [11:45] popey, no you guys are good [12:05] thanks pmcgowan === _salem is now known as salem_ [12:24] jibel: sorry to ping you a lot today... since pitti is out - do you know how the adt VMs are built? [12:24] when is adt-buildvm-ubuntu-cloud called and how can I get a change to be effective there? [12:25] Laney, no problem. The VMs that run on HW or the cloud instances? [12:25] jibel: the HW ones [12:25] popey: when the gates are not closed, after QA sign-off it's all good to publish [12:25] sil2100: is now good? :) [12:25] Laney, I'll tell you as soon as NM stops crashing and I can bring the VPN up [12:25] Good good :) [12:25] jibel: to fix https://jenkins.qa.ubuntu.com/view/Wily/view/AutoPkgTest/job/wily-adt-udisks2/ARCH=amd64,label=adt/48/console I need to make a change to the setup script [12:26] Laney, 1 min, I restart my session [12:30] anpok_: tell me once silo 004 is good to land [12:30] * sil2100 off to lunch [12:31] Laney, there is a job called wily-adt-setup-testbed which calls autopkgtest/tools/adt-buildvm-ubuntu-clound [12:31] Laney, it is currently running. [12:32] Laney, I've an appointment now, but I can have a look when I'm done. [12:37] jibel: I found it, just need to know where/how it gets its copy of autopkgtest now [12:37] Laney, from git trunk I guess [12:38] I assume so, just can't see that [12:39] and can't change it if that is true :P [12:43] unless we can temporariliy point it to another url [13:12] mandel, i reconfigured silo 9 again, the content-hub branch was against 15.04 [13:12] so i used your other MP that was against trunk [13:40] trainguards: can i land a silo into another silo (ie, have the "target ppa" be another silo)? [13:41] dobey: hey! Yes, but remember that the upload to the other silo won't be auto-noticed by the trian [13:41] dobey: the silo will just clean itself after doing a copy-package to the target PPA (in this case, the silo) [13:42] sil2100: is that how it works for the ovleray ppa? [13:42] So the target silo needs to then know what to do with those packages [13:42] dobey: yes [13:42] It's the very same mechanism [13:42] ok [13:43] ogra_: eeeenndoorrrssssmeeennnnt [13:43] ogra_: a quick one would be enough ;) [13:44] sil2100, i'll try today [13:44] cool, that will make dealing with the gcc5 silo at least slightly easier [13:44] Thanks! Fingers crossed ;) Would like to submit my application soonish [13:45] dobey: be sure to keep track of which branches you merge into [13:45] So that there's no chaos later on with the trunk != archive [13:46] cihelp, can you remove the utopic jobs from ubuntu-calendar-app on core apps jenkins? [13:48] sil2100: yeah. idea would be to just land stuff into the gcc5 silo now, and then when it's copied to archive next week, things will just fall into place [13:52] balloons: will do in a little bit [13:54] ty! [13:57] dobey: many teams simply release their gcc-5 changes to the normal archives and then just get no-change rebuilds copied to silo 16 [13:57] sil2100: too much rebuilding. really i'd rather just wait until stuff is copied to archive and just fix everything there [13:58] kenvandine, ok, I have to ensure that the udm bum works [13:58] kenvandine, we need to retest the silo [14:09] sil2100, can you give nuclearbob access to the spreadsheet so he can proceed with the landing of autopilot? [14:09] jibel: just got it [14:10] ok [14:10] thanks [14:10] Done :) [14:27] sil2100: the job to build for the silo failed, could you help me figure out what I'm doing wrong? [14:28] nuclearbob: let me take a look, but it seems the trunk for this project is missing one version that seems released to the archive [14:28] sil2100: yes, I've just heard it was released to wily to unblock landings, I can get an mp to get that back in sync [14:30] nuclearbob: all the changes from 1.5.1+15.10.20150716-0ubuntu1 need to be in the trunk you are merging into, along with the changelog entry for that version [14:30] sil2100: okay, I'll work on getting that merged [14:30] You can either add this MP to the landing or simply merge those changes to that trunk and rebuild [14:30] Both approaches should be fine [14:30] nuclearbob: ok :) [14:33] sil2100: since I'm new at this, do you know the best place to grab the branch or mp that was merged into the archive? I see all the merges to trunk, but I'm not sure which branch was used to push to wily [14:33] mzanetti: Silo 6 approved [14:34] nuclearbob: strange that it wasn't merged in... let me take a look [14:34] nuclearbob: ah! Ok, I see now what's going on [14:34] nuclearbob: so generally, I would recommend waiting a little bit for the merge to get merged in automatically by the train [14:35] sil2100: okay [14:35] autopilot is stuck in proposed [14:35] Any chance of it migrating? [14:35] sil2100, the branch nuclearbob is trying to land should fix that [14:35] davmor2: Silo 6 is landing, so 7 can be rebuilt [14:35] Ok [14:35] sil2100, not without the fix he's trying to land :) [14:35] maybe silo 51 should be force merged [14:35] Then hmmmm, let's force merge silo 51 [14:35] Indeed [14:36] he's trying to land a fix from me to fix the migration blocking a bunch of packages :) [14:36] Force merging - nuclearbob you should be able to build in a moment [14:36] sil2100: cool, thanks [14:38] rvr, yay! [14:38] rvr, next one coming in a minute :D [14:38] greyback, mzanetti: can you please rebuild silo007 and not land any more unity8's till I get this one tested thanks ;) [14:38] nuclearbob: you can build now :) [14:38] sil2100: cool, saw that :) [14:38] davmor2, I think 7 can't land atm because of some Mir things [14:39] davmor2: silo7 blocked until silo4 lands [14:40] greyback: I'll remove the card then :( sorry dude we keep trying to test it and people keep breaking it for you :( [14:41] davmor2: yeah. I've not been lucky. [14:41] Today looks like a bad landing day [14:41] Not the first package that can't land [14:51] sil2100: the reason why usc-boottest failed for silo004, was because do not have explicit dependencies to any of the mir drivers [14:52] and that is on purpose because on the phone we do not want to pull in both drivers as the mesa driver adds a lot of runtime dependencies [14:52] and in earlier version we could not probe during startup (that part is solved now) [14:52] so within the usc boottest usc used the new mir libraries it depends on, but those had no drivers to use. [14:53] sil2100: I tried removing the ABI bump of the driver package this morning, but it turned out that the driver ABI bump was necessary [14:56] sil2100: to solve bootest of usc, we could add usc meta packages one for desktop and one for android phablet, which contain explicit (and versioned) dependencies to mirs driver packages. [14:56] mandel, for some reason that content-hub branch is reverting previous landings... [14:57] anpok_: hm, I guess that could be good, but I would consult this with an archive admin [14:59] sil2100: hm who could that be in the current timezone? [15:01] slangasek should be up soon, infinity might be able to help also since he uses a very fuzzy timezone [15:01] mandel, thankfully it was easy to spot in the packaging review :) [15:01] Non-discreet [15:01] kenvandine, is it? how? weird... [15:01] kenvandine, I'm in a meeting can you fix that? [15:01] yes [15:01] i really don' [15:01] t understand why though [15:02] you had a no change branch [15:02] mandel, anyway, i fixed [15:02] mandel, i'll handle getting it landed [15:03] kenvandine, oh, thx, sorry in a meeting, is that silo 09? [15:03] kenvandine, I bumped the version of udm as per sil2100 request [15:03] mandel, yes [15:03] that's good too [15:09] kenvandine, perfect [15:27] balloons: http://91.189.93.70:8080/job/ubuntu-calendar-app-ci/configure does not have utopic jobs now [15:33] robru: do you know when wendigo will be back up? [15:47] psivaa, are you sure? I still see them: http://91.189.93.70:8080/job/ubuntu-calendar-app-ci/ [15:48] psivaa, generic-mediumtests-utopic and ubuntu-calendar-app-utopic-amd64-ci [15:48] balloons: those listed are the old ones, [15:48] balloons: any new job will not execute them [15:48] psivaa, ok, executing :-) [15:48] psivaa, did you fix ubuntu-calendar-app-autolanding also? [15:53] balloons: that should have been fixed as well, http://91.189.93.70:8080/job/ubuntu-calendar-app-autolanding/configure doesn't now have utopic jobs === chihchun is now known as chihchun_afk [16:28] sil2100: we discussed further in the team.. and concluded that the solution outlined above just moves the problem.. [16:30] sil2100: can we instead have an excemption for the usc-boottest? and land the next finished build of silo004 === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk [16:47] anpok_: hm, since this is about proposed migration, also the decision here should be made by the archive admins or even the release team [16:47] I heard what this means more or less so I understand why you would like this skipped === alan_g is now known as alan_g|EOD [17:08] sil2100: ack .. i am off for a bit . [17:25] sil2100: uh, are you able to load the train? i can't seem to connect [17:26] robru: you mean citrain jenkins? Loads here for me [17:26] Spreadsheet as well [17:26] sil2100: yeah, I can't connect, it just spins... [17:26] sil2100: spreadsheet is fine for me [17:27] https://ci-train.ubuntu.com/ works fine here [17:27] grrr [17:36] robru: is your vpn up? [17:37] davmor2: never needed a VPN to access citrain before. [17:37] hm, right, I'm on VPN [17:38] Let me disconnect [17:38] robru: just trying to rule stuff out as I can access it too [17:38] davmor2: well, I just connected to VPN and now I can load [17:38] robru: still working here [17:38] davmor2: sil2100: also downforeveryoneorjustme.com shows it as up [17:39] robru: You ISP is stopping you from working, hate them :) [17:39] davmor2: sil2100: OOOOOOOOOOOOOOHHHHHHHHHHHHHHHHHHHHH lol I'm dumb. My /etc/hosts munges those domains to point at the new deployment I'm supposed to be verifying, I forgot about that from last night [17:40] hah [17:40] ;) [17:40] robru: that'll do it :) [18:09] trainguards: could I have a silo for row 61? [18:10] jgdx: you can assign your own silos now. just click the row and then click 'landing tools > assign/reconfigure' menu [18:11] robru, man, that's out of the ballpark [18:11] jgdx: heh, you're welcome. it's a little experimental, let me know if you have any problems [18:11] thanks! [18:11] jgdx: you're welcome [18:27] trainguards: the spreadsheet won't let me enter ci-train-ppa-service/ubuntu/landing-016 in column L :( [18:28] dobey: why would you want to do that? [18:28] robru: because it's just a gcc5 build fix, and i don't want to have to deal with maintaining 2 conflicting copies of the same package until the end of next week [18:29] dobey: I'm not really following. why not just build in silo 16 in the first place? [18:29] dobey: what are you expecting to happen by having a separate silo that publishes into silo 16? [18:29] robru: because it's not a normal silo, so i can't just add a branch to it and then reconfigure and rebuild the silo, as i understand it [18:30] dobey: it's a normal silo, but somebody decided it would be a great idea to add thousands of packages to it without configuring it properly. [18:30] robru: i expect it to commit the MP to the target branch and publish the package in that silo; and next week the contents of that silo will be pushed into the archive [18:30] dobey: you can add an MP to the silo 16 config and then build it if you want. [18:31] dobey: ok what row are you doing? [18:31] robru: and my doing that won't cause the archive to blow up by deleting all the packages in it alrady? [18:31] dobey: no the train never deletes packages from PPAs unless it's doing merge & clean, after publication [18:32] dobey: hang on. is your goal to merge your merge before silo 16 gets published? [18:33] my goal is to fix the issue in silo 16, without having to maintain two versions of the same package to do so [18:34] and i don't want to have to manually resolve the differences in the trunk, when silo 16 gets published [18:39] robru: is that not possible? [18:39] dobey: I don't know what you mean by "two versions". what scenario will cause two versions of the same package? [18:42] robru: the existance of silo 16 for the gcc5 migration. if i land directly into the archive, i'll have to get someone to upload a no-change rebuild to silo16. then, when that gets merged to the archive, i'd have to resolve the conflicts by hand in trunk, to add the new revisions from debian/changelog [18:42] dobey: ok, so how does publishing to silo 16 fix that? you just won't publish to archive at all, and wait for 16 to publish? [18:43] infinity, slangasek: ping [18:43] but if i understand correctly, i should just be able to land by publishing to silo 16, and then that will satisfy the rebuild, and it will go in the archive when silo 16 publishes [18:43] ? [18:43] infinity: hi [18:43] robru: i think so, yes [18:43] infinity: we have a problem with boottest of unity-system-compositor [18:43] dobey: ok well it should be possible to put silo 16 as a publish target, just right click on the cell and click 'data validation' and change it from 'refuse invalid' to 'show warning' or something [18:44] anpok_: Indeed you do. [18:44] robru: ah ok [18:44] the boottest updates unity-system-compositor, and thus also the server librariers of mir which it uses. [18:44] but it does not install any drivers required by libmirserver32 [18:44] hence launching usc and greeter fails [18:45] anpok_: So, nothing depends on a driver? [18:45] we decided against making the drivers a dependency of libmirserver or one of ther shells that user libmirserver [18:46] instead this is handled by other meta packages during image generation [18:46] i.e. if we made both a dependency we would always pull in x and wayland libararies because of mesa.. [18:46] anpok_: Okay, but those metapackages are installed in the image, so what's breaking here? An ABI break in the drivers or something? [18:47] infinity: with that mir release we have an abi break between server and drivers so the driver package gets a bumped abi - and not a new version since we want to support having multiple driver abis installed [18:47] anpok_: Anyhow, if this is something that needs hacking around in the boottest infra to fake things up better, that's not my code. I think jibel owns it (or knows who does). [18:48] infinity: we wondered if we could get an exemption for silo004 landing [18:48] anpok_: Well, an exemption is only sane if you're positive that all the failures are false negatives (ie: people have tested this all by hand with the right package combinations and you're sure boottest is lying). [18:49] anpok_: And, more importantly, we need to be sure this problem goes away once all that stuff promotes and a new base image happens. [18:49] well thats what the boottest log tells us [18:50] anpok_: Sure, "this is what the log is hinting at" isn't the same as "I reproduced the issue locally, then upgraded/installed a few more packages, and everything was good again". [18:50] ok.. then again [18:50] anpok_: Is it a question of packages not being installed at all, or not upgraded? [18:50] I know this happens because of that because I reproduced it locally [18:50] and tried different ways to circumvent the problem [18:50] robru: ah, i guess i can't do this after all :-/ [18:50] 2015-07-23 18:48:58,290 ERROR pay-service 2.0.0+15.10.20150721-0ubuntu2~gcc5.1 is missing from the changelog, which has up to 2.0.0+15.10.20150702-0ubuntu1. Please sync destination version back to trunk. [18:50] infinity, I'm happy to not own boottest. I think psivaa or at least someone in cihelp can help [18:50] but I cannot find a solution that makes boottest-mir and boottest-usc run successfull [18:51] .. well the only solution is explicit dependencies that we decided against some time ago [18:51] jibel: I don't want to own it either. :P [18:51] dobey: so that implies that there's already a pay-service in silo 16. [18:51] dobey: FORCE_REBUILD will steamroll over that as long as you're ok with clobbering whatever is in silo 16. [18:51] robru: yeah, there is. will force rebuild work around that? [18:51] ok, great [18:51] anpok_: Asking again, is it a question of packages not being installed at all, or not upgraded? [18:52] not being installed at all. [18:52] anpok_: If it's packages not installed *at all*, how will the be installed on "correct" images? [18:52] jibel, infinity, anpok_, catching up [18:52] s/the/they/ [18:52] infinity: through the seed package [18:52] hmm [18:52] anpok_: livecd-rootfs hacks, or a metapackage that pulls them in? [18:52] anpok_: If it's a metapackage, why isn't that updated yet? That would fix the test failure. [18:53] because bootest does not work that way [18:53] boottest takes wily .. and just installed one of the packages of the silo [18:53] and no upgrade [18:53] *installs [18:53] Oh, fair point. [18:53] It's a bit broken in that regard for special cases like this. [18:54] Or any case where an "unrelated" package causes a failure. [18:54] anpok_: Alright, well. If you can assure me that this is all reproduced locally, that installing the right packages fixes it, *and* that images/metapackages will be correct and sane once this all promotes, I can give it a big override hammer. [18:54] I can! [18:54] anpok_: But you're also implicitly taking responsiblity for fixing whatever mess that causes. Deal? [18:55] deal [18:55] i am in mess mode since a few weeks already.. what bad can happen? [18:55] ^ i said that last week [18:55] anpok_: Alright, I'll iterate through landing-004 and override as needed. [18:55] thanks [19:00] anpok_, is this going to happen again the next time there is a mir landing? [19:00] fginther: the next time when we have a driver bump - yes. [19:01] anpok_: So, we should work out a hack for that in boottest itself, to install the right drivers in the base if required. [19:01] i think boottest showed us real problems last week [19:01] anpok_: ie: whatever you had to do to manually validate it, the infra should be doing that. [19:02] anpok_, indeed, I'd like to know what would resolve this and see if it can be added before the next bump [19:02] infinity: yes - we should add something for mir server related boottest runs [19:02] anpok_: If you and fginther can figure out what that "something" is, that would be great. [19:03] anpok_: I'm backing away from it now. :P [19:03]