| TJ- | When using sbuild, and a package with source/format "3.0 (git)" do we have to manually add 'git' as a Build-Depends ? | 09:49 |
|---|---|---|
| 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:38 |
| 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 | 14:39 |
| === transfusion3 is now known as transfusion | ||
| cjwatson | TJ-: I really wouldn't use source format 3.0 (git). It was experimental and never got much adoption | 16:10 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| cjwatson | But is it an autoconfy upstream? It probably has a perfectly good make dist if so | 16:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| TJ- | In my shell scripts I do a lot of if $VAR; then ... and setting VAR to /bin/true or /bin/false | 16:24 |
| cjwatson | Sure, I use that sort of idiom as well | 16:25 |
| cjwatson | (Though I omit the path prefix) | 16:25 |
| 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:26 |
| TJ- | well, it sees the change in debian/rules :D " checking build system type... Invalid configuration `./autogen.sh': machine `./autogen.sh' not recognized" | 16:29 |
| cjwatson | What exactly did you type in debian/rules? | 16:31 |
| cjwatson | Oh, blah, sorry, I meant dh_autoreconf ./autogen.sh | 16:32 |
| cjwatson | Drop the -- | 16:32 |
| cjwatson | I was confused by an unrelated thing in grub2's code | 16:33 |
| TJ- | aha! thanks, I dropped into the chroot and noticed in config.log "$ ./configure --enable-maintainer-mode ./autogen.sh" | 16:35 |
| TJ- | cjwatson: thanks - I've got past the packaging errors now, on to the upstream problems :) | 16:41 |
| cjwatson | Cool | 16:41 |
| === blaze` is now known as blaze | ||
| 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:07 |
| alkisg | TJ-: https://lintian.debian.org/tags/appstream-metadata-in-legacy-location.html | 19:15 |
| alkisg | All lintian tags have excellent documentation | 19:16 |
| TJ- | alkisg: thanks | 19:19 |
| alkisg | np | 19:19 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!