| tsimonq2 | cyphermox: Whoops, got carried away doing something else, running that now. | 00:06 |
|---|---|---|
| tsimonq2 | THERE we go. | 00:07 |
| * tsimonq2 digs | 00:07 | |
| 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:08 |
| cyphermox | there might be some gems there; probably something about DNSSEC not being happy | 00:09 |
| tsimonq2 | cyphermox: lol ok | 00:09 |
| tsimonq2 | cyphermox: You has mail. | 00:19 |
| cyphermox | what did you dig for, just so I know where to look? | 00:27 |
| tsimonq2 | cyphermox: www.google.com | 00:30 |
| 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:40 |
| 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:41 |
| 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:43 |
| cyphermox | that's where knowing what to search for exactly helps a lot | 00:44 |
| tsimonq2 | Ok. | 00:44 |
| tsimonq2 | cyphermox: Get my email? | 00:45 |
| cyphermox | yup | 00:46 |
| tsimonq2 | Yay ok | 00:46 |
| 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:48 |
| cyphermox | (or libnss-resolved is installed and nsswitch points to the right place) | 00:49 |
| 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:50 |
| 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:51 |
| 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:53 | |
| tsimonq2 | cyphermox: Alright, reproducable now. Can't systemd-resolve either vps.tsimonq2.net or www.verisign.com | 00:56 |
| tsimonq2 | Wait, wrong wording there. It's a bug now... | 00:57 |
| 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:58 |
| 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. | 00:59 |
| 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:18 |
| cyphermox | tsimonq2: that is a representative sample | 01:28 |
| cyphermox | the key here is Timeout, and it's not something I've seen before | 01:29 |
| tsimonq2 | cyphermox: Oooooh ok | 01:32 |
| tsimonq2 | cyphermox: So what about my system could be Special? | 01:32 |
| cyphermox | no idea | 01:53 |
| cyphermox | timeouts are most often an environment issue, but it could also not be. | 01:53 |
| tsimonq2 | Ok. | 01:56 |
| === _salem is now known as salem_ | ||
| 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:47 |
| ubottu | Launchpad bug 1321955 in postfixadmin (Ubuntu) "postfixadmin dependencies not well defined (requires mysql-server or postgresql, removes MariaDB)" [Undecided,In progress] | 02:47 |
| Belldandu | The fix is so miniscule its depressing that it hasnt been fixed | 02:48 |
| Belldandu | Change debconf depency line mysql-client | pgsql-client to mysql-client | pgswl-client | mariadb-client | 02:50 |
| Belldandu | pgsql-client* | 02:50 |
| infinity | Belldandu: Looks already fixed in zesty | 02:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| Belldandu | Yeah and ok | 02:55 |
| 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:57 |
| infinity | onthewings: https://www.canonical.com/projects/directory lists the contacts for each CLA-using project. | 02:58 |
| 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. | 02:59 |
| infinity | Unit193: Well, it's an SRU by definition. It just might need different rules, like tzdata and a few others. | 03:00 |
| 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:01 |
| 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:02 |
| infinity | It's a solution, just not the most community-friendly one. :P | 03:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:13 |
| 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:14 |
| 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:15 |
| Unit193 | (I'm not kidding, sadly.) infinity: Thanks! | 03:18 |
| 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:23 |
| sarnold | better get started on that email a dozen years ago if you want in on his todo list :) | 03:26 |
| === salem_ is now known as _salem | ||
| 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 | 03:32 |
| cyphermox | jbicha: looks like a fresh install works with shell here; so this smells like a packaging issue | 04:16 |
| 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. | 04:17 |
| === _salem is now known as salem_ | ||
| === salem_ is now known as _salem | ||
| === CRogers_________ is now known as CRogers | ||
| === morphis_ is now known as morphis | ||
| 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:56 |
| 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 | 11:59 |
| sil2100 | So it was around for a bit but no one actually informed us I guess | 12:00 |
| ginggs | Mirv, is there something that should ensure that appmenu-qt5 is removed? | 12:34 |
| infinity | ginggs: It's very not removed here. Should it be? | 12:36 |
| infinity | Oh, I see, it's not in zesty anymore. | 12:36 |
| ginggs | it seems to cause problems if it is not removed, see LP: #1680943 | 12:38 |
| ubottu | 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:38 |
| 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:39 |
| 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) | 12:40 |
| === _salem is now known as salem_ | ||
| === salem_ is now known as _salem | ||
| === _salem is now known as salem_ | ||
| Mirv | ginggs: it could be useful, yes, now that replacing functionality is in Qt 5.7 | 14:50 |
| 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:43 |
| 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:45 |
| 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:46 |
| 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:47 |
| Zta | yes sir, hold on | 16:48 |
| Zta | https://pastebin.com/zz4wmrjt | 16:56 |
| 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:57 |
| nacc | (note the _ vs. - ) | 16:58 |
| Zta | nacc: exactly, I just noticed that now. That's been bugging me for hours now =) | 17:02 |
| nacc | Zta: yeah, it's a bit hard to detect that difference if you aren't looking for it :) | 17:03 |
| 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:05 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| Zta | It's not my code, so I can't put it into Launchpad. | 17:12 |
| Zta | Hm, I was expecting dh_make to generate a better Depends list. | 17:14 |
| Zta | Look at this: https://pastebin.com/HY4Nmkkr | 17:14 |
| nacc | uh | 17:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| cjwatson | or a simpler case, https://anonscm.debian.org/cgit/users/cjwatson/dumpet.git/tree/debian | 17:28 |
| cjwatson | the simplest possible cases can have a three-line debian/rules | 17:30 |
| cjwatson | anyway, must get a train | 17:30 |
| Zta | Take the A train. | 17:36 |
| Zta | That debian/rules looks complex =\ | 17:37 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:44 |
| 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:45 |
| nacc | my guess is `make install` will dtrt and ninja is purely there for speed | 17:46 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:53 | |
| 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:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| 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:58 |
| nacc | Zta: yes, see 'ACTIONS PERFORMED' in `man dh_make` | 17:59 |
| Zta | Right. | 18:00 |
| 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:01 |
| 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:03 |
| 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:04 |
| 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:06 |
| 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:08 |
| nacc | Zta: so that it can track what you change relative to the 'pristine' upstream | 18:09 |
| Zta | yes | 18:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:20 |
| 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:21 |
| 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:22 |
| Zta | yes | 18:23 |
| nacc | Zta: then you can pass those to sbuild (after having set up a sbuild environment locally (see mk-sbuild) | 18:24 |
| Zta | Do I need both mk-sbuild and sbuild? | 18:25 |
| Zta | mk-sbuild is from ubuntu-dev-tools | 18:25 |
| sarnold | mk-sbuild is by far the easiest way to make the schroots that sbuild will use | 18:26 |
| 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:27 |
| === nacc is now known as Guest42667 | ||
| === nacc_ is now known as nacc | ||
| Zta | How much of those instructions on SimpleSbuild should I go though? | 18:40 |
| 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:41 |
| 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:42 |
| Zta | ...Docker seems less intrusive | 18:43 |
| 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:45 |
| Zta | Done building zesty-amd64! | 18:49 |
| Zta | I'm on xenial, though. Is that a problem? =\ | 18:49 |
| nacc | Zta: not necessarily | 18:50 |
| 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:51 |
| Zta | The tutorial learned me a nice command: sg sbuild I've been missing that some times. | 18:52 |
| 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:08 |
| sarnold | try mkdir -p /home/stephan/.ubuntu-sbuild/logs and try again? | 19:09 |
| 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:10 |
| 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:15 |
| 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:16 |
| Zta | wow! | 19:17 |
| Zta | It builds something. | 19:18 |
| 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:19 |
| Zta | Correct =) | 19:21 |
| Zta | Build failed, though: https://pastebin.com/KMQ2CVPq | 19:22 |
| nacc | Zta: did you add cmake as a build-dep in d/control? | 19:22 |
| 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:23 |
| 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:24 |
| Zta | Thanks for the help so far. I'll be back for some more dh_pain soon =) | 19:25 |
| 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:27 |
| 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:34 |
| 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. | 19:37 |
| acheronUK | Is there any way I can fool the update notifier etc into thinking Zesty is released? | 20:43 |
| acheronUK | Just want a screenshot of the upgrade being offered | 20:44 |
| 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:46 |
| acheronUK | nacc: I want plasma-discover to think there is an upgrade, so I need to manually change a file somewhere I guess | 20:47 |
| 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:49 |
| 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:50 |
| 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 | 20:51 |
| 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:12 | |
| Laney | maybe change the gt to ge? | 21:13 |
| nacc | Laney: yeah that does seem off | 21:14 |
| 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:17 |
| 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:18 |
| Laney | interrupt the upgrade and hack the file or something | 21:19 |
| 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:20 |
| === _salem is now known as salem_ | ||
| Laney | k, it's running | 21:28 |
| === koza is now known as koza|away | ||
| Laney | Building for 4.8.0-46-generic 4.10.0-19-generic | 21:42 |
| Laney | looking ok so far | 21:42 |
| bdmurray | there's also this new autoinstall_all_kernels option | 21:44 |
| LocutusOfBorg | bdmurray, hello, wrt LP: #1681566, let me understand, you can install virtualbox-dkms without having corresponding kernel sources available? | 21:58 |
| ubottu | Launchpad bug 1681566 in virtualbox (Ubuntu) "nvidia-375 DKMS module not recompiled on upgrade to 17.04" [Undecided,Confirmed] https://launchpad.net/bugs/1681566 | 21:58 |
| * LocutusOfBorg is going to sleep, sorry for the delay | 21:59 | |
| 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:00 |
| jackpot51 | bdmurray: any ideas what was happening? | 22:05 |
| 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:07 |
| 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:08 |
| jackpot51 | Don't know | 22:09 |
| === salem_ is now known as _salem | ||
| 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:09 |
| nacc | Laney: nice work, have a restful evening!@ | 22:10 |
| Laney | thanks! | 22:10 |
| 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:11 |
| jackpot51 | Hey Laney, Where can I see your work? | 22:12 |
| bdmurray | jackpot51: in the ubg | 22:12 |
| 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:14 |
| sarnold | I understand routers were having new rules pushed | 22:16 |
| LocutusOfBorg | thanks lamont bdmurray | 22:22 |
| LocutusOfBorg | s/lamont/laney | 22:23 |
| LocutusOfBorg | I would like to upload but it is seeded almost everywhere :( | 22:24 |
| * lamont did nothing :D | 22:24 | |
| LocutusOfBorg | SRU? | 22:24 |
| 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:26 |
| LocutusOfBorg | bdmurray, please upload then :) | 22:37 |
| * LocutusOfBorg is going to sleep, 1am here and alarm is at 6 | 22:37 | |
| === Guest27115 is now known as RAOF | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!