jbicha | I think I'm going to need help with LP: #1718085 tomorrow (or at least this week) | 02:04 |
---|---|---|
ubot5 | Launchpad bug 1718085 in ubuntu-gnome-meta (Ubuntu) "FFe: Transition to ubuntu-desktop and provide vanilla-gnome-desktop" [Undecided,New] https://launchpad.net/bugs/1718085 | 02:04 |
jbicha | apologies for not doing it sooner, my excuse is that agreeing on a name (even an apparently simple one) is hard | 02:05 |
infinity | jbicha: Can I bikeshed that name? :P | 04:06 |
jbicha | sure but it might not change the name ;) | 04:08 |
Ukikie | Speaking of, did anyone look into how notification-daemon slipped into every ISO? | 04:25 |
slangasek | ... no? which ISO are you expecting it to not be in? | 04:36 |
Ukikie | slangasek: Xubuntu, Ubuntustudio, Lubuntu and likely Kubuntu, Ubuntu MATE. The former ship xfce4-notifyd which provides notification-daemon (expected, same as the last many releases) and I presume KDE and MATE provide something as well. | 04:45 |
slangasek | cyphermox: nplan autopkgtests regressed again? | 05:20 |
LocutusOfBorg | doko, I want to see if the llvm fixes are all in debian, I already have a merge ready for the python change (llvm 3.9) http://launchpadlibrarian.net/337517278/llvm-toolchain-3.9_1%3A3.9.1-13ubuntu7_1%3A3.9.1-16.diff.gz I couldn't find references in changelog for the FUZZER change, maybe not needed anymore | 07:06 |
* LocutusOfBorg good morning btw | 07:06 | |
LocutusOfBorg | also ldc should be fixed now | 07:06 |
LocutusOfBorg | will appear in some minutes in new queue | 07:06 |
-queuebot:#ubuntu-release- New binary: ldc [amd64] (artful-proposed/universe) [1:1.4.0-1ubuntu1] (no packageset) | 07:16 | |
-queuebot:#ubuntu-release- New binary: ldc [ppc64el] (artful-proposed/universe) [1:1.4.0-1ubuntu1] (no packageset) | 07:17 | |
-queuebot:#ubuntu-release- New binary: ldc [i386] (artful-proposed/universe) [1:1.4.0-1ubuntu1] (no packageset) | 07:22 | |
=== Guest19724 is now known as RAOF | ||
LocutusOfBorg | doko, stuff seems to build better with the new ldc https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/debhelper/+build/13392398 | 09:04 |
LocutusOfBorg | what is your opinion? it is FTBFS on armhf, but at least if we remove binaries there we can finish the transition | 09:04 |
xnox | bdmurray, i believe i have fixed up templates on all the sru bugs =/ | 10:06 |
doko | LocutusOfBorg: you could do a test build for powerpc on trusty and xenial to see if it is still needed | 10:21 |
LocutusOfBorg | doko, context please? | 10:22 |
LocutusOfBorg | llvm? | 10:22 |
doko | well, that's what you asked? | 10:22 |
LocutusOfBorg | yep, I was wondering about ldc, the second question | 10:23 |
LocutusOfBorg | actually that FUZZER variable was tested but never defined | 10:23 |
doko | better keep armhf and fix it for th next release | 10:23 |
LocutusOfBorg | so, in each case, the sync -f has not changed the status quo | 10:24 |
LocutusOfBorg | for armhf, I pushed an llvm 5.0 that might fix it | 10:24 |
LocutusOfBorg | -opt_flags = -g -O2 | 10:25 |
LocutusOfBorg | +opt_flags = -g1 -O2 | 10:25 |
LocutusOfBorg | +ifneq (,$(filter $(DEB_HOST_ARCH),arm64 ppc64el)) | 10:25 |
LocutusOfBorg | + opt_flags = -g1 -O2 | 10:25 |
LocutusOfBorg | +endif | 10:25 |
LocutusOfBorg | maybe you didn't want to change opt_flags regardless of the architecture? | 10:25 |
LocutusOfBorg | otherwise the if test would have been useless | 10:25 |
doko | why? did you find out what caused the explosion of the debug symbol size? | 10:27 |
apw | that is an odd if, it has the same value both ways | 10:29 |
apw | LocutusOfBorg, ^ | 10:30 |
LocutusOfBorg | ^^ that one, the first line | 10:30 |
apw | as in you reverted the first line | 10:30 |
apw | of that existing diff ? | 10:30 |
LocutusOfBorg | AFAIK the explosion of debug symbol size has been a thing in arm64 and ppc64el | 10:31 |
LocutusOfBorg | so, using -g1 only there should be the exact thing to do | 10:31 |
LocutusOfBorg | the above is the diff between the current ubuntu and the current debian | 10:31 |
LocutusOfBorg | (me, discard the latest sentence) | 10:32 |
LocutusOfBorg | the current debian is "good" | 10:32 |
* LocutusOfBorg wrt the if statement | 10:32 | |
LocutusOfBorg | http://launchpadlibrarian.net/337530714/llvm-toolchain-5.0_1%3A5.0-1ubuntu2_1%3A5.0-2~build1.diff.gz | 10:33 |
doko | no, you are wrong, it' see for s390x as well, even for debian. so please don't speculate | 10:33 |
LocutusOfBorg | look at the above diff for 5.0 | 10:33 |
LocutusOfBorg | it is enabled in +ifneq (,$(filter $(DEB_HOST_ARCH),amd64 arm64 ppc64el s390x)) | 10:34 |
doko | well, you just said: "the explosion of debug symbol size has been a thing in arm64 and ppc64el" | 10:36 |
doko | which is wrong | 10:36 |
LocutusOfBorg | you are right, sorry! I was meaning "for a subset of the whole architecture list", and now debian has that list embedded into the rules file | 10:37 |
sergiusens | slangasek any update on the armhf network errors? | 11:26 |
cyphermox | slangasek: it's possible, but I did run it twice on amd64 before uploading, and both passed no problem. admittedly not against proposed, because proposed was otherwise broken atm (python xml). I'll have a look, given that it passes without proposed, it ought to be a fairly simple debugging session | 13:32 |
jbicha | sil2100: does this look ok? https://code.launchpad.net/~jbicha/ubuntu-cdimage/drop-ubuntu-gnome-artful/+merge/330983 | 13:41 |
acheronuk | Ukikie: seems notification-daemon is on the Kubuntu iso also. trying to work out how to evict it! | 14:10 |
cjwatson | acheronuk: I think it will work if you explicitly seed plasma-workspace in kubuntu.artful/desktop rather than relying on it being pulled in via dependencies. | 14:15 |
cjwatson | acheronuk: At the moment, germinate hasn't yet worked out that plasma-workspace is going to be pulled into desktop at the point when it's resolving dependencies (well, Recommends) of libnotify4 while expanding desktop-common, so it picks the real package rather than realising that the Kubuntu-ish replacement is wanted. | 14:16 |
acheronuk | cjwatson: yeah, I'm just weaving my way through those depends and recommends | 14:17 |
acheronuk | lets try that then. see what germinate things on the next iso build | 14:21 |
acheronuk | *thinks | 14:21 |
sil2100 | jbicha: commented on it | 14:21 |
cjwatson | acheronuk: The important bit is explicitly seeding things that you want to be picked instead of the default. | 14:26 |
acheronuk | cjwatson: indeed. thanks for pointing that out. saved me some time puzzling..... | 14:29 |
cjwatson | I'm not entirely sure what the problem is in the Xubuntu case. xfce4-notifyd in core should suffice. | 14:33 |
rbasak | slangasek: could you accept the python-certbot-nginx binNEW for Xenial please? | 14:42 |
cyphermox | slangasek: I re-ran the nplan autopkgtests, currently waiting in the queue. the failure looked like something about the infra though -- as if the tests had been run on the host somehow, and the modules/directories were not cleaned up afterwards -- mac80211_hwsim should never be on any system to begin with, unless it ran the tests and exploded midway :) | 14:54 |
ogra_ | cyphermox, did you see my comment regarding the console-setup udev rule ? | 14:56 |
cyphermox | ogra_: I did | 14:56 |
ogra_ | good | 14:56 |
ogra_ | someone should at least test if it doesnt break initrd input ... (not sure if it does or does not, but we used to install the rule there) | 14:56 |
cyphermox | well, if it did, it's still being in the way now. I'm sure there is a better way to handle this | 15:00 |
cyphermox | that said, my current thought is why the hell did things need to start using tty1 for graphical, and why can't wayland handle the input correctly anyway? | 15:00 |
Laney | it does handle it correctly? | 15:05 |
Laney | Xorg has the same problem - you can't change the console mode underneath it | 15:06 |
slangasek | rbasak: done | 15:07 |
slangasek | cyphermox: ok cool | 15:07 |
cyphermox | Laney: things were working fine under X | 15:07 |
Laney | no, they worked fine under lightdm/Unity because it was on tty7 | 15:07 |
Laney | start an X session from GDM and reproduce this bug | 15:07 |
-queuebot:#ubuntu-release- New: accepted python-certbot-nginx [amd64] (xenial-proposed) [0.14.2-0ubuntu0.16.04.1] | 15:07 | |
Laney | it happens there too | 15:07 |
cyphermox | partly because things were running on tty7, but I would wager it was also jigling the console modes differently | 15:07 |
Laney | No | 15:08 |
Laney | It's K_OFF, and then when you get K_UNICODE it breaks | 15:08 |
cyphermox | I can't begin to explain why you'd see your password in clear text on the screen when it crashes then. | 15:08 |
Laney | That does explain why you see that | 15:08 |
cyphermox | and that^ makes me very scared on it | 15:08 |
rbasak | slangasek: thanks! | 15:09 |
Laney | ...don't switch the keyboard mode... | 15:09 |
cyphermox | Laney: not the right place to discuss this in any case. | 15:09 |
Laney | k | 15:09 |
cyphermox | slangasek: any idea what that issue with nplan might have been? | 15:10 |
slangasek | cyphermox: nope! | 15:10 |
cyphermox | yipee.\ | 15:11 |
-queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (xenial-proposed) [229-4ubuntu20] | 15:23 | |
Laney | cyphermox: did you try to reproduce this locally? | 15:24 |
Laney | File "/tmp/autopkgtest.OH8cTq/build.rJx/nplan-0.28/tests/integration.py", line 104, in create_devices | 15:24 |
Laney | raise SystemError('mac80211_hwsim module already loaded') | 15:24 |
Laney | SystemError: mac80211_hwsim module already loaded | 15:24 |
cyphermox | of course I did, it works locally when not using -proposed (because there was another issue with python xml yesterday) | 15:24 |
cyphermox | this is specifically the kind of failure you see if the test previously ran but was killed before the end | 15:25 |
cyphermox | (ie. cleanup didn't run) | 15:25 |
Laney | that paste was from my machine | 15:25 |
cyphermox | why would this happen though? | 15:26 |
cyphermox | did you use lxc as the runner or qemu? | 15:26 |
Laney | qemu | 15:26 |
cyphermox | err | 15:26 |
cyphermox | with proposed? | 15:27 |
Laney | nplan from proposed | 15:27 |
cyphermox | --apt-pocket=proposed or not? | 15:27 |
Laney | no | 15:27 |
Laney | proposed=src:nplan | 15:27 |
cyphermox | because I had nplan build locally, in that qemu. | 15:27 |
cyphermox | ie. autopkgtest -U -s . -- qemu ~u/adt-artful-amd64-cloud.img | 15:28 |
Laney | autopkgtest.u.c doesn't do it like that | 15:28 |
cyphermox | I know that | 15:28 |
Laney | ok | 15:29 |
cyphermox | but it's the closest I can emulate "netplan from proposed" without uploading it to proposed. | 15:29 |
cyphermox | furthermore, that has always worked fine until now; so I had no reason to do otherwise. | 15:30 |
jbicha | sil2100: I resubmitted the cdimage change (not sure if it sent you an email or not) | 15:32 |
Laney | if you want the actual package from proposed, then --apt-pocket=proposed=src:nplan is the way to ask for that | 15:32 |
Laney | you can see the autopkgtest invocation used near the top of the logs; that helps when reproducing failures | 15:33 |
cyphermox | Laney: that's fine once something is in proposed | 15:34 |
Laney | this broken nplan is? | 15:35 |
cyphermox | my point was, I tested this locally before uploading, and the autopkgtests were passing with no issues, so I have no idea why it would fail in the infra. | 15:35 |
Laney | ok, well I came in where there was a claim that the infrastructure was broken and a retry was issued - at that point it was possible to reproduce the same failure without needing local packages | 15:37 |
cyphermox | I can't reproduce the failure here. | 15:37 |
cyphermox | http://paste.ubuntu.com/25573075/ | 15:37 |
cyphermox | this is admittedly *not* the same command as you provided, but it *is* the same package being used (it's logged as nplan 0.28) | 15:37 |
cyphermox | I'm not claiming that the infra is broken, just trying to figure out where something is different so I know why it works here, but doesn't work in autopkgtests.ubuntu.com | 15:38 |
cyphermox | or why it fails for you | 15:38 |
cyphermox | ugh, that paste is incomplete | 15:39 |
cyphermox | this here is complete: http://paste.ubuntu.com/25573084/ | 15:40 |
slangasek | sergiusens: I've done some quick smoketests and hammering the DNS server from inside with lookups in a loop was not enough to trigger the problem. :/ I'll go ahead and badtest snapcraft/armhf now to let it through, and continue tugging at that problem | 15:42 |
slangasek | sergiusens: oh, or somebody already did let it through which is also good | 15:42 |
slangasek | (but didn't badtest it, which is bad) | 15:43 |
slangasek | (badtest added) | 15:44 |
Laney | cyphermox: sorry, team meeting --- here's three commands which failed in the same way for me https://paste.ubuntu.com/25573149/, not sure if that's helpful | 15:51 |
Laney | it's also a fresh image built 30 minutes ago or so | 15:52 |
apw | slangasek, how would they have let it through without a badtest/skiptest | 15:56 |
cyphermox | Laney: ta. I have an idea, perhaps I know what this is | 15:56 |
slangasek | apw: because proposed-migration remains completely advisory for SRUs; we need to change sru-release to write hints instead of doing copy-package in order to change this | 16:12 |
apw | slangasek, derp in a stable release, of course | 16:12 |
jbicha | slangasek: please update your badtest for (artful) flapak/ppc64el and add s390x (since it's NBS on s390x), also please update the badtest for ostree (L_aney's hint file) | 17:49 |
doko | glibc is now only stopped by the libhardware/libhybris stack | 18:15 |
slangasek | jbicha: fixing the autopkgtest failure is something any Ubuntu dev has access to do; updating the hint is something only the release team can do; why not fixing the flatpak/ppc64el test failure instead? | 18:23 |
slangasek | and why did flatpak 0.8.7-5 run tests on s390x if there are no binaries :P | 18:23 |
sergiusens | slangasek thanks, I wasn't even aware it went through! We can certainly look into it live next week and get some proper data to pin point the problem | 18:26 |
slangasek | sergiusens: yeah... it's confusing, as I said I have seen more lookup failures on armhf than elsewhere, but they've seemed pretty infrequent - not enough for me to expect snapcraft to fail continuously | 18:27 |
jbicha | flatpak only passed 4 times in its history on ppc64el on Ubuntu so it seems more likely that some change in the infrastructure helped it pass | 18:30 |
Ukikie | acheronuk: Yeah it looks like a regression somewhere as the package is everywhere, even when an acceptable alternative is seeded. | 18:47 |
slangasek | infinity, xnox: were either of you still working the libhybris dep chain? | 19:58 |
ahasenack | hi, for some reason ubuntu-advantage-tools v8 is in artful/universe instead of main (https://launchpad.net/ubuntu/+source/ubuntu-advantage-tools), could someone "push" it over to main, like it is in all other ubuntu releases before AA? | 20:10 |
ahasenack | I don't know what happened there, also why it is showing "published 3h ago" when it built back in Aug 22nd | 20:12 |
slangasek | ahasenack: it's in universe instead of main because we haven't yet seeded it in ubuntu-minimal | 20:14 |
slangasek | someone probably demoted it as a component-mismatch | 20:14 |
slangasek | (which was not wrong; it's on me for not having seeded it before now) | 20:15 |
doko | slangasek: please could you skip the autopkg tests for python3-defaults? the queue gets large. I see the the ones for build-essential are almost done, and the ones for python-defaults aretriggerring almost the same packages as python3-defaults | 20:18 |
doko | so autopkg tests for universe packages can catch up | 20:18 |
xnox | slangasek, why would you want to work on the libhybris dep chain? | 20:19 |
slangasek | xnox: it's still blocking glibc. Is there an agreed path forward? Is someone working on resolving this? | 20:23 |
xnox | slangasek, i do not see it blocking glibc | 20:23 |
xnox | slangasek, just need to wait for britney to migrate it, as far as i can tell. | 20:24 |
xnox | slangasek, publisher is slow | 20:24 |
slangasek | xnox: did you look at http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt ? | 20:24 |
xnox | yes | 20:24 |
xnox | slangasek, did you look at https://launchpad.net/ubuntu/+source/libhybris/0.1.0+git20151016+6d424c9-0ubuntu26 ? | 20:24 |
slangasek | heh | 20:25 |
* xnox likes to call & raise | 20:25 | |
slangasek | xnox: you didn't close LP: #1718030 in the changelog :) | 20:26 |
ubot5 | Launchpad bug 1718030 in libhybris (Ubuntu) "libhybris fails to build with glibc 2.26" [Undecided,New] https://launchpad.net/bugs/1718030 | 20:26 |
xnox | slangasek, it's not like it would have made a different until after the package migrates.... | 20:27 |
doko | slangasek, ahasenack: sorry, yes I demoted it | 20:27 |
slangasek | xnox: are you sure I'm not scraping changes emails for bug references? | 20:28 |
slangasek | ;) | 20:28 |
slangasek | xnox: thanks for the fix | 20:28 |
xnox | slangasek, if you were scrapping changes emails, you would have noticed that i uploaded libhybris ;-) | 20:28 |
slangasek | xnox: not if I was filtering for bugs I care about! | 20:29 |
slangasek | it's plausible | 20:29 |
xnox | deniability | 20:30 |
xnox | anyway. publisher is so slow | 20:30 |
slangasek | publisher, or britney? | 20:30 |
slangasek | publisher says it's published. britney doesn't show it moving | 20:31 |
xnox | it's not yet even in rmadison output | 20:31 |
slangasek | rmadison is post-publisher | 20:31 |
-queuebot:#ubuntu-release- Unapproved: cockpit (zesty-backports/universe) [148-1~ubuntu17.04.1 => 150-2git1~ubuntu17.04.1] (no packageset) | 20:31 | |
xnox | ... and the builds finished building 1h ago, hence i blame publisher for the delays | 20:32 |
slangasek | doko: I only see long 'huge' queues of autopkgtests, not regular queues. It's fine for these autopkgtests to run as low-priority jobs, unless there are things queued behind these in the 'huge' queue that you care about? | 20:32 |
xnox | britney doesn't notice things until they are in rmadison. Maybe imprecise timing, but that is my perception from how things look to me. | 20:32 |
-queuebot:#ubuntu-release- Unapproved: cockpit (xenial-backports/universe) [148-1~ubuntu16.04.1 => 150-2git1~ubuntu16.04.1] (no packageset) | 20:32 | |
slangasek | doko: also, dumping the tests is different than letting python3-defaults through before the tests are done; is the latter what you care about? | 20:33 |
xnox | doko, do you need that package to start archive rebuild or something? | 20:33 |
doko | slangasek: sure, fine. please lower the priority and enjoy yourself looking at the logs ;p | 20:33 |
slangasek | xnox: britney talks to ftpmaster.internal directly. rmadison data is generated from ftpmaster.internal. | 20:33 |
doko | xnox: I've given up on that. will do the tst rebuild with -proposed enabled :/ | 20:34 |
slangasek | doko: they are already in the low-priority queue | 20:34 |
xnox | doko, or is that the fix for parsing that debian file? | 20:34 |
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (xenial-backports) [150-2git1~ubuntu16.04.1] | 20:34 | |
-queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (zesty-backports) [150-2git1~ubuntu17.04.1] | 20:34 | |
doko | xnox: no, it's just a version bump | 20:34 |
xnox | doko, yeah anything that triggers more than a few tests automatically ends up in a different queue in the autopkgtests. | 20:34 |
xnox | it's round robin across ubuntu, ppas, upstream, and "things that triggered a lot of tests". To not starve "small" upgrades, by the "large ones". | 20:35 |
xnox | but i think it does not do round-robin across releases | 20:35 |
slangasek | I think it is | 20:35 |
xnox | thus one has to wait for xenial to be drained before artful is tested. | 20:35 |
xnox | hm, ok. | 20:35 |
slangasek | doko: I'm not opposed to doing something here to expedite. what I'm asking is that we be clear about what we're doing, and the rationale. Clearing the autopkgtest queues doesn't make python3-defaults migrate any faster; adding a skiptest hint for python3-defaults would make it migrate faster | 20:37 |
doko | slangasek: well, it's not that these autopkg tests would catch anything which is not already in the release pocket | 20:38 |
slangasek | doko: ok, but what is it that you are trying to accomplish? "empty autopkgtest queues" is not a goal that gets me out of bed | 20:39 |
slangasek | is something that you care about blocked / slow? | 20:39 |
xnox | slangasek, hm so new publisher run does not start until after a britney run finishes? i would have thought that is decoupled. | 20:39 |
xnox | slangasek, such that things in -proposed can publish multiple times whilst britney is running | 20:39 |
doko | lol, 1pm in bed? | 20:40 |
xnox | shhh | 20:40 |
slangasek | xnox: they are decoupled. I was only saying that if you want to know when britney will see it, looking in rmadison has false-negatives | 20:40 |
slangasek | doko: a saying | 20:40 |
doko | slangasek: britney runs are currently slow, for whatever reason | 20:40 |
slangasek | yes. maybe they're slow because they're trying to check a lot of autopkgtest results | 20:41 |
xnox | slangasek, so a run 20 minutes ago, did not notice libhybris that finished 1h ago and published 57 minutes ago? | 20:42 |
xnox | although it may be a lie that it published 57 minutes ago, could have been just the source publication | 20:42 |
slangasek | xnox: the 'generated' timestamp is near the end of the britney run, not the start, fwiw | 20:42 |
xnox | looking at the current running log at http://people.canonical.com/~ubuntu-archive/proposed-migration/log/artful/2017-09-19/20:20:05.log | 20:43 |
xnox | britney run that "started" 20 minutes ago | 20:43 |
slangasek | xnox: right, new update_excuses up and still no libhybris; I'll dig if time allows, but I have a call in 10 minutes | 20:49 |
xnox | slangasek, and now that that britney is done, new libhybris appeared in rmadison, and i suspect next run of britney will have the new libhybris. | 20:51 |
xnox | it does feel like britney locks and block ftpmaster.internal | 20:51 |
slangasek | it doesn't | 20:52 |
xnox | migrating \o/ | 21:13 |
doko | wonders still happen | 21:18 |
slangasek | uh | 21:20 |
slangasek | arpack++ now shows up as a regression under glibc, where did that come from? | 21:20 |
slangasek | skiptested, so not fatal, but | 21:20 |
slangasek | oh, because it passed for the first time with new openblas, so it's a retroactive regression ;P | 21:21 |
doko | now finally clang demoted to universe. we really should take more care about auto promotions to main | 21:57 |
infinity | xnox: \o/ | 22:17 |
tsimonq2 | Release team: I'd like to do a change to gdebi that's all in one upload. One change (that I've already made locally) fixes a bug that Ubuntu MATE was having, the other thing that I would like to do is port away from the obsolete, insecure framework kdesudo and instead use kdesu for gdebi-kde. kdesudo has already been removed in Debian because it's KDE 3 and hasn't been touched upstream since | 23:11 |
tsimonq2 | 2011. Can I JFDI or do you want me to file a bug for the FFe for the kdesudo port? | 23:11 |
tsimonq2 | I just don't know if it deserves an FFe. | 23:11 |
tsimonq2 | I'd consider it a bugfix in the sense that kdesu is generally more secure and has less bugs, but a feature in the sense that it's porting to a new framework. | 23:12 |
tsimonq2 | Thoughts? | 23:12 |
nacc | if someone from the release team could review the FFE at LP: #1658469, I'd appreciate it. | 23:18 |
ubot5 | Launchpad bug 1658469 in apache2 (Ubuntu) "[FFe] mod_http2 is not available in Apache" [Low,Triaged] https://launchpad.net/bugs/1658469 | 23:18 |
tsimonq2 | (actually, might work better as separate gdebi upload, let's get that out of the way) | 23:28 |
tsimonq2 | (bugfix) | 23:28 |
-queuebot:#ubuntu-release- New binary: cockpit [amd64] (xenial-backports/universe) [150-2git1~ubuntu16.04.1] (no packageset) | 23:46 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!