[00:06] cyphermox: Whoops, got carried away doing something else, running that now. [00:07] THERE we go. [00:07] * tsimonq2 digs [00:08] cyphermox: Want to see this log? [00:08] Because like I said, acting normally. [00:08] tsimonq2: not especially [00:08] tsimonq2: just kidding, yes please [00:08] send it via email or put it in a bug [00:09] there might be some gems there; probably something about DNSSEC not being happy [00:09] cyphermox: lol ok [00:19] cyphermox: You has mail. [00:27] what did you dig for, just so I know where to look? [00:30] cyphermox: www.google.com [00:40] tsimonq2: I can't see it here; could you please start again but this time query for 'www.perdu.com' ? [00:40] cyphermox: Ok. [00:41] that's a test page that is easily recognizable in text; google turns up way too often on its own in normal use in logs like this [00:41] sorry for the trouble [00:41] It's totally fine, I'm sorry that I'm putting you though log searching >__< [00:43] cyphermox: You want the full log or just the excerpt from digging? [00:43] as little as possible is best, but it's easy to miss some important bits, so if you sent the entire thing I'll manage [00:44] that's where knowing what to search for exactly helps a lot [00:44] Ok. [00:45] cyphermox: Get my email? [00:46] yup [00:46] Yay ok [00:48] and it successfully returned 208.97.177.124 ? [00:48] Yup [00:48] so firefox should also be happy if resolv.conf was set to point to 127.0.0.53 [00:48] ;; ANSWER SECTION: [00:48] www.perdu.com. 13909 IN A 208.97.177.124 [00:49] (or libnss-resolved is installed and nsswitch points to the right place) [00:50] tsimonq2: nothing looks out of place [00:50] cyphermox: That's super weird. If you give me a sec, I can repeat with a fresh reboot when it's an issue. [00:51] tsimonq2: when you get the issue again, try 'systemd-resolve $url' with the same thing you tried to open (the hostname, anyway) [00:51] if that succeeds, then try again with something else like www.verisign.com (which I expect should be DNSSEC capable, but you don't go hit every day) [00:53] and put all of this in a bug... I don't see what's up right now [00:53] cyphermox: Ok. [00:53] * tsimonq2 is on phone [00:56] cyphermox: Alright, reproducable now. Can't systemd-resolve either vps.tsimonq2.net or www.verisign.com [00:57] Wait, wrong wording there. It's a bug now... [00:58] the exact answer to systemd-resolve is important [00:58] but yeah, they should probably resolve, it's just that /how/ they don't tells us what's broken [00:58] Got it. [00:59] and I'm sure it's still DNSSEC, it's the only thing that is consistently horrible [00:59] Going though the same steps to collect logs as you told me before. [01:18] cyphermox: Sent you one last set of logs. It would be wonderful if you could tell me what would be relevant to put in the bug report, but I totally understand if you don't have the time tonight. [01:28] tsimonq2: that is a representative sample [01:29] the key here is Timeout, and it's not something I've seen before [01:32] cyphermox: Oooooh ok [01:32] cyphermox: So what about my system could be Special? [01:53] no idea [01:53] timeouts are most often an environment issue, but it could also not be. [01:56] Ok. === _salem is now known as salem_ [02:47] (Belldandu) So i would like to submit a dependency fix for postfixadmin but i'm not even able to branch of the code in order to propose a merge. This problem hasn't been fixed for 3 years from trusty all the way to the latest ubuntu https://bugs.launchpad.net/ubuntu/+source/postfixadmin/+bug/1321955 [02:47] Launchpad bug 1321955 in postfixadmin (Ubuntu) "postfixadmin dependencies not well defined (requires mysql-server or postgresql, removes MariaDB)" [Undecided,In progress] [02:48] The fix is so miniscule its depressing that it hasnt been fixed [02:50] Change debconf depency line mysql-client | pgsql-client to mysql-client | pgswl-client | mariadb-client [02:50] pgsql-client* [02:51] Belldandu: Looks already fixed in zesty [02:52] in zesty and none of the other branches. Not everyone is going to use zesty [02:52] Im using xenial for instance [02:52] Belldandu: Sure. So just attach the debian/control diff and subscribe ubuntu-sponsors. [02:53] Belldandu: For xenial and yakkety. And maybe backport the fix to trusty too, if you're feeling keen. [02:53] Ok [02:53] Looks like trusty also needs this fix to close the original bug: [02:53] * [76ef] change recommends of postgresql-server (not existing) to postgresql. [02:54] While xenial and yakkety only need: [02:54] * update dependencies to allow mariadb as database (closes: #778794) [02:54] Belldandu: As for "branching for an MP", UDD is long dead. Just "pull-lp-source postfixadmin $release" and hack on the package that way. [02:55] Yeah and ok [02:57] hey, I want to sign the contributor agreement. It asks me for a "Project contact (Please add the Canonical Project Manager or contact)". What can I put there? [02:57] I just want to send a PR to https://github.com/snapcore/snapcraft [02:58] onthewings: https://www.canonical.com/projects/directory lists the contacts for each CLA-using project. [02:59] wow, I've never seen that before [02:59] infinity: A while ago we talked about 'automatic' backports of geoip-database, anything new on that? Also was starting to wonder about publicsuffix too. [02:59] Unit193: I doubt I used the word automatic. ;) [02:59] You did not, it's also in 'quotes'! Not sure to call it a backport or SRU, it's rather neither. [03:00] Unit193: Well, it's an SRU by definition. It just might need different rules, like tzdata and a few others. [03:01] infinity: Right, and you had said something about it being discussed, considered, or thereabouts. [03:01] Unit193: I suspect that we then failed to discuss it. And for a long while, given I don't really remember the original. ;) [03:02] Unit193: Step 1 would be to find someone (or a group of someones) willing to take responsiblity for said updates. From there, working up a sane policy and making it happen shouldn't be too much effort. [03:02] Ah, alright. I've been using backportpackage on it for a few releases now, so doesn't directly affect me. But that's not really a solution. [03:03] It's a solution, just not the most community-friendly one. :P [03:04] (And we're all guilty of it... The joy of open source is being able to fix things locally, the burden/responsibility is that we shouldn't be fixing locally because that's selfish) [03:04] It's one for meeeee. ;D [03:04] Which I totally do far too often. [03:04] And tend to forget and discover 2 years later on an LTS upgrade when something breaks and I go "oh, huh, I never uploaded that?" [03:05] Like that sbuild thing. :P [03:05] 'virtualbox-ext-pack', 'youtube-dl', 'geoip-database' are a few, but then 'whois', 'publicsuffix' and a few others are starting to get the same treatment. :3 [03:06] *I* am even guilty of *that* :P [03:06] Unit193: whois is a bad example, unless someone breaks the data out from the code. [03:06] Unit193: tzdata is in a good place there, as upstream tries very hard to decouple data and code, and we just update the data. [03:07] infinity: Perhaps yes, I haven't been backporting that. And yeah, that's one db that does get updated, the mobile data does too IIRC. [03:07] wireless-crda is on the list, yeah. [03:07] The kernel team was meant to start loving that, but I think we fell down in the final steps of JFDIing that. [03:08] Err, wireless-regdb, I mean. [03:08] Whatever. "the wireless thing". [03:08] usb-modeswitch-data? mobile-broadband-provider-info? I dunno, one of those. [03:09] Unit193: If you have a certain passionate interest in this, I suggest that post-release (I'm only awake at 4am because release week, so clearly a bit too busy to multitask on this), you bring it up again, with a broad enough audience to also work on getting volunteers to own the various updates. [03:10] Perhaps a nice bullet list of "* package : owner", and fill in the blanks until it looks less unpleasant. [03:10] I certainly have a vested interest in this, though not entirely sure I want to drive it as my current solution is much easier without outside help. :3 [03:10] The only ones I know we do reasonably well at are "tzdata: glibc maintainers" and "pciutils: kernel team" [03:10] infinity: Side note, I thought you were in Canada? Where are you that it's 4 AM? [03:10] tsimonq2: London. [03:11] infinity: Fancy. You move there or just there for now? [03:11] Just sprinting. [03:11] Ah, gotcha. [03:11] I'd move here if I could afford it. [03:11] It *does* seem like a wonderful place. [03:11] But my Calgary flat would cost about 3M pounds in a similar size and location here. [03:11] Which is a bit out of my range. [03:11] Eeek. Yeah. [03:13] infinity: I could bring it up, but guessing it'd have to be on -discuss. [03:13] Right, (hopefully actually final) rebuilds kicked off. I need to get some sleep before morning attacks. [03:13] Sleep well infinity. [03:13] G'night. [03:13] infinity: anything that needs babysitting? I'll be up for another 2-3 hours I expect [03:13] Unit193: Yeah. I do a crap job of reading devel/devel-discuss, so if you do bring it up and want my input in the thread, please explicitly CC me. [03:14] stgraber: I guess just make sure none of the builds go missing? Should be 20170412 spitting out for $world over the next couple of hours. [03:14] infinity: ok, will check the tracker before I go to bed and track down anything that didn't update [03:15] infinity: It's email, so it may take me a few months to get to it, but I'll put it on the todo. :P [03:15] Unit193: Heh. [03:15] stgraber: Ta. [03:18] (I'm not kidding, sadly.) infinity: Thanks! [03:23] Unit193: I didn't assume you were. My INBOX has unread messages older than some of our contributors. [03:23] Unit193: And I don't mean "older than their contributions", I literally mean older than the people. [03:23] Haha! \o/ [03:23] * infinity -> bed. [03:23] So I've got time. [03:26] better get started on that email a dozen years ago if you want in on his todo list :) === salem_ is now known as _salem [03:32] I've actually got a message from 3 years ago I haven't responded to yet, and gotta do something about a message from 07/09/2016 >_> [03:32] Belldandu: ping [04:16] jbicha: looks like a fresh install works with shell here; so this smells like a packaging issue [04:17] gdm3 starts fine at boot, so does shell, etc. [04:17] I'm going to bed now but we could look at this some more when I'm back to debug it. === _salem is now known as salem_ === salem_ is now known as _salem === CRogers_________ is now known as CRogers === morphis_ is now known as morphis [11:56] seb128: hey! Just in case - I poked around a bit and got the zesty language stats exported, also pushed a change to l-o-m to now look for them in the proper location [11:56] seb128: i.e. http://people.canonical.com/~people-l10n/data/ubuntu-l10n/ [11:56] seb128: (for future langpack generation) [11:59] sil2100, nice, thanks [11:59] is that a new team¿ [11:59] ? [11:59] seb128: not new new, dpm requested its creation when he was leaving [12:00] So it was around for a bit but no one actually informed us I guess [12:34] Mirv, is there something that should ensure that appmenu-qt5 is removed? [12:36] ginggs: It's very not removed here. Should it be? [12:36] Oh, I see, it's not in zesty anymore. [12:38] it seems to cause problems if it is not removed, see LP: #1680943 [12:38] Launchpad bug 1680943 in telegram-desktop (Ubuntu) "telegram-desktop's window never shows up (differently from Debian's sid)" [Undecided,Confirmed] https://launchpad.net/bugs/1680943 [12:39] ginggs: Fun. [12:39] ginggs: So, a do-release-upgrade will probably offer to remove it. But all of us who have been tracking zesty will still have it installed. [12:40] ginggs: Ideally, some other Qt component should Conflict/Replace it. [12:40] (But not going to let that land between now and release either) === _salem is now known as salem_ === salem_ is now known as _salem === _salem is now known as salem_ [14:50] ginggs: it could be useful, yes, now that replacing functionality is in Qt 5.7 [16:43] How does one create a .deb out of, say, nothing? I do have some source code, but none of the tools I use work. All tools and tutorials require some weird structure beforehand. [16:45] Zta: do you want a 'good' .deb or just something 'good enough' ? [16:45] Zta: dh_make creates that structure [16:45] Zta: like something you can submit for inclusion or put in a ppa? [16:45] Zta: if you just need something locally, you can use checkinstall [16:46] nacc: Let's start with something 'good enough'. [16:46] Actually, I'm trying to make a package out of this: https://github.com/aseprite/aseprite/blob/master/INSTALL.md#platforms [16:46] Zta: but for creating a true source package, you'll need to go down the path of what jtaylor suggested [16:46] It uses ninja for build system. This might be what's confusing the debhelpers? [16:46] via cmake? [16:46] Zta: have no idea what your d/rules says, etc [16:46] At worst, that's just a matter of a couple of overrides. [16:46] Zta: maybe just make a snap [16:47] dh_make fails [16:47] debhelper can work with anything. [16:47] You'll probably do best if you pastebin terminal transcripts showing what's going wrong [16:48] yes sir, hold on [16:56] https://pastebin.com/zz4wmrjt [16:57] oh wait, -p aseprite_123 does something good [16:57] cd ..; mv aseprite aseprite-123; cd -; dh_make [16:57] or similar [16:57] that's what it's telling you [16:57] but yes, -p aseprite_123 would work too [16:57] (and is probably better, actually, so do that) [16:58] (note the _ vs. - ) [17:02] nacc: exactly, I just noticed that now. That's been bugging me for hours now =) [17:03] Zta: yeah, it's a bit hard to detect that difference if you aren't looking for it :) [17:05] Is there a tool to edit the debian/control file programmatically? (besides sed =) [17:05] Zta: vi ? [17:05] Zta: not sure what you mean, i guess :) [17:05] Zta: it's just a text file, i mean [17:07] I mean now dh_make generated a neat skeleton. Now I want to edit some of the fields like dh_editcontrol --homepage "http://aseprite.org" --section "universe/graphics" [17:07] Zta: right, just use an editor [17:07] I'm trying to script this, so vi isn't an option =). Right, sed it is. [17:07] Zta: i don't believe there is a helper command to edit d/control -- seems like overkill to me :) [17:08] Zta: why are you scripting it? [17:08] Zta: once you build a source package, you don't need to do it again [17:08] Zta: alternatively, like i said, you coudl snap it and it might be a bit faster [17:08] Yes I do, because it source code gets updated. [17:08] Zta: uscan/uupdate handle tht [17:08] Zta: the packaging is distinct from the upstream [17:08] debian/control usually doesn't change on every upstream change [17:09] there is cme if you want to automate though [17:09] Zta: given a good d/watch file [17:09] cjwatson: interesting, i hadn't seen that before, thanks! [17:09] (though personally I find cme way too complex and don't bother) [17:09] Ideally, I create a cronjob that pulls, builds, and reinstalls. Or a docker image that serves a PPA? [17:10] Zta: right, that's a recipe in launchpad (I think) [17:10] Zta: a git recipe, in this case [17:10] Zta: and you'd keep your debian/ in another repo (aiui) which just has the packaging stuff [17:10] https://help.launchpad.net/Packaging/SourceBuilds [17:10] Zta: and the two get combined (magic!) and your package builds [17:11] Zta: but the point is debian/control doesn't really change on every upstream change (necessarily at least) -- only if deps change or whatever. d/changelog will update with the new version [17:11] and debian/changelog updates are scriptable using dch [17:12] It's not my code, so I can't put it into Launchpad. [17:14] Hm, I was expecting dh_make to generate a better Depends list. [17:14] Look at this: https://pastebin.com/HY4Nmkkr [17:15] uh [17:16] i think you're missing something in all of this [17:16] dh_make just generates a skeleton [17:16] Zta: do you undrestand the difference between a source and binary package? [17:16] This is where I actually started. Then I came to the conclusion that he manual dependency lookup was ... wrong. So I started looking at dh_make. But that doesn't really seem to generate a complete Depends list. [17:16] it's not expected to write your Depends for you [17:16] Zta: dh_make sets up the skeleton of a source package for you, nothing else [17:16] Zta: and it doesn't build anything (which is what generates thea ctual depends in the binary package) [17:17] you should regard debian/ as a chunk of code that you need to maintain on an ongoing basis [17:17] it is not a thing you should be trying to generate for each upstream commit you want to build [17:17] Zta: iirc, launchpad can import a github repository [17:17] and writing anything under DEBIAN/ by hand is a red flag that you are doing something fundamentally wrong [17:18] cjwatson: The DEBIAN/ thing was from a tutorial. It could be outdated, I don't know. Is it better to write stuff in debian/ by hand? [17:18] Zta: DEBIAN and debian are different [17:18] dh_make should generate a thing that uses dh to do the build; when you build the binary packages, that'll end up calling dh_shlibdeps somewhere, and dh_shlibdeps substitutes package dependencies corresponding to your ELF dependencies where you write ${shlibs:Depends} in debian/control [17:19] yes, debian/* should be written by hand (perhaps starting from a skeleton generated by something like dh_make) [17:19] nacc: I won't do that. The auther of this code doesn't want anyone to distribute it. It's open source, but you have to buy it or compile it *yourself*. That's the deal. [17:19] DEBIAN/* should only be touched by tools called (eventually) from debian/rules, which is the entry point of the source package [17:19] cjwatson: Makes sense. [17:20] if you find any tutorial that recommends writing files in DEBIAN/* directly, throw it in the bin and look for a better tutorial [17:20] Right. [17:20] i bet that is an interestingly worded license agreement [17:20] Zta: except you are breaking that rule by building packages at all then [17:20] Zta: so screw that and just do it the easier way :) [17:20] Ok, so I have a skeleton for my source package now. [17:21] nacc: I think I'm allow to distribute my own build it to myself =) [17:21] right, that's all the recipe would do too (just in a ppa) [17:21] you can make the ppa private [17:21] hmm [17:22] nacc: that's a paid feature [17:22] cjwatson: ah :( [17:22] Zta: so nm :) [17:22] much though I'm a Launchpad developer, I think getting into recipes for this is too much of a rat-hole for now [17:23] cjwatson: you might be right [17:23] =) [17:23] and you have to write the packaging anyway [17:23] i'm curious what software this is [17:23] sprite editor [17:23] Zta: ok, so you've got the skeleton, so now you need to modify d/ files [17:23] Think GIMP for kids 8) [17:24] GIMP for 8bit gamers [17:24] Zta: this has some rough guidelines iirc, for dh_make workflow: https://www.debian.org/doc/manuals/maint-guide/first.en.html [17:24] Zta: but once you do it once, you don't throw it away [17:24] Zta: you keep that as your source package and then do updates to it as needed [17:25] It's the Depends section that made me look into this whole mess. The script I pasted before actually create a package that Works On My Machine. [17:25] Zta: right, but as cjwatson said, that script is bunk :) [17:26] Zta: it seems to be pretending that debhelper doesn't exist to do all this for you (e.g. dh-shlibdeps) [17:26] err, dh_shlibdeps [17:27] so just looking at my packages, here's one that's a compromise between being so simple that it doesn't help you learn much, and far too complex: https://anonscm.debian.org/cgit/pkg-man-db/man-db.git/tree/debian [17:27] debian/control has ${shlibs:Depends}, ${misc:Depends}, which are filled in by various debhelper tools, and also some manually inserted dependencies [17:27] debian/rules has override_* targets in cases where the defaults don't work [17:28] or a simpler case, https://anonscm.debian.org/cgit/users/cjwatson/dumpet.git/tree/debian [17:30] the simplest possible cases can have a three-line debian/rules [17:30] anyway, must get a train [17:36] Take the A train. [17:37] That debian/rules looks complex =\ [17:40] Zta: so d/rules can generally be left alone, it will just end up calling make (presuming that works) -- so i'd change that last, on some level [17:40] Should I use some debhelper tool to issue the actual compiling? Or is it okay to do that myself and install the binaries in a package dir that's then wrapped up? [17:40] debuild [17:41] Zta: i would recommend using one of debuild, dpkg-buildpackage and sbuild. I find it easiest personally to generate a source packge with dpkg-buildpackage and then sbuild that (so i don't mess with my host system) [17:41] I'd prefer not to mess with my host system. [17:42] sbuild for sure [17:42] Zta: yeah, so get your code in good shape [17:42] but you still need to debuild -S to generate the source package on host [17:42] yep [17:42] or you can try to build the source pkg inside sbuild too, but it's a bit of a pain [17:42] which is just (aiui), dpkg-buildpackage -S [17:42] This doesn't fit well with this weird ninja build system. [17:42] with a few extra commands [17:42] Zta: what do you mean? [17:44] My build instructions say: mkdir BUILD ; cd BUILD ; cmake -G Ninja .. This will generate build files in ./ (being BUILD). Then I should issue the actual build: ninja asprite [17:44] ok, then add a build-depends on ninja-build and run that command in an appropriate override [17:45] sounds easy [17:45] how? =) [17:45] well you likely don't have to use ninja, and debhelper already supports cmake natively [17:45] cmake works out of the box with make too, if you don't need the extra speed debhelper defaults should be fine [17:45] yeah i can't tell if you need ninja or not [17:45] the ninja speed is not important for package builds anyway [17:45] its more useful for partial rebuilds [17:45] aka development [17:45] i undrestand their instructions say to use it, but i'd try it wihtout and see what works [17:46] my guess is `make install` will dtrt and ninja is purely there for speed [17:50] Well, it seems I have to do something, because running plain dpkg-buildpackage fails: https://pastebin.com/dssCzckH [17:50] Zta: well, as we said [17:51] Zta: you want to use -S [17:51] Zta: build a source package and then build the binary using sbuild or so [17:51] sorry, I'm downing in info =) [17:51] Zta: yes, there's a lot to take in [17:51] nacc: well it will still fail with the same error [17:51] nacc: since that's trying to build the source package first [17:51] dobey: yeah, i hadn't looked at the details yet :) [17:52] Zta: ok, so it ooks like dpkg-buildpackage is seeing local changes relative to the orig tarball you used [17:52] I didn't use a tarball; i checkout out from git. [17:52] Zta: that is, it looking at the contents of aseprite_1.2-dev-master-fece0cf.orig.tar.xz [17:52] Zta: yes, that's not how deb building works [17:53] urgh.. [17:53] Zta: in that, as on the debian guide linked earlier [17:53] Zta: there is an orig tarball and a debian tarball used to build [17:53] * nacc also reiterates that a snap would probably be way faster for this [17:54] My original question: (18:43:33) Zta: How does one create a .deb out of, say, nothing? I do have some source code, but none of the tools I use work. All tools and tutorials require some weird structure beforehand. [17:54] =) [17:54] Zta: yep, did you read the debian packaging guide i linked? [17:54] Zta: that gives you a lot of inofrmation, but i think it's necessary so you understand how building works [17:55] I saw it mentiond a tar.gz a couple of times and assumed it wasn't meant for me, since I'm not in that situation. I really hoped it would be able to build off a directory, say and extracted tarball. [17:56] Zta: where did ./aseprite_1.2-dev-master-fece0cf.tar.xz come form? [17:56] *from [17:56] Zta: no, that's not how building works [17:57] I have no idea. For what I know it doesn't exist. I did define that name and version when running dh_make, though. [17:57] look in the current directory [17:57] no such file. [17:57] Oh, there's one in .. [17:57] ~/asperite-workdir/aseprite I guess [17:58] ah yeah it'll be in ../ sorry [17:58] Ok, so that's what took so long. dh_make wrapped up the entire dir? Ok, so I have a tarball. [17:59] Zta: yes, see 'ACTIONS PERFORMED' in `man dh_make` [18:00] Right. [18:01] because non-native package building needs an orig tarball and a debian tarball [18:01] Wait... I have my workdir. Here I have aseprite/ which is cloned. Should I run dh_make (ie. have my debian dir) in the workdir or in the aseprite dir? [18:03] Zta: i don't know what you mean by "have my debian dir" [18:03] Zta: dh_make is used to generate a debian/ directory [18:03] that's the directory I mean. [18:04] you would run it from aseprite/, afaict [18:04] should it be workdir/debian/ or workdir/aseprite/debian/ ? [18:04] ok [18:04] so the latter [18:04] And the tarball magically ends up in workdir. [18:06] yes, because all the tooling needs it to be in ../ relative to where you run the build from [18:06] (even for source package builds) [18:08] Zta: so basically, what dh_make did was it tarred up the current directory as it was (since no -f was given) and put it in ../orig.tar.xz [18:09] Zta: so that it can track what you change relative to the 'pristine' upstream [18:09] yes [18:10] and every change to the upstream source must be stored as a patch in the debian/patches directory (for quilt-based packages) [18:10] and then your packaging decisions go in debian/ which will be tarred up by dpkg-buildpackage into ../debian.tar.xz [18:10] But the upstream is already outdated because it has the skeleton debian/control file. [18:11] upstream does *not* have a d/control file [18:11] https://github.com/aseprite/aseprite [18:11] no debian/ directory [18:11] dh_make just created one [18:11] dh_make did the tarring *before* creating debian [18:11] oh [18:11] as i said earlier [18:12] or it excludes debian/ i'm not sure (effect is the same) [18:12] It first compresses, then it generates. [18:12] ok [18:13] well, you can see in the log from dpkg-buildpackage (there's a file referenced) what the changes it is detecting are [18:13] dh_make also won't execute if a debian/ dir or the ../tarball exists is seems =) [18:14] well if ../tarball exists, you should use -f [18:14] and yeah, dh_make is for making a new skeleton [18:14] doesn't make sense torun it if you have a debian/ [18:14] I deleted both so I could retry. [18:20] Ah, dpkg-buildpackage -S fails because if signing: No secret key [18:20] Zta: try [18:20] dpkg-buildpackage -S -nc -d -uc -us [18:21] the last two say don't sign [18:21] -nc says don't clean (can be handy while you iterate) [18:21] and -d says don't worry about builddeps here [18:21] since you are (hopefully) going to use sbuild to build, and the builddeps will get satisfied there [18:22] no errors, exit code 0. That must mean success. [18:22] right so go into the parent directory [18:22] you should see an appropriately named .dsc file [18:22] and a _changes file, iirc [18:23] yes [18:24] Zta: then you can pass those to sbuild (after having set up a sbuild environment locally (see mk-sbuild) [18:25] Do I need both mk-sbuild and sbuild? [18:25] mk-sbuild is from ubuntu-dev-tools [18:26] mk-sbuild is by far the easiest way to make the schroots that sbuild will use [18:27] yeah, that's what i was just checking on [18:27] Zta: i would use mk-sbuild, just to be sure you do it right :) [18:27] have you seen this yet/ https://wiki.ubuntu.com/SimpleSbuild [18:27] sarnold: thanks, was just pulling that up [18:27] sudo apt install ubuntu-dev-tools --no-install-recommends it is === nacc is now known as Guest42667 === nacc_ is now known as nacc [18:40] How much of those instructions on SimpleSbuild should I go though? [18:41] I feel it's building an entire ubuntu distriution right now =) [18:41] Zta: it is [18:41] Zta: in a schroot [18:41] that's how you build in an environment that doens't affect your host [18:42] .. and so your host environment doesn't affect your build :) [18:42] (of course the running kernel affects the build, but these day's that's usually not a big deal) [18:42] sarnold: good point! :) [18:43] ...Docker seems less intrusive [18:45] docker and lxd can also be used, but they aren't so directly integrated [18:45] meaning you have to wrap commands in commands to build in them, afaict [18:49] Done building zesty-amd64! [18:49] I'm on xenial, though. Is that a problem? =\ [18:50] Zta: not necessarily [18:51] Zta: so you need to have an sbuild environemnt suitable for building your package for the release you want to target [18:51] Zta: so in you case, you probably wanted to run `mk-sbuild xenial` if you want a .deb for xenial [18:52] The tutorial learned me a nice command: sg sbuild I've been missing that some times. [19:08] So I'm here and I ran this: ~/aseprite-workdir/aseprite$ sbuild -A -d xenial-amd64 --host ../*.dsc [19:08] and I get: E: Failed to open build log /home/stephan/.ubuntu-sbuild/logs/aseprite_1.2-dev-master-fece0cf-1_../aseprite_1.2-dev-master-fece0cf-1.dsc-20170412-2102.build: No such file or directory [19:09] try mkdir -p /home/stephan/.ubuntu-sbuild/logs and try again? [19:10] Zta: yeah, i think you're missing some .sbuildrc values [19:10] Zta: this is what i use locally: http://paste.ubuntu.com/24369306/ [19:15] The dirs are all there, and that paste doesn't help. But that path in the error message looks bad with those ".." in the middle. Did I execute toe sbuild properly? [19:15]