[08:04] <juliank> seems I messed up the livecd-rootfs change yesterday - no packages are marked as automatically installed by the minimize-manual script. Just uploaded a fix :)
[08:05] <juliank> it was so obvious, ugh
[08:05] <juliank> had to do s/continue/pass/
[08:06] <juliank> infinity: turns out we can't really test the change either, as nothing seems to pull in ubiquity from a metapackage in disco, so its dependencies never get marked in the first place.
[09:04] <doko> oSoMoN: I uploaded your packages, plus fonts-liberation2 for the security pocket (no-change upload)
[09:05] <oSoMoN> doko, I saw that, thanks! there was a suspicious amd64 build failure in the PPA (all other arches built fine), I retried the build
=== velix_inuse is now known as velix
=== ricab is now known as ricab|bbiab
[10:50] <doko> oSoMoN: odk/CustomTarget_javadoc.mk:33: recipe for target '/<<PKGBUILDDIR>>/workdir/CustomTarget/odk/docs/java/ref/javadoc_log.txt' failed
[10:51] <oSoMoN> doko, yes, that's the same error as last night, looking into it now
[10:51] <doko> javadoc: error - The code being documented uses modules but the packages defined in http://java.sun.com/j2se/1.5/docs/api/ are in the unnamed module.
[10:52] <doko> oSoMoN: looks like the missing javadoc backport that we already had for disco
=== ricab|bbiab is now known as ricab
[11:02] <oSoMoN> doko, so https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/commit/ff9d43e60d872a54a0982b3572e6f2085c09ddf5 should fix it, I'll add that patch and re-upload to the PPA
[11:05] <doko> ta
=== ricab is now known as ricab|lunch
[14:55] <ahasenack> what's the trick again to use a variable like $ARCH in debian/<pkg>.install files?
[14:55] <ahasenack> it was another debhelper iirc
[14:55] <ahasenack> or should I just use * instead of the arch name?
[14:55] <ahasenack> usr/lib/*/libpytalloc-util.cpython-37m-x86-64-linux-gnu.so.*
[14:56] <ahasenack> dh-exec?
[14:56]  * ahasenack looks for it
[14:57] <ahasenack> #!/usr/bin/dh-exec
[14:57] <ahasenack> usr/lib/*/pmdk_debug/libpmem.so.1* usr/lib/${DEB_HOST_MULTIARCH}/pmdk_dbg/
[14:57] <ahasenack> dh-exec
[14:57] <ahasenack> k
=== ricab|lunch is now known as ricab
[16:08] <infinity> juliank: ubiquity isn't pulled in via metapackage in *any* release.  If you're operating under the assumption that that's the cause of the bug, your assumption's wrong. :)
[16:08] <juliank> infinity: well, there was some suggests or something from somewhere in a cycle or something
[16:09] <juliank> I don't remember the analysis
[16:09] <juliank> s/suggests/recommends/
[16:14] <infinity> juliank: Not ubiquity itself.  It's the top level of that chain.
[16:16] <juliank> infinity: The chain was xubuntu-desktop -> indicator-messages -> ubiquity-frontend-gtk (via provides inidicator-renderer) -> ubiquity -> cryptsetup & lvm
[16:16] <juliank> some of those are recommends, some are depends
[16:16] <juliank> oh, maybe I should ook at the xubuntu build log
[16:18] <juliank> yeah, that one is visiting ubiquity, but that does not happen in ubuntu itself
[16:18] <infinity> juliank: Ahh, kay.  The metapackage isn't what installed it, but it happened to provide something for somehting in the meta's chain.  Check.
[16:18] <juliank> yup
=== Serge is now known as hallyn
[17:18] <ahasenack> doko: ok, now I hit the problem you brought up in samba-technical@
[17:29] <ahasenack> doko: do you have a link to the fedora packaging which has the patches?
[17:31] <doko> https://src.fedoraproject.org/rpms/samba/blob/master/f/samba.spec
[17:32] <doko> ahasenack: https://src.fedoraproject.org/  but as I wrote, they don't have the patches. the one rh guy pointed to the old patch
[17:38] <ahasenack> yeah, just cloned, no patches
[17:39] <ahasenack> doko: without those patches, do we have a way out of this?
[17:39] <ahasenack> something like a symbol file per arch, if that is even enough to fix it?
[17:40] <doko> dh-exec?
[17:40] <doko> yes, per arch should work as well
[17:40] <ahasenack> no, the symbols having the architecture
[17:40] <ahasenack> or did you mean a dh-exec trick for the symbols file?
[17:40] <doko> (arch=amd64)<symbol>
[17:41] <doko> no, dh-exec doesn't work with symbols files
[17:43] <ahasenack> doko: so I would include symbols for all arches in the symbols file, but prefix them with (arch=<arch>)? or what is the trick?
[17:43] <ahasenack> do we have something like this already in the archive somewhere?
[17:44] <doko> libffi.so.7 libffi7 #MINVER#
[17:44] <doko>  (symver)LIBFFI_BASE_7.0 3.3~20180313
[17:44] <doko>  (symver)LIBFFI_CLOSURE_7.0 3.3~20180313
[17:44] <doko>  (symver|arch=!hppa !ia64 !m68k !riscv64 !sh4)LIBFFI_GO_CLOSURE_7.0 3.3~20180313
[17:44] <doko>  (symver|arch=!hppa !ia64 !m68k !mips !mipsel !mips64el !powerpc !powerpcspe !ppc64 !ppc64el !riscv64 !sh4)LIBFFI_COMPLEX_7.0 3.3~20180313
[17:44] <doko>  (symver)LIBFFI_BASE_7.1 3.3~20180313
[17:48] <ahasenack> doko: I wonder if the #include trick could help. From the manpage:
[17:48] <ahasenack>             (arch=amd64 ia64 alpha)#include "package.symbols.64bit"
[17:48] <ahasenack> although
[17:49] <ahasenack> looks like it's just one
[17:49] <ahasenack> hm
[17:51] <doko> yes, would just use six lines for that one symbol
[17:52] <ahasenack> what about the first line of the symbols file, which is the library name? It has $arch in its name
[17:53] <doko> argh
[17:53] <ahasenack> specifically
[17:53] <ahasenack> libpytalloc-util.cpython-37m-x86-64-linux-gnu.so.2 python3-talloc #MINVER#
[17:53] <ahasenack>  PYTALLOC_UTIL.CPYTHON_37M_X86_64_LINUX_GNU_2.1.16@PYTALLOC_UTIL.CPYTHON_37M_X86_64_LINUX_GNU_2.1.16 2.1.16
[17:53] <doko> so, just six separate symbols files
[17:53] <ahasenack> do we need some sort of foo.symbols.in file and render that?
[17:54] <doko> like the current libffi is doing that
[17:54] <doko> have to run now ...
[17:55] <ahasenack> ok, thanks, I'll look at libffi
[17:55] <ahasenack> cya
[17:59] <ahasenack> doko: 23 symbols files, that ought to be fun :)
[19:56] <ahasenack> doko: got it done for talloc, using per-arch symbols files, and an #include directive to keep it less repetitive, seems fine
[19:56] <ahasenack> thanks for the tip
[19:57] <ahasenack> like https://git.launchpad.net/~ahasenack/ubuntu/+source/talloc/tree/debian/python3-talloc.symbols.amd64?h=disco-talloc-2.1.16
[20:04] <doko> ahasenack: yeah, but upstream is insane, and doesn't listen ...
[20:04] <ahasenack> the guy from fedora seems aboard
[20:06] <ahasenack> not upstream, but if two (three) big distros push for it, we might get it
[21:49] <seb128> vorlon, oh, you also mentioned curl on the desktop iso yesterday, it looks like it's due to gettext which Recommends curl | wget, if we prefer wget we should have it listed first
[21:54] <vorlon> seb128: well, wget should have been pulled in already earlier due to it being in standard; so it might be we should do some seed surgery rather than adding a delta on gettext
[22:17] <seb128> vorlon, right, unsure what's the best way there
=== lesshaste is now known as Guest70800