[11:32] <piet> chrisccoulson: could you perhaps take a look at this security issue concerning Firejail?
[11:32] <piet> https://bugs.launchpad.net/ubuntu/xenial/+source/firejail/+bug/1655136
[11:32] <piet> A fix has been provided by Reiner Herrmann, but it needs to be uploaded by a member of the Ubuntu Security Team.
[11:32] <piet> Would you perhaps want to do that?
[12:01] <chrisccoulson> piet, sure, will take a look
[12:51] <piet> chrisccoulson: thanks!
[16:07] <Dmitrii-Sh> Hi guys. Could anybody from the SRU team take a look at this one? https://bugs.launchpad.net/ubuntu/+source/barbican/+bug/1570356
[16:11] <sil2100> Dmitrii-Sh: will try taking a look at it
[16:11] <Dmitrii-Sh> sil2100: thx
[16:12] <sil2100> Laney: hey! Could you take a look at http://people.canonical.com/~ubuntu-archive/proposed-migration/yakkety/update_excuses.html#dbus ? There are libnih tests there that are infinitely "Test in progress" (even though I re-run them explicitly with our tools)
[16:13] <Laney> sil2100: It's blacklisted https://git.launchpad.net/~ubuntu-release/+git/autopkgtest-cloud/tree/worker-config-production/worker.conf
[16:14] <Laney> also see https://bugs.launchpad.net/auto-package-testing/+bug/1579090
[16:16] <sil2100> Laney: oh, ok, so I should probably just ignore those being in progress, thanks!
[17:06] <mdeslaur> infinity: meeting?
[17:28] <xnox> barry, whos responsibility is it to fix ADT tests regressions for the SRU uploads?
[17:29] <xnox> (as pointed out on pending-sru report)
[17:30] <tjaalton> the new systemd-resolve thingy isn't too happy to work with my home dns, although it shows the server as listed but can't find any machines
[17:31] <tjaalton> Host eldon not found: 2(SERVFAIL)
[17:37] <seb128> tjaalton, check the bugs reported on https://bugs.launchpad.net/ubuntu/+source/systemd/+bugs?field.tag=resolved
[17:38] <tjaalton> seb128: thanks, found it
[17:38] <seb128> which one is it?
[17:42] <tjaalton> not sure actually
[17:47] <tjaalton> yeah it's #1647031
[17:47] <tjaalton> updating n-m fixed it
[17:47] <seb128> good
[17:48] <tjaalton> it's been in proposed for ten days though?
[17:48] <tjaalton> almost
[17:49] <seb128> the systemd autopkg is having issues so the update is not considered
[17:49] <seb128> barry, ^ is that something you are looking at sorting out?
[17:49] <seb128> "upstream             FAIL timed out"
[17:50] <tjaalton> mesa update needed several autopkg reruns, some timeouts and some weird errors
[17:56] <barry> seb128: yeah, i know about that one.  i still haven't figured it out :(
[17:57] <seb128> barry, hum, k, do we have anyone looking at systemd since p_itti left? since that seems the issue there...
[18:00] <barry> seb128: yeah, i don't think so :(  i've tried to look, and will be getting back to it when i can
[18:02] <seb128> can slangasek or xnox help you maybe?
[18:03] <barry> seb128: possibly.  i'll raise this with our team
[18:03] <barry> (systemd responsibilities in general)
[18:05] <xnox> barry, i think it maybe me....
[18:06] <xnox> howerver not sure how the upstream tests are run. i'm sure it uses pitti's github credentials and tokens
[18:06] <xnox> also i'm packing for volleyball and going out in a moment
[18:07] <Laney> No, don't get the distro tests confused with the PR tests
[18:07] <Laney> Not that either of them use anyone's personal credentials
[18:07] <xnox> horum, ok
[18:09] <Laney> https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/tests/upstream
[18:09] <Laney> night!
[19:05] <pitti> xnox, seb128: hm, the upstream tests are supposed to work, they run in upstream CI all the time (but on xenial, so different kernel etc.); nothing to do with my github creds, they just call the upstream QEMU tests, you can run them in local autopkgtest like any other
[19:57] <pitti> xnox: at first sight it seems to coincide with linux 4.9?
[19:58] <pitti> and FWIW, I don't think it's a good idea to just hint over that.. (which apparently happened)
[19:59] <pitti> ah sorry, no, I looked at linux-meat
[19:59] <pitti> meta
[19:59] <barry> pitti, xnox yeah, and the problem i've had is that when i run the upstream tests locally, it crashes qemu (in kvm.c iirc)
[20:01]  * barry gives it a try again now
[20:01] <pitti> barry: the inner qemu? or even the outer one?
[20:02] <barry> pitti: the inner one
[20:02] <pitti> nested qemu had been a bit flaky in the past, but it has worked rather nicely in the recent years
[20:02] <barry> pitti: let me run it again and see if 1) it still crashes; 2) i can get you a log
[20:05] <pitti> barry: http://autopkgtest.ubuntu.com/packages/s/systemd/zesty/amd64 coincide with linux 4.8 vs. 4.9 fairly consistently
[20:05] <pitti> except for that dnsmasq failure, but that was not a timeout, "just" a flaky test
[20:05] <pitti> so confirming on that seems like a good direction
[20:06] <barry> pitti: you mean one kernel fails consistently and the other passes?
[20:06] <barry> (i'm still testing against systemd 232-8)
[20:06] <sarnold> mmm linux-meat
[20:06] <barry> not even counting the network-manager change, just systemd in zesty
[20:11] <pitti> barry: looks like it, at least
[20:12] <pitti> sarnold: we clearly need a linux-veggie flavor!
[20:12] <sarnold> pitti: heheheh
[21:09] <barry> pitti: http://paste.ubuntu.com/23818532/
[22:02] <sushi__> hello, I have a weird behaviour with fancontrol and my usb audio card
[22:03] <sushi__> I've run pwmconfig to create the config file /etc/fancontrol
[22:04] <sushi__> In this file, I've the line INTERVAL=10 wich means that the temperature sensors which are used as input for the fan speed monitoring are read every 10 sec
[22:04] <sushi__> It's working fine
[22:04] <sushi__> However, every 10 sec, I can hear a buzz in the sound when the usb sound card is playing some sound
[22:05] <sushi__> I've tested with the internal audio chipset and no problem in this case
[22:05] <sushi__> So I guess there is some conflicts with temperature sensors reading and usb
[22:05] <sushi__> any ideas ?
[22:06] <sladen> sushi__: the method of reading the I2C bus with the sensors on is probably having to turn off interrupts
[22:07] <sladen> sushi__: from memory, there are different ways that the I2C can be read.  Some of less reliable, but don't involved disabling interupts
[22:08] <sushi__> sladen: thank you. Thus, how to change the ways of reading I2C bus or where to find this info ?
[22:08] <sarnold> sushi__: hehe, you know that bit about "shall not generate harmful interference and shall accept all interference in the environment" bit stuck on every piece of electronics? this is why :)
[22:10] <sushi__> sarnold: so you think It's not a bug but some electric interferences ?
[22:10] <sarnold> sushi__: hard to say without hearing the noise myself
[22:11] <sarnold> sushi__: but I've heard very similar noises from e.g. ethernet nics or hard drive controllers via audio cards
[22:11] <sushi__> sarnold: let me reduce the interval from 10 sec to 1 sec and record the audio output..
[22:11] <sarnold> sushi__: folks used to generate radio signals using their CPUs and put a radio near the computer, to see it..
[22:16] <cjwatson> You could probably still test that kind of thing by putting a handheld radio near it
[22:16] <cjwatson> (Though it's a bit harder to tell when the interference is from something that itself makes noise)
[22:20] <sushi__> sarnold: http://www.sekisushai.net/usb_buzz.wav
[22:21] <sarnold> sushi__: wow, that's -really- annoying.
[22:21] <sushi__> sladen: could you give me some more info on how to configure I2C bus reading way ?
[22:22] <sarnold> sushi__: also, I think I was wrong :) ignore everything I wrote above :D
[22:22] <sushi__> sarnold: yes, very annoying ... it's with my usb-audio card only and if fancontrol module is off then no problem at all
[22:23] <sushi__> sarnold: no probs, thank you anyway
[22:23] <sarnold> sushi__: maybe you can workaround the issue by setting realtime scheduling priorities for your music player, maybe pulseaudio too if you use it
[22:24] <sushi__> sarnold: the issue is not there, I've tested using the card with alsa, or with jack server with real time on an off and the buzz it's still at the periodicity of the I2C bus reading
[22:25] <sarnold> sushi__: is it possible to try moving the card to a diffreent usb port?
[22:25] <sushi__> sarnold: same issue with all the usb ports, I've tested that too
[22:26] <dasjoe> What about adding an USB hub?
[22:28] <sushi__> dasjoe: I don't have one... :( but I guess it would be the same
[22:29] <sladen> sushi__: all I'm going to be able to do is Google for things like "fancontrol" "lm-sensors" "i2c" "interupts"
[22:29] <sladen> sushi__: these days I think the kernel has the i2c stuff built, in and readable under /sys
[22:31] <sladen> sushi__: the buses are probably visible with 'grep -r . /sys/bus/i2c/devices/*/name'
[22:31] <sarnold> does reading those give the same stutters?
[22:36] <sushi__> sladen: with the usb card plug or unplugged it's the same output : http://pastebin.com/87EXnQLe
[22:40] <sladen> sushi__: what about   grep . /sys/class/hwmon/hwmon*/device/*temp*
[22:41]  * sladen skimming https://wiki.archlinux.org/index.php/fan_speed_control
[22:46] <sushi__> sladen: nothing for  grep . /sys/class/hwmon/hwmon*/device/*temp*
[22:47] <sladen> sushi__: fancontrol is non-standard.  How did you configure it?
[22:47] <sladen> sushi__: what values are in the 'fancontrol' configuration file  (these tell 'fancontrol' where to read data from)
[22:48] <sushi__> sladen: http://pastebin.com/55ewukdj
[22:50] <sushi__> sladen: i've install the package fancontrol, then run pwmconfig to generate /etc/fancontrol
[22:56] <sladen> sushi__: prepend '/sys/' to these paths in the config file
[22:56] <sladen> sushi__: eg. find /sys/devices/platform/coretemp.0/.../...
[23:11] <sushi__> sladen: prepending /sys/ makes fancontrol not work anymore
[23:12] <sushi__> sladen: i guess the /sys/ prefix is already known somewhere..
[23:29] <sushi__> sladen: I will open a bug in launchpad, thank you for your help