[01:40] <dja> hi all - does anyone know where the official upstream of sbsigntool lives now?
[01:41] <dja> is it jejb's kernel.org repo, or does the official one live at Canonical still?
[01:43] <sarnold> heh, the url in debian/copyright looks dead .. this looks like the new name for the old thing https://kernel.ubuntu.com/git/jk/sbsigntool/ -- looks like it's six years idle
[01:44] <dja> yes, it's jk's old tool but it's still useful (the secure boot stuff hasn't changed much, and it was current when cyphermox wrote https://blog.ubuntu.com/2017/08/11/how-to-sign-things-for-secure-boot in 2017)
[01:50] <cyphermox> dja: https://git.kernel.org/pub/scm/linux/kernel/git/jejb/sbsigntools.git/
[01:51] <cyphermox> (it does need an update, more specifically a merge from Debian; I will take care of that)
[02:02] <dja> cyphermox: cool. There's an issue in at least cosmic where sbverify ignores -v despite having code to process it, it needs the getopt line to include lowercase v as well as uppercase V
[02:02] <dja> I can send a patch to james for master
[02:04] <dja> ah looks like master already has it
[02:17] <dja> cyphermox: master got the fix I wanted in 2014 so hopefully a sync with debian should catch it
[02:17] <dja> thanks :)
[06:41] <LocutusOfBorg> mwhudson, maybe we can make 1.11 migrate and then transition again?
[06:53] <LocutusOfBorg> didrocks, ubuntu-report is having a sad day with new default golang... I don't think I understood the testsuite failure....
[07:16] <didrocks> LocutusOfBorg: ah, interesting, I guess autopkgtests rdepends?
[07:17] <didrocks> LocutusOfBorg: funny, because with the upstream google compiler, I'm using 1.11 (and not 1.12) for months…
[07:18] <didrocks> I bet it's a question of 1.11 with modules and it tries to fetch the upstream repo instead of the vendor/ directory
[07:18] <didrocks> and no git installed, so…
[07:19] <didrocks> the question is really why gccgo 1.11 ignores the vendor/ directory
[07:19] <didrocks> (upstream compiler doesn't)
[07:19] <didrocks> that's in mwhudson's hand IMHO
[07:49] <LocutusOfBorg> didrocks, interesting I found mostly the same, after installing a lot of golang packages
[07:49] <LocutusOfBorg> didrocks, interesting I found mostly the same, after installing a lot of golang packages
[07:51] <mwhudson> uh what
[07:52] <xnox> mwhudson, didrocks, does any of https://github.com/golang/go/issues/29670 make sense?
[07:52] <LocutusOfBorg> I mean, I installed stuff like: golang-github-spf13-pflag-dev and so on
[07:52] <xnox> you shall have PWD in GOPATH?
[07:52] <LocutusOfBorg> and it still tries to fetch them...
[07:52] <LocutusOfBorg> even 1.12 seems to fail...
[07:53] <xnox> didrocks, i wonder if 'cd /tmp' at the end of debian/tests/setup would fix everything.....
[07:54] <mwhudson> oh well
[07:56] <didrocks> xnox: need to test it. I don't have 1.11.4 here (upstream 1.12.*)
[07:56] <xnox> didrocks, yeah, i'm doing...
[07:56] <didrocks> thx
[07:56] <xnox> didrocks, also I wonder if the autopkgtest can be reduced to:
[07:56] <xnox> Test-Command: /bin/true
[07:57] <xnox> Restrictions: requires-build
[07:57] <xnox> or whatever it was to ask autopkgtest to rebuild the package
[07:57] <didrocks> yeah, basically the idea is to rebuild + run the package tests
[07:57] <mwhudson> or GO111MODULE=off
[07:57] <mwhudson> "Outside GOPATH while inside a file tree with a go.mod — defaults to modules behavior"
[07:58] <xnox> cause that restriction would get you rw build-tree without needing to copy src tree.
[07:58] <didrocks> mwhudson: how is this related? in both behavior they should look at the vendor/ directory
[07:58] <xnox> and like one should use AUTOPKGTMP not /tmp
[07:58] <didrocks> so unsure if autopkgtests doesn't include it
[07:58] <mwhudson> "By default, go commands like go build ignore the vendor directory when in module mode."
[07:58] <mwhudson> if you're in a directory that's not in GOPATH and there is a go.mod file -> module mode
[07:59] <didrocks> mwhudson: where is that coming from? That was the first intent, but then, it got amended for distros like us
[07:59] <didrocks> when I discussed with Russ Cox
[07:59] <mwhudson> https://github.com/golang/go/wiki/Modules#when-do-i-get-old-behavior-vs-new-module-based-behavior
[07:59] <mwhudson> i should say that i'm not very aware of modules
[08:00] <mwhudson> but the behaviour in the autopkgtest is consistent with that wiki page
[08:00] <didrocks> I'm using modules for some months already :)
[08:00] <xnox> 'cd /tmp' fixes everything
[08:00] <xnox> let me try the GO111MODULE=off
[08:00] <didrocks> ok, so it's just that we are not in the correct directory
[08:01] <didrocks> I wonder if -mod=vendor hasn't been added in 1.12, not 1.11
[08:02] <didrocks> I'll add that for future references, at least with gccgo as I only use a vendor directory for the ubuntu package (not when doing upstream dev)
[08:02] <mwhudson> didrocks: why are you using gccgo!?
[08:03] <xnox> didrocks, mwhudson - 'export GO111MODULE=off' in debian/tests/setup also works
[08:03] <xnox> i can upload fixup with either 'cd' or 'export' or both.... any preference?
[08:04] <didrocks> mwhudson: isn't what the distro is using? Not upstream go compiiler?
[08:04] <mwhudson> didrocks: if you want to figure out how go modules should interact with packaging and implement that in debain ... >:)
[08:04] <mwhudson> didrocks: no!
[08:04] <didrocks> xnox: I would like to try GOFLAGS
[08:04] <LocutusOfBorg> me too
[08:04] <LocutusOfBorg> :)
[08:04] <xnox> didrocks, what do you want me to try in GOFLAGS?
[08:04] <didrocks> xnox: GOFLAGS=-mod=vendor
[08:05] <xnox> so... export GOFLAGS=-mod=vendor ?
[08:05] <didrocks> mwhudson: ah, I really thought that, good news
[08:05] <didrocks> yep
[08:05] <didrocks> xnox: it should pick the vendor/ directory in that case
[08:05] <LocutusOfBorg> goflags works too...
[08:05] <xnox> didrocks, we have always used golang-go on all arches it was available on, and only fellback to gccgo on arches that didn't. but golango is now available on all arches.
[08:06] <didrocks> mwhudson: if I have official time allocated for figuring out go modules support in debian, I would love to :)
[08:06] <mwhudson> didrocks: go build -mod=vendor is supported in 1.11 it seems
[08:06] <didrocks> xnox: ah, that's where my misinterpretation was for
[08:07] <mwhudson> didrocks: what kind of whisky does will like? :)
[08:07] <didrocks> mwhudson: ask him, he may answer that he prefers beers anyway :p
[08:08] <xnox> didrocks, GOFLAGS works too. so which of the three to upload?
[08:09]  * xnox doesn't like the version number in that GO111MODULE=off variable, as if, it's per-version-specific var
[08:10] <mwhudson> i think the idea is that it indicates the version it became valid in
[08:10] <didrocks> xnox: please use GOFLAGS and submit it in ubuntu-report upstream :)
[08:10] <mwhudson> you're not going to have to say GO112MODULE=off with go 1.12
[08:10]  * mwhudson afk for a while
[08:13] <xnox> i see that didrocks 2019 edition, does not like to prefix releases with 'v' =)
[08:13] <xnox> https://github.com/xnox/ubuntu-report/releases
[08:13] <didrocks> xnox: arg, nicely spotted! I blame debcommit -r :)
[08:13]  * didrocks adds a second tag
[08:14]  * xnox ponders if i should be uploading or not
[08:14] <xnox> https://github.com/ubuntu/ubuntu-report/pull/27
[08:14] <xnox> please upload?
[08:14] <LocutusOfBorg> btw xnox you might want to add all the three and decomment only the GOFLAGS one, so in case in future something breaks again... we have fallbacks
[08:14] <didrocks> xnox: feel free to upload :)
[08:15] <xnox> didrocks, ack, pushed tag to my repo. no idea if github merges tags or not.
[08:16] <didrocks> xnox: I guess for safety I'll pull/push
[08:16] <didrocks> once CI pass :p
[08:16] <xnox> didrocks, i think it's a trap
[08:16] <didrocks> heh
[08:16] <xnox> didrocks, "feel free to upload" and like no.....
[08:16] <xnox> 376 files changed, 7 insertions(+), 201177 deletions(-)
[08:17] <didrocks> hum
[08:17] <xnox> is my diffstat when i try to make an upload
[08:17] <didrocks> what?
[08:17] <didrocks> ah I know
[08:17] <didrocks> you need to go mod vendor
[08:17] <xnox> well, vendor tree is not in git?! or i failed to init them?
[08:17] <didrocks> to generate that vendor/ dir
[08:17] <didrocks> yeah, it's not in git
[08:17] <xnox> yeah, not doing that =)
[08:17] <didrocks> because you have go.mod and go.lock which defines the content
[08:17] <didrocks> so you have the exact same content
[08:17] <didrocks> I can upload anyway if you are scared :p
[08:18] <didrocks> let me sponsor you :p
[08:18] <didrocks> the day we have module support in debian/ubuntu, this go mod vendor can cease to exists
[08:19] <xnox> willcooke is not in the channel, but i am offering a whiskey tasting out of my own reserves to make ^ happen.
[08:20] <didrocks> heh
[08:21] <LocutusOfBorg> travis is happy!
[08:22] <didrocks>  changelog   |    6 ++++++
[08:22] <didrocks>  tests/setup |    1 +
[08:22] <didrocks> looks better ;)
[08:23] <didrocks> sponsored with love :)
[08:23] <didrocks> thanks xnox, mwhudson, LocutusOfBorg
[08:23] <LocutusOfBorg> thanks you all!
[08:23] <LocutusOfBorg> I hope we can move forward with golang-1.12 now :)
[08:24] <LocutusOfBorg> I'm stealing golang-1.11 merge :D
[08:24] <didrocks> same :)
[08:25] <didrocks> I have even some dreams of 1.13 released in early August and us picking it up
[08:25] <LocutusOfBorg> or mwhudson you want to do it?
[08:25] <LocutusOfBorg> the changelog is not listing all the delta, I'm unsure if it is wanted or not...
[08:43] <xnox> i did not expect the day to start with go; it was meant to start with perl!
[08:43] <LocutusOfBorg> you mean perl 5.28.2? :) /me hides
[08:46] <xnox> nah, just some modules
[08:49] <LocutusOfBorg> yep I know, I see the proposed page :)
[08:58] <xnox> Laney, our armhf autopkgtests appear to lack internets
[08:58] <xnox> Err:50 http://ftpmaster.internal/ubuntu eoan/main armhf pinentry-curses armhf 1.1.0-2
[08:58] <xnox>   Unable to connect to ftpmaster.internal:http:
[08:58] <Laney> retry
[08:59] <Laney> it happens sometimes, nobody has ever been able to figure it out
[08:59] <Laney> never ever happens when you access them manually, that would be too easy
[09:01] <xnox> hahaha
[09:01] <xnox> yeah the other package now passed. lolz
[09:03] <LocutusOfBorg> Laney, since the introduction of systemd-resolve, from time to time, I get some DNS resolving failure
[09:03] <dupondje> Was just about to ask something about golang-1.12 :) And I see history is full of golang talk :)
[09:03] <Laney> same thing
[09:03] <LocutusOfBorg> and when I type: "systemd-resolve --status" to figure it out, my laptop auto-heals
[09:03] <Laney> oh
[09:03] <Laney> not on tests
[09:03] <Laney> don't ask me about that stuff :-)
[09:03] <dupondje> Are there plans to get 1.12.4 into disco?
[09:04] <LocutusOfBorg> dupondje, like the one already in eoan? https://launchpad.net/ubuntu/+source/golang-1.12
[09:04] <dupondje> LocutusOfBorg: yep
[09:04] <LocutusOfBorg> just backport it into your ppa :)
[09:04] <dupondje> its bugfix only release, so might be usefull to backport it to disco no?
[09:04] <LocutusOfBorg> I'm to scared to SRU something I don't understand completely
[09:05] <LocutusOfBorg> dupondje, golang is a black hole for me
[09:05] <LocutusOfBorg> so... I don't know implications wrt archive sanity of stuff built with the previous version
[09:05] <LocutusOfBorg> as well as ABI issues while looking at the diff
[09:06] <LocutusOfBorg> and disco will be EOL soon, like in some months or so, loong before I can learn that language
[09:06] <LocutusOfBorg> Laney, the question was actually: can we put some hook to launch systemd-resolve --status when failures happen? or a cronjob saving it? or: are you using that as dns daemon or not?
[09:07] <Laney> seriously?
[09:07] <LocutusOfBorg> I don't know if you are using systemd to resolve or not...
[09:08] <LocutusOfBorg> I presume you have some DNS server in your lan to translate ftpmaster.internal into a private ip, right?
[09:09] <Laney> yes it's using systemd-resolved, but adding a hack like that is not really appropriate
[09:09] <Laney> if there's a bug then it should be fixed...
[09:10] <LocutusOfBorg> Laney, I'm not asking to add in the archive... I'm asking to add it in some machine to reproduce and log the issue to debug it
[09:10] <LocutusOfBorg> or try to see if stop using it helps...
[09:10] <Laney> and if you're experiencing the bug, then woohoo! we have someone who can debug
[09:10] <LocutusOfBorg> that would be *too* easy
[09:10] <LocutusOfBorg> :)
[09:11] <LocutusOfBorg> is it possible to install a custom systemd version on some armhf runners with debug code? or isolate some machines from the net and use them for testing purposes?
[09:12] <LocutusOfBorg> that systemd-resolve bug is something I'm trying to understand why/when happens since a lot, and it is happening on my machine
[09:13] <LocutusOfBorg> hopefully it is the same, and I presume it happens when I switch network, sometimes I'm connected on the same network via eth and wifi, when I disconnect wifi looks like the routing tables are not updated until I do some arp on the network (hopefully this is what systemd-resolve does)
[09:13] <LocutusOfBorg> I know having many connections on the same lan is not correct, this is something I forget to do (switching off wifi)
[09:18] <LocutusOfBorg> xnox, do you have systemd merge plans?
[09:19] <xnox> yes, i will merge systemd
[09:19]  * LocutusOfBorg wornders if something on new systemd will make armhf workers more happy
[09:49] <mwhudson> LocutusOfBorg: sure go ahead with 1.12
[10:10] <LocutusOfBorg> mwhudson, the changes in gbp.conf are useful or not?
[10:10] <LocutusOfBorg> https://patches.ubuntu.com/g/golang-1.12/golang-1.12_1.12.4-1ubuntu1.patch
[10:10] <LocutusOfBorg> also, the "find -delete *.syso" is not listed in changelog
[10:14] <LocutusOfBorg> I think you should commit them on debian git repo...
[10:14]  * LocutusOfBorg golang uploaded
[10:25] <mwhudson> LocutusOfBorg: uhh i merged golang-1.12 already
[10:25] <mwhudson> didn't i?
[10:27] <mwhudson> LocutusOfBorg: i thought you were talking about moving the default onto 1.12 ...
[10:29] <LocutusOfBorg> yep you did I made a mistake, I now uploaded 1.11 merged
[10:29] <LocutusOfBorg> I leave 1.11 default migrate (hopefully on next britney run) and then leave to you the default switch to 1.12
[10:29] <LocutusOfBorg> my biggers concern is to kick 1.10 out
[10:39] <mwhudson> LocutusOfBorg: the changes in gbp.conf are useful
 also, the "find -delete *.syso" is not listed in changelog
