[04:02] <theweirdn8> so i have a general question about devving for ubuntu.  If im on Arch Linux Distro, if i compile something there does it work on ubuntu?? Or do  I need ubuntu for ubuntu dev?
[04:03] <sarnold> It's Complicated
[04:03] <sarnold> by far the easiest approach is to have an ubuntu system, whether via kvm or lxc or hardware or whatever
[04:03] <theweirdn8> sarnold: can you elaborate
[04:04] <theweirdn8> So, assuming im just using C++ and SDL 2.0.x it still wont work easily on Ubuntu?
[04:04] <sarnold> but there's usually pretty good binary compatibility even between distributions, so long as you stick to the big things, like either using gcc 5.x on both or gcc 4.x on both..
[04:05] <theweirdn8> Ok, thats interesting to hear
[04:05] <sarnold> c++ is infact one of the areas where gcc 5.x broke ABI compatibility. your code could probably be compiled on arch and then run on whichever versions of ubuntu shared that same version of gcc...
[04:05] <theweirdn8> i hope i can get my IDE working on at least Ubuntu and Debian and Raspberry pis
[04:05] <sarnold> you probably don't need the whole IDE though; just enough build environment needs to exist on the other systems..
[04:05] <theweirdn8> Working on this
[04:05] <theweirdn8> http://create.pawbyte.com/
[04:06] <theweirdn8> im making na IDE
[04:06] <sarnold> and in fact you can use ubuntu servers to do the actual building, which sidesteps most of the difficulties: https://help.launchpad.net/Packaging/PPA
[04:08] <sarnold> fwiw, there's also https://build.opensuse.org/ which has been on my "to investigate" list for a few years.. they claim to be able to build debs and rpms from single sources, which would likely save you loads of time
[04:08] <sarnold> by and large whatever -source- you work on would work fine, but binary compatibility is where things get awkward.
[04:10] <theweirdn8> oh mkay
[04:10] <theweirdn8> i will look at it later
[04:37] <nacc> Pharaoh_Atem: i can try to help you out in the AM
[04:37] <nacc> AM
[04:48] <Pharaoh_Atem> nacc: cool
[04:48] <Pharaoh_Atem> that'd be great
[04:48] <Pharaoh_Atem> sarnold: it works
[04:48] <Pharaoh_Atem> I've been using the openSUSE Build Service for years
[04:49] <Pharaoh_Atem> it's fully binary compatible because it builds Ubuntu VMs to build things on the fly
[04:49] <Pharaoh_Atem> the only problem (for Ubuntu users) is that the build of osc and zypper is badly broken
[04:50] <Pharaoh_Atem> as in, it segfaults on some operations due to a bad zypper/libsolv build
[05:30] <slangasek> cjwatson: did you happen to see that devscripts is dep-wait?
[06:41] <mvo> rbasak: hi, just fyi (you asked/mentioned this yesterday) - I uploaded a new command-not-found with the xenail data now
[07:08] <pitti> Good morning!
[07:22] <pitti> hallyn: the updated systemd is in xenial now
[07:57] <mvo> mwhudson: hi, I wonder if you can help me? I try to find out what the plan for gccgo and golang 1.5 library support is. I looked at gcc trunk and AFAICS the 1.5 runtime (libgo) go merged ~3 month ago. snappy is using (some) 1.5 library bits and our 5.3 fails right now. now it seems that the gcc5_3 branch does not have 1.5 support and the next gcc is gcc6 - is that correct? no 1.5 support for gcc5.3?
[08:32] <ondrej> nacc: re swig - ignoring the problem in hope somebody else will solve it?
[09:13] <mwhudson> mvo: yeah, it's a bit of a mess between go and gcc release schedules
[09:13] <mwhudson> mvo: however!
[09:13] <mwhudson> mvo: we shouldn't have to care about gccgo for x
[09:13] <mwhudson> oh, except for powerpc (32 bit)
[09:14] <mwhudson> i recommend not caring about powerpc :)
[09:14] <mwhudson> 1.6 everywhere, with ibm's port to s390x as a distro patch
[09:15] <cjwatson> slangasek: I hadn't, thanks.  I guess that's a MIR job, will see about that later today
[09:16] <mwhudson> mvo: there's a 1.6beta2 package in https://launchpad.net/~xnox/+archive/ubuntu/nonvirt/+packages if you want to try that
[09:16]  * mwhudson goes to bed
[09:34] <rbasak> mvo: thanks!
[09:35] <mvo> mwhudson: thanks a bunch!
[09:35] <mvo> rbasak: yw
[10:35] <ginggs> Laney: I saw you sync'd glib2.0, thanks!
[10:38] <Laney> ginggs: np!
[11:46] <pitti> hallyn: I followed up on #1533839 with an initial diagnosis
[13:00] <doko> mitya57, dh_sphinxdoc: error: unknown JavaScript code: debian/python-pygraphviz-doc/usr/share/doc/python-pygraphviz-doc/html/_static/jquery.js
[13:01] <doko> any idea why I see this in xenial?
[15:28] <ginggs> pitti: in case you are still around, glib2.0 seems to be running its tests against pcre3 8.35, can it be convinced to run them against pcre3 8.38 in -proposed instead?
[15:32] <pitti> ginggs: it can, but shouldn't it Depends: on the -proposed libpcre3 then if it needs that?
[15:36] <ginggs> pitti: let me check on that. iirc, the patch for glib2.0 to work with new pcre3 should be conditional
[15:36] <Laney> It checks the build version
[15:36] <Laney> I suppose if available we could make it look at the runtime version instead
[15:37] <nacc> ondrej: :) fair enough -- i've pinged upstream to see if i can help
[15:37] <nacc> ondrej: but i meant for packages that depend on the swig bindings ... will they just be broken in debian if you try to install php7.0?
[15:37] <nacc> mvo_: thanks for the cnf data! i'll see what it says today
[15:40] <pitti> ginggs, Laney: I suppose we are talking about both http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#pcre3 and http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#glib2.0, right?
[15:40] <Laney> indeed
[15:40] <Laney> It's more correct to move the check in question to a runtime one
[15:41] <pitti> $ run-autopkgtest -s xenial --trigger=glib2.0/2.47.4-1 --trigger=pcre3/2:8.38-1ubuntu1 glib2.0
[15:41] <pitti> started
[15:41] <pitti> (this will install the -proposed versions of both)
[15:46] <seb128> @pilot in
[15:54] <mvo_> nacc: sure, your welcome. what in particular was missing there?
[16:15] <nacc> mvo_: what i noticed was that php-config wasn't showing up as a known command
[16:16] <nacc> mvo_: php5-config still was but php-config is provided by a package in universe (php7.0-dev, iirc)
[16:17] <nacc> mvo_: hrm, after update/upgrade, still don't see it ... is there some latency before it will be in the repos?
[16:17] <nacc> mvo_: or might this be something that needs manual intervention?
[16:18] <mvo_> nacc: let me check
[16:19] <nacc> mvo_: thanks!
[16:19] <mvo_> nacc: oh, is php-config using the update-alternatives system maybe? thats notoriously tricky for the c-n-f parser to parse
[16:20] <mvo_> nacc: as those are shell constructs etc
[16:23] <nacc> mvo_: yes, it is
[16:27] <nacc> mvo_: so in that case, is it better to provide a manual update? I can try and spin something up ... not sure what the best way is
[16:30] <mvo_> nacc: I guess the parser is just confused, it gets it right for emacs and vi but its fragile by nature as it tries to understand what the shell code is doing without executing it
[16:30] <mvo_> nacc: I guess I need to look at php7.0-dev to see what it is doing?
[16:31] <nacc> mvo_: probably :) I'd have to look at the emacs code to understand how cnf parses the file. For src:php7.0, you'll want to look at debian/php-dev.postinst, I think
[16:32] <mvo_> nacc: thanks, looking now
[16:34] <nacc> mvo_: also applies to phpize, I think, fyi. This is going to be one of the painful parts of the PHP7.0 transition. They've changed the names of all the binaries away from php<version>-... whatever to php-... whatever. So that's good, but means there might be a lot of churn in the meanwhile. I know those two commands are issues, I'll keep looking for others as I go
[16:36] <mvo_> nacc: thanks! I think its the quotes that confuse it, I wonder if ${i} would be easier to grok for the c-n-f extractor
[16:37] <nacc> mvo_: oh good point ... I don't know why they did it that way; these loops are pretty generic to all the php scripts, so could just be c&p
[16:37] <nacc> mvo_: actuall, i lied, the other scripts use ${var}
[16:38] <nacc> mvo_: i can push something to debian if that will help?
[16:39] <mvo_> nacc: thanks, it will definitely not do any harm :)
[16:39] <nacc> mvo_: ok -- and if we do that, will it get autosyncd and regenerated with cnf in the future? or should i ping you once/if debian updates?
[16:39] <mvo_> nacc: I will need to a bit more time to build a test case to see if it really fixes it, but emacs is using this and there it works
[16:40] <nacc> mvo_: sure, np
[16:40] <mvo_> nacc: once its in ubuntu feel free to ping me, then I will check, the extractor runs daily
[16:40] <nacc> mvo_: ah got it, thanks!
[16:40] <mvo_> nacc: cool, thanks a lot!
[17:39] <hallyn> pitti: thx
[18:00] <seb128> @pilot out
[18:56] <nacc> hrm, so let's say there's a package that generates a file ... shouldn't apt-file indicate that? or is there something that generates apt-file's contents? In particular, I was looking for the php.h generated by php7.0-dev
[18:58] <nacc> ondrej: is there a reason php7.0-dev generates /usr/include/php/20151012 (the phpapi) rather than, say /usr/include/php/7.0/ ?
[19:08] <Pharaoh_Atem> nacc: afaik, that's upstream design
[19:09] <nacc> Pharaoh_Atem: /usr is quite messy ... e.g., /usr/lib/php/7.0 and /usr/lib/php/20151012
[19:09] <nacc> Pharaoh_Atem: but yeah, might just be how it is
[19:10] <nacc> Pharaoh_Atem: means that, e.g., grahviz's swig bindings not only need updating (probably) but also that graphviz's configure does as the paths aren't defined for it search for, e.g. php.h
[19:11] <Pharaoh_Atem> yeah
[19:11] <Pharaoh_Atem> upstream likes making things inconsistent
[19:12] <TJ-> nacc: does "apt-file search -x 'php\.h$' " find the file?
[19:12] <TJ-> nacc: it uses the packages .list files
[19:12] <nacc> TJ-: no, it also says that only php5-dev provides it, which is weird
[19:13] <nacc> TJ-: do I need to do something special, perhaps, to search in universe?
[19:13] <nacc> that might be the thinko on my part
[19:15] <nacc> hrm, on my reading, since universe is in my sources.list, it should work?
[19:15] <TJ-> nacc: well, might be worth doing apt-file update
[19:16] <nacc> TJ-: yeah, just did -- no difference yet, but i'll check again
[19:16] <Pharaoh_Atem> nacc: can you help me with this? http://fpaste.org/311344/52885297/
[19:16] <TJ-> nacc: strange. it puts the content list under "/var/cache/apt/apt-file/"
[19:16] <nacc> TJ-: ok, will look there next, thanks!
[19:16] <Pharaoh_Atem> I've been trying to get a working php-fpm conf, and for whatever reason, it's not working :(
[19:17] <TJ-> nacc: nacc find the package's list and check it. "ls /var/lib/dpkg/info/php7.0-dev.list"
[19:17] <Pharaoh_Atem> I forked it from the php7.0 config and merged in the conf settings used in Fedora's php-fpm package to make it work
[19:18] <Pharaoh_Atem> but it doesn't work :(
[19:18] <Pharaoh_Atem> even accounting for the packaging differences
[19:18] <nacc> TJ-: ok, php.h is present in /var/lib/dpkg/info/php7.0-dev.list
[19:18] <nacc> TJ-: but apt-file still doesn't show it
[19:19] <nacc> TJ-: weird! `apt-file list php7.0-dev` is empty?
[19:20] <TJ-> nacc: have you configured the repo line in /etc/apt/sources.list or in a file under /etc/apt/sources.list.d/ ?
[19:20] <nacc> the former, TJ-, unaltered Xenial cloud image
[19:21] <TJ-> a literal reading of 'man 1 apt-file' suggests it only reads the former
[19:22] <nacc> TJ-: to be clear, my /etc/apt/sources.list.d/ is empty, and since there are *some* results, it must be using /etc/apt/sources.list ...
[19:22] <TJ-> Yes; you may have found a bugette :)
[19:23] <nacc> TJ-: hrm, it seems that php7.0 doesn't even show up in the Contents.gz file(s)?
[19:23] <nacc> i'm looking /var/cache/apt-file...
[19:25] <TJ-> nacc: try this: "zgrep 'php\.h[[:space:]]' /var/cache/apt/apt-file/*.gz"
[19:26] <nacc> TJ-: just shows php5-dev
[19:26] <nacc> TJ-: so it's like the universe entries aren't there?
[19:28] <nacc> heh, zless keeps getting killed while trying to page the 32M Contents.gz file :)
[19:28] <TJ-> nacc: that suggests something wrong with the 'update', or the deb line in sources.list. are there any "universe/<section>/<package> entries?
[19:29] <nacc> TJ-: hrm, there are, actually, you're right
[19:30] <TJ-> nacc: I'm running "zgrep '[[:space:]]universe/' /var/cache/apt/apt-file/*.gz | wc -l" to get an idea of how many
[19:30] <nacc> actually, less was getting OOM killed .... interesting ... probably a bad implementation for memory? does it try to keep the entire file in memory?
[19:31] <nacc> oh bah, it's because i'm in a tiny VM by default :)
[19:33] <nacc> TJ-: i get: 4222502
[19:34] <TJ-> On 15.10 I got 3978947 so you win :)
[19:35] <nacc> heh
[19:38] <nacc> Pharaoh_Atem: i'll look, not sure how much help i'll be! what's the symptom of it "not working"?
[19:41] <nacc> TJ-: ok, so dpkg (perhaps obviously) does know what provides the file I was looking for (but is obviously only look at what's installed) ... ah well, should I file a bug?
[20:08] <TJ-> nacc: it looks like something is out of sync with the files apt-file fetches, compared to the package .list files. I'm not clear right now how/why that would be
[20:35] <Pharaoh_Atem> nacc: my hello.php containing "<?php echo "Hello, world!\n"; ?>" doesn't output "Hello, world!" and instead outputs the plain file
[20:35] <nacc> Pharaoh_Atem: hrm...
[20:42] <nacc> Pharaoh_Atem: what port is php-fpm listening on?
[20:44] <Pharaoh_Atem> it's listening on a unix socket
[20:47] <Pharaoh_Atem> starting with httpd 2.4.12, it can talk to things like fpm with a unix socket, just like nginx can
[21:56] <nacc> Pharaoh_Atem: ah duh
[21:59] <nacc> Pharaoh_Atem: shouldn't those be /var/run?
[22:18] <Pharaoh_Atem> nacc: it seems /var/run is symlinked to /run
[22:19] <nacc> Pharaoh_Atem: fact :)
[22:19] <nacc> ah ok
[22:19] <nacc> and the socket in question does indeed exist, etc?
[22:59] <Pharaoh_Atem> nacc: yep
[22:59] <Pharaoh_Atem> the corresponding pid file is there too