| === salem_ is now known as _salem | ||
| === lutostag_ is now known as lutostag | ||
| === maclin1 is now known as maclin | ||
| infinity | kees: "More general purpose registers on armv7 than i386" wins understatement of the year. | 05:05 |
|---|---|---|
| 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. | 05:08 |
| === 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 | ||
| doko | infinity, kees: -mfpu=vfpv3-d16 is for floating point registers only | 13:34 |
| infinity | doko: I know what it means. ;) | 13:42 |
| 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) | 13:43 |
| nacc | Zta: does the upstream tarball contain a binary file? | 16:35 |
| 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? | 16:56 |
| infinity | nacc: Yep. | 17:53 |
| nacc | infinity: ok, thanks! | 17:53 |
| === nacc_ is now known as nacc | ||
| === lifeless_ is now known as lifeless | ||
| 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:44 |
| nacc | Zta: even if you are making it, there is one when dpkg is building the package | 19:45 |
| 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:46 |
| Zta | Urgh, I just wiped the entire working directory by accident. I might as well create a whole new Docker image then. | 19:48 |
| 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:04 |
| 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:06 |
| 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:07 |
| Zta | Ok. That's a one time thing? Even after I update the sources? | 20:08 |
| 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:09 |
| 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:10 |
| 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:13 |
| nacc | Zta: dch -i to insert (but note it won't detect the version correctly when you are bumping upstreams) | 20:14 |
| Zta | I tried to build the source package *with* signing, but it fails. I did make a gpg key though. | 20:17 |
| Zta | ah, nevermind gpg | 20:19 |
| nacc | ok | 20:19 |
| 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:25 |
| 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:32 |
| Zta | Oh no, it's some sort of Dropbox issue. That last URL should return 404 but it doens't. | 21:37 |
| nacc | Zta: sorry, was afk -- i dont have any experience with repos that aren't PPAs :) | 21:46 |
| Unit193 | nacc: They're really fun! More so if you use people.ubuntu.com! :P | 21:47 |
| nacc | Unit193: :) | 21:47 |
| Zta | Unit193: Perhaps I should look into that. Or there's always github or bitbucket. | 21:48 |
| Unit193 | Zta: That's not to say it can't be done in Dropbox. | 21:50 |
| Zta | Unit193: Can it? | 21:50 |
| 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:51 |
| 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:55 |
| nacc | Zta: i get a 404 for the InRelease file | 21:58 |
| Unit193 | nacc: It's a 404 page, without the 404 code, right. | 21:59 |
| nacc | oh fun | 22:00 |
| nacc | lame, 200 return code wrapping 404 | 22:00 |
| nacc | so dropbox = fail :) | 22:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| Zta | Release, yes. Release.gpg no. | 22:04 |
| 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:05 |
| 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:06 |
| 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:08 |
| Zta | If only I could get sufficient entropy out of my Docker container =) | 22:28 |
| Zta | Zzz.. | 22:28 |
| Unit193 | (For public.u.c, I recommend 'lftp mirror') | 22:53 |
| 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. | 22:58 |
| Unit193 | bug 1676547? | 23:00 |
| ubottu | 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:00 |
| dmj_s76 | We suspect a missing netplan policy snippet is at issue: there's no /etc/netplan/01-network-manager-all.yaml | 23:01 |
| dmj_s76 | Unit193: That looks like it could be the same bug. | 23:03 |
| 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:08 |
| nacc | s/like/be interested/ | 23:09 |
| slangasek | ahhhh | 23:09 |
| slangasek | nacc: will be interesting to see the Debian response | 23:09 |
| slangasek | though "cannot import" is certainly a less severe class of bug than "you want me to reconstitute what now?" | 23:10 |
| nacc | slangasek: yep | 23:11 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!