| 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:00 |
| Wimpress | rbasak: Here you go - https://forum.snapcraft.io/t/installing-snap-on-centos/10020 | 09:32 |
| Wimpress | Cover RHEL too. | 09:32 |
| Wimpress | Linked from https://docs.snapcraft.io/installing-snapd/6735 | 09:33 |
| 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:53 |
| 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:54 |
| 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:56 |
| 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:57 |
| 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 | 09:58 |
| 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:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| jamespage | cpaelzer_: are we stillhaving to blacklist the i386 testing for proposed migrations? | 10:06 |
| cpaelzer_ | jamespage: my last test was a few weeks ago and still failing | 10:44 |
| jamespage | cpaelzer_: ack - raised a review to bump | 11:21 |
| jamespage | https://code.launchpad.net/~james-page/britney/ovs-bump/+merge/363351 | 11:21 |
| infinity | ahasenack: Are you aware of apache2's failing autopkgtests? | 14:07 |
| infinity | ahasenack: Why is t/apache/expr_string.t poop? | 14:07 |
| ricotz | infinity, the new dpkg doesn't create a Binary field in .changes files | 14:36 |
| ricotz | launchpad doesn't like that | 14:37 |
| infinity | ricotz: Well that's fun. | 14:44 |
| infinity | ricotz: Example? | 14:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:55 |
| ahasenack | let me check | 14:56 |
| ahasenack | I see it failed the same way once when I uploaded openldap | 14:56 |
| ahasenack | and passed after a retry. Still, annoying to have a flaky test | 14:57 |
| 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 | 14:58 |
| 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:00 |
| 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:03 |
| sarnold | it locks in pages as they are faulted in; unused parts of libraries etc wouldn't necessarily be faulted in | 15:04 |
| doko | infinity: no, I wasn't aware of that one | 15:15 |
| robert_ancell | sarnold, is there a way to check how much memory is locked in a process? | 15:33 |
| sarnold | robert_ancell: I believe the Locked: lines in /proc/self/smaps would show that | 15:35 |
| === cpaelzer_ is now known as cpaelzer | ||
| === imcleod_ is now known as imcleod | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!