=== genii is now known as genii-core
[04:10] <mwhudson> anyone want to do some reviews https://code.launchpad.net/~mwhudson/ubuntu-seeds/+git/ubuntu/+merge/403848 https://code.launchpad.net/~mwhudson/casper/+git/casper/+merge/403846
=== hmr is now known as hmr4c
[08:15] <ricotz> doko, hi :), it looks like there is a regression introduced with openjdk-lts/impish on armhf which is triggered by libreoffice autopkgtests https://autopkgtest.ubuntu.com/packages/libr/libreoffice/impish/armhf
[08:19] <doko> ricotz, I see all failures with 7.1.4rc2, none with 7.1.3. is this coincidence?
[08:20] <ricotz> doko, seb128 meant to do a retry with 1:7.1.3-0ubuntu1 but it seems it wasn't actually doing that
[08:20] <ricotz> I have run autopkgtest of the same libreoffice source in hirsute/armhf which passed
[08:21] <ricotz> https://autopkgtest.ubuntu.com/results/autopkgtest-hirsute-libreoffice-libreoffice-prereleases/hirsute/armhf/libr/libreoffice/20210607_175937_445f4@/log.gz
[08:22] <ricotz> while the log shows a crash of java I would suspect the openjdk-lts update
[08:31] <doko> ricotz, please can you include the hs_err log file into the artifacts of the autopkg tests?
[08:37] <ricotz> doko, I will have to figure out how to do that
[08:37] <ricotz> doko, if you can give me a pointer please do so
[08:39] <ricotz> doing an immediate rebuild of libreoffice for that seems not reasonable, a patch can be included into the 7.1.4 final build
[11:06] <cpaelzer> hi seb128, I've seen that you uploaded https://launchpad.net/ubuntu/+source/extractpdfmark/1.1.0-1.1build1 for the new poppler
[11:07] <cpaelzer> have you / are you planning to also upload  gambas3, calligra, kitinerary, openboard and scribus ?
[11:07] <cpaelzer> I've not yet seen these uploads, but you might prepare or test them so I want to avoid duplicating that work
[11:14] <cpaelzer> Oh I just realized that poppler is a desktop subscribed main package
[11:14] <cpaelzer> that explains why you unblock it seb128, thanks :-)
[11:15] <cpaelzer> I guess I'll let my +1 eyes move on to something else knowing that you will handle poppler
[11:51] <seb128> cpaelzer, right,that's being handled but thanks for checking!
[13:54] <kanashiro> doko, I sent a MP your way to update the lto-disabled-list package, feedback is appreciated especially if this is the right way to do it
[14:12] <icey> rafaeldtinoco: hey - wanted to follow up about the OpenStack packageset emails - got a few we identified late last week in preparing for the OPenStack milestone that just went out
[14:13] <rafaeldtinoco> icey: hey o/
[14:13] <rafaeldtinoco> icey: yep, ive been keeping your emails (2) inbox
[14:13] <rafaeldtinoco> i'll try to do it today (together with the entire packageset)
[14:13] <rafaeldtinoco> sorry for the delay there =)
[14:14] <icey> I appreciate it! No worries on the delay, just wanted to make sure the process was still working for you :)
[14:14] <rafaeldtinoco> it is!
[14:14] <rafaeldtinoco> thx for checking
[14:15] <seb128> doko, what's the rational for adding delta to packages to disable lto vs listing them in lto-disabled-list ? asking for ipp-usb which could be synced without that change
[15:49] <toabctl> bdmurray, could you please move livecd-rootfs for bionic from the queue to -proposed?
[15:58] <bdmurray> toabctl: I've added it to my personal SRU queue for the day
[15:58] <toabctl> bdmurray, thanks a lot!
[16:36] <bdmurray> toabctl: Why aren't other releases affected by bug 1930686?
[16:36] <ubottu> Bug 1930686 in livecd-rootfs (Ubuntu Bionic) "Do not include /dev device node filles in OCI rootfs tarballs" [Undecided, New] https://launchpad.net/bugs/1930686
[16:37] <toabctl> bdmurray, because that was correctly done within https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/1926732
[16:37] <ubottu> Launchpad bug 1926732 in livecd-rootfs (Ubuntu Hirsute) "Add ubuntu-oci project for building OCI-ready tarballs with livecd-rootfs" [Undecided, Fix Released]
[16:38] <toabctl> bdmurray, eg. for hirsute (see https://git.launchpad.net/livecd-rootfs/commit/?id=6270e4d7ad3ff58ae966ea9572be0a42c2033a40 ), the change for the new ubuntu-oci project was correct. it was just this one line missing in bionic because the code structure changed a bit since then
[16:38] <ubottu> Commit 6270e4d in livecd-rootfs "Merge branch 'sru-hirsute-lp1926732' into ubuntu/hirsute"
[16:39] <bdmurray> toabctl: okay thanks for the clarification
[16:40] <bdmurray> toabctl: Also it looks like there is some cruft in the upload http://launchpadlibrarian.net/542776162/livecd-rootfs_2.525.54_2.525.55.diff.gz
[16:48] <bdmurray> toabctl: I'll fix that though
=== pizzaiolo is now known as pizza
[17:24] <toabctl> bdmurray, cruft? where? the link you sent looks good to me. or am I missing something?
[17:32] <bdmurray> toabctl: this line "Only in /tmp/tmp6sglmwyh/I8_VqK1Mcg/livecd-rootfs-2.525.55/live-build/ubuntu-server/includes.binary/overlay/usr/lib/systemd/system: getty@tty1.service"
=== genii-core is now known as genii
[20:42] <cipherboy> So about debugging packages... I've pulled postfix on 18.04's `dbgsym` packages and run `apt source` and specified the path in `gdb` via the `dirs` command. I've gotten some more function symbols than before, but gdb can't seem to get source mapping information at all for this package (e.g., source doesn't show up in the gdb tui and backtraces are lacking the usual
[20:42] <cipherboy> ../path/to/source.c:<linenum> and parameters information...). Is this a bug in postfix's patching? How would I go about uh, debugging why the dbgsym package doesn't seem to be giving me useful information?
[20:43] <cipherboy> The `dbgsym` + `apt source` process worked fine for OpenSSL, so that's why I'm leaning towards an issue with Postfix? I dunno. :)
[20:53] <cipherboy> https://pastebin.ubuntu.com/p/s7ddcbZjDq/ in case anyone's curious what I'm seeing -- OpenSSL are the top two functions, the rest is postfix/smtpd and doesn't have much debug info (though, more than before installing the dbgsym packages for postfix! -- it was lacking interior function names before).
[20:54] <TJ-> cipherboy: have you added all the source paths with "directory ..." ?
[20:54] <cipherboy> TJ-: Yep, mentioned that in the first comment. Colon separated.
[20:55] <cipherboy> Added base directory and several nested directories just to be sure I got everything... I can paste the list if you want.
[20:56] <TJ-> cipherboy: i've hit that in the past; found it needed me to list *every* directory not just parents
[20:57] <cipherboy> TJ-: Every for the entire project or just the subset of the program I'm debugging?
[20:58] <TJ-> cipherboy: if I recall correctly, for every possible file incluing headers
[21:00] <TJ-> I know I was amazed and very annoyed it didn't seem to be able to deduce, e.g. "directory src" wouldn't find a #include "include/myheader.h" I had to do "directory src:src/include"
[21:01] <cipherboy> Hmm no dice. Lemme paste again.
[21:01] <TJ-> cipherboy: have you read https://sourceware.org/gdb/onlinedocs/gdb/Source-Path.html
[21:02] <sergiodj> cipherboy: you might want to try 'set substitute-path'
[21:02] <sergiodj> this is what I generally use when debugging from debs
[21:03] <TJ-> ^^^ was just about to mention that
[21:03] <TJ-> cipherboy: see https://sourceware.org/gdb/onlinedocs/gdb/Source-Path.html#set-substitute_002dpath
[21:03] <cipherboy> TJ-: Yeah, I've used gdb a decent amount, and I'm surprised that it works fine for OpenSSL but not postfix, which is why I'm curious if there's a packaging difference I wouldn't know to look for.
[21:03] <TJ-> cipherboy:  it depends on what's embedded in the object files I guess
[21:05] <cipherboy> sergiodj: But wouldn't substitute-path only work if the debug symbols actually contained path entries? If you look at my bin, it doesn't look like I'm getting _any_ paths at all, and most of the time GDB will still give me that info if it has it --- even if there's no source present on dirs.
[21:07] <cipherboy> I have no way of knowing what path to substitute with, since gdb isn't even telling me what the paths for the functions are; it only tells me which object file contains the symbol.
[21:08] <sergiodj> cipherboy: postfix is trickier to debug than normal programs because of the way the services run in a chroot.  that may be the problem you're facing here
[21:08] <sergiodj> did you check http://www.postfix.org/DEBUG_README.html ?
[21:09] <cipherboy> sergiodj: Yep I started there. :-) I have gdb from inside screen and -D specified in master.cf to smtpd. It is a minimal install to try and debug this issue with OpenSSL FIPS package that occurs with Postfix and not other servers, which is why I really want to debug Postfix itself :-/
[21:10] <cipherboy> main.cf has: debugger_command = PATH=/bin:/usr/bin:/sbin:/usr/sbin; export PATH; HOME=/root; export HOME; screen -e^tt -dmS $process_name gdb $daemon_directory/$process_name $process_id & sleep 2
[21:10] <cipherboy> Aha!
[21:10] <cipherboy> https://pastebin.ubuntu.com/p/9CFNDtTCcy/
[21:10] <sergiodj> right, so if you're inside the chroot you probably don't have access to the debug symbols that you've just installed outside...?
[21:11] <cipherboy> > Reading symbols from /usr/lib/postfix/sbin/smtpd...Reading symbols from /usr/lib/debug/.build-id/9b/c4e924c12d39a5f8577f7bf3432ccafc11bed9.debug...(no debugging symbols found)...done.
[21:11] <cipherboy> sergiodj: This isn't a production config, there's no chroot.
[21:11] <sergiodj> ah, it couldn't find the debug symbol
[21:11] <cipherboy> sergiodj: But it can for OpenSSL: Reading symbols from /usr/lib/x86_64-linux-gnu/libssl.so.1.1...Reading symbols from /usr/lib/debug/.build-id/4d/c99284f0de8d49c61e453175f32ab34b46bcb8.debug...done.
[21:11]  * cipherboy sighs
[21:12] <sergiodj> cipherboy: version mismatch between the postfix package and its dbgsym counterpart?
[21:12] <cipherboy> sergiodj: Sadly, lines 2 and 5 seem to imply not: https://pastebin.ubuntu.com/p/s7ddcbZjDq/ :/
[21:13] <cipherboy> And apt show postfix says it is coming out of main: APT-Sources: http://us.archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages
[21:13] <cipherboy> And on postfix-dbgsym it gives: APT-Sources: http://ddebs.ubuntu.com bionic-updates/main amd64 Packages
[21:13] <cipherboy> So unless there's a mismatch between ddebs.ubuntu.com and us.archive.ubuntu.com... I'm at a loss.
[21:14] <sergiodj> let me check locally
[21:14] <cipherboy> I suppose I could try grabbing dbgsym from Launchpad and comparing them to the dbgsym from ddebs?
[21:14] <sergiodj> if we had debuginfod, this whole conversation would be moot
[21:14] <sergiodj> sigh...
[21:15] <cipherboy> sergiodj: Fedora just put that in and I hear it broke what used to be working ;-)
[21:15] <sergiodj> I maintain the Debian debuginfod service, and it's working wonders!
[21:16] <sarnold> wooooo
[21:17] <sergiodj> but we'll get there.  maybe next cycle :)
[21:17] <sarnold> double woo :)
[21:17] <cipherboy> \o/ \o/
[21:21] <sergiodj> cipherboy: indeed, smtpd's build-id is not present in the dbgsym.  I'm checking in other places to see if I can find it
[21:22] <cipherboy> sergiodj: Hmmm, the path mentioned there _does_ exist... Wonder if I can force it to load?
[21:22] <sergiodj> ah, I see it there
[21:29] <cipherboy> sergiodj: The file seems alright? /usr/lib/debug/.build-id/3f/aa67e6a05ec7c431510aa282e437d189a93558.debug: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=3faa67e6a05ec7c431510aa282e437d189a93558, not stripped
[21:30] <cipherboy> the not stripped being the important part :-)
[21:32] <sergiodj> cipherboy: this file seems strange because it doesn't have any DWARF information
[21:33] <cipherboy> \o/ I'm not crazy!
[21:34] <sergiodj> if you look at the message, GDB is actually reading the file
[21:34] <sergiodj> but it can't find any debug symbols in it
[21:34] <sergiodj> which is confirmed by eu-readelf
[21:35] <cipherboy> sergiodj: So, it seems like I file a postfix packaging bug and hope the maintainer can help out? :)
[21:35] <sergiodj> cipherboy: yeah, although I find it unlikely that you will see fix for this in bionic :-/
[21:36] <cipherboy> Of course, but good to get it fixed going forward and documented. Also good to know I should just rebuild postfix with better debugging myself rather than keep trying to debug the package as-is.
[21:36] <sergiodj> cipherboy: +1
[21:39] <cipherboy> sergiodj: Well, thank you very much! I learned something today :-)
[21:40] <sergiodj> cipherboy: sorry we couldn't make it work!
[21:44] <cipherboy> sergiodj: https://bugs.launchpad.net/ubuntu/+source/postfix/+bug/1931306
[21:44] <ubottu> Launchpad bug 1931306 in postfix (Ubuntu) "bionic: postfix-dbgsym package lacks DWARF information" [Undecided, New]
[21:45] <sergiodj> cipherboy: thanks!