[02:00] <teward> cjwatson: thanks, it was asked of me by a Debian package maintainer when their package which autosynced into proposed would get out of it
[02:08] <dobey> teward: the exuces page suggested a new apt and gcc, which probably doesn't help much with things migrating from proposed. i know i've been having issues with packages in PPAs that depend on -proposed in xenial the past couples days, because of installability issues for build deps
[02:09] <teward> dobey: it wasn't delayed migration - it was delayed lack of available binary packages
[02:09] <teward> which in turn caused a delayed migration - but it wasn't due to apt/gcc afaict
[02:09] <dobey> teward: which delays migration...
[02:09] <teward> indeed.
[02:09] <teward> but i was more concerned about the "no binary packages in any arch" issue that was there
[02:09] <dobey> and apt/gcc can delay binary packages
[02:09] <teward> it was resolved though
[02:09] <teward> ahhhh, okay
[02:10] <dobey> and the excuses.html can be very out of sync with reality sometimes
[02:14] <dobey> anyway, i should probably be doing something other than sitting at the computer
[02:23] <cjwatson> teward: That would probably have been caused by the seeds being broken, yes.
[03:03] <teward> so, question, why're all the armhf builders disabled...?
[03:03] <teward> except for one
[03:03] <teward> (for PPAs)
[03:05] <teward> (3 days for an armhf PPA build sounds a little excessive?)
[03:10] <cjwatson> We recently switched to building them virtualised on arm64 hardware, but the reset procedure on that cloud is not entirely reliable yet.
[03:11] <cjwatson> Let's see if they'll come back.
[03:11] <cjwatson> (Er, by which I mean that I'm poking them.)
[03:17] <teward> that looks a bit nicer, now.  (referring to the Builders page)
[03:17] <teward> cjwatson: thanks for poking it
[03:17] <cjwatson> This is not as promising as it might be, but I may be able to resurrect some more with a bit of persistence.
[03:17] <teward> mmm, indeed.
[03:18] <teward> i mean, it's not a huge importance for immediately for me, i'm just build-testing something at the request of a Debian maintainer in relation to a bug about a missing Ubuntu-specific build dep, so there's not a huge need
[03:19] <teward> it just struck me as odd to see a 3-day-in-the-future build date
[03:19] <cjwatson> Yes, that'll happen when the cloud is semi-broken.
[03:19] <cjwatson> We don't yet know exactly what the problem is.  It looks like DHCP requests get lost when the instances are trying to boot, but it's not entirely clear.
[03:20]  * teward shrugs
[03:20] <teward> thanks for poking at it anyways :)
[03:20] <cjwatson> But at a weekend we aren't going to be able to get sysadmins to help dig into the root cause, so whack-a-mole and prayer it is.
[03:21] <teward> indeed.
[03:24] <cjwatson> The point of the test rebuild currently running on arm64 was to arrange for there to be enough resets that we could have time to dig into the root cause, so hopefully we can make more headway on that soon.
[03:25] <cjwatson> Well, I'm not enormously hopeful that that'll stay up overnight, but I'll check again in the morning.
[15:01] <ricotz> hello, could someone restart https://launchpad.net/~canonical-libreoffice-builds/+archive/ubuntu/archive-staging/+build/8964534
[15:05] <cjwatson> ricotz: hmm, that's peculiar, but OK, doing
[15:05] <cjwatson> ricotz: (you didn't have a "cancel build" option yourself?)
[17:39] <ricotz> cjwatson, thanks (I am not in that group but waiting for this built to succeed)
[17:59] <cjwatson> ricotz: oh, of course
[18:05] <sergio-br2> I learned on math that 0.02015 < 0.170
[18:05] <sergio-br2> but apt does not agree with that
[18:05] <sergio-br2> it's 0.02015.git
[18:06] <sergio-br2> actually
[18:06] <cjwatson> sergio-br2: Version numbers aren't decimals.
[18:06] <cjwatson> sergio-br2: https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version
[18:07] <sergio-br2> :/
[18:07] <sergio-br2> and now, what do I do then?
[18:07] <cjwatson> Choose different versions?
[18:07] <sergio-br2> I want to change to 0.170
[18:07] <sergio-br2> * it's mame libretro package
[18:08] <cjwatson> I think you should be able to solve all your problems by reading the above document carefully.
[18:08] <sergio-br2> ah, using epoch right
[18:09] <cjwatson> That's one option, although you should be aware that it isn't reversible (within a given archive, anyway).
[18:11] <cjwatson> As the policy document says, it's for leaving behind mistakes, not for coping with silly orderings.  It may not be compatible with other packagings of the same upstream source, and it effectively constitutes a promise to figure out how to use a sensible strictly-increasing versioning scheme in future.
[18:12] <dobey> i would avoid epochs unless impossible to do so
[18:13] <cjwatson> Strings of digits are generally compared numerically, but segment-by-segment - so the relevant mathematical fact here is that 02015 > 170.
[21:21] <mbaynton1> anyone want to help a newbie out with uploads to my ppa that just go into the void? I'm pretty sure it's not an incorrectly signed .changes file
[21:30] <cjwatson> mbaynton1: Looking
[21:31] <cjwatson> mbaynton1: So if the .changes file is sufficiently broken, we can't even manage to parse it to notify you of the problem ...
[21:31] <cjwatson> 2016-02-07 15:11:13 INFO    Failed to parse changes file '/srv/launchpad.net/ppa-queue/incoming/upload-ftp-20160207-151022-089181/~mbaynton/ubuntu/trafficserver/trafficserver_6.1.0-1_amd64.changes': Unable to find mandatory field 'Binary'
[21:31] <cjwatson>  in the changes file.
[21:32] <cjwatson> mbaynton1: Did you build this with dpkg-buildpackage or a wrapper around it, or did you construct the files by hand?
[21:32] <cjwatson> mbaynton1: It looks like maybe you initially tried to do a binary upload, and then hacked the file to try to make it into a source upload?
[21:33] <mbaynton1> cjwatson: thanks for finding that. Indeed; I read that "Binary" in .changes meant there were binaries, and when I got a message complaining about the presence of binaries, I removed it.
[21:33] <cjwatson> mbaynton1: OK, that's quite wrong
[21:34] <cjwatson> Binary lists the binary packages that a source upload may produce
[21:34] <mbaynton1> cjwatson: :| then https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Binary is not esepcially helpful; it seems to say that's what Binary in the .dsc does
[21:34] <cjwatson> mbaynton1: You're unlikely to be able to get this right by hacking the file around by hand unless you know the system well.  Instead, you should use dpkg-buildpackage -S
[21:35] <cjwatson> mbaynton1: That's entirely not what it says :)
[21:35] <cjwatson> Oh, under .changes
[21:35] <cjwatson> Well, maybe
[21:35] <cjwatson> Anyway, the point remains, don't hack the file around by hand, you don't need to
[21:35] <cjwatson> Just use dpkg-buildpackage -S
[21:35] <cjwatson> That will give you a _source.changes
[21:36] <mbaynton1> cjwatson: ok thank you, I will try that. I initially was using debian instructions and got a .deb that works fine there, and then afterward went aw heck, let's see if I can put it in an ubuntu ppa...
[21:36] <cjwatson> Also, I note that your earlier upload was targeted to unstable
[21:36] <cjwatson> (in debian/changelog)
[21:37] <cjwatson> If you don't want to change debian/changelog, this is one case (basically the only one) where it isn't terrible to hack .changes; you can build the package with dpkg-buildpackage -S, then edit the Distribution: line to name an Ubuntu series
[21:37] <cjwatson> Or you can have debian/changelog target an Ubuntu series instead, up to you
[21:38] <mbaynton1> cjwatson: got it
[21:39] <cjwatson> https://help.launchpad.net/Packaging/PPA/BuildingASourcePackage may be helpful
[21:39]  * cjwatson goes for some much-needed sofa and book time
[22:18] <mbaynton1> cjwatson: success, thanks again for the tips!
[23:13] <cjwatson> mbaynton1: good good