[00:31] <mattfly> hello
[00:31] <mattfly> https://bugs.launchpad.net/ubuntu/+source/uswsusp/+bug/1770491
[00:31] <mattfly> installing nvidia drivers = no more hibernation to me (aka s2disk hangs while trying to hibernate)
[00:31] <mattfly> does it have something to do with meltdown patches?
[00:34] <mattfly> s/does it/can it/
[09:52] <tarzeau> i'm not sure, if i'm right here: we run ubuntu for linux workstations, and we manage them centrally, users has no installed: network-manager, nor gnome-software store, nor aptdeamon gui update manager
[09:53] <tarzeau> yet we want them be able to set background image, i.e have gnome-control-center installed (which has depends on the three things mentioned above)
[09:53] <tarzeau> what worked for us is: rebuild gnome-control-center with the depends ripped away. i'm not sure if that'd be useful for others too
[09:54] <tarzeau> in numbers: 33 bionic, 142 xenial machines (and another 10 trusty)
[15:36] <jpleau> tarzeau: nice to know it works, I was wondering doing that myself for my own machine (disabling dependencies I will never use like network-manager and friends so I can uninstall them)
[15:56] <ScottE> I came across an interesting gcc regression that can result in corrupt pointers when code is compiled with -O2. Reproducable on xenial and bionic (and likely other versions). Simple testcase attached here: https://bugs.launchpad.net/ubuntu/+source/gcc-7/+bug/1770676
[16:01] <rbasak> ScottE: interesting. Though that could be an issue in libc rather than gcc.
[16:03] <rbasak> (depending on how it's defined)
[16:03] <ScottE> It could be, except that it only occurs when compiling the testcase with -O2 - libc would be the same in either case? Hard to say though, sometimes these sort of issues happen in a different place than where the symptom is.
[16:03] <rbasak> libc could be depending on undefined behaviour.
[16:04] <rbasak> I'm not familiar enough with the many levels of indirection libc function definitions go through to be able to tell quickly.
[16:04] <ScottE> It could be, although on xenial, if I reproduce the original issue I was chasing (with cronolog), it doesn't surface with the cronolog binary in xenial until I recompile cronolog. Still not definitive, though...
[16:05] <ScottE> I'll add the cronolog testcase to that bug, too - it's easy to reproduce there too
[18:41] <jbicha> doko: could you merge ilmbase? it's needed by openexr
[18:41] <jbicha> doko: maybe a compromise with Debian would be to only use a symbols file for amd64 where it's more easily maintained?
[18:59] <doko> jbicha: ilmbase belongs to the desktop team. and no, dropping the symbols file would invalidate the constraints for being in main
[19:03] <jbicha> doko: could Foundations please take ilmbase? it's only in main because of imagemagick (via openexr) which is Foundations
[19:04] <jbicha> I didn't say drop the symbols file, I said only use it on amd64. Wouldn't that be sufficient to tell if there was an API break?
[19:04] <jbicha> I imagine there's several C++ libraries in main that don't use symbols files
[19:13] <jbicha> symbols files aren't mentioned as a strict requirement at https://wiki.ubuntu.com/UbuntuMainInclusionRequirements
[19:14] <jbicha> so how about I just sync ilmbase now to fix openexr and you can deal with symbols files later if it's important enough to you?
[20:07] <doko> jbicha: absolutely no. please properly merge
[20:09] <doko> jbicha: "I imagine there's several C++ libraries in main": sorry, I don't think your imaginations are relevant for main inclusion. and I hate your exaggerations and unprecise statements, like "hundreds of runtime failures for missing dependencies".  this is a technical channel, not an advocating channel
[20:59] <jbicha> it sounds like you're referring to Debian bug 893755 now. I think it was a correct statement at the time since your change broke glib for instance