| === Ursinha-afk is now known as Ursinha | ||
| === henrix_ is now known as henrix | ||
| JackYu | hi release team, who could help to review the FFE at bug #1293299? | 12:06 |
|---|---|---|
| ubot2 | Launchpad bug 1293299 in Ubuntu "[FFE]upload ubuntu-kylin-software-center into archive" [Undecided,Confirmed] https://launchpad.net/bugs/1293299 | 12:06 |
| jamespage | any release team members around? I could do with an opinion on the delay from upstream to bug 1278466 | 12:11 |
| ubot2 | Launchpad bug 1278466 in ceph (Ubuntu Trusty) "[FFe] ceph firefly stable release" [High,New] https://launchpad.net/bugs/1278466 | 12:11 |
| jamespage | opinion/chat on options | 12:11 |
| === agateau_ is now known as agateau | ||
| jamespage | stgraber, Laney, Daviey: any of you around to discuss how I dig us out of bug 1278466 | 15:34 |
| ubot2 | Launchpad bug 1278466 in ceph (Ubuntu Trusty) "[FFe] ceph firefly stable release" [High,New] https://launchpad.net/bugs/1278466 | 15:34 |
| jamespage | ? | 15:34 |
| sergiusens | can I get some eyes on https://bugs.launchpad.net/ubuntu/+bug/1290360 ? | 15:57 |
| ubot2 | Launchpad bug 1290360 in Ubuntu "[FFe] New Ubuntu Touch specific package: media-hub" [Undecided,New] | 15:57 |
| Laney | jamespage: would it be bad to keep the current version? | 15:58 |
| Laney | I'm not familiar with ceph, I'm afraid | 15:58 |
| jamespage | Laney, well the current version is a stable release, but it won't get support for as long as the firefly release | 16:02 |
| jamespage | Laney, hence the intent to ship with firefly; but upstream dates have slipped; they don't want to mark it for long term support until they are happy with it | 16:03 |
| Laney | jamespage: Indeed, so the risk is shipping with a buggy version | 16:03 |
| Laney | Daviey's suggestion of updating post-release might work if the SRU team thinks that is acceptable | 16:04 |
| Daviey | jamespage: hey o/ | 16:05 |
| jamespage | Daviey, hey | 16:05 |
| Daviey | jamespage: Could you respond to the options on the bug? | 16:06 |
| jamespage | yes | 16:06 |
| jamespage | Daviey, updated - also discussing with sage upstream who suggested the same approach re using the 0.78/0.79 releases as rc's (which in effect they are) for firefly | 16:22 |
| Daviey | jameapage, thanks - reaponded | 16:29 |
| jamespage | Daviey, I've asked sage to engage directly on that bug report | 16:47 |
| Daviey | jamespage, great | 17:20 |
| zequence | highvoltage: Hi. Did you do another upload of ubuntustudio-live, by any chance? | 19:46 |
| highvoltage | zequence: yep, yesterday | 19:46 |
| zequence | highvoltage: Ah, thanks :) | 19:46 |
| highvoltage | zequence: you're welcome | 19:46 |
| jdstrand | infinity: hey, I'd like you opinion on whether our pending apparmor upload needs a FFe | 19:59 |
| jdstrand | infinity: basically, I went through sarnold's debdiff and believe that the new upstream release does not warrant a FFe | 20:00 |
| jdstrand | infinity: in essence we are trimming some 80 patches and using an upstream version. the upstream version has refactoring, code, cleanups, some rewrites, etc, but no new features | 20:00 |
| jdstrand | infinity: however, it does include a python rewrite of the user space tools | 20:01 |
| jdstrand | infinity: which is the bit that I think is gray | 20:01 |
| jdstrand | infinity: the current perl tools in 2.8.0 are a rather significant pile of poo | 20:01 |
| jdstrand | infinity: the python tools are somewhat better, and work at least as well (except for two issues we will be fixing shortly) | 20:02 |
| jdstrand | infinity: we want the python tools for the LTS cause they are supportable. the perl ones are not. ie, we might actually be able to do SRUs for trusty to make them better | 20:03 |
| jdstrand | infinity: another thing to note is that the perl tools are highly broken right now | 20:03 |
| jdstrand | infinity: so much so that people aren't really using them | 20:04 |
| jdstrand | infinity: so my feeling is that the python tools, while a total rewrite, do not consitute a FFe because they offer no new functionality and are tested to work as well or better than the perl tools | 20:05 |
| jdstrand | infinity: I should also mention that the tools aren't used on the images (though they are in the supported seed) | 20:06 |
| jdstrand | infinity: bonus point> the python tools have something of a testsuite where the perl ones do not | 20:07 |
| infinity | jdstrand: I think that does warrant an FFe, but I'm happy to grant a verbal one. Are the python tools in feature parity with the perl ones? | 20:07 |
| jdstrand | infinity: what are your thoughts on doing an FFe? I would argue 'no', but can understand the release team saying 'yes' | 20:07 |
| jdstrand | infinity: yes | 20:08 |
| infinity | I assume this is 'apparmor-utils'? | 20:08 |
| jdstrand | yes | 20:08 |
| infinity | Yeah, that's not seeded anywhere outside supported, so happy to not care about the language switch, etc. | 20:09 |
| infinity | (If that was in the base system, we might have words...) | 20:09 |
| jdstrand | sure | 20:09 |
| infinity | jdstrand: If you guys have tested this all and have a high degree of confidence, I'm fine with it. | 20:09 |
| jdstrand | I would've just filed an FFe in that case :) | 20:09 |
| infinity | jdstrand: Are the any backward compat issues, or will this all work sanely with older kernels? | 20:09 |
| jdstrand | infinity: ok, thanks! should I file a bug with that in it or not worry about it? | 20:09 |
| jdstrand | infinity: all backward compatible | 20:10 |
| infinity | jdstrand: No need for a bug, just point people at me if they ask. | 20:10 |
| jdstrand | infinity: thanks for your help | 20:10 |
| infinity | jdstrand: And if this is the upload that makes debhelper stop depending on python, even better. :P | 20:11 |
| jdstrand | infinity: it is that upload :) | 20:13 |
| infinity | jdstrand: \o/ | 20:13 |
| jdstrand | we are no targeting tomorrow | 20:13 |
| jdstrand | s/no/now/ | 20:13 |
| infinity | jdstrand: Given the (actually, rather large) impact that has on build-deps for most of the archive, I'd probably support backporting that small change (the dep removal and doc/string change) to previous releases too. | 20:14 |
| infinity | Though, if it was only in a non-LTS, meh, they're all gone soon anyway. | 20:14 |
| infinity | And, yeah, that happened post-precise, so whatever. | 20:15 |
| jdstrand | yeah | 20:15 |
| infinity | Looks like it happened in saucy. | 20:16 |
| infinity | I dunno, a backport of that small bit as an SRU might still be appreciated, so the behaviour is consistent. | 20:16 |
| infinity | I'm guessing it's a whopping 3 or 4 lines. | 20:16 |
| jdstrand | infinity: sorry it took so long btw-- we expected it to happen a bit ago, but then found some issues, UDS, etc. one of those things where we thought we were going to upload, then like "ah, we'll fix that', oh, and that :) | 20:16 |
| jdstrand | it isn't much | 20:17 |
| * jdstrand adds to todo | 20:17 | |
| infinity | jdstrand: I understand, I have a backlog of things for this cycle that all fit that profile. Some will make it, many won't. :/ | 20:17 |
| jdstrand | yeah | 20:17 |
| jdstrand | it's like that sometimes | 20:17 |
| robru | infinity, cjwatson: ping about unity-chromium-extension in -proposed. Seems there's no chromium-browser for arm64, powerpc, and ppc64el. Should I limit the arches then, or are we expecting a powerpc chromium port shortly? | 20:44 |
| infinity | robru: Or build-dep on chromium-browser, and let it sort itself. | 20:45 |
| robru | infinity, excellent | 20:46 |
| infinity | (Not quite ideal, as that's a heavy build-dep, but it ends up expressing what you want: only building on arches that have the package) | 20:46 |
| robru | infinity, yes it's quite clever, much better than hard-coding arches. | 20:47 |
| robru | thanks | 20:47 |
| infinity | Sort of curious how you can have a testsuite that tests a browser extension without having the browser installed anyway. :) | 20:47 |
| robru | infinity, oh yeah, that huge test suite that totally exists, yeah, that one is quite thorough. ;-) | 20:47 |
| infinity | robru: Well, it *had* a testsuite. Just not clear on what it tests. :) | 20:49 |
| infinity | robru: Anyhow, if you upload with the build-dep change, let me know. I'll have to clear the crufty binaries out for it to migrate. | 20:49 |
| robru | infinity, yeah, the tests for that one are very error prone and flaky, also difficult to set up the test environment. very manual, doesn't get run at build time. | 20:49 |
| infinity | But I'd rather do that after you change it to not build there. | 20:49 |
| robru | infinity, ok, doing an MP for that now. will have to rebuild & republish the silo. will ping you in an hour or so | 20:50 |
| infinity | robru: The CI stuff may give you a grumpy face about it regressing on those arches. Not sure how one forces that, but I assume you know how. | 20:50 |
| robru | infinity, CI Train doesn't care about arch regressions, it's just -proposed that does that as far as I know | 20:51 |
| infinity | Oh, handy. | 20:51 |
| infinity | I guess. | 20:51 |
| infinity | I'd like to think it cares enough to not copy things out when builds fail... | 20:51 |
| robru | infinity, heh, nope. I publish stuff with certain arches failed all the time. | 20:53 |
| infinity | Fun. | 20:53 |
| robru | infinity, in fact we've been largely steamrolling over ppc64el, powerpc, and arm64 all along. It's only getting cleaned up now because cjwatson is working on it. | 20:55 |
| infinity | robru: Oh, no, but you were steamrolling in the past because they weren't regressions. | 20:55 |
| infinity | robru: My assumption was thet ci-train should care about regressions. | 20:55 |
| infinity | robru: If it doesn't, that seems like a pretty fundamental flaw for something labelled CI. | 20:56 |
| infinity | Anyhow, we'll see how your unity-chrome-thingee upload pans out. | 20:56 |
| robru | infinity, hmm, maybe I'm not familiar with that part. When we check for "regressions", it's to do with test failures that didn't fail before. I never saw anything outside of -proposed that cared about arches. | 20:56 |
| robru | infinity, let's just say, -proposed is part of CI process ;-) | 20:59 |
| infinity | robru: Arguably the most important part, yes. Though some other people who work hard on the other bits might disagree. :P | 21:00 |
| cjwatson | robru: you weren't *able* to steamroller over them in the cases where they actually mattered; however the lack of qtdeclarative on those arches with Qt 5.0 meant you didn't see much of it | 21:04 |
| robru | right | 21:05 |
| cjwatson | ci-train does sort of care, it's just overrideable | 21:05 |
| === retoaded is now known as retoaded_afk | ||
| robru | infinity, this seems to be the expected result in the PPA, is it not? https://launchpad.net/~ci-train-ppa-service/+archive/landing-006/+sourcepub/4029222/+listing-archive-extra if so, please clear out those binaries like you said and I'll publish shortly | 21:55 |
| infinity | robru: Publish away. | 21:55 |
| robru | infinity, thanks! | 21:56 |
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!