| === Spads_ is now known as Spads | ||
| teward | bdmurray: ping - can you undo the team subscription done by your patch detection bot? Sponsoring isn't needed on the given bug (I have upload rights, I"m just waiting for Daviey to sanity-check my diffs because I asked for a second set of eyes) | 02:13 |
|---|---|---|
| teward | (for a given bug) | 02:13 |
| teward | i shouldn't have asked, I think Daviey is on the sponsors team... i'll ask him to do the unsubscribe :/ | 02:19 |
| * teward yawns | 02:19 | |
| bdmurray | teward: on what but? | 05:02 |
| bdmurray | teward: on what bug? | 05:02 |
| shiva | hi all , I have a question on pulseaudio ... am in the right channel ? | 05:25 |
| TheMuso | shiva: You are probably best asking in #pulseaudio, although the devs are not likely around at the moment. | 05:28 |
| shiva | Thanks for the rply | 05:29 |
| draos | hello, is there any apply for developer for ubuntu? | 06:17 |
| slangasek | TheMuso: hi, it appears your latest speech-dispatcher upload causes brltty to FTBFS - it was buildable June 19 when it was last tried in the pythoneers ppa, now it fails with a libspeechd header error: https://launchpadlibrarian.net/212248803/buildlog_ubuntu-wily-amd64.brltty_5.2~20141018-4ubuntu2_BUILDING.txt.gz | 06:27 |
| slangasek | TheMuso: was this on your radar? | 06:27 |
| draos | hi is there any "apply for staff" or become an ubuntu developer? | 06:31 |
| === marcusto_ is now known as marcustomlinson | ||
| ScottK | draos: This has some useful links https://wiki.ubuntu.com/UbuntuDevelopers | 06:39 |
| draos | thx | 06:40 |
| draos | are there any rewards for ubuntu development ? | 06:40 |
| LocutusOfBorg1 | Hi Folks, is there any process to apply for Ubuntu Membership for a DD? | 07:06 |
| LocutusOfBorg1 | I see from the sponsorship page I might need to ping dholback, ginggs_ or somebody else, right? | 07:06 |
| LocutusOfBorg1 | I do not want to create a page if I do not have an endorser :) | 07:07 |
| * LocutusOfBorg1 is looking at https://wiki.ubuntu.com/DeveloperMembershipBoard/ApplicationProcess | 07:07 | |
| seb128 | LocutusOfBorg1, I'm unsure the process is different for DDs | 07:11 |
| seb128 | you are on the right wikipage I think | 07:11 |
| seb128 | oh, seems like slangasek is starting that python transition after all :-) | 07:11 |
| * LocutusOfBorg1 is not yet a DD, missing the account creation, just the key has been uploaded yesterday | 07:12 | |
| dholbach | good morning | 07:19 |
| ari-tczew | hello dholbach | 07:22 |
| dholbach | hey ari-tczew | 07:25 |
| === marcusto_ is now known as marcustomlinson | ||
| flexiondotorg | Laney, I see you up for piloting today. May I kindly request you look at this please? - https://bugs.launchpad.net/ubuntu/+bug/1476653 | 09:04 |
| ubottu | Launchpad bug 1476653 in Ubuntu "[needs-packaging] ubuntu-mate-welcome" [Wishlist,New] | 09:04 |
| Laney | flexiondotorg: We'll see, I might end up moving it. | 09:12 |
| flexiondotorg | Laney, Moving it? | 09:12 |
| Laney | my slot | 09:12 |
| flexiondotorg | Ah, OK. | 09:12 |
| cjwatson | Laney: could you have a look at agda? build-deps on old cpphs | 09:12 |
| Laney | cjwatson: hm, did that plan not catch that? | 09:14 |
| Laney | Seems fixed by upgrading to 2.4.2.3 anyway, will do later on | 09:15 |
| cjwatson | Laney: dunno, maybe the plan did but it hasn't been uploaded to match? | 09:17 |
| ogra_ | infinity, hmm, your live-build upload makes phones explode | 09:41 |
| ogra_ | infinity, "/bin/sh: 1: /bin/sh: initctl: not found" ... (we use upstart all the way there, on both, vivid and wily) | 09:42 |
| ogra_ | infinity, bug 1477051 for more details | 09:51 |
| ubottu | bug 1477051 in live-build (Ubuntu) "Phones on devel-proposed do not boot - /bin/sh: 1: /bin/sh: initctl: not found" [Critical,Confirmed] https://launchpad.net/bugs/1477051 | 09:51 |
| xnox | horum. where is piti when you need one | 10:26 |
| xnox | stgraber: have you looked into integrating systemd-resolvd (/run/systemd/resolve/resolv.conf) with resolvconf in ubuntu? | 10:28 |
| xnox | stgraber: ideally we'd have e.g. lo & eth* things managed by systemd-networkd and the rest elsewhere (e.g. networkmanager for wifi, etc.) | 10:28 |
| Laney | on holiday | 10:34 |
| doko | apw, did you have a chance to check your regexp theory with schroot? | 10:55 |
| doko | infinity, Laney: would it be possible to limit a transition tracker just for main? just would like to know where my priorities should be | 11:00 |
| Laney | doko: Not really easy for the main instance. You can s/html/txt/ to get something that you might be able to wrangle with a script... | 11:02 |
| Laney | doko: Don't we have to fix everything for it to be able to migrate, though? | 11:02 |
| doko | Laney, wishful thinking =) I wanted to check what I minimally need to rebuild to get a desktop login | 11:04 |
| doko | I wish I had debian's autoremove tool ... | 11:05 |
| Laney | I suppose we could run it a second time, maybe | 11:05 |
| Laney | doko: what's going to break the desktop? | 11:07 |
| doko | Laney, I don't know yet. the thing is that I didn't even start doing no change uploads for libraries, and for the transitions started there, plus we'll probably have breakage when we rebuild and not rename the library package | 11:08 |
| Laney | you mean undetected ABI breaks, I see | 11:08 |
| doko | see https://wiki.ubuntu.com/GCC5 for the explicit transitions in the ppa | 11:09 |
| doko | yes, see my 400 bug reports for debian ... | 11:09 |
| Laney | I have seen your analysis, which is why I wasn't aware that there is a risk of missing some transitions | 11:10 |
| doko | right, so we could start these, but then would have to redo things when syncing/merging from debian | 11:13 |
| doko | I mean, we could start with the packages which have confirmed transitions | 11:15 |
| doko | mvo_, python-apt ping | 11:34 |
| === MacSlow is now known as MacSlow|lunch | ||
| teward | bdmurray: sorry for slow response, bed was calling. https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1476811 is the bug that your foundations bot tagged 'patch' then subbed sponsors to. It doesn't need sponsors attention though since I have upload rights, it's pending voluntary review by Daviey however for sanitychecking. | 12:04 |
| ubottu | Launchpad bug 1476811 in nginx (Ubuntu) "Merge nginx 1.9.3-1 (main) from Debian unstable (main)" [Medium,In progress] | 12:04 |
| teward | 'cause i have a tendency to make mistakes when tired :/ | 12:04 |
| === _salem is now known as salem_ | ||
| Daviey | teward: I unsubb'd sponsors. | 12:21 |
| === ssweeny` is now known as ssweeny | ||
| cjwatson | doko: can I merge python-debian, or do you want to? | 13:07 |
| cjwatson | doko: (we need its build profiles support) | 13:07 |
| doko | cjwatson, please do, still in GCC 5 only mode ;) | 13:08 |
| cjwatson | ok | 13:08 |
| cjwatson | I'm in "will I ever escape from fiddly launchpad-buildd bugs" mode | 13:09 |
| doko | heh | 13:09 |
| Luke | What's the correct behavior for systemd user instances? I've not been able to get them working due to lack of ability to connect to D-Bus. I've heard perhaps user instances are still managed by upstart? | 13:13 |
| caribou | If anyone has time, I need a sponsor for the rsyslog merge, bug #1464201 | 13:20 |
| ubottu | bug 1464201 in rsyslog (Ubuntu) "Please merge rsyslog 8.9.0-3 (main) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/1464201 | 13:20 |
| xnox | Luke: we have all three =) | 13:27 |
| Luke | xnox: the question is what's the intended use path for user session init system? | 13:28 |
| xnox | Luke: pam_systemd starts system user instance for us, which does nothing. As we don't have anything running "there". our Xsession start scripts spawn upstart which start "session" dbus. user systemd has no idea about session dbus. | 13:28 |
| xnox | Luke: we have all user sessions managed by upstart since 14.04 or 13.10, can't remember. | 13:29 |
| Luke | xnox: what about after the move to systemd in 15.04? | 13:29 |
| xnox | Luke: still. we only moved pid1 to systemd, user sessions are still managed by upstart. | 13:29 |
| Luke | gotcha. thanks. is that documented anywhere? | 13:30 |
| xnox | Luke: moving user session to systemd is blocked by moving phone to systemd as pid1. as that is still using upstart as pid1. | 13:30 |
| Luke | are there plans to move user sessions to systemd? | 13:30 |
| Luke | gotcha | 13:30 |
| xnox | Luke: documented in the release notes and all the systemd/snappy sessions every UOS. | 13:30 |
| Luke | UOS | 13:30 |
| Luke | ? | 13:30 |
| xnox | Luke: and user systemd implies, dbus user session, which at the moment brakes all sorts of upstream things - and not at all tested on e.g. Ubuntu Desktop. | 13:31 |
| xnox | Luke: UOS - ubuntu online summit, aka uds but over hangout.s | 13:31 |
| Luke | I'm having the same trouble on Debian btw (spun up a VM to see what they do)... they don't have the phone constraint.... is this an upstream issue? | 13:31 |
| xnox | Luke: which issue, what constraing, and debian is weird - they don't have any inits in the user sessions as far as I know. | 13:32 |
| Luke | also this is Ubuntu server I'm using so there is no Xsession. how should I start a user session upstart then? | 13:32 |
| Luke | xnox: ah i see... so debian has never had user session init? | 13:32 |
| xnox | Luke: on a server you either have nothing, or systemd user session. You can launch upstart user session, but we don't do that by default. As currently that is only setup for "desktops" | 13:32 |
| Luke | aaah gotcha | 13:33 |
| xnox | Luke: debian just uses e.g. Xsession.d to track things and e.g. just logind, just policykit, just ssh session leader and some such. | 13:33 |
| === MacSlow|lunch is now known as MacSlow | ||
| xnox | not policykit, sorry, consolekit. | 13:33 |
| mvo_ | doko: thanks, I will try to fix that later today, sorry for the trouble | 13:33 |
| Luke | it uses Xsession.d even for non-X environments? | 13:33 |
| Luke | xnox: in #ubuntu-server they asked me to file this bug: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1476364 | 13:34 |
| ubottu | Launchpad bug 1476364 in systemd (Ubuntu) "“systemd --user” instance can't find d-bus" [Undecided,New] | 13:34 |
| Luke | can you comment on that and close if appropriate? | 13:34 |
| Luke | xnox: also, if I'm running a server, it seems the easiest approach may be to just get a user session dbus that my user session systemd can connect to. I used 'systemctl enable-linger myUser' to get the user session in the first place | 13:35 |
| xnox | Luke: what are you trying to do or run? | 13:37 |
| Luke | I have an app that I want to keep running during certain time periods. it's not a system app i just want it to be managed for me | 13:37 |
| xnox | which app? | 13:37 |
| xnox | Luke: crontab much? | 13:38 |
| Luke | custom | 13:38 |
| Luke | cron doesn't do process monitoring | 13:38 |
| xnox | Luke: you are already inside vagrant box, are you sure you don't have root already? | 13:38 |
| Luke | I do have root on that box. on the deployment boxes I don't want it to run as root | 13:38 |
| xnox | Luke: also you can spawn lxc container with full init, as an upriviledged user. | 13:38 |
| stgraber | xnox: nope, haven't looked at it. I'm also not really maintaining any of those networking packages nowadays | 13:39 |
| Luke | I want a unprivileged user to login to the box and be able to restart the app etc | 13:39 |
| Luke | I don't want containers due to network performance reduction | 13:39 |
| xnox | stgraber: horum, is pitti doing all of that, or like nobody? | 13:42 |
| xnox | Luke: netere is no network penalty if you simply let your containers to run on the host network without any nat/bridges in between, and even then i don't buy the argument of network pentaly. | 13:43 |
| Luke | xnox: you don't have to buy it. it's a fact =) | 13:43 |
| xnox | Luke: look into using e.g. runit or other lightweight processor supervisioning things that are readilly availble from the archive and usable as user instances. | 13:44 |
| Luke | at least as measured in docker | 13:44 |
| Luke | docker uses lxc tho underneath right? | 13:44 |
| Luke | xnox: i'll check out runit | 13:44 |
| xnox | Luke: haha =) docker can use a lot of network setups, by default it's quite crappy. and no, it does not use lxc by default. anyway, you can make docker "on the host network without any nat/bridges in between" with standard daemon args. | 13:45 |
| xnox | Luke: thus docker != "slow network" | 13:45 |
| Luke | fair enough | 13:46 |
| xnox | it can be as good as normal network, your user instance would see. | 13:46 |
| Luke | still this all seems like more work than just having a systemd user instance start up | 13:47 |
| Luke | runit looks like the same amount of work except I already have the systemd scripts | 13:47 |
| xnox | Luke: i'm failing to see what's stopping /you/ from using systemd user instance. | 13:48 |
| Luke | xnox: nothing. just making sure i'm going down the right path | 13:48 |
| xnox | Luke: it's not provided for you by the distribution, and you will need to add support units yourself to get it up and running, and will have to run user dbus your self, with user dbus units. | 13:48 |
| Luke | xnox: basically I was looking to have this exact discussion to explore alternatives with someone more knowledgable than myself | 13:49 |
| stgraber | xnox: it's probably split between pitti and cyphermox | 13:49 |
| xnox | Luke: all about your problem sounds like the wrong path =) | 13:49 |
| xnox | at leat to me. | 13:49 |
| Luke | xnox: you'd go w/ lxc? | 13:49 |
| xnox | Luke: i'd add policykit rules to allow certain users to execute certain commands with systemctl/systemd e.g. restart, and that's it. | 13:51 |
| xnox | and run everything of the system init. | 13:51 |
| Luke | ok i've seen that done before as well | 13:51 |
| ogra_ | policykit ... so advanced ... | 13:51 |
| Luke | I think I'll explore doing that. thanks xnox | 13:51 |
| ogra_ | just allow a sudoers group to do it and add the users to that group | 13:51 |
| xnox | Luke: cause you really don't want to maintain a hanging user pam session, with systemd, dbus et.al. running there. which are all disconnected from system upgrades more or less. | 13:52 |
| Luke | right | 13:52 |
| Luke | which is why I came here in the first place =) | 13:52 |
| Luke | xnox: thank you so much. this was an extremely helpful discussion | 13:54 |
| teward | Daviey: thank you kindly :) | 14:03 |
| infinity | ogra_: Curious. That doesn't make a whole lot of sense, I'll have to poke at it. | 14:35 |
| infinity | ogra_: I assume the latest build of https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/vivid/ubuntu-touch should contain the bug? | 14:36 |
| ogra_ | infinity, nope, vivid is still in proposed afaik, wily did expose it ... | 14:36 |
| ogra_ | and seb128 wanted to block the vivid SRU promotion for it | 14:36 |
| infinity | ogra_: Oh, right. wily it is. | 14:36 |
| infinity | ogra_: Oh, I think I see the bug. The initial 'exit 0' is BS. | 14:38 |
| infinity | ogra_: Same bug I fixed previous with the upstart-user-sessions patch which I reverted for this due to conflicts. | 14:39 |
| infinity | ogra_: Will test a bit and confirm and upload. | 14:39 |
| ogra_ | yay | 14:39 |
| infinity | ogra_: (ie: dba's upstart handling always assumes that system upstart == only upstart) | 14:39 |
| ogra_ | well, we are kind of unusual with the phones anyway :) | 14:40 |
| infinity | Which would actually be true for phones, except your install procedure is "install systemd, then remove it to add upstart". :P | 14:40 |
| ogra_ | blame pitti for that one :) | 14:40 |
| infinity | ogra_: Meh, it was the path of least pain. Pretty sure I agreed with and/or implemented bits of that plan. | 14:41 |
| infinity | ogra_: It's just a bit weird is all. :) | 14:41 |
| ogra_ | sadly i expect that status to persist til at least the 16.04 cycle | 14:41 |
| infinity | ogra_: Anyhow, this logic is equally wrong for the desktop, where we install upstart post-bootstrap, so yeah. Fixing. | 14:41 |
| * ogra_ was hoping we switch to snappy earlier which would give us systemd init | 14:41 | |
| infinity | Not sure how I missed that when visually reviewing it. | 14:41 |
| ogra_ | well, i saw the exit 0 but thought "well, initctl will be there, so no harm" | 14:42 |
| ogra_ | i didnt think of the bootstrapping with systemd issue :) | 14:42 |
| smoser | ok. so... grabbed cd image from | 15:10 |
| smoser | http://cdimage.ubuntu.com/ubuntu/daily-live/20150722/ | 15:10 |
| smoser | used usb-creator-gtk . said 'Discarded on shutdown'. | 15:11 |
| smoser | stick that in a UEFI intel nuc try to boot it. | 15:11 |
| smoser | "no operating system" | 15:11 |
| smoser | and same thing with | 15:12 |
| smoser | sudo qemu-system-x86_64 --drive if=virtio,file=/dev/sdb,format=raw | 15:13 |
| infinity | smoser: I'd guess there's a bug about that already, but I'd think that's expected, since usb-creator remasters images with syslinux, which only works on BIOS. | 15:13 |
| infinity | smoser: dd is the best way to get a hybrid image written to USB. | 15:13 |
| smoser | well, didnt work with qemu above either (which does not use uefi) | 15:13 |
| smoser | which is why i did it. | 15:13 |
| infinity | smoser: Okay, the second bit is more potentially irksome. :P | 15:14 |
| infinity | usb-creator is kinda dead (ie: no upstream, no real activity); patches welcome. :/ | 15:14 |
| smoser | im' good with dd. just need some path. | 15:14 |
| smoser | and almost all doc i suspect points to it. | 15:14 |
| infinity | I think the best patch would be for it to just fork 'dd' if you don't ask for it to do fancy things like persistent partitions. | 15:14 |
| smoser | or maybe my reading of such things is justold. | 15:14 |
| smoser | but man... | 15:15 |
| smoser | sudo dd if=/tmp/wily-desktop-amd64.iso of=/dev/sdb | 15:15 |
| smoser | that is just scary :) | 15:15 |
| infinity | smoser: A lot of docs point to it since it's the only GUI tool we ship for this. Which is a solid argument for fixing it. It just never seems to be a priority for anyone. :/ | 15:15 |
| infinity | smoser: And yeah, dd is scary. I tend to triple-check dmesg and /proc/partitions before I have the cajones to hit <enter> :P | 15:16 |
| infinity | "Are you sure that's your USB stick? No, really, are you SURE?" | 15:16 |
| smoser | (and i just freaked out a bit after having hit enter) | 15:16 |
| doko | xnox, updated the boost1.58 packages. the one python upstream patch breaks the build, but it's only needed for 3.3 anymore. so maybe time to upload to experimental too | 15:16 |
| infinity | smoser: If you don't want it to take forever, you might want to up the block size to 1M or 4M or something. USB isn't known for its speed with small block sizes (too much back and forth over a slow and chatty protocol) | 15:17 |
| xnox | doko: so you didn't merge from debian, how ubuntu of you ;-) | 15:17 |
| xnox | doko: https://tracker.debian.org/pkg/boost1.58 | 15:17 |
| xnox | doko: http://metadata.ftp-master.debian.org/changelogs//main/b/boost1.58/boost1.58_1.58.0+dfsg-1_changelog | 15:18 |
| xnox | doko: only took the 0002-Fix-a-regression-with-non-constexpr-types.patch from erratra, didn't take the python one. | 15:18 |
| doko | xnox, sorry, didn't see it. did you include the arm64 patch? | 15:20 |
| xnox | doko: * Don't call the compiler with -m{32,64} explicitly. | 15:21 |
| xnox | doko: credit to you, if that's the one. | 15:21 |
| doko | xnox, no the one from fedora | 15:22 |
| xnox | didn't. | 15:22 |
| === spineau is now known as spineau_afk | ||
| smoser | is here a password set on the isos ? X isnt working for some reason, and alt-f1 / tty1 has a login prompt | 15:28 |
| tjaalton | no, uid is ubuntu | 15:29 |
| smoser | i thought in the past maybe theree was just a prompt there? | 15:29 |
| tjaalton | maybe | 15:30 |
| tarpman | IIRC that changed with the switch to systemd | 15:35 |
| bdmurray | teward: If you were a member of ubuntu-dev then ubuntu-sponsors would not have been subscribed. | 15:44 |
| teward | bdmurray: ack. | 15:48 |
| teward | bdmurray: i'm not, obviously, a member of ubuntu-dev. | 15:48 |
| teward | but that explains why the bot did what it did :) | 15:50 |
| Daviey | bdmurray: If teward has PPU upload access, shouldn't he be a member of ~ubuntu-dev? | 15:56 |
| bdmurray | Daviey: I'd think so, I'm looking into it. | 16:05 |
| teward | great, another nondeterministic build failure | 16:09 |
| teward | "dpkg-gencontrol: error: cannot read dhstrip-dummy-debian-files: No such file or directory" https://launchpadlibrarian.net/212318997/buildlog_ubuntu-wily-armhf.nginx_1.9.3-1ubuntu1_BUILDING.txt.gz | 16:10 |
| teward | and all the others built fine >.> | 16:10 |
| infinity | teward: pkg-create-dbgsym might not be parallel safe. | 16:16 |
| infinity | teward: And your rules file is clearly running them in parallel. | 16:16 |
| infinity | Though, why that raced unluckily on only one arch is curious. | 16:16 |
| teward | infinity: happened before | 16:18 |
| teward | infinity: and that's Debian's handiwork, not mine. | 16:18 |
| teward | infinity: i've seen one of these build failures before | 16:18 |
| teward | iirc it's always on arm it fails | 16:18 |
| infinity | teward: I bet it would clear up if you take out the nasty DEB_BUILD_OPTIONS -> MAKEFLAGS business and instead call dh with --parallel | 16:18 |
| teward | typically seen a rebuild 'work' | 16:18 |
| teward | mmm, probably | 16:20 |
| teward | i'll look into it, but i've only seen this race fail once every few uploads *shrugs* | 16:21 |
| teward | first, lunch, coffee, a 5-hour energy, and then to figure out why my mailserver stopped relaying mail :/ | 16:21 |
| infinity | teward: Yeah. But it's clearly a parallel race, and "dh --parallel" only calls the underlying build system with -j, while "MAKEFLAGS = -j4" will run the entirety of debian/rules parallel. | 16:21 |
| infinity | teward: Not that this isn't also a bug in pkg-create-dbgsym, mind you. We probably need some better locking and serialising there to deal with this. | 16:22 |
| teward | mhm | 16:22 |
| rbasak | infinity, doko: OK to retask bug 1453133 to gcc? I don't think there's anything to do in docker.io or go-md2man now. | 16:25 |
| ubottu | bug 1453133 in docker.io (Ubuntu) "[Ubuntu 14.04.3] Backport docker 1.5 to Ubuntu 14.04 on ppc64el" [Undecided,New] https://launchpad.net/bugs/1453133 | 16:25 |
| infinity | rbasak: It was previously a generic "Ubuntu" task before one of your team reassigned it to docker. :P | 16:26 |
| infinity | rbasak: And generic Ubuntu seems right, since it would require a gcc backport package or similar evil. It's not just a "please fix a bug in gcc" thing. | 16:26 |
| rbasak | infinity: bugsquad triager, not server team | 16:26 |
| rbasak | I'll move it back to Ubuntu then I guess. | 16:26 |
| infinity | rbasak: We should discuss it with IBM, probably, and settle on wontfix to not get their hopes up, but I'll bring that up with them in the next call. | 16:27 |
| infinity | rbasak: But yes, from a docker perspective, you've done all you can do. If the right GCC bits existed, your packages would just magically work. | 16:28 |
| rbasak | infinity: ack. I don't really expect it to happen either. | 16:28 |
| infinity | rbasak: With 16.04 "around the corner" (at least, at the speed that "Enterprise" people move, it may as well be tomorrow), I think we can probably convince people that just waiting for the next LTS will have to do. Or they can pay us big money to clone doko. | 16:30 |
| rbasak | I find it a bit silly really. | 16:30 |
| rbasak | "We must use the LTS because it's stable" but also "We must change the LTS so people can use this extra new shiny stuff". | 16:30 |
| infinity | rbasak: I don't find the request silly. Their goal is feature parity with x86, and their target market doesn't want releases with 9mo support. But that doesn't mean we don't get to put our foot down when a request just isn't serviceable. | 16:31 |
| rbasak | The issue I have with it is that they want it in yesterday's release rather than tomorrow's release. But anyway, yes, it's not as simple as that. | 16:32 |
| infinity | rbasak: And it *could* be done without destabilising the LTS, with a careful backported compiler with a different name and a private libgcc1, etc, etc. But that's a lot of work that our contract doesn't cover, and there's only so much time we have to spend being "nice" to people who can afford to pay instead of ask for favours. :) | 16:33 |
| rbasak | I'd like to see "third party overlays" to work better than PPAs. So Snappy I guess. | 16:33 |
| infinity | rbasak: snappy isn't exactly a magic bullet here. The fundamentals are still the same, in that you need a new toolchain, and some human has to maintain that. | 16:33 |
| rbasak | Snappy would make all this Docker and Juju backporting pain go away quite nicely, and in a way that I think everyone would be happy with. | 16:33 |
| rbasak | You could use Vivid's toolchain. | 16:34 |
| rbasak | But target Trusty. | 16:34 |
| infinity | rbasak: The naive "app store" model where people just throw random bits at users and don't care about bugs, sure, that "solves" it, but not in any way I'd want to sell to a customer like IBM. | 16:34 |
| rbasak | The model is basically exactly how users consume Docker today. | 16:34 |
| rbasak | Or any other third party publishing an apt repository | 16:35 |
| rbasak | Many of them build binary packages directly with no "source package" (though obviously they have a source) | 16:35 |
| rbasak | See fpm, etc. | 16:35 |
| infinity | rbasak: Yes. And early adopters of docker are the sorts of cowboys who don't care about security. That's going to change. And we need to be ready to do it right, IMO. | 16:35 |
| rbasak | I think Snappy could still solve that, with a layer on top for reproducible builds, etc. | 16:36 |
| rbasak | (a build-time tooling layer, that is) | 16:36 |
| infinity | rbasak: ie: They don't care if they statically link a libc that hasn't had an update in 3 years, cause that's their build chroot, and who cares. When people who aren't github cowboys adopt this sort of model, things will change. They have to. | 16:36 |
| cjwatson | You can use vivid's toolchain for a trusty PPA, too, if you don't care about it being self-contained - snappy ~= PPAs for this purpose | 16:36 |
| cjwatson | Although you'd have to statically link libgcc1 or something | 16:36 |
| rbasak | But PPAs are hacky in, for example, managing the namespace. | 16:36 |
| rbasak | (both package namespace and filesystem namespace) | 16:37 |
| rbasak | They all collide with each other. | 16:37 |
| rbasak | If we want third parties to be able to independently publish stuff, then giving them separate namespaces for everything would work better. | 16:37 |
| infinity | rbasak: Oh, I'm not saying the appstore/snappy model doesn't solve SOME problems. It does. | 16:37 |
| rbasak | And no need to give them root. | 16:37 |
| infinity | rbasak: It absolutely does. | 16:37 |
| infinity | rbasak: But it's not a magic bullet for maintaining code. The idea that we can just stop caring about bug fixes for software *we* produce (ie: the toolchain) is a bit lolz. | 16:38 |
| rbasak | I don't think anyone's saying that. | 16:38 |
| infinity | rbasak: docker users do. At least, that's the usual model. | 16:40 |
| infinity | rbasak: docker users treat containers as black box blobs they don't tend to have to care about. And snappy is in danger of that same sort of usage, so we need to be careful, that's all. | 16:41 |
| rbasak | I think that all we can really do is document (and follow) best practice. | 16:42 |
| infinity | rbasak: Yeah. The "and follow" bit is the important part. snaps we produce, or docker images we provide, or any such thing that comes from us, needs to follow our classic distro support model and lead by example. | 16:43 |
| infinity | rbasak: Other people can produce crap, and that's unfortunate, but we need to show people there's a right way. | 16:43 |
| rbasak | Agreed | 16:43 |
| ricotz | infinity, hi, can you trigger a retry of https://launchpad.net/ubuntu/+source/x264/2:0.146.2538+git121396c-3 ? | 18:05 |
| infinity | ricotz: Done. | 18:10 |
| infinity | ricotz: Well, attempted... | 18:11 |
| infinity | ricotz: Oh. It breaks horribly because sbuild doesn't support filtering out <profiles> .... Except it should. Hrm. | 18:12 |
| infinity | Oh. No, that probably needs backporting. Grr. | 18:12 |
| ricotz | infinity, ah, I see (pbuilder does it fine) | 18:13 |
| infinity | ricotz: sbuild does it fine in wily too. | 18:14 |
| ricotz | and the builders are trusty ;) | 18:14 |
| infinity | ricotz: It's that the buildds are trusty (and some precise), and they don't grok the syntax. | 18:14 |
| infinity | cjwatson: Meh, I don't just need apt/python-apt backports for profiles, I also need a libdpkg-perl mangling, I think. Time to find some Free Time. | 18:15 |
| infinity | ricotz: The simplest thing for now would be to introduce an Ubuntu delta that strips the <profile> bits, but we obviously need to fix this on the infra side Very Soon. | 18:16 |
| cjwatson | We do | 18:17 |
| ricotz | infinity, ok, except for the gpac and ffmpeg transition there is no hurry for that build | 18:17 |
| ricotz | on that thought, there is a ffmpeg transition taken care of? | 18:17 |
| Gallomimia | hi everyone. i'm really annoyed by the following message: http://pastebin.com/fRuGxjeh it is found in thunderbird upon launching, and it really bothers me to learn that there's a nightly build installed of software i use. without my permission or foreknowledge | 18:28 |
| sarnold | Gallomimia: apparently that just means mozilla folks haven't written the introduction page for that release yet | 18:30 |
| sarnold | Gallomimia: if you'd like to follow the progress, the bug is https://bugzilla.mozilla.org/show_bug.cgi?id=1186390 | 18:31 |
| ubottu | Mozilla bug 1186390 in Thunderbird ""Welcome to Daily!" message in thunderbird 31.8.0" [Normal,Unconfirmed] | 18:31 |
| Gallomimia | typical. sorry for assuming it's package maintainers >< | 18:32 |
| hjd | sarnold: Neat. :) Do you think you could link that with bug 1476805? | 18:32 |
| ubottu | bug 1476805 in thunderbird (Ubuntu) "Thunderbird says it's Daily" [Undecided,Confirmed] https://launchpad.net/bugs/1476805 | 18:32 |
| sarnold | hjd: let me try :) | 18:33 |
| hjd | (don't know if Launchpad supports bug watches for bugzilla...) | 18:33 |
| sarnold | hjd: looks like the link worked :) | 18:34 |
| hjd | sarnold: :) | 18:34 |
| Guest91863 | guys remember the old ubuntu 9.10 theme. i love it a lot. my project is to get that old and light interface to ubuntu 14.04 and make an new ubuntu for old pc's with the classic theme :)) | 19:37 |
| sarnold | Guest91863: investigate MATE and Cinnamon, I think one of those may be what you want | 19:38 |
| Guest91863 | yes but the old theme is pretty cool :) | 19:39 |
| Guest91863 | do canonal give rewards for ubuntu developers ? | 19:41 |
| teward | 'rewards'? | 19:42 |
| flexiondotorg | cyphermox, Yo. It's been a while. o/ | 19:44 |
| cyphermox | flexiondotorg: hey! | 19:45 |
| flexiondotorg | cyphermox, I've been busy with stuff. But I did a fresh install of Ubuntu MATE 15.10 daily today. | 19:45 |
| flexiondotorg | cyphermox, I can see the foundations team have been busy :-D | 19:46 |
| Guest91863 | yes rewards | 19:46 |
| teward | Guest91863: contributing to the overall usefulness and betterment of the Ubuntu operating system isn't a reward in itself? | 19:46 |
| Guest91863 | yes but tings from canonal store like notebook or pen | 19:48 |
| * lamont has an ifup question... I currently have this in /etc/network/interfaces (albeit with a slightly different non-1918 IP): http://paste.ubuntu.com/11922261/ -- I'm pondering whether or not a 'src' option would be a good thing for /e/n/i to grow | 19:49 | |
| Guest91863 | i can see the ubuntu cursor in the boot screen when booting ?!?!?!???!? | 19:49 |
| Luke | xnox: do you have any good polkit config examples for systemctl service management? | 19:50 |
| cyphermox | flexiondotorg: tbh I'm not sure what would look different right now, I'm busy with multipath :) | 19:52 |
| flexiondotorg | cyphermox, Well VirtualBox does hang on restart after install and eject media works too. | 19:52 |
| sarnold | lamont: /etc/network/interfaces feels pretty archaic these days, doesn't it? multiple IPs ought to be better supported, that's just so common these days. src would make sense to me too.. | 19:53 |
| flexiondotorg | cyphermox, And the virtualbox drivers now install again from software-properties :-) | 19:53 |
| cyphermox | that's good | 19:53 |
| lamont | sarnold: true | 19:53 |
| flexiondotorg | cyphermox, Yep. For people testing that is 2 less QA trackers I'll get next week with Alpha 2. | 19:53 |
| infinity | sarnold: How should multiple IPs be "better" supported? Seems well supported to me. | 20:03 |
| flexiondotorg | infinity, I'd agree with that I just equipped a new aircraft with a device running Ubuntu and 16 ethernet interfaces. | 20:07 |
| sarnold | infinity: afaik the way to do it is to specify one address via 'address', and then additional addresses via 'up ip addr add ...' | 20:08 |
| sarnold | infinity: I know I've spent some time reading the manpages to figure out if there's a way to specify multiple 'address' lines, and folks have asked in #ubuntu-server about it, and always seem slightly dissapointed when the answer is 'use up ip addr ...' | 20:09 |
| infinity | sarnold: Oh, I just add "iface eth0:0", "iface eth0:1", etc. | 20:09 |
| sarnold | infinity: heh, that method of interface aliasing has been deprecated for over fifteen years now :) one of these days it's really going to go away! I'm sure of it! | 20:10 |
| infinity | sarnold: Un huh. | 20:10 |
| sarnold | infinity: while I've got an open wishlist going, it'd also be nice if /etc/network/interfaces could allow you to specify tc limits in human-friendly ways :) | 20:13 |
| cyphermox | sarnold: https://wiki.debian.org/fr/NetworkConfiguration#Adresses_IP_multiples_pour_une_interface | 20:15 |
| cyphermox | I know it's in french, but it documents just adding the extra IPs in separate stanzas | 20:16 |
| cyphermox | I'd like to believe it works :) | 20:16 |
| cyphermox | (scroll to the end) | 20:16 |
| sarnold | cyphermox: oh! interesting | 20:16 |
| cyphermox | let me know if it works, it's a pretty cool trick that probably should make it to the manpage | 20:17 |
| cyphermox | (as so is 'up blah') | 20:17 |
| teward | cyphermox: that method would work, so would manual addition with ip addr add .. | 20:18 |
| teward | (i have that for one of my odd setups) | 20:18 |
| cyphermox | ok | 20:18 |
| teward | (some VPSes have that approach too) | 20:18 |
| cyphermox | then it's just a matter of opening a bug in debian to suggest adding a note that this works to the manpage | 20:19 |
| teward | i haven't tested it on a recent one, perhaps I should | 20:19 |
| teward | then get back to you | 20:19 |
| teward | or sarnold can test it | 20:19 |
| teward | (last server i did this on i haven't modified for a year and a half, and it's 12.04) | 20:20 |
| cyphermox | fwiw, it's in /usr/share/doc/ifupdown/examples/network-interfaces.gz too | 20:20 |
| flexiondotorg | Is there anyone out there who is thinking to themselves "I'd really love to sponsor an upload for Ubuntu MATE this evening?" ;-) | 20:22 |
| cyphermox | flexiondotorg: what do you want sponsored? | 20:29 |
| flexiondotorg | cyphermox, Well a few things, but this is the most important - https://bugs.launchpad.net/ubuntu/+bug/1476653 | 20:30 |
| ubottu | Launchpad bug 1476653 in Ubuntu "[needs-packaging] ubuntu-mate-welcome" [Wishlist,New] | 20:30 |
| flexiondotorg | cyphermox, I'd like it in for Alpha 2, which is fast approaching. | 20:30 |
| cyphermox | welcome wizard? | 20:31 |
| flexiondotorg | cyphermox, Yep, that sort of thing. | 20:32 |
| cyphermox | I know this is an evil idea, but depending on what it does, have you considered making it very generic and shipping customization bits for it, so that others could possibly reuse the code? | 20:33 |
| flexiondotorg | cyphermox, This is what it looks like - http://i.imgur.com/PRmBDxK.png | 20:33 |
| flexiondotorg | cyphermox, Right now, it is the "simplest thing possible". | 20:34 |
| cyphermox | yep | 20:34 |
| flexiondotorg | cyphermox, In a future version I'd like to make the content from templates so it is more reusable. But I need something to get banged on. | 20:35 |
| cyphermox | sure | 20:35 |
| flexiondotorg | cyphermox, That said, I has been well tested by about 20 people. So what it does now, works. | 20:35 |
| flexiondotorg | cyphermox, And the code I used is derived from Antergos, which was derived from Manjaro, which was derived from Korora. So it has a rich history of reuse :-) | 20:36 |
| cyphermox | flexiondotorg: by my reading, ubuntu-mate-welcome is the only file that is GPL-3, not GPL-2+ | 20:49 |
| cyphermox | (aside from the others under MIT or whatnot) | 20:50 |
| flexiondotorg | cyphermox, Err, let me double check that. | 20:50 |
| flexiondotorg | Hmmm, yes. The header would agree with that. I based my licensing on the COPYING file I inherited when I forked it. | 20:53 |
| flexiondotorg | Cydrobolt, Which is GPL-2. | 20:53 |
| flexiondotorg | cyphermox, How to proceed? Update copyright and resubmit tarball? | 20:55 |
| flexiondotorg | cyphermox, A quick bit of code archeology show this confusion was introduced in the fork before mine, Antergos. | 20:57 |
| flexiondotorg | cyphermox, The code ubuntu-mate-welcome is derived from has always been GPL-3. | 20:58 |
| cyphermox | yes | 20:58 |
| cyphermox | just update debian/copyright | 20:58 |
| flexiondotorg | cyphermox, So, update copyright and resubmit the tarball? | 20:58 |
| cyphermox | if you attached a source package to the bug, yes | 20:58 |
| Noskcaj | It seems the gcc5 version of ilmbase has broken the gegl build, can someone please explain how i can fix this? | 20:59 |
| flexiondotorg | cyphermox, Change pushed to git. Files on LP bug have been replaced :-) | 21:12 |
| Noskcaj | forgot to link https://launchpadlibrarian.net/212351937/buildlog_ubuntu-wily-amd64.gegl_0.3.0-2ubuntu2~gcc5.1_BUILDING.txt.gz | 21:34 |
| === salem_ is now known as _salem | ||
| TheMuso | slangasek: No, thanks for the heads up, will chase up. | 22:21 |
| Logan | doko: the python2.7 packaging is making me very sad | 22:49 |
| Logan | http://bazaar.launchpad.net/~ubuntu-branches/debian/sid/python2.7/sid/view/head:/debian/rules#L393 | 22:49 |
| Logan | it's using a README as a source of truth for what extensions are compiled into the binary | 22:49 |
| doko | Logan, so what's wrong? | 22:49 |
| Logan | I'm not sure how you don't see what's wrong with that | 22:50 |
| Logan | I spent a long time trying to figure out why datetime was compiled into the binary as an extension | 22:50 |
| Logan | only to figure out that the rules file is awking the README for lines ending in extension and then compiling them in | 22:51 |
| doko | so you want me to rename that file? | 22:51 |
| Logan | that would probably make sense | 22:52 |
| doko | and what do you gain? | 22:52 |
| Logan | the problem is that I pushed a new version to production servers and everything broke, and there was no mention in the changelog of this happening | 22:52 |
| doko | apparently nothing broke within the distro | 22:53 |
| Logan | we have virtualenvs that were built already that were looking for the datetime.so and couldn't find it after the upgrade | 22:53 |
| doko | not my problem | 22:53 |
| Logan | alright, thanks | 22:54 |
| doko | please don't misunderstand me, but virtualenvs really have issues when you upgrade the underlaying python interpreter. however this is a problem that should be addressed upstream | 22:55 |
| doko | I'm just surprised that you see this with the datetime.so module, because that should be built as a builtin at anytime | 22:56 |
| Logan | we were running a version before that was a built-in | 22:56 |
| doko | was that an upgrade across major python versions? | 22:57 |
| Logan | no, minor | 22:57 |
| Logan | to be fair, it was a very old version | 22:57 |
| Logan | so it's not exactly a supported upgrade path | 22:57 |
| Logan | but I would really recommend not calling that a README.in to show that it's not only changing documentation | 22:58 |
| Logan | I had done a debdiff and thought that change was inconsequential since nothing related to datetime had changed in the rules | 22:58 |
| doko | well, the reason for that is to have one source, and document it | 22:58 |
| Logan | understood | 22:59 |
| Logan | sorry, I really appreciate the work you've done on this package | 22:59 |
| Logan | just wanted to let you know what happened so that maybe there could be more clarification in the packaging about what is a source of truth | 23:00 |
| doko | I shouldn't be that sloppy with changelogs ... but if you have any ideas how to document the state of virtualenvs and what might happen, that would be nice. however that should be done as a wiki page, and then be referenced | 23:03 |
| mwhudson | infinity, doko: so can you tell me about the debian/patches/016-armhf-elf-header.patch in the go packaging | 23:15 |
| infinity | mwhudson: Maybe. It's been a while. | 23:15 |
| doko | golang? | 23:15 |
| mwhudson | this seems to make go built on armhf (vs armel?) produce binaries that claim to adhere to the hardfloat abi | 23:15 |
| mwhudson | doko: yes | 23:16 |
| infinity | mwhudson: Was that the one where I fixed their braindead linker to behave like bfd? | 23:16 |
| mwhudson | infinity: maybe? your name is on it | 23:16 |
| infinity | mwhudson: Right, sounds like that's the one. | 23:16 |
| infinity | mwhudson: So, what needs explaining? | 23:16 |
| mwhudson | infinity: well that code is in Go now, so some stuff needs to change, but i'm not sure what relly | 23:17 |
| mwhudson | infinity: well, what bad things happen without it? | 23:17 |
| infinity | mwhudson: They wrong a linker in Go? | 23:17 |
| mwhudson | go -> go calls don't really follow the platform abi at all | 23:18 |
| mwhudson | so this must be about c<->go stuff | 23:18 |
| mwhudson | infinity: there is no c code in the golang distribution any more | 23:18 |
| infinity | mwhudson: It's self-hosting? | 23:19 |
| mwhudson | yep | 23:19 |
| infinity | How does one bootstrap it? | 23:19 |
| mwhudson | go 1.4 or gccgo | 23:19 |
| infinity | Huh. The lack of bug ref is annoying. | 23:20 |
| infinity | I blame myself. | 23:20 |
| doko | hmpff, no, go 1.4 is no option for some archs | 23:20 |
| infinity | But there was definitely a bug being fixed. :P | 23:20 |
| mwhudson | doko: so, gccgo! | 23:22 |
| mwhudson | it's even officially recommended in the docs | 23:22 |
| mwhudson | (because i wrote a doc patch...) | 23:22 |
| doko | I saw | 23:22 |
| infinity | mwhudson: https://bugs.launchpad.net/ubuntu/+source/golang/+bug/1187722 | 23:22 |
| ubottu | Launchpad bug 1187722 in golang (Ubuntu) "dpkg-shlibdeps fails on armhf ELF binaries that do not define architecture specific information" [High,Fix released] | 23:22 |
| mwhudson | infinity: my brain hurts already | 23:24 |
| infinity | mwhudson: So, the real "bug" is that we (Debian and Ubuntu) insist on differentiating between hf and sf, while most people only ever build for one target or the other, so don't give a crap. | 23:24 |
| infinity | mwhudson: But, since we do care about the difference, we need to tag binaries correctly. | 23:24 |
| mwhudson | yeah | 23:24 |
| infinity | mwhudson: gcc, glibc, and binutils upstream all abide by this. | 23:25 |
| mwhudson | man | 23:25 |
| mwhudson | i can sort of see why go has its own linker | 23:25 |
| infinity | mwhudson: The crap linker that golang cargo-culted from some ancient bsd fork didn't. :P | 23:25 |
| mwhudson | but i wish they wouldn't bother when linking against system libraries | 23:25 |
| infinity | mwhudson: And I somehow doubt it's improved since they rewrote it. | 23:25 |
| infinity | mwhudson: Incidentally, the reason I never upstreamed this is because it's fundamentally not upstreamable in its current form. | 23:26 |
| mwhudson | upstream would (and hey, i see did) object because it's too much influence from the build environment | 23:26 |
| infinity | mwhudson: It assumes build arch == host arch, which is a false assumption in golang, I believe? | 23:26 |
| mwhudson | right | 23:26 |
| infinity | mwhudson: It should actually be testing the target arch, not ifdef'd at build time like I did. | 23:27 |
| mwhudson | also i think someone about 5 years ago thought arch was a simple concept :) | 23:27 |
| infinity | mwhudson: But, if it were to test the target arch for hard-floatiness, this is conceptually correct to upstream. | 23:27 |
| mwhudson | yes | 23:27 |
| mwhudson | there is a GOARM knob | 23:27 |
| mwhudson | which is set to 5,6,7 to indicate armvX | 23:28 |
| mwhudson | and maaaaybe GOARM==7 implies hardfloatiness? | 23:28 |
| infinity | It wouldn't. | 23:28 |
| mwhudson | it's one of those "sort of related but not really" things | 23:28 |
| mwhudson | the reason i care about this today is i want to do some rebuild testing | 23:28 |
| mwhudson | and i think for those purposes i can just set the flags to hardfloaty because that's what we actually want always on ubuntu | 23:29 |
| infinity | For all I know, golang isn't hf at all (as in, maybe it doesn't use vfp registers), or maybe it's selctively hf if a vfp exists. | 23:29 |
| infinity | But what matters is the floatiness of the C bits its linking against. | 23:29 |
| infinity | It's entirely possible to write float-agnostic binaries that do all this at runtime. Only crazy people do, mind you. | 23:29 |
| infinity | My guess is golang doesn't. | 23:30 |
| infinity | And should actually tag what they really are. | 23:30 |
| infinity | But meh. | 23:30 |
| mwhudson | is that what the bit in the flag means thought? | 23:30 |
| infinity | mwhudson: But yes, for Ubuntu, you can probably get away with ARM == ARMhf for now. We've been basically that incorrect for years, and no one's complained. | 23:30 |
| mwhudson | i thought soft float hard float was more "do float args go in registers" | 23:30 |
| infinity | mwhudson: The bit in the flag means "uses vfp registers" or "not". | 23:31 |
| infinity | mwhudson: Err, for args, yeah. | 23:31 |
| infinity | mwhudson: I was shorthanding. | 23:31 |
| mwhudson | $CC -dumpmachine | grep armhf ? >:) | 23:32 |
| mwhudson | er gnueabihf rather | 23:33 |
| * mwhudson looks gingerly at the horror that is aarch32 codegen | 23:35 | |
| infinity | mwhudson: Anyhow, I don't speak Go, so I doubt I'd be much help forward-porting the patch, but I'd like to think it'll be trivial. If you can find the right bit to fix in the first place. :/ | 23:35 |
| infinity | mwhudson: But it would be a nice bonus if you could sort out how to do it in a correctly upstreamable way, so we can forget about it. | 23:36 |
| infinity | (I'd forgotten about it, cause I never thought anyone would be silly enough to rewrite a linker twice) | 23:36 |
| mwhudson | infinity: so the issue is something like: if linking against system libraries, then the tag needs to match the system libraries | 23:36 |
| infinity | Especially not with two very good linkers already available to them... | 23:36 |
| infinity | mwhudson: Well, no. And yes. And maybe. | 23:37 |
| infinity | mwhudson: Really, the flag should represent what the binary is. And the binary should only be linked against libraries of the same sort. | 23:37 |
| infinity | mwhudson: Because ld.so wants those things to be true. | 23:37 |
| mwhudson | infinity: if the binary is static, the flag is close to meaningless | 23:37 |
| mwhudson | surely | 23:37 |
| infinity | mwhudson: It lets you get away with untagged linking to tagged for backward compat, but that's Not Right. | 23:37 |
| infinity | mwhudson: Not all Go binaries are static, thus the tag needs to be correct sometimes, so just make it correct always? :P | 23:38 |
| * mwhudson looks for arm c/go glue code | 23:38 | |
| mwhudson | infinity: well yeah | 23:38 |
| infinity | mwhudson: In our case, we want it correct always, because we look at it for other reasons. | 23:38 |
| mwhudson | er er | 23:38 |
| mwhudson | is this flag set in relocatable object (.o) files? | 23:39 |
| mwhudson | yes looks like it | 23:41 |
| infinity | Well, sort of? | 23:42 |
| mwhudson | when using cgo the (go) linker reads some files that have been compiled with the system compiler | 23:42 |
| infinity | It's not generally correct. | 23:42 |
| mwhudson | and istm that the flags on the binary must match the flags from those files | 23:42 |
| mwhudson | as it's those files that contain the calls to the system libs | 23:42 |
| mwhudson | that might be overthinking tho | 23:42 |
| mwhudson | i'm now actually wondering if using cgo to call a c function with a float arg works at all :-) | 23:43 |
| mwhudson | (on arm) | 23:43 |
| mwhudson | oh hey upstream bug https://github.com/golang/go/issues/7094 | 23:44 |
| mwhudson | comment 3 is basically what i would write :) | 23:45 |
| infinity | Yeah. | 23:45 |
| infinity | So, trusting intermediate objects to have sane headers will fail you. | 23:45 |
| infinity | Random example I had lying around on my filesystem... | 23:45 |
| mwhudson | Flags: 0x5000000, Version5 EABI | 23:46 |
| mwhudson | thanks gcc | 23:46 |
| infinity | http://paste.ubuntu.com/11923048/ | 23:46 |
| infinity | Exactly. | 23:46 |
| infinity | Perhaps gcc also wants to be fixed here. But binutils is the only thing I know of that's doing the correct tagging. | 23:46 |
| infinity | Which is fine, cause we always link with ld. | 23:46 |
| infinity | Except when lolgo. | 23:47 |
| mwhudson | so +1 for thinking, minus several million for execution | 23:47 |
| mwhudson | well yeah, that's the other suggestion from minux: force external linking | 23:47 |
| mwhudson | (gospeak for "make a .o file and feed it to ld") | 23:47 |
| infinity | mwhudson: Honestly, I'd be more comfortable with "always use bfd on *all* linux arches", cause I don't trusty anyone to write linkers. | 23:48 |
| infinity | mwhudson: But meh. Fixing the Go linker to be sane probably makes sense. | 23:48 |
| infinity | s/trusty/trust/ | 23:48 |
| infinity | That release completely ruined my ability to type 'trust' | 23:49 |
| mwhudson | i don't trust the bfd authors either :-) but yeah | 23:49 |
| mwhudson | did you know -Bsymbolic-functions doesn't work on armhf? | 23:49 |
| infinity | Isn't that documented? | 23:50 |
| infinity | Something along those lines is, I thought. | 23:50 |
| mwhudson | no, it's just a bug | 23:51 |
| mwhudson | well maybe it's a documented bug i dunno | 23:51 |
| mwhudson | oh right, it's only with function pointers, not function calls: https://sourceware.org/bugzilla/show_bug.cgi?id=18646 | 23:52 |
| ubottu | sourceware.org bug 18646 in ld "function pointer values are still interposed with -Bsymbolic-functions on ARM" [Normal,New] | 23:52 |
| * mwhudson waits for clang to install in his armhf chroot | 23:59 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