[10:40] <mwhudson> sure it is, that's what "Do not distribute un-built from source race detector runtime files" is about
[10:40] <mwhudson> i should probably get that change into debian but my inertia for ITP-ing golang-race-detector-runtime seems to be basically infinite
[10:44] <mwhudson> LocutusOfBorg: i do the merges from debian via git not mom btw
[10:44]  * mwhudson zzz
[10:46] <LocutusOfBorg> mwhudson, do you need a debian sponsor?
[10:47] <LocutusOfBorg> I couldn't find the ubuntu branch on debian git, but I might be wrong, and I hope the delta will go away...
[11:47] <Wafficus> hi there can anyome help me modify the Ubuntu ISO Tester to solely automate the testing of Lubuntu isos?
[11:48] <Wafficus> https://bazaar.launchpad.net/~ubuntu-server-iso-testing-dev/ubuntu-server-iso-testing/trunk/view/head:/docs/README.dev
[11:48] <Wafficus> if anyone can point me to the specific spot of the docs on how to use altermate isos id appreciate it
[11:49] <Wafficus>  my email is SBanya@outlook.com if you can help me
[11:49] <Wafficus> thanks
[14:08] <sahid> Laney: hello, in autopktest, what is related to the armhf worker? i have difficulty to find that
[14:08] <sahid> in my idea that was the arm64 workers but it seems that i'm worng
[14:13] <sahid> coreycb: ^ you might have an idea
[14:29] <acheronuk> mwhudson: hi. now eoan exists here, https://partner-images.canonical.com/core/eoan/current/ , is there a change of eoan docker images soon?
[14:29] <acheronuk> *chance of
[15:17] <coreycb> sahid: i'm not sure that i understand the question
[15:21] <sahid> coreycb: it's related to this merge request https://code.launchpad.net/~sahid-ferdjaoui/autopkgtest-cloud/+git/autopkgtest-cloud/+merge/366696
[15:39] <obiwahn> hi guys i would like to build a newer binutils for 16.4 so it can be used in travis
[15:40] <obiwahn> it would be cool if here is somebody who can provide me with a template and who answers a few questions as they araise
[15:41] <doko> oSoMoN: the fonts update was needed because the new version was required in the security pocket
[15:42] <oSoMoN> doko, ack, that's what I understood from talking to t_daitx, but the cosmic task in the bug report was irrelevant, right?
[15:42] <doko> I assume so
[15:46] <coreycb> sahid: ah i see, you've updated the arm64 conf and there's no obvious armhf conf?
[15:48] <sahid> coreycb: yep
[15:49] <sahid> i was expecting Laney to give me a hint
[16:49] <rbasak> obiwahn: are you speaking as Travis upstream, or a Travis user? You should just ask your questions - nobody is going to put themselves on the hook for answering if they don't know what the questions are.
[16:59] <obiwahn> How do I get the 18.04 biutils sources on 16.04?
[16:59] <obiwahn> i know there ist apt-get source
[17:00] <obiwahn> Is there a cross release mechanism to get the sources?
[17:02] <sarnold> obiwahn: copy the /etc/apt/sources.list to /etc/apt/sources.list.d/bionic.list -- replace all the 'xenial' with 'bionic', then apt-get update && apt-get source binutils/bionic
[17:29] <rbasak> obiwahn: the cross release mechanism Ubuntu developers use is "pull-lp-source binutils bionic". pull-lp-source is in the ubuntu-dev-tools package.
[17:34] <JohnGavr> hello there
[17:34] <JohnGavr> I am coming here with a question about the new kernel
[17:35] <JohnGavr> When i stop a video or a music in any client, i hear a bip on the external audio speakers. In other kernels don't do that.
[17:49] <obiwahn> thank you - i am just setting up a vm and look how far i get
[18:02] <JohnGavr> obiwahn, are you talking to me?
[18:02] <Eickmeyer> !support | JohnGavr
[18:21] <obiwahn> rbasak: I have unsatisfied build deps for binutils. I can proably build it with any other older gcc but what must I do to change the dependencies? Is it ok just to lower the versions in the control file?
[18:22] <obiwahn> i think i just try to change files in the binutils dir and build the content with dpkg-buildpackage.
[18:37] <obiwahn> oh gosh dpkg-gencontrol|vendor has it to be that complicated:P
[18:37] <cjwatson> You shouldn't normally use dpkg-gencontrol manually
[18:38] <cjwatson> Changing debian/control is usually all you need to do to change build-deps, unless debian/control is generated from other files in debian/ (which is fairly rare but some packages do it - in that case poke through the rules files under debian/ to find what the actual source file is and change that)
[18:39] <obiwahn> cjwatson: What are the correct steps to change the dependencies when creating a backport?
[18:39] <cjwatson> Depends wildly
[18:39] <cjwatson> I mean most backports don't need to change build-dependencies
[18:39] <cjwatson> In the cases that do it's utterly specific to the problem at hand
[18:39] <cjwatson> But for general advice on changing build-deps, see my previous remark
[18:43] <sarnold> obiwahn: hmm. I wonder, if you actually want bionic on travis's xenial systems, maybe using debootstrap would get you to your desired end result more quickly
[19:11] <ddstreet> xnox i see systemd in eoan is still failing boot-smoke due to lp #1825997 do you want me to prep a debdiff for you to include in your next upload or are you already working on it
[19:11] <ddstreet> i have a patch ready to fix it, then i think storage is the only failing test left, right?
[19:20] <ddstreet> xnox mp for u: https://code.launchpad.net/~ddstreet/ubuntu/+source/systemd/+git/systemd/+merge/366857
[19:20] <ddstreet> enjoy
[19:39] <pipegeek> hi, folks!  was wondering: how does GNOME Software determine which packages to make visible and which ones to hide from search results?
[19:39] <obiwahn> Is there a command to install everything that is in a control file. Something like apt-get build-dep but for control files instead of packages
[19:40] <pipegeek> and in particular, would it be reasonable to open a feature request bug against the network-manager-.*-gnome packages (or against gnome-software depending on how that works) to request that they be made visible through that interface?
[19:40] <pipegeek> those seem like reasonable things for nontechnical end-users to want to be able to install (e.g. "L2TP VPN Support for Gnome")
[19:40] <pipegeek> without having to open a terminal to do it
[19:50] <pipegeek> never mind!  I just realized I can't read
[19:50] <pipegeek> it's already there, it's just not listed as a separate package.
[19:51] <pipegeek> sorry for the noise :)
[21:25] <mwhudson> acheronuk: in short, yes
[21:25] <mwhudson> LocutusOfBorg: no, i maintain all this crap in debian too
[21:25] <mwhudson> LocutusOfBorg: the ubuntu branches are only in my launchpad git repo, not debian
[21:26] <mwhudson> LocutusOfBorg: so it's perfectly reasonable for you not to have found them, now that I remember that fact :)
[21:51] <Unit193> mwhudson: ...If you get bored, could I entice you to look at gocryptfs?  (Sorry I'm bugging about this one yet again..)
[21:58] <mwhudson> Unit193: uhh as in why is it still in proposed?
[22:00] <mwhudson> looks like it depends on the new golang-golang-x-sys
[22:01] <mwhudson> golang-go4 maybe needs new grpc?
[22:01] <mwhudson> this stuff is all such a mess
[22:02] <Unit193> That's kind of why I asked you, since you seem to be an expert.  It got stuck in disco because x-sys needed a retry on arm64 (so I ended up backporting both to a PPA)
[22:06] <mwhudson> hmm clearly i need to stop appearing like an expert :)
[22:06] <Unit193> Too late.