=== helio|afk is now known as heliocastro
[08:51] <seb128> hey SRU team, where is the code that generate the 'Autopkgtest regression report' comments/emails?
[08:51] <seb128> sil2100, ^ you probably know?
[08:54] <seb128> sil2100, also could you review the pulseaudio/focal pending SRU, it's a trivial fix to a recent oem patch that landed before release and create a regression with jack headsets, would be nice to see it accept
[08:55] <seb128> sil2100, also accountsservice, another one for a segfault which takes gdm and the session down (also mutter, gnome-shell would be nice but those aren't trivial to review if you want to read the diff so depends how buy you are)
[09:00] <sil2100> seb128: hey! It's in the britney2 code if anything
[09:02] <sil2100> seb128: I'll try to look at some of those, I'm doing SRUs now but I don't know how many more I'll be able to do!
[09:03] <seb128> sil2100, thanks, small annoyance but e.g https://bugs.launchpad.net/ubuntu/+source/evolution-data-server/+bug/1876125/comments/3 the p.c.c url is cut by a new line in tb and such clicking on it doesn't work for me, it's fine on launchpad though
[09:03] <ubottu> Launchpad bug 1876125 in evolution-data-server (Ubuntu Focal) "SRU the current 3.36.2 stable update" [Undecided,Fix committed]
[09:03] <seb128> sil2100, pulseaudio is trivial and accountsservices as well, and they are high impact, please just open the diffs to give them a chance, shouldn't take you long :)
[09:04] <seb128> sil2100, I understand if gnome-shell&co you don't have time for today, no worry
[09:09] <seb128> sil2100, k, so the email / url issue is an ancient launchpad issue, bug #28649
[09:09] <ubottu> bug 28649 in Launchpad itself "mail word wrapping breaks urls and other words" [Low,Triaged] https://launchpad.net/bugs/28649
[09:09] <seb128> at least not your fault :)
[09:14] <ackk> juliank, hi, any chance you could review https://code.launchpad.net/~ack/ubuntu/+source/maas/+git/maas/+ref/snap-channel-2.7-default today?
[09:14] <juliank> ackk: on it
[09:16] <ackk> juliank, thanks!
[09:30] <seb128> sil2100, also gnucash is a one liner fix to the icon so it's valid
[09:56] <seb128> sil2100, thanks!
[09:57] <sil2100> seb128: I think that's as much as I can do today! Since I need to move on to non-SRU work now :)
[09:57] <seb128> sil2100, that's enough to make me happy, thanks again and sorry for the nagging :)
[09:59] <sil2100> No worries, yw!
[09:59] <sil2100> I don't mind being pinged for this stuff, especially that we do have a few packages in the queue
[10:00] <sil2100> I think we all need more hours in a day!
[10:00] <Unit193> Try cutting sleep back to 5 or 6 hours, it helps a bit.
[10:00] <Unit193> (I find less than 4 makes the day a bit long though.)
[11:11] <LocutusOfBorg> vorlon, I fixed inkscape gtk+mm dependency, but I'm left with gdl one. According to build logs, the previous version was embedding gdl while now it is used the system one. Would it be possible to add i386 back to libgdl-3-dev?
[11:11] <LocutusOfBorg> mapreri, ^^ please tell me if I'm wrong
[11:51] <LocutusOfBorg> cjwatson, looks like libpoe-test-loops-perl autopkgtest is now failing because of new perl autodep8. I'm dropping the delta you introduced back in xenial days
[12:08] <steveire> When I run ldd I get this:
[12:08] <steveire> jenkins@0b769a54e699:~/root/workspace/products/build$ ldd /usr/lib/x86_64-linux-gnu/libopencv_imgcodecs.so | grep tiff
[12:08] <steveire>         libtiff.so.5 => /lib/x86_64-linux-gnu/libtiff.so.5 (0x00007fca14345000)
[12:08] <steveire>         libgeotiff.so.5 => /lib/x86_64-linux-gnu/libgeotiff.so.5 (0x00007fca109cc000)
[12:09] <steveire> But when I try to link to the lib, I get this:
[12:09] <steveire> /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libopencv_imgcodecs.so: undefined reference to `TIFFReadRGBAStrip@LIBTIFF_4.0'
[12:09] <steveire> /usr/bin/ld: /lib/x86_64-linux-gnu/libgeotiff.so.5: undefined reference to `_TIFFmemcpy@LIBTIFF_4.0'
[12:09] <cjwatson> locutus_: fine by me
[12:09] <steveire> Note the different SO numbers. Is opencv broken on 20.04?
[12:09] <cjwatson> steveire: I haven't looked in detail, but you can't necessarily assume that the SONAME in the actual library matches the filename
[12:10] <steveire> cjwatson: Ok, nevertheless, linking fails.
[12:10] <cjwatson> Right, it might be broken for some other reason, just not that one :)
[12:11] <steveire> Ok. Known issue?
[12:11] <cjwatson> (I don't mean SONAME, I mean version definitions)
[12:11] <cjwatson> I don't know, sorry, not a libtiff/opencv person myself
[12:11] <cjwatson> # objdump -p /lib/x86_64-linux-gnu/libtiff.so.5 | grep -A2 'Version definitions'
[12:11] <cjwatson> Version definitions:
[12:11] <cjwatson> 1 0x01 0x0bba1ce5 libtiff.so.5
[12:11] <cjwatson> 2 0x00 0x0dfcf290 LIBTIFF_4.0
[12:12] <cjwatson> Have you looked in the bug tracker?
[12:12] <steveire> Not yet
[12:12] <steveire> Does that objdump output mean something relevant?
[12:12] <steveire> Not so familiar with it.
[12:13] <cjwatson> It means that libtiff.so.5 does indeed contain symbol versions ending with @LIBTIFF_4.0, so just confirming my earlier note that the apparently 4 vs. 5 difference is a red herring
[12:13] <steveire> Ok thanks
[12:14] <steveire> Can I somehow tell if TIFFReadRGBAStrip is in the library? nm doesn't work because it's stripped I guess.
[12:14] <cjwatson> nm -D should work
[12:15] <cjwatson> This feels more likely to be a linker invocation bug
[12:15] <cjwatson> Do you have -ltiff on your ld command line after -lopencv_imgcodecs?
[12:19] <cjwatson> (Well, probably a gcc command line in fact, since normally you'd use gcc as the linker, but either way)
[12:21] <steveire> Indeed. I had an old libtiff on my system which the buildsystem was finding.
[12:21] <steveire> Fixed that and the issue is gone, thanks!
[12:22] <cjwatson> Ah good
[12:51] <cpaelzer> hi, is there any minimum amount of cpus I can expect our autopkgtest environments to always have?
[13:01] <danboid> Does zsys plan to support hot-swapping spare ZFS disks?
[13:01] <danboid> zed doesn't seem to be able to do this
[13:34] <suniel> Hi all, I have a board based on Rockchip RK3399 64-bit SOC based on ARMv8A.The board can boot from the following devices:Micro SD, emmc, USB, NVMe SSD.I have installed ubuntu focal fossa with LXDE Display manager.(I have downloadedfocal-base-arm64.tar.gz and installed all the necessary packages). The board boots fine with ubuntu focal fossa
[13:34] <suniel> installed on Micro SD, emmc, USB.I am using Linux kernel 5.5.10 from kernel.org.When the board is booted via NVMe SSD(this NVMe SSD is connected via PCIe on to the main board), the board looses power(powered off) automatically during the bootprocess. This happens and once kernel loads and systemd trying to fully load ubuntuuser space.In the process
[13:34] <suniel> of identifying what is causing the problem, found out that systemd-udevd is the one.when loading rules from udev/rules.d, some of them are creating a problem.so removed all the rules apart from:50-udev-default.rules, 60-drm.rules, 90-console-setup.rules, 60-block.rules60-serial.rules, 99-systemd.rules.By doing the above change, i am able to get a
[13:34] <suniel> basic command prompt. It says LXDE displaymanager is started but I couldnt get display.Can any one please comment on this issue. Thanks
[15:21] <xnox> rs2009:  hi
[16:24] <rbasak> waveform: I'm looking at your u-boot "git ubuntu merge start" failure
[16:27] <rbasak> waveform: import/2019.07+dfsg-1 is correctly an ancestor of debian/sid
[16:27] <rbasak> waveform: but your supplied upload/2019.07+dfsg-1ubuntu1 commit, which was adopted, didn't have import/2019.07+dfsg-1 from Debian as an ancestor
[16:28] <rbasak> So I think your assessement is accurate, but this isn't a bug in git-ubuntu
[16:28] <waveform> rbasak, yup
[16:28] <rbasak> You'll need to rebase by hand - so you can still use the workflow, but you'll have to determine the base by hand, and "merge start" won't help you
[16:28] <waveform> rbasak, (well other than the fact it didn't pick it up on import :)
[16:29] <rbasak> It's not supposed to pick it up on import
[16:29] <rbasak> Your upload tag was trusted on a "developer knows best" basis
[16:29] <waveform> me? know best? ha! :)
[16:29] <rbasak> :)
[16:29] <rbasak> BTW, there's a separate bug whose fix is awaiting review
[16:29] <rbasak> After that I'd like to reimport u-boot again
[16:29] <rbasak> Hopefully that will be the final time
[16:30] <waveform> ok
[16:30] <rbasak> So maybe hold off for a day or two if you're in no hurry?
[16:30] <waveform> sure
[16:30] <rbasak> Thanks
=== heliocastro is now known as helio|afk
[17:39] <Teduardo> Hello, I noticed that if you don't specify a storage configuration in an autoinstall file the usable space in the final install is 1% of the size of the drive. Also it doesn't really follow the default of the installer.
[17:39] <Teduardo> Anyone know which project I should file a bug in?
=== nikow1 is now known as nikow
=== ben_r_ is now known as ben_r