| pitti | good morning | 05:18 |
|---|---|---|
| === ppisati_afktmux is now known as ppisati | ||
| === jamesh__ is now known as jamesh | ||
| pitti | cking: good morning! | 08:29 |
| cking | hi there | 08:29 |
| pitti | cking: I read through the logind code a bit and now have a local build with debugging enabled; could we do another round of ssh? | 08:30 |
| cking | pitti, sure, let me get the machine up and running, it will take a few minutes | 08:31 |
| === marcusto_ is now known as marcustomlinson | ||
| peat-psuwit | I'm compiling pulseaudio for armhf on amd64 using chroot and qemu-arm-static. But thread-mainloop-test, thread-test and sigbus-test fail. Any advice? | 09:19 |
| sidi | I've got a ubuntu package that contains a "ubuntu-patches" folder on top of the usual "debian/patches". What am I to do with it? Is there a way to integrate the outcome of those patches with quilt? i.e. quilt push obviously doesn't apply those patches, but i dont wanna have to apply them to work on my package, and then unapply them to generate clean diffs for my own patches. I'm also curious how they're handled when automatically building packages | 09:23 |
| rbasak | sidi: why aren't these patches in a place where quilt maintains them? | 09:24 |
| sidi | rbasak, i have no idea. i'm actually here to understand whether that is a normal thing or an issue with that package | 09:31 |
| sidi | it's lp:ubuntu/vivid-proposed/gpaste, for the record | 09:31 |
| rbasak | sidi: I've not seen that before. Looks like upstream is keeping those files around - not the Debian maintainer. | 09:33 |
| sidi | rbasak, oh, right! thanks for checking up. interestingly the package doesn't build (syntax errors on the Makefile which I suspect are linked to those 2 patches not being applied) | 09:35 |
| rbasak | sidi: it's currently built on Vivid. You mean it fails to rebuild now? | 09:35 |
| sidi | rbasak, hm you're correct. bzr bd -- -b works, but ./autogen.sh && ./configure && make doesn't. | 09:40 |
| sidi | i'm not a debian/ubuntu packager so i don't understand what exactly builddep or debuild do differently | 09:40 |
| sidi | i'm starting to suspect the app just has a buggy configure.ac, missing dependencies though | 09:41 |
| cjwatson | The entry point used by debuild etc. is debian/rules, not directly via ./autogen.sh etc. | 09:41 |
| sidi | i did have to install one more builddep (appdata-tools), and it seems the ubuntu-patches remove that dependency for old ubuntus but are unapplied by default | 09:41 |
| === gusnan is now known as Guest91434 | ||
| === Guest91434 is now known as gusnan | ||
| LocutusOfBorg1 | good morning developers! | 10:29 |
| LocutusOfBorg1 | pitti, how is going the systemd progress? I see it going nice, I hope to have it in vivid ;) | 10:30 |
| pitti | hey LocutusOfBorg1 | 10:30 |
| LocutusOfBorg1 | I'm using it since a month for my embedded yocto sytems and I LOVE it :) | 10:30 |
| pitti | LocutusOfBorg1: looks ok so far; I'm crawling through the bugs, but we are now at the level of "happens in rare circumstances and needs lots of debugging" | 10:31 |
| LocutusOfBorg1 | I hope you won't revert the change for vivid | 10:31 |
| pitti | so far nobody asked for that | 10:31 |
| LocutusOfBorg1 | wonderful! I see the last debian rc have been squashed | 10:31 |
| pitti | it has certainly been a lot of pain, and I'm grateful for the vivid testers for bearing with it | 10:31 |
| LocutusOfBorg1 | I'm also testing vivid right now | 10:32 |
| LocutusOfBorg1 | I don't bother unless I see bugs :) | 10:32 |
| LocutusOfBorg1 | BTW pitti I have an eth.network file, how can I say "try udhcpc and if DHCP fails take this ipv4 address?" | 10:34 |
| LocutusOfBorg1 | this is the file https://github.com/gumstix/meta-gumstix-extras/blob/dizzy/recipes-core/systemd/files/eth.network | 10:34 |
| LocutusOfBorg1 | maybe you can give me a pointer, adding Address below doesn't work | 10:34 |
| pitti | LocutusOfBorg1: sorry, I haven't done anythign with networkd yet, I'm afraid; can you try asking in #systemd? | 10:36 |
| LocutusOfBorg1 | yes, I'll debug something more and then ask :) | 10:36 |
| LocutusOfBorg1 | thanks | 10:36 |
| LocutusOfBorg1 | question: is it normal that "reboot" on vivid doesn't require sudo anymore? | 10:42 |
| LocutusOfBorg1 | pitti, ^^^ | 10:42 |
| LocutusOfBorg1 | :) | 10:42 |
| pitti | LocutusOfBorg1: if you are in a local desktop session, there's a polkit rule which allows that | 10:43 |
| pitti | pkcheck --action-id org.freedesktop.login1.reboot --process $$ | 10:44 |
| LocutusOfBorg1 | thanks! | 10:44 |
| pitti | this requires a "challenge" (i. e. entering your admin password) on remote sessions, but is currently allowed locally it seems | 10:44 |
| pitti | similar to mounting usb sticks, setting the clock, etc. | 10:45 |
| pitti | (or rebooting through the indicator) | 10:45 |
| LocutusOfBorg1 | thanks | 10:46 |
| mdeslaur | pitti: thank you very much for fixing my nfs at boot, and the subsequent shut down hang! Very appreciated! | 11:29 |
| pitti | mdeslaur: *beam* good news! | 11:33 |
| mdeslaur | :) | 11:33 |
| === gnuoy` is now known as gnuoy | ||
| === MacSlow is now known as MacSlow|lunch | ||
| Riddell | dpm: why is launchpad still recommending translating utopic a month from releasing vivid? | 12:18 |
| dpm | Riddell, probably because we did not change the translation focus, let me check | 12:18 |
| === _salem is now known as salem_ | ||
| dpm | Riddell, fixed. Seems like we hadn't changed the translation focus when we opened vivid translations a while ago | 12:20 |
| Riddell | dpm: lovely thanks | 12:20 |
| dpm | np | 12:20 |
| seb128 | "Object: <lp.registry.model.personproduct.PersonProduct object at 0x2afba3735ad0>, name: u'pin-dbusmock'" | 12:26 |
| seb128 | thanks lp, useful error :p | 12:26 |
| seb128 | oh, somebody deleted the merge request while I had it open that's why it couldn't post on it | 12:27 |
| === MacSlow|lunch is now known as MacSlow | ||
| pitti | infinity, didrocks: FYI, the systemd test regression (most of it) is now tracked down, I filed bug 1439191 | 13:11 |
| ubottu | bug 1439191 in xserver-xorg-video-cirrus (Ubuntu) "[vivid regression] X.org fails to start on i386 cirrus" [Undecided,New] https://launchpad.net/bugs/1439191 | 13:11 |
| pitti | worked around by running the test with -vga vmware, like vivid's qemu does now by default | 13:12 |
| didrocks | pitti: great! | 13:12 |
| pitti | simple to reproduce in qemu | 13:13 |
| infinity | pitti: Yay. | 13:14 |
| pitti | it'll still fail on another test, didrocks is bisecting | 13:14 |
| pitti | that looks like an actual regression | 13:14 |
| pitti | so, yay tests | 13:14 |
| infinity | Now to get the kernel people to fix their tests on i386... | 13:15 |
| infinity | apw: ^ | 13:15 |
| apw | infinity, those look to be a testbed failure on i386, and are being rerun | 13:15 |
| infinity | apw: I noticed the re-run, I didn't look at the logs, just remembered that it's been failing on i386 for ages. | 13:16 |
| * infinity reads a log. | 13:16 | |
| apw | apw, the results i looked at looked like success up to that point, though it may yet fail again genuinly | 13:16 |
| apw | the logs having no summary near the end does not help any | 13:17 |
| infinity | Indeed, lots of hunting with find. | 13:17 |
| infinity | pitti: I don't suppose autopkgtests have a concept of "why"? | 13:18 |
| infinity | pitti: As in, "I was triggered because of a change in package-foo". | 13:18 |
| pitti | infinity: not at the moment with our really crappy setup | 13:18 |
| apw | infinity, to my reading all the ' END ' statements are ' END GOOD ' so i think that means it would have been green | 13:19 |
| pitti | quite easy to do once we move to something sensible with AMQP | 13:19 |
| infinity | pitti: These kernel build tests are completely pointless (and take forever) for kernel uploads themselves, but very necessary for toolchain uploads, for instance. | 13:19 |
| pitti | apw: right, it failed on copying the results back up, which sometimes triggers this odd tar EOF error which I've never been able to reproduce (but it happens quite frequently on the CI machines) | 13:19 |
| pitti | infinity: right, this is known and has been discussed a lot of times; but the current setup is fragile enough as it is, I really don't want to spend a lot of time changing and breaking it | 13:20 |
| infinity | Yeah, fair enough. | 13:20 |
| pitti | heck, in that time I could probably get my AMQP prototype to work reliably enough :) | 13:20 |
| * apw hands pitti a doughnut as encouragement | 13:21 | |
| infinity | Mmm, doughnuts. | 13:23 |
| infinity | pitti: I'm well aware that the current autopkgtest infra is far from what you'd like it to be, which is why I try to refrain from talking shit about it. :) | 13:25 |
| infinity | pitti: But once it morphs into what it's meant to be, I might have some input into all the ways it sucks. :P | 13:25 |
| pitti | infinity: oh, yes :) (there are lots of ways indeed..) | 13:27 |
| infinity | pitti: Mostly, my obvious complaint (if we ignore Jenkins) is just reliability. Comparing to our buildd network, which rarely (at least, in a comparison of failures per number-of-builds) needs attention, this all seems rather fragile. | 13:28 |
| pitti | right; the biggest machinery related ones that I see are (1) that tar EOF thingy, (2) apt hash sum mismatches, and (3) uninstallable packages | 13:29 |
| pitti | and there are tons of flaky tests which need regular retries | 13:29 |
| infinity | pitti: Yeah, flapping tests are obviously not your fault, though maybe we should try to build a small army of people to drive that closer to zero so we can actually have a good clean baseline for future comparison. | 13:30 |
| pitti | we do have some defence against (2) by retrying automatically once after 15 seconds, but that might need some improvement too | 13:32 |
| pitti | as for (3), that's a case for detecting that from the logs and auto-retrying half an hour later or so | 13:32 |
| pitti | some kind of "transient error" result code which makes adt-britney just retry in the next run | 13:33 |
| infinity | pitti: Yeah, I was going to suggest auto-retrying for known infra bugs. Wasn't sure if you, like me, once held the opinion that forcing yourself to manually intervene reminds you that there's a bug that needs investigating, but as I get older and wiser(?), I'm realising that's BS, and all it does is train me to do the busywork every day, not fix the bug. | 13:35 |
| pitti | infinity: yeah, that sounds terribly familiar | 13:35 |
| pitti | I tried to investigate and understand the tar EOF bug like 5 times and wasted a day or so on that in total, but I'm none the wiser | 13:36 |
| pitti | and it won't actually matter for the nova/cloud tests that CI is now running in parallel | 13:36 |
| pitti | ev: ^ incidentally, how does that go? | 13:37 |
| pitti | lol @ https://com.google/ | 13:40 |
| pitti | apw: oh, you were saying you use libvirt under systemd? I wondered how urgent bug 1312304 was | 13:46 |
| ubottu | bug 1312304 in libvirt (Ubuntu) "[systemd] libvirt-bin needs a unit file" [High,Triaged] https://launchpad.net/bugs/1312304 | 13:46 |
| apw | pitti, i am using it, it seems to work as is, it may be one of the slownesses, but not exploding m | 13:47 |
| apw | me | 13:47 |
| pitti | apw: ack, thanks | 13:47 |
| === mbiebl_ is now known as mbiebl | ||
| === salem_ is now known as _salem | ||
| ev | pitti: the majority of the work is done, but proving that this doesn't introduce failures that weren't present in the Jenkins adt infra remains: https://trello.com/c/MelDDUma/193-2-ue-staging-testing-infrastructure-to-cope-with-increased-load-of-tests | 13:59 |
| ev | It's at the top of the proposed backlog. If this is important to QA and Foundations, I ask that you send your stakeholder reps to our backlog meeting Thursday the 9th to lobby for it. | 13:59 |
| ev | ^ Ursinha heads up | 13:59 |
| === _salem is now known as salem_ | ||
| === salem_ is now known as _salem | ||
| infinity | ev: I'm all for proof and testing, but I'll also cautiously say that it would take deliberate action to create something worse than the current shoestring and bubblegum infra. :P | 14:01 |
| ev | lol | 14:01 |
| ev | can I rise to that challenge? | 14:01 |
| infinity | I'd prefer you didn't. | 14:02 |
| ev | hahaha | 14:02 |
| === gusnan is now known as Guest86151 | ||
| === doko_ is now known as doko | ||
| === _salem is now known as salem_ | ||
| === marcusto_ is now known as marcustomlinson | ||
| === gusnan_ is now known as gusnan | ||
| cjwatson | pitti: Hm, so I tried running a cleanup on the ddebs a-f database in the same kind of way that Launchpad now does regularly to maintain reasonable performance, and this doesn't look good: http://paste.ubuntu.com/10718827/ | 15:25 |
| * cjwatson tries for rtm | 15:25 | |
| pitti | cjwatson: hmm, I remember clearly that I worked on vacuuming the database the other day, but I indeed got some errors there | 15:26 |
| pitti | which is why I didn't roll it out | 15:26 |
| pitti | but not these errors | 15:26 |
| cjwatson | Heh, for RTM this gives me an 8K resulting DB, I might not have got it quite right | 15:27 |
| pitti | some weird bdb "out of memory"-like message | 15:27 |
| pitti | cjwatson: I tried with http://ddebs.ubuntu.com/clean.conf | 15:27 |
| cjwatson | This screams of "time to nuke the db and start from scratch" to me | 15:27 |
| pitti | yeah, can do; it takes ~ 1.5 days | 15:28 |
| pitti | but oh well | 15:28 |
| cjwatson | pitti: OK, there's definitely something wrong with this cleanup procedure, http://paste.ubuntu.com/10718856/ | 15:29 |
| cjwatson | Ah, needs to be run in the right directory because the paths in the cachedb aren't absolute, unlike in LP | 15:38 |
| cjwatson | (Which is a bit of a timebomb really ...) | 15:38 |
| === Raccoon changed the topic of #ubuntu-devel to: HAPPY APRIL FOOLS DAY! | #ubuntu-devel Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: | ||
| === cjwatson changed the topic of #ubuntu-devel to: Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: | ||
| seb128 | barry, hey, is https://errors.ubuntu.com/problem/44254dfe1ed3a5acdec9c4e4172b009e905dcd89 still on your todolist? it seems the issue started with your python3 port of oneconf | 15:42 |
| cjwatson | pitti: I'll see if the BDB repair tools can fix it ... | 15:43 |
| barry | seb128: yeesh. first i've seen of it. no clue what's going on but it looks like it's going to be a python3-apt problem perhaps | 15:43 |
| cjwatson | pitti: For RTM, this reduces the DB size from ~44MB to ~15MB. You do want the more complete architecture list from my paste, though (it should be the union of all architectures in any published suite) | 15:43 |
| pitti | cjwatson: ack, thanks | 15:44 |
| pitti | cjwatson: updated clean.conf | 15:44 |
| barry | seb128: i'll keep a tab open on it, but no promises. i'm fully saturated trying to finish up worky-work before pycon next week. ;) | 15:44 |
| cjwatson | pitti: This is all yak-shaving because I was looking for a plausible place to stick a timestamp of the BPPH threshold from LP :) | 15:45 |
| pitti | cjwatson: if it's broken, just rm'ing it shoudl suffice, the next cron run will then run for ages and rebuild it | 15:45 |
| cjwatson | pitti: (I don't think I need to keep a separate map of which ddebs it already knows about, though; whether they exist in pool should be sufficient) | 15:45 |
| cjwatson | pitti: You don't feel like moving ddeb-retriever to a real project so that I can use MPs, I suppose? | 15:46 |
| pitti | cjwatson: we can do that; it just never came up so far | 15:47 |
| pitti | but it seems it might live a whole lot longer still :) | 15:47 |
| teward | under the current freeze an upload which just enables position independent building for a given application wouldn't get past freeze would it? | 15:48 |
| pitti | cjwatson: (can't do it right now, sorry; can on on Tuesday, unless you or someone else beat me to it) | 15:49 |
| pitti | I'll be on vac tomorrow and national holidays Fri/Mon FTR | 15:49 |
| cjwatson | pitti: Sure, not a desperate rush. I'll be on nat holiday Fri/Mon and vac Tue | 15:49 |
| seb128 | barry, thanks | 15:56 |
| cjwatson | Ah, good, db5.1_dump | db5.1_load fixed the ddebs a-f cache | 16:07 |
| === gusnan is now known as Guest17266 | ||
| === Guest17266 is now known as gusnan | ||
| === salem_ is now known as _salem | ||
| doko | http://bugs.python.org/issue23842 | 17:48 |
| === _salem is now known as salem_ | ||
| ovidiu-florin | hello world | 18:32 |
| ovidiu-florin | doko: are you around? | 18:33 |
| teward | so, stupid question, but i'm getting FTBFS on nginx on ppc64el and powerpc because a change (from Debian) to enable PIE isn't recognized, has anyone seen this before and got an idea for how to fix? | 18:46 |
| sarnold | teward: can you pastebin the relevant compile line and error message? | 18:50 |
| teward | sarnold: http://paste.ubuntu.com/10719958/ <-- errors from the build logs (this was the latest upload, and using the changes as-is from Debian). http://paste.ubuntu.com/10719968/ <-- from debian/rules | 18:52 |
| sarnold | teward: hunh I wouldn'thave expected those to be configure flags.. | 18:53 |
| teward | sarnold: i didn't make the change, Debian did | 18:53 |
| teward | sarnold: suggestions to fix? | 18:53 |
| sarnold | teward: maybe that means a newer auto* is needed to provide a newer ./configure ? | 18:53 |
| sarnold | teward: (that's a wild-ass-guess) | 18:53 |
| teward | sarnold: considering this is in Vivid, IDK if that'd help | 18:53 |
| teward | sarnold: this is quite literally the output and information from the builders after the upload - no idea how to resolve | 18:53 |
| mdeslaur | if it works on other archs, I doubt it needs a new conf* | 18:56 |
| infinity | teward: There's no way those are configure flags. | 18:58 |
| infinity | teward: And it's broken on all arches, not just ppc... | 18:58 |
| teward | infinity: yes i know that | 18:58 |
| teward | infinity: i'm ahead of you, with a build in local sbuild to try and resolve | 18:58 |
| teward | (it'll be uploaded to fix the global FTBFS) | 18:58 |
| teward | infinity: i think someone up in Debian who made the change was drunk | 18:58 |
| === gusnan is now known as Guest55680 | ||
| mdeslaur | teward: you upload stuff without building it locally first? | 18:59 |
| teward | mdeslaur: that was a mistake, yes. | 18:59 |
| mdeslaur | the archive isn't your ppa | 18:59 |
| infinity | teward: Probably. I assume he meant to add -pie to ldflags and -fPIE to cflags. | 18:59 |
| teward | infinity: yes, indeed. | 18:59 |
| teward | mdeslaur: i misread the diff, assumed they changed the cflags, not configure flags | 19:00 |
| teward | mdeslaur: hence the failure in my part | 19:00 |
| teward | (yes it's not a PPA, it was a failure on my part to be thorough) | 19:00 |
| teward | (so sue me) | 19:00 |
| === Guest55680 is now known as gusnan | ||
| * infinity sues. | 19:00 | |
| * teward counter sues with the argument that everyone makes mistakes and to not berate one person for one occasional mistake | 19:00 | |
| * infinity sues harder, and in several jurisdictions. | 19:01 | |
| * teward yawns | 19:01 | |
| infinity | Anyhow, it happens. Patiently awaiting the new upload in the queue. | 19:02 |
| teward | infinity: it'll be there as soon as I berate Debian for being drunk, and my own sbuild schroot to update | 19:02 |
| * teward is raising hell :P | 19:02 | |
| infinity | teward: dpkg-buildflags might be more helpful here. | 19:03 |
| teward | infinity: mmm... probably. the rules file is set to have a different variable used in the compile time... | 19:05 |
| teward | debian_cflags:=$(shell dpkg-buildflags --get CFLAGS | sed 's/-O3/-O2/') $(shell dpkg-buildflags --get CPPFLAGS) <-- currently that defines the cflags for building | 19:06 |
| infinity | teward: Right, so it's already using dpkg-buildflags, you just need to pump up the fancy. | 19:06 |
| infinity | teward: Note the difference between "dpkg-buildflags" and "DEB_BUILD_MAINT_OPTIONS=hardening=+all dpkg-buildflags" | 19:06 |
| infinity | teward: That gets you PIE/pie and z,now, the two things noted missing in that bug report. | 19:08 |
| teward | yep | 19:08 |
| infinity | teward: So, probably exporting DEB_BUILD_MAINT_OPTIONS=hardening=+all above the current dpkg-buildflags calls would do the trick. | 19:09 |
| teward | infinity: right, i was about to do that just now | 19:09 |
| teward | urgh i hate gpg2 >.< | 19:11 |
| teward | it doesn't remember i unlocked the keys :/ | 19:11 |
| teward | infinity: in the sbuild schroot it seems that it's working and not FTBFSing. going to run the hardening-check against it after build though, because thoroughness | 19:17 |
| infinity | teward: Good deal. | 19:17 |
| teward | assuming it doesn't burn my CPU up in the process >.< | 19:17 |
| teward | urgh, now it's failing on perl | 19:22 |
| infinity | teward: Testing here to see if it makes sense to me. | 19:27 |
| teward | infinity: the failure looks like it's in the extras package | 19:27 |
| teward | god i hate perl | 19:27 |
| teward | ... have i said i hate perl yet? | 19:27 |
| infinity | teward: It might just be that the PERL_LDFLAGS bit needs to be less restrictive. | 19:28 |
| teward | MMM | 19:28 |
| teward | mmm* | 19:28 |
| teward | infinity: build logs from sbuild here: http://paste.ubuntu.com/10720164/ | 19:28 |
| teward | LOVELY thing about sbuild: logs are there :P | 19:28 |
| teward | infinity: please let me know if you have any insights, if it were up to me the third party modules would be gone but it's not up to me since so many users use -extras still | 19:29 |
| teward | (I can at least say nginx-core would not fail xD) | 19:30 |
| teward | infinity: any chance the hardening flags caused the failures? | 19:30 |
| teward | cause without them on ubuntu1, it worked fine apparently (from a build perspective) | 19:31 |
| infinity | teward: Yeahp, probably. I'm testing a bit here. | 19:33 |
| teward | infinity: ack. | 19:33 |
| ovidiu-florin | doko: ping | 19:49 |
| === salem_ is now known as _salem | ||
| infinity | teward: Hrm, this is slightly more annoying than I assumed it would be. | 19:51 |
| teward | infinity: indeed. | 19:52 |
| teward | infinity: in theory we could *manually* add the -fPIE -pie flag... | 19:52 |
| teward | infinity: the problem is that -extras has a lot of extra modules that... aren't core | 19:52 |
| teward | which is why we had to create -core for the MIR | 19:53 |
| teward | and i think the problem will trace back to the perl module | 19:53 |
| infinity | ovidiu-florin: Asking what you want to know might be more helpful than sending random pings out into the ether. | 19:59 |
| ovidiu-florin | infinity: I've been told to talk to doko, that's why I'm not asking | 20:01 |
| teward | infinity: i'm going to take a wild test and see if this happens with -fPIE added to only CFLAGS and not LDFLAGS - if it builds then great, if not, then we know the perl module is blocking PIE | 20:02 |
| teward | (if not other hardening flags) | 20:02 |
| infinity | teward: It's more likely that the perl modules are accidentally getting the PIE cflags, when they're libraries and should be PIC. | 20:05 |
| teward | infinity: i think it is since -fPIE is being passed in the LDFLAGS | 20:07 |
| teward | (at least, when i poke it on a Trusty system with that variable, running the command that generates the flags) | 20:07 |
| infinity | teward: Still playing here. Whee. | 20:11 |
| teward | infinity: well, stupidly, building with cflags only of -fPIE and not including -fPIE -pie in LDFLAGS seems to make the build succeed, but that doesn't help the perl side | 20:12 |
| teward | infinity: thanks for the assistance though, it helps having two people attacking the problem xD | 20:14 |
| teward | infinity: i think PIC and PIE are incompatible with each other because of shared objects... | 20:19 |
| teward | (I wonder if it's even possible to achieve this cause of the perl parts) | 20:20 |
| infinity | teward: Yes, I said as much up there. | 20:20 |
| teward | i missed that sorry | 20:20 |
| * teward yawns | 20:20 | |
| teward | i need sleep i guess :) | 20:20 |
| infinity | teward: Libraries are PIC, executables are PIE. | 20:20 |
| infinity | Fundamentally, it's pretty much the same thing, I wish the toolchain were a bit smarter and just turned pie into pic when -shared was specified. | 20:21 |
| mdeslaur | mmm...pie | 20:23 |
| teward | infinity: heh. | 20:25 |
| teward | well i'm running a... hackish... test... :/ | 20:26 |
| teward | locally of course | 20:26 |
| teward | i hate hackish solutions though :/ | 20:26 |
| teward | nice clean solutions, they work better... :/ | 20:27 |
| infinity | Hrm. I did something that built, but I'm not convinced it should have. | 20:28 |
| infinity | And still didn't link the nginx binary properly anyway. | 20:29 |
| teward | i don't think there's a clean method given Perl | 20:30 |
| teward | but we'll see, i'm curious if this thing i just did builds. | 20:30 |
| teward | it's still updating the schroot for the build deps heh | 20:31 |
| teward | infinity: i'd like to see what you did, if only to satisfy curiosity | 20:31 |
| teward | (kinda curious how you tested the linking too) | 20:31 |
| === JanC_ is now known as JanC | ||
| infinity | teward: I'd rather do something less buggy first. The linking failure clearly pointed at me being dumb. ;) | 20:32 |
| teward | heh | 20:32 |
| teward | infinity: ok. well again, i dont' want to detract from your likely busy schedule, but I do appreciate the help :) | 20:32 |
| infinity | teward: I need a distraction sometimes. | 20:32 |
| teward | heh | 20:32 |
| teward | infinity: i'm up to my 'hope it doesn't fail again' state :/ | 20:35 |
| infinity | There we go, that went better. | 20:38 |
| teward | infinity: mine built as well, question i had was how did you test linking of the binaries. | 20:38 |
| infinity | teward: hardening-check | 20:38 |
| teward | ... wow sbuild didn't put the .debs :/ | 20:38 |
| teward | infinity: well it'd be nice if sbuild had KEPT the .debs :/ | 20:38 |
| infinity | teward: http://paste.ubuntu.com/10720546/ | 20:38 |
| infinity | teward: That worked for me. | 20:39 |
| infinity | teward: With these results: http://paste.ubuntu.com/10720549/ | 20:39 |
| teward | infinity: that's effectively what I do but slightly different, I export +all,-pie and then add -fPIE to the debian_cflags separately | 20:39 |
| teward | (per the manpage explaining what buildflags adds for +pie) | 20:39 |
| infinity | teward: Needs to have -pie in ldflags, though, or it won't actually link pieishly. | 20:40 |
| teward | mmm good point | 20:40 |
| infinity | teward: -fPIE just sets some CPP defines. | 20:40 |
| teward | infinity: OK, i'll use yours, if you don't mind. | 20:40 |
| infinity | teward: Be my guest. | 20:40 |
| teward | want credit? | 20:40 |
| teward | this is ultimately going up to Debian too | 20:40 |
| infinity | Don't care. My name's all over the place. | 20:40 |
| teward | cool | 20:40 |
| teward | infinity: could we do what you did with line 28 in that diff on line 23 instead? | 20:42 |
| infinity | teward: If you wanted to make it entirely upstreamable (or moreso), there's some flag-mangling in the perl setup bits, they already sed out some CFLAGS, wouldn't be unreasonable to sed out -fPIE and -pie as well from CFLAGS and LDFLAGS. | 20:42 |
| infinity | teward: No, doing it on line 23 entirely defeats the purpose. | 20:43 |
| infinity | teward: The build (except the perl modules) *must* have -pie in LDFLAGS. | 20:44 |
| teward | infinity: ok | 20:44 |
| infinity | teward: You might want to test that it actually works built this way, mind you. :P | 20:47 |
| infinity | It load enough to tell me I don't have a config file at least. | 20:48 |
| teward | infinity: it's the perl module, I have no use case to do a thorough test | 20:48 |
| teward | the only reason it's included is because 'highly demanded' | 20:49 |
| teward | i'll run standard testing though, with default site setups, etc. | 20:50 |
| teward | but that's a given test | 20:50 |
| teward | ... i need a vivid vm :/ | 20:50 |
| === _salem is now known as salem_ | ||
| slangasek | infinity, chrisccoulson: I just got the firefox landing page in Turkish now | 21:20 |
| sarnold | not arabic? | 21:21 |
| slangasek | infinity, chrisccoulson: that's not a setting in my browser; firefox doesn't appear to have been upgraded here since March 6; it previously was working just fine in English | 21:21 |
| slangasek | sarnold: nope | 21:21 |
| slangasek | just hit refresh and now it's in English again | 21:22 |
| bkerensa | slangasek: what version of FF? | 21:22 |
| slangasek | bkerensa: the current version in the archive | 21:23 |
| chrisccoulson | I thought we'd established that this was a bug with the startpage? | 21:23 |
| slangasek | chrisccoulson: was that established? It certainly seemed that way to me but I got the impression not everyone was convinced. If it is a bug in the start page, where should I report that? | 21:24 |
| chrisccoulson | slangasek, https://bugs.launchpad.net/ubuntu-start-page/ | 21:24 |
| slangasek | chrisccoulson: cheers | 21:25 |
| slangasek | looks like it's reported already, bug #1427844 | 21:25 |
| ubottu | bug 1427844 in Ubuntu Start Page "Ubuntu search page comes up in wrong language from time to time" [High,Triaged] https://launchpad.net/bugs/1427844 | 21:25 |
| bkerensa | chrisccoulson: Does Ubuntu's Firefox have a prebundled addon? | 21:26 |
| bkerensa | chrisccoulson: for the bookmarks and unity stuff? | 21:26 |
| PartNAS | rww: you in here? | 21:28 |
| chrisccoulson | bkerensa, yes | 21:28 |
| bkerensa | chrisccoulson: you know about the upcoming requirement for addon signing I assume? :) | 21:29 |
| chrisccoulson | bkerensa, yes | 21:29 |
| bkerensa | chrisccoulson: I'm sure we will have a flag for distros though | 21:29 |
| bkerensa | distros / esr etc | 21:29 |
| chrisccoulson | fingers crossed! | 21:31 |
| bdmurray | tedg: didn't you right write some binary or library instead of calling /usr/share/apport/recoverable_problem? | 21:35 |
| flexiondotorg | bdmurray, Regarding https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1434579 | 22:11 |
| ubottu | Launchpad bug 1434579 in software-properties (Ubuntu) "Unable to install VirtualBox Guest Service in 15.04" [High,Incomplete] | 22:11 |
| flexiondotorg | bdmurray, Looks like multiverse was removed from the repo list when the Ubuntu MATE meta packages were imported and uploaded. | 22:12 |
| flexiondotorg | bdmurray, I did have multiverse enabled by default. | 22:12 |
| flexiondotorg | bdmurray, Are you able to do a little sponsoring and update the ubuntu-mate-meta package to add multiverse please? | 22:13 |
| infinity | flexiondotorg: How would multiverse relate to your metapackages? | 22:30 |
| infinity | flexiondotorg: Or, rather, if your meta is mangling sources.list, you've done something a bit scary. | 22:30 |
| flexiondotorg | infinity, I've not done anything scary :) Let me just check... | 22:31 |
| flexiondotorg | infinity, http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/vivid/ubuntu-mate-meta/vivid/view/head:/update.cfg#L14 | 22:31 |
| flexiondotorg | flexiondotorg, When I was hakc my unofficial version of Ubuntu MATE the line referenced above had 'multiverse' on it. | 22:32 |
| flexiondotorg | infinity, I was wondering if adding 'multiverse' back in there would enable the multiverse repos? | 22:33 |
| infinity | flexiondotorg: That won't relate to what's available in sources.list. | 22:33 |
| flexiondotorg | infinity, OK. | 22:33 |
| infinity | flexiondotorg: All that does is define which components your seeds should be looking for packages in. | 22:33 |
| flexiondotorg | infinity, Thanks. Understood. | 22:34 |
| flexiondotorg | infinity, bdmurray Therefore, until recently virtualbox-guest-x11 could be install via software-properties without manually enabling multiverse. That is no longer the case. | 22:34 |
| infinity | flexiondotorg: Hrm. So, I have multiverse enabled in a default install here... | 22:39 |
| flexiondotorg | infinity, So, I've just checked using a daily in a new VM. I have multiverse enabled too. | 22:39 |
| flexiondotorg | By default. | 22:39 |
| infinity | And I assume you can select the fancy non-free driver? | 22:40 |
| flexiondotorg | infinity, I'll double check in this new VM. One sec. | 22:41 |
| flexiondotorg | infinity, No. Still unable to install virtualbox-guest-dkma via the "Additional Hardware" tool. | 22:43 |
| flexiondotorg | infinity, See https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1434579 and the screenshot I've attached there. | 22:44 |
| ubottu | Launchpad bug 1434579 in software-properties (Ubuntu) "Unable to install VirtualBox Guest Service in 15.04" [High,Confirmed] | 22:44 |
| infinity | flexiondotorg: Curious. | 22:45 |
| infinity | flexiondotorg: Grabbing a daily to see this for myself. | 22:46 |
| flexiondotorg | infinity, Thanks. | 22:46 |
| flexiondotorg | infinity, I think this started happening around the time Xorg 1.17 landed. | 22:48 |
| infinity | flexiondotorg: Yeahp, it could be that the driver doesn't support the new xserver. | 22:48 |
| flexiondotorg | infinity, BTW, Xorg is completely busted for PowerPC :( | 22:49 |
| flexiondotorg | infinity, Working with upstream... | 22:49 |
| lathiat | on a totally unrelated note, glibc source (nss) is something special. | 22:49 |
| lathiat | so much legacy | 22:50 |
| flexiondotorg | infinity, I cat apt install virtualbox-guest-x11 and it works just fine. | 22:53 |
| infinity | flexiondotorg: Fun. Okay, can totally reproduce, not sure where the bug lies just yet. | 23:42 |
| flexiondotorg | infinity, Thanks for looking. | 23:43 |
| flexiondotorg | Time for sleeping... | 23:43 |
| infinity | flexiondotorg: It was an excuse to learn something new. I've never looked at this bit before. | 23:43 |
| flexiondotorg | :) | 23:43 |
| flexiondotorg | Z Z Z z z z zzzz... | 23:43 |
| infinity | if page == self.vbox_drivers: | 23:46 |
| infinity | self.button_revert.set_visible(False) | 23:46 |
| * infinity blinks. | 23:46 | |
| infinity | Oh, totally not virtualbox, just a badly named variable. | 23:47 |
| === gusnan is now known as Guest22972 | ||
| infinity | flexiondotorg: Oh, that's why. The dkms driver was pulled into the kernel, things need to change a bit to accomodate this new world order. | 23:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!