[05:05] <infinity> kees: "More general purpose registers on armv7 than i386" wins understatement of the year.
[05:08] <infinity> kees: And if the compiler's smart enough in the armhf case to see -mfpu=vfpv3-d16 and notice it's just been gifted another 16 registers on top of the 15 it already had to play with, whee.
[13:34] <doko> infinity, kees: -mfpu=vfpv3-d16 is for floating point registers only
[13:42] <infinity> doko: I know what it means. ;)
[13:43] <doko> but you argue as if these were general purpose registers ...
[13:43] <infinity> doko: armhf already violently abuses it to store function arguments in the vfp registers, PIE could pull similar tricks.
[13:43] <infinity> doko: (Not saying it does, saying it could)
[16:35] <nacc> Zta: does the upstream tarball contain a binary file?
[16:56] <nacc> infinity: for a bugfix for a package in zesty which has been fixed in debian, is it appropriate to upload for z the SRU version now (and similar for X and Y)? And then sync it immediately when AA opens?
[17:53] <infinity> nacc: Yep.
[17:53] <nacc> infinity: ok, thanks!
[19:44] <Zta> nacc: there's not upstream tarball; I'm cloning a git repo and then using dh_make to create the initial upstream tarball (?).
[19:44] <nacc> um, then there *is* an upstream tarball
[19:45] <nacc> Zta: even if you are making it, there is one when dpkg is building the package
[19:46] <Zta> Okay, just making sure we were (or I was) on the same page =).  I don't think there's a binary it in, but I'll check to make sure.
[19:48] <Zta> Urgh, I just wiped the entire working directory by accident.  I might as well create a whole new Docker image then.
[20:04] <Zta> I'm reading a little in the manpage of dpkg-buildpackage.  I'm currently running: dpkg-buildpackage -S -nc -d -uc -us    Maybe -nc is causing trouble with existing binaries?  Since it's not cleaning.
[20:06] <nacc> Zta: wait, are you building in the tree first aand then running dpkg-buildpackage?
[20:06] <Zta> Hm, running dpkg-buildpackage -S -uc -us (with and without -nc) successively works.
[20:07] <Zta> I've started from a clean clone of the source.  Then I ran  dh_make -s --createorig -p ${APP_NAME}_${APP_VERSION} -y   and now  the above.
[20:07] <Zta> (Uh, I modified d/control inbetween) those two commands
[20:07] <nacc> Zta: once you create a source package, it doesn't really make sense to keep creating it
[20:08] <Zta> Ok.  That's a one time thing?  Even after I update the sources?
[20:09] <nacc> Zta: so your debian/ directory doesn't generally need to change because upstream changes
[20:09] <nacc> or, at least, not the whole thing
[20:09] <nacc> you'll wanto insert a new changelog entry referring to the new upstream
[20:10] <nacc> (and then dpkg-buildpackage will look for an appropriately named orig tarball in ..)
[20:10] <nacc> and if the upstream changes the dependencies, you'd update d/control, of ocurse
[20:13] <Zta> Okay, makes sense.  Is there a dpkg-tool for adding a change log entry?  I see the first line in my current/changelog contains "aseprite (1.2-dev-master-6829b3d-1) unstable; urgency=medium"  That "-1" appended to my version is not mine, so I either have to be able read that from somewhere or "dh_addchlog".
[20:13] <nacc> Zta: dch
[20:14] <nacc> Zta: dch -i to insert (but note it won't detect the version correctly when you are bumping upstreams)
[20:17] <Zta> I tried to build the source package *with* signing, but it fails.  I did make a gpg key though.
[20:19] <Zta> ah, nevermind gpg
[20:19] <nacc> ok
[21:25] <Zta> nacc: Ok I have a .deb now, so I don't want to experiment with building a new version just now.  But perhaps you can help me with my next step: To setup a repository.  I've used reprepo to create this https://www.dropbox.com/sh/ppx2zr5gf2dx4rz/AAC7x0WK9sS1Xmn7sJjU9KgSa but when I add "deb https://www.dropbox.com/sh/ppx2zr5gf2dx4rz/AAC7x0WK9sS1Xmn7sJjU9KgSa xenial main" in my /etc/apt/sources.list.d/aseprite.list and run "apt update" I get: Clearsigned file 
[21:32] <Zta> E: Failed to fetch https://www.dropbox.com/sh/ppx2zr5gf2dx4rz/AAC7x0WK9sS1Xmn7sJjU9KgSa/dists/xenial/InRelease  Clearsigned file isn't valid, got 'NOSPLIT' (does the network require authentication?)
[21:37] <Zta> Oh no, it's some sort of Dropbox issue.  That last URL should return 404 but it doens't.
[21:46] <nacc> Zta: sorry, was afk -- i dont have any experience with repos that aren't PPAs :)
[21:47] <Unit193> nacc: They're really fun!  More so if you use people.ubuntu.com! :P
[21:47] <nacc> Unit193: :)
[21:48] <Zta> Unit193: Perhaps I should look into that.  Or there's always github or bitbucket.
[21:50] <Unit193> Zta: That's not to say it can't be done in Dropbox.
[21:50] <Zta> Unit193: Can it?
[21:51] <Unit193> Zta: I have never tried, but if you're using the Public/ folder, I don't see why not.
[21:51] <Zta> I'm using a shared link to a folder within Dropbox.
[21:55] <Zta> You can try out the above url if you like. I can't make it work.  But I think Dropbox is to blame because I don't get 404 when I should: https://askubuntu.com/a/475202/344227
[21:58] <nacc> Zta: i get a 404 for the InRelease file
[21:59] <Unit193> nacc: It's a 404 page, without the 404 code, right.
[22:00] <nacc> oh fun
[22:00] <nacc> lame, 200 return code wrapping 404
[22:00] <nacc> so dropbox = fail :)
[22:01] <Zta> I think so. But why does dpkg rely on a page to return 404?  Why contact it to begin with?
[22:01] <nacc> it doesn't rely on it returning 404
[22:01] <nacc> it's trying to read that page and it's giving bad data
[22:01] <Unit193> apt*
[22:01] <nacc> *apt* is asking for that page to give the InRelease data
[22:02] <nacc> (dpkg doesn't talk to the network)
[22:02] <nacc> and that page, rather than reporting an error, is saying here's some garbage that wraps a 404 response code :)
[22:02] <nacc> but not actually expressing an error in the code
[22:03] <Zta> I don't have a file named InRelease in my generated repository.  Is that a problem?
[22:03] <Unit193> I presume you have Release and Release.gpg?
[22:04] <Zta> Release, yes.  Release.gpg no.
[22:05] <nacc> iirc, InRelease can fail and it falls back to Release but Release needs to be signed (hence Release.gpg)
[22:05] <nacc> InRelease = signed inline release
[22:05] <Unit193> nacc: Well, pretty much.  You can cheat and have [Trusted=yes], but I wouldn't recommend it.  But yeah, InRelease will fall back (unless, 200...)
[22:06] <Zta> Okay, that all makes sense.  I'll try signing it.  Tomorrow.
[22:06] <nacc> Unit193: right, since the InRelease isn't saying 404, i think apt can't fallback correctly
[22:06] <nacc> Unit193: ah yes, I forgot about Trusted= :)
[22:08] <Unit193> Zta: What are you using to create the repo?
[22:08] <nacc> Unit193: reprepo, i think
[22:08] <Zta> reprepro -b $ASEPRITE_DIST includedeb xenial $ASEPRITE_ROOT/*.deb
[22:08] <Unit193> Ah, well in that case you should be able to configure a signing key and be done.
[22:28] <Zta> If only I could get sufficient entropy out of my Docker container =)
[22:28] <Zta> Zzz..
[22:53] <Unit193> (For public.u.c, I recommend 'lftp mirror')
[22:58] <dmj_s76> cyphermox: So, we're still testing, but we've gotten several reports of 16.04 -> 17.04 upgrades leaving ethernet unmanaged by network manager.
[23:00] <Unit193> bug 1676547?
[23:01] <dmj_s76> We suspect a missing netplan policy snippet is at issue: there's no /etc/netplan/01-network-manager-all.yaml
[23:03] <dmj_s76> Unit193: That looks like it could be the same bug.
[23:08] <nacc> slangasek: fun (non sequitur, apologies), but qemu 2.0.0+dfsg.orig.tar.xz apparently cannot be imported by `gbp import-orig` with pristine-tar: "pristine-xz failed to reproduce build" ... will report to debian, but thought you'd like to know :)
[23:09] <nacc> s/like/be interested/
[23:09] <slangasek> ahhhh
[23:09] <slangasek> nacc: will be interesting to see the Debian response
[23:10] <slangasek> though "cannot import" is certainly a less severe class of bug than "you want me to reconstitute what now?"
[23:11] <nacc> slangasek: yep