[09:49] <TJ-> 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] <alkisg> cyphermox: hi, while developing ltsp-next, I noticed that in 19.04 initramfs, ./etc/dhcp/dhclient-enter-hooks.d/config writes:
[14:38] <alkisg> echo "IPV4DNS0=$new_domain_name_servers" >> /run/net-$interface.conf
[14:38] <alkisg> I.e. all DNS servers (in my case 3) in IPV4DNS0; this makes netplan show some errors
[14:39] <alkisg> 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
[16:10] <cjwatson> TJ-: I really wouldn't use source format 3.0 (git).  It was experimental and never got much adoption
[16:12] <cjwatson> 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] <TJ-> 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] <cjwatson> I just did :)
[16:13] <cjwatson> Oh, missing tarball
[16:13] <TJ-> 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] <cjwatson> Do upstream not make releases?
[16:13] <TJ-> cjwatson: no, and no tags in git either
[16:14] <cjwatson> Well then you do need to produce one, but that's not really a Debian question
[16:14] <cjwatson> No make dist or equivalent?
[16:14] <TJ-> cjwatson: its network-manager-wireguard https://github.com/max-moser/network-manager-wireguard
[16:14] <cjwatson> I am not going to look
[16:14] <cjwatson> Other things to do
[16:14] <TJ-> cjwatson: from what I can tell he copied the build system from network-manager-openvpn
[16:14] <cjwatson> I know nothing of the specifics
[16:15] <cjwatson> You basically just want a tarball that has say network-manager-wireguard/ at the top level
[16:15] <TJ-> I can't find any docs on how to deal with this when there is no upstream release/tarbal/tags
[16:15] <cjwatson> Exact naming doesn't really matter
[16:15] <cjwatson> You could try git archive
[16:15] <TJ-> 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] <cjwatson> But is it an autoconfy upstream?  It probably has a perfectly good make dist if so
[16:17] <cjwatson> Anyway, as long as it's a tarball that pretty much unpacks to what you get from git, it should do
[16:17] <cjwatson> (except for the .git itself)
[16:17] <TJ-> 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] <TJ-> Yes, it has an autogen.sh, and configure.ac
[16:17] <cjwatson> If there's an autogen.sh then you should tell dh_autoreconf to run that
[16:18] <cjwatson> dh_autoreconf -- ./autogen.sh
[16:18] <cjwatson> In an override_dh_autoreconf rule
[16:18] <TJ-> 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] <TJ-> ahhhh, specific call?
[16:18] <TJ-> thanks
[16:18] <cjwatson> man dh_autoreconf says no such thing
[16:18] <cjwatson> It says that it calls autoreconf -f -i
[16:19] <cjwatson> Which is not necessarily the same thing as a custom autogen.sh if a package has one of those
[16:19] <TJ-> it does
[16:19] <cjwatson> See the bit under OPTIONS starting with "program -- params"
[16:20] <cjwatson> grub2 uses "dh_autoreconf -- ./autogen.sh" in its debian/rules because the autogen.sh is a specialised custom thing
[16:20] <TJ-> it says "export LIBTOOLIZE = true" - I thought that would include the intltoolize :)
[16:20] <cjwatson> Er no
[16:20] <cjwatson> Not even a little bit
[16:20] <TJ-> cjwatson: OK, now it makes sense !
[16:20] <TJ-> let me try your override command, there is already one in place but not with that on it
[16:20] <cjwatson> autoreconf(1) doesn't have any integration for intltoolize
[16:21] <cjwatson> So no simple environment variable setting will do what you're looking for
[16:21] <TJ-> cjwatson: thanks, it's been a weekend of confusion heaped on confusion so far
[16:21] <cjwatson> (Also, slightly confusingly, "export LIBTOOLIZE = true" actually means "run 'true' instead of 'libtoolize'", i.e. *disable* libtoolize)
[16:22] <TJ-> cjwatson: yeah, I got that nuance
[16:22] <TJ-> I was surprise it wasn't 'false' :)
[16:22] <cjwatson> I imagine that would cause autoreconf to run false and then bail out because its exit code is non-zero
[16:23] <TJ-> I thought likewise ... return codes do turn binary/bool results on their head :)
[16:23] <cjwatson> Lots of ways to fail, only one way to succeed
[16:23] <cjwatson> is perhaps an easy way to remember it
[16:23] <TJ-> indeed, and I've failed in every way possible this weekend!
[16:24] <TJ-> In my shell scripts I do a lot of if $VAR; then ... and setting VAR to /bin/true or /bin/false
[16:25] <cjwatson> Sure, I use that sort of idiom as well
[16:25] <cjwatson> (Though I omit the path prefix)
[16:26] <TJ-> 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] <TJ-> well, it sees the change in debian/rules :D " checking build system type... Invalid configuration `./autogen.sh': machine `./autogen.sh' not recognized"
[16:31] <cjwatson> What exactly did you type in debian/rules?
[16:32] <cjwatson> Oh, blah, sorry, I meant dh_autoreconf ./autogen.sh
[16:32] <cjwatson> Drop the --
[16:33] <cjwatson> I was confused by an unrelated thing in grub2's code
[16:35] <TJ-> aha! thanks, I dropped into the chroot and noticed in config.log "$ ./configure --enable-maintainer-mode ./autogen.sh"
[16:41] <TJ-> cjwatson: thanks - I've got past the packaging errors now, on to the upstream problems :)
[16:41] <cjwatson> Cool
[19:07] <TJ-> 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] <TJ-> 20:06 <TJ-> grrr, asked in the wrong channel and only just realised!
[19:15] <alkisg> TJ-: https://lintian.debian.org/tags/appstream-metadata-in-legacy-location.html
[19:16] <alkisg> All lintian tags have excellent documentation
[19:19] <TJ-> alkisg: thanks
[19:19] <alkisg> np