| infinity | karstensrage: Sorry, yeah. Haven't had a chance yet. It's been a messy 24h. | 00:18 |
|---|---|---|
| karstensrage | i understand, very sorry | 00:18 |
| === JanC_ is now known as JanC | ||
| alkisg | Good morning | 05:17 |
| alkisg | smoser: Re: #1718227, does that need action from the developers of those affected packages, or netplan will gain support for calling if{up,down}.d script and us developers just need to test that it works fine? | 05:18 |
| slangasek | alkisg: netplan only feeds configuration into the network renderer (systemd-resolved or network-manager). It does not call any scripts, and neither does systemd-resolved | 05:19 |
| alkisg | slangasek: AFAIK, network-manager does have a compatibility layer that calls ifupdown scripts | 05:21 |
| slangasek | yes. networkd does not, and will not | 05:21 |
| alkisg | slangasek: to rephrase... as the developer of one of the affected packages (epoptes), I don't know what I'm supposed to do with that bug | 05:21 |
| slangasek | alkisg: add a systemd unit that handles the corresponding events from systemd | 05:22 |
| alkisg | OK, so it's not actually about supporting netplan, but about supporting systemd-networkd? | 05:22 |
| slangasek | yes | 05:22 |
| alkisg | Got it, thank you :) | 05:22 |
| alkisg | slangasek: ehm, an additional question just to make sure... so the best resolution is to ship (1) ifupdown scripts for backwards compatibility, (2) network-manager dispatcher.d scripts for those using nm, and (3) networkd units, for those using that? | 05:24 |
| alkisg | Or just (3) is enough for 16.04+ compatibility? | 05:24 |
| alkisg | Is everyone guaranteed to be running networkd from some release and on/ | 05:25 |
| alkisg | ? | 05:25 |
| slangasek | alkisg: desktops will continue to use Network Manager, so really you want to integrate with both NM and networkd going forward | 05:31 |
| slangasek | alkisg: looking at /etc/network/if-up.d/epoptes-client, I wonder if this shouldn't be some combination of a udev rule, and a systemd unit that starts on network-online | 05:33 |
| slangasek | because the latter is a generic entry point supported by all network renderers | 05:33 |
| alkisg | slangasek: the basic task there is to relaunch the client when the ip changes | 05:34 |
| alkisg | As it doesn't have enough intelligence to reestablish the ssl tunnel using the new ip | 05:34 |
| alkisg | network-online wouldn't be recalled when the ip changes, would it? | 05:34 |
| slangasek | alkisg: correct, it would not; but I don't see anything there that shuts down the previous client, where does that happen? | 05:35 |
| alkisg | Just running epoptes-client (the last line) takes care about all that | 05:35 |
| alkisg | Terminating the previous instance and running a new one | 05:36 |
| slangasek | ok | 05:36 |
| slangasek | arguably, this should be implemented using netlink instead, to reconnect when the source IP changes - for any reason | 05:38 |
| alkisg | Thank you, I'll read about that | 05:38 |
| slangasek | however, netlink is basically impossible in shell, and barely possible in C ;) | 05:39 |
| alkisg | Whoops :) | 05:39 |
| slangasek | still, that's the way you subscribe to kernel network change events | 05:39 |
| seb128 | wgrant, hey, could you trigger an artful langpack export manually? I would like to refresh the base pack to look at where we stand with those without having to wait for next monday | 08:07 |
| wgrant | seb128: Have you hit the web UI flag to request the full export? | 08:09 |
| seb128 | wgrant, yes | 08:10 |
| wgrant | seb128: It's running now. | 08:12 |
| seb128 | wgrant, thanks! do you know how long the job takes nowadays? | 08:13 |
| wgrant | seb128: Looks like about 3h15 | 08:15 |
| seb128 | nice | 08:15 |
| seb128 | thx | 08:15 |
| LocutusOfBorg | kirkland, hello, wrt your pdf (thanks for sharing it) | 08:50 |
| LocutusOfBorg | page 18, rhythmbox is in two different graphs | 08:51 |
| LocutusOfBorg | because many people mispelled it | 08:51 |
| xnox | infinity, netcfg: relocation error: /lib/libnss_dns.so.2: symbol __resolv_context_get, version GLIBC_PRIVATE not defined in file libc.so.6 with link time reference | 09:29 |
| xnox | i wonder what am I doing wrong | 09:29 |
| xnox | hm my libc.so.6 checksums don't match | 09:42 |
| xnox | ok rebuild again, and things are fine | 09:54 |
| xnox | unping | 09:54 |
| cpaelzer | LocutusOfBorg: I remember doing so on other packages but I fail to find the link to the old llvm versions debs to download for bug 1717574 | 10:42 |
| ubottu | bug 1717574 in clamav (Ubuntu) "freshclam crashed with SIGABRT in __assert_fail_base()" [Medium,Confirmed] https://launchpad.net/bugs/1717574 | 10:42 |
| cpaelzer | I thought to remember something like built binaries being a list of debs, but can't find the right link from publishing hostroy to them atm :-/ | 10:42 |
| cpaelzer | ah on the builds | 10:43 |
| LocutusOfBorg | exactly | 10:43 |
| LocutusOfBorg | click on the version, and grab the debs | 10:43 |
| cpaelzer | I knew I did that before :-) | 10:43 |
| LocutusOfBorg | snapshots.debian.org works better indeed | 10:43 |
| LocutusOfBorg | you just need libllvm3.9 AFAICS | 10:44 |
| cpaelzer | for dependencies it is libllvm3.9 llvm-3.9 llvm-3.9-dev llvm-3.9-runtime, which isn't much harder | 10:47 |
| cpaelzer | while the case is building I can script the fetch of all those pkg's | 10:47 |
| doko | mehh, opencv was synced from experimental :-/ | 11:09 |
| blaze | qtcreator still depends on outdated llvm libllvm3.9 (>= 1:3.9.1-6~), isn't it possible to rebuild it? | 11:19 |
| cpaelzer | LocutusOfBorg: since 1:3.9.1-13ubuntu6-13377849 | 11:20 |
| cpaelzer | LocutusOfBorg: but there was quite a lot in between | 11:21 |
| cpaelzer | LocutusOfBorg: that was on those that released, I'll split those that at least built and made it into LP publishing history after lunch | 11:22 |
| doko | mapreri: please could you have a look at the sikuli ftbfs? works with opencv2 in debian ... you synced the new one from experimental | 11:23 |
| === rbalint_ is now known as rbalint | ||
| mapreri | doko: you mean sikulix? well, I only did https://launchpad.net/ubuntu/+source/sikulix/1.1.0-2build1 that went just file (+ ubuntu1 to fix an hardcoded dependency) | 11:42 |
| mapreri | i.e. didn't do anything extra/special for it | 11:42 |
| doko | mapreri: well, changes lists you ask the one syncing ... | 11:42 |
| doko | as even | 11:42 |
| mapreri | doko: I'll have a look, as that means we have yet another package breaking with opencv 3 now, and we're struggling to take that transition to an end :\ | 11:43 |
| mapreri | just not today | 11:43 |
| doko | ta | 11:44 |
| doko | mapreri: so my idea to sync opencv again was not a good idea. probably will reject it, currently sitting in NEW | 12:00 |
| cpaelzer | LocutusOfBorg: more specific it broke 1:3.9.1-13ubuntu4-13351809 -> 1:3.9.1-13ubuntu6-13377849 | 12:02 |
| mapreri | doko: yes, I recommend against. OCV 3.2 brings more FTBFS among its rdeps that 3.1 doesn't. | 12:14 |
| mapreri | I aim at working on it on the debian side (finally) during the next days and the week end | 12:14 |
| LocutusOfBorg | cpaelzer, since the failure happens on i386 too, would be nice to test 3.9.1-13ubuntu5 | 12:18 |
| LocutusOfBorg | doko, how could using -g1 instead of -g cause the issue https://launchpad.net/bugs/1717574 | 12:19 |
| ubottu | Launchpad bug 1717574 in clamav (Ubuntu) "freshclam crashed with SIGABRT in __assert_fail_base()" [Medium,Confirmed] | 12:19 |
| LocutusOfBorg | blaze, why? there is no need to have a stricter dependency | 12:20 |
| doko | does clamav use unwinding internally? | 12:22 |
| cpaelzer | LocutusOfBorg: need to setup an nev doing so on i386, but ok easy enough | 12:23 |
| LocutusOfBorg | I uploaded something in a ppa | 12:29 |
| LocutusOfBorg | https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/costamagnagianfranco-ppa/+packages | 12:29 |
| LocutusOfBorg | it won't probably build | 12:29 |
| LocutusOfBorg | also, I expect it to fail also here http://debomatic-amd64.debian.net/distribution#unstable/clamav/0.99.3~beta1+dfsg-2build1/buildlog | 12:30 |
| LocutusOfBorg | since the same llvm is in Debian | 12:30 |
| LocutusOfBorg | if it doesn't fail, I would blame glibc | 12:31 |
| cpaelzer | The same test doesn't trigger in i386 | 12:35 |
| cpaelzer | I'll check out your ppa ocne built | 12:36 |
| blaze | LocutusOfBorg: look at the package name: libllvm3.9 | 12:37 |
| LocutusOfBorg | libllvm3.9 (>= 1:3.9.1-6~), | 12:37 |
| blaze | now I have 3.9, 4.0 and 5.0. Isn't it a bit toomuch | 12:37 |
| LocutusOfBorg | this means, everything with an higher value | 12:37 |
| LocutusOfBorg | blaze, if you want to port the code to llvm 4.0, 5.0 or 6.0, you are welcome to do it | 12:38 |
| LocutusOfBorg | cpaelzer, http://debomatic-amd64.debian.net/distribution#unstable/clamav/0.99.3~beta1+dfsg-2build1/buildlog | 12:38 |
| LocutusOfBorg | good | 12:38 |
| LocutusOfBorg | so I blame glibc | 12:38 |
| cpaelzer | wow that worked | 12:38 |
| cpaelzer | interesting | 12:38 |
| cpaelzer | so this becomed a package update love triangle then | 12:39 |
| LocutusOfBorg | my package won't probably build because llvm takes too memory on amd64 without -g1 | 12:39 |
| LocutusOfBorg | rbalint, unattended-upgrades merge? | 12:44 |
| smoser | slangasek, i'm not sure that "it's not actually about supporting netplan, but about supporting systemd-networkd?" is true. | 12:46 |
| smoser | from a forward looking perspective, systemd-networkd is happenstance and netplan is design. i'd much rather tell people "this is how you integrate with netplan" and promise that that will work in 18.04, 20.04 and 22.04 then "integrate with systemd-networkd and then we might tell you something else in 20.04" | 12:47 |
| smoser | ie, it *is* about supporting netplan. and netplan being able to support things that interact with networking events. | 12:48 |
| ddstreet | bdmurray can you approve artful nomination for lp #1716964 please | 13:10 |
| ubottu | Launchpad bug 1716964 in vlan (Ubuntu Zesty) "VLAN network script if-up.d/ip limits rp_filter value to 0 or 1" [Medium,In progress] https://launchpad.net/bugs/1716964 | 13:10 |
| doko | bdmurray: 1715641 doesn't match the changelog. wrong number? | 13:17 |
| rbalint | LocutusOfBorg: yes, i'm preparing it | 13:19 |
| LocutusOfBorg | cpaelzer, interestingly, clamav builds on all except amd64 and i386 | 13:41 |
| kirkland | LocutusOfBorg: indeed, turns out "rhythm" is a hard word to spell :-) | 13:43 |
| LocutusOfBorg | :) | 13:44 |
| LocutusOfBorg | kirkland, fortunately the outcome didn't change | 13:44 |
| LocutusOfBorg | it is still in second place | 13:44 |
| doko | rbasak: is mariadb serverish? if yes, there are autopkg test failures on ppc64el and s390x | 13:49 |
| LocutusOfBorg | btw such results, are probably somewhat faulty, because people who answered, are probably ubuntu users, and Ubuntu always used gnome apps | 13:50 |
| rbasak | doko: yes, though not in main. I've passed on a message to one of the DDs who looks after it for us in Ubuntu. | 13:56 |
| rbasak | (well, pinged him on IRC at least - #debian-mysql on OFTC) | 13:56 |
| doko | ta | 13:56 |
| xnox | doko, yes but it is systemd fault | 14:01 |
| xnox | rbasak, unping | 14:01 |
| ricotz | LocutusOfBorg, hi, regarding your mention of rustc/cargo, syncing libgit2 0.26.0 would still be nice | 14:10 |
| ddstreet | bdmurray would you like to sponsor a bug for me into artful? or cpaelzer perhaps? lp #1716964 please | 14:13 |
| ubottu | Launchpad bug 1716964 in vlan (Ubuntu Zesty) "VLAN network script if-up.d/ip limits rp_filter value to 0 or 1" [Medium,In progress] https://launchpad.net/bugs/1716964 | 14:13 |
| cpaelzer | ddstreet: bdmurray: I'm looking at it | 14:40 |
| ddstreet | cpaelzer thnx | 14:40 |
| ddstreet | bdmurray i have another one you could sponsor please, lp #1718055 | 14:41 |
| ubottu | Launchpad bug 1718055 in initramfs-tools (Ubuntu) "update-initramfs fails for MODULES=dep when root is on LVM wich uses nvme device" [Medium,In progress] https://launchpad.net/bugs/1718055 | 14:41 |
| LocutusOfBorg | ricotz, but out of Ffe | 14:47 |
| doko | nacc: https://launchpad.net/ubuntu/+source/pacemaker/1.1.17-1ubuntu1 | 15:05 |
| nacc | doko: yeah, it's ftbfs in debian too | 15:05 |
| nacc | doko: LP: #1712441 | 15:06 |
| ubottu | Launchpad bug 1712441 in pacemaker (Ubuntu) "pacemaker 1.1.17-1ubuntu1 FTBFS" [Undecided,New] https://launchpad.net/bugs/1712441 | 15:06 |
| cpaelzer | LocutusOfBorg: I see your llvm ppa at dh_install so it might even succeed | 15:08 |
| LocutusOfBorg | cpaelzer, strange | 15:08 |
| LocutusOfBorg | I see it too | 15:09 |
| rbasak | xnox: error: ping stack underflow :-) | 15:25 |
| xnox | rbasak, que....? | 15:29 |
| rbasak | <xnox> rbasak, unping | 15:30 |
| rbasak | Never mind :) | 15:30 |
| xnox | rbasak, hahahahah =) ok | 15:30 |
| * xnox doesn't understand underflow jokes, i mostly code in C </giggles> | 15:30 | |
| slangasek | seb128: uhhhh how is gnome-software using packagekit instead of aptdaemon now? that's not ok | 15:41 |
| === zyga-ubu1tu is now known as zyga-ubuntu | ||
| seb128 | slangasek, why is it not ok? | 15:42 |
| seb128 | slangasek, it's bug #1673258, aptdaemon is unmaintained for years | 15:42 |
| ubottu | bug 1673258 in update-notifier (Ubuntu) "Remove aptdaemon and drop or port its reverse-dependencies" [Undecided,New] https://launchpad.net/bugs/1673258 | 15:42 |
| slangasek | seb128: packagekit's lack of debconf integration is a critical blocker, we JUST fixed all the regressions with debconf handling that were breaking users from being able to enable dkms modules on secureboot systems | 15:42 |
| slangasek | yes, aptdaemon is unmaintained; but packagekit is broken by design | 15:43 |
| slangasek | this needs to be reverted | 15:43 |
| seb128 | slangasek, I though that debconf was working in gnome-software now (robert_ancell fixed that iirc) | 15:43 |
| seb128 | slangasek, I don't think it's as simple as "can be reverted" | 15:43 |
| slangasek | seb128: AIUI it was working by way of an aptdaemon backend, not packagekit | 15:43 |
| slangasek | am I mistaken? | 15:43 |
| seb128 | could be, I didn't check | 15:43 |
| seb128 | Laney probably knows more | 15:43 |
| slangasek | ok | 15:44 |
| slangasek | I thought you were referring to a recent change in artful :) | 15:44 |
| seb128 | it's not that old | 15:44 |
| seb128 | we dropped our aptd backend and switching to packagekit in 3.25 | 15:44 |
| seb128 | which landed in august iirc | 15:44 |
| slangasek | ok hmm | 15:44 |
| slangasek | cyphermox, bdmurray: ^^ we need to revalidate virtualbox install on secureboot in 17.10 | 15:45 |
| seb128 | did anyone test recently? | 15:45 |
| slangasek | seb128: not in the past month, I'm sure | 15:47 |
| bdmurray | slangasek: I forget was there a bug with instructions for testing that? | 15:47 |
| Laney | I don't know that PK doesn't work with debconf. | 15:48 |
| slangasek | bdmurray: LP: #1679435 is the bug | 15:48 |
| ubottu | Launchpad bug 1679435 in gnome-software (Ubuntu Artful) "GNOME Software fails to install .deb packages that trigger debconf prompts" [High,Fix released] https://launchpad.net/bugs/1679435 | 15:48 |
| Laney | Robert worked on that https://mail.gnome.org/archives/gnome-software-list/2017-May/msg00010.html | 15:48 |
| slangasek | was that with the pk backend? I don't know. if there's been a change, we need to revalidate | 15:48 |
| slangasek | in any case, there are also architectural problems with how pk approaches apt that are going to be a problem down the line | 15:49 |
| slangasek | infinity can speak to this | 15:49 |
| infinity | slangasek: I mean, I can in theory. I'm pretty sure I need to re-evaluate the current state of the world. | 15:52 |
| slangasek | ok | 15:52 |
| infinity | slangasek: In the past, pk's approach to apt/dpkg was "install the package you asked for and hope for the best, and hey, maybe we'll try some crap dependency resolution on our own", ie: it entirely bypassed apt. | 15:53 |
| infinity | slangasek: aptdaemon, of course, is the other end of the insane spectrum, which is "hand off an exact apt-get call to aptdaemon, and let it go to town", which gets perfect results, but also assumes you entirely trust the every bit of that pipe. | 15:54 |
| cjwatson | I think that must have been quite a while in the past | 15:54 |
| cjwatson | I haven't looked very recently, but when I was trying to understand packagekit for click, it made basically sensible apt transactions | 15:54 |
| infinity | slangasek: I haven't looked at the current state of pk, but unless they invoke apt or python-apt to do proper resolution, I have doubts it'd be any better than it once was. | 15:54 |
| infinity | cjwatson: Okay, that sounds promising. What do you mean by "apt transactions"? Does it invoke apt via backend priv escalation? | 15:55 |
| infinity | (Which would, effectively, make it aptdaemon part two) | 15:55 |
| cjwatson | it's using libapt | 15:56 |
| infinity | s/part/mark/ | 15:56 |
| cjwatson | in C++ | 15:56 |
| cjwatson | (I think) | 15:56 |
| infinity | Well, that's definitely more promising then. | 15:56 |
| cjwatson | see backends/aptcc/ (you might want to check that that's actually still the backend in use) | 15:56 |
| infinity | Probably still has issues with bubbling up dpkg interaction, but aptdaemon had that same problem (it's just that aptdaemon frontends were usually written to know that). | 15:57 |
| infinity | Anyhow, if it's using libaptpkg, I think many of my old concernes might be moot. | 15:58 |
| cjwatson | You should definitely actually review its current state, since it sounds like your concerns are from several years ago at least. | 15:58 |
| infinity | I still loathe the gnome-software UI, but that's not a technical concern. :P | 15:58 |
| infinity | cjwatson: Oh, indeed, as mentioned when I jumped into the conversation, my concerns are based on outdated information from the last time I argued with pk and gave up ever wanting to use it on dpkg systems. ;) | 15:59 |
| infinity | And I believe that was from the last time someone suggested update-manager should be ported to pk, and the conclusion was "lol, no". | 15:59 |
| slangasek | cool; if the net is that pk does meet our needs and we can migrate to it, that's a good item to have off the lits | 16:00 |
| cjwatson | At one point there was a threat to remove aptcc due to undermaintenance, but I see a chunk of maintenance from (mainly) Ubuntuish people that's more recent than that. | 16:00 |
| cjwatson | So that's probably not a problem any more. | 16:00 |
| slangasek | however, since we didn't expect pk to be a viable replacement for aptdaemon, we haven't scoped that work for update-manager this cycle | 16:00 |
| infinity | slangasek: Yup, definitely worth re-evaluating the world here and seeing if aptdaemon can indeed die. | 16:00 |
| cyphermox | slangasek: I have this brand new install of artful where I can go install virtualbox from the software tool | 16:02 |
| slangasek | cyphermox: so you're going to take care of validating this and bdmurray doesn't need to look further? | 16:03 |
| cyphermox | sure, I'm kicking it *now* | 16:03 |
| slangasek | ok | 16:04 |
| cyphermox | or I would have, if gnome-software hadn't crashed on me | 16:04 |
| slangasek | dun-dun-dunnnnn | 16:04 |
| cyphermox | it's working now... | 16:05 |
| cyphermox | I do have a prompt. That was using the image from yesterday | 16:06 |
| cyphermox | is that software/pk change something that landed today? | 16:06 |
| Laney | no | 16:08 |
| Laney | several weeks ago | 16:08 |
| cyphermox | ah, backlog tells me | 16:08 |
| cyphermox | right | 16:09 |
| cyphermox | that's what I thought too, just making sure | 16:09 |
| cyphermox | thanks Laney | 16:09 |
| Laney | sounds good, we can not panic? | 16:09 |
| Laney | :-) | 16:09 |
| cyphermox | yes, we can not panic | 16:09 |
| Laney | great, thanks | 16:09 |
| * cyphermox moves the hands away from the Big Red Panic Button | 16:09 | |
| cyphermox | Laney: how can I make very sure this indeed used PK and not aptdaemon, given that aptdaemon is still on the system? | 16:10 |
| cyphermox | I mean, I would expect things to just use DBus, but as I recall aptdaemon has just enough DBus pretention of being PK | 16:11 |
| Laney | it doesn't, that was dropped | 16:12 |
| cyphermox | oh right, I dropped it :) | 16:12 |
| Laney | there's probably PackageKit stuff in the journal | 16:13 |
| cyphermox | indeed | 16:15 |
| cyphermox | history.log mentions this was a Commandline: packagekit role='install-packages' | 16:15 |
| bdmurray | I tested it with the noisy-fake-driver deb and it worked for me too with packagekit in the history.log | 16:18 |
| Laney | ♥ | 16:20 |
| slangasek | \o/ | 16:24 |
| slangasek | cyphermox, seb128, Laney, bdmurray: thanks for the double-check | 16:24 |
| slangasek | now if we could figure out how to make that an autopkgtest... :) | 16:24 |
| cyphermox | make the installing the driver | 16:24 |
| cyphermox | ? | 16:24 |
| cyphermox | should be "doable", but requires an UEFI-SB-enabled VM | 16:25 |
| slangasek | we would need to be able to drive gnome-software programmatically | 16:25 |
| cyphermox | that too | 16:25 |
| slangasek | it doesn't have to be SB-enabled, see fake-noisy-driver | 16:25 |
| cyphermox | oh, that one is doing straight debconf? | 16:25 |
| cyphermox | because you don't necessarily have to run gnome-software programmatically, it could be dbus-driven, as a PK autopkgtest. | 16:26 |
| cyphermox | (I think) | 16:26 |
| LocutusOfBorg | cpaelzer, works :/ | 16:27 |
| Laney | there's a gnome-software-cmd | 16:27 |
| Laney | feel free to look at / hack on that :-) | 16:27 |
| Laney | (also, it has a testsuite) | 16:28 |
| Laney | not an autopkgtest one, but it is a start | 16:28 |
| slangasek | cool, then we would just need to divert the gnome debconf frontend :) | 16:31 |
| slangasek | cyphermox: this is not about autopkgtesting pk, it's about autopkgtesting gnome-software. | 16:31 |
| slangasek | autopkgtesting pk itself would be useless, because the debconf passthrough has to be setup /by/ gnome-software | 16:32 |
| cyphermox | ah, right :( | 16:38 |
| cpaelzer | LocutusOfBorg: the ppa build works, I updated the bug | 17:24 |
| smoser | ok. clearly i dont know what i'm doing | 17:37 |
| smoser | i go https://extensions.gnome.org/extension/615/appindicator-support/ | 17:37 |
| smoser | i click 'on' | 17:38 |
| smoser | it moves over, but then reloading the page shows 'off' again. | 17:38 |
| LocutusOfBorg | strange cpaelzer , really strange | 17:53 |
| nacc | smoser: fwiw, i thikn there's something lower level busted with extensions in artful | 17:54 |
| nacc | smoser: you're not the onnly one to complain of this (and i see it too with the tweak tool) | 17:54 |
| nacc | smoser: the only extensions i got to to 'stay on' were those that had the gear and in their submenu i had to turn them on as well | 17:55 |
| smoser | nacc, :-( | 18:27 |
| nacc | smoser: yeah | 18:28 |
| smoser | nacc, i completely removed just about all my .* files | 18:28 |
| smoser | tried agin | 18:28 |
| smoser | now i get 'error' | 18:28 |
| nacc | smoser: yeah, have a test user for the same purposes | 18:28 |
| nacc | smoser: i can switch over to it later and check | 18:28 |
| smoser | seems like it must have worked at some point | 18:32 |
| smoser | https://didrocks.fr/2017/08/23/ubuntu-gnome-shell-in-artful-day-7/ | 18:32 |
| smoser | anyone know how to configure more than 2 virtual desktops or viewports or whatever they're called. | 18:42 |
| smoser | logged in to default Ubuntu (which i'm pretty sure is wayland now) | 18:42 |
| jbicha | smoser: I recommend installing gnome-tweak-tool 3.26.1-1ubuntu1 which has some fixes for the Workspaces panel | 19:01 |
| jbicha | it's brand new | 19:02 |
| smoser | jbicha, in -proposed ? | 19:08 |
| * smoser gets | 19:09 | |
| nacc | not in artful at all afaict | 19:09 |
| nacc | artful or artful-proposed | 19:09 |
| nacc | per rmadison | 19:09 |
| nacc | jbicha: --^ | 19:09 |
| smoser | https://launchpad.net/ubuntu/+source/gnome-tweak-tool | 19:09 |
| smoser | ^ shows in -proposed as of 16 minutes ago. you are way behind the times nacc | 19:09 |
| nacc | smoser: ah rmadison hasn't seen it yet | 19:09 |
| jbicha | I did say it was brand new ;) | 19:11 |
| nacc | heh | 19:12 |
| dmj_s76 | Trevinho: I think there are some issues with the new scaling code in gnome 3.26. | 19:15 |
| dmj_s76 | There's been a fairly recent regression where the shell text is tiny every login. the control center also requires the user to set the scale twice for it to actually take effect. | 19:17 |
| jdstrand | xnox: hi! so, in your estimation, is there anything special I should have to do to ssh into lxd containers or libvirt qemu guests on artful? (ie, with systemd-resolved) | 20:35 |
| nacc | jdstrand: (to be clear (from #snappy) -- i have the ssh snippet stgraber recommended) | 20:36 |
| nacc | jdstrand: and i generally use uvt-kvm for VMs | 20:36 |
| stgraber | right and that snippet bypasses DNS so you don't have to fight with systemd | 20:40 |
| nacc | yep | 20:40 |
| jdstrand | xnox: ok, nm on lxc (nacc is referring to http://paste.ubuntu.com/25582138/ for lxd), but how about libvirt? | 20:41 |
| * jdstrand nods | 20:41 | |
| jdstrand | I could probably do the same with libvirt | 20:41 |
| jdstrand | that would be way better than injecting stuff into resolved, only to have it occasionally forget | 20:41 |
| stgraber | jdstrand: https://stgraber.org/2012/07/17/easily-ssh-to-your-containers-and-vms-on-ubuntu-12-04-lts/ | 20:42 |
| stgraber | jdstrand: that has the .libvirt equivalent | 20:42 |
| jdstrand | nic | 20:43 |
| jdstrand | nice even | 20:43 |
| jdstrand | stgraber: that is *super* helpful. I've been using way worse workarounds for so long it is sad | 20:43 |
| jdstrand | stgraber: thanks! :) | 20:43 |
| jdstrand | ah right, the dnsmasq looks at the host's configuration so you get: | 20:53 |
| jdstrand | $ host sec-xenial-amd64 192.168.122.1 | 20:53 |
| jdstrand | ... | 20:53 |
| jdstrand | sec-xenial-amd64 has address 192.168.122.182 | 20:53 |
| jdstrand | Host sec-xenial-amd64 not found: 2(SERVFAIL) | 20:53 |
| jdstrand | ;; connection timed out; no servers could be reached | 20:53 |
| jdstrand | which is slow and annoying. however, libvirt now has virsh domifaddr | 20:54 |
| jdstrand | so I can use that | 20:54 |
| ddstreet | very good .ssh-config-fu ^ I will have to use similar modifications for my lxd/uvt-kvm instances | 21:00 |
| nacc | ddstreet: if you use uvt-kvm, then i thinkn you can use `uvt-kvm ip <isntance>` | 21:00 |
| nacc | ddstreet: or just use uvt-kvm ssh <instance> :) | 21:00 |
| ddstreet | nacc i do that, but uvt-kvm ssh forces you to use --insecure every time | 21:01 |
| ddstreet | so right now i alias uvssh='uvt-kvm ssh --insecure' | 21:01 |
| nacc | ddstreet: heh | 21:01 |
| nacc | good poitn | 21:01 |
| ddstreet | but throwing a bit of .ssh/config logic in there will let me ssh to them even more easily | 21:01 |
| ddstreet | and lxd containers too, i just do lxc exec bash now | 21:02 |
| jdstrand | ddstreet: I landed on this for libvirt: http://paste.ubuntu.com/25582228/ | 21:02 |
| * nacc suggests someone do a blog post | 21:03 | |
| * jdstrand is doing it now :) | 21:03 | |
| nacc | heh | 21:03 |
| ddstreet | jdstrand that's pretty good i may steal that for my .ssh/config ;-) | 21:05 |
| ddstreet | jdstrand nacc this is what i wound up with for lxd: http://paste.ubuntu.com/25582407/ | 21:36 |
| ddstreet | just uses the first non-lo ipv4 addr it finds | 21:37 |
| nacc | ddstreet: why not just use -c4 like the other one? | 21:37 |
| nacc | ddstreet: which explicitly askes for the ipv4 config? | 21:37 |
| ddstreet | nacc -c4 to what, cut? | 21:38 |
| nacc | ddstreet: lxd list | 21:38 |
| nacc | *lxc list | 21:38 |
| ddstreet | nacc yeah you can do that, parsing that table output is a bit harder imo | 21:38 |
| cjwatson | lxc list --format=json would probably be more sensible than all this seddery | 21:38 |
| cjwatson | with jq | 21:38 |
| cjwatson | shame info doesn't have that | 21:39 |
| nacc | ddstreet: i'm just quoting stgraber's reference :) | 21:39 |
| nacc | cjwatson: true :) | 21:39 |
| ddstreet | cjwatson oh i like that | 21:39 |
| stgraber | that was unfortunately missing back in LXD 2.0 :) | 21:39 |
| ddstreet | yes, i don't know how anyone got anything done with containers before lxd 2.0, very happy for it xD | 21:40 |
| nacc | heh | 21:40 |
| ddstreet | i mean pre-lxd 2.0 is still light-years ahead of non-lxc/non-lxd | 21:40 |
| stgraber | these days (2.17+) you could even use something like: lxc query /1.0/containers/artful/state | jq -r .network.eth0.addresses[0].address | 21:41 |
| stgraber | which would grab just what you need in a single API call | 21:41 |
| cjwatson | yeah, it's quite fiddly with earlier versions | 21:44 |
| cjwatson | lxc list -c4 --format=json | jq -r 'map(select(.name=="INSERT-CONTAINER-NAME-HERE"))|.[].state.network.eth0.addresses[0].address' is the best I've been able to do with xenial's lxd | 21:45 |
| cjwatson | (probably possible to do better - I only speak quite basic jq) | 21:45 |
| ddstreet | stgraber i'm still waiting for lxc ssh NAME ;-) | 21:46 |
| seb128 | dmj_s76, did you report bugs on launchpad (and maybe GNOME upstream) about those hidpi issues? | 22:36 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!