[07:26] <abeato> anybody knows why the hugepages package is not in focal anymore (https://bugs.launchpad.net/ubuntu/+source/libhugetlbfs/+bug/1873103)?
[07:29] <Unit193> Try libhugetlbfs-bin?
[07:30] <abeato> it is not found either
[07:31] <abeato> ah, wait, it should be there
[07:34] <abeato> thanks
[07:34] <Unit193> Sure thing.
[09:56] <mwhudson> huh maybe glib really is causing a regression here https://autopkgtest.ubuntu.com/packages/s/sbd/groovy/amd64
[09:58] <xnox> doko:  so gcc-10/binutils are next? but when can i do libffi? or shall we wait on response from upstream?
[10:04] <doko> xnox: binutils 2.35 already is in groovy. gcc-10 is not related. which soname do you want to use?
[10:05] <xnox> doko:  .so.8 and bash upstream to bump it to .so.9 if they break it between now and going forward.
[10:06] <xnox> doko:  that is take current git snapshot and roll with it.
[10:08] <doko> no, that would assume a decision on upstream. either don't bump the soname, and change the package name to libffi7-1, or bump it to 80, and change the package name to libffi80
[10:58] <seb128> mwhudson, could be really buggy but it seems it has been forced hinted now...
[10:58] <Laney> whoops, I hinted and then unhinted it, guess I was too late with that
[10:59] <Laney> but there was another retry since which also failed, sooooo
[12:48] <xnox> doko:  but upstream master has bumped soname
[12:49] <xnox> doko:  so their master is 8, and package name should be libffi8. I guess i want it to be explicit, so should email them.
[12:54] <ahasenack> rbasak: hi, I have a packaging question
[12:54] <ahasenack> rbasak: when adding a d/<package>.maintscript file to a package that has, let's say, just d/postinst
[12:55] <ahasenack> but not the other d/postrm, d/prerm, etc files
[12:55] <ahasenack> I suppose I have to add them with the #DEBHELPER# marker, so that dpkg-maintscript-helper can do its job?
[12:55] <rbasak> IIRC, you don't.
[12:55] <rbasak> debhelper will create the ones that don't exist
[12:55] <doko> xnox: it's not a release, you don't know if it will change until the release
[12:55] <rbasak> Easy enough to verify in the built deb, but I'm pretty sure
[12:56] <ahasenack> rbasak: hm, create when? At build time, and ship in the binary?
[12:56] <rbasak> At build time, into the binary - without changing the source
[12:58] <ahasenack> thanks, I'll verify
[13:12] <xnox> ahasenack:  postinst will be installed into the main package regardless of whether it has a #DEBHELPER# marker or not.
[13:12] <ahasenack> xnox: postinst is fine, I was wondering about the others that dpkg-maintscript-helper would need to touch, if they don't exist in the source package
[13:12] <xnox> ahasenack:  for example people omit that marker on purpose, to prevent from debhelper injecting its snippets, because they are too large / have deps not avialable / are borken / etc.
[13:13] <xnox> ahasenack: if you create .maintscript it's enough, it is smart.
[13:13] <ahasenack> nice
[13:13] <cjwatson> You definitely don't need to add empty files with #DEBHELPER# markers, indeed.
[13:13] <cjwatson> (Otherwise-empty, I mean)
[13:13] <ahasenack> that's what I was wondering about, if I had to add the "template" files with #DEBHELPER#
[13:13] <xnox> ahasenack:  note that postinst is _an override_ / complete replacement.
[13:13] <xnox> ahasenack:  and #DEBHELPER# is like "but yeah, please ressurect the stock snippets"
[13:14] <cjwatson> ahasenack: This is documented in debhelper(7) - please read
[13:14] <xnox> and put them on this line please.
[13:14] <cjwatson> "Automatic generation of Debian install scripts"
[13:15] <ahasenack> "If a script does not exist at all and debhelper needs to add something to it, then debhelper will create the complete script." <-- that settles it, thanks
[23:47] <mwhudson> dpkg-source: warning: source directory 'pam' is not <sourcepackage>-<upstreamversion> 'pam-1.1.8'
[23:47]  * mwhudson stares
[23:51] <mwhudson> uh pam really is a native package in bionic?