infinityvorlon: Yeah, it was only https://bugs.launchpad.net/ubuntu/+source/msttcorefonts/+bug/1713615/comments/18 who implied a dpkg failure, and since he didn't back it up with any evidence, I'm going to assume he was smoking something, cause all the pasted logs look fine.01:09
ubottuLaunchpad bug 1713615 in ubuntu-restricted-extras (Ubuntu) "ttf-mscorefonts-installer fails because Redirection from https to http is forbidden" [Undecided,Confirmed]01:09
vorlonLogan: have you seen that the new mtail's autopkgtests seem to be less than happy (possibly related to the presence of proxies)?04:48
juliankinfinity: So apt would have done the right thing with both filename and sha256; but apt-helper only accepts one09:56
juliankthis fixes it: https://github.com/Debian/apt/compare/master...julian-klode:pu/apt-helper-multihash?expand=109:56
juliankallows you to add as many hashes a you want to a download-file09:56
juliank(download-file accepts multiple URL PATH pairs, so it's a bit confusing09:57
LocutusOfBorgmwhudson, it was quite easy to find out... I did build successfully on my laptop (bionic amd64) and it failed on ppa, so I found two possible reasons: 1) restrictions on ppas 2) something in -proposed pocket. I did reconfigure my ppa to not use proposed-pocket and the build was good, so I diffed the two logs and found that only gcc and openssl had -proposed version... looking at the version number of openssl gave me the answer10:30
LocutusOfBorgwithout having to prove it :)10:30
=== ricab is now known as ricab|lunch
LocutusOfBorgmwhudson, golang-1.11 merge too please?12:02
LocutusOfBorgalso golang-defaults...12:03
LocutusOfBorgI can do them if you want12:04
LocutusOfBorgthey are trivial12:04
ahasenackhello sru team, we almost gave up on an sru that has been unverified for too long, but yesterday the reporter finally flipped the tags. That upload was blocking another more urgent sru, but looks like now it can finally move forward!12:14
ahasenackit's sssd, and both bugs are green now in the sru report page: 1722936 179388212:14
=== cpaelzer__ is now known as cpaelzer
rbasakapw: linux-snapdragon ended up getting imported by git-ubuntu as it isn't matched by the blacklist. Is that a problem? Should I blacklist and/or remove the repo?12:35
coreycbRAOF: hello, would you have cycles in your rotation today to take a look at nova in the xenial unapproved queue? we'd like to see if we can get that one moving along.12:48
apwrbasak, i have no idea what it really means to be imported, i assume it is making a default repository called +git/linux-snapdragon which we then never use ?12:48
apwrbasak, ahh there they are, as they are in another user entirely, i am not sure if i care either way if you blacklist them or not12:53
rbasakapw: the repository will end up being the default one for the package if I don't blacklist it.13:12
apwrbasak, presumbly not if i then later change it13:13
rbasakapw: which would collide in the case of "linux", for example, which currently points to https://code.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/version-seeds/+ref/master13:13
rbasak(but "linux" is blacklisted)13:13
apwrbasak, are you saying you would move it back every time, or only when you first make it13:14
rbasakapw: you could later change it, but you'd be fighting with our scripts - since occasionally we have to batch run the defaults change for all repositories that we import.13:14
rbasakI can of course coordinate and adjust scripts which is why I'm talking to you :)13:14
apwrbasak, it would feel like you should take the default if it has none currently, else not13:14
rbasakThe question is just what we want exactly to maximise benefit and minimise pain.13:14
apwthen the thing could always import safely13:15
rbasakThat's a good idea.13:15
apwout default is stupid, i did that to try and make pushes to new repos cheaper, it didn't work13:15
apwand some new git setting helped it not be so stupid13:15
rbasakOne thing I'd like is to reduce exceptions.13:16
apwas i have no objction to linux being imported, so raw dscs are in there13:16
rbasakgit-ubuntu is most valuable if it works on all packages13:16
rbasakYou had warned me from importing linux for performance reasons :)13:16
apwoh it might make you sad ;)13:16
apwbut i have no philosphical objection13:16
rbasakAny objection to git-ubuntu eventually taking over the default for all packages without exception?13:17
apwi don't know that that makes sense, the default should be what the packager expects you to use, no ?13:17
apwnot that we can even do that in our current namespace for linux for example13:17
rbasakThat makes it very painful for new and/or drive-by contributors13:17
apwit is more painful surely if they do their work against an importer tree13:18
apwand we have no way to work with what they give us, and make them do it another way13:18
rbasakNo way? git-rebase is trivial for us.13:18
rbasakThe benefit of doing it against an importer tree is consistent documentation and tooling for all packages.13:19
rbasakWhen "git ubuntu build" and "git ubuntu lint" and "git ubuntu submit" eventually work.13:19
apwi am going to ignore this part for now, and say, that i am expecting you will have to do something13:19
rbasakThen it'll be a case of "clone, cherry-pick, build, submit".13:19
rbasakNo learning packaging involved.13:20
apwwitht the default, for the 'push a tag here as an upload' world,13:20
apwso maybe it all becomes forced on us by then anyhow13:20
rbasakOK. So let's leave it for a future discussion when tooling is better.13:20
rbasaklinux-snapdragon I'll ignore for now then, and let it continue importing.13:21
apwrbasak, but with our per series repo split, we cannot use the default for anything useful, as you can only have one13:21
rbasakIt will become default when I next run the script (the importer instance can't do it since it doesn't have core dev credentials)13:21
rbasakAnd next time I work on the script, I'll add your suggestion about only assigning the default if none is set.13:21
rbasak(without --force or something)13:21
apwsounds fine, i tend to unset the default to stop it being utterly confusing to people13:22
rbasakOK. Thanks!13:22
=== ricab|lunch is now known as ricab
seb128bdmurray, hey, do you know what's needed to get http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-ee-incoming-bug-tasks.html generated?13:58
bdmurrayseb128: you reminding me ;-) maybe we should add it to the release opening checklist14:07
seb128bdmurray, that would make sense I guess (or maybe the system should just be smart enough to query launchpad for active series and no need manual changes)14:08
seb128bdmurray, thx in any case :)14:08
infinityjdstrand: What are you trying to accomplish with gcc-multilib on arm64?16:44
infinityjdstrand: Note that gcc-multilib:armhf (that you believe you want) is hf/sf multilib, not v8/v7.16:45
infinityjdstrand: Is it possible that what you actually want is gcc-arm-linux-gnueabihf (which does exist on arm64)?16:47
jdstrandinfinity: to be able to use -m32 on arm64, like I can with gcc-multilib on amd6416:47
infinityjdstrand: Yeah, -m32 on arm64 is a non-starter, as we don't do arm64 multilib.16:48
infinityjdstrand: For any number of reasons, though a major one being that armv8 doesn't actually require armv7 compat as part of the spec.16:48
infinityjdstrand: That said, I'd also suggest that multilib is an outdated, evil, and nasty concept that we might want to shy away from, not lean into. :P16:49
jdstrandinfinity: it is only for test code so I have 32 bit binaries I can run on 64 bit machines16:49
jdstrandand trying to make that work with a single snapcraft.yaml that will build everything in LP16:50
infinityjdstrand: Kay.  Keeping in mind, again, that most armv8 machines can't run 32-bit code. :P16:50
jdstrandinfinity: that's fine. I disabled the 32 bits bit from arm64 for this test code16:51
jdstrandthanks for the info16:51
infinityjdstrand: Anyhow, crossing with gcc-arm-linux-gnueabihf will produce 32-bit binaries.  Running them is a bit more exciting, since you won't have a libc or linker on path, but you can fudge that by running the linker by hand if you're only do it for test purposes.16:52
infinityjdstrand: (ie: LD_PRELOAD=/path/to/cross/libc.so /path/to/cross/ld.so /path/to/test/binary)16:52
infinityOr similary hideousness.16:53
jdstrandyeah, I was thinking about that. I'd need to get a libc on the system I could use and the same bug that prevented me from getting gcc-multilib prevents me from getting that staged16:53
jdstrandit works for amd64 so I'm ok16:54
infinityjdstrand: I'm not sure how people will respond to your request for foreign arches in snap builds, but I've been strongly against it for deb builds because it leads to the architectures no longer being self-contained (and, also, some fuzziness on how to resolve multi-arch deps when packages exist on A, B, C, but not D, E, F)16:54
infinityjdstrand: There's a libc pulled in by the cross gcc (it needs one to link to), it's just that ld.so and libc.so aren't on the usual paths, so don't "work" by default.  Aiming at them manually will make it magically work if the goal is just to build and run a throwaway binary.16:55
infinityjdstrand: Then if you don't want weirdly divergent code, you could switch the x86 implementation to use gcc-i686-linux-gnu and the cross-libc too, but meh.16:56
infinity(Guess how much I wish multilib wasn't a thing)16:56
infinity(Guess how functional my time machine isn't)16:56
xnoxjdstrand, this been discussed before. and gcc-multilib is bad, crossbuild-essential-ARCH is good! and it does pull in the right libc, etc.16:57
jdstrandyeah. since the arm doesn't require the compat, for the test code I think I'm good as is, but noted16:58
xnoxin all cases, devel machines, chroots, snap builds etc. and that's the thing to use. Including enabling multiarch deps, where needed.16:58
xnoxjdstrand, that's generic supported any-to-any solution.16:58
coreycbbdmurray: hello, if you have cycles in your rotation today can you take a look at nova in the xenial unapproved queue? we'd like to see if we can get that one moving along.19:31
bdmurraycoreycb: bug 1708572 doesn't have any Ubuntu tasks19:38
ubottubug 1708572 in OpenStack Compute (nova) "Unable to live-migrate : Disk of instance is too large" [High,Fix released] https://launchpad.net/bugs/170857219:38
coreycbbdmurray: sorry about that. i've updated the bug.20:22
mwhudsonLocutusOfBorg: was going to do golang-defaults but forgot21:01
mwhudsonLocutusOfBorg: should probably remove golang-1.11, it'll be EOL by the time eoan releases21:01
mwhudson(let's not mention anything about disco releasing with eol golang 1.10 oops)21:02

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!