[01:25] <mwhudson> ugh this ffmpeg transition is a bit of a doozy huh
[01:45] <mwhudson> and what is actually going on with pandoc
[02:42] <rbasak> I've been looking into pandoc.
[02:42] <rbasak> It's tied in to various Haskell related build failures
[02:43] <rbasak> The easiest reproducer is the haskell-splitmix FTBFS in proposed since that has few other dependencies
[02:43] <rbasak> The same source succeeds in Debian with nearly the same ghc.
[02:43] <rbasak> /usr/bin/ld.gold: error: dist-ghc/build/System/Random/SplitMix.dyn_o: requires dynamic R_X86_64_PC32 reloc against 'splitmixzm0zi1zi0zi4zm7WezzxDFZZxfp5n4UMHruZZ3s_SystemziRandomziSplitMix_SMGen_con_info' which may overflow at runtime; recompile with -fPIC
[02:44] <rbasak> There are lots of these all over the Haskell stack.
[02:44] <rbasak> I understand what it means but not where it's coming from. Unhelpfully the build log doesn't show the call to the linker.
[02:45] <arraybolt3[m]> This might sound silly, but I can try to help. The package is just called "pandoc", right?
[02:45] <rbasak> The source package is "pandoc" yes
[02:45]  * arraybolt3[m] does local sbuild... should I do it against Jammy or Kinetic?
[02:46] <rbasak> Kinetic (the version in proposed)
[02:47] <arraybolt3[m]> OK. If I come up with anything I'll report back.
[03:40] <arraybolt3[m]> rbasak: Well I got a much different error, but still an error: https://paste.ubuntu.com/p/DZ7SzpMCHq/
[03:40] <arraybolt3[m]> The part that finally died was "hlibrary.setup: No test suites enabled. Did you remember to configure with '--enable-tests'?"
[03:41] <arraybolt3[m]> And the command in the build that triggered it was "Running debian/hlibrary.setup test --builddir=dist-ghc --show-details=direct"
[03:42] <arraybolt3[m]> I notice in what appears to be the configure line: "Running debian/hlibrary.setup configure --ghc -v2 --package-db=/var/lib/ghc/package.conf.d --prefix=/usr --libdir=/usr/lib/haskell-packages/ghc/lib --libexecdir=/usr/lib --builddir=dist-ghc --ghc-option=-optl-Wl,-Bsymbolic-functions --ghc-option=-optl-flto=auto --ghc-option=-optl-ffat-lto-objects --ghc-option=-optl-flto=auto --ghc-option=-optl-Wl,-z,relro
[03:42] <arraybolt3[m]> --haddockdir=/usr/lib/ghc-doc/haddock/pandoc-/ --datasubdir=pandoc --htmldir=/usr/share/doc/libghc-pandoc-doc/html/ --enable-library-profiling --flags=-threaded --ghc-options=+RTS -V0 -RTS -ftests"
[03:42] <arraybolt3[m]> And I see that "--enable-tests" is missing in there, so that may be part of the problem?
[03:43] <arraybolt3[m]> I'm on an Ubuntu Jammy system, compiling for Kinetic, using the kinetic-proposed package of pandoc.
[03:46] <arraybolt3[m]> (This is despite "DEB_ENABLE_TESTS = yes" being present in the debian/rules file, oddly enough.)
[03:51] <arraybolt3[m]> I hacked the debian/rules file to put --enable-tests in there and it appears to have accepted it, so we'll see what happens next.
[04:42] <arraybolt3[m]> After hacking the debian/rules file to get tests enabled, the package appeared to almost build properly - however 8 unit tests failed. https://paste.ubuntu.com/p/qNTZc6hygk/
[04:43] <arraybolt3[m]> The debian/rules file that allowed for near success is: https://paste.ubuntu.com/p/qwWVVWY4CM/
[06:33] <Skuggen> https://people.canonical.com/~ubuntu-archive/proposed-migration/kinetic/update_excuses.html#mysql-8.0 Could someone rerun the failed s390x run for MySQL? Doesn't seem mysql-related
[06:33] <Skuggen> rbasak: ^
[06:35] <RikMills> Skuggen: done
[06:49] <Skuggen> Thanks!
[07:40] <Skuggen> Or maybe it is. sqlite has the same issue, I see
[07:41] <RikMills> the retry passed, so shrug
[07:42] <Skuggen> Oh! I was just looking at the excuses page, which hasn't updated yet
[11:52] <LocutusOfBorg> luis220413, hello, you there?
[11:52] <LocutusOfBorg> LP: #1982554
[11:52] <LocutusOfBorg> can we please have some discussion?
[11:52] <LocutusOfBorg> now ghc is built everywhere, so the transition rebuilds can start
[11:52] <LocutusOfBorg> but I want a solution that can be upstream in Debian too
[12:31] <luis220413> LocutusOfBorg: I am ready
[12:32] <LocutusOfBorg> I wrote a comment on the bug
[12:45] <luis220413> LocutusOfBorg: My solution is to enable -fPIC in devtools, to enhance security.
[12:47] <luis220413> LocutusOfBorg: How can removing -Bsymbolic-functions from the linker flags remove relocation errors?
[12:48] <lucascastro> Hello, I was talking to freeipa development team and they told krb5 api changed a lot from 1.19 to 1.20. Wouldn't it be a good idea keep 1.20 on experimental by now?
[12:48] <rbasak> LocutusOfBorg: are you working on haskell?
[12:49] <luis220413> LocutusOfBorg: Yes, LocutusOfBorg is working on Haskell.
[12:49] <luis220413> *rbasak: Yes, LocutusOfBorg is working on Haskell.
[12:50] <rbasak> I have been looking at this too
[12:52] <lucascastro> wrong window
[12:53] <rbasak> Why does this affect Ubuntu but not Debian?
[12:53] <rbasak> I've not been able to undertand that.
[12:53] <luis220413> LocutusOfBorg: ^
[13:00] <LocutusOfBorg> rbasak, I would like to
[13:01] <rbasak> I'm on +1 maintenance this week. I've been digging into this, but it looks like you have a much better understanding than I do.
[13:01] <rbasak> So how can I help?
[13:01] <LocutusOfBorg> I don't know but removing bSymbokic functions from linker works
[13:01] <rbasak> I'm using haskell-splitmix as my guinea pig as it's quick to fail and has few other dependencies
[13:02] <rbasak> I'm not familiar with haskell-devscript
[13:02] <rbasak> s
[13:02] <rbasak> I extracted the failing linker script it's using on Ubuntu
[13:02] <LocutusOfBorg> rbasak, export DEB_LDFLAGS_MAINT_ADD=-Wl,-Bsymbolic-functions in Debian?
[13:02] <rbasak> That's as far as I got really
[13:03] <rbasak> LocutusOfBorg: no, I mean that if you rebuild (eg.) haskell-splitmix on sid, then it works.
[13:03] <rbasak> On amd64
[13:03] <rbasak> But on kinetic it fails. So where's the difference?
[13:03] <rbasak> The failing linker script on Ubuntu makes mention of lto, so I wonder if it's that.
[13:03] <LocutusOfBorg> as said, disabling lto works
[13:03] <LocutusOfBorg> also disabling bsymbolic
[13:04] <rbasak> Either? Or both?
[13:04] <LocutusOfBorg> for some you need both I guess
[13:04] <LocutusOfBorg> let me check haskell-diff in Debian
[13:04] <rbasak> I tried disabling LTO for haskell-splitmix just before this discussion and it didn't work, but I don't know if I did it right.
[13:05] <LocutusOfBorg> export DEB_LDFLAGS_MAINT_ADD=-Wl,-Bsymbolic-functions
[13:05] <LocutusOfBorg> export DEB_BUILD_OPTIONS=optimize=lto
[13:05] <LocutusOfBorg> I want to try this in Debian
[13:06] <LocutusOfBorg> rbasak, https://launchpadlibrarian.net/614021872/buildlog_ubuntu-kinetic-amd64.haskell-splitmix_0.1.0.4-1build1_BUILDING.txt.gz
[13:06] <LocutusOfBorg> this is haskell-splitmix
[13:06] <LocutusOfBorg> Get:121 http://ftpmaster.internal/ubuntu kinetic-proposed/universe amd64 haskell-devscripts-minimal all 0.16.23 [50.3 kB]
[13:06] <LocutusOfBorg> now, if I retry this build
[13:07] <LocutusOfBorg> it gets the haskell-devscripts from my ppa, with the strip of bsymbolic-functions
[13:07] <LocutusOfBorg> lets see
[13:07] <LocutusOfBorg> Get:121 http://ftpmaster.internal/ubuntu kinetic-proposed/universe amd64 haskell-devscripts-minimal all 0.16.23 [50.3 kB]
[13:07] <rbasak> I used export DEB_BUILD_MAINT_OPTIONS=optimize=-lto
[13:07] <LocutusOfBorg> and didn't work?
[13:08] <rbasak> In haskell-splitmix/debian/rules, to be clear. And that still fails.
[13:08] <LocutusOfBorg> I patch directly hlibrary.mk
[13:08] <rbasak> Yeah I'm not sure the flag got to the right place
[13:08] <rbasak> I haven't checked that yet.
[13:09] <rbasak> splitmix uses cdbs
[13:09] <rbasak> Is it using dpkg-buildflags, etc?
[13:09] <rbasak> Is hlibrary using dpkg-buildflags?
[13:09] <rbasak> etc
[13:10] <LocutusOfBorg> dont know
[13:10] <LocutusOfBorg> but I can say, in Debian, adding the two above lines makes haskell-diff fails in the same way
[13:10] <LocutusOfBorg> (DEB_LDFLAGS_MAINT_APPEND is the correct string btw)
[13:11] <LocutusOfBorg> well, in Debian just doing this: export DEB_LDFLAGS_MAINT_APPEND=-Wl,-Bsymbolic-functions
[13:11] <LocutusOfBorg> is enough to trigger the failure
[13:12] <rbasak> Here's the failing link: https://paste.ubuntu.com/p/td42z5FQCz/
[13:12] <LocutusOfBorg> https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+build/24189678
[13:12] <LocutusOfBorg> and build its
[13:12] <LocutusOfBorg> ok
[13:13] <LocutusOfBorg> so, at the end "export DEB_LDFLAGS_MAINT_APPEND=-Wl,-Bsymbolic-functions" in hlibrary.mk or rules file is enough to reproduce the issue in Debian
[13:13] <LocutusOfBorg> and DEB_LDFLAGS_MAINT_STRIP=-Wl,-Bsymbolic-functions is enough to fix the issue in Ubuntu
[13:14] <LocutusOfBorg> https://launchpadlibrarian.net/614046196/buildlog_ubuntu-kinetic-armhf.haskell-splitmix_0.1.0.4-1build1_BUILDING.txt.gz
[13:14] <LocutusOfBorg> for amd64 and armhf
[13:14] <rbasak> You might not be triggering it for the same reason though.
[13:14] <rbasak> You might be moving some other static library to PIC, therefore requiring PIC elsewhere.
[13:14] <rbasak> (IIUC)
[13:15] <rbasak> Back in a bit.
[13:21] <luis220413> LocutusOfBorg, rbasak: I was busy discussing a security update for jupyter-notebook and will return in 30 minutes.
[13:22] <LocutusOfBorg> ./lib/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm:    my $ldflags_line = run(qw{dpkg-buildflags --get LDFLAGS});
[13:22] <LocutusOfBorg> rbasak, ^^ it uses buildflags
[13:22] <LocutusOfBorg> not cflags I would say?
[13:23] <LocutusOfBorg> so you say that cflags are missing pic, while ldflags arent
[13:45] <LocutusOfBorg> export DEB_SETUP_GHC_CONFIGURE_ARGS = --ghc-options="-fPIC"
[13:45] <LocutusOfBorg>  doesn't fix the issue
[13:49] <LocutusOfBorg> removing pic doesn't help, exporting -pic from DEB_ doesn't help
[13:49] <LocutusOfBorg> exporting LDFLAGS=-no-pic doesn't help
[13:49] <rbasak> AFAICT, when I set DEB_BUILD_MAINT_OPTIONS=optimize=-lto and call "debian/hlibrary.setup build --builddir=dist-ghc", it still puts /usr/lib/gcc/x86_64-linux-gnu/12/liblto_plugin.so in the linker script
[13:49] <LocutusOfBorg> adding pic everywhere doesn't help
[13:50] <rbasak> debian/hlibrary.setup is a binary. Where's the source for it?
[13:51] <LocutusOfBorg>         perl -d:Confess -MDebian::Debhelper::Buildsystem::Haskell::Recipes=/.*/ \
[13:51] <LocutusOfBorg>                 -E 'make_setup_recipe'
[13:51] <LocutusOfBorg>         run(qw{ghc --make}, $shipped_setup, '-o',$ENV{DEB_SETUP_BIN_NAME});
[13:51] <LocutusOfBorg> I guess this is how it gets created
[13:52] <LocutusOfBorg> its created from setup file
[13:53] <LocutusOfBorg> ghc --make Setup.lhs -o debian/hlibrary.setup
[13:53] <LocutusOfBorg> this is how we create it
[13:55] <rbasak> OK so it's entirely what cabal does?
[13:55] <rbasak> Unmodified?
[13:55] <rbasak> What's Setup.lhs vs. Setup.hs?
[14:40] <luis220413> rbasak: .lhs is Literate Haskell (Haskell with comments in LaTeX or another markup language) while .hs is Haskell.
[14:40] <rbasak> Ah thanks
[14:46] <luis220413> LocutusOfBorg: Use -fPIC in compiler flags *and* -pic in compiler-linker or linker flags.
[14:47] <luis220413> Compiler-linker is when you are invoking the compiler just to do the same as a linker.
[14:52] <luis220413> And do not disable -Bsymbolic-functions. I would even recommend -Bsymbolic if it does not break Haskell code.
[15:25] <bluca> slyon: any chance we could pretty preeetty please queue enabling repartd in the next Jammy systemd SRU now that it's enabled in Karmic?
[15:25] <bluca> I've done as much as homework as I can do: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1897932
[15:33] <slyon> bluca: we're not supposed to enable new features after FeatureFreeze or final release. But let me check the details.. if this can be isolated and maintained in universe we might be able to get an exception for that. I need to check with the release team in #ubuntu-release
[15:33] <slyon> (or you could try to get their approval on the LP bug report)
[15:34] <slyon> bluca: like, we cannot ship it in the 'systemd' package as proposed right now. that's most probably a no-go
[15:34] <bluca> it's a single new command line executable, completely inert until someone calls it
[15:35] <bluca> no functionality/runtime behaviour is affected at all
[15:36] <slyon> could it be shipped as a separate systemd-repartd package, without any dependency pulling it into the "main" component (and therefore the default installation of any ubuntu installation out there)?
[15:36] <bluca> yes I suppose it could - but it would be a divergence from debian and karmic
[15:36] <bluca> in debian and karmic it's in the main pkg
[15:40] <bluca> it's also covered by autopkgtest + build time unit tests
[15:50] <slyon> right, we would need some "Replaces:" in kinetic to "merge" it back into the main package after an upgrade...
[15:50] <slyon> let me try to ask the relevant people, as I do not have the powers to make that change myself
[15:50] <bluca> thank you
[15:51] <bluca> I can update the MR if that's the way it needs to go
[15:58] <slyon> thanks. But maybe let's first try to figure out if that could be accepted at all before putting more work into this
[15:58] <bluca> sounds good
[23:44] <mwhudson> well ok https://github.com/dstndstn/astrometry.net/blob/main/configure
[23:47] <sarnold> Ok
[23:47] <sarnold> https://github.com/dstndstn/astrometry.net/blob/main/Makefile#L58
[23:48] <sarnold> that line, pkg-config --version || echo ...   probably saves them lots of time; I've lost track of how many people missed installing pkg-config when building things and then have *no* idea how to handle the errors that pop out