=== xclaesse5 is now known as xclaesse === meetingology` is now known as meetingology [06:07] Good morning [06:27] morning jibel [06:29] Hi callmepk [07:05] good morning desktoppers [07:11] Salut oSoMoN [07:11] hi oSoMoN [07:16] hey oSoMoN, jibel, callmepk, how are you? [07:17] seb128, I am fine, just completed my morning class... [07:19] salut jibel, seb128 [07:19] hey callmepk [07:20] I'm doing alright, caught in the morning rush to take my daughters to school… [07:37] Salut seb128 [08:11] morning jibel callmepk oSoMoN seb128 [08:14] Hi marcustomlinson [08:32] good morning [08:35] hey didrocks [08:38] hey marcustomlinson [08:44] Salut didrocks [08:44] salut jibel [08:49] hi marcustomlinson [09:02] heya [09:04] hey Laney [09:30] marcustomlinson: I know you did some work a while back on shrinking snaps, so you might find this interesting: https://github.com/snapcore/snapcraft/pull/3413 [09:51] callmepk, did you see my review comments on the wslu merge request? [10:01] jamesh: nice! what about dependencies that are linked at runtime though? [10:02] dlopen() and the like [10:03] marcustomlinson: it tries to add plugin-style shared libraries to the starting kernel when determining what libraries are used. [10:04] marcustomlinson: at first I was using the heuristic of "elf files without sonames", but that didn't work so well, so the current version is "elf files not directly in a lib/ or lib/${arch_triplet} directory" [10:05] which also isn't perfect, but gets closer [10:05] ah, very cool [10:07] it turns out there are a lot of dlopen() style plugins that have a soname set, and a few libraries linked with DT_NEEDED without a soname [10:07] it's a bit of a mess [10:20] oh absolutely it’s a mess [10:23] seb128, yep I see it, I am right now switching to the patch method on wslutilities/wslu.git at ubuntu/master branch, would that be better? [10:24] callmepk, yes, better to the use the upstream patch if possible [11:14] ricotz, FYI, I just pushed 2 revisions to the firefox-beta.xenial branch (and the corresponding package to the firefox-next PPA): I did some patch cleanup, and updated the test expectations [11:14] I am doing the same for other releases now [11:22] oSoMoN, did you actually runtime tested those changes [11:23] ricotz, autopkgtests passed for all the architectures [11:23] e.g. ppc-no-static-sizes.patch and s390x-ycbcr.patch are not build fixes [11:25] ppc-no-static-sizes.patch is already upstream [11:26] autopkgtests doesn't cover rendering issues like what s390x-ycbcr.patch is for [11:27] true, but the patch didn't have any metadata and it really looked like a build fix, I'm happy to add it back if you have a pointer to a bug or a description of the problem it solves [11:27] and we should upstream it [11:29] so don't remove it without having any feedback [11:29] ricotz, was there someone who reported the problem and verified the fix at the time you added the patch? [11:31] ricotz, the changelog entry for when that patch was added says "Fix skia build on arm64 and s390x", which is why I assumed it was a build fix [11:34] oSoMoN, there are likely more color conversion issue regarding big-endian archs, e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=1672395 [11:34] Mozilla bug 1672395 in Graphics "[s390x] [big endian?] Some images have wrong colors in Firefox" [S3,New] [11:34] sorry I don't have time now [11:35] might be better to postpone such a clean up until after xenial is EOL [11:36] oSoMoN, I am going to force push and revert you updates [11:38] ricotz, please don't [11:38] I'll revert it myself [11:38] no [11:39] why not? [11:39] because I haven't pushed my local change yet anyway [11:39] (I wanted to wait for beta 9) [11:40] I have taken that into account and your changelog entries are there [11:40] basically a simple question before doing this, would have been nice [11:42] I should have asked indeed, but the changelog entry really implied it was a build-time fix and my test builds without the patch succeeded, so I didn't really think that required further discussion [11:42] I'll add back the patch with better metadata so this doesn't happen again [11:44] please cancel all the ppa builds [11:44] ricotz, sounds like an honest mistake, errors happen... [11:44] seb128, hi, I realize that [11:47] builds cancelled [11:48] oSoMoN, thank you for looking into cleaning things up, but you are usually not pushing to the beta branches or beta ppa build, so there is more than just a warning wanted from my side [12:59] hey seb128, messed up the local git during the patch, so delayed a bit... I had to create a new MR here: https://code.launchpad.net/~callmepk/ubuntu/+source/wslu/+git/wslu/+merge/396311 [13:07] good morning/afternoon :D [13:09] hey ItzSwirlz [13:09] callmepk, I saw it, no conflict and it seems to address the review issues, I will sponsor it today [13:09] o/ [13:11] thanks seb128 [13:11] np! [13:55] ricotz, re firefox on s390x, there's also https://bugzilla.mozilla.org/show_bug.cgi?id=1626236 [13:56] Mozilla bug 1626236 in ImageLib "[s390x / Big endian] - Image decoders produce swizzled output" [S3,Unconfirmed] [13:56] but none of these two bugs mention or link to the patch that we currently have in our packages [13:57] I'm guessing it is coming from https://chromium.googlesource.com/chromium/src/+/fbf038170dc0bd29ead8630013b28c6008047ec1, but I would like to see/read a confirmation from someone who actually tested it that it makes things better [13:57] and then we could upstream it [13:57] otherwise I feel like we're carrying a patch for no real added value [13:58] but I'm fine leaving it there until we figure it out [15:22] oSoMoN, I don't remember where it came from, but it serves a purpose. I don't have a s390x instance to give a build some runtime testing, I am going to try setting one up with qemu if that is possible [15:22] ricotz, cool [15:23] oSoMoN, afair seb gave s390x some runtime testing last time when the bigendian icu patches were merged [15:24] it better to target the ff trunk builds here [15:31] ricotz: oSoMoN: I'd not recommend to try s390x-qemu emulation; by far the simplest way is getting an s390x instance on canonistack [15:31] yeah, I got one of those running, I'll see if I can run tests [15:34] cpaelzer, I see, I assume it would be very slow? [15:36] oSoMoN, thanks [15:39] ricotz: it is not supporting all instructions a new kernel&glibc might issue, so expect breakage in the worst case [15:56] ricotz, here are some screenshots taken on s390x: https://people.canonical.com/~osomon/ff-s390x/ [15:57] the first 3 are with the version in the hirsute archive (84.0.2), the 4th one is a 85.0~b8 from my PPA without the s390x patch [15:57] I'm not seeing any difference in image rendering between the two versions [15:57] i.e. image colors are wrong in both cases [16:03] we don't care about s390x though =) [16:07] good morning desktopers [16:11] good morning hellsworth [16:11] hi there oSoMoN [16:11] hey hellsworth [16:11] o/ marcustomlinson [16:15] oSoMoN, I assumed this color format is used in videos, but its might be obsolete [16:23] oSoMoN, could you compare these https://people.ubuntu.com/~ricotz/firefox/ [16:34] oSoMoN, could you compare these https://people.ubuntu.com/~ricotz/firefox/ [16:39] horay! new laptop bad screen resolution =) [16:40] i'm confused if i have hidh-dpi laptop or not, and if i should have scaling or not, and how things should look like on it [21:24] ricotz, it looks like my last messages didn't go through as I was having issues connecting to my IRC bouncer [21:24] ricotz, see the first 4 screenshots in https://people.canonical.com/~osomon/ff-s390x/ [21:24] (ff84 is the archive build, ff85 is my custom build without the patch) [21:24] looks the same to me [21:26] oSoMoN, I assumed this color format is used in videos, but its might be obsolete [21:26] oSoMoN, could you compare these https://people.ubuntu.com/~ricotz/firefox/ [21:27] ricotz, yes, and the above was my answer to your request for comparison [21:28] ok [22:12] oSoMoN, uploaded beta 9 [22:12] ack, thanks