| tytel | hello! i'm running into some issue with a ppa build. hoping to find some help :) | 06:28 |
|---|---|---|
| tytel | i have a ppa that works fine when i build it on my machine, but when i build it on the ubuntu servers, i sometimes get "Illegal instruction (core dumped)" | 06:28 |
| tytel | it's weird, some of the builds work fine. | 06:29 |
| tytel | and per build the errors are consistent. That is, either I always get "Illegal Instruction" or it works all the time | 06:30 |
| wgrant | tytel: "per build"? | 06:32 |
| wgrant | Surely it either fails once or it doesn't fail at all. | 06:32 |
| geser | on which architectures do you get this error? | 06:32 |
| wgrant | How can it fail consistently? | 06:32 |
| wgrant | A failure should terminate the build... | 06:32 |
| tytel | wgrant: what i mean is it's not like an intermittent seg fault | 06:34 |
| tytel | each build i download either works all the time, or none of the time | 06:35 |
| wgrant | tytel: I still don't understand what you mean. Can you give specific examples? | 06:35 |
| tytel | geser: i386 though I've had two people test it on amd64 and one worked and one didn't | 06:35 |
| wgrant | Oh. | 06:36 |
| wgrant | So the build isn't failing, but it breaks when you run the executable? | 06:36 |
| tytel | wgrant: yes | 06:36 |
| wgrant | Sounds like your build process is erroneously tailoring the code it generates to the CPU it's built on. | 06:36 |
| wgrant | eg. it builds on a machine that supports AVX, so it uses AVX in the generated object code. | 06:37 |
| wgrant | Well-behaved build systems shouldn't do that, for this sort of reason :) | 06:37 |
| wgrant | They should build for the lowest reasonable denominatorr. | 06:37 |
| tytel | wgrant: I found a -march=native in the Makefile. Is that the problem? | 06:37 |
| wgrant | tytel: That's the one, yep. | 06:37 |
| wgrant | Drop that and all will be good. | 06:37 |
| wgrant | Well, unless it does other mischief. | 06:37 |
| tytel | wgrant: thanks, should it be set to something else or just totally dropped? | 06:38 |
| wgrant | tytel: The defaults are sensible, so dropping it should be fine. | 06:38 |
| tytel | ok thanks | 06:38 |
| wgrant | march=native never makes sense for anything that is going to be distributed. | 06:38 |
| wgrant | If I built it on my Haswell machine, it won't run on anything earlier than Haswell. | 06:38 |
| tytel | wgrant: the Makefiles were autogenerated :/ | 06:39 |
| tytel | i was just along for the rid | 06:39 |
| tytel | e | 06:39 |
| wgrant | tytel: Hopefully whatever generates them has an option. | 06:40 |
| tytel | wgrant: thanks again for the quick help | 06:44 |
| wgrant | Hopefully it's just that one option! | 06:45 |
| tytel | wgrant: this one worked! hopefully that fixed it :) | 07:12 |
| wgrant | tytel: Excellent. | 07:15 |
| wgrant | tytel: Note that the PPA build farm runs on a couple of different generations of servers, so it could just have been luck this time. | 07:16 |
| tytel | wgrant: ok thanks for the heads up. | 07:16 |
| Madkiss | hi folks | 08:12 |
| Madkiss | I have a problem with launchpad ppas. My ppa has a backported version of php (5.4) for Trusty. Obviously, Trusty itself has newer packages of php. | 08:13 |
| Madkiss | When I try to build packages for PHP 5.4, the builders will not automatically choose the php 5.4 from the same repo, but use the nwer packages from the official repository instead | 08:13 |
| Madkiss | how can I add something like apt preferences to a PPA? | 08:14 |
| maxb | You cannot | 08:14 |
| Madkiss | So I'll have to build php 5.4 with an epoch?! | 08:15 |
| maxb | Options are an epoch or changed binary package names | 08:15 |
| Madkiss | Okay, thanks. | 08:15 |
| mapreri | Madkiss: as: builder always pick up the higher version available of everything. | 08:19 |
| Madkiss | Yeah, well. | 08:19 |
| Madkiss | If I can make it work with an epoch, I guess that'll have to do for now. | 08:20 |
| dobey | Madkiss: don't use an epoch | 13:28 |
| dobey | Madkiss: if you are building something else that requires php 5.4, then in its build-depends you should specify that it requires 5.4 and not 5.5 or whatever | 13:28 |
| dobey | ie "php (>= 5.4), php (<< 5.5)" or similar | 13:29 |
| dobey | or fix the thing to work with the new php | 13:29 |
| dobey | not sure why you want to use an old insecure version really | 13:29 |
| Madkiss | dobey: well. profit. ;) | 13:43 |
| dobey | i didn't realize that deploying versions of software with known exploits meant profit ;) | 13:52 |
| Laney | depends who for | 16:03 |
| jeroen___ | Hello. I have a question about gpg signing in Launchpad. | 16:25 |
| jeroen___ | I'm trying to understand the difference between how maintainers sign packages on launchpad and on debian sid. | 16:26 |
| jeroen___ | When I upload a package to launchpad I only sign the source package. When a user installs the package from launchpad, he has to first import my gpg key. But what I don't understand is how Launchpad can sign the *binary* build of the package on my behalf. I only signed the source package? | 16:29 |
| dobey | jeroen___: no, the binaries are signed with a different key, not yours | 16:30 |
| jeroen___ | So why does the user have to import my gpg key to install the packages? | 16:30 |
| dobey | jeroen___: a new gpg key for your ppa is created when you first create the ppa. binaries are signed with that key | 16:30 |
| dobey | the user doesn't have to import your key. the key for the PPA has to be imported | 16:30 |
| maxb | Your signature on the source package enables Launchpad to trust that you uploaded it. Launchpad's signature on the repository enables the user's computer to trust the package was produced by Launchpad on your behalf. | 16:32 |
| jeroen___ | aha so this key is not on the gpg keyserver at all? How is the user supposed to authenticate this key? | 16:32 |
| maxb | Launchpad uploads the keys it generates to the keyservers. | 16:32 |
| dobey | "sudo add-apt-repository ppa:owner/ppa" automatically imports the key | 16:32 |
| maxb | The user's means of authentication is to get the key fingerprint from your PPA page on https://launchpad.net/ | 16:33 |
| cjwatson | Similarly, on Debian, users don't trust your signature directly, they trust the signature on the archive. | 16:33 |
| cjwatson | It's just that Launchpad has lots more archives. | 16:33 |
| jeroen___ | Yes but on debian all binary packages are signed with the master key that is included with the distro. | 16:34 |
| cjwatson | Binary packages aren't signed, the whole archive is. | 16:34 |
| jeroen___ | Yes sorry | 16:34 |
| cjwatson | Anyway, it makes sense to sign each archive separately. | 16:34 |
| cjwatson | Rather than just having a sort of amorphous expanding cloud of trust. | 16:35 |
| dobey | indeed | 16:35 |
| cjwatson | This way e.g. a malicious proxy can't substitute a different PPA for the one you thought you were using. | 16:35 |
| jeroen___ | The part that is unclear to me is how the user/client can safely import this autogenerated key from my ppa that is supposed to represent me but wasn't really made by me. | 16:36 |
| cjwatson | Most users won't know you any better than the Launchpad-generated key | 16:37 |
| cjwatson | The initial setup (perhaps unfortunately, but better than nothing) relies on HTTPS to launchpad.net | 16:37 |
| jeroen___ | I know, but I want to understand the chain of trust here | 16:37 |
| cjwatson | So they have to trust the integrity of Launchpad, which is the case anyway since Launchpad is doing the builds | 16:38 |
| dobey | jeroen___: as i said, when one runs "sudo add-apt-repository" to add a ppa from launchpad, it imports the key as well | 16:38 |
| dobey | jeroen___: that's how the client "safely" imports the key | 16:39 |
| cjwatson | It's correct for Launchpad to sign the archive containing the binaries that it produced; if you want to think of it this way, that signature certifies that the only sources that make up that repository were put there by somebody with authority to upload to it | 16:39 |
| cjwatson | But also the integrity of the other parts of the archive that didn't come directly from you | 16:39 |
| Robe | ohai | 17:00 |
| jeroen___ | mmkay | 17:02 |
| Robe | cjwatson: I noticed that the source branches in https://code.launchpad.net/ubuntu/+source/curl seem to contain applied patch series | 17:04 |
| Robe | is this the code imported by the build bot after the source tree has been prepared for building? | 17:04 |
| dobey | Robe: the archive builders don't build from the bzr imported branches, no | 17:24 |
| dobey | but yes, i think the branch importer does import with patches applied | 17:24 |
| Robe | thanks | 17:25 |
| Robe | Rhonda is currently explaining dpkg v3 to me in another channel ;) | 17:25 |
| dobey | source format 3.0 you mean? | 17:26 |
| Robe | yesh | 17:26 |
| cjwatson | Robe: those are auto-imports, yeah, also frequently broken and heading towards deprecation in favour of something git-based, so don't get too used to them | 19:12 |
| Robe | cjwatson: thanks! | 19:33 |
| Robe | cjwatson: these repos are just for documentation purposes - the authoritative source sources (!) are still the uploaded tarballs containing the upstream releases and maintainer changes, right? | 19:38 |
| === kostja_o1ipov is now known as kostja_osipov | ||
| === mwhudson_ is now known as mwhudson | ||
| === mwhudson is now known as Guest82160 | ||
| === Guest82160 is now known as mwhudson | ||
| mordred | lifeless: it's possible it woudl be more productive for me to ask you this here | 23:38 |
| mordred | lifeless: this is all related to the private team swift-private | 23:38 |
| mordred | http://paste.openstack.org/show/356693/ | 23:38 |
| mordred | we have not used the team in almost 5 years :) | 23:38 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!