| 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:04 |
|---|---|---|
| juliank | it was so obvious, ugh | 08:05 |
| juliank | had to do s/continue/pass/ | 08:05 |
| 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. | 08:06 |
| doko | oSoMoN: I uploaded your packages, plus fonts-liberation2 for the security pocket (no-change upload) | 09:04 |
| 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 | 09:05 |
| === velix_inuse is now known as velix | ||
| === ricab is now known as ricab|bbiab | ||
| doko | oSoMoN: odk/CustomTarget_javadoc.mk:33: recipe for target '/<<PKGBUILDDIR>>/workdir/CustomTarget/odk/docs/java/ref/javadoc_log.txt' failed | 10:50 |
| 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:51 |
| doko | oSoMoN: looks like the missing javadoc backport that we already had for disco | 10:52 |
| === ricab|bbiab is now known as ricab | ||
| 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:02 |
| doko | ta | 11:05 |
| === ricab is now known as ricab|lunch | ||
| 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:55 |
| ahasenack | dh-exec? | 14:56 |
| * ahasenack looks for it | 14:56 | |
| 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 | 14:57 |
| === ricab|lunch is now known as ricab | ||
| 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:08 |
| juliank | I don't remember the analysis | 16:09 |
| juliank | s/suggests/recommends/ | 16:09 |
| infinity | juliank: Not ubiquity itself. It's the top level of that chain. | 16:14 |
| 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:16 |
| 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 | 16:18 |
| === Serge is now known as hallyn | ||
| ahasenack | doko: ok, now I hit the problem you brought up in samba-technical@ | 17:18 |
| ahasenack | doko: do you have a link to the fedora packaging which has the patches? | 17:29 |
| doko | https://src.fedoraproject.org/rpms/samba/blob/master/f/samba.spec | 17:31 |
| 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:32 |
| ahasenack | yeah, just cloned, no patches | 17:38 |
| 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:39 |
| 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:40 |
| doko | no, dh-exec doesn't work with symbols files | 17:41 |
| 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:43 |
| 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:44 |
| 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:48 |
| ahasenack | looks like it's just one | 17:49 |
| ahasenack | hm | 17:49 |
| doko | yes, would just use six lines for that one symbol | 17:51 |
| ahasenack | what about the first line of the symbols file, which is the library name? It has $arch in its name | 17:52 |
| 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:53 |
| doko | like the current libffi is doing that | 17:54 |
| doko | have to run now ... | 17:54 |
| ahasenack | ok, thanks, I'll look at libffi | 17:55 |
| ahasenack | cya | 17:55 |
| ahasenack | doko: 23 symbols files, that ought to be fun :) | 17:59 |
| 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:56 |
| ahasenack | like https://git.launchpad.net/~ahasenack/ubuntu/+source/talloc/tree/debian/python3-talloc.symbols.amd64?h=disco-talloc-2.1.16 | 19:57 |
| doko | ahasenack: yeah, but upstream is insane, and doesn't listen ... | 20:04 |
| ahasenack | the guy from fedora seems aboard | 20:04 |
| ahasenack | not upstream, but if two (three) big distros push for it, we might get it | 20:06 |
| 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:49 |
| 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 | 21:54 |
| seb128 | vorlon, right, unsure what's the best way there | 22:17 |
| === lesshaste is now known as Guest70800 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!