=== doko_ is now known as doko [07:59] livecd-rootfs fixes ubuntu-touch build failures [08:00] not totally sure why that's still hardcoded, but not investigating that at 9am on a Saturday [08:19] There's one merge and three rebuilds needed for Perl 5.20.1, that I know about. Staging in my PPA [08:26] And landing [08:28] (libpar-packer-perl was auto-accepted) [11:19] can someone please let this in ^^^^ so we get working touch images again [12:26] stgraber, are you around ? we have a bad image on s-i [12:26] infinity: slangasek: stgraber: cjwatson: ^^ [12:26] ogra_: whoelse? [12:26] there must be more [12:27] asac, dunno, LP should know who is -release [12:27] Laney: ^ [12:27] ScottK: Riddell: ^^ [12:28] tumbleweed: ^^ [12:28] please check with ogra - emergency [12:29] https://launchpad.net/~ubuntu-release/+members [12:50] I could approve that, but I can't do anything about building new images [12:50] tumbleweed, i can ... we just need that in [12:51] ogra_: I've seen situations where ^ii isn't exactly what is wanted, and ^.i is more accurate, but I assume you've tested this or, we use similar constructions elsewhere in that file [12:51] tumbleweed: pleae approve!! [12:51] thanks! [12:51] tumbleweed, yes i tested that on a running system [12:52] ok, approved [12:52] (it will need smoe correction next week to not hardcode the 8 and 3 in the package names, but for an emergency fix it is good right now) [12:53] \o/ [14:05] SRU team, please release the above menulibre into trusty-proposed so we can begin verification [14:05] xfdesktop MRE has also been sitting in an unaccepted state for a while now, https://bugs.launchpad.net/ubuntu/+source/xfdesktop4/+bug/1365965 [14:05] Launchpad bug 1365965 in xfdesktop4 (Ubuntu) "[MRE] Please update xfdesktop4 to 4.11.8 in Trusty" [Undecided,In progress] [14:06] please let me know if there are any questions :-) [14:22] tumbleweed: There aren't just some situations, ^.i is *always* what you want, unless you're actually testing for the desired state (which nearly no one is) [14:22] tumbleweed: Luckily, in the case of livecd-rootfs, it's pretty unlikely that a package will be on hold, etc. [14:23] ogra_: post-accept review of that upload. Why are you manually setting the alternative if you've also made sure the right packages are installed? Seems redundant? [14:24] infinity, i didnt make sure the right packages are installed ... there is dependency breakage that pulled the -mesa packages in additionally [14:24] ogra_: Oh, you mean you're getting both now? [14:24] infinity, and depending on the order apt installs tem in the chroot you might end up with the wrong alternative [14:24] right [14:24] Gross. [14:24] Please fix that? Having useless packages installed is silly. [14:25] we need to fix the dep ... but i cant do a quick upload of mir [14:25] * infinity nods. [14:25] so as emergency fix forcing the alternative is ok [14:25] Yeah, that's fine, as long as the better fix is on the TODO. [14:25] and long term it will save us from the same issue if -mesa slips in again [14:26] (well, after i fixed the matching in the code ... that hardcoded numbers in tteh package names indeed need to go) [14:26] for now getting the phones out there to boot again is #1 prio :) [14:26] ogra_: And the other bit, tumbleweed's mention of ^.i instead of ^ii is true. We don't actually have anything on the livefses that's in a state other than ^i, but who knows if someone might decide to change that for some specific image for some weird reason, even if just a temp hack in a hook. Better to always use the form that means what you want. [14:26] ogra_: But also not a big deal. [14:27] well, i shoul dprobably drop the whole check [14:27] so that the build actually fails if the -android packages are not there [14:27] * infinity nods. [14:27] It's also, again, redundant because you ask for them by name in the install pass. [14:27] but it felt safer for an emergency fix to do it with a check for the moment [14:27] But I imagine seeds might eventually do that right and you'll remove that. [14:28] right [14:28] But yes, checking if a package is installed before doing a mandatory thing with it will miss errors, as you say. [14:28] well, i would like to keep forcing the alternative to make it future proof, as i said [14:29] Could you not just make the android alternative prio higher? [14:29] This is one of those cases where I can't see why a desktop user would ever install the android package. [14:29] So it's safe to assume that if you install the android one, that's the one you want to win. [14:34] yeah, i dont think our issue are the desktop users that install stuff ... but the desktop-next seed [14:34] (which needs to use mesa) [14:35] theoretically there should always be a seed entry for -android in touch and -mesa in desktop-next [14:35] but if the package gets updated without seed change alongside such crap can happen [21:22] infinity: what I meant was situations where it ^ii doesn't work at all :)