=== salem_ is now known as _salem === lutostag_ is now known as lutostag === maclin1 is now known as maclin [05:05] kees: "More general purpose registers on armv7 than i386" wins understatement of the year. [05:08] 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. === maclin1 is now known as maclin === maclin1 is now known as maclin === marlinc_ is now known as marlinc === _salem is now known as salem_ === salem_ is now known as _salem [13:34] infinity, kees: -mfpu=vfpv3-d16 is for floating point registers only [13:42] doko: I know what it means. ;) [13:43] but you argue as if these were general purpose registers ... [13:43] doko: armhf already violently abuses it to store function arguments in the vfp registers, PIE could pull similar tricks. [13:43] doko: (Not saying it does, saying it could) [16:35] Zta: does the upstream tarball contain a binary file? [16:56] 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] nacc: Yep. [17:53] infinity: ok, thanks! === nacc_ is now known as nacc === lifeless_ is now known as lifeless [19:44] 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] um, then there *is* an upstream tarball [19:45] Zta: even if you are making it, there is one when dpkg is building the package [19:46] 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] Urgh, I just wiped the entire working directory by accident. I might as well create a whole new Docker image then. [20:04] 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] Zta: wait, are you building in the tree first aand then running dpkg-buildpackage? [20:06] Hm, running dpkg-buildpackage -S -uc -us (with and without -nc) successively works. [20:07] 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] (Uh, I modified d/control inbetween) those two commands [20:07] Zta: once you create a source package, it doesn't really make sense to keep creating it [20:08] Ok. That's a one time thing? Even after I update the sources? [20:09] Zta: so your debian/ directory doesn't generally need to change because upstream changes [20:09] or, at least, not the whole thing [20:09] you'll wanto insert a new changelog entry referring to the new upstream [20:10] (and then dpkg-buildpackage will look for an appropriately named orig tarball in ..) [20:10] and if the upstream changes the dependencies, you'd update d/control, of ocurse [20:13] 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] Zta: dch [20:14] Zta: dch -i to insert (but note it won't detect the version correctly when you are bumping upstreams) [20:17] I tried to build the source package *with* signing, but it fails. I did make a gpg key though. [20:19] ah, nevermind gpg [20:19] ok [21:25] 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] 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] Oh no, it's some sort of Dropbox issue. That last URL should return 404 but it doens't. [21:46] Zta: sorry, was afk -- i dont have any experience with repos that aren't PPAs :) [21:47] nacc: They're really fun! More so if you use people.ubuntu.com! :P [21:47] Unit193: :) [21:48] Unit193: Perhaps I should look into that. Or there's always github or bitbucket. [21:50] Zta: That's not to say it can't be done in Dropbox. [21:50] Unit193: Can it? [21:51] Zta: I have never tried, but if you're using the Public/ folder, I don't see why not. [21:51] I'm using a shared link to a folder within Dropbox. [21:55] 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] Zta: i get a 404 for the InRelease file [21:59] nacc: It's a 404 page, without the 404 code, right. [22:00] oh fun [22:00] lame, 200 return code wrapping 404 [22:00] so dropbox = fail :) [22:01] I think so. But why does dpkg rely on a page to return 404? Why contact it to begin with? [22:01] it doesn't rely on it returning 404 [22:01] it's trying to read that page and it's giving bad data [22:01] apt* [22:01] *apt* is asking for that page to give the InRelease data [22:02] (dpkg doesn't talk to the network) [22:02] and that page, rather than reporting an error, is saying here's some garbage that wraps a 404 response code :) [22:02] but not actually expressing an error in the code [22:03] I don't have a file named InRelease in my generated repository. Is that a problem? [22:03] I presume you have Release and Release.gpg? [22:04] Release, yes. Release.gpg no. [22:05] iirc, InRelease can fail and it falls back to Release but Release needs to be signed (hence Release.gpg) [22:05] InRelease = signed inline release [22:05] 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] Okay, that all makes sense. I'll try signing it. Tomorrow. [22:06] Unit193: right, since the InRelease isn't saying 404, i think apt can't fallback correctly [22:06] Unit193: ah yes, I forgot about Trusted= :) [22:08] Zta: What are you using to create the repo? [22:08] Unit193: reprepo, i think [22:08] reprepro -b $ASEPRITE_DIST includedeb xenial $ASEPRITE_ROOT/*.deb [22:08] Ah, well in that case you should be able to configure a signing key and be done. [22:28] If only I could get sufficient entropy out of my Docker container =) [22:28] Zzz.. [22:53] (For public.u.c, I recommend 'lftp mirror') [22:58] 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] bug 1676547? [23:00] bug 1676547 in network-manager (Ubuntu) "No network connectivity after upgrade from 16.04 to 16.10" [Critical,In progress] https://launchpad.net/bugs/1676547 [23:01] We suspect a missing netplan policy snippet is at issue: there's no /etc/netplan/01-network-manager-all.yaml [23:03] Unit193: That looks like it could be the same bug. [23:08] 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] s/like/be interested/ [23:09] ahhhh [23:09] nacc: will be interesting to see the Debian response [23:10] though "cannot import" is certainly a less severe class of bug than "you want me to reconstitute what now?" [23:11] slangasek: yep