[01:05] dmj_s76: that's something that is using the classic scaling mode, not the new one... [01:07] Trevinho: hmm...there have been a lot changes in the mutter/settings center code recently, even for xorg [01:07] if not directly from hidpi work then from the settings center changes. === maclin1 is now known as maclin [03:16] How would I go about using syncpackage with a package from wheezy-security? [03:17] (oh, just as I got done typing that I see other uploads in {stretch,jessie}-security but it's still an interesting question nonetheless) [03:24] (probably just needs --no-lp and the link to the dsc file) [05:34] LocutusOfBorg: your last llvm didn't go in for a failed upload https://launchpadlibrarian.net/337703796/upload_13396831_log.txt [05:41] sure cpaelzer there is an ubuntu3 [05:41] not sure why it was good amd64 on my ppa and not on ubuntu official builds [05:42] well only s390x didn't copy [05:42] but ok looking for ubuntu3 then [05:42] ah no ubuntu3 is the one with amd64 issues [05:42] ok I see [05:44] cpaelzer, didn't copy because of superseeded [05:46] well whatever it is worth, the ubuntu2 that didn't copy works [05:47] LocutusOfBorg: since you said the same ubuntu3 worked for you before what is the plan, rebuilding that? [06:16] cpaelzer, I'm trying a patch without that RELWITHDEBINFO [06:16] or relegated only for arm64 [06:23] LocutusOfBorg: ok, just let me know if I shall try anything new [07:05] LocutusOfBorg, cpaelzer: what are you trying? we are back with two one gigabyte debug builds on ppc64el and s390x, and of course the failing amd64 build [07:09] doko, -g1 is breaking clamav [07:09] -g works [07:09] I'm doing a -g -NDEBUG to see what happens [07:12] doko: bug 1717574 [07:12] bug 1717574 in clamav (Ubuntu) "new llvm3.9 breaking freshclam bytecode execution" [Medium,Confirmed] https://launchpad.net/bugs/1717574 [07:14] cpaelzer: is this upstreamed to clamav, or are trying to change things which we don't understand? why is a change for the debug information responsible for that? [07:14] s/are/are we/ [07:15] doko: I only rerun the test and found the link of the issue to llvm - there is no clamav change [07:16] doko: so nothing to upstream there that we'd know yet [07:16] doko: it is just that their bytecode worked before a certina llvm upload and fails since then [07:16] cpaelzer: did you try to rebuild clamav with the same flags as llvm? [07:17] cpaelzer: or did you try to rebuild clamav at all? [07:17] we rebuilt clamav with old and new llvm, but not change flags [07:17] none of the rebuilds had any effect [07:17] we also tried a new clamav just to be sure [07:17] but yeah, no changes in flags, except for llvm [07:18] please can you report that upstream? [07:20] so far things looked like "Ubuntu changed the llvm build and that broke clamav" at least I expected clamav to say "so what fix your llvm" - but I can report if you think that is worth [07:25] cpaelzer: we can't accomodate these builds if they take too much disk space to build, and even if, each of these packages take 1 gb, that makes 4gb for every upload ... [07:28] doko: I did never say "please make them big" I'm only naively debugged a clamav crash and found that it is broken since these llvm uploads [07:28] I beg your pardon if that got to you differently [07:29] I'm reporting to clamav and will link it up [07:30] Also the case is easily reproducible, I msut admit I don't even understand why exactly it now fails [07:30] doko: if you follow the bug I linked maybe you can see what the actual root cause might be the reason for that incompatibility [07:31] cpaelzer: what is the change in compiler and linker flags? [07:32] cpaelzer, https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/costamagnagianfranco-ppa/+packages [07:32] II uploaded a new llvm with -g1 (to make doko and infra happy) and with -DNDEBUG [07:32] what I discovered, is that ppassing RELWITHDEBINFO flags, overrides the cmake default ones [07:32] and that -DNDEBUG is stripped then [07:32] so the change has probably been a side-effect of that -g1, but not directly related [07:34] I'll test that once it is built LocutusOfBorg [07:34] cpaelzer: there's nothing about this -DNDEBUG in the bug report [07:35] and then find out why clamav is relying on that ... [07:35] I discovered it some minutes ago, melding the failed amd64 and the succeeded one [07:36] because in my ppa it was good that build [07:36] you should turn on creation of debug package in your ppa if you want to simulate the builders [07:38] both enabled, build and publish [07:38] thanks for the reminder, I admit I didn't recheck it [07:47] interesting, libclamav is using some NDEBUG stuff [07:48] LocutusOfBorg: doko: I reported to clamav and linked it up in the bug [07:49] LocutusOfBorg: let me know if/once there is a build I shall try for you [07:49] configure: CXXFLAGS from llvm-config: -I/usr/lib/llvm-3.9/include -std=c++0x -gsplit-dwarf -Wl,-fuse-ld=gold -fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wno-maybe-uninitialized -Wdelete-non-virtual-dtor -Wno-comment -Werror=date-time -std=c++11 -ffunction-sections -fdata-sections -O2 -g -DNDEBUG [07:49] -fno-exceptions -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS [07:49] interestingly, clamav is getting the build flags from llvm, so a no change rebuild should change them too [07:50] and in fact this seems to happen [07:50] but you rebuilt a new clamav [07:50] also I did with a local build vs the new library and -dev packages [07:52] but clamav not picking up NDEBUG from llvm flags, means that the code ifdefs are not triggered [07:52] this means less asserts [07:53] but the clamav currently in artful uploaded by mdeslaur still built by picking -DNDEBUG up as it was before the llvm changes [07:53] I think I'll directly upload to Ubuntu this one [07:53] https://launchpadlibrarian.net/333379617/buildlog_ubuntu-artful-amd64.clamav_0.99.2+dfsg-6ubuntu2_BUILDING.txt.gz [07:54] LocutusOfBorg: do you mean we have lost the -NDEBUG in llvm and those "extra" asserts might be the reason to break it now? [07:54] somewhat this is a possible reason [07:54] rebuilding makes it assert because the current llvm in artful proposed is built without [07:54] probably rebuilding it with -DNDEBUG makes it pass [07:56] LocutusOfBorg: ok, so since clamav is already built with -DNDEBUG from the old llvm builds that would mean likely no re-upload there. Once your ppa is ready I would install from it and then retry + rebuild+retry - ok? [07:57] ok [07:57] so waiting on https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/costamagnagianfranco-ppa/+build/13399109 now [07:57] I could also upload directly to Ubuntu [07:57] I personally prefer uploading to ubuntu what is known or at least expected to work [07:57] the current proposed one has debug symbols too huge [07:57] ah, ok I see the reason [07:58] even if not working, it is worth an upload [07:58] * LocutusOfBorg meeting time [07:58] well, are you sure the ubuntu5 at least builds and is as good/bad than the last one that had small symbols? [07:58] I'll carry all this discussion into the bug for documentation [08:04] yes, it should build [08:04] now with debug logs melded I had a clear view of the build issue [09:02] coreycb: ping [09:57] cpaelzer, mostly built [09:58] https://launchpad.net/ubuntu/+source/llvm-toolchain-3.9/1:3.9.1-16ubuntu4/+build/13399140 [10:51] Hi guys! I was looking at the latest Live CD/USB manifest (http://cdimage.ubuntu.com/daily-live/pending/artful-desktop-amd64.manifest), at the Ubuntu Package Search (https://packages.ubuntu.com/), and at Launchpad (https://launchpad.net/ubuntu), and I noticed that there are still lots of GNOME-related packages with 3.25.x versions (3.26 pre-releases). Will they be replaced with proper 3.26 versions? What about packages that [10:51] are stuck at 3.24 (e.g., gnome-terminal or gnome-getting-started-docs, among others)? And perhaps there are even packages lingering from even older GNOME releases that I've missed! Any plans about this? [11:17] petersaints: that's a lot of questions! [11:18] the docs package might get updated today. Generally if we have a 3.25 version we can update it to 3.26. Terminal might stay at 3.24 [11:19] for 17.10 [11:28] Thats what I thought @jbicha. It wouldn't have made much sense to move packages to 3.25.x if they are not supposed to be replaced by the final 3.26 version. [11:28] And thanks for the reply jbicha [11:33] LocutusOfBorg: FYI 1:3.9.1-16ubuntu4 from the current build in a-p is not working [11:33] 1:3.9.1-16ubuntu2 from the same place did work [11:35] so while -DNDEBUG was a nice idea, that wasn't it [11:35] no reply on the upstream report yet [12:13] mwhudson: golang still at 1.8, and nobody complained? [12:13] so cpaelzer I have zero idea [12:13] if doko is not happy with debug symbols of 1gb, and no other flags changed... [12:13] I don't know [12:13] (I'm not happy with them too, btw) [12:14] cpaelzer, did you try a rebuild of it? [12:14] did you try to use -g1 in clamav too? [12:28] configure: CXXFLAGS from llvm-config: -I/usr/lib/llvm-3.9/include -std=c++0x -Wl,-fuse-ld=gold -Wl,--no-keep-files-mapped -Wl,--no-map-whole-files -fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wno-maybe-uninitialized -Wdelete-non-virtual-dtor -Wno-comment -Werror=date-time -std=c++11 -ffunction-sections -fdata-sections -g1 - [12:29] fno-exceptions -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS [12:29] LocutusOfBorg: I thought you brought -DNDEBUG back but in combination with -g1 in ubuntu4 [12:30] And failing still when rebuilt against the most recent - as expected [12:42] I'm really with no ideas [12:42] some parts in llvm build log are with -g instead of -g1 [12:42] not sure why [12:42] btw manually adding -DNDEBUG does change something? [12:53] ohh wonderful new gnome3 world ... [12:57] Laney, seb128: python2 is back on the desktop. was this intended? [12:58] ubuntu-artwork team using python2. great! [12:59] ... and samba is installed by default again ... [13:01] doko, what is bringing it in [13:01] ? [13:02] seb128: ^^^ [13:02] doko, ubuntu-artwork team ... a team is using python? [13:02] for what package? [13:03] ahh, adium-theme-ubuntu [13:07] seb128: or is this temporary and will be replaced? [13:08] sil2100, hi, I have tried to use '--image-size' option in ubuntu-core. The effect is that the size of the resulting volume is as I specified, but the rootfs partition has the same size as before, leaving empty space in the volume... [13:09] sil2100, is that a bug? [13:09] doko, that seems like a packaging error, let me look [13:09] s/ubuntu-core/ubuntu-image [13:09] just asking because this theme has changes up to 2012, and one in 2016 [13:12] doko, that theme is not very active indeed but can still be useful [13:13] seb128: but it's installed by default [13:13] right [13:13] it's still useful [13:14] ok, converting to py3 [13:14] doko, you know python build systems better than me, why is that package even getting a depends on python? [13:14] doko, it uses ${python:Depends}, [13:14] but there is no python file included in the deb [13:15] doko, it has a setup.py that is just used to copy files to the right target as far as I can tell [13:16] seb128: yes, I see that, but it provides an egg-info file too. why? [13:16] bug [13:16] ? [13:16] where is that coming from [13:16] it's not in the source? [13:17] because it's *built* as a python module. see setup.py [13:18] is that easy to change? [13:18] I don't know that build system at all [13:19] doko, I guess I could just revert the packaging changes in http://launchpadlibrarian.net/255953920/adium-theme-ubuntu_0.3.4-0ubuntu1_0.3.4-0ubuntu2.diff.gz [13:19] before that it didn't have that depends [13:20] seb128: sure, sounds fine [13:20] k [13:20] seb128: and the status quo about samba was, that it was installed on demand, afaik [13:21] what is pulling it in now? [13:22] doko, samba itself isn't installed, only -common-bin? [13:22] and libs [13:22] seb128: gnome-control-center -> gvfs-backends libsmbclient [13:22] libsmbclient is linked against libpython2.7 [13:22] ah [13:23] that's not a new issue [13:23] we never resolved that one afaik [13:23] yes, but now it's pulled in unconditinally [13:23] it always was [13:23] no? [13:23] libsmbclient is used by the gvfs samba backend [13:23] we had python2 free desktop images in the past [13:23] are you sure? when? [13:24] I don't think we ever got there [13:32] LocutusOfBorg: -g1 -NDEBUG on the clamav rebuild still not changing a thing [13:32] it is llvm that has "changed" [13:32] I'm lost [13:33] hope that upstream respsonds at some point [13:33] doko, I've uploaded a fix for the theme [13:33] completely disabling llvm support in clamav is the only option that I could toggle on clamav to unbreak it [13:33] I agree with doko on the fact that the change -g -g1 should have no effect, because symbols file are outside the package and stripped away [13:33] but then I wonder if there is more out there that might react to thellvm change [13:34] I totally agree, but I can only report what I see :-/ [13:35] LocutusOfBorg: do you know if the -g1 change was also done in Debian already? [13:35] that might be a great chance to cross check there [13:35] yes, and it is not failing there [13:35] I already tried a no change rebuild [13:36] ld/glibc then maybe? [13:36] the llvm in artful is in sync with the one in debian [13:36] (the one in artful proposed not really) [13:36] ld is in sync, because binutils is at the same version [13:36] glibc isn't [13:36] (this is why I put glibc on the table) [13:37] fortunately libc6 is the simplest package to exchange for a test :-/ [13:37] lol [13:38] so zesty + new llvm + new clamav might be the closest low-hanging-fruit to try [13:38] you can ask infinity to upload new glibc on debian experimental [13:38] and test there [13:39] good idea as well [13:39] cpaelzer, LocutusOfBorg: did you compare the build flags from before and after these changes? [13:40] doko, melding the build flags is painful with 500k logs [13:40] I now ... [13:41] for some reasons current llvm does -g somewhere and -g1 somewhere else [13:41] so, not even in sync with itself [13:41] clamav picks up the CXX Flags from llvm-config - so the one in artful righ tnow still has -g, but rebuilding with the -g1 doesn't change anything [13:41] https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/costamagnagianfranco-ppa/+build/13396394 [13:42] also tried the -NDEBUG, same (no) effect [13:42] this is the llvm that worked [13:42] cpaelzer, confirm please :) [13:42] confirmed [13:43] of the -16 series ubuntu1 = bad, ubuntu2 = good, ubuntu 3 doesn't exist) ubuntu4 = bad [13:43] all -g1 are bad for the case at hand, but they obviously fix the huge debug symbols [13:44] the NDEBUG was the other flag that LocutusOfBorg found, but that didn't resolve it either [13:44] and we all agree that without debug symbols installed the effect of -g[1] should be non [13:44] but this is "shoult (tm)" which never does as it should :-) [13:45] why the hell the NDEBUG is not there [13:45] hold on [13:47] :/ [13:48] seb128: incomplete, you need to use python3:Depends. otoh, you should just remove the egg-info file, shouldn't you? [13:48] cpaelzer, please try the llvm ubuntu5 I have just uploaded [13:48] :( [13:48] or just remove the python:Depends [13:48] doko, I'm not familiar with python packaging, feel free to fix it (or to let it like that, it removed the depends which was not useful anyway) [13:50] later, I have an idea how to remove the interpreter from the images ... [13:53] doko, oh, how? and did you figure out if python was really off the iso on some serie and when? (I'm happy to compare/look what regressed if that's the case) [13:54] LocutusOfBorg: https://launchpad.net/ubuntu/+source/llvm-toolchain-3.9/1:3.9.1-16ubuntu5 ? [13:54] will do so [13:54] did you spot the error? [13:55] I didn't compare debdiffs or anything [13:55] I just read you cahngelog and will try later [13:55] you can see it in the web interface [13:55] just click on the link at the bottom [13:55] :) [13:55] once it is generated [13:55] sure, but I only click there if needed :-) [13:55] it is there already [13:56] oh I see, yeah +=/= [13:56] so O2 and NDEBUG went away [13:56] well worth a try for sure [13:56] you don't have to upload to a-p all the time [13:56] I'm fine with a ppa [13:57] until we have settled on one working version [14:08] seb128: https://launchpad.net/ubuntu/+source/talloc/2.1.9-2ubuntu1 [14:09] doko, let's see how that goes :-) === lewq__ is now known as lewq [14:13] cpaelzer, cross your fingers [14:13] :) [14:34] seb128: done, shouldn't be there anymore on the image [14:34] great === JanC is now known as Guest54020 === JanC_ is now known as JanC [14:54] didrocks, i have a question wrt your continued posts on desktop stuff. [14:54] mostly this is due to my novice like understanding of desktops [14:54] https://didrocks.fr/2017/08/23/ubuntu-gnome-shell-in-artful-day-7/ [14:55] i used rely on 2 indicators heavily [14:55] smoser: you should have the indicators shown there [14:55] * the 'mail' icon, which would go blue when xchat highlighted me [14:55] but it's only appindicator [14:55] not messaging indicator [14:56] * the indicator multiload indicator [14:56] (the mail icon was the messaging indicator) [14:56] so you will only get the first one [14:56] (see, you just went way over my head with the distinction of 'appindicator' and 'messaging indicator' ) [14:56] :) [14:56] heh, I'm a little bit late and need to head out [14:56] we can talk about it tomorrow or andyrock can help you ^ [14:56] I can reply [14:57] ok. thanks. [14:57] ah seb128 as well :) [14:57] thanks seb128 :) [14:57] waiting to see where smoser is going [14:57] yw! [14:57] :) [14:57] so i just ran 'indicator-multiload' and it seems like it only gets a dozen pixels wide or so [14:58] and then i really want *some* indication that i got a xchat highlight. [14:58] are we expecting to get a 'messaging indicator' again ? [14:59] smoser, for the monitor you might want to try https://extensions.gnome.org/extension/120/system-monitor/ or look for similar extensions [14:59] smoser, not at the moment but we are trying to get back the "unread count" on the launcher, see bug #1713712 [14:59] bug 1713712 in gnome-shell-extension-ubuntu-dock (Ubuntu) "[UIFe, FFe] Provide Unity Launcher API" [Medium,New] https://launchpad.net/bugs/1713712 [14:59] smoser, like https://user-images.githubusercontent.com/3677105/30074008-23a5de62-9270-11e7-91e1-19ebc7b7dade.png [15:00] smoser, that should give you hint about IRC pings and unread email [15:00] if you use apps that integrate, like hexchat and tb [15:02] seb128, thanks. [15:03] FWIW, I replaced indicator multiload by the extension seb128 mentioned when I switched to gnome-shell and never went back. [15:16] LocutusOfBorg, hi, is it expected that the installed libllvm3.9 grew by 44MB with -16ubuntu2? [15:17] I mean -16ubuntu4 === ricotz_ is now known as ricotz [15:28] ricotz, yes, I changed the -g flag [15:30] LocutusOfBorg, ah, I see [15:33] ricotz, the latest ubuntu5 should be fine again [15:33] ok [15:34] I missed a "+" so the NDEBUG and the -O2 got stripped [16:34] apw: Hi, James Hunt told me you are a Ubuntu kernel maintainer and I have a question regarding the recent kernel supplied by Canonical in the Ubuntu 16.04.3 LTS image through Azure [16:35] apw: I have noticed that the kernel bumped from 4.4.0-92-generic (yesterday) to 4.11.0-1011-azure (today) [16:36] apw: the problem being that 4.11.0-1011-azure does not have CONFIG_KVM enabled [16:36] apw: is that expected ? [16:41] seb128, sorry. you're prbably gone now, but i just looked at your screenshot. the only thing that i'd suggest is that any unread counts in hte launcher i'm generally not going to see because it auto-hides.l the panel blue envelope i saw all the time. [16:41] sboeuf_: in azure or elsewhere? [16:41] in azure [16:42] apw: ^ [16:42] * ogra_ is curious how the -generic kernel ended up there in the first place [16:43] ogra_: virtual reports as generic [16:43] ah [16:43] ogra_: well that's supposed to be a completely *clean* Ubuntu 16.04 image, meaning that it is supposed to be delivered with the generic kernel, right ? [16:43] but wouldnt -azure have been used initially ? [16:44] ogasawara: |` [16:45] apw: ogra_ : I don't really know if the "generic" name matters here, but basically the latest kernel provided by Canonical for the Ubuntu 16.04 image does not enable KVM anymore [16:46] no, the name doesnt matter for that particular issue ... i was just curious why the original image didnt use -azure in the first place [16:46] apw: ogra_ : and that's an issue since I am using some Azure platforms allowing nested VM [16:51] you should be able to switch by installing linux-hwe by eneric [16:51] bloody autocorrupt [16:52] linux-generic [16:53] sboeuf_: we are talking with Microsoft right now about this [16:54] sboeuf_: and relaying impact of it not being enabled [16:59] ogasawara: oh okay, thank you [17:00] ogasawara: do you know the timeline for a new release (if you/they agree on releasing a new Ubuntu 16.04 with a kernel supporting KVM) ? [17:01] sboeuf_: I suspect we could respin a kernel in a day once we reach agreement [17:01] apw: what do you mean ? installing when logged into the distro ? or you suggest custom image ? [17:01] ogasawara: oh that's pretty fast ;) [17:01] sboeuf_: apw was suggesting you could go back to the previous linux-virtual kernel [17:02] when logged into the instance install linux-virtual and reboot selecting that kernel [17:08] apw: that's a good idea but I need to see how it goes about interactions between my Jenkins CI and the automation of Azure VMs launching [17:10] * apw nods [17:10] apw :force-badtest virtualbox/5.1.26-dfsg-2 [17:11] please update it! 5.1.28-dfsg-1 [17:11] or make it versionless [17:11] thanks :) [17:11] it'd be good to fix dkms ... [17:12] now it is currently blocking libpng and python :) [17:12] dkms can wait I guess [17:12] maybe you can just lower a little bit the kernel version for the module [17:12] calling it 5.1.28~ [17:12] so the virtualbox-dkms one has higher value and overrides it [17:13] interesting thought, I like that [17:14] :) [17:14] or I can increase it [17:14] I appreciate having higher priority wrt your module [17:15] we should reduce will look at it when I have power again [17:27] apw: btw, how am I supposed to reboot to the new installed kernel (modifying grub I guess) [17:45] apw, in case you want to override the virtualbox one you can call it 5.1.28Ubuntu1 [17:45] otherwise a ~Ubuntu1 might be the best versioning [17:45] * LocutusOfBorg didn't test that [17:48] LocutusOfBorg: likely we want the dkms package to replace in case you want the live ones [17:53] why should somebody prefer them? maybe because they might be signed? [18:05] sboeuf_: fyi bug 1718740 [18:05] bug 1718740 in linux-azure (Ubuntu) "linux-azure: KVM nested virtualization is disabled" [Undecided,In progress] https://launchpad.net/bugs/1718740 [18:08] ping Trevinho [18:08] dmj_s76: hey [18:12] When you were making the hidpi changes, did any of the multimonitor (not fractional) work get incorporated in a way that xorg would use or was that purely left in the old way? [18:12] dmj_s76: no, there was a big refactoring of the configuration management which jonas did... [18:16] Trevinho: so this is probably the configuration changes separate from the hidpi work, xorg should be using the same exact scaling mechanisms as before, and the new config settings tools just didn't get any testing for scaling on xorg. [18:19] dmj_s76: I suggest you to ping Jonas in #gnome-shell (he will be available later) [18:19] (jadahl is the nick) [18:20] yeah, waiting on a response :) [18:20] Thanks! [18:49] tjaalton: xorg in artful probably needs https://lists.freedesktop.org/archives/wayland-devel/2017-August/034895.html [18:50] part of the pointer confine fixes the package already has [18:59] jtaylor: I think that patch was dropped from artful already [19:01] tjaalton: dropped as in added and removed again? [19:01] jtaylor, https://launchpad.net/ubuntu/+source/xorg-server/2:1.19.3-1ubuntu6 [19:02] jtaylor, which was the segfault your fix addresses [19:03] seb128: no its the xwayland-pointer-confine.diff [19:03] I have added the patch to ubuntu6 and it fixed my issue [19:03] jtaylor, what issue? did you report it to lp? [19:04] no, it requires prop. software to reproduce, though according the xwayland bug it can be reproduced with qemu too [19:05] ah you commented on the bug :) https://bugs.freedesktop.org/show_bug.cgi?id=102474 [19:05] Freedesktop bug 102474 in XWayland "segfault in zwp_pointer_constraints_v1_lock_pointer" [Normal,Resolved: fixed] [19:05] I think [19:06] well i can drop that one too :) [19:07] jtaylor, well for me (and I reported the upstream bug you mention) the upload withough xwayland-add-grab-protocol-support.diff fixes the issue [19:08] tjaalton, or just include the fix [19:08] sure [19:09] fwiw the program I hit the crash was the steam game xcom2 in windowed mode which is already buggy as all hell [19:09] but with that patch at elast it doesn't crash wayland :) [19:14] slangasek: What's the alternative to dhclient hooks in the networkd world? Do you know? [19:18] Odd_Bloke: so, I think you can introspect /run/systemd/netif/leases after the fact; there is no explicit hook mechanism because networkd itself is designed to be asynchronous and non-blocking, so there would be some scaffolding to build up around querying + triggering [19:18] I haven't checked if anyone is already working on this generically around networkd [19:18] (haven't checked recently) [19:18] right [19:19] Odd_Bloke: and you should spot-check that /run/systemd/netif/leases actually gives you all the info you require [19:19] leases will tell you some of what you want to know, otherwise you'd need to have a unit trigger based on a network interface being up, I guess? [19:19] cyphermox: we need to get the actual value of the ntp server passed by the dhcp server [19:20] and reconfigure the ntp client based on changes [19:20] right, that's why I say from leases (which should have some data from the dhcp server), and trigered from a job [19:20] or timedateddd or whatever it's called. [19:20] right, you said "some of" what we want to know, we need to know that it tells us everything we want to know (except the timing) [19:21] I don't know right now, will be able to tell you in a few minutes [19:21] this desktop is using NM, I'm installing an artful VM with server :) [19:22] I was just going to spin up an instance directly on GCE to check [19:22] yeah, or that [19:24] # grep -i ntp /run/systemd/netif/leases/2 [19:24] NTP=169.254.169.254 [19:24] # [19:24] lgtm [19:25] yup [19:25] 2 would be the ifindex of the interface, if you care [19:25] yeah, that's the scaffolding bit that sucks to write [19:26] indeed :) [19:26] well, possibly we don't need to map interfaces [19:26] we just need to know whether the set of ntp servers has changed as a result of any interface going up or down [19:26] (... or getting a new lease) [19:26] what if more than one iface comes up, with a different NTP server? [19:26] so we don't need to know /which/ interface triggered, we just need to know there was an event, and re-examine /run/systemd/netif/leases/* [19:27] oh, I guess you just re-read everything then [19:27] the sensible default behavior is to take the union of those values, unless we have configuration telling us to ignore ntp from one source but not another [19:27] yes [19:27] (which AFAIK for ifupdown+dhclient we have never had previously) [19:28] Odd_Bloke: sound good so far? :P [19:29] slangasek: that NTP value looks odd though, that's a zeroconf address. not that it means it's wrong, just surprising to see. [19:30] cyphermox: That's the GCE metadata server IP address. [19:30] cyphermox: indeed, and therefore I went to double-check if it's really there; and I discovered that a) yes the address pings, and b) it's also the DNS server and functions as one, and c) this GCE daily image has broken /etc/resolv.conf [19:30]