[01:26] <vorlon> cyphermox: can you tell me why zita-ajbridge is not showing up in the output of http://people.canonical.com/~ubuntu-archive/packagesets/disco/ubuntustudio despite having Task: ubuntustudio-desktop-core, ubuntustudio-desktop ?
[01:28] <Unit193> mwhudson: Hrm, something weird in golang?  https://buildd.debian.org/status/package.php?p=gocryptfs&suite=unstable built fine a couple days ago, but in Ubuntu it failed https://launchpad.net/ubuntu/+source/gocryptfs/1.6.1-1, while retrying it now it's gotten even worse: https://launchpad.net/~unit193/+archive/ubuntu/staging/+sourcepub/9970424/+listing-archive-extra
[01:28] <Unit193> Though backporting a couple libs and trying on cosmic was fine: https://launchpad.net/~unit193/+archive/ubuntu/staging/+sourcepub/9583688/+listing-archive-extra
[01:29] <Unit193> I did find https://github.com/golang/go/issues/26832
[01:30] <mwhudson> is our golang-golang-x-sys out of date?
[01:30] <mwhudson> our default _go_ is somewhat behind debian's
[01:30] <Unit193> It's older than Debian's.
[01:31] <Unit193> Stuck in proposed, it seems.
[01:31] <mwhudson> Unit193: does your ppa have proposed enabled?
[01:32] <mwhudson> the arm64/armhf failures are timeouts?
[01:32] <Unit193> It has backports, which may well exclude proposed.. :/
[01:33] <mwhudson> golang-go.crypto tests fail
[01:34] <mwhudson> TestInvalidTerminalMode
[01:34] <mwhudson> dunno what's up with that
[01:34] <Unit193> Based on Debian, autopkgtest will fail.
[01:38] <mwhudson> sounds like time for a hint
[01:39] <sarnold> I thought that said "sounds like time for a pint"
[01:39] <mwhudson> that said TestInvalidTerminalMode has been there since 2012
[01:43] <mwhudson> maybe openssh-server ignores rather than failing invalid terminal modes now?
[01:47] <mwhudson> orrr maybe the packaging changed so this test is actually run now
[01:54] <mwhudson> no, no idea
[02:17] <Unit193> \o/
[02:30] <mwhudson> ban i386: https://paste.ubuntu.com/p/vcpN3kDJfb/
[02:37] <sarnold> wow. how'd that happen.
[02:37] <sarnold> I mean I know floating point means you get the usual "lolwtf" output.. but still. that's not even close. :)
[02:38] <mwhudson> only happens with rustc 1.32 too
[02:38] <mwhudson> at least i think, i haven't absolutely checked that
[02:45] <mwhudson> um no it happens with 1.31.0 too
[02:45] <mwhudson> wtf
[02:56] <mwhudson> https://github.com/paholg/typenum/pull/115
[02:57] <sarnold> paholg?
[02:58] <sarnold> hmm looks like he's upstream for typenum. TIL. :)
[03:30] <Unit193> mwhudson: That one sitting in -prop, can you retry arm*?
[03:30] <Unit193> https://launchpad.net/~unit193/+archive/ubuntu/staging/+build/16490024 suggests it should build fine.
[12:10] <rbasak> tjaalton: why aren't you following the SRU verification instructions?
[12:11] <rbasak> Please comment explaining what testing you performed and what versions you tested before you change the tag to done.
[12:11] <rbasak> I can't be bothered to go through all your bugs where you haven't done this. Please go over them, tell me when they're all done, and then I'll take a look.
[12:17] <tjaalton> rbasak: so if the description already says the test case, I'd need to again say what was tested?
[12:17] <tjaalton> and how
[12:18] <tjaalton> assuming this is mesa
[12:18] <rbasak> tjaalton: "I followed the test case described in the bug description and the results were X" would be sufficient then (together with confirmation of the package versions tested)
[12:19] <rbasak> I don't understand why you think just changing the tag is sufficient. If it were, why do you think we manually review instead of having a bot that just autoreleases on the tag change?
[12:19] <rbasak> What do you expect me to manually review if you say nothing?
[12:20] <tjaalton> rbasak: which bug are you talking about?
[12:21] <rbasak> I was triggered by https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1789924
[12:23] <tjaalton> it adds pci-id strings
[12:23] <rbasak> Then I looked at https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1815172 and you haven't confirmed the package version tested (as requested in the long standing template, and something I've brought up on ubuntu-devel@ before)
[12:23] <rbasak> And?
[12:23] <tjaalton> I can grep the dri driver for the strings if that's enough. I don't have the hw
[12:23] <tjaalton> yes the test case probably is overly optimistic in this case
[12:24] <rbasak> OK, so say what you can and cannot do, what you consider to be sufficient testing, etc.
[12:24] <rbasak> This is a perfect example. You didn't actually test, and in the bug you're implying you did.
[12:24] <rbasak> The SRU team is supposed to make a judgement call.
[12:24] <rbasak> You are preventing the SRU team from being able to do so by saying nothing.
[12:26] <tjaalton> I don't know what you're asking for 1815172
[12:26] <tjaalton> the change in 18.2.2+ was already verified, bug reopened because the new .changes file in 18.2.8 referenced the same bug (again)
[12:29] <tjaalton> (because 18.2.2+ never got in cosmic, then bionic got the new 18.2.8 backport)
[12:29] <rbasak> I don't think that's at all clear from your comment.
[12:29] <rbasak> "bionic was already tested earlier": when? What package version?
[12:30] <tjaalton> can't bother to go back to #13?
[12:30] <rbasak> It wasn't obvious to me that this was relevant, because you apparently can't be bothered to actually explain and seem to expect me to mindread.
[12:31] <rbasak> And given that you just admitted you tried to slip one past the SRU team in 1789924, I think my position is justified.
[12:33] <seb128> you guys should perhaps step back and calm down a bit and assume people have good intend...
[12:34] <seb128> tjaalton, it's standard practice to comment while change the tag to specify the version you tested (that was added due to the fact that we had regular cases of users testing and commenting that the fix worked/didn't work but sometime they still had the old version or a wrong one installed, stating the version used helps to give confidence the right one was used)
[12:34] <seb128> it also doesn't hurt to state how/what you tested, again we had users who just changed tags
[12:34] <seb128> so saying "I went through the testcase with version <v> installed, all worked as expected" isn't much
[12:34] <seb128> tjaalton, seems reasonable?
[12:36] <tjaalton> I should've said something in this bug yes. but upstream adding 10 pci-id's is impossible to verify along the sru rules
[12:37] <tjaalton> same is true for any bug that requires certain hw
[12:37] <tjaalton> err
[12:37] <seb128> it's fine, sometime we can't test, then just add a comment "I didn't test by lack of access to the hardware, but the fix is right on principle and we didn't get report of regressions so ti makes sense to validate the SRU"
[12:38] <tjaalton> no, of course isn't impossible, but adding pci-id's is *trivial*
[12:38] <seb128> yeah, it's fine
[12:38] <seb128> just add the reason
[12:38] <seb128> the SRU team usually agrees when the rational makes sense
[12:38] <seb128> I've no been annoyed by e.g libmtp updates which add a stack of new device ids and where we can't test them all
[12:39] <seb128> not*
[12:39] <seb128> just state that there is little potential for regression by adding those and that we tested and nothing is obvious broken on other systems
[12:57] <tjaalton> did my best
[12:57] <tjaalton> this time
[13:38] <doko> tjaalton: could you have a look at the resteasy3.0 autopkg test regression in cosmic-proposed? All archs. http://autopkgtest.ubuntu.com/packages/d/dogtag-pki/cosmic/amd64
[13:39] <doko> succeeded in bionic-proposed
[13:54] <tjaalton> doko: ok
[14:13] <tjaalton> doko: well, that's odd, seems as if certutil failed.. anyway, that's while setting up pki-tps which likely no-one uses, so I think you can just ignore it. I don't have time to test it myself now
[14:26] <doko> tjaalton: ok, thanks for checking
[15:19] <seb128> unsure who unblocked curl if it's a side effect of other changes, but thx :)
[16:42] <vorlon> cyphermox: I guess you missed my question about zita-ajbridge showing up in the ubuntustudio tasks but not in the packageset
[16:49] <cyphermox> indeed
[16:49] <cyphermox> vorlon: currently on a ho with rbasak to try and clarify our disagreement on packageset matters
[16:50] <cyphermox> (or our lack of disagreement and figure out a good way forward, and then propose that to the DMB as a whole)
[16:50] <cyphermox> it's been quite useful to make use of higher bandwidth
[16:52] <Laney> that package ends up in desktop-core
[16:53] <cyphermox> Laney: you saying it should?
[16:53] <Laney> not necessarily
[16:53] <cyphermox> afaict it does not right now
[16:53] <Laney> but that's why you don't get it in ubuntustudio
[16:53] <Laney> sure it does, grep your germinate-output
[16:53] <cyphermox> I was looking at http://people.canonical.com/~ubuntu-archive/packagesets/disco/desktop-core
[16:54] <Laney> not that, the germinate generated thing
[16:54] <cyphermox> I know
[16:54] <Laney> ok, well they're not the same thing
[16:54] <cyphermox> no, I know; I'm just saying it's neither in that, generated this morning, nor in ubuntustudio
[16:55] <cyphermox> so clearly there is still a subtle bug in the packageset update script
[16:56] <Laney> I'd think you would want to investigate why germinate is putting it in 'desktop-core'(*not* the packageset)
[16:59] <cyphermox> it looks to me to be entirely because it's only transitively referred to by desktop-core.
[17:00] <Laney> that's what I'm saying
[17:01] <Laney> +    'ubuntustudio/desktop-core': ['ubuntustudio'],
[17:01] <cyphermox> yes, I'm looking at that
[17:03] <Laney> k
[18:19] <sarnold> bdmurray: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1819162
[19:00] <sarnold> bdmurray: https://pagure.io/SSSD/sssd/issue/3901
[19:56] <Eickmeyer> vorlon: I'm looking at the logs from the latest build failure for ubuntustudio. Are we any closer to a solution? An idea I had was to remove the update-grub command from the postinst just to get it building again, but I know that would interfere with your investigation.
[19:58] <mwhudson> Unit193: sure
[20:12] <vorlon> Eickmeyer: if you want to drop the update-grub call, feel free; I don't think it significantly blocks my investigation.  The consequence is that new installs of Ubuntu Studio will have the bootloader unthemed in the meantime, but that seems to be status quo
[20:14] <Eickmeyer> vorlon: Doesn't update-grub have to run at the end of the installl anyhow?
[20:16] <vorlon> Eickmeyer: yes, I suppose it does at that
[20:16] <Eickmeyer> vorlon: Okay. I'm going to go ahead and make the modifications in  the ubuntustudio-look package.
[20:19] <Eickmeyer> vorlon: Quick question: since this will require a re-upload, should I bump the version number completely or just tack a "-1" on the end (e.g. 0.57-1)?
[20:20] <vorlon> Eickmeyer: since this is a native package, you would normally bump the version number
[20:20] <Eickmeyer> vorlon: Thanks.
[20:20] <vorlon> a -1 would suggest you're switching it to non-native
[20:21] <Eickmeyer> Good to know
[21:19] <Eickmeyer> vorlon: I pushed the commit for the fix, and since it's under my PPU list, I'm learning how to upload it now, or at least looking for the wiki. :/
[21:21] <vorlon> Eickmeyer: I don't know that the actual acl has been edited yet in order to let you upload
[21:21] <Eickmeyer> vorlon: Oh, okay. In that case, it's ready, have at it?
[21:22] <Eickmeyer> I did push the tag this time. :)
[21:22] <cyphermox> Eickmeyer: in progress
[21:22] <Eickmeyer> cyphermox: Awesome, thanks.
[21:22] <cyphermox> actually, if vorlon wants to apply commands I'll send them in a bit
[21:26] <cyphermox> vorlon: https://bugs.launchpad.net/ubuntu-community/+bug/1819970
[21:27] <vorlon> yeah, let me run the commands and then Eickmeyer can do the upload himself
[21:31] <vorlon> cyphermox: grub2-theme-ubuntustudio sees to not be the correct source package name
[21:32] <Eickmeyer> vorlon: That's because I made an error when creating the project on launchpad. It's grub2-themes-ubuntustudio. Themes plural.
[21:32] <Eickmeyer> Only reason for that was because it's forked from grub2-themes-ubuntu-mate. Themes plural again.
[21:33] <vorlon> Eickmeyer: got it
[21:33] <vorlon> Eickmeyer: acls added
[21:33] <Eickmeyer> vorlon: Much appreciated.
[21:33] <vorlon> and I'm confused that the acl for 'carla' worked
[21:33] <Eickmeyer> Yeah, that shouldn't have considering it's not even there yet.
[21:44] <cyphermox> I think LP knows about it because it's been uploaded to a PPA before.
[21:51]  * Eickmeyer is currently uploading ubuntustudio-look directly for the first time
[21:52] <cyphermox> yay!
[21:52] <Eickmeyer> TIL my upload speeds stink.
[21:54] <Eickmeyer> bbl, leaving to get my son from school
[22:48] <Unit193> mwhudson: Thanks!