| infinity | vorlon: 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 |
|---|---|---|
| ubottu | Launchpad bug 1713615 in ubuntu-restricted-extras (Ubuntu) "ttf-mscorefonts-installer fails because Redirection from https to http is forbidden" [Undecided,Confirmed] | 01:09 |
| vorlon | Logan: have you seen that the new mtail's autopkgtests seem to be less than happy (possibly related to the presence of proxies)? | 04:48 |
| juliank | infinity: So apt would have done the right thing with both filename and sha256; but apt-helper only accepts one | 09:56 |
| juliank | this fixes it: https://github.com/Debian/apt/compare/master...julian-klode:pu/apt-helper-multihash?expand=1 | 09:56 |
| juliank | allows you to add as many hashes a you want to a download-file | 09:56 |
| juliank | (download-file accepts multiple URL PATH pairs, so it's a bit confusing | 09:57 |
| LocutusOfBorg | mwhudson, 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 answer | 10:30 |
| LocutusOfBorg | without having to prove it :) | 10:30 |
| === ricab is now known as ricab|lunch | ||
| LocutusOfBorg | mwhudson, golang-1.11 merge too please? | 12:02 |
| LocutusOfBorg | also golang-defaults... | 12:03 |
| LocutusOfBorg | I can do them if you want | 12:04 |
| LocutusOfBorg | they are trivial | 12:04 |
| ahasenack | hello 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 |
| ahasenack | it's sssd, and both bugs are green now in the sru report page: 1722936 1793882 | 12:14 |
| === cpaelzer__ is now known as cpaelzer | ||
| rbasak | apw: 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 |
| coreycb | RAOF: 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 |
| apw | rbasak, 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 |
| apw | rbasak, 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 not | 12:53 |
| rbasak | apw: the repository will end up being the default one for the package if I don't blacklist it. | 13:12 |
| apw | rbasak, presumbly not if i then later change it | 13:13 |
| rbasak | apw: 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/master | 13:13 |
| rbasak | (but "linux" is blacklisted) | 13:13 |
| apw | rbasak, are you saying you would move it back every time, or only when you first make it | 13:14 |
| rbasak | apw: 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 |
| rbasak | I can of course coordinate and adjust scripts which is why I'm talking to you :) | 13:14 |
| apw | rbasak, it would feel like you should take the default if it has none currently, else not | 13:14 |
| rbasak | The question is just what we want exactly to maximise benefit and minimise pain. | 13:14 |
| apw | then the thing could always import safely | 13:15 |
| rbasak | That's a good idea. | 13:15 |
| apw | out default is stupid, i did that to try and make pushes to new repos cheaper, it didn't work | 13:15 |
| apw | and some new git setting helped it not be so stupid | 13:15 |
| rbasak | One thing I'd like is to reduce exceptions. | 13:16 |
| apw | as i have no objction to linux being imported, so raw dscs are in there | 13:16 |
| rbasak | git-ubuntu is most valuable if it works on all packages | 13:16 |
| rbasak | You had warned me from importing linux for performance reasons :) | 13:16 |
| apw | oh it might make you sad ;) | 13:16 |
| apw | but i have no philosphical objection | 13:16 |
| rbasak | Any objection to git-ubuntu eventually taking over the default for all packages without exception? | 13:17 |
| apw | i don't know that that makes sense, the default should be what the packager expects you to use, no ? | 13:17 |
| apw | not that we can even do that in our current namespace for linux for example | 13:17 |
| rbasak | That makes it very painful for new and/or drive-by contributors | 13:17 |
| apw | it is more painful surely if they do their work against an importer tree | 13:18 |
| apw | and we have no way to work with what they give us, and make them do it another way | 13:18 |
| rbasak | No way? git-rebase is trivial for us. | 13:18 |
| rbasak | The benefit of doing it against an importer tree is consistent documentation and tooling for all packages. | 13:19 |
| rbasak | When "git ubuntu build" and "git ubuntu lint" and "git ubuntu submit" eventually work. | 13:19 |
| apw | i am going to ignore this part for now, and say, that i am expecting you will have to do something | 13:19 |
| rbasak | Then it'll be a case of "clone, cherry-pick, build, submit". | 13:19 |
| rbasak | No learning packaging involved. | 13:20 |
| apw | witht the default, for the 'push a tag here as an upload' world, | 13:20 |
| apw | so maybe it all becomes forced on us by then anyhow | 13:20 |
| rbasak | OK. So let's leave it for a future discussion when tooling is better. | 13:20 |
| rbasak | linux-snapdragon I'll ignore for now then, and let it continue importing. | 13:21 |
| apw | rbasak, but with our per series repo split, we cannot use the default for anything useful, as you can only have one | 13:21 |
| rbasak | It 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 |
| rbasak | And 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 |
| apw | sounds fine, i tend to unset the default to stop it being utterly confusing to people | 13:22 |
| rbasak | OK. Thanks! | 13:22 |
| === ricab|lunch is now known as ricab | ||
| seb128 | bdmurray, 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 |
| bdmurray | seb128: you reminding me ;-) maybe we should add it to the release opening checklist | 14:07 |
| seb128 | bdmurray, 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 |
| seb128 | bdmurray, thx in any case :) | 14:08 |
| infinity | jdstrand: What are you trying to accomplish with gcc-multilib on arm64? | 16:44 |
| infinity | jdstrand: Note that gcc-multilib:armhf (that you believe you want) is hf/sf multilib, not v8/v7. | 16:45 |
| infinity | jdstrand: Is it possible that what you actually want is gcc-arm-linux-gnueabihf (which does exist on arm64)? | 16:47 |
| jdstrand | infinity: to be able to use -m32 on arm64, like I can with gcc-multilib on amd64 | 16:47 |
| infinity | jdstrand: Yeah, -m32 on arm64 is a non-starter, as we don't do arm64 multilib. | 16:48 |
| infinity | jdstrand: 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 |
| infinity | jdstrand: 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. :P | 16:49 |
| jdstrand | infinity: it is only for test code so I have 32 bit binaries I can run on 64 bit machines | 16:49 |
| jdstrand | and trying to make that work with a single snapcraft.yaml that will build everything in LP | 16:50 |
| infinity | jdstrand: Kay. Keeping in mind, again, that most armv8 machines can't run 32-bit code. :P | 16:50 |
| jdstrand | infinity: that's fine. I disabled the 32 bits bit from arm64 for this test code | 16:51 |
| jdstrand | thanks for the info | 16:51 |
| infinity | jdstrand: 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 |
| infinity | jdstrand: (ie: LD_PRELOAD=/path/to/cross/libc.so /path/to/cross/ld.so /path/to/test/binary) | 16:52 |
| infinity | Or similary hideousness. | 16:53 |
| jdstrand | yeah, 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 staged | 16:53 |
| jdstrand | it works for amd64 so I'm ok | 16:54 |
| infinity | jdstrand: 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 |
| infinity | jdstrand: 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 |
| infinity | jdstrand: 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 |
| xnox | jdstrand, 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 |
| jdstrand | yeah. since the arm doesn't require the compat, for the test code I think I'm good as is, but noted | 16:58 |
| xnox | in all cases, devel machines, chroots, snap builds etc. and that's the thing to use. Including enabling multiarch deps, where needed. | 16:58 |
| xnox | jdstrand, that's generic supported any-to-any solution. | 16:58 |
| jdstrand | ack | 16:58 |
| coreycb | bdmurray: 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 |
| bdmurray | coreycb: bug 1708572 doesn't have any Ubuntu tasks | 19:38 |
| ubottu | bug 1708572 in OpenStack Compute (nova) "Unable to live-migrate : Disk of instance is too large" [High,Fix released] https://launchpad.net/bugs/1708572 | 19:38 |
| coreycb | bdmurray: sorry about that. i've updated the bug. | 20:22 |
| mwhudson | LocutusOfBorg: was going to do golang-defaults but forgot | 21:01 |
| mwhudson | LocutusOfBorg: should probably remove golang-1.11, it'll be EOL by the time eoan releases | 21: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!