[00:25] <vorlon> mwhudson: autopkgtest retries needed with all-proposed=1?
[00:26] <vorlon> ah, no, the package is dep-wait
[01:18] <mwhudson> vorlon: yeah it's build-side
[01:19] <mwhudson> vorlon: i think someone must have uploaded things in a very careful order to debian while we weren't importing, or something like that
[07:18] <seb128> cyphermox, hey, did you get anywhere with ffmpeg/armhf?
[07:32] <tjaalton> what's wrong with my sbuilder.. it refuses to install libudev-dev/libsystemd-dev
[07:33] <tjaalton> eoan
[07:33] <tjaalton> proposed enabled or not doesn't matter
[07:36] <seb128> tjaalton, what's the error?
[07:44] <tjaalton> Depends: libsystemd-dev but it is not going to be installed
[07:45] <tjaalton> is libudev-dev gone?
[07:46] <tjaalton>  libudev-dev : Depends: libudev1 (= 240-6ubuntu9) but 243~rc1-0ubuntu2 is to be installed
[07:46] <tjaalton> ah
[07:47] <tjaalton> proposed had that version for a while it seems
[07:47] <tjaalton> but no longer
[07:47] <seb128> 243~rc1 had been deleted from proposed because not ready
[07:47] <seb128> yeah
[07:47] <seb128> has*
[07:52] <tjaalton> had to downgrade libudev1, libsystemd0 that's all
[08:42] <lennyb> Hi, what is a procedure to import pkg to Ubuntu bionic. This pkg exists in debian (https://packages.debian.org/search?searchon=sourcenames&keywords=networking-mlnx )
[10:19] <rbasak> lennyb: that depends. https://wiki.ubuntu.com/StableReleaseUpdates or https://wiki.ubuntu.com/UbuntuBackports. I suggest you start with a PPA though.
[10:20] <rbasak> lennyb: looks like it was removed from Bionic because of an incompatiblity with neutron
[10:20] <rbasak> https://launchpad.net/ubuntu/+source/networking-mlnx/+publishinghistory
[11:59] <Locutusofborg> cpaelzer, hello, nspr sync?
[12:02] <cpaelzer> I haven't looked at nspr for a while Locutusofborg
[12:02] <Locutusofborg> I'm trying a sync on my ppa... lets see
[12:03] <Locutusofborg> I'm not sure if the fix was about a build failure or something else... debian might have fixed it differently
[12:03] <cpaelzer> yeah
[12:03] <cpaelzer> I'm not 100% sure that "Set LD_LIBRARY_PATH when running tests. Closes: #925790" covers what we had to do
[12:04] <cpaelzer> if it builds fine in your ppa then you should be good to go
[12:04] <cpaelzer> at least it is the same debian bug that our delta was created for
[12:05] <cpaelzer> and LD_LIBRARY_PATH should be cleaner than relying on --disable-new-dtags implicitly changing the rpaths
[12:05]  * cpaelzer would never have thought LD_LIBRARY_PATH could be the cleaner solution than anything else
[12:10] <Locutusofborg> LOL
[12:10] <Locutusofborg> that one was good!
[12:15] <Locutusofborg> and it works LOL
[12:25] <lennyb> rbasak, thanks. We have some bug fixes that we would like to backport into Debian. how can I know on which debian version this failed pkg was based on? Are there any logs
[12:27] <rbasak> lennyb: examine debian/changelog, and you might find my writeup at http://www.justgohome.co.uk/blog/2015/01/ubuntu-package-versions.html helpful
=== ricab is now known as ricab|lunch
[14:10] <GunnarHj> Hi Locutusofborg, do you possibly have time to sponsor bug #1731459? Only upstream patch. Pre-verified via PPA.
[14:10] <ubottu> bug 1731459 in sane-backends (Ubuntu Disco) "genesys_gl847 scanners produce a black band in scanned images on Ubuntu 17.10+, 18.04 LTS and 18.10 Cosmic cuttlefish" [Medium,In progress] https://launchpad.net/bugs/1731459
=== ricab|lunch is now known as ricab
=== cpaelzer__ is now known as cpaelzer
[14:58] <Locutusofborg> GunnarHj, ack
[15:24] <GunnarHj> Locutusofborg: Thanks a lot!
[17:02] <blackboxsw> vorlon: thanks for the suggestion on cloud-init use of debconfig-loadtemplate for ubuntu-drivers work. The only wrinkle here is that cloud-init doesn't currently have a dependency on debconf-utils package.  I'd like to avoid adding that new strict package dependency if we can to avoid bloat (57K) on most cloud-init deployments which don't try to configure ubuntu-drivers.     one option is for cloud-init to
[17:02] <blackboxsw> install debconf-utils if we are already processing ubuntu-drivers in cloud-config.       Are there any other alternatives you would suggest?
[17:07] <vorlon> blackboxsw: oh, sorry, I overlooked that the command was in the non-default debconf-utils.  You can also use the X_LOADTEMPLATE debconf protocol extension to load it without having to install other packages
[17:08] <blackboxsw> ahh /me rtfms now thanks
[17:08] <vorlon> so then you just have to talk the debconf protocol, no big deal :P
[17:08] <blackboxsw> SMOP :)
[17:15] <blackboxsw> vorlon: looks like we'll have db_x_loadtemplatefile in /usr/share/debconf/confmodule so that should be a big help as it's delivered by debconf proper
[17:16] <blackboxsw> ok we can work with this
[17:16] <blackboxsw> thanks again
[17:16] <vorlon> blackboxsw: yeah, you're just then subjected to implementing in shell in order to use /usr/share/debconf/confmodule but otherwise ok :)
[17:22] <blackboxsw> vorlon: or maybe I could push a patch back to python3-debconf to support x_loadtemplatefile as it seems like that would be a trivial upstream commit as it seems the only command not supported by the python library
[17:22] <blackboxsw> maybe I'll try both routes, and cloud-init can adopt the python3-debconf library in the future
[17:23] <vorlon> ah, given that python3-debconf is already in the server task (which I hadn't realized), that seems like the better approach IMHO
[17:23] <vorlon> though we'd then have to SRU it back
[17:24] <blackboxsw> yeah and we'd need to MIR in xenial : /
[17:24] <blackboxsw> as it looks like it's only back to bionic
[17:24]  * blackboxsw checks state of /usr/share/debconf/confmodule in xenial too
[17:25] <blackboxsw> db_x_loadtemplatefile exists in xenial  /usr/share/debconf/confmodule
[17:26] <blackboxsw> hrm, ok so need to weigh using subp shell to source db_x_loadtemplatefile /usr/share/debconf/confmodule  vesus just installing debconf-utils if ubuntu-drivers cloud-config is specified
[17:26] <blackboxsw> vs. rolling our own simple wire write of debconf cmds for X_LOADTEMPLATEFILE support
[19:02] <vorlon> blackboxsw: there's no expectation that we'll have these drivers on xenial fwiw
[22:30] <Odd_Bloke> Is there any way to change the make target that dh_auto_test will run, or should I just override it and run `make not_quite_test_but_so_close` myself?
[22:31] <Odd_Bloke> (`make test` runs both Py2 and Py3 tests, I'm looking at dropping the python2 binary packages produced, so don't want to install the Python 2 build deps to make the tests run.)
[22:54] <rbasak> https://sources.debian.org/src/debhelper/12.5.3/lib/Debian/Debhelper/Buildsystem/makefile.pm/#L167
[22:54] <rbasak> Doesn't look like it - not for the "make" buildsystem implementation
[22:56] <rbasak> Assuming you're using the make buildsystem and not one of the Python ones
[22:56] <rbasak> So overriding it seems like the appropriate mechanism to use
[23:23] <mwhudson> Locutusofborg: um how many rebuilds is this golang-google stuff going to take? :)
[23:23] <mwhudson> Locutusofborg: fwiw it seems the grpc failure is real