[00:06] <tsimonq2> cyphermox: Whoops, got carried away doing something else, running that now.
[00:07] <tsimonq2> THERE we go.
[00:07]  * tsimonq2 digs
[00:08] <tsimonq2> cyphermox: Want to see this log?
[00:08] <tsimonq2> Because like I said, acting normally.
[00:08] <cyphermox> tsimonq2: not especially
[00:08] <cyphermox> tsimonq2: just kidding, yes please
[00:08] <cyphermox> send it via email or put it in a bug
[00:09] <cyphermox> there might be some gems there; probably something about DNSSEC not being happy
[00:09] <tsimonq2> cyphermox: lol ok
[00:19] <tsimonq2> cyphermox: You has mail.
[00:27] <cyphermox> what did you dig for, just so I know where to look?
[00:30] <tsimonq2> cyphermox: www.google.com
[00:40] <cyphermox> tsimonq2: I can't see it here; could you please start again but this time query for 'www.perdu.com' ?
[00:40] <tsimonq2> cyphermox: Ok.
[00:41] <cyphermox> 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] <cyphermox> sorry for the trouble
[00:41] <tsimonq2> It's totally fine, I'm sorry that I'm putting you though log searching >__<
[00:43] <tsimonq2> cyphermox: You want the full log or just the excerpt from digging?
[00:43] <cyphermox> 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] <cyphermox> that's where knowing what to search for exactly helps a lot
[00:44] <tsimonq2> Ok.
[00:45] <tsimonq2> cyphermox: Get my email?
[00:46] <cyphermox> yup
[00:46] <tsimonq2> Yay ok
[00:48] <cyphermox> and it successfully returned 208.97.177.124 ?
[00:48] <tsimonq2> Yup
[00:48] <cyphermox> so firefox should also be happy if resolv.conf was set to point to 127.0.0.53
[00:48] <tsimonq2> ;; ANSWER SECTION:
[00:48] <tsimonq2> www.perdu.com.          13909   IN      A       208.97.177.124
[00:49] <cyphermox> (or libnss-resolved is installed and nsswitch points to the right place)
[00:50] <cyphermox> tsimonq2: nothing looks out of place
[00:50] <tsimonq2> 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] <cyphermox> tsimonq2: when you get the issue again, try 'systemd-resolve $url' with the same thing you tried to open (the hostname, anyway)
[00:51] <cyphermox> 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] <cyphermox> and put all of this in a bug... I don't see what's up right now
[00:53] <tsimonq2> cyphermox: Ok.
[00:53]  * tsimonq2 is on phone
[00:56] <tsimonq2> cyphermox: Alright, reproducable now. Can't systemd-resolve either vps.tsimonq2.net or www.verisign.com
[00:57] <tsimonq2> Wait, wrong wording there. It's a bug now...
[00:58] <cyphermox> the exact answer to systemd-resolve is important
[00:58] <cyphermox> but yeah, they should probably resolve, it's just that /how/ they don't tells us what's broken
[00:58] <tsimonq2> Got it.
[00:59] <cyphermox> and I'm sure it's still DNSSEC, it's the only thing that is consistently horrible
[00:59] <tsimonq2> Going though the same steps to collect logs as you told me before.
[01:18] <tsimonq2> 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] <cyphermox> tsimonq2: that is a representative sample
[01:29] <cyphermox> the key here is Timeout, and it's not something I've seen before
[01:32] <tsimonq2> cyphermox: Oooooh ok
[01:32] <tsimonq2> cyphermox: So what about my system could be Special?
[01:53] <cyphermox> no idea
[01:53] <cyphermox> timeouts are most often an environment issue, but it could also not be.
[01:56] <tsimonq2> Ok.
[02:47] <Belldandu> (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:48] <Belldandu> The fix is so miniscule its depressing that it hasnt been fixed
[02:50] <Belldandu> Change debconf depency line mysql-client | pgsql-client to mysql-client | pgswl-client | mariadb-client
[02:50] <Belldandu> pgsql-client*
[02:51] <infinity> Belldandu: Looks already fixed in zesty
[02:52] <Belldandu> in zesty and none of the other branches. Not everyone is going to use zesty
[02:52] <Belldandu> Im using xenial for instance
[02:52] <infinity> Belldandu: Sure.  So just attach the debian/control diff and subscribe ubuntu-sponsors.
[02:53] <infinity> Belldandu: For xenial and yakkety.   And maybe backport the fix to trusty too, if you're feeling keen.
[02:53] <Belldandu> Ok
[02:53] <infinity> Looks like trusty also needs this fix to close the original bug:
[02:53] <infinity>   * [76ef] change recommends of postgresql-server (not existing) to postgresql.
[02:54] <infinity> While xenial and yakkety only need:
[02:54] <infinity>   * update dependencies to allow mariadb as database (closes: #778794)
[02:54] <infinity> 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] <Belldandu> Yeah and ok
[02:57] <onthewings> 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] <onthewings> I just want to send a PR to https://github.com/snapcore/snapcraft
[02:58] <infinity> onthewings: https://www.canonical.com/projects/directory lists the contacts for each CLA-using project.
[02:59] <sarnold> wow, I've never seen that before
[02:59] <Unit193> 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] <infinity> Unit193: I doubt I used the word automatic. ;)
[02:59] <Unit193> You did not, it's also in 'quotes'!  Not sure to call it a backport or SRU, it's rather neither.
[03:00] <infinity> Unit193: Well, it's an SRU by definition.  It just might need different rules, like tzdata and a few others.
[03:01] <Unit193> infinity: Right, and you had said something about it being discussed, considered, or thereabouts.
[03:01] <infinity> 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] <infinity> 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] <Unit193> 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] <infinity> It's a solution, just not the most community-friendly one. :P
[03:04] <infinity> (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] <Unit193> It's one for meeeee. ;D
[03:04] <infinity> Which I totally do far too often.
[03:04] <infinity> 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] <tsimonq2> Like that sbuild thing. :P
[03:05] <Unit193> '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] <tsimonq2> *I* am even guilty of *that* :P
[03:06] <infinity> Unit193: whois is a bad example, unless someone breaks the data out from the code.
[03:06] <infinity> 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] <Unit193> 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] <infinity> wireless-crda is on the list, yeah.
[03:07] <infinity> The kernel team was meant to start loving that, but I think we fell down in the final steps of JFDIing that.
[03:08] <infinity> Err, wireless-regdb, I mean.
[03:08] <infinity> Whatever.  "the wireless thing".
[03:08] <Unit193> usb-modeswitch-data?  mobile-broadband-provider-info?  I dunno, one of those.
[03:09] <infinity> 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] <infinity> Perhaps a nice bullet list of "* package : owner", and fill in the blanks until it looks less unpleasant.
[03:10] <Unit193> 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] <infinity> The only ones I know we do reasonably well at are "tzdata: glibc maintainers" and "pciutils: kernel team"
[03:10] <tsimonq2> infinity: Side note, I thought you were in Canada? Where are you that it's 4 AM?
[03:10] <infinity> tsimonq2: London.
[03:11] <tsimonq2> infinity: Fancy. You move there or just there for now?
[03:11] <infinity> Just sprinting.
[03:11] <tsimonq2> Ah, gotcha.
[03:11] <infinity> I'd move here if I could afford it.
[03:11] <tsimonq2> It *does* seem like a wonderful place.
[03:11] <infinity> But my Calgary flat would cost about 3M pounds in a similar size and location here.
[03:11] <infinity> Which is a bit out of my range.
[03:11] <tsimonq2> Eeek. Yeah.
[03:13] <Unit193> infinity: I could bring it up, but guessing it'd have to be on -discuss.
[03:13] <infinity> Right, (hopefully actually final) rebuilds kicked off.  I need to get some sleep before morning attacks.
[03:13] <tsimonq2> Sleep well infinity.
[03:13] <Unit193> G'night.
[03:13] <stgraber> infinity: anything that needs babysitting? I'll be up for another 2-3 hours I expect
[03:13] <infinity> 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] <infinity> 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] <stgraber> infinity: ok, will check the tracker before I go to bed and track down anything that didn't update
[03:15] <Unit193> 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] <infinity> Unit193: Heh.
[03:15] <infinity> stgraber: Ta.
[03:18] <Unit193> (I'm not kidding, sadly.)  infinity: Thanks!
[03:23] <infinity> Unit193: I didn't assume you were.  My INBOX has unread messages older than some of our contributors.
[03:23] <infinity> Unit193: And I don't mean "older than their contributions", I literally mean older than the people.
[03:23] <Unit193> Haha! \o/
[03:23]  * infinity -> bed.
[03:23] <Unit193> So I've got time.
[03:26] <sarnold> better get started on that email a dozen years ago if you want in on his todo list :)
[03:32] <Unit193> 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] <nacc> Belldandu: ping
[04:16] <cyphermox> jbicha: looks like a fresh install works with shell here; so this smells like a packaging issue
[04:17] <cyphermox> gdm3 starts fine at boot, so does shell, etc.
[04:17] <cyphermox> I'm going to bed now but we could look at this some more when I'm back to debug it.
[11:56] <sil2100> 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] <sil2100> seb128: i.e. http://people.canonical.com/~people-l10n/data/ubuntu-l10n/
[11:56] <sil2100> seb128: (for future langpack generation)
[11:59] <seb128> sil2100, nice, thanks
[11:59] <seb128> is that a new team¿
[11:59] <seb128> ?
[11:59] <sil2100> seb128: not new new, dpm requested its creation when he was leaving
[12:00] <sil2100> So it was around for a bit but no one actually informed us I guess
[12:34] <ginggs> Mirv, is there something that should ensure that appmenu-qt5 is removed?
[12:36] <infinity> ginggs: It's very not removed here.  Should it be?
[12:36] <infinity> Oh, I see, it's not in zesty anymore.
[12:38] <ginggs> it seems to cause problems if it is not removed, see LP: #1680943
[12:39] <infinity> ginggs: Fun.
[12:39] <infinity> 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] <infinity> ginggs: Ideally, some other Qt component should Conflict/Replace it.
[12:40] <infinity> (But not going to let that land between now and release either)
[14:50] <Mirv> ginggs: it could be useful, yes, now that replacing functionality is in Qt 5.7
[16:43] <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.
[16:45] <nacc> Zta: do you want a 'good' .deb or just something 'good enough' ?
[16:45] <jtaylor> Zta: dh_make creates that structure
[16:45] <nacc> Zta: like something you can submit for inclusion or put in a ppa?
[16:45] <nacc> Zta: if you just need something locally, you can use checkinstall
[16:46] <Zta> nacc: Let's start with something 'good enough'.
[16:46] <Zta> Actually, I'm trying to make a package out of this: https://github.com/aseprite/aseprite/blob/master/INSTALL.md#platforms
[16:46] <nacc> Zta: but for creating a true source package, you'll need to go down the path of what jtaylor suggested
[16:46] <Zta> It uses ninja for build system.  This might be what's confusing the debhelpers?
[16:46] <jtaylor> via cmake?
[16:46] <nacc> Zta: have no idea what your d/rules says, etc
[16:46] <cjwatson> At worst, that's just a matter of a couple of overrides.
[16:46] <nacc> Zta: maybe just make a snap
[16:47] <Zta> dh_make fails
[16:47] <cjwatson> debhelper can work with anything.
[16:47] <cjwatson> You'll probably do best if you pastebin terminal transcripts showing what's going wrong
[16:48] <Zta> yes sir, hold on
[16:56] <Zta> https://pastebin.com/zz4wmrjt
[16:57] <Zta> oh wait, -p aseprite_123 does something good
[16:57] <cjwatson> cd ..; mv aseprite aseprite-123; cd -; dh_make
[16:57] <cjwatson> or similar
[16:57] <cjwatson> that's what it's telling you
[16:57] <cjwatson> but yes, -p aseprite_123 would work too
[16:57] <cjwatson> (and is probably better, actually, so do that)
[16:58] <nacc> (note the _ vs. - )
[17:02] <Zta> nacc: exactly, I just noticed that now.  That's been bugging me for hours now =)
[17:03] <nacc> Zta: yeah, it's a bit hard to detect that difference if you aren't looking for it :)
[17:05] <Zta> Is there a tool to edit the debian/control file programmatically? (besides sed =)
[17:05] <nacc> Zta: vi ?
[17:05] <nacc> Zta: not sure what you mean, i guess :)
[17:05] <nacc> Zta: it's just a text file, i mean
[17:07] <Zta> 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] <nacc> Zta: right, just use an editor
[17:07] <Zta> I'm trying to script this, so vi isn't an option =).  Right, sed it is.
[17:07] <nacc> Zta: i don't believe there is a helper command to edit d/control -- seems like overkill to me :)
[17:08] <nacc> Zta: why are you scripting it?
[17:08] <nacc> Zta: once you build a source package, you don't need to do it again
[17:08] <nacc> Zta: alternatively, like i said, you coudl snap it and it might be a bit faster
[17:08] <Zta> Yes I do, because it source code gets updated.
[17:08] <nacc> Zta: uscan/uupdate handle tht
[17:08] <nacc> Zta: the packaging is distinct from the upstream
[17:08] <cjwatson> debian/control usually doesn't change on every upstream change
[17:09] <cjwatson> there is cme if you want to automate though
[17:09] <nacc> Zta: given a good d/watch file
[17:09] <nacc> cjwatson: interesting, i hadn't seen that before, thanks!
[17:09] <cjwatson> (though personally I find cme way too complex and don't bother)
[17:09] <Zta> Ideally, I create a cronjob that pulls, builds, and reinstalls.  Or a docker image that serves a PPA?
[17:10] <nacc> Zta: right, that's a recipe in launchpad (I think)
[17:10] <nacc> Zta:  a git recipe, in this case
[17:10] <nacc> Zta: and you'd keep your debian/ in another repo (aiui) which just has the packaging stuff
[17:10] <cjwatson> https://help.launchpad.net/Packaging/SourceBuilds
[17:10] <nacc> Zta: and the two get combined (magic!) and your package builds
[17:11] <nacc> 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] <cjwatson> and debian/changelog updates are scriptable using dch
[17:12] <Zta> It's not my code, so I can't put it into Launchpad.
[17:14] <Zta> Hm, I was expecting dh_make to generate a better Depends list.
[17:14] <Zta> Look at this: https://pastebin.com/HY4Nmkkr
[17:15] <nacc> uh
[17:16] <nacc> i think you're missing something in all of this
[17:16] <cjwatson> dh_make just generates a skeleton
[17:16] <nacc> Zta: do you undrestand the difference between a source and binary package?
[17:16] <Zta> 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] <cjwatson> it's not expected to write your Depends for you
[17:16] <nacc> Zta: dh_make sets up the skeleton of a source package for you, nothing else
[17:16] <nacc> Zta: and it doesn't build anything (which is what generates thea ctual depends in the binary package)
[17:17] <cjwatson> you should regard debian/ as a chunk of code that you need to maintain on an ongoing basis
[17:17] <cjwatson> it is not a thing you should be trying to generate for each upstream commit you want to build
[17:17] <nacc> Zta: iirc, launchpad can import a github repository
[17:17] <cjwatson> and writing anything under DEBIAN/ by hand is a red flag that you are doing something fundamentally wrong
[17:18] <Zta> 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] <nacc> Zta: DEBIAN and debian are different
[17:18] <cjwatson> 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] <cjwatson> yes, debian/* should be written by hand (perhaps starting from a skeleton generated by something like dh_make)
[17:19] <Zta> 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] <cjwatson> DEBIAN/* should only be touched by tools called (eventually) from debian/rules, which is the entry point of the source package
[17:19] <Zta> cjwatson: Makes sense.
[17:20] <cjwatson> 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] <Zta> Right.
[17:20] <dobey> i bet that is an interestingly worded license agreement
[17:20] <nacc> Zta: except you are breaking that rule by building packages at all then
[17:20] <nacc> Zta: so screw that and just do it the easier way :)
[17:20] <Zta> Ok, so I have a skeleton for my source package now.
[17:21] <Zta> nacc: I think I'm allow to distribute my own build it to myself =)
[17:21] <nacc> right, that's all the recipe would do too (just in a ppa)
[17:21] <nacc> you can make the ppa private
[17:21] <Zta> hmm
[17:22] <cjwatson> nacc: that's a paid feature
[17:22] <nacc> cjwatson: ah :(
[17:22] <nacc> Zta: so nm :)
[17:22] <cjwatson> 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] <nacc> cjwatson: you might be right
[17:23] <Zta> =)
[17:23] <cjwatson> and you have to write the packaging anyway
[17:23] <dobey> i'm curious what software this is
[17:23] <Zta> sprite editor
[17:23] <nacc> Zta: ok, so you've got the skeleton, so now you need to modify d/ files
[17:23] <Zta> Think GIMP for kids 8)
[17:24] <Zta> GIMP for 8bit gamers
[17:24] <nacc> Zta: this has some rough guidelines iirc, for dh_make workflow: https://www.debian.org/doc/manuals/maint-guide/first.en.html
[17:24] <nacc> Zta: but once you do it once,  you don't throw it away
[17:24] <nacc> Zta: you keep that as your source package and then do updates to it as needed
[17:25] <Zta> 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] <nacc> Zta: right, but as cjwatson said, that script is bunk :)
[17:26] <nacc> Zta: it seems to be pretending that debhelper doesn't exist to do all this for you (e.g. dh-shlibdeps)
[17:26] <nacc> err, dh_shlibdeps
[17:27] <cjwatson> 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] <cjwatson> debian/control has ${shlibs:Depends}, ${misc:Depends}, which are filled in by various debhelper tools, and also some manually inserted dependencies
[17:27] <cjwatson> debian/rules has override_* targets in cases where the defaults don't work
[17:28] <cjwatson> or a simpler case, https://anonscm.debian.org/cgit/users/cjwatson/dumpet.git/tree/debian
[17:30] <cjwatson> the simplest possible cases can have a three-line debian/rules
[17:30] <cjwatson> anyway, must get a train
[17:36] <Zta> Take the A train.
[17:37] <Zta> That debian/rules looks complex =\
[17:40] <nacc> 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] <Zta> 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] <dobey> debuild
[17:41] <nacc> 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] <Zta> I'd prefer not to mess with my host system.
[17:42] <dobey> sbuild for sure
[17:42] <nacc> Zta: yeah, so get your code in good shape
[17:42] <dobey> but you still need to debuild -S to generate the source package on host
[17:42] <nacc> yep
[17:42] <dobey> or you can try to build the source pkg inside sbuild too, but it's a bit of a pain
[17:42] <nacc> which is just (aiui), dpkg-buildpackage -S
[17:42] <Zta> This doesn't fit well with this weird ninja build system.
[17:42] <nacc> with a few extra commands
[17:42] <nacc> Zta: what do you mean?
[17:44] <Zta> 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] <nacc> ok, then add a build-depends on ninja-build and run that command in an appropriate override
[17:45] <Zta> sounds easy
[17:45] <Zta> how? =)
[17:45] <dobey> well you likely don't have to use ninja, and debhelper already supports cmake natively
[17:45] <jtaylor> cmake works out of the box with make too, if you don't need the extra speed debhelper defaults should be fine
[17:45] <nacc> yeah i can't tell if you need ninja or not
[17:45] <jtaylor> the ninja speed is not important for package builds anyway
[17:45] <jtaylor> its more useful for partial rebuilds
[17:45] <jtaylor> aka development
[17:45] <nacc> i undrestand their instructions say to use it, but i'd try it wihtout and see what works
[17:46] <nacc> my guess is `make install` will dtrt and ninja is purely there for speed
[17:50] <Zta> Well, it seems I have to do something, because running plain dpkg-buildpackage fails: https://pastebin.com/dssCzckH
[17:50] <nacc> Zta: well, as we said
[17:51] <nacc> Zta: you want to use -S
[17:51] <nacc> Zta: build a source package and then build the binary using sbuild or so
[17:51] <Zta> sorry, I'm downing in info =)
[17:51] <nacc> Zta: yes, there's a lot to take in
[17:51] <dobey> nacc: well it will still fail with the same error
[17:51] <dobey> nacc: since that's trying to build the source package first
[17:51] <nacc> dobey: yeah, i hadn't looked at the details yet :)
[17:52] <nacc> Zta: ok, so it ooks like dpkg-buildpackage is seeing local changes relative to the orig tarball you used
[17:52] <Zta> I didn't use a tarball; i checkout out from git.
[17:52] <nacc> Zta: that is, it looking at the contents of aseprite_1.2-dev-master-fece0cf.orig.tar.xz
[17:52] <nacc> Zta: yes, that's not how deb building works
[17:53] <Zta> urgh..
[17:53] <nacc> Zta: in that, as on the debian guide linked earlier
[17:53] <nacc> 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] <Zta> 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] <Zta> =)
[17:54] <nacc> Zta: yep, did you read the debian packaging guide i linked?
[17:54] <nacc> Zta: that gives you a lot of inofrmation, but i think it's necessary so you understand how building works
[17:55] <Zta> 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] <nacc> Zta: where did ./aseprite_1.2-dev-master-fece0cf.tar.xz come form?
[17:56] <nacc> *from
[17:56] <nacc> Zta: no, that's not how building works
[17:57] <Zta> 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] <nacc> look in the current directory
[17:57] <Zta> no such file.
[17:57] <Zta> Oh, there's one in ..
[17:57] <nacc> ~/asperite-workdir/aseprite I guess
[17:58] <nacc> ah yeah it'll be in ../ sorry
[17:58] <Zta> Ok, so that's what took so long.  dh_make wrapped up the entire dir?  Ok, so I have a tarball.
[17:59] <nacc> Zta: yes, see 'ACTIONS PERFORMED' in `man dh_make`
[18:00] <Zta> Right.
[18:01] <nacc> because non-native package building needs an orig tarball and a debian tarball
[18:01] <Zta> 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] <nacc> Zta: i don't know what you mean by "have my debian dir"
[18:03] <nacc> Zta: dh_make is used to generate a debian/ directory
[18:03] <Zta> that's the directory I mean.
[18:04] <nacc> you would run it from aseprite/, afaict
[18:04] <Zta> should it be workdir/debian/   or workdir/aseprite/debian/ ?
[18:04] <Zta> ok
[18:04] <Zta> so the latter
[18:04] <Zta> And the tarball magically ends up in workdir.
[18:06] <nacc> yes, because all the tooling needs it to be in ../ relative to where you run the build from
[18:06] <nacc> (even for source package builds)
[18:08] <nacc> 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] <nacc> Zta: so that it can track what you change relative to the 'pristine' upstream
[18:09] <Zta> yes
[18:10] <nacc> and every change to the upstream source must be stored as a patch in the debian/patches directory (for quilt-based packages)
[18:10] <nacc> and then your packaging decisions go in debian/ which will be tarred up by dpkg-buildpackage into ../debian.tar.xz
[18:10] <Zta> But the upstream is already outdated because it has the skeleton debian/control file.
[18:11] <nacc> upstream does *not* have a d/control file
[18:11] <nacc> https://github.com/aseprite/aseprite
[18:11] <nacc> no debian/ directory
[18:11] <Zta> dh_make just created one
[18:11] <nacc> dh_make did the tarring *before* creating debian
[18:11] <Zta> oh
[18:11] <nacc> as i said earlier
[18:12] <nacc> or it excludes debian/ i'm not sure (effect is the same)
[18:12] <Zta> It first compresses, then it generates.
[18:12] <nacc> ok
[18:13] <nacc> well, you can see in the log from dpkg-buildpackage (there's a file referenced) what the changes it is detecting are
[18:13] <Zta> dh_make also won't execute if a debian/ dir or the ../tarball exists is seems =)
[18:14] <nacc> well if ../tarball exists,  you should use -f
[18:14] <nacc> and yeah, dh_make is for making a new skeleton
[18:14] <nacc> doesn't make sense torun it if you have a debian/
[18:14] <Zta> I deleted both so I could retry.
[18:20] <Zta> Ah, dpkg-buildpackage -S fails because if signing: No secret key
[18:20] <nacc> Zta: try
[18:20] <nacc> dpkg-buildpackage -S -nc -d -uc -us
[18:21] <nacc> the last two say don't sign
[18:21] <nacc> -nc says don't clean (can be handy while you iterate)
[18:21] <nacc> and -d says don't worry about builddeps here
[18:21] <nacc> since you are (hopefully) going to use sbuild to build, and the builddeps will get satisfied there
[18:22] <Zta> no errors, exit code 0. That must mean success.
[18:22] <nacc> right so go into the parent directory
[18:22] <nacc> you should see an appropriately named .dsc file
[18:22] <nacc> and a _changes file, iirc
[18:23] <Zta> yes
[18:24] <nacc> Zta: then you can pass those to sbuild (after having set up a sbuild environment locally (see mk-sbuild)
[18:25] <Zta> Do I need both mk-sbuild and sbuild?
[18:25] <Zta> mk-sbuild is from ubuntu-dev-tools
[18:26] <sarnold> mk-sbuild is by far the easiest way to make the schroots that sbuild will use
[18:27] <nacc> yeah, that's what i was just checking on
[18:27] <nacc> Zta: i would use mk-sbuild, just to be sure you do it right :)
[18:27] <sarnold> have you seen this yet/ https://wiki.ubuntu.com/SimpleSbuild
[18:27] <nacc> sarnold: thanks, was just pulling that up
[18:27] <Zta> sudo apt install ubuntu-dev-tools --no-install-recommends  it is
[18:40] <Zta> How much of those instructions on SimpleSbuild should I go though?
[18:41] <Zta> I feel it's building an entire ubuntu distriution right now =)
[18:41] <nacc> Zta: it is
[18:41] <nacc> Zta: in a schroot
[18:41] <nacc> that's how you build in an environment that doens't affect your host
[18:42] <sarnold> .. and so your host environment doesn't affect your build :)
[18:42] <sarnold> (of course the running kernel affects the build, but these day's that's usually not a big deal)
[18:42] <nacc> sarnold: good point! :)
[18:43] <Zta> ...Docker seems less intrusive
[18:45] <nacc> docker and lxd can also be used, but they aren't so directly integrated
[18:45] <nacc> meaning you have to wrap commands in commands to build in them, afaict
[18:49] <Zta> Done building zesty-amd64!
[18:49] <Zta> I'm on xenial, though.  Is that a problem? =\
[18:50] <nacc> Zta: not necessarily
[18:51] <nacc> Zta: so you need to have an sbuild environemnt suitable for building your package for the release you want to target
[18:51] <nacc> Zta: so in you case, you probably wanted to run `mk-sbuild xenial` if you want a .deb for xenial
[18:52] <Zta> The tutorial learned me a nice command: sg sbuild  I've been missing that some times.
[19:08] <Zta> So I'm here and I ran this: ~/aseprite-workdir/aseprite$ sbuild -A -d xenial-amd64 --host ../*.dsc
[19:08] <Zta> 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] <sarnold> try mkdir -p /home/stephan/.ubuntu-sbuild/logs and try again?
[19:10] <nacc> Zta: yeah, i think you're missing some .sbuildrc values
[19:10] <nacc> Zta: this is what i use locally: http://paste.ubuntu.com/24369306/
[19:15] <Zta> 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] <nacc> Zta: oh wait
[19:15] <sarnold> oh I missed that entirely
[19:15] <sarnold> that does smell funny
[19:16] <nacc> Zta: um, i don' think --host on its own does anything
[19:16] <nacc> Zta: and then you really don't want to use *.dsc
[19:16] <nacc> well, it might work right now
[19:16] <nacc> but eventually taht will be multiple dsc files
[19:16] <Zta> ok
[19:16] <nacc> can you try with the actual file name?
[19:16] <Zta> I know it's a hack for now; I was lazy.  It seems to evaluate properly, but I'll try full name.  And exclude host.
[19:17] <Zta> wow!
[19:18] <Zta> It builds something.
[19:19] <nacc> Zta: when it finishes, it should put a .deb in .ubuntu-sbuild if you've not set upa  .sbuildrc
[19:19] <nacc> iirc
[19:19] <Zta> Btw this is was "mk-sbuild xenial" ended by saying: "To BUILD for : sbuild -A -d xenial-amd64 --host  PACKAGE*.dsc", so it seems like there's a $host missing somewhere =)
[19:19] <nacc> the last lines should say explicitly the name of the .deb
[19:19] <nacc> Zta: right, you *can* pass --host
[19:19] <nacc> but it's only useful for cross-building
[19:19] <nacc> which i assuemd you weren't doing :)
[19:21] <Zta> Correct =)
[19:22] <Zta> Build failed, though: https://pastebin.com/KMQ2CVPq
[19:22] <nacc> Zta: did you add cmake as a build-dep in d/control?
[19:23] <Zta> mmmno
[19:23] <nacc> Zta: right, now you're at the point where you need to flesh out the skeleton
[19:23] <nacc> with the build-deps, possible binary package deps, rules overrides, etc
[19:24] <nacc> Zta: bbiab -- but i think you can iterate from here
[19:24] <nacc> Zta: make some changes in debian/, run dpkg-buildpackage -S -nc -d -uc -us, run sbuild on the dsc and get it to build :)
[19:24] <Zta> I'll call it day
[19:25] <Zta> Thanks for the help so far.  I'll be back for some more dh_pain soon =)
[19:27] <Zta> ..wait what? http://stackoverflow.com/questions/32012811/how-to-build-a-deb-file-for-cmake-from-source  ... I better leave that where I found it.
[19:34] <Zta> Right, I managed to add cmake to dependency, and I commented out something cmake related in the the skeleton d/rules.  Now cmake is installed, and the build is executed, but it still fails.  I feel I'm close, but I'll come back and finish the job some other time.
[19:37] <nacc> Zta: sure, just ping me if you need help, and paste the logs
[19:37] <nacc> *pastebin
[19:37] <Zta> Will do.  And again, thanks a lot of all the help everyone.
[20:43] <acheronUK> Is there any way I can fool the update notifier etc into thinking Zesty is released?
[20:44] <acheronUK> Just want a screenshot of the upgrade being offered
[20:46] <nacc> acheronUK: i'm not sure if passing -d would do it?
[20:46] <nacc> acheronUK: you can do that for update-manager, at least
[20:47] <acheronUK> nacc: I want plasma-discover to think there is an upgrade, so I need to manually change a file somewhere I guess
[20:49] <nacc> acheronUK: i would guess taht's specific to plasma-discover, but not sure
[20:49] <nacc> maybe something in /etc/apt/apt.conf.d/60plasma-discover?
[20:50] <acheronUK> nacc: I was thinking it's getting the info that a release upgrade is available from the same source as native ubuntu upgrade tools would
[20:50] <acheronUK> nacc: no, definitely not that file.
[20:51] <nacc> acheronUK: ok, i'm not sure
[20:51] <acheronUK> anyway. I'm not overly fussed. I can quickly grab a screenshot when the release goes out for real and put that on the wiki. just would have been nice to get it all done now
[21:12] <Laney> bdmurray: dkms> Is is that the get_newest_kernel_debian thing is broken? https://paste.ubuntu.com/24369911/
[21:12]  * Laney doesn't know very much about dkms but it seems that this should return 4.10.0-19 not nothing ...
[21:13] <Laney> maybe change the gt to ge?
[21:14] <nacc> Laney: yeah that does seem off
[21:17] <nacc> it doesn't seem like it would do any harm to be -ge, as it should be a no-op or, as in this case, a correct assignment of what is 'currently' consider the newest kernel when we haven't seen any kernels yet
[21:17] <Laney> looks that way to me
[21:17] <nacc> alternatively, rather than do the COMPARE_TO assignemnt, just do the same assignment in that section as later and continue the loop, as i think that's the intent
[21:18] <nacc> the assignment in the if, that is
[21:18] <nacc> Laney: nice catch
[21:18] <Laney> didn't test it end to end yet ;)
[21:18] <Laney> (actually not immediately sure how to do that)
[21:19] <Laney> interrupt the upgrade and hack the file or something
[21:20] <bdmurray> install dkms, hack it, then do the upgrade?
[21:20] <Laney> apt install --reinstall bcmwl-kernel-source does give Building initial module for 4.10.0-19-generic though
[21:20] <Laney> yeah I guess
[21:20] <Laney> lemme try that
[21:28] <Laney> k, it's running
[21:42] <Laney> Building for 4.8.0-46-generic 4.10.0-19-generic
[21:42] <Laney> looking ok so far
[21:44] <bdmurray> there's also this new autoinstall_all_kernels option
[21:58] <LocutusOfBorg> bdmurray, hello, wrt LP: #1681566, let me understand, you can install virtualbox-dkms without having corresponding kernel sources available?
[21:59]  * LocutusOfBorg is going to sleep, sorry for the delay
[22:00] <bdmurray> LocutusOfBorg: dkms isn't building modules for the new kernel during an upgrade. reinstalling the kernel or the dkms package then causes the modules to be built for the new kernel.
[22:00] <bdmurray> LocutusOfBorg: Laney is testing a fix now.
[22:05] <jackpot51> bdmurray: any ideas what was happening?
[22:07] <nacc> maybe better asked here .. given just a .dsc, how do i dtermine which distribution the package targets? i'm not seeing anyting in the dsc object that provides that info
[22:07] <nacc> or is that simply not deducible given just a .dsc -- it's fine if so, just wondering
[22:08] <jackpot51> Try to dget the dsc file
[22:08] <nacc> (assume i can also extract said source package)
[22:08] <nacc> jackpot51: right, but dget works with ppas, say
[22:08] <jackpot51> Look in the debian/changelog of the source package
[22:08] <nacc> jackpot51: yep, that should work, was just wondering if there was seomething ... faster :)
[22:09] <jackpot51> Don't know
[22:09] <Laney> nacc: bdmurray: LocutusOfBorg: Attached. I need to go to bed now, so could one of you review / test / maybe upload? It might be worth asking tseliot and/or superm1 for advice if you can find them (maybe forwarding to upstream on github will get a response).
[22:10] <nacc> Laney: nice work, have a restful evening!@
[22:10] <Laney> thanks!
[22:11] <Laney> oh, and feel free to try and understand the logic a bit better of course
[22:11] <Laney> to determine if it was actually intended to behave like that and should be fixed elsewhere
[22:11] <Laney> o/
[22:12] <jackpot51> Hey Laney, Where can I see your work?
[22:12] <bdmurray> jackpot51: in the ubg
[22:14] <jackpot51> Launchpad was down for about 30 seconds. That was freakin scary
[22:14] <jackpot51> Doing a release upgrade on the launchpad.net servers I hope?
[22:16] <sarnold> I understand routers were having new rules pushed
[22:22] <LocutusOfBorg> thanks lamont bdmurray
[22:23] <LocutusOfBorg> s/lamont/laney
[22:24] <LocutusOfBorg> I would like to upload but it is seeded almost everywhere :(
[22:24]  * lamont did nothing :D
[22:24] <LocutusOfBorg> SRU?
[22:26] <jackpot51> bdmurray: LocutusOfBorg: Can we have the DKMS fixes in the repos before people get update-manager notifications?
[22:26] <bdmurray> jackpot51: that's technically possible
[22:37] <LocutusOfBorg> bdmurray, please upload then :)
[22:37]  * LocutusOfBorg is going to sleep, 1am here and alarm is at 6