[01:08] <xnox> nacc, retriggered all current regressions with all-proposed=1 which have ruby in the name, this should do it to clear up obvious things that are fixed.
[02:54] <nacc> xnox: thanks!
[02:54] <nacc> xnox: i'll pick it up in the morning
[06:04] <doko> nacc, xnox: sorry. there were some unfullfillable b-d's needing >= 2.5.0
[07:13] <doko> tjaalton: xorg-lts-transitional has an invalid dependency. see excuses
[07:15] <tjaalton> doko: ok
[07:16] <tjaalton> ah
=== _cpaelzer is now known as cpaelzer
[08:13] <cpaelzer> bdrung: hi, any news to bug 1753938 and the related upstreaming?
[08:13] <ubottu> bug 1753938 in qemu (Ubuntu) "slirp: domainname and classic stateless for DHCP" [Undecided,New] https://launchpad.net/bugs/1753938
[08:14] <cpaelzer> hmm I should have read the bug updates before asking :-)
[08:14]  * cpaelzer ponders why this missed the important flag in his inbox
[08:15] <cpaelzer> ok, so for now V3 is on its way
[08:15] <cpaelzer> keep me in the loop bdrung
[08:16] <cpaelzer> I made sure also the upstream thread shows up at the top of my inbox
[08:16] <cpaelzer> lets see what the V3 review brings
[08:39] <cpaelzer> I'm lokking for hint on side effects of adding a debian/<pkg>.install file
[08:39] <cpaelzer> my d/rules alwas had an override_dh_install that did dh_install and then some additional "install -m" calls
[08:40] <cpaelzer> it did not have a debian/<pkg>.install
[08:40] <cpaelzer> I added the latter
[08:40] <cpaelzer> and since then the "install -m" seem to fail on target dirs not being available
[08:40] <cpaelzer> I wondere if adding a debian/<pkg>.install did somehow stop it from creating those directories
[08:41] <cpaelzer> (no .dirs file btw)
[08:43] <cpaelzer> it is reproducible, I can take the debian/<pkg>.install out and it works again
[08:44] <cpaelzer> I can add a .dirs file to fix it, but I'd prefer to understand how the addition of the .install file affetcs the directory creation
[08:48] <cpaelzer> for those interested to help, reproducible with: "pull-lp-source chrony; cd chrony-3.2/; echo "debian/README.Debian /usr" > debian/chrony.install; dpkg-buildpackage -S -nc -d; cd ..; DEB_BUILD_OPTIONS=3 sbuild -Adbionic-LP-amd64 chrony_3.2-4ubuntu1.dsc"
[08:48] <cpaelzer> or whatever your usual build setup is for the last step
[08:52] <cpaelzer> the path I'm missing in the bad case is not mentioned at all in the good case, so it is hard to spot what creates it in the good case
[08:53] <cpaelzer> ah found it
[08:54] <cpaelzer> it is a single binary package package, so it has a install file and the <pkg>.install obviously overrules that
=== bashfulrobot_ is now known as bashfulrobot
=== slashd- is now known as slashd
=== broder_ is now known as broder
[11:51] <juliank> So, I see that we have support for additional module signing keys in the kernel, but do we have support for signing dkms stuff automatically?
=== tyhicks` is now known as tyhicks
=== tyhicks is now known as Guest65850
=== alan_g_ is now known as alan_g
=== thegodfather is now known as fabbione
[12:41] <sasluc_> I assume that the reason for the package Ganeti not being part of the bionic/18.04 release is, that not all archs on http://autopkgtest.ubuntu.com/packages/ganeti pass the test?
[12:42] <doko> coreycb, rbasak: is it correct that tomcat8 is getting demoted?
[12:43] <rbasak> dpb1: ^
=== NishanthMenon__ is now known as NishanthMenon
[13:16] <smoser> xnox: could you take a look at bug 1751797 ?
[13:16] <ubottu> bug 1751797 in systemd (Ubuntu) "dns resolution only works for domains in 'search'." [Critical,Confirmed] https://launchpad.net/bugs/1751797
[13:16] <smoser> It sure seems to me that this bug affects close to 100% of desktop users. I'm really surprised there isnt more screaming.
[13:17] <xnox> smoser, i am surprised too.
[13:18] <xnox> smoser, what's your $ systemd-resolve --status <broken device> ?
[13:18] <xnox> do you have ~ in the search domain field?
[13:18] <xnox> smoser, is your router "normal" ISP provided thing, or some crazy custom firmware WRT?
[13:19] <xnox> smoser, and i guess i should move my desktop to use NM and check if i can reproduce this.
[13:21] <xnox> doko, your export DH_RUBY_IGNORE_TESTS=ruby2.3 ruby2.5 in debian/rules do not appear to affect the autopkgtest which are autodetected and autorun by gem2deb autodep8
=== infinity1 is now known as infinity
[13:22] <xnox> doko, do you know how to make the packages ignore autopkgtest results too, not just build-time failures?
[13:23] <xnox> hm, looks like
[13:23] <xnox> test -f debian/ruby-tests.rake -o -f debian/ruby-tests.rb -o -f debian/ruby-test-files.yaml
[13:23] <xnox> is what generates it
[13:26] <smoser> xnox: posted to bug.
[13:27] <xnox> smoser, THANKS!
[13:40] <xnox> smoser, mine is similar http://paste.ubuntu.com/p/xS2vP87TGb/ and I do not have same problem =/ i use different domain and 192. addresses instead of 10. ; and I do not have extra route to 169.
[13:40] <doko> xnox: sorry, no. ask #debian-ruby?
=== Guest65850 is now known as tyhicks
=== tyhicks is now known as Guest1006
[13:53] <xnox> smoser, can i please get $ nmcli c show 72c7fac3-c017-4b76-9954-b4fb08262376
[13:54] <xnox> 181    /* If this link is never the default (e.g. only used for resources on this
[13:54] <xnox> 182     * network) add a routing domain. */
[13:54] <xnox> 183    route_only =   addr_family == AF_INET
[13:54] <xnox> 184                 ? !nm_ip4_config_best_default_route_get (config)
[13:54] <xnox> 185                 : !nm_ip6_config_best_default_route_get (config);
[13:54] <xnox> hmmmm.....
[13:54] <xnox> i smell that your routes might be causing something of above to fail.
[13:56] <xnox> smoser, it smells like NetworkManager knows better and claims it is not the best route....
[13:57] <doko> tumbleweed: do you have an idea about https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/amd64/s/sphinxcontrib-doxylink/20180314_234233_02148@/log.gz ?
[13:59] <smoser> xnox: added.
[14:01] <xnox> smoser, can you explain your routes to me? e.g. what is this:
[14:01] <xnox> IP4.ROUTE[3]: dst = 169.254.0.0/16, nh = 0.0.0.0, mt = 1000
[14:01] <juliank> hmm, /dev/urandom on my T480s does 160 MB/s, my X230 had 260. hmm.
[14:02] <smoser> xnox: "crazy" openwrt
[14:03] <smoser> xnox: i'm not sure where that 169 route came from
[14:03] <smoser> 169.254 is ipv4 link local
[14:05] <xnox> smoser, reading network-manager code, instead of asserting that one ticked "only use this interface for resources on this network" it goes into guessing mode "how insane does this route look like"
[14:06] <smoser> xnox: if you're suggesting i clicked some b utton for "only use this interface for resources on this network", then I' have to say that that *could* have happened. i'm quite incompetent with user interfaces.
[14:06] <smoser> although the fact that i have a route to the interwebs *on* that network device would seem contradictory
[14:06] <smoser> ie, i'm using it to type this message to you.
[14:07] <smoser> so if network manager tried to only give me routes to local resources on that device then it failed.
[14:08] <smoser> and looking at network config, i do *not* have a check in 'Use this connection only for resources on its network'
[14:12] <xnox> smoser, yeah, and network-manager->dns->resolved-plugin doesn't seem to check for that checkbox, and instead tries to make an "educated" guess if this is a best route dns server, or not.
=== tych0- is now known as tych0
[15:09] <nacc> doko: np
[15:34] <nacc> mdeslaur: fyi, i think php5 might also be affected by (some of) those CVEs ?
[15:37] <mdeslaur> nacc: yes, I'm doing updates for php5 too
[15:37] <nacc> mdeslaur: thanks
[16:34] <tsimonq2> stgraber: Hey, mind looking at my queuebot MP I proposed a few weeks back?
[16:35] <tsimonq2> stgraber: Specifically: https://code.launchpad.net/~tsimonq2/queuebot/add-ubuntu-qt/+merge/33675
[16:35] <tsimonq2> Er...
[16:35] <tsimonq2> https://code.launchpad.net/~tsimonq2/queuebot/add-ubuntu-qt/+merge/336753
[16:36] <stgraber> lets see if I still know how to use bzr
[16:37] <tsimonq2> stgraber: Or you could just use https://github.com/mnauw/git-remote-bz
[16:37] <tsimonq2> ...
[16:37] <tsimonq2> https://github.com/mnauw/git-remote-bzr
[16:37] <tsimonq2> I never use Bazaar directly these days. ;)
[16:51] <dpb1> doko: yes, that was the intent
[17:06] <doko> dpb1: the source as well?
[17:16] <dpb1> doko: I feel like there is another question or concern behind that question? :)
[17:18] <bdmurray> bigon: Could you add SRU information to bug 1683761?
[17:18] <ubottu> bug 1683761 in libnative-platform-java (Ubuntu Artful) "undefined symbol: tgetent" [High,In progress] https://launchpad.net/bugs/1683761
[17:19] <bdmurray> coreycb: does bug 1755027 need to be private? If so I'll reject the SRU upload.
[17:19] <ubottu> Error: Launchpad bug 1755027 could not be found
[17:20] <coreycb> bdmurray: it probably should be until all the updates are queued up
[17:20] <coreycb> bdmurray: i'll add you to it
[17:20] <bdmurray> coreycb: Its not about me but SRU bugs need to be public.
[17:21] <coreycb> bdmurray: i think we can make it public when the updates are queued up. it's a security vulnerability.
[17:21] <coreycb> bdmurray: does that work?
[17:22] <bdmurray> coreycb: Sure are all these -dashboard packages in artful related to it?
[17:23] <coreycb> bdmurray: yes but the vulnerability is in ocata and before. we might as well make it public now.
[17:24] <coreycb> i should have updates by eod
[17:24] <bdmurray> coreycb: okay, feel free to ping me when you want them reviewed.
[17:24] <coreycb> bdmurray: ok thanks
[17:38] <bigon> bdmurray: I don't think I still have the package here
[17:39] <bdmurray> bigon: This is about update the bug report with a test case, regression potential etc.
=== kees_ is now known as kees
[17:44] <doko> dpb1: looking at http://people.canonical.com/~ubuntu-archive/component-mismatches.txt, a few binary packages are kept in main. I assume you should talk to the desktop team (libreoffice), if you want to demote tomcat8 altogether
[17:54] <dpb1> doko: ah, I see, because of the servlet library
[17:54] <dpb1> doko: ok, just the binary packages then
[17:54] <tumbleweed> doko: I did notice some ply related test failures before, because they weren't using dh_python-ply to have tight enough dependencies. Been meaning to look at those
[17:54] <dpb1> tomcat8 and tomcat8-admin
[17:54] <tumbleweed> but this one is not that
[18:02] <doko> dpb1: so still demote these binary package, even if we have to keep the source in main?
[20:47] <coreycb> bdmurray: everything's uploaded into the corresponding unapproved queues for 1755027
[20:48] <coreycb> bdmurray: there's a version of horizon in xenial-proposed atm that failed testing and needs to be rejected - 1725421
[20:48] <bdmurray> coreycb: if its already in -proposed there isn't really a way to "reject" it. just upload a better one.
[20:49] <coreycb> bdmurray: ok then the new version should be able to replace it
[20:51] <coreycb> bdmurray: for some reason i can't target some releases in launchpad, for example trove-dashboard doesn't have xenial or artful series available
[20:53] <bdmurray> coreycb: wow, that's weird.
[21:08] <bdmurray> coreycb: The API let me add one...
[21:09] <coreycb> bdmurray: that's promising
[21:09] <bdmurray> coreycb: should this have been included in the sahara upload? d/p/fix-neutron-related-openstack_dashboard-imports.patch:
[21:11] <coreycb> bdmurray: yes. unfortunately 7.0.0 is the correct version for artful but it was released too late so we have 6.0.0 in artful.
[21:12] <bdmurray> coreycb: I ask as that patch has no bug reference or anything.
[21:13] <coreycb> bdmurray: i understand. i could add one if you want. it hit a build failure running tests and that fixed it.
[21:14] <bdmurray> coreycb: I think it'd be best.
[21:15] <coreycb> bdmurray: ok. i need to step away for a little  but will do that and let you know when it's done.
[21:59] <coreycb> bdmurray: uploaded a new sahara-dashboard to artful with bug #
[22:03] <bdmurray> coreycb: Hate to be a pain but it didn't need a new version number since it hasn't been released anywhere yet.
[22:03] <bdmurray> coreycb: You could just reuse ubuntu1.1
[22:09] <coreycb> bdmurray: ok need a new upload? its just easier that way in our source repo rather than force pushing tags.
=== blahdeblah_ is now known as blahdeblah
[22:12] <bdmurray> coreycb: If its extra work for you its fine then
[22:17] <coreycb> bdmurray: ok lets go with 1.2. thanks.