| -queuebot:#ubuntu-release- New: accepted libcryptx-perl [arm64] (bionic-proposed) [0.054-1] | 00:12 | |
| -queuebot:#ubuntu-release- New: accepted radare2 [amd64] (bionic-proposed) [2.1.0+dfsg-1] | 00:12 | |
| -queuebot:#ubuntu-release- New: accepted radare2 [armhf] (bionic-proposed) [2.1.0+dfsg-1] | 00:12 | |
| -queuebot:#ubuntu-release- New: accepted radare2 [ppc64el] (bionic-proposed) [2.1.0+dfsg-1] | 00:12 | |
| -queuebot:#ubuntu-release- New: accepted libcryptx-perl [s390x] (bionic-proposed) [0.054-1] | 00:12 | |
| -queuebot:#ubuntu-release- New: accepted radare2 [i386] (bionic-proposed) [2.1.0+dfsg-1] | 00:12 | |
| -queuebot:#ubuntu-release- New: accepted radare2 [arm64] (bionic-proposed) [2.1.0+dfsg-1] | 00:12 | |
| -queuebot:#ubuntu-release- New: accepted radare2 [s390x] (bionic-proposed) [2.1.0+dfsg-1] | 00:12 | |
| -queuebot:#ubuntu-release- New: accepted cardo [amd64] (bionic-proposed) [1.04-1] | 00:13 | |
| -queuebot:#ubuntu-release- New: accepted liblocale-codes-perl [amd64] (bionic-proposed) [3.55-1] | 00:13 | |
| -queuebot:#ubuntu-release- New: accepted gnocchi [amd64] (bionic-proposed) [4.1.1-0ubuntu1] | 00:13 | |
| -queuebot:#ubuntu-release- New: accepted node-ms [amd64] (bionic-proposed) [2.0.0-1] | 00:13 | |
| -queuebot:#ubuntu-release- New: accepted adlibtracker2 [i386] (bionic-proposed) [2.4.23-1] | 00:17 | |
| -queuebot:#ubuntu-release- New binary: scalapack [ppc64el] (bionic-proposed/universe) [2.0.2-3ubuntu1] (no packageset) | 02:23 | |
| -queuebot:#ubuntu-release- New binary: scalapack [i386] (bionic-proposed/universe) [2.0.2-3ubuntu1] (no packageset) | 02:34 | |
| -queuebot:#ubuntu-release- New: accepted scalapack [i386] (bionic-proposed) [2.0.2-3ubuntu1] | 02:37 | |
| -queuebot:#ubuntu-release- New: accepted scalapack [ppc64el] (bionic-proposed) [2.0.2-3ubuntu1] | 02:37 | |
| -queuebot:#ubuntu-release- New binary: scalapack [amd64] (bionic-proposed/universe) [2.0.2-3ubuntu1] (no packageset) | 02:39 | |
| -queuebot:#ubuntu-release- New binary: scalapack [s390x] (bionic-proposed/universe) [2.0.2-3ubuntu1] (no packageset) | 02:39 | |
| -queuebot:#ubuntu-release- New: accepted scalapack [amd64] (bionic-proposed) [2.0.2-3ubuntu1] | 03:23 | |
| -queuebot:#ubuntu-release- New: accepted scalapack [s390x] (bionic-proposed) [2.0.2-3ubuntu1] | 03:23 | |
| tsimonq2 | slangasek: Could you please review this (this is similar to v5 stuff, which is why I ask) to make sure I did things right? https://launchpad.net/~tsimonq2/+archive/ubuntu/universe-upload-testing/+sourcepub/8528605/+listing-archive-extra | 03:38 |
|---|---|---|
| tsimonq2 | Can someone please kick nodejs into bionic-release? The three autopkgtests that fail are all bad, I just verified all three against themselves: https://autopkgtest.ubuntu.com/packages/node-chokidar/bionic/s390x https://autopkgtest.ubuntu.com/packages/node-platform/bionic/s390x https://autopkgtest.ubuntu.com/packages/node-yargs/bionic/armhf | 04:57 |
| -queuebot:#ubuntu-release- New binary: qhull [i386] (bionic-proposed/universe) [2015.2-3] (kubuntu) | 05:12 | |
| -queuebot:#ubuntu-release- New binary: qhull [s390x] (bionic-proposed/universe) [2015.2-3] (kubuntu) | 05:12 | |
| -queuebot:#ubuntu-release- New binary: qhull [ppc64el] (bionic-proposed/universe) [2015.2-3] (kubuntu) | 05:12 | |
| -queuebot:#ubuntu-release- New binary: qhull [amd64] (bionic-proposed/universe) [2015.2-3] (kubuntu) | 05:13 | |
| -queuebot:#ubuntu-release- New binary: qhull [armhf] (bionic-proposed/universe) [2015.2-3] (kubuntu) | 05:13 | |
| -queuebot:#ubuntu-release- New binary: qhull [arm64] (bionic-proposed/universe) [2015.2-3] (kubuntu) | 05:13 | |
| -queuebot:#ubuntu-release- New binary: r-cran-drr [amd64] (bionic-proposed/none) [0.0.2-1] (no packageset) | 05:13 | |
| infinity | stgraber: Feel like investigating and fixing the lxcfs autopkgtest failures on s390x? I'm going through a list of "stuff that fails now that s390x provides isolation-machine", but I don't think "just ignore it" is the right answer for lxc stuff. :P | 05:47 |
| === maclin1 is now known as maclin | ||
| slangasek | tsimonq2: +1 on the opencsg revert | 05:52 |
| slangasek | tsimonq2: (I've only looked at the archive state to confirm that a revert + provides is sane; I haven't double-checked the debian/control of the package you uploaded there) | 05:53 |
| slangasek | infinity: good news, probably? I think at this rate arm64 is going to catch up with the backlog tonight/tomorrow | 05:59 |
| infinity | slangasek: Which means I can SRU glibc! | 06:00 |
| slangasek | was that the plan?: ) | 06:00 |
| infinity | (And we can use that as a reasonable benchmark for which queues suck the least) | 06:00 |
| infinity | slangasek: There's a pending glibc SRU, yes, but I've been holding off for the queues to empty. | 06:00 |
| slangasek | k | 06:01 |
| infinity | It should also double as a painful way for us to reset large chunks of the s390x baseline. | 06:01 |
| infinity | Which we might have to do with manually editing state or something, cause I don't want to carry a bunch of "this now fails with isolate-machine, lolz" hints forever. | 06:01 |
| slangasek | hey, there's still that proposed change to britney that would magically fix this for all regressions in release pocket | 06:02 |
| infinity | The "testbed is now better and your test sucks" case feels like it could be handled more elegantly in a few places. | 06:04 |
| infinity | I mean, we *have* the info to know that the test was previously skipped due to testbed restrictions, thus never actually "passed". | 06:04 |
| infinity | But we're taking pass/fail at a lower granularity. | 06:04 |
| slangasek | right | 06:04 |
| infinity | But rather than rewriting everything to do test-level ganularity (which has other issues, like tests disappearing), this feels like perhaps the domain of a one-time clean-up script. | 06:07 |
| infinity | Check old passes, record skips, check new failures, compare, if same, twiddle old passes to fail. | 06:07 |
| infinity | Or some such. | 06:07 |
| slangasek | infinity: which would mean twiddling the statuses in swift aiui | 06:09 |
| infinity | slangasek: Would it? Does britney not have its own internal idea of the current state? It can't possibly be hitting all the history in autopkgtest every time until it walks back to a success. | 06:12 |
| infinity | (If it is, ew?) | 06:12 |
| slangasek | infinity: if it didn't, it would overlook new passes of the test that happened after the triggering package was uploaded; and I know in fact it doesn't, even though sometimes it would be more sensible if it did | 06:13 |
| infinity | The britney<->debci interface probably needs a complete rewrite. I'm not volunteering. :/ | 06:15 |
| infinity | The largest portion of britney runs is also the 8 billion http requests to debci now. | 06:15 |
| infinity | There should surely be a way to consolidate that into one range request or something more clever. | 06:16 |
| slangasek | perhaps britney should just pull down the sqlite database | 06:16 |
| infinity | slangasek: Other than the part where I suspect sqlite databases are arch-specific, that's not the dumbest dumb idea I've ever heard. | 06:18 |
| slangasek | arch-specific meaning on-disk format? | 06:18 |
| infinity | (If they're not arch-specific, they would be missing a ton of low-hanging optimisations in their binary format, and I don't think the sqlite upstream are that silly) | 06:18 |
| infinity | slangasek: Yeah. | 06:18 |
| slangasek | not sure | 06:18 |
| slangasek | I thought they were meant to be portable | 06:18 |
| infinity | slangasek: And, sure, we happen to be amd64 in both places, but that's not a thing I'd like to rely on being true. :P | 06:18 |
| infinity | If they're portable, I'd be shocked. | 06:19 |
| infinity | Since portable binary formats and high speed DB access don't tend to be goals you can easily achieve in parallel. | 06:19 |
| infinity | But ICBW. | 06:19 |
| stgraber | infinity: out this week but I'll try to remember to take a look next week | 07:16 |
| slangasek | doko: should /usr/share/python/dist_fallback in python be synced with /usr/share/dh-python/dist/cpython2_fallback in dh-python? or is a package like 'legit' which calls dh --with python2 doing something wrong? | 08:33 |
| doko | slangasek: I would keep it like that. packages are supposed to b-d on dh-python in any case. is there something broken? | 08:35 |
| doko | in bionic, ubuntu-touch.bionic still exists. Is this intended? | 08:36 |
| doko | I mean, in the bionic seeds | 08:36 |
| slangasek | doko: how does build-depending on dh-python change the behavior? | 08:36 |
| slangasek | dh-python is installed; but /usr/bin/dh_python2 is owned by python | 08:37 |
| slangasek | oh seriously | 08:37 |
| slangasek | adding the build-dependency is enough to change the output? | 08:38 |
| doko | dh_python2 is diverted by dh-python | 08:39 |
| slangasek | doko: I think ubuntu-touch.bionic should be removed | 08:39 |
| doko | slangasek: can you do that, or should I file a bug report for that? | 08:43 |
| doko | the fallback: I'll update python-defaults, looks safe to do | 08:43 |
| -queuebot:#ubuntu-release- New: accepted r-cran-drr [amd64] (bionic-proposed) [0.0.2-1] | 09:16 | |
| -queuebot:#ubuntu-release- New: accepted qhull [amd64] (bionic-proposed) [2015.2-3] | 09:17 | |
| -queuebot:#ubuntu-release- New: accepted qhull [armhf] (bionic-proposed) [2015.2-3] | 09:17 | |
| -queuebot:#ubuntu-release- New: accepted qhull [ppc64el] (bionic-proposed) [2015.2-3] | 09:17 | |
| -queuebot:#ubuntu-release- New: accepted qhull [arm64] (bionic-proposed) [2015.2-3] | 09:17 | |
| -queuebot:#ubuntu-release- New: accepted qhull [s390x] (bionic-proposed) [2015.2-3] | 09:17 | |
| -queuebot:#ubuntu-release- New: accepted qhull [i386] (bionic-proposed) [2015.2-3] | 09:17 | |
| -queuebot:#ubuntu-release- New binary: pyroute2 [amd64] (bionic-proposed/main) [0.4.21-0.1ubuntu2] (ubuntu-server) | 10:04 | |
| ginggs | what to do with r-cran-openssl and r-cran-future? the tests pass locally and in debian https://ci.debian.net/packages/r/r-cran-openssl/unstable/amd64/ https://ci.debian.net/packages/r/r-cran-future/unstable/amd64/ | 10:24 |
| apw | ginggs, how do the fail in ubuntu adt ? | 10:28 |
| ginggs | apw: r-cran-openssl 'Failed to connect to 216.58.204.83 on port 443' | 10:29 |
| apw | so that sounds like it is trying to connect to random things ... | 10:30 |
| ginggs | apw: r-cran-future passes on armhf and s390x only | 10:30 |
| ginggs | apw: it's trying to download a cert from google | 10:31 |
| apw | lhr25s13-in-f83.1e100.net. sounds like google indeed | 10:31 |
| apw | well thats not a very sensible test why does it not include the cert | 10:31 |
| apw | expecting to be able to connect randomly to the internet is not a reasonable thing for a test suite to do | 10:32 |
| ginggs | apw: i thought that network connections are allowed for autopkgtests, but not for buildds | 10:32 |
| apw | i thought you had access to squid.internal in there, but i am not sure direct connections are allowed | 10:32 |
| apw | ginggs, yeah i am reminded we had the same problem for docker in ADT we had to use the proxy | 10:37 |
| cjwatson | doko,slangasek: I've removed (I think) all references to ubuntu-touch.bionic and marked the branch as abandoned in LP | 11:02 |
| -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (trusty-proposed/main) [3.13.0-136.185] (core, kernel) | 13:26 | |
| -queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (trusty-proposed) [3.13.0-136.185] | 13:29 | |
| sergiusens | slangasek is there a configureable timeout for autopkgtests? I get this https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/armhf/s/snapcraft/20171124_001006_97bdb@/log.gz (also on zesty) (search for the third match of integrationtests-plugins for a quick find) | 13:57 |
| jbicha | infinity: here are more newly-failing s390x tests you can copy & paste: https://code.launchpad.net/~jbicha/britney/hints-skip-s390x-tests/+merge/334334 | 14:25 |
| -queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.29.4 => 2.29.4.1] (desktop-core, ubuntu-server) | 15:12 | |
| -queuebot:#ubuntu-release- Unapproved: snapd (artful-proposed/main) [2.29.4+17.10 => 2.29.4.1+17.10] (desktop-core, ubuntu-server) | 15:13 | |
| -queuebot:#ubuntu-release- Unapproved: snapd (zesty-proposed/main) [2.29.4+17.04 => 2.29.4.1+17.04] (desktop-core, ubuntu-server) | 15:13 | |
| * apw looks at snapd | 15:16 | |
| -queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (artful-proposed) [2.29.4.1+17.10] | 15:27 | |
| -queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (zesty-proposed) [2.29.4.1+17.04] | 15:28 | |
| -queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (xenial-proposed) [2.29.4.1] | 15:29 | |
| slashd | tinoco ^ | 15:57 |
| slangasek | sergiusens: there is an option to configure some tests as 'long' tests. I don't really like this as a solution, raising the timeout raises it for each test within a package's test suite which is already at 2h46m, when I think the direction we /should/ be trying to move is to have finer granularity (of timeouts and test results) within packages. It's also potentially abusive of the | 16:28 |
| slangasek | infrastructure (and not actually helpful to the upstream project) if it allows the tests to grow unbounded | 16:28 |
| slangasek | sergiusens: I will add snapcraft to the 'long' test list on armhf only, if that works? | 16:29 |
| sergiusens | slangasek yes please, only armhf | 16:36 |
| sergiusens | slangasek we are slowly (pun) moving to making these test leaner as well | 16:37 |
| sergiusens | it got slower because we added more tests (all the new ROS ones) | 16:37 |
| slangasek | sure | 16:38 |
| -queuebot:#ubuntu-release- Unapproved: rejected ubuntu-image [source] (artful-proposed) [1.2+17.10ubuntu1] | 16:44 | |
| -queuebot:#ubuntu-release- Unapproved: rejected ubuntu-image [source] (xenial-proposed) [1.2+16.04ubuntu1] | 16:45 | |
| -queuebot:#ubuntu-release- Unapproved: rejected ubuntu-image [source] (zesty-proposed) [1.2+17.04ubuntu1] | 16:45 | |
| === lamont` is now known as lamont | ||
| -queuebot:#ubuntu-release- Unapproved: systemd (artful-proposed/main) [234-2ubuntu12.1 => 234-2ubuntu12.2] (core) | 16:51 | |
| dannf | bdmurray: hi - would you mind cancelling qemu/zesty-proposed? (see comments #33/#35 in LP: #1710019) | 16:58 |
| ubot5 | Launchpad bug 1710019 in linux (Ubuntu Zesty) "support GICv3 ITS save/restore & migration" [Undecided,In progress] https://launchpad.net/bugs/1710019 | 16:58 |
| -queuebot:#ubuntu-release- Unapproved: ipxe (zesty-proposed/main) [1.0.0+git-20150424.a25a16d-1ubuntu2.1 => 1.0.0+git-20150424.a25a16d-1ubuntu2.2] (ubuntu-desktop, ubuntu-server) | 17:14 | |
| sergiusens | thanks slangasek | 17:47 |
| -queuebot:#ubuntu-release- Unapproved: accepted ipxe [source] (zesty-proposed) [1.0.0+git-20150424.a25a16d-1ubuntu2.2] | 18:02 | |
| -queuebot:#ubuntu-release- Unapproved: ubuntu-image (xenial-proposed/universe) [1.1+16.04ubuntu4 => 1.3+16.04ubuntu1] (no packageset) | 18:30 | |
| -queuebot:#ubuntu-release- Unapproved: ubuntu-image (zesty-proposed/universe) [1.1+17.04ubuntu3 => 1.3+17.04ubuntu1] (no packageset) | 18:30 | |
| -queuebot:#ubuntu-release- Unapproved: ubuntu-image (artful-proposed/main) [1.1+17.10ubuntu5 => 1.3+17.10ubuntu1] (desktop-core) | 18:31 | |
| -queuebot:#ubuntu-release- New sync: drkonqi (bionic-proposed/primary) [5.11.4-0ubuntu1] | 19:15 | |
| -queuebot:#ubuntu-release- New sync: plasma-vault (bionic-proposed/primary) [5.11.4-0ubuntu1] | 19:16 | |
| slangasek | infinity: in answer to the question of which archs are slowest... the answer is definitely bos02 still. queues are growing there in response to uploads even as the other archs have zeroed out | 19:27 |
| tsimonq2 | slangasek: If you're around, any chance you could review drkonqi and plasma-vault? (or any other AA) | 20:42 |
| tsimonq2 | It shows up as a sync but it's from the CI Train | 20:43 |
| -queuebot:#ubuntu-release- Unapproved: accepted nplan [source] (xenial-proposed) [0.32~16.04.2] | 21:27 | |
| wxl | slangasek: tsimonq2 supposedly fixed the lubuntu bionic seed so that uefi packages would get pulled in, but it doesn't seem that's the case. any ideas? | 21:28 |
| slangasek | wxl: what was fixed, and what packages are you expecting that aren't there currently? | 21:29 |
| slangasek | tsimonq2: source new processing is not currently near the top of my list. Is there a reason these packages aren't going via Debian? | 21:30 |
| tsimonq2 | slangasek: These are Kubuntu packages and needed for Plasma, so I guess the same reason why Kubuntu doesn't do more in Debian. | 21:33 |
| tsimonq2 | We don't have team members besides myself participating in the Debian side as well | 21:34 |
| wxl | slangasek: https://bazaar.launchpad.net/~ubuntu-cdimage/ubuntu-cdimage/mainline/revision/1691 | 21:34 |
| slangasek | I'm not clear on what that reason is ;) we also have various KDE packages in Ubuntu that are removed from Debian as obsolete but have different Ubuntu-specific versions in Ubuntu, which makes it awkward to process removals | 21:35 |
| wxl | tsimonq2 do you remember the missing packages for UEFI? | 21:36 |
| tsimonq2 | wxl: not offhand, see ship-live-share | 21:37 |
| cyphermox | what do you know, that does explain the failures. | 21:37 |
| tsimonq2 | slangasek: It's a historical thing, really. We've always been a bit faster and we have different procedures. | 21:39 |
| wxl | slangasek: i THINK it's shim-signed and grub-efi-amd64-bin that's missing | 21:41 |
| tsimonq2 | slangasek: I don't really know how to explain it otherwise except that "It's Always Been Thay Way" and there's a few blockers from us being more in-sync | 21:41 |
| slangasek | tsimonq2: yeah, it hasn't always been that way | 21:41 |
| slangasek | that's the thing :) | 21:41 |
| tsimonq2 | (well, not always, but for the past 3 years at least) | 21:41 |
| slangasek | wxl: so, which image are you looking at that you see these packages missing from? | 21:42 |
| slangasek | wxl: lubuntu/daily-live/current/bionic-desktop-amd64.list shows me grub-efi-amd64-bin and shim-signed | 21:42 |
| tsimonq2 | And that's the weird part, because those aren't in manifest | 21:42 |
| tsimonq2 | (or are they?) | 21:42 |
| slangasek | that's not weird at all | 21:42 |
| slangasek | you added them to a 'ship' seed | 21:42 |
| tsimonq2 | OH | 21:43 |
| tsimonq2 | Right | 21:43 |
| tsimonq2 | My bad :) | 21:43 |
| wxl | :/ | 21:43 |
| slangasek | that puts them in the package pool, which is in .list; it doesn't install them in the livefs, which is what .manifest lists | 21:43 |
| tsimonq2 | Anyways, we've still had to install the packages on live ISOs for that stuff to work, slangasek | 21:43 |
| cyphermox | they couldn't be in the manifest anyway, coinstalled with grub-pc... | 21:43 |
| slangasek | you're going to have to elaborate | 21:44 |
| slangasek | installing them in the live environment does nothing for you | 21:44 |
| slangasek | selecting them for installation onto the target disk is explicitly part of what the installer is supposed to do | 21:44 |
| wxl | actually i don't care about the live environment. it's the fact that the installer can't install them | 21:44 |
| cyphermox | tsimonq2: with r1691 landed on 11-20; this should be re-tested, I think | 21:44 |
| tsimonq2 | cyphermox: Ok | 21:45 |
| cyphermox | now, given that they were added to ship-live-share, and that wasn't the case before, I think we were looking at "efi doesn't install properly" but of a different form than it was before | 21:45 |
| cyphermox | ie. it doesn't install correctly if you're offline, but does if you're online? | 21:46 |
| cyphermox | that's about the only thing adding these to ship-* would change, I think | 21:46 |
| wxl | actually it didn't install correctly while being online | 21:48 |
| wxl | but it was originally brought to out attention with an offline install | 21:48 |
| cyphermox | the original bug looks online | 21:48 |
| cyphermox | but then you also had a difference in what was in the manifest, one particular package that was causing a conflict, IIRC | 21:49 |
| * cyphermox updates his copy of lubuntu-daily-live | 21:49 | |
| wxl | i'll try again in a moment. i'm installing a zesty system now to try to troubleshoot some stupid node module problem i'm having :eyeroll: | 21:53 |
| tsimonq2 | While we're at it... | 21:54 |
| tsimonq2 | Root on XFS doesn't seem to be working either :P | 21:55 |
| tsimonq2 | (this, and LVM and UEFI not working, has sort of surprised me in that nobody tested these cases and made a big enough deal about them before release, something that we *need* to change as the Lubuntu team) | 21:55 |
| wxl | yeah well we're kind of unique because i think everyone else just assumes EFI | 21:56 |
| wxl | where as in general, i think we assume NOT UEFI | 21:56 |
| wxl | so it's like we need to have special testcases just for UEFI | 21:56 |
| wxl | which sucks, because that doubles our workload as far as QA is concerned | 21:56 |
| cyphermox | wxl: no; nothing assumes UEFI; you just get a different bootloader depending on how you boot the image -- that's true for all our images AFAIK | 21:58 |
| wxl | cyphermox: so no one is explicitly testing both UEFI and non-UEFI installs? | 21:58 |
| jbicha | wxl: VirtualBox is non-UEFI by default and it is used a lot by testers | 22:00 |
| cyphermox | everyone is testing that both UEFI and non-UEFI installs; but different individuals test different things. | 22:00 |
| wxl | VirtualBox and KVM can both do UEFI boot | 22:01 |
| wxl | but yeah i guess what i'm saying is we need to explicitly have testcases if we want to assume adequate coverage | 22:01 |
| slangasek | infinity: the reason autopkgtest queues are growing is bos02 fell over again. | 22:02 |
| wxl | this is mostly a lubuntu issue because of no-follow-recommends (:eyeroll: again) but it's not to say that SOMETHING couldn't happen to affect other flavors | 22:02 |
| cyphermox | wxl: indeed. | 22:02 |
| wxl | i do have it on my list to write some testcases | 22:03 |
| wxl | but it's basically going to copy the old testcases but request a UEFI boot | 22:03 |
| wxl | both sets of testcases will need to have more instruction about how to twiddle UEFI and non-UEFI on VM and otherwise | 22:04 |
| wxl | maybe i should make a bug about this against ubuntu-manual-tests and we can put our heads together to resolve it | 22:05 |
| tsimonq2 | wxl: Speaking of no-follow-recommends... | 22:05 |
| * wxl harumphs | 22:05 | |
| tsimonq2 | wxl: I think we should just *try* disabling it in Lubuntu Next | 22:05 |
| tsimonq2 | Just for a little test. | 22:05 |
| tsimonq2 | See how much the ISO size increases. | 22:05 |
| wxl | i'm game | 22:05 |
| tsimonq2 | Alright, I'll make the change after dinner. | 22:06 |
| wxl | please report to the list | 22:06 |
| tsimonq2 | I will. | 22:07 |
| LocutusOfBorg | sigh perl | 22:49 |
| chrisccoulson | hi, can someone please copy the rustc binaries (1.21.0+dfsg1+llvm-0ubuntu5) from https://launchpad.net/~ubuntu-mozilla-security/+archive/ubuntu/rust-updates/ to bionic-proposed so that I can get firefox built there? | 22:52 |
| LocutusOfBorg | chrisccoulson, source+binaries, correct? | 22:54 |
| chrisccoulson | yeah | 22:54 |
| LocutusOfBorg | ./copy-package --from=ppa:ubuntu-mozilla-security/ubuntu/rust-updates --from-suite=bionic --to=ubuntu --to-suite=bionic-proposed --include-binaries rustc | 22:56 |
| LocutusOfBorg | y, 50 copies requested. | 22:56 |
| LocutusOfBorg | it will be available on next publisher run | 22:57 |
| chrisccoulson | LocutusOfBorg, thanks | 22:57 |
| LocutusOfBorg | you are welcome, I'm not sure why you can't do it by yourself, but you might have your good reasons :) | 22:57 |
| chrisccoulson | oh, I didn't know that I could | 22:57 |
| LocutusOfBorg | (copy-package is part of ubuntu-release-tools) | 22:57 |
| LocutusOfBorg | assuming you have upload rights for the package, https://code.launchpad.net/~ubuntu-archive/ubuntu-archive-tools/trunk | 22:58 |
| LocutusOfBorg | the command is the one above ^^ | 22:58 |
| sergiusens | slangasek am I good to retrigger the armhf tests that I mentioned earlier or will you get back to me on that long/slow test marker change? | 23:08 |
| tsimonq2 | LocutusOfBorg: Why do you copy to bionic-proposed? Copying to bionic should work fine, no? | 23:20 |
| cjwatson | No, you must copy to bionic-proposed. | 23:21 |
| cjwatson | The copier doesn't have the same sugar that uploads do. | 23:21 |
| cjwatson | Not least because the process of promoting from bionic-proposed to bionic uses copies, and it was very unclear what that would do if there were an automatic mapping thing in its way. | 23:22 |
| tsimonq2 | cyphermox: Oh, TIL, thank you | 23:23 |
| wxl | just came back. any luck with that new lubuntu daily, cyphermox | 23:32 |
| -queuebot:#ubuntu-release- New binary: opencsg [s390x] (bionic-proposed/universe) [1.4.2-1ubuntu1] (no packageset) | 23:33 | |
| -queuebot:#ubuntu-release- New binary: opencsg [amd64] (bionic-proposed/universe) [1.4.2-1ubuntu1] (no packageset) | 23:34 | |
| -queuebot:#ubuntu-release- New binary: opencsg [ppc64el] (bionic-proposed/universe) [1.4.2-1ubuntu1] (no packageset) | 23:34 | |
| -queuebot:#ubuntu-release- New binary: opencsg [i386] (bionic-proposed/universe) [1.4.2-1ubuntu1] (no packageset) | 23:34 | |
| -queuebot:#ubuntu-release- New binary: opencsg [arm64] (bionic-proposed/universe) [1.4.2-1ubuntu1] (no packageset) | 23:36 | |
| -queuebot:#ubuntu-release- New binary: opencsg [armhf] (bionic-proposed/universe) [1.4.2-1ubuntu1] (no packageset) | 23:36 | |
| -queuebot:#ubuntu-release- New: accepted opencsg [amd64] (bionic-proposed) [1.4.2-1ubuntu1] | 23:38 | |
| -queuebot:#ubuntu-release- New: accepted opencsg [armhf] (bionic-proposed) [1.4.2-1ubuntu1] | 23:38 | |
| -queuebot:#ubuntu-release- New: accepted opencsg [ppc64el] (bionic-proposed) [1.4.2-1ubuntu1] | 23:38 | |
| -queuebot:#ubuntu-release- New: accepted opencsg [arm64] (bionic-proposed) [1.4.2-1ubuntu1] | 23:38 | |
| -queuebot:#ubuntu-release- New: accepted opencsg [s390x] (bionic-proposed) [1.4.2-1ubuntu1] | 23:38 | |
| -queuebot:#ubuntu-release- New: accepted opencsg [i386] (bionic-proposed) [1.4.2-1ubuntu1] | 23:38 | |
| -queuebot:#ubuntu-release- New: accepted pyroute2 [amd64] (bionic-proposed) [0.4.21-0.1ubuntu2] | 23:39 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!