[09:49] When using sbuild, and a package with source/format "3.0 (git)" do we have to manually add 'git' as a Build-Depends ? [14:38] cyphermox: hi, while developing ltsp-next, I noticed that in 19.04 initramfs, ./etc/dhcp/dhclient-enter-hooks.d/config writes: [14:38] echo "IPV4DNS0=$new_domain_name_servers" >> /run/net-$interface.conf [14:38] I.e. all DNS servers (in my case 3) in IPV4DNS0; this makes netplan show some errors [14:39] Sorry for not filing a bug report as it's a little complicated where the issue is (dhclient or netplan) and I'm not using netplan; just thought I'd ping here even if it's lost === transfusion3 is now known as transfusion [16:10] TJ-: I really wouldn't use source format 3.0 (git). It was experimental and never got much adoption [16:12] TJ-: Pretty much everyone is using 3.0 (quilt) for your sort of use case, often with the quilt patches actually being automatically generated from git commits (using gbp pq or git-dpm or possibly others) [16:12] cjwatson: hmmm, can you tell me what I should use for working from pure git from upstream? When it was set to quilt I was getting failures due to missing tarball, and couldn't figure out the correct process to create it! [16:12] I just did :) [16:13] Oh, missing tarball [16:13] cjwatson: but the debian/ directory isn't done with that, and I've made no changes to the upstream, I'm just trying to get the initial package correct! [16:13] Do upstream not make releases? [16:13] cjwatson: no, and no tags in git either [16:14] Well then you do need to produce one, but that's not really a Debian question [16:14] No make dist or equivalent? [16:14] cjwatson: its network-manager-wireguard https://github.com/max-moser/network-manager-wireguard [16:14] I am not going to look [16:14] Other things to do [16:14] cjwatson: from what I can tell he copied the build system from network-manager-openvpn [16:14] I know nothing of the specifics [16:15] You basically just want a tarball that has say network-manager-wireguard/ at the top level [16:15] I can't find any docs on how to deal with this when there is no upstream release/tarbal/tags [16:15] Exact naming doesn't really matter [16:15] You could try git archive [16:15] right, actually, I did use that (!!) last night but that a long time after I'd switched from quilt to git... maybe I should switch back! [16:16] But is it an autoconfy upstream? It probably has a perfectly good make dist if so [16:17] Anyway, as long as it's a tarball that pretty much unpacks to what you get from git, it should do [16:17] (except for the .git itself) [16:17] My main problem though as been the debhelper autoreconf invocation is NOT calling intltoolize and as result (in sbuild) config.status rails due to missing po/Makefile.in.in - intltool is a build-dep and I've been into the schroot chroot and checked the intltoolize is there [16:17] Yes, it has an autogen.sh, and configure.ac [16:17] If there's an autogen.sh then you should tell dh_autoreconf to run that [16:18] dh_autoreconf -- ./autogen.sh [16:18] In an override_dh_autoreconf rule [16:18] If I build locally, calling ./autogen.sh it's fine (because that specifically calls intltoolize ) but couldn't figure out why dh_autoreconf wasn't doing likewise, from its man-page it implied it would do that for me :) [16:18] ahhhh, specific call? [16:18] thanks [16:18] man dh_autoreconf says no such thing [16:18] It says that it calls autoreconf -f -i [16:19] Which is not necessarily the same thing as a custom autogen.sh if a package has one of those [16:19] it does [16:19] See the bit under OPTIONS starting with "program -- params" [16:20] grub2 uses "dh_autoreconf -- ./autogen.sh" in its debian/rules because the autogen.sh is a specialised custom thing [16:20] it says "export LIBTOOLIZE = true" - I thought that would include the intltoolize :) [16:20] Er no [16:20] Not even a little bit [16:20] cjwatson: OK, now it makes sense ! [16:20] let me try your override command, there is already one in place but not with that on it [16:20] autoreconf(1) doesn't have any integration for intltoolize [16:21] So no simple environment variable setting will do what you're looking for [16:21] cjwatson: thanks, it's been a weekend of confusion heaped on confusion so far [16:21] (Also, slightly confusingly, "export LIBTOOLIZE = true" actually means "run 'true' instead of 'libtoolize'", i.e. *disable* libtoolize) [16:22] cjwatson: yeah, I got that nuance [16:22] I was surprise it wasn't 'false' :) [16:22] I imagine that would cause autoreconf to run false and then bail out because its exit code is non-zero [16:23] I thought likewise ... return codes do turn binary/bool results on their head :) [16:23] Lots of ways to fail, only one way to succeed [16:23] is perhaps an easy way to remember it [16:23] indeed, and I've failed in every way possible this weekend! [16:24] In my shell scripts I do a lot of if $VAR; then ... and setting VAR to /bin/true or /bin/false [16:25] Sure, I use that sort of idiom as well [16:25] (Though I omit the path prefix) [16:26] cjwatson: I don't trust myself not to have at some time created a true or false somewhere else in the PATH :P [16:29] well, it sees the change in debian/rules :D " checking build system type... Invalid configuration `./autogen.sh': machine `./autogen.sh' not recognized" [16:31] What exactly did you type in debian/rules? [16:32] Oh, blah, sorry, I meant dh_autoreconf ./autogen.sh [16:32] Drop the -- [16:33] I was confused by an unrelated thing in grub2's code [16:35] aha! thanks, I dropped into the chroot and noticed in config.log "$ ./configure --enable-maintainer-mode ./autogen.sh" [16:41] cjwatson: thanks - I've got past the packaging errors now, on to the upstream problems :) [16:41] Cool === blaze` is now known as blaze [19:07] sbuild on/for 18.04, getting a Lintian warning "appstream-metadata-in-legacy-location usr/share/appdata/..." -- but looking at "dpkg -S" seems like that is the place for appdata. Do I need to change this or figure out how to add a lintian override (I've seem people talk about those but never done one) ? [19:07] 20:06 grrr, asked in the wrong channel and only just realised! [19:15] TJ-: https://lintian.debian.org/tags/appstream-metadata-in-legacy-location.html [19:16] All lintian tags have excellent documentation [19:19] alkisg: thanks [19:19] np