[00:56] <Son_Goku> nacc_: yes, there’s no ZTS in debian/ubuntu
[00:57] <Son_Goku> as far as I can tell
[00:57] <Son_Goku> I haven’t been testing with php-zts
[01:06] <nacc_> Son_Goku: ok, just checking
[01:08] <nacc_> slangasek: i think i figured out the php-imagick bug, but i don't know how to fix it...it's either a bug in libgomp or in imagemagick when compiled with openmp support. I built a version w/o it and no segfaults... NOte that just setting the environment variable or the policy.xml value isn't sufficient, it seems like imagemagick still uses openmp even then.
[01:09] <nacc_> kirkland: fyi --^
[01:26] <nacc_> slangasek: maybe it's not that dire, actually -- i wonder how the tests do w/o imagemagick fully installed (note this means there is still this relatively (?) serious bug in imagemagick, but it is independent of php-imagick, at least). Testing that now
[03:45] <Pharaoh_Atem> nacc_: so this happened to me when I ran the Twig test with process isolation and jit switched on: http://fpaste.org/332583/76723145/
[03:48] <Pharaoh_Atem> the problem repeats itself when I turn pcre.jit off, so I assume it doesn't have anything to do with pcre jit
[06:47] <cpaelzer> good morning
[07:36] <pitti> Good morning
[07:36] <pitti> ogra_: yay!
[07:36] <pitti> ogra_: I saw a component-mismatches email fly by last night about fakechroot wanting to go to main, btw
[07:54] <dholbach> good morning
[08:38] <ricotz> xnox, cjwatson, hi, regarding https://blueprints.launchpad.net/ubuntu/+spec/core-1403-hidpi-boottime , you might want to have a look at https://launchpad.net/~ricotz/+archive/ubuntu/staging/+sourcepub/6167873/+listing-archive-extra
[08:49] <phatina> cjwatson: Hi, can you have a look at this package, please? https://phatina.fedorapeople.org/deb/volume-key/ If you recall from yesterday, I was wondering, how to properly split 1 source package into several *.deb packages...
[08:49] <phatina> cjwatson: what I get now is: 2 *.deb packages, but there is only /usr/share/doc/* in both of them
[08:58] <phatina> all: anyone, who can guide how to properly split one tarball into several deb packages, please?
[10:51] <marlinc> Is there something like dh_make but for non source code package? In this case its simply a package containing a set of shell scripts
[11:06] <xnox> ricotz, given that 2x highdpi plymouth theme has regressed, i'm interested in proper highdpi plymouth.
[11:13] <flexiondotorg> Is PowerPC supposed to be able to submit bugs via apport?
[11:13] <flexiondotorg> https://bugs.launchpad.net/ubuntu-mate/+bug/1547568
[11:18] <pitti> flexiondotorg: in principle yes, but a screenshot of the error would be helpful
[11:18] <pitti> this is a rather vague description
[11:18] <ricotz> xnox, would be great if this could still make it in, afaics this upstream solution works here (this snapshot ignores the needed soname bump due api changes, the symbols used by mountall are untouched), rstrode got pinged in that regard too
[11:31] <Laney> pitti: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1549403 FFe might be up your street to review
[11:32] <pitti> Laney: queueing
[11:32] <Laney> r0x0r!
[11:41] <pitti> Laney: well, I'd call myself biased as I've lobbied for fixing this for ages; but I'll try to stay objective wrt. risk assessment :)
[11:41] <Laney> :)
[11:45] <phatina> all: I have a problem with splitting tarball into several deb packages: in control file, I have 3 packages stated, corresponding *.dirs *.install and the packages contain only /usr/share/doc/* not any binary, library, headers...
[11:45] <phatina> all: is there anyone, who is willing to have a look at this?
[11:45] <pitti> Laney: followed up
[11:46] <Laney> pitti: thanks
[11:46]  * Laney is occasionally checking the release bugmail
[11:46] <Laney> pitti: and hi, don't think I said that today
[11:50] <pitti> Laney: inded, good day!
[11:51] <pitti> Laney: KDE mass upload> autopkgtest queues just recovered from the perl hit and are still aching under the load of Qt from Ubuntu and silos simultaneously
[11:52] <pitti> I accidentally killed some silo test request this morning; I'll put them back, but that'll add another 100 or so
[11:53] <Laney> fun
[11:53] <pitti> Laney: FYI, I split the queus between ubuntu, ppa, and upstream now; so none can starve the other two
[11:53] <Laney> indeed K* are already being tested
[11:53] <pitti> see http://autopkgtest.ubuntu.com/running.shtml
[11:53] <pitti> Laney: yes, for Qt
[11:54] <Laney> right
[11:55] <LocutusOfBorg> ok I might be stupid, but what is now preventing fonts-android from migrating? at least, ubuntustudio-desktop* shouln't be listed as a problem anymore
[11:55] <LocutusOfBorg> Trying easy from autohinter: fonts-android/1:6.0.1r16-1 renpy/6.99.8+dfsg-2 request-tracker4/4.2.12-5 ubuntukylin-theme/1.5.1
[11:55] <LocutusOfBorg>     * amd64: ubuntustudio-default-settings, ubuntustudio-desktop, ubuntustudio-desktop-core
[11:56] <LocutusOfBorg> I can see the default-settings as a problem
[11:56] <zequence> LocutusOfBorg: Yes, we haven't changed that yet
[11:56] <zequence> Let me do that right now.
[11:56] <LocutusOfBorg> yes, thanks
[11:56] <LocutusOfBorg> but I still see the fixed package in the nasty list
[11:59] <Laney> Might be because it depends on the default-settings
[12:05] <zequence> Uploaded. Will check in later to see that it built. But, that package is going to be broken for us for a little while. I'm instructing our next project lead how to make changes to it, so he will finish up the rest.
[12:05] <zequence> I think that was the last dependency to fonts-droid anyhow
[12:11] <LocutusOfBorg> thanks Laney zequence
[12:11] <LocutusOfBorg> I hope to see it migrate
[12:18] <cjwatson> phatina: hmm, looks OK from a quick scan through the packaging, do you happen to have a build log?
[12:35] <LocutusOfBorg> where is doko when needded? :)
[12:35] <LocutusOfBorg> Package: libpurple-dev
[12:35] <LocutusOfBorg> Section: libdevel
[12:35] <LocutusOfBorg> Architecture: all
[12:35] <LocutusOfBorg> damn, multiarch broken
[12:35] <LocutusOfBorg> the pc file is shipped on lib/x86_64 on every arch
[12:35] <LocutusOfBorg> going to change all to any and reupload
[12:36] <Laney> DOKOOOOOOOOOOOOOOOOOOOooooooooooOOOOOOOOoooooOOOOOo
[12:36] <LocutusOfBorg> I lost 15 minutes trying to understand why pidgin-data was failing
[12:37] <LocutusOfBorg> and rebuilding on i386 pidgin was fine, because the arch:all was good on that arch :)
[12:48] <phatina> cjwatson: yes, I have: https://phatina.fedorapeople.org/deb/volume-key_0.3.9-1_amd64.build
[12:49] <phatina> cjwatson: I can't find dh_install in there
[12:49] <phatina> cjwatson: that may be the problem, right?
[12:53] <Mirv> pitti: for some reason the autopkgtest retry request does not finish loading, just hangs in there (after loggin in phase), despite several attempts
[13:02] <cjwatson> phatina: that's a pointer in the direction of the problem, but you shouldn't need to call dh_install explicitly; for some reason dh is deciding that there are no .install files so it doesn't need to call dh_install
[13:03] <cjwatson> phatina: can you double-check that those .install files really exist in the environment where the build is running?  it's not something like those files not having been added to a VCS?
[13:03] <phatina> cjwatson: hmm, those files need to be added to bzr?
[13:03] <cjwatson> phatina: it looks like you're using bzr builddeb so it would be worth checking that "bzr status" doesn't show those files as unknown
[13:04] <cjwatson> phatina: if you're using bzr builddeb then you need to add them to bzr, yes
[13:04] <phatina> cjwatson: yes, they aren't added yet
[13:04] <cjwatson> there we go
[13:04] <pitti> Mirv: ah, let me look; we got some SSL restriction settings yesterday, maybe they broke something
[13:04] <phatina> cjwatson: ok, I'll need to build the *.deb without bzr
[13:07] <phatina> cjwatson: thanks for the tips
[13:10] <cjwatson> np
[13:18] <LocutusOfBorg> zequence, fonts-android migrated, hurray
[13:19] <LocutusOfBorg> thanks!
[13:28] <LocutusOfBorg> boinc is not migrating because of: boinc-client-nvidia-cuda/amd64 unsatisfiable Depends: nvidia-modprobe
[13:29] <LocutusOfBorg> this is false
[13:29] <LocutusOfBorg> did something broke somewhere? I didn't change anything on that side
[13:39] <pitti> LocutusOfBorg: boinc is universe, nvidia-modprobe is multiverse
[13:39] <pitti> i. e. you apparently added that as a new dependency, but universe packages must not depend on multiverse
[13:39] <LocutusOfBorg> pitti, the problem is that the previous version migrated, with the same set of dependencies
[13:39] <LocutusOfBorg> well, lunch and investigation :)
[13:40] <pitti> LocutusOfBorg: yeah, we enabled component checking in britney recently
[13:40] <pitti> but it would have been a component-mismatch anyway before
[13:41] <pitti> nvidia-modprobe | 361.28-1         | unstable/contrib         | source, amd64, armhf, i386, ppc64el
[13:41] <pitti> so it could probably go to universe
[13:41] <pitti> or boinc needs to go to multiverse
[13:41] <pitti> not sure, but that smells RC to me in Debian too -- a main package depending on contrib
[13:42] <Mirv> pitti: I'll try again if you find some fixable issue
[13:42] <pitti> Mirv: happens for me too, I just don't know what's up yet
[13:42] <pitti> (looking at it)
[13:42] <Mirv> ok
[13:44] <pitti> I can't reproduce it in my juju-local instance
[14:06] <pitti> Mirv: ok, should work again, but please don't hit the buttons yet, I'm still cleaning up
[14:07] <LocutusOfBorg> thanks pitti
[14:12] <Mirv> ok :)
[14:15] <LocutusOfBorg> pitti, moving Depends to Recommends or Suggests can fix the issue?
[14:15] <pitti> LocutusOfBorg: suggests is fine, recommends not (as that gets installed by defaultl
[14:16] <pitti> LocutusOfBorg: or boinc needs to move to contrib in Debian/multiverse in Ubuntu
[14:16] <pitti> whic is reasonably doable, only boinc-app-seti depends on it
[14:16] <ginggs> LocutusOfBorg: you shouldn't need to suggest or recommend nvidia-modprobe
[14:18] <ginggs> LocutusOfBorg: in debian the nvidia driver depends on it, and in ubuntu the required drivers are supposed to be loaded at boot
[14:19] <pitti> robru: we need to remove all pending.json from landing-{050,012,036}, due to some hiccups; where to ask about that again, and where are the file paths to tell webops to delete?
[14:19] <LocutusOfBorg> the boinc-nvidia has been created to force installation of graphic drivers
[14:19] <LocutusOfBorg> so moving to suggests is not probably the right thing to do
[14:19] <LocutusOfBorg> demoting is maybe the best way
[14:38] <pitti> Mirv: ok, should be all working again, retry away
[14:38] <lamont> smb: cyphermox I suspect one of you has more info than me from mgilbert?  looks like he'll be adding back in the -export libs, working on it this weekend
[14:39] <lamont> not sure how that fits with our timeline
[14:39] <smb> lamont, I did not hear anything but I found out more background about the problem
[14:39] <smb> and why it works with network-mangler
[14:40] <lamont> cool.  it'll be sunday at the earliest (and more likely midweek next week) before I can dig into it myself, so hoping mgilbert finishes it up this weekend
[14:41]  * lamont is going to toss -5 up sometime today/tomorrow, with apparmor and some other simple stuff
[14:41] <lamont> tjaalton: ^^ did you want me to drop your autoconf thing from that? (it's in the queue already)
[14:42] <smb> lamont, ok ... meanwhile if you are interested, I am currently writing more detailed findings into bug 1551351
[14:42] <lamont> and already pushed to the main tree, so nm...
[14:42] <lamont> yeah, I'll read that when I get closer to it
[14:45] <tjaalton> lamont: it can wait
[14:46] <cyphermox> lamont: he didn't respond to me
[14:47] <lamont> cyphermox: ok.  he poked me late last night, pointed at the launchpad bug, and the 2015 email and said he'd be working on -export readd this weekend
[14:48] <lamont> cyphermox: so we have a clear path forward
[14:48] <cyphermox> jes
[14:49] <smb> cyphermox, as a tl;dr update, your case only works because networkmanager runs dhclient in debug/foreground mode
[14:49] <cyphermox> oik
[14:49] <lamont> smb: hahaha
[14:53] <Mirv> pitti: works, thank you
[14:55] <GunnarHj> pitti: Hi Martin, did you see my question in #ubuntu-desktop?
[14:56] <pitti> GunnarHj: I did; sorry, backlogged, fighting infrastructure fires
[14:57] <GunnarHj> pitti: Ok, my thing is not an emergency. Trying to be patient. :)
[15:14] <barry> pitti: is autopkgtest.ubuntu.com down?
[15:15] <teward> barry: shows up for me?
[15:15] <barry> teward: huh
[15:15] <mitya57> works for me too
[15:16] <barry> pitti: it could just be the retry button
[15:16] <barry> (from excuses)
[15:16] <barry> e.g. https://autopkgtest.ubuntu.com/request.cgi?release=xenial&arch=amd64&package=deja-dup&trigger=deja-dup%2F34.1-1ubuntu3
[15:19] <pitti> barry: argh, again
[15:19] <pitti> barry: I just had it working again
[15:20] <pitti> barry: so, it took me over an hour to gracefully shut down everything with a million tests waiting, and I lost a few already
[15:20] <pitti> barry: so let's wait until the Qt madness is over, and I'll look into it tomorrow
[15:23] <barry> pitti: ack
[15:24] <pitti> apparently somethign hangs when talking to the AMQP server
[15:35] <tsdgeos> do you guys also get a 500 on https://wiki.ubuntu.com/ ?
[15:36] <teward> tsdgeos: randomly, yes, but it returns as "up" for me right now
[15:45] <ginggs> mdeslaur: you asked about WINE some time ago, there hasn't been any activity from the 'wine team' since a PPA upload in December. What can I do to help move this along? Assuming the team is no more, is removing the Ubuntu packaging and transitioning to the Debian packaging an option?
[15:47] <mdeslaur> ginggs: the packaging is completely different, so someone would need to look through it all and add whatever is necessary to do the transition
[15:47] <mdeslaur> ginggs: I think the best thing is to use the packages in the ppa, perhaps by asking whoever uploaded them if it's good enough for xenial
[15:47] <mdeslaur> actually, probably too late for xenial, but x+1
[15:48] <ginggs> msdeslaur: i've been playing with a transitional package in my PPA, i mostly does the right thing, but gets confused by the fact that debian's wine package is :all and ubuntu have wine:i386 and wine:amd64.  Otherwise the packages all have different names
[15:49] <mdeslaur> the ubuntu package definitely has the advantage that multiple versions can co-exist
[15:49] <mdeslaur> which is probably desirable for wine
[15:49] <ginggs> mdeslaur: so does debian's
[15:49] <ginggs> mdeslaur: at least they have a wine and and wine-developement these days
[15:49] <mdeslaur> oh, I though they only had stable and development
[15:49] <mdeslaur> right, but ubuntu can have 1.6 and 1.8, etc.
[15:50] <mdeslaur> anyway, I have no opinion either way, I don't care much about wine
[15:50] <mdeslaur> I just wanted to try 1.8
[15:51] <mdeslaur> either continuing the approach in ubuntu/the ppa, or migrating to debian's packaging, there's work to be done either way
[15:53] <xnox> pitti, what is /dev/disk/by-dname ? first time i see that, can it be used somehow for the root= arg?
[15:53] <ginggs> mdeslaur: let me start by trying to contact the team and see if they are still interested in maintaining it
[15:53] <pitti> xnox: I don't know this at all -- perhaps a typo?
[15:54] <xnox> i see those links in the initramfs.
[15:54] <pitti> xnox: or maybe a typo of your's, and you mean by-name/?
[15:54] <xnox> oh, it looks like something funky maas-ish.
[15:54] <rbasak> cyphermox: bug 1547206 claims a regression in a multipath-tools SRU I think. Please could you take a look?
[15:54] <pitti> (but even then, by-name/ doesn't exist either for block devices)
[15:55] <pitti> xnox: ah, maybe they  set up their own udev rules then
[15:55] <cyphermox> rbasak: yeah, I've already been in contact with tore on that
[15:56] <rbasak> cyphermox: OK thanks. I'm just triaging and didn't see any response in the bug. Can I mark it Triaged?
[15:56] <cpaelzer> xnox: I know the by-name thing from s390 - when you create names in multipath.conf they will populate that
[15:57] <xnox> cpaelzer, that's udev.
[15:57] <xnox> by-dname looks like stuff that curtin creates
[15:57] <cyphermox> rbasak: yeah
[16:01] <pabs3> is there a channel for the wiki.ubuntu.com sysadmins? I found a page that crashes with certain user-agent headers but not with no user-agent header and not with other headers
[16:01] <robru> pitti, talk to #webops, it'll be /tmp/britney_data/landing-XX-{xenial,vivid}/autopkgtest/pending.json
[16:01] <pabs3> https://wiki.ubuntu.com/MoroccanTeam/En
[16:02] <cpaelzer> xnox: ah you really menat "d"name - sorry, I didn't scroll up enough, yeah seems to be curtin related to bug 1477756
[16:02] <robru> pitti: list of directories is always here: https://requests.ci-train.ubuntu.com/static/britney/report.txt
[16:04] <pitti> robru: ah, thanks
[16:04] <robru> yw
[16:11] <mterry> mvo_, for uboot-go, you said you changed source name too?  Is it stuck in NEW?  I don't see the source pkg in LP
[16:12] <mvo_> mterry: let me check what is going on, might be an upload issue
[16:13] <mterry> mvo_, you also said you fixed the issues with goconfigparser?  I don't see a new upload there eithe
[16:13] <mvo_> mterry: yeah, incorrect upload, sorry for that, will fix in a sec, same issue on the other one
[16:13] <mvo_> too
[16:15] <robru> pitti: I guess we should think about some sort of admin panel for bileto that allows to delete arbitrary files.
[16:17] <mvo_> mterry: silly me, -sa was missing, uploaded them again now
[16:17] <mterry> mvo_, ah.  I do that all the time  :)
[16:17] <mvo_> mterry: :) thanks again
[16:20] <Odd_Bloke> Hmm, I'm seeing some strange sysctl behaviour on wily.  I have configuration in a file in /etc/sysctl.d (which was there before boot) that only seems to take effect if I restart the systemd-sysctl service.
[16:23] <cjwatson> pabs3: #canonical-sysadmin
[16:24] <pabs3> thanks
[16:35] <tjaalton> how does one get rid of an obsolete autopkgtest?
[16:36] <tjaalton> fglrx is blocking xorg-server, while it shouldn't (it'll get removed from the archive instead)
[16:43] <pitti> tjaalton: you mean fglrx-installer will be removed?
[16:43] <tjaalton> yes
[16:43] <pitti> and -updates?
[16:43] <tjaalton> same
[16:44] <pitti>  fglrx-updates : Depends: xorg-video-abi-11 but it is not installable or
[16:44] <pitti> ah
[16:44] <pitti> tjaalton: so can we remove it now, so that it stops being an rdependency?
[16:45] <pitti> tjaalton: is the reason "the free driver is good enough now" by any chance?
[16:45] <tjaalton> pitti: yes. the reason is "there won't be updates anymore, and free driver is good enough for most" :)
[16:45] <pitti> tjaalton: excellent
[16:45] <pitti> tjaalton: so, say the word, and I'll kill them
[16:46] <tjaalton> gogogo :)
[16:46] <pitti> with fire!
[16:46] <tjaalton> from xenial
[16:46] <tjaalton> trusty will still have it of course :)
[16:46] <tjaalton> tseliot: ^
[16:47] <tseliot> pitti: yes, we can remove it. I sent a pull request to the kernel team to add some improvements to open drivers for the same reason
[16:47] <tseliot> (in xenial)
[16:47] <pitti> *ZAP*
[16:47]  * pitti watches it explode
[16:48] <tjaalton> pitti: so in this case, the autopkgtest was in..? not in the package itself at least
[16:48] <pitti> tjaalton: auto-generated one by autodep8 (DKMS testing)
[16:48] <tjaalton> I have some pet projects I need to add tests for..
[16:48] <tjaalton> ah ok
[16:49] <tjaalton> yeah, so removing the pkg was needed
[16:49] <tseliot> :)
[16:49] <pitti> tjaalton: that's what generates a debian/tests/control for sets of similar packages, like lib*-perl, ruby modules, or DKMS packagse
[16:49] <pitti> so that they don't need to be copied around a bazillion times
[16:49] <tjaalton> right, ok
[16:50] <pitti> tjaalton: ofono isn't your fault, I'll hint that away from xorg
[16:50] <tjaalton> yeah I noticed :)
[16:50] <tjaalton> was about to kick it
[16:51] <pitti> yeah, I give it another chance with a retry first
[16:51] <tjaalton> pitti: thanks!
[16:52] <pitti> tjaalton: this is a good day :)
[16:52] <pitti> tjaalton: we can kill the nvidia drivers tomorrow, right?
[16:54] <tseliot> :D
[17:00] <pitti> speaking of binary junk, what's the current word on broadcom wifi cards? I haven't followed that for quite a while
[17:00] <pitti> there've been like 4 drivers in the past 10 years
[17:01] <pitti> bcm43xx with fwcutter, wl, and the two free ones in staging
[17:04] <tseliot> I'm not sure
[17:13] <tjaalton> pitti: yep, a good day indeed :)
[17:18] <rharper> how would I make a request to have a PPA be allowed to build packages on s390x ?
[17:19] <cjwatson> rharper: https://answers.launchpad.net/launchpad, and I'm afraid at the moment this is only allowed for PPAs that can be devirtualised (i.e. must only be uploadable to by Canonical employees)
[17:19] <cjwatson> due to lack of sandboxing
[17:20] <rharper> cjwatson: ok, thanks for the information;
[17:39] <xnox> rharper, is this for juju? you should have a canonical-only devirt ppa imho.
[17:39] <xnox> cjwatson, ^
[17:39] <nacc> xnox: i believe it's for docker
[17:40] <xnox> nacc, ah. right.
[17:40] <xnox> nacc, rharper: maas -> openstack -> scalingstack -> lp is the dependency chain to get that enabled.
[17:41] <Son_Goku> nacc: so any luck with pcre+php7?
[17:42] <nacc> Son_Goku: twig now runs/passes the test -- I put in a manual phpunit isolation on the failing test
[17:42] <nacc> Son_Goku: i've been getting some help from upstream
[17:42] <nacc> Son_Goku: I do think something is off with the pcre jit code, but not sure what yet
[17:42] <Son_Goku> I spent a few hours tracing it through gdb, but I got nowhere
[17:45] <Son_Goku> I’m setting up a Fedora VM to fiddle with it a bit more, since Remi said it doesn’t fail there, and I want to see it pass with pcre.jit=1 myself
[17:45] <nacc> Son_Goku: yeah, i have it to the point where I'm getting sort of weird results (https://bugs.exim.org/show_bug.cgi?id=1803)
[17:45] <nacc> Son_Goku: if you could do that, that'd be great
[17:46] <Son_Goku> nacc: I couldn’t reproduce your error states in my CentOS 7 PHP7 environment
[17:46] <Son_Goku> I got *different* error data
[17:47] <nacc> heh
[17:47] <nacc> Son_Goku: but the same error location?
[17:47] <Son_Goku> yes
[17:47] <Son_Goku> it’s the most bizarre thing ever
[17:49] <Son_Goku> nacc: at this point, I’m wondering how people expect PHP to ever be consistent about anything?!
[17:52] <nacc> Son_Goku: what values do you get?
[18:38] <nacc> Son_Goku: sorry, didn't see if you responded -- what values do you see in centos?
[18:38] <Son_Goku> nacc: ah one moment
[18:38] <nacc> Son_Goku: also, keep in mind, compiler differences, etc., might lead to slight differences
[18:38] <Son_Goku> yeah, I think that’s the primary effect here
[18:41] <Son_Goku> nacc: http://fpaste.org/333171/57030506/
[18:44] <nacc> Son_Goku: ah, aggressive optimization :)
[18:44] <nacc> Son_Goku: hrm, yeah, so it fails *earlier* with centos7, i think?
[18:44] <nacc> at pcre_exec time?
[18:49] <Son_Goku> nacc: yes
[18:50] <Son_Goku> it looks like it
[18:51] <nacc> which is perhaps the same issue -- just not noticed at the same time. I think the JIT code is failing to move the offsets on every call
[18:51] <nacc> but i need to reproduce that
[18:51] <Son_Goku> this is with php 7.0.4 and pcre 8.32-15.el7 (so 8.32 with a bunch of backported issues)
[18:51] <Son_Goku> err, backported fixes
[18:51] <Son_Goku> nacc: yeah, I suspect that’s the case
[18:51] <nacc> Son_Goku: any luck setting up a fc vm?
[18:51] <Son_Goku> nacc: working on it now
[18:52] <nacc> Son_Goku: cool, keep me posted please
[18:52] <Son_Goku> most def
[18:52] <Son_Goku> just finished the install of fc23
[18:52] <Son_Goku> so rebooting it into new environment to install php7
[18:53] <oSoMoN> Mirv, FYI: https://bugs.launchpad.net/ubuntu/+source/qtsystems-opensource-src/+bug/1552860
[18:55] <Son_Goku> thank god for oVirt, or I’d never get anything done
[18:55] <nacc> Son_Goku: thanks!
[18:55] <Son_Goku> my pleasure
[19:35] <Son_Goku> nacc: well… it happens in Fedora
[19:35] <Son_Goku> http://fpaste.org/333217/45703374/
[19:36] <Son_Goku> annoyingly enough, Remi didn’t upload the debuginfo package for php70, so I need to poke him with a stick for those
[19:36] <Son_Goku> but it did fail differently here, too
[19:36] <Son_Goku> well, differently ish
[19:38] <nacc> Son_Goku: that's good!
[19:38] <nacc> Son_Goku: in that i did backport those patches
[19:38] <nacc> and it didn't help me
[19:38] <nacc> and i was worried something else was up
[19:38] <nacc> but having it not fixed anywhere is good
[19:39] <nacc> looking at hte trace, ti'll be the same symptoms, last_match will have moved past where the offsets imply and we'll get a negative length calculation, if i had to guess
[19:39] <Son_Goku> yeah
[19:39] <Son_Goku> the patch backport was still good to do
[19:39] <nacc> yep
[19:39] <Son_Goku> because it minimized the number of conditions
[19:40] <nacc> ruled some stuff out
[19:40] <Son_Goku> and besides, pcre is crap, and needs to be fixed
[19:40] <nacc> :)
[19:40] <nacc> Son_Goku: since you are the ones that's reproduced it, can you update the pcre bug?
[19:40] <Son_Goku> now I just want to know wtf Remi is doing that makes it work on his computer
[19:40] <Son_Goku> nacc: sure
[19:40] <Son_Goku> on exim?
[19:40] <nacc> Son_Goku: yeah that'd be good to know for sure
[19:40] <nacc> yep
[19:40] <Son_Goku> or on php.net?
[19:40] <nacc> https://bugs.exim.org/show_bug.cgi?id=1803
[19:41] <nacc> i am thinking more and more, that it's a bug in pcre ... just need to figure out if i cna write a testcase for it. I told you the other day i wrote the twig testcase as it's own (what split_utf8.test does) and it doesn't fail ... so it's a stateful issue. Which is why process-isolation helps
[19:42] <nacc> but i'm not sure what state pcre could be holding that would go corrupt
[19:42] <nacc> as it's supposed to be using the offsets passed in to decide where to look in the string, etc
[19:47] <nacc> hrm, after upgrading to xenial, my previousl working adt-run, which uses my already built .deb says:
[19:47] <nacc> blame: arg:/home/nacc/ubuntu/build/php-imagick_3.4.0~rc6-1ubuntu3_amd64.deb deb:php-imagick php-imagick_3.4.0~rc6-1ubuntu3.dsc
[19:47] <nacc> badpkg: got 9 lines of results from extract where 4 expected
[19:47] <nacc> adt-run [11:44:54]: ERROR: erroneous package: got 9 lines of results from extract where 4 expected
[19:47] <chiluk> xnox do you have a chance to look at a preseed and debug syslog with me?
[19:47] <Son_Goku> nacc: done: https://bugs.exim.org/show_bug.cgi?id=1803
[19:48] <nacc> Son_Goku: thanks!
[19:48] <Son_Goku> I’ve attached the log output as attachments, to make things simpler
[19:48] <nacc> Son_Goku: makes sense
[19:49] <Son_Goku> the best part is that since these are three different distros, it’s not likely to be considered distro-specific
[19:49] <nacc> right, it seems like it should be something that is fixable by upstream now :)
[19:49] <nacc> but we'll see
[19:50] <mahmoh> hi, I'm seeing a hang with upstart, I tried --verbose on the kernel command line with 14.04 to get additional info but that's not working, any ideas?
[20:07] <nacc> pitti: hrm, after upgrading to xenial, my previousl working adt-run, which uses my already built .deb says:
[20:07] <nacc> pitti: blame: arg:/home/nacc/ubuntu/build/php-imagick_3.4.0~rc6-1ubuntu3_amd64.deb deb:php-imagick php-imagick_3.4.0~rc6-1ubuntu3.dsc
[20:07] <nacc> pitti: adt-run [11:44:54]: ERROR: erroneous package: got 9 lines of results from extract where 4 expected
[20:08] <nacc> pitti: and the results in particular are: http://pastebin.ubuntu.com/15276066/
[20:16] <nacc> pitti: i think it's because fo the dpkg-source output, but not positive?
[20:35] <nacc> pitti: adding >/dev/null 2>&1 to the invocation of dpkg-source fixed it, but i think that's clearly not expected. Did perhaps dpkg-source change it's output in xenial? actually that doesn't make sesne, looking at the exec line, it seems like fd3 gets redirected to stdout and then stdout gets redirected to stderr; so somehow dpkg-source's output is showing up on fd3? will debug it some more
[20:49] <Saviq> xnox, hey, is it normal that trying to install libboost-dev in a cross-armhf chroots tries to remove gcc and all?
[20:51] <Saviq> or actually, doko, you seem to have dabbled in "g++ dependencies" in there https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/wily/boost-defaults/wily/revision/15
[21:35] <superm1> pitti:  new hardware is supported by brcmfmac, older hardware is supported by wl
[23:49] <nacc> slangasek: woo! i think i found another imagemagick backport that is why php-imagick segfaults its tests ... build and testing now
[23:59] <Pharaoh_Atem> hmm