[01:40] hi all - does anyone know where the official upstream of sbsigntool lives now? [01:41] is it jejb's kernel.org repo, or does the official one live at Canonical still? [01:43] 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] 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] dja: https://git.kernel.org/pub/scm/linux/kernel/git/jejb/sbsigntools.git/ [01:51] (it does need an update, more specifically a merge from Debian; I will take care of that) [02:02] 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] I can send a patch to james for master [02:04] ah looks like master already has it [02:17] cyphermox: master got the fix I wanted in 2014 so hopefully a sync with debian should catch it [02:17] thanks :) === MarkMaglana_ is now known as MarkMaglana [06:41] mwhudson, maybe we can make 1.11 migrate and then transition again? [06:53] didrocks, ubuntu-report is having a sad day with new default golang... I don't think I understood the testsuite failure.... [07:16] LocutusOfBorg: ah, interesting, I guess autopkgtests rdepends? [07:17] LocutusOfBorg: funny, because with the upstream google compiler, I'm using 1.11 (and not 1.12) for months… [07:18] 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] and no git installed, so… [07:19] the question is really why gccgo 1.11 ignores the vendor/ directory [07:19] (upstream compiler doesn't) [07:19] that's in mwhudson's hand IMHO [07:49] didrocks, interesting I found mostly the same, after installing a lot of golang packages [07:49] didrocks, interesting I found mostly the same, after installing a lot of golang packages [07:51] uh what [07:52] mwhudson, didrocks, does any of https://github.com/golang/go/issues/29670 make sense? [07:52] I mean, I installed stuff like: golang-github-spf13-pflag-dev and so on [07:52] you shall have PWD in GOPATH? [07:52] and it still tries to fetch them... [07:52] even 1.12 seems to fail... [07:53] didrocks, i wonder if 'cd /tmp' at the end of debian/tests/setup would fix everything..... [07:54] oh well [07:56] xnox: need to test it. I don't have 1.11.4 here (upstream 1.12.*) [07:56] didrocks, yeah, i'm doing... [07:56] thx [07:56] didrocks, also I wonder if the autopkgtest can be reduced to: [07:56] Test-Command: /bin/true [07:57] Restrictions: requires-build [07:57] or whatever it was to ask autopkgtest to rebuild the package [07:57] yeah, basically the idea is to rebuild + run the package tests [07:57] or GO111MODULE=off [07:57] "Outside GOPATH while inside a file tree with a go.mod — defaults to modules behavior" [07:58] cause that restriction would get you rw build-tree without needing to copy src tree. [07:58] mwhudson: how is this related? in both behavior they should look at the vendor/ directory [07:58] and like one should use AUTOPKGTMP not /tmp [07:58] so unsure if autopkgtests doesn't include it [07:58] "By default, go commands like go build ignore the vendor directory when in module mode." [07:58] if you're in a directory that's not in GOPATH and there is a go.mod file -> module mode [07:59] mwhudson: where is that coming from? That was the first intent, but then, it got amended for distros like us [07:59] when I discussed with Russ Cox [07:59] https://github.com/golang/go/wiki/Modules#when-do-i-get-old-behavior-vs-new-module-based-behavior [07:59] i should say that i'm not very aware of modules [08:00] but the behaviour in the autopkgtest is consistent with that wiki page [08:00] I'm using modules for some months already :) [08:00] 'cd /tmp' fixes everything [08:00] let me try the GO111MODULE=off [08:00] ok, so it's just that we are not in the correct directory [08:01] I wonder if -mod=vendor hasn't been added in 1.12, not 1.11 [08:02] 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] didrocks: why are you using gccgo!? [08:03] didrocks, mwhudson - 'export GO111MODULE=off' in debian/tests/setup also works [08:03] i can upload fixup with either 'cd' or 'export' or both.... any preference? [08:04] mwhudson: isn't what the distro is using? Not upstream go compiiler? [08:04] didrocks: if you want to figure out how go modules should interact with packaging and implement that in debain ... >:) [08:04] didrocks: no! [08:04] xnox: I would like to try GOFLAGS [08:04] me too [08:04] :) [08:04] didrocks, what do you want me to try in GOFLAGS? [08:04] xnox: GOFLAGS=-mod=vendor [08:05] so... export GOFLAGS=-mod=vendor ? [08:05] mwhudson: ah, I really thought that, good news [08:05] yep [08:05] xnox: it should pick the vendor/ directory in that case [08:05] goflags works too... [08:05] 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] mwhudson: if I have official time allocated for figuring out go modules support in debian, I would love to :) [08:06] didrocks: go build -mod=vendor is supported in 1.11 it seems [08:06] xnox: ah, that's where my misinterpretation was for [08:07] didrocks: what kind of whisky does will like? :) [08:07] mwhudson: ask him, he may answer that he prefers beers anyway :p [08:08] 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] i think the idea is that it indicates the version it became valid in [08:10] xnox: please use GOFLAGS and submit it in ubuntu-report upstream :) [08:10] you're not going to have to say GO112MODULE=off with go 1.12 [08:10] * mwhudson afk for a while [08:13] i see that didrocks 2019 edition, does not like to prefix releases with 'v' =) [08:13] https://github.com/xnox/ubuntu-report/releases [08:13] 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] https://github.com/ubuntu/ubuntu-report/pull/27 [08:14] please upload? [08:14] 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] xnox: feel free to upload :) [08:15] didrocks, ack, pushed tag to my repo. no idea if github merges tags or not. [08:16] xnox: I guess for safety I'll pull/push [08:16] once CI pass :p [08:16] didrocks, i think it's a trap [08:16] heh [08:16] didrocks, "feel free to upload" and like no..... [08:16] 376 files changed, 7 insertions(+), 201177 deletions(-) [08:17] hum [08:17] is my diffstat when i try to make an upload [08:17] what? [08:17] ah I know [08:17] you need to go mod vendor [08:17] well, vendor tree is not in git?! or i failed to init them? [08:17] to generate that vendor/ dir [08:17] yeah, it's not in git [08:17] yeah, not doing that =) [08:17] because you have go.mod and go.lock which defines the content [08:17] so you have the exact same content [08:17] I can upload anyway if you are scared :p [08:18] let me sponsor you :p [08:18] the day we have module support in debian/ubuntu, this go mod vendor can cease to exists [08:19] willcooke is not in the channel, but i am offering a whiskey tasting out of my own reserves to make ^ happen. [08:20] heh [08:21] travis is happy! [08:22] changelog | 6 ++++++ [08:22] tests/setup | 1 + [08:22] looks better ;) [08:23] sponsored with love :) [08:23] thanks xnox, mwhudson, LocutusOfBorg [08:23] thanks you all! [08:23] I hope we can move forward with golang-1.12 now :) [08:24] I'm stealing golang-1.11 merge :D [08:24] same :) [08:25] I have even some dreams of 1.13 released in early August and us picking it up [08:25] or mwhudson you want to do it? [08:25] the changelog is not listing all the delta, I'm unsure if it is wanted or not... [08:43] i did not expect the day to start with go; it was meant to start with perl! [08:43] you mean perl 5.28.2? :) /me hides [08:46] nah, just some modules [08:49] yep I know, I see the proposed page :) [08:58] Laney, our armhf autopkgtests appear to lack internets [08:58] Err:50 http://ftpmaster.internal/ubuntu eoan/main armhf pinentry-curses armhf 1.1.0-2 [08:58] Unable to connect to ftpmaster.internal:http: [08:58] retry [08:59] it happens sometimes, nobody has ever been able to figure it out [08:59] never ever happens when you access them manually, that would be too easy [09:01] hahaha [09:01] yeah the other package now passed. lolz [09:03] Laney, since the introduction of systemd-resolve, from time to time, I get some DNS resolving failure [09:03] Was just about to ask something about golang-1.12 :) And I see history is full of golang talk :) [09:03] same thing [09:03] and when I type: "systemd-resolve --status" to figure it out, my laptop auto-heals [09:03] oh [09:03] not on tests [09:03] don't ask me about that stuff :-) [09:03] Are there plans to get 1.12.4 into disco? [09:04] dupondje, like the one already in eoan? https://launchpad.net/ubuntu/+source/golang-1.12 [09:04] LocutusOfBorg: yep [09:04] just backport it into your ppa :) [09:04] its bugfix only release, so might be usefull to backport it to disco no? [09:04] I'm to scared to SRU something I don't understand completely [09:05] dupondje, golang is a black hole for me [09:05] so... I don't know implications wrt archive sanity of stuff built with the previous version [09:05] as well as ABI issues while looking at the diff [09:06] and disco will be EOL soon, like in some months or so, loong before I can learn that language [09:06] 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] seriously? [09:07] I don't know if you are using systemd to resolve or not... [09:08] I presume you have some DNS server in your lan to translate ftpmaster.internal into a private ip, right? [09:09] yes it's using systemd-resolved, but adding a hack like that is not really appropriate [09:09] if there's a bug then it should be fixed... [09:10] 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] or try to see if stop using it helps... [09:10] and if you're experiencing the bug, then woohoo! we have someone who can debug [09:10] that would be *too* easy [09:10] :) [09:11] 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] 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] 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] I know having many connections on the same lan is not correct, this is something I forget to do (switching off wifi) [09:18] xnox, do you have systemd merge plans? [09:19] yes, i will merge systemd [09:19] * LocutusOfBorg wornders if something on new systemd will make armhf workers more happy [09:49] LocutusOfBorg: sure go ahead with 1.12 [10:10] mwhudson, the changes in gbp.conf are useful or not? [10:10] https://patches.ubuntu.com/g/golang-1.12/golang-1.12_1.12.4-1ubuntu1.patch [10:10] also, the "find -delete *.syso" is not listed in changelog [10:14] I think you should commit them on debian git repo... [10:14] * LocutusOfBorg golang uploaded === tinoco_ is now known as tinoco === lfaraone_ is now known as lfaraone [10:25] LocutusOfBorg: uhh i merged golang-1.12 already [10:25] didn't i? [10:27] LocutusOfBorg: i thought you were talking about moving the default onto 1.12 ... [10:29] yep you did I made a mistake, I now uploaded 1.11 merged [10:29] I leave 1.11 default migrate (hopefully on next britney run) and then leave to you the default switch to 1.12 [10:29] my biggers concern is to kick 1.10 out [10:39] LocutusOfBorg: the changes in gbp.conf are useful [10:39] also, the "find -delete *.syso" is not listed in changelog [10:40] sure it is, that's what "Do not distribute un-built from source race detector runtime files" is about [10:40] 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] LocutusOfBorg: i do the merges from debian via git not mom btw [10:44] * mwhudson zzz [10:46] mwhudson, do you need a debian sponsor? [10:47] 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] hi there can anyome help me modify the Ubuntu ISO Tester to solely automate the testing of Lubuntu isos? [11:48] https://bazaar.launchpad.net/~ubuntu-server-iso-testing-dev/ubuntu-server-iso-testing/trunk/view/head:/docs/README.dev [11:48] if anyone can point me to the specific spot of the docs on how to use altermate isos id appreciate it [11:49] my email is SBanya@outlook.com if you can help me [11:49] thanks === ricab is now known as ricab|lunch === ricab|lunch is now known as ricab === stgraber_ is now known as stgraber [14:08] Laney: hello, in autopktest, what is related to the armhf worker? i have difficulty to find that [14:08] in my idea that was the arm64 workers but it seems that i'm worng [14:13] coreycb: ^ you might have an idea [14:29] 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] *chance of [15:17] sahid: i'm not sure that i understand the question [15:21] coreycb: it's related to this merge request https://code.launchpad.net/~sahid-ferdjaoui/autopkgtest-cloud/+git/autopkgtest-cloud/+merge/366696 [15:39] hi guys i would like to build a newer binutils for 16.4 so it can be used in travis [15:40] 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] oSoMoN: the fonts update was needed because the new version was required in the security pocket [15:42] 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] I assume so [15:46] sahid: ah i see, you've updated the arm64 conf and there's no obvious armhf conf? [15:48] coreycb: yep [15:49] i was expecting Laney to give me a hint === sarnold_ is now known as sarnold [16:49] 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] How do I get the 18.04 biutils sources on 16.04? [16:59] i know there ist apt-get source [17:00] Is there a cross release mechanism to get the sources? [17:02] 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] 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] hello there [17:34] I am coming here with a question about the new kernel [17:35] 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] thank you - i am just setting up a vm and look how far i get [18:02] obiwahn, are you talking to me? [18:02] !support | JohnGavr [18:02] JohnGavr: The official ubuntu support channel is #ubuntu. Please be aware that this channel is for development only. [18:21] 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] i think i just try to change files in the binutils dir and build the content with dpkg-buildpackage. [18:37] oh gosh dpkg-gencontrol|vendor has it to be that complicated:P [18:37] You shouldn't normally use dpkg-gencontrol manually [18:38] 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] cjwatson: What are the correct steps to change the dependencies when creating a backport? [18:39] Depends wildly [18:39] I mean most backports don't need to change build-dependencies [18:39] In the cases that do it's utterly specific to the problem at hand [18:39] But for general advice on changing build-deps, see my previous remark [18:43] 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] 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] Launchpad bug 1825997 in systemd (Ubuntu Eoan) "boot-smoke fails due to running jobs" [Low,In progress] https://launchpad.net/bugs/1825997 [19:11] i have a patch ready to fix it, then i think storage is the only failing test left, right? [19:20] xnox mp for u: https://code.launchpad.net/~ddstreet/ubuntu/+source/systemd/+git/systemd/+merge/366857 [19:20] enjoy [19:39] hi, folks! was wondering: how does GNOME Software determine which packages to make visible and which ones to hide from search results? [19:39] 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] 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] 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] without having to open a terminal to do it [19:50] never mind! I just realized I can't read [19:50] it's already there, it's just not listed as a separate package. [19:51] sorry for the noise :) [21:25] acheronuk: in short, yes [21:25] LocutusOfBorg: no, i maintain all this crap in debian too [21:25] LocutusOfBorg: the ubuntu branches are only in my launchpad git repo, not debian [21:26] LocutusOfBorg: so it's perfectly reasonable for you not to have found them, now that I remember that fact :) [21:51] mwhudson: ...If you get bored, could I entice you to look at gocryptfs? (Sorry I'm bugging about this one yet again..) [21:58] Unit193: uhh as in why is it still in proposed? [22:00] looks like it depends on the new golang-golang-x-sys [22:01] golang-go4 maybe needs new grpc? [22:01] this stuff is all such a mess [22:02] 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] hmm clearly i need to stop appearing like an expert :) [22:06] Too late.