| lpotter | ++fqvvx | 01:05 |
|---|---|---|
| lpotter | geez qtbase takes forever to build... | 03:33 |
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| === faenil_ is now known as faenil | ||
| mardy | cjwatson: hi! Is this normal? https://launchpad.net/~mardy/+archive/ubuntu/phablet/+build/9416048 | 09:57 |
| mardy | cjwatson: seems to be stuck there | 09:57 |
| cjwatson | mardy: no, I presume a compute node is sad, cancelling and retrying | 09:58 |
| mardy | cjwatson: thanks | 10:01 |
| cjwatson | mardy: (done) | 10:03 |
| === marcusto_ is now known as marcustomlinson_ | ||
| === marcustomlinson_ is now known as marcustomlinson | ||
| tvoss | robru, ping | 11:02 |
| tvoss | robru, hey there, I have got a build for platform-api consistently failing for xenial whereas it passes reliably on vivid+o. Would you mind having a look? silo 74 | 11:03 |
| tvoss | sil2100, ^ | 11:03 |
| sil2100 | In a moment | 11:15 |
| Mirv | tvoss: all the simbackendtests seem to be failinng on xenial | 11:31 |
| Mirv | tvoss: just use "trainguards" is easiest always, it'll higlight me, sil, robert, and others at times | 11:31 |
| tvoss | Mirv, yeah, wondering why | 11:31 |
| tvoss | Mirv, ack | 11:32 |
| tvoss | Mirv, I'm doing a test build locally in a xenial chroot | 11:32 |
| tvoss | Mirv, let's see | 11:32 |
| Mirv | tvoss: erm. " Actual: 4-byte object <03-00 00-00>, Expected: core::posix::wait::Result::Status::exited" | 11:32 |
| tvoss | Mirv, that's a result of the backend not being loadable | 11:32 |
| Mirv | tvoss: it's almost two months since last platform-api landing, this could be something changed in xenial. I've been hit by some, including a glibc bug. | 11:33 |
| === chihchun is now known as chihchun_afk | ||
| tvoss | Mirv, interesting | 11:36 |
| tvoss | Mirv, the build used to work fine before, though | 11:36 |
| tvoss | Mirv, silo has been around for some time and actively rebuilding | 11:36 |
| Mirv | tvoss: I see you had a successful build at 2016-03-22. assuming it's not something you changed in platform-api, it could be something change in xenial since then. | 11:37 |
| tvoss | Mirv, yup | 11:38 |
| Mirv | tvoss: at least this gcc-5 landing happened during the timeframe http://launchpadlibrarian.net/249840962/gcc-5_5.3.1-12ubuntu4_5.3.1-13ubuntu1.diff.gz | 11:38 |
| Mirv | tvoss: and also the whole glibc 2.21 -> 2.23 upgrade https://launchpad.net/ubuntu/+source/glibc/+changelog that broke a single Qt unit test for me which took some hunting to find the culprit | 11:39 |
| tvoss | Mirv, ack, I will do a deep dive in a local environment then, thanks for investigating | 11:40 |
| === alan_g is now known as alan_g|lunch | ||
| === _salem is now known as salem_ | ||
| popey | jibel: sil2100 is https://trello.com/c/qnhVyg2j/2936-1095-ubuntu-landing-050-ubuntu-ui-toolkit-bzoltan going to make OTA-10? It's blocking an update to music. | 12:59 |
| ahayzen | popey, not blocking an update to music, it makes the *current* app startup horrible, eg a regression :-) | 13:00 |
| === alan_g|lunch is now known as alan_g | ||
| popey | oh, yes, you're right! | 13:05 |
| popey | ^ jibel sil2100 :) | 13:05 |
| jibel | popey, it won't land unless bzoltan cherry picks the fix | 13:07 |
| popey | bzoltan: ^ | 13:07 |
| ahayzen | it is this bug specifically https://bugs.launchpad.net/ubuntu/+source/ubuntu-ui-toolkit/+bug/1554897 | 13:07 |
| ubot5` | Launchpad bug 1554897 in ubuntu-ui-toolkit (Ubuntu RTM) "App with dark background flickers temporarily to white at startup" [High,Fix committed] | 13:07 |
| bzoltan | popey: what UITK rev do you need? | 13:08 |
| popey | It causes a problem for "dark" apps like music and podbird | 13:08 |
| popey | music is more adversely affected as it takes a while to load, so it is very noticable. | 13:09 |
| popey | Also, being a default app we're breaking. | 13:09 |
| ahayzen | bzoltan, we need this fix https://code.launchpad.net/~tpeeters/ubuntu-ui-toolkit/fasterWindowColor/+merge/288661 | 13:09 |
| popey | ta ahayzen | 13:09 |
| ahayzen | revision 1895 of staging it landed | 13:09 |
| bzoltan | ahayzen: why now? OTA10 is closing. | 13:10 |
| ahayzen | because it has been in the queue for ages sortof expected it to be in ota10 :') | 13:10 |
| popey | it's a regression in ota-10 | 13:10 |
| ahayzen | and when it says "Description of landing: OTA10 landing" ... that sortof leads you to think it'll be in ota10... | 13:10 |
| bzoltan | ahayzen: popey: an OTA10 tag helps me to put it on our backlogs | 13:11 |
| ahayzen | yeah this one seems to have missed having the usual canonical-devices thing + a milestone | 13:13 |
| ahayzen | i think it was because it was found from the previous UITK silo while testing that | 13:14 |
| bzoltan | ahayzen: I can start pulling it in.. but it does take time.. only siloing and building takes ate least 24h if we are lucky | 13:14 |
| ahayzen | ugh :-/ | 13:14 |
| ahayzen | bzoltan, what's the reason that this silo isn't landing through QA? https://trello.com/c/qnhVyg2j/2936-1095-ubuntu-landing-050-ubuntu-ui-toolkit-bzoltan | 13:14 |
| bzoltan | jibel: how much time we have? | 13:15 |
| bzoltan | ahayzen: That is not the same silo :) | 13:15 |
| ahayzen | it includes that fix? no? | 13:15 |
| ahayzen | that was the one i was assuming was going to land... | 13:15 |
| bzoltan | ahayzen: it is the next landing and it does include that fix ... but it does include a regression too | 13:15 |
| === chihchun_afk is now known as chihchun | ||
| ahayzen | ah ! | 13:15 |
| popey | So, pick your regresion or fix both? | 13:16 |
| ahayzen | heh many options :-) | 13:16 |
| jibel | bzoltan, if you can have a silo with just this fix today it can land for OTA10 | 13:16 |
| bzoltan | popey: Fixing that silo will take a day | 13:16 |
| popey | So a cherry pick then? | 13:17 |
| bzoltan | jibel: today? the Automated Signoff will take a day if not two | 13:17 |
| popey | bzoltan: jibel this is what it looks like - from my phone running rc-proposed http://people.canonical.com/~alan/music.mkv | 13:26 |
| === chihchun is now known as chihchun_afk | ||
| bzoltan | popey: Confirmed | 13:28 |
| john-mcaleely | jibel, I believe this device landing is needed for adb. Anything needed for it to be 'ready for qa'? | 13:34 |
| john-mcaleely | jibel, https://requests.ci-train.ubuntu.com/#/ticket/1197 | 13:34 |
| john-mcaleely | I think I'm done with it | 13:34 |
| bzoltan | jibel: popey: the silo35 is chewing on it already | 13:40 |
| popey | heh, thanks. | 13:40 |
| bzoltan | popey: andf here comes the gles parade ... Mirv help me :) | 13:43 |
| rvr | tvoss: morphis: Silo 47 approved | 13:45 |
| Mirv | bzoltan: looks like your previous successful landing did not touch changelog at all https://code.launchpad.net/~bzoltan/ubuntu-ui-toolkit/applauncher-fixes-gles/+merge/288861 | 13:51 |
| Mirv | bzoltan: now it seems the train is increasing the number on every build and if you want to keep the changelog change maybe try .2 next... | 13:52 |
| tvoss | rvr, thank you | 13:56 |
| bzoltan | Mirv: i am running after an escaping number :) It is not going well | 14:06 |
| pmcgowan | sil2100, heya do we need a new custom tarball for mako? seems it hasnt been updated with the apps yet | 14:18 |
| sil2100 | pmcgowan: you mean the one in the BQ aquaris channel, yes? | 14:19 |
| sil2100 | Let me spin that one quickly | 14:19 |
| AlbertA | trainguards: could somebody retrigger the arm64+armhf builds in the xenial ppa: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-016/+packages | 14:27 |
| sil2100 | AlbertA: on it | 14:28 |
| rvr | mterry: Hi. How can I check the name set in the wizard? | 14:28 |
| mterry | rvr: you mean to confirm it got set correctly? "cat /var/lib/extrausers/passwd" should show the new name instead of "Ubuntu" | 14:29 |
| rvr | mterry: Ah, it does, great | 14:30 |
| mterry | rvr: or, if you are on a tablet, the greeter will show your name | 14:30 |
| mterry | rvr: awesome | 14:30 |
| mterry | rvr: that was a surprisingly annoying bug to fix :) | 14:31 |
| rvr | mterry: Because the image partition is usually ro? | 14:32 |
| ogra_ | /var/lib/extrausers/passwd is rw ;) | 14:32 |
| mterry | rvr: well the ro partition was part of it, but there were like 3 things that had to be fixed to get that right. Each time, I'd be like "got it!" and then it still wouldn't work | 14:32 |
| ogra_ | (and adduser respects that with the right options) | 14:33 |
| mterry | ogra_: but usermod didn't, had to fix it :-/ But should be good now | 14:33 |
| ogra_ | cant you just use adduser instead of usermod ? i think adduser can modify too | 14:33 |
| ogra_ | (academic though ... since you fined it :) ) | 14:34 |
| ogra_ | *fixed | 14:34 |
| mterry | ogra_: well this usage was more like passwd -- wants to try /etc/passwd and fallback to extrausers gracefully. And AccountsService was driving use of usermod, didn't want to hack/patch it to switch | 14:36 |
| ogra_ | passwd needs the --extrausers option | 14:37 |
| ogra_ | then it shoudl just ignore /etc/passwd | 14:37 |
| ogra_ | (for any write operations) | 14:37 |
| bzoltan | jibel: popey: in the silo50 I have a fix to help the flaky builds on Xenuial. I am not going to port that fix to the silo35, so you need to take the silo35 as it is.. or I keep pushing builds as long as it gets OK. But xenial armhf should not be an issue for you. | 14:40 |
| jibel | bzoltan, okay | 14:41 |
| mterry | ogra_: no... My memory is that adduser has an --extrausers option (because it doens't know where you want to add the new user). I didn't add that though. I do remember patching passwd (and now usermod) to fallback to checking extrausers if they can't find the provided user in /etc/passwd and extrausers exists (without any arguments, because the callers of | 14:41 |
| mterry | such programs rarely know where the user will be ahead of time) | 14:41 |
| ogra_ | hmm, i thought adduser simply hands the option through to passwd | 14:42 |
| ogra_ | but i might mis-remember that + | 14:42 |
| mterry | ogra_: I dunno. I didn't add the --extrausers support, not sure how that works | 14:42 |
| ogra_ | yeah, that was sergiuens | 14:42 |
| mterry | anyway, it should all work fine now | 14:43 |
| mterry | Until we find another low-level tool that doesn't know about extrausers :) | 14:43 |
| ogra_ | chfn doesnt | 14:46 |
| * ogra_ has that on the TODO to fix for snappy | 14:46 | |
| AlbertA | sil2100: thanks! is there something up with the arm64 builders? https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-016/+build/9414590 | 15:22 |
| AlbertA | I don't see a build log... | 15:22 |
| sil2100 | Now that's strange | 15:23 |
| sil2100 | cjwatson: hey! Could you take a look what happened with the build AlbertA posted above? ^ | 15:24 |
| sil2100 | We don't see the build-log for that | 15:24 |
| cjwatson | that happens if the builder died catsastrophically. retry | 15:24 |
| sil2100 | ACK | 15:25 |
| sil2100 | AlbertA: retried again | 15:25 |
| cjwatson | I have crappy networking right now and it would take ages to check further | 15:25 |
| AlbertA | cjwatson, sil2100: thanks gentleman :) | 15:25 |
| AlbertA | gentlemen even... | 15:25 |
| bzoltan | popey: jibel: the vivid UITK is there in the silo35. | 15:40 |
| bzoltan | popey: jibel: the gles amd package is acting up.. i rebuild | 15:40 |
| === tvoss is now known as tvoss|dinner | ||
| robru | Mirv: you're looking at the input merge. train generates gles changelog for you: http://bazaar.launchpad.net/~phablet-team/ubuntu-ui-toolkit/gles/revision/111 | 16:22 |
| jibel | Saviq, mterry 66 approved | 16:49 |
| bzoltan | jibel: popey: the silo35 is ready for you. i can not flip the approved flag because the xenial armhf failed | 17:00 |
| bzoltan | jibel: but if you want to release it the packages are there | 17:00 |
| jibel | bzoltan, thanks, I'll force the flag | 17:01 |
| jibel | ah I cannot if the build failed on one target | 17:02 |
| jibel | bzoltan, this will land as part of silo 50 on xenial? | 17:03 |
| bzoltan | jibel: the silo50 has other fixes... including the build stability | 17:04 |
| bzoltan | jibel: not easy to cherry pick :) | 17:04 |
| jibel | bzoltan, yes, I mean silo 35 won't be published to xenial? | 17:04 |
| bzoltan | jibel: I do not need it on xenial | 17:04 |
| jibel | bzoltan, fine, thanks | 17:04 |
| bzoltan | jibel: I keep the dual landing because of the version clarity | 17:05 |
| jibel | understood, not sure how the publication will work | 17:05 |
| bzoltan | jibel: this change would fix the xenial armhf build http://bazaar.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/staging/revision/1913 But it tcan wait with the next real landing | 17:07 |
| jibel | sil2100, ^ will this work? land only on vivid a dual landing silo? | 17:08 |
| === alan_g is now known as alan_g|EOD | ||
| Saviq | jibel, great, thanks | 17:15 |
| Saviq | mterry, can you publish please https://requests.ci-train.ubuntu.com/#/ticket/1186 | 17:15 |
| dobey | trainguards: can someone hit https://autopkgtest.ubuntu.com/request.cgi?release=vivid&arch=armhf&package=unity-scope-click&trigger=unity-scope-click%2F0.1.1%2B15.04.20160330-0ubuntu1&ppa=ci-train-ppa-service%2Fstable-phone-overlay&ppa=ci-train-ppa-service%2Flanding-075 please? | 18:16 |
| dobey | or kenvandine ^^ :) | 18:16 |
| mterry | Saviq: sorry was at gym, looks like it still needs publishing? | 18:19 |
| robru | dobey: sorry, you need somebody with upload rights, train guards have no power there. maybe mterry ^ | 18:20 |
| dobey | well, sil2100 has the power i guess, but yeah | 18:21 |
| mterry | robru, dobey: done | 18:21 |
| dobey | thanks mterry | 18:21 |
| robru | dobey: right but that's because he's a core dev and not because he's a train guard | 18:21 |
| dobey | sure | 18:22 |
| dobey | but a motu would be fine here too; i didn't know if you were motu or not (i guess not) :) | 18:23 |
| === boiko_ is now known as boiko | ||
| robru | dobey: yeah I got nuthin | 18:30 |
| rvr | bzoltan: Hi. Silo 35... I still see the menu bar turning white briefly with silo 35 installed https://private-fileshare.canonical.com/~vrruiz/top-bar-white.mp4 | 18:33 |
| rvr | bzoltan: Although problem is gone for music app | 18:33 |
| * mterry feeds queuebot a cookie | 20:11 | |
| === salem_ is now known as _salem | ||
| alecu | ping trainguards | 21:32 |
| alecu | hi! I can't understand what failed here: https://requests.ci-train.ubuntu.com/#/ticket/1204 | 21:32 |
| robru | alecu: there's a unity8 autopkgtest failure in xenial. | 21:33 |
| alecu | I see a regression for the autopkgtest for unity8, but the revert in the silo should not be causing that | 21:33 |
| alecu | robru: right... | 21:33 |
| alecu | robru: is there a way to retry? | 21:34 |
| alecu | should I just try rebuilding? | 21:34 |
| robru | alecu: no | 21:35 |
| robru | that is the worst thing you can do, extremely wasteful | 21:35 |
| robru | alecu: I guess there's some problem with unity8's autopkgtests, I don't really understand it, just ask QA nicely to add your silo to the queue | 21:36 |
| alecu | robru: will do, thanks. | 21:36 |
| robru | alecu: assuming you're ready to release I mean | 21:36 |
| robru | you're welcome | 21:36 |
| alecu | I guess ToyKeeper is the one to ask in this timezone... | 21:37 |
| robru | yeah I think so | 21:37 |
| ToyKeeper | Hmm? | 21:37 |
| alecu | robru: we are ready to release, thanks. | 21:37 |
| ToyKeeper | The silo bot should pick it up soon and add it to the QA queue. | 21:38 |
| robru | ToyKeeper: no because britney is hung up on an unrelated unity8 autopkgtest failure, so the whole thing is marked as "failed" and won't get into the queue on it's own. needs to be poked | 21:40 |
| ToyKeeper | I'd have to double-check, but I think the QA silo bot only cares about the "QA Signoff=Ready" flag. | 21:40 |
| robru | ToyKeeper: that's what I'm saying, it won't get to ready because the autopkgtests are failed. | 21:41 |
| ToyKeeper | Ah, and there it is. | 21:41 |
| alecu | ToyKeeper: yes, it just showed up on the Trello board. Thanks!!! | 21:41 |
| ToyKeeper | Er, [15:38:12] -queuebot/#ubuntu-ci-eng- dobey, https://requests.ci-train.ubuntu.com/#/ticket/1204 QA Signoff: Ready | 21:41 |
| ToyKeeper | ^^^ That triggered the trello bot to add it. | 21:42 |
| robru | ToyKeeper: uh ok, I don't understand how it approved that considering the glaring unity8 autopkgtest failure, this doesn't make any sense. | 21:42 |
| ToyKeeper | I don't know how it got marked as ready, but that's all the trello bot cares about. It assumes any other details are handled elsewhere. | 21:43 |
| ToyKeeper | If a human overrides the other bots and marks it as ready, the QA bot will pick it up. | 21:44 |
| robru | oh the unity8 failure went away *just now*, huh | 21:45 |
| ToyKeeper | Anyway, I moved it to the top of the queue and marked it green. | 21:46 |
| alecu | yay, thanks robru, ToyKeeper! | 21:48 |
| ToyKeeper | I helped break it, so I kinda want to get it fixed quickly... | 21:49 |
| robru | alecu: you're welcome | 21:49 |
| Saviq | robru, can you please force-merge https://requests.ci-train.ubuntu.com/#/ticket/1186 - we need a follow up packaging thing to unstick those from proposed | 22:26 |
| Saviq | https://requests.ci-train.ubuntu.com/#/ticket/1206 would be the follow-up (just packaging changes) | 22:27 |
| robru | Saviq: sure. Sorry about the testsuite thing, i tried backporting dpkg from vivid to trusty to fix this but it fails to compile for no discernable reason. Not sure how to proceed other than migrating the train to xenial, which won't happen for a few months yet. | 22:32 |
| robru | Saviq: pitti was saying it needs to be XS-Testsuite because trusty dpkg doesn't support Testsuite at all. | 22:33 |
| Saviq | robru, that's fine, we shoulda had it explicit in any case | 22:34 |
| Saviq | robru, ack, lemme fix | 22:34 |
| Saviq | robru, well, you could build the source packages in a minimal xenial chroot (I know you don't wanna :)) | 22:35 |
| robru | Saviq: i just spent weeks ripping all the chroots out :-P | 22:36 |
| Saviq | robru, I wanna talk to you about one more thing at some point - how do we share code between train and jenkaas - after all a whole lot of what we need in CI train is doing, too | 22:37 |
| robru | Saviq: what kind of code do you want to share? | 22:37 |
| Saviq | robru, everything up to (and maybe including) building packages | 22:38 |
| robru | Saviq: i don't understand what that even means. All the train does is build packages. | 22:38 |
| Saviq | robru, yup ;) | 22:38 |
| Saviq | robru, fetch code from branches, build source packages, build binary packages, run autopkgtests - that's really the extent of what our jenkins instance is doing | 22:39 |
| Saviq | some teams have a little more built on top | 22:40 |
| robru | Saviq: train does not build binary packages or run autopkgtests, that's all handled remotely. | 22:40 |
| robru | Saviq: i don't really understand what jenkaas is even doing for you, it sounds like you just want more silos. | 22:41 |
| Saviq | robru, for one, it's triggered on MP changes | 22:41 |
| Saviq | robru, for two, we have touch devices to run autopilot tests on in there | 22:42 |
| Saviq | robru, three - we can build much faster than PPAs by cutting corners (ccache, prepopulated chroots etc.) | 22:42 |
| Saviq | robru, four - report on MPs | 22:42 |
| Saviq | robru, five - autolanding | 22:42 |
| Saviq | robru, six - custom things on top | 22:42 |
| robru | Saviq: yeah I'm not sure what to say. I don't see how they could share any code. I'm in the middle of tearing everything apart, no way I'm ready to handle any sort of stable api that other services could consume. | 22:42 |
| Saviq | robru, which is why I said we ~"have to talk at some point" | 22:43 |
| robru | Saviq: autolanding is the opposite of what the train does. That merges to trunk when branches are approved, doesn't wait for packages to publish. | 22:43 |
| Saviq | robru, you don't need to explain the differences to me :) | 22:44 |
| Saviq | robru, I just mean there's a lot of overlap which I'd really like to get rid of | 22:44 |
| Saviq | nothing that needs to happen any time soon | 22:44 |
| robru | Saviq: there's just a huge and bizarre impedance mismatch here, they're different tools that have different work flows and age only superficially similar. | 22:44 |
| Saviq | robru, I don't want to take the whole of train and shove it into jenkaas | 22:45 |
| Saviq | robru, but there are discrete work items that both need to do, and those common bits can arguably be abstracted to benefit both | 22:46 |
| robru | Saviq: it sounds like you want jenkaas to create tickets and trigger builds for you. | 22:46 |
| robru | Saviq: one thing i could consider is making silos auto-rebuild when new commits are detected but i worry that might not quite be what people want, eg rebuilding all conflicting silos when one merges. | 22:47 |
| Saviq | robru, that was an idea at some point, but the latency of train is too big IMO for the MP level - we need as quick turnaround as possible | 22:47 |
| Saviq | robru, no, train is good as is - I would just like to share the code that has the same result on both sides | 22:48 |
| robru | Saviq: right, I'm working on reducing the latency, parallelism is coming soon so each build will only take a couple minutes | 22:48 |
| robru | Saviq: OK, well think about specifically what features you'd need because i can't even picture really what bits you're wanting. | 22:49 |
| Saviq | robru, fetch code, build source packages - that at least | 22:49 |
| Saviq | robru, later, maybe, dealing with ephemeral PPAs where appropriate | 22:50 |
| robru | Hmm | 22:50 |
| robru | Once that code is even written :-P | 22:50 |
| Saviq | robru, yup :) | 22:50 |
| Saviq | robru, in the mean time, would you please be so kind as to review the two unreviewed branches in https://requests.ci-train.ubuntu.com/#/ticket/1206 | 22:51 |
| robru | Saviq: OK well the new paradigm is that everything is a super simple shell script so i might be able to commit to an api in there and you could just invoke the shell script for the steps you need rather than having to have a full train deployment | 22:51 |
| Saviq | robru, that's my thinking exactly | 22:52 |
| Saviq | robru, btw, not sure if you saw my twist to inline gles: https://code.launchpad.net/~unity-team/qtmir/inline-gles-quilt/+merge/290061 | 22:52 |
| robru | Saviq: you apparently didn't see my review | 22:54 |
| robru | ;-) | 22:54 |
| Saviq | robru, :) | 22:54 |
| Saviq | just noticed the wrong sed, too | 22:54 |
| robru | Saviq: nice approach though. I wonder if it might make sense to just make the train do the quilt and then let packages supply their patches. From a security perspective it'd be nicer than running arbitrary scripts. | 22:58 |
| Saviq | robru, https://code.launchpad.net/~unity-team/qtmir/inline-gles-quilt/+merge/290061/comments/743560 | 22:59 |
| Saviq | robru, I don't see a reason why not - the sed on changelog can be automated, too so | 23:00 |
| Saviq | robru, one disadvantage would be for people to do it locally | 23:00 |
| Saviq | they'd need to do the sed manually | 23:01 |
| robru | Right | 23:02 |
| robru | Hmm | 23:02 |
| robru | Saviq: maybe write some docs about how you generated the patch in the first place? I find quilt strange and fiddly to work with. | 23:06 |
| Saviq | robru, oh easy, export QUILT_PATCHES=debian/gles-patches; quilt new convert-to-gles.patch; quilt add debian/*; # do your thing; quilt refresh | 23:09 |
| Saviq | robru, then, when you want to update: quilt push -af; # fix up; quilt refresh; quilt pop -a | 23:09 |
| Saviq | robru, but yeah, I'll add something to the branch | 23:10 |
| Saviq | especially on the "how to update" bit | 23:10 |
| * Saviq found it frustrating that ~/.quiltrc takes precedence over QUILT_PATCHES to be honest | 23:11 | |
| robru | Saviq: maybe I'll leave it as a script since I already have the infrastructure for running hooks, and then if somebody can get away with just having a sed, they're not forced to use quilt at all. | 23:12 |
| robru | Saviq: I should probably decouple this gles stuff from the giant monster branch I'm working on... | 23:12 |
| Saviq | robru, can you change https://requests.ci-train.ubuntu.com/#/ticket/1206 to QA: N/A? it's only dumb packaging changes | 23:50 |
| robru | Saviq: heh, ok | 23:51 |
| robru | Saviq: why are you dropping the testsuite header from qtmir> | 23:51 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!