[09:00] <alkisg> vorlon: sorry for the direct ping, re: https://bugs.launchpad.net/ubuntu/+source/shim/+bug/1813541 - is it possible that `apt source shim` in 18.04 shows different code than the binary shipped/signed by microsoft?
[09:00] <ubottu> Launchpad bug 1813541 in shim (Ubuntu) "Shim uses wrong TFTP server IP in proxyDHCP mode" [Medium,Triaged]
[09:00] <alkisg> Because I'm trying with upstream shimx64.efi and it works, yet 18.04's shim doesn't, even though the patch seems to be in the codebase...
[09:32] <Wimpress> rbasak: Here you go - https://forum.snapcraft.io/t/installing-snap-on-centos/10020
[09:32] <Wimpress> Cover RHEL too.
[09:33] <Wimpress> Linked from https://docs.snapcraft.io/installing-snapd/6735
[09:53] <vorlon> alkisg: there are lots of ways that apt source might give you different behavior depending on what's in your sources.list, did you check that the versions match?
[09:53] <alkisg> vorlon: yes, I only have the "normal" sources list, the versions match
[09:54] <vorlon> alkisg: ok; then that is the source for the binary included in the shim-signed package
[09:54] <alkisg> vorlon: if the shim binary is signed by ms on every shim package update, then the problem is elsewhere and I'll find it; I just wanted that part from you, if it's signed on every build
[09:54] <alkisg> Thank you :)
[09:54] <vorlon> it's not signed on /every/ build, but every shim package version that gets published to the archive is also signed by MS
[09:54] <alkisg> Right, that's what I meant, my english failed me
[09:56] <alkisg> (probably another patch was needed which is available upstream, not just the one pointed out by the developers)
[09:56] <cyphermox> alkisg: what patch?
[09:56] <cyphermox> alkisg: basically, the source in src:shim should match the binary in source:shim-signed
[09:57] <cyphermox> well, the other way around, modulo the microsoft signature
[09:57] <cyphermox> we actually test for that at build-time for shim-signed
[09:58] <alkisg> cyphermox: yup, that's what I was asking. So, in  https://github.com/rhboot/shim/issues/165, they pointed out commit 5f4fd53 which we do have, but probably b3e4d1f is needed as well; I'll check now if we have that already, e.g. in disco
[09:58] <alkisg> Ah disco has the same shim version, nevermind
[10:02] <rbasak> Wimpress: thanks!
[10:02] <cyphermox> b3e4d1f is just the tip
[10:02] <cyphermox> is it not?
[10:02] <alkisg> Let me check...
[10:02] <cyphermox> nevermind
[10:03] <cyphermox> it was the tip at which my tree was before I just pulled
[10:03] <cyphermox> but that's like, 4 commits away from 3beb291; which is what disco is
[10:03] <alkisg> cyphermox: well, it's possible that the fix for the issue I see is there; I don't mind if Ubuntu gets it sooner or later, as long as we do get it :)
[10:03] <cyphermox> sure sure
[10:04] <cyphermox> I do plan on updating shim again very soon, but it's at least two weeks away from now, at the earliest
[10:04] <alkisg> Oh great, I'll test again then
[10:04] <alkisg> Thank you cyphermox :)
[10:05] <cyphermox> none of the commits in between 3beb971 and b3e4d1f are netboot.c relevant
[10:05] <alkisg> That would leave me with the question... "wth, why is upstream shim working and ubuntu's not..." :)
[10:06] <jamespage> cpaelzer_: are we stillhaving to blacklist the i386 testing for proposed migrations?
[10:44] <cpaelzer_> jamespage: my last test was a few weeks ago and still failing
[11:21] <jamespage> cpaelzer_: ack - raised a review to bump
[11:21] <jamespage> https://code.launchpad.net/~james-page/britney/ovs-bump/+merge/363351
[14:07] <infinity> ahasenack: Are you aware of apache2's failing autopkgtests?
[14:07] <infinity> ahasenack: Why is t/apache/expr_string.t poop?
[14:36] <ricotz> infinity, the new dpkg doesn't create a Binary field in .changes files
[14:37] <ricotz> launchpad doesn't like that
[14:44] <infinity> ricotz: Well that's fun.
[14:44] <infinity> ricotz: Example?
[14:45] <ricotz> Rejected:
[14:45] <ricotz> Unable to find mandatory field 'Binary' in the changes file.
[14:45] <ricotz> Further error processing not possible because of a critical previous error.
[14:46] <infinity> ricotz: Is that a source upload or a build?
[14:46] <ricotz> I would assume this happens with any package, or did I hit some intermediate state?
[14:46] <ricotz> the source upload
[14:46] <ricotz> this happened already with the previous try to update to 1.19.4
[14:46] <infinity> Fun.  doko didn't mention that bit when he asked me to re-do the merge. :P
[14:47] <infinity> Very much an intentional change:
[14:47] <infinity>  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818618
[14:47] <ubottu> Debian bug 818618 in dpkg-dev "dpkg-genchanges: Please exclude packages disabled in unstaged builds" [Normal,Fixed]
[14:55] <ahasenack> infinity: hm, no, I wasn't aware, it wasn't in https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses_by_team.html#ubuntu-server this morning, but is now
[14:56] <ahasenack> let me check
[14:56] <ahasenack> I see it failed the same way once when I uploaded openldap
[14:57] <ahasenack> and passed after a retry. Still, annoying to have a flaky test
[14:58] <sarnold> robert_ancell: sigh. I can't recall now where the discussion about mlockall and lightdm was; ~300 M feels like quite a lot to pin into memory. If you can limit it to the password field, and anything derived from it, that'd be better
[15:00] <robert_ancell> sarnold, I guess that's hard because the password is used in many places.
[15:00] <robert_ancell> I think just dropping the mlockall entirely is probably the way to go for now and adding in something better in the future if necessary
[15:03] <sarnold> robert_ancell: hmmm.. what do you think about using MCL_ONFAULT ? it's really new.. (I just learned about it a moment ago :)
[15:03] <robert_ancell> I have no idea what that is - I'd have to look it up
[15:04] <sarnold> it locks in pages as they are faulted in; unused parts of libraries etc wouldn't necessarily be faulted in
[15:15] <doko> infinity: no, I wasn't aware of that one
[15:33] <robert_ancell> sarnold, is there a way to check how much memory is locked in a process?
[15:35] <sarnold> robert_ancell: I believe the Locked: lines in /proc/self/smaps would show that
=== cpaelzer_ is now known as cpaelzer
=== imcleod_ is now known as imcleod