[02:19] <Lord-Kamina> cjwatson, could you give me an idea of how to use chdist to find which dependency is making apt choke?
[04:44] <Lord-Kamina> Now THIS is pretty weird... especially because I could swear I got it to begin building earlier... https://launchpadlibrarian.net/379795140/buildlog_ubuntu-xenial-amd64.dpkg_1.18.24ubuntu1ppa-xenial1_BUILDING.txt.gz
[04:45] <Lord-Kamina> Oops wrong build log.
[04:45] <Lord-Kamina> https://launchpadlibrarian.net/379810592/buildlog_ubuntu-trusty-amd64.dpkg_1.18.24ubuntu1ppa-trusty5_BUILDING.txt.gz
[07:51] <cjwatson> Lord-Kamina: "chdist create SOME-NAME", then edit ~/.chdist/SOME-NAME/etc/apt/sources.list to have a sources.list that matches what the PPA build is using (you can get that from near the top of the build log, just replace ftpmaster.internal with archive.ubuntu.com and make sure there's a deb-src line for the PPA containing the source package), "chdist SOME-NAME apt update", then "chdist ...
[07:51] <cjwatson> ... SOME-NAME apt build-dep SOURCE-PACKAGE-NAME"
[07:52] <cjwatson> Lord-Kamina: assuming that reproduces the failure, break it down: get the build-deps and pass them all individually in a single long "chdist SOME-NAME apt install ..." line
[07:53] <cjwatson> Lord-Kamina: now add each of the other package names that apt install complains about to that apt install line.  Repeat until you get error messages that aren't "is not going to be installed"
[07:53] <cjwatson> Lord-Kamina: (don't ever actually say yes to an install-these-packages prompt inside chdist ... apt install; it's only meant for simulation)
[07:55] <cjwatson> That last sbuild failure is certainly weird.  Is it reproducible?
[08:02] <ePierre> Hello! I'm facing a problem when trying to build a snap from my launchpad project. I need to pull FWTS from kernel.ubuntu.com, but it's blocked apparently:
[08:02] <ePierre> https://launchpadlibrarian.net/379826575/buildlog_snap_ubuntu_xenial_amd64_qabro-test_BUILDING.txt.gz
[08:02] <ePierre> Pulling fwts
[08:02] <ePierre> Cloning into '/build/qabro/parts/fwts/src'...
[08:02] <ePierre> [24/Jul/2018:07:05:43 +0000] "CONNECT kernel.ubuntu.com:9418 HTTP/1.0" 403 1697 "-" "-"
[08:02] <ePierre> 2018/07/24 07:05:44 socat[10875] E CONNECT kernel.ubuntu.com:9418: Forbidden
[08:02] <ePierre> fatal: Could not read from remote repository.
[08:02] <ePierre> Please make sure you have the correct access rights
[08:02] <ePierre> and the repository exists.
[08:02] <ePierre> ---
[08:02] <ePierre> is it normal?
[08:11] <cjwatson> ePierre: Hosts within the Canonical datacentre need to be explicitly whitelisted (to avoid causing problems for legacy services that assume that any request coming from within the datacentre is trustable).  Could you file a bug on the "rutabaga" project please?
[08:12] <cjwatson> (It'll be a small change to whitelist this.)
[08:15] <ePierre> cjwatson, https://bugs.launchpad.net/rutabaga/+bug/1783280
[08:15] <ePierre> cjwatson, thanks!
[08:15] <cjwatson> Cheers
[08:16] <ePierre> (and by the way, thanks again for the fix for bug #1729754 , will be very helpful when in lands)
[08:16] <cjwatson> No problem.  It was quite a journey of discovery fixing it!
[08:30] <ePierre> cjwatson, I was actually wondering... what was your thought process to find the root cause, and how long did it take you?
[08:36] <cjwatson> ePierre: We've known for a while that it was line-ending mangling in the standard library's email module, though the form of the errors already made it fairly clear that it was something like that.  Actually fixing it took a couple of days, mainly due to the stdlib's behaviour being wildly different across Python versions so needing to do quite a large matrix of tests
[08:39] <rmescandon> I've just pushed a new branch in a git repository. When I access to the web, to see all the branches for that repo I see the message 'Updating repository...' stuck there (15 minutes stuck so far) and the new branch is not pushed. Does anybody know how to solve it?
[08:39] <wgrant> rmescandon: Which git repository?
[08:40] <rmescandon> it is a private repo
[16:08] <Lord-Kamina> cjwatson, apparently that sbuild failure was caused by me backporting a newer tar.
[16:12] <cjwatson> oww
[16:12] <cjwatson> yeah, I kind of generally don't recommend backporting lots of foundational components.  if you have something that has a newer dependency on something like that (even up as far as debhelper or so), then it's usually easier to work out how to make do with a lower version of the dependency instead
[16:13] <cjwatson> you can get yourself into some real tangles otherwise
[16:16] <Lord-Kamina> Yeah, even tar 1.28 is producing that error.
[16:17] <Lord-Kamina> One of the tests required tar --sort, I guess I'll just have to remove it. *shrugs*
[16:17] <cjwatson> I imagine dpkg or sbuild or something needed to be adjusted to cope.  When you backport low-level components you end up rediscovering a whole bunch of compatibility fixes ...
[17:26] <Lord-Kamina> Is there any way to solve/is it sane to try to rely on the order something might be installed?
[17:27] <Lord-Kamina> Like, if one package works after another is installed but if it's installed before the other, installation breaks?
[17:28] <nacc> Lord-Kamina: that sounds like it should be a Depends ?
[17:29] <Lord-Kamina> Yeah but I think I've gotten myself in a catch 22.
[17:29] <Lord-Kamina> I'm probably not understanding how the different kind of depends work.
[17:30] <nacc> Lord-Kamina: certainly possible :)
[17:34] <Lord-Kamina> Should it be possible to specify, for example Build-Depends: foo (<< 2.0) and then Depends: foo (>= 2.0)
[17:36] <nacc> that seems ... weird
[17:36] <nacc> and seems like it would lead to broken applications if that ends up creating any lib dependencies
[17:40] <Lord-Kamina> Let me create a list to illustrate better.
[17:45] <Lord-Kamina> This is not what I was doing earlier (which was probably fubar), is this legal: https://gist.github.com/Lord-Kamina/43395c6564843c7a4eb8290fab501ab7 ?
[18:26] <Lord-Kamina> cjwatson it was dpkg that needed fixing for the newer tar.
[19:10] <nacc> Lord-Kamina: what creates binary foo?
[19:10] <nacc> Lord-Kamina: and binary bar?
[19:10] <nacc> Lord-Kamina: also you may want #debian-packaging or #ubuntu-packaging (iirc)
[19:10] <Lord-Kamina> Their respective package, I just added binary to make it clear those are the binaries.
[19:11] <nacc> Lord-Kamina: right, but it changes the contents of the control files
[19:11] <nacc> Lord-Kamina: right now you have a binary package depending on srcpkgs :)
[19:13] <Lord-Kamina> It's not like that in the actual packages but still it's a gotcha I hadn't considered.
[19:13] <Lord-Kamina> Thanks.
[19:13] <nacc> Lord-Kamina: just makes it harder to provide accurate feedback :)
[19:14] <Lord-Kamina> I think I solved that particular case, though. I'm pretty deep down the rabbit hole with this idiocy, It's probably so not worth it.
[19:19] <nacc> Lord-Kamina: my initial reaction to your example is to agree with you :)
[19:22] <Lord-Kamina> Hahahaha
[20:17] <Lord-Kamina> Anybody know what could be the reason for this? build appears to be stuck in a loop https://launchpad.net/~litenstein/+archive/ubuntu/dpkg1-17-trusty/+build/15164379
[20:18] <Lord-Kamina> Does not happen in the amd64 build, neither did it apparently happen in the i386 build at the ppa where I copied that from.
[20:39] <cjwatson> I'd suggest cancelling it and then diffing the build log from the PPA you copied it from against the failing build, and looking for differences in e.g. build-deps that get installed
[20:56] <Lord-Kamina> I had and wasn't finding any but I think I just did.
[20:56] <Lord-Kamina> I think the original build was using the ubuntu toolchain builds repository and I was using the toolchain test builds.
[21:52] <Lord-Kamina> How strict is the ppa size quota?
[21:53] <Lord-Kamina> I just copied a bunch of packages and binaries from the toolchain test builds to one of my own ppas, and I'm going over the quota... There's a bunch of archs I don't intend on using among the copied binaries but I don't think I can just delete those.
[22:02] <Lord-Kamina> Or will the archs unselected in my ppa be pruned from my copies when the next disk clean happens?
[23:03] <cjwatson> Lord-Kamina: The quota is applied when doing source uploads.  It doesn't cause deletions, but if you're over quota you won't be able to upload anything to the PPA until you resolve it.
[23:03] <Lord-Kamina> Ok.
[23:04] <cjwatson> Lord-Kamina: I'd have to check in more detail in order to be sure, but I wouldn't expect binaries for architectures that aren't enabled in your PPA to actually end up published in it.
[23:05] <cjwatson> So they shouldn't count towards quota.
[23:07] <Lord-Kamina> They did, though. Which is why I'm asking whether they get nuked later. :P
[23:07] <Lord-Kamina> https://launchpad.net/~litenstein/+archive/ubuntu/toolchain/+packages
[23:09] <cjwatson> I obviously misremember.  They won't be pruned.  It is possible to remove them, although only with command-line tools.
[23:09] <cjwatson> (remove-package from lp:ubuntu-archive-tools - would take some care though)
[23:11] <Lord-Kamina> I see.
[23:12] <Lord-Kamina> A question that is probably extremely basic... what thought process should I follow when configuring ppa dependencies. What's the difference between Ubuntu dependencies and Ubuntu components?
[23:13] <cjwatson> remove-package> it'd be something like   remove-package -A ppa:litenstein/ubuntu/toolchain -m 'unused architectures' -a arm64 -a armhf -a powerpc -a ppc64el -b <big list of binary package names>
[23:13] <cjwatson> but inspect the output carefully
[23:13] <cjwatson> PPA dependencies are only for build-time dependencies - there's no mechanism for telling users to use them, so they should be configured accordingly
[23:17] <Lord-Kamina> What I mean is, what's the difference between dependencies and components  and how would each behave?
[23:17] <cjwatson> sorry, I'm trying to answer but my son is also talking to me :P
[23:18] <cjwatson> in the web UI, "Ubuntu dependencies" corresponds to the part after the hyphen in "trusty-proposed", "trusty-security", "trusty-updates" etc. in APT sources.list files
[23:18] <cjwatson> you might think of it as a channel
[23:18] <cjwatson> or a risk level, or something like that
[23:19] <cjwatson> packages are published in one or more of those "suites"
[23:19] <cjwatson> so a package might go first to trusty-proposed, and then be copied to trusty-updates after it's been tested properly
[23:20] <cjwatson> components are a different axis.  there are four components in Ubuntu: main, restricted, universe, multiverse
[23:20] <cjwatson> these correspond to a matrix of {supported, unsupported} x {free, non-free}, more or less
[23:22] <cjwatson> some archives (e.g. anything that's ultimately going to end up in Ubuntu proper) want to build in a way that corresponds to how the Ubuntu archive builds, where roughly packages only get to see build-dependencies that are at least as "strict" as the component they themselves are in - so for instance a free package doesn't see non-free build-dependencies, to avoid unfortunate accidents
[23:22] <cjwatson> most PPA users don't much care about that sort of sanitisation, so the default is "use all Ubuntu components available"
[23:27] <Lord-Kamina> I see.
[23:28] <Lord-Kamina> Is this possibly caused by wrongly configuring that? https://launchpadlibrarian.net/379913285/buildlog_ubuntu-trusty-i386.gcc-defaults_1.136ubuntu2~ubuntu14.04.1york2_BUILDING.txt.gz
[23:29] <cjwatson> goodness knows, at this point you have a serious case of frankenppa
[23:29] <cjwatson> it's going to be a full-time job to disentangle
[23:29] <Lord-Kamina> tl;dr for that log.
[23:29] <cjwatson> debhelper/dpkg backports are always tough
[23:29] <Lord-Kamina> Need gcc-4.9.2
[23:29] <cjwatson> my previous recommendation of using chdist stands
[23:30] <Lord-Kamina> It says it's trying to install 4.9-20140406 instead.
[23:30] <Lord-Kamina> And earlier it says gcc-4.9-base was "kept back"
[23:31] <Lord-Kamina> After your explanation I'm inclined to believe I need to rebuild some dependencies down the line
[23:31] <cjwatson> you have to use chdist (or some other way of invoking apt) to get actually useful diagnostics here
[23:31] <cjwatson> apt stops at the first level and doesn't dig deeper when issuing diagnostics, unless you coerce it
[23:32] <Lord-Kamina> I tried using chdist as you said but mostly I just get a list of every single package because nothing is actually installed.
[23:32] <cjwatson> you're doing it wrong then :)
[23:32] <cjwatson> let me get you a transcript so you can see what to do
[23:32] <cjwatson> because having me debug it every time doesn't scale
[23:33] <Lord-Kamina> I don't really like bugging you constantly either but so far you've proven orders of magnitude more helpful than google. :P
[23:34] <cjwatson> if you get a list of every single package then you've failed to reproduce the error
[23:36] <Lord-Kamina> (not literally every single package, but rather all of the dependencies)
[23:37] <Lord-Kamina> I figure I might have done the sources.list wrong.
[23:38] <cjwatson> Lord-Kamina: https://paste.ubuntu.com/p/R65vfVrC8R/
[23:39] <cjwatson> (I typoed "libc6" instead of "libc6-dev" at one point there, but it doesn't affect the outcome.)
[23:46] <Lord-Kamina> Thanks.
[23:46] <Lord-Kamina> That made it a lot clearer.
[23:47] <cjwatson> There can be variations of course, but hopefully the general strategy is visible there.
[23:47] <cjwatson> And often the final output will be some kind of conflict or a directly unsatisfiable dependency rather than missing packages.
[23:47] <Lord-Kamina> How do I actually get/use ubuntu-archive-tools?
[23:47] <Lord-Kamina> Do I need to get binaries, or is it just scripts?
[23:48] <cjwatson> It's just a load of Python code; bzr branch lp:ubuntu-archive-tools
[23:48] <cjwatson> (Some day we should probably do proper packaging or something ...)
[23:49] <cjwatson> It's mainly intended for use by Ubuntu archive administrators, but a few of the tools there are also useful for people managing PPAs
[23:49] <cjwatson> Mostly copy-package and remove-package