[00:23] <smckee> Hi everyone, I'm doing a study at Oregon State University trying to determine what is difficult about merge conflicts and how developers solve their conflicts. We're looking for professional developers with 3+ years of experience. Would anybody here be interested in participating in a ~20 minute interview? We will, of course, compensate you for your time :)
[00:24] <teward> !offtopic | smckee
[00:24] <ubottu> smckee: #ubuntu is the Ubuntu support channel, for all Ubuntu-related support questions. Please register with NickServ (see /msg ubottu !register) and use #ubuntu-offtopic for other topics (though our !guidelines apply there too). Thanks!
[00:24] <teward> close enough
[00:24] <sarnold> I've gotta say, twenty minutes feels like an absolute eternity, especially this close to release date..
[00:26] <smckee> teward and ubottu, My apologies, I wasn't sure which channel to use as there are so many to choose from.
[00:47] <nacc> Pharaoh_Atem: slangasek: i can confirm http.so is loading before raphf.so per strace, even though the http.so build specifies: PHP_ADD_EXTENSION_DEP([http], [raphf], true)
=== muktupavels is now known as muktupavels_
[01:19] <Pharaoh_Atem> nacc: so is there a way to fix that?
[01:20] <nacc> Pharaoh_Atem: not sure, need to figure out where the bug is first
[01:20] <nacc> slangasek: fyi, using your output, we have about 46 pacakges left to fix up, i'm starting on build-deps now
[01:20] <nacc> some might be swig/drops, too
[01:21] <slangasek> nacc: yep, that number sounds about what I saw at last check
[01:22] <nacc> slangasek: ok, will try to get to 0 tomorrow :)
[01:23] <slangasek> nacc: I actually count 37 now, with some manual filtering of the false-positives
[01:23] <slangasek> and some are pending either in -proposed or in the sponsor queue
[01:44] <nacc> slangasek: cool, yeah, that number above was raw, not processed for the ones i know about
=== juliank is now known as Guest22643
=== juliank_ is now known as juliank
=== salem_ is now known as _salem
[03:03] <stgraber> pitti: do you think it would be possible to publish the VM images for adt somewhere on autopkgtest.ubuntu.com? just spent half an hour trying to understand why my testsuite failed on adt but not locally, just to find that it had to do with the package list differing as I'm using the cloud images locally that contain a bunch more things
[03:04] <stgraber> (in this case, I was missing lxc-templates)
[03:33] <Skuggen> rbasak: ack
[03:35] <Skuggen> infinity, rbasak: So does that leave us with the suggestion in https://bugs.launchpad.net/ubuntu/+source/myodbc/+bug/1564856/comments/1? Focus on getting everything else working, and then see if we can get myodbc working and updated?
[03:35] <ubottu> Launchpad bug 1564856 in myodbc (Ubuntu) "myodbc uses internal libmysqlclient functions no longer exported by 5.7" [Undecided,New]
[04:00] <infinity> Skuggen: Yep.
[04:01] <sarnold> which installer is used on the server disk? is that debian-installer or ubiquity? I see them both in the pool/
[04:14] <Unit193> infinity: BTW, do you think it'd be sane to have ddebs commented out in the default sources.list, just like proposed?
[04:42] <cpaelzer> good morning
[06:10] <pitti> Good morning
[06:11] <Foxtrot> Morning
[06:12] <pitti> stgraber: I don't think that there's anywhere I could publish them, but they are using "--setup-commands setup-testbed" on lcy01, and the equivalent of adt-buildvm-ubuntu-cloud on the two other clouds
[06:12] <pitti> stgraber: I'd like to use the latter on all three, but lcy01 doesn't allow new image builds, so it behaves differently :/
[06:13] <pitti> rbasak: sure, you can sudo mkdir the cgroup you want, and then echo $$ > /sys/fs/cgroup/<controller>/<cgroup>/tasks
[06:17] <pitti> rbasak: ah, reading more scrollback -- you can use something like "sudo systemd-run -t -p MemoryLimit=5M bash" too
[06:17] <pitti> rbasak: see man systemd.resource-control for the various settings wrt. cgroup limits
[06:39] <infinity> sarnold: d-i is used to install the server ISO.  ubiquity is there for people to use oem-config post-install.
[06:41] <sarnold> infinity: thanks :D
=== athairus is now known as afkthairus
[07:05] <pitti> stgraber: I just noticed that adt-buildvm-ubuntu-cloud hangs eternally now, on/after "Started LXD - network bridge" (this is after *removing* lxd..)
[07:16] <GunnarHj> pitti: Good morning, Martin. As an alternative to the fontconfig upgrade we talked about yesterday, we successfully patched a few upstream commits:
[07:16] <GunnarHj> https://launchpad.net/~gunnarhj/+archive/ubuntu/fontconfig-test/+packages
[07:16] <GunnarHj> Would you consider that to be a safer/better alternative, considering that we are late in the cycle? (The patch is not small.)
=== BinLi_afk is now known as BinLi
[07:43] <pitti> GunnarHj: yes, quite obviously safer; do we actually want/need any of the other fixes from the new version?
[07:43] <pitti> GunnarHj: shall I sponsor this for now?
[07:43] <GunnarHj> pitti: Not as far as we know. This ought to be sufficient.
[07:44] <GunnarHj> pitti: Yes, it would be great if you could sponsor it. (Can you please correct a typo in the changelog if you do - the patch name is not correct.)
[07:45] <pitti> GunnarHj: uploaded with fixed changelog, thanks!
[07:46] <GunnarHj> pitti: Thank you!
=== muktupavels_ is now known as muktupavels
=== shuduo_ is now known as shuduo
[08:36] <pitti> meh, github.com feels like a pit of tar today
[08:37] <pitti> and now I'm getting unicorns
[08:37]  * Unit193 tests pitti's BAC.
[08:38] <smb> pitti, that rather sounds like an improvement... ;)
[08:38] <pitti> smb: but *pink* unicorns?? *shudder*
[08:38] <pitti> Unit193: "BAC"?
[08:38] <smb> Sure its not *pink* but some other colour we cannot describe
[08:38] <pitti> ah, https://status.github.com/ mentions this too
[08:39] <Unit193> pitti: Blood Alcohol Content. ;)
[08:39] <pitti> this was *not* a pull request for "moar beer!" :)
[08:40] <pitti> it's a little early in the morning for that
[08:40] <smb> pitti, not in Bavaruia
[08:46] <infinity> pitti: That must have just happened, I was getting ~100 Mbit/s from them an hour ago.
[08:57] <elmo> infinity, pitti: they're currently being routed via a DDoS scrubber FWIW
[08:58] <pitti> and https://status.github.com/ now changed from "connectivity problems" to "major service outage"
[08:58]  * pitti will just wait then, not only me obviously
[08:59] <pitti> Laney: whoa, "No nova image available that matches ubuntu/ubuntu-vivid-.*-i386-server" → seems our clouds lost the vivid images :/
[08:59] <pitti> lgw at least
[09:00] <flexiondotorg> Morning Pilots xnox, tjaalton, smoser
[09:01] <flexiondotorg> If you are able please can you take a look at my sponsor requests?
[09:01] <flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/mate-tweak/+bug/1565356
[09:01] <ubottu> Launchpad bug 1565356 in mate-tweak (Ubuntu) "Sync mate-tweak 3.5.9-1 (universe) from Debian unstable (main)" [Undecided,New]
[09:01] <flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-artwork/+bug/1563971
[09:01] <ubottu> Launchpad bug 1563971 in ubuntu-mate-artwork (Ubuntu) "ubuntu-mate-artwork 16.04.6 bug fix release [debdiff attached]" [Undecided,New]
[09:02] <Laney> pitti: !!!
[09:02]  * pitti sends an RT
[09:12] <seb128> bdmurray, hey, do you have any idea why https://errors.ubuntu.com/problem/9add44104f20d47646d1c9f9f952bc5fee42bbc3 fails to give a backtrace?
=== tsdgeos_ is now known as tsdgeos
[10:45] <doko> mvo_, please could you fix your goget-ubuntu-touch b-d's? see  http://people.canonical.com/~ubuntu-archive/nbs.html
[11:06] <doko> jamespage, python-pathspec accepted, however the python3 package doesn't use python3:Depends
[11:06] <jamespage> doko, ack will get that fixed up...
[11:10] <ginggs> pitti: could we ignore the i386 autopkgtest for julia please?
[11:10] <pitti> ginggs: the llvm error is back? ok
[11:10] <doko> jamespage, why are python-stuf and python-otherstuf not packaged for Python3?
[11:11] <pitti> ginggs: hint committed
[11:12] <ginggs> pitti: danke
[11:12] <doko> jamespage, theblues: Comment: License information is not present in the 0.1.1 release; see
[11:12] <doko>  XXX for actual licensing information.
[11:12] <doko> is this still valid?
[11:15] <rbasak> pitti: neat. Thanks!
[11:16] <doko> jamespage, 	python-libcharmstore doesn't have a copyright file
[11:17] <jamespage> doko, actually that might not be - let me check (re the blues)
[11:18] <jamespage> doko, stuf and otherstuf depend on python-parse which is not yet py3 enabled...
[11:18] <jamespage> doko, let me check in libcharmstore - I swear I fixed that
[11:19] <doko> well, then enable it ;)  apparently it won't be enabled in Debian
[11:20] <jamespage> doko, I'll ask marcoceppi to take a look at the py3 enablement for parse and *stuf
[11:20] <jamespage> python-libcharmstore in the NEW queue does have a copyright...
[11:20] <doko> jamespage, it's the comment in debian/copyright which I cited
[11:22] <jamespage> doko, you are correct about theblues - my comment in the copyright file was on the first version I reviewed which lackes any upstream licensing information
[11:22] <jamespage> I can correct that and re-upload if you like, or I can fix it post acceptance...
[11:24] <doko> jamespage, ok, but please before the release ...
[11:24] <jamespage> doko, I have it ready to go for theblues...
[11:25] <jamespage> doko, http://paste.ubuntu.com/15627833/
[11:25] <jamespage> doko, re 'python-libcharmstore doesn't have a copyright file'
[11:25] <doko> jamespage, the upstream copyright file is missing
[11:26] <jamespage> doko, lemme take anther look
[11:27] <jamespage> doko, ah sorry I missed that
[11:27] <jamespage> LGPL is identitified in the setup.py but its not versioned...
[11:28] <jamespage> marcoceppi, hey - can you update libcharmstore for licensing information please; its to light atm
=== hikiko is now known as hikiko|ln
=== _salem is now known as salem_
[12:02] <pkern> We don't install git by default on laptop. Heresy.
[12:18] <highvoltage> 1/win 10
[12:24] <mvo_> doko: sure, will do
=== hikiko|ln is now known as hikiko
[12:41] <mvo_> doko: how often is the nbs.html updated? this should be fixed with the latest upload
[12:43] <doko> mvo_, once the package is migrated
[12:45] <doko> xnox, is this temporary? https://launchpadlibrarian.net/251822278/buildlog_ubuntu-xenial-s390x.openexr_2.2.0-9ubuntu1_BUILDING.txt.gz
[12:46] <xnox> looks weird
[12:50] <doko> bdmurray, please could you have a look at https://launchpadlibrarian.net/251821539/buildlog_ubuntu-xenial-amd64.update-manager_1%3A15.10.3_BUILDING.txt.gz missing b-d?
=== xnox_ is now known as xnox
=== psivaa_ is now known as psivaa
=== inaddy_ is now known as inaddy
=== TJ_Remix is now known as TJ-
[13:27] <hallyn> pitti: hey - lxc and lxcfs use Delegate= in their systemd jobs.  In jessie that's not supported.  What is the recommended way to deal with that?  sed it out in debian/rules until systemd is updated, or is there a better way?
[13:28] <pitti> hallyn: systemd normally ignores directives it does not know about (at most it might warn about them); does that actually cause problems?
=== lewq_ is now known as lewq
[13:31] <hallyn> yeah apparently theywon't start
[13:31] <TJ-> interesting openjdk-7 question from a user: required by the android build tools, but no longer in 16.04 (although I have a March 5th 16.04 chroot that still contains openjdk-7) - is this intended (to break android builds) ?
[13:31] <hallyn> fiding url
[13:31] <hallyn> pitti: https://lists.linuxcontainers.org/pipermail/lxc-devel/2016-April/013964.html
[13:33] <pitti> hallyn: ah, seems I'm wrong then, sorry
[13:35] <doko> tjaalton, is ubuntu-x-swat used as bug subscriber for other packages as well?
[13:37] <tjaalton> doko: all of X
[13:52] <doko> mvo_, goget-ubuntu-touch (0.33-0ubuntu2 to 0.34-0ubuntu1)
[13:52] <doko> won't migrate: ubuntu-emulator/i386 unsatisfiable Depends: ubuntu-emulator-runtime
[13:53] <TJ-> Urgent: we seem to have a widespread signing-key mismatch for the trusty-updates lists, on the main archive server and mirrors
[13:54] <cjwatson> TJ-: sample output please
[13:55] <cjwatson> I'm not seeing it here
[13:55] <TJ-> cjwatson: 2 users in the last hour reported hash sum mismatch for it, one on the main archive, one on the US archive. I've just pulled the files manually and http://paste.ubuntu.com/15629885/
[13:56] <cjwatson> (note that archive.ubuntu.com is a mirror too)
[13:56] <TJ-> cjwatson: right :)
[13:57] <cjwatson> the master site is fine
[13:58]  * cjwatson analyses
[13:58] <TJ-> I've just grep-ed my irc log, for the 2 users reporting. The 1st user cleared their /var/lib/apt/lists/ out and redid apt-get update and still hit it. http://paste.ubuntu.com/15629926/
[14:00] <TJ-> hah, 3 users isn't there. missed that :)
[14:00] <cjwatson> all archive.ubuntu.com hosts are fine
[14:01] <cjwatson> which is a superset of all us.archive.ubuntu.com hosts
[14:02] <cjwatson> TJ-: so I can't reproduce this as a live issue on our primary mirrors.  please ask users to pastebin the output of "apt-get -o Debug::Acquire::http=true -o Debug::Hashes=true update"
[14:02] <TJ-> cjwatson: will do
[14:02] <cjwatson> my (crude) methodology was:
[14:02] <cjwatson> for x in 91.189.88.152 91.189.92.200 91.189.91.15 91.189.92.201 91.189.91.14 91.189.88.149 91.189.88.153 91.189.91.13 2001:67c:1560:8001::11 2001:67c:1562::15 2001:67c:1562::14 2001:67c:1360:8001::17 2001:67c:1360:8c01::19 2001:67c:1360:8c01::18; do mkdir -p $x; curl --resolve archive.ubuntu.com:80:$x -o $x/Release http://archive.ubuntu.com/ubuntu/dists/trusty-updates/Release; curl --resolve archive
[14:02] <cjwatson> .ubuntu.com:80:$x -o $x/Release.gpg ...
[14:02] <cjwatson> for x in *; do gpg --verify $x/Release.gpg $x/Release; done
[14:03] <cjwatson> ... http://archive.ubuntu.com/ubuntu/dists/trusty-updates/Release.gpg; done
[14:03] <cjwatson> TJ-: this sort of thing is usually a mirror update race which goes away though
[14:04] <TJ-> cjwatson: OK, I thought that for the first 1 although the user had tried 30 minutes apart, but with 2 more reporting it seemed ... strange
[14:04] <cjwatson> TJ-: well, if the race happens to hit a mirror rather than just a single user, it can persist for a while
[14:05] <cjwatson> oh hell my methodology is bust isn't it
[14:05] <cjwatson> I was checking Release vs. Release.gpg not Packages files
[14:06] <cjwatson> still, that debug output would be useful
[14:06] <TJ-> :p
[14:06] <TJ-> I've asked for it, I'll give you pastebin links once they're available
[14:06] <TJ-> and:   scwizard | TJ-: http://paste.ubuntu.com/15630027/
[14:06] <cjwatson> this issue will go away for xenial soon
[14:07] <cjwatson> TJ-: that's not the output of the command I gave
[14:07] <TJ-> hmm!
[14:07] <cjwatson> come back when it actually has debugging information in it :)
[14:07] <TJ-> oh, does debugging go to stderr by any chance? if so, it's because of the redirection I gave them :p
[14:07] <cjwatson> probably
=== bigon_ is now known as bigon
[14:09] <cjwatson> 2>&1 |
[14:09] <cjwatson> or >foo 2>&1
[14:12] <TJ-> cjwatson:  scwizard | TJ-: http://paste.ubuntu.com/15630108/
[14:15] <smoser> hey, for flexiondotorg it seems acceptable to sync that to me. i tried copy-package with target of xenial-proposed but i think that just got swallowed . should i just copy by hand (pull-source and then dput)?
[14:15] <cjwatson> smoser: before you do that, what exactly did you do with copy-package?
[14:16] <smoser> bah. i just noticed its in unapproved.
[14:16] <cjwatson> ah well there you go
[14:16] <smoser>  yeah. copy-package --from=debian --to=ubuntu --suite=sid --to-suite=xenial mate-tweak
[14:16] <cjwatson> TJ-: still investigating, it's just being slow
[14:16] <smoser> so yeah, thanks cjwatson . sorry for noise.
[14:16] <TJ-> cjwatson: yes, I'm trying to reprodce on other mirrors
[14:16] <cjwatson> TJ-: I think that's probably unnecessary at this point
[14:18] <mvo_> sergiusens: hm, what ubuntu-device-flash is unhappy about ubuntu-emulator-runtime:won't migrate: ubuntu-emulator/i386 unsatisfiable Depends: ubuntu-emulator-runtime - any hints? should this get demoted to recommends?
[14:18] <sergiusens> mvo_, I will invoke sil2100 for that, I have no idea about the android emulator anymore
[14:19] <sergiusens> if it is demoted to recommends we might need some code changes in the ubuntu-emulator command to fail gracefully
[14:19] <doko> jamespage, your commons-vfs merge is dep-wait for a month
[14:22] <jamespage> nacc, hey - can you take a looks at why common-vfs is dep-wait as doko points out please
[14:22] <jamespage> as that was pretty much your merge...
[14:23] <cjwatson> smoser: I'm a little surprised that worked; I would expect to need --to-suite=xenial-proposed instead.
[14:23] <cjwatson> But there is a mate-tweak in unapproved for proposed.
[14:24] <cjwatson> smoser: Just "syncpackage mate-tweak" would have worked though, which is a bit friendlier when you don't need low-level control.
[14:24] <smoser> oh. i did use xenial-proposed
[14:25] <smoser> with just 'xenial' it failed with a nice message like "use xenial-proposed, smoser"
[14:25] <cjwatson> Ah good.
=== shuduo is now known as shuduo-afk
[14:27] <cjwatson> Having the raw copyPackage API understand the redirection directly would be much riskier, because basically the same interface is used to promote stuff from xenial-proposed to xenial, so we don't try to be magical there.
=== bregma_ is now known as bregma
=== dpm is now known as dpm-afk
[14:37] <TJ-> cjwatson: all seems fine now; race condition across those 3 mirrors must have been coincidence 3 users fetched at that point
[14:43] <cjwatson> TJ-: mirror.jmu.edu still has a Release file from four hours before archive.ubuntu.com but a more current Translation-en.bz2
[14:43] <TJ-> cjwatson: yes, that user started in us.archive and switched to try to avoid the issue ... they've switched back now
[14:43] <cjwatson> TJ-: but it looks like an entirely straightforward race, nothing sinister; should clear up at its next sync
[14:45] <TJ-> cjwatson: glad to hear it... was making me concerned with several reports in a short space of time :)
[14:46] <cjwatson> Oh, we usually get them in bulk when a mirror races.
[14:47] <TJ-> not seen one in ages, my good fortune ... thanks for your swift help :)
[14:47] <cjwatson> by-hash is hopefully rolling out todayish for xenial.  Not for earlier releases, so we'll have to put up with it for the lifetime of trusty, but with any luck this should be on the decline.
[14:48] <rharper> nice!
[14:51] <bdmurray> seb128: I'll have a look but that crash looks similar to bug 1538438.
[14:51] <ubottu> bug 1538438 in apt (Ubuntu) "apt-helper crashed with SIGABRT in __gnu_cxx::__verbose_terminate_handler()" [High,Triaged] https://launchpad.net/bugs/1538438
[14:51] <seb128> bdmurray, thanks
=== zyga_ is now known as zyga
[14:57] <hallyn> pitti: hm, finally gave in and set up a new jessie desktop.  yeah systemd *warns* about unknown Delegate but it runs fine
[14:57] <hallyn> now i'm annoyed
[15:01] <bdmurray> seb128: looks like there was no crash signature after retracing
[15:02] <seb128> bdmurray, would that be because gdb doesn't give a valid stacktrace?
[15:05] <bdmurray> seb128: https://pastebin.ubuntu.com/15631038/
[15:05] <seb128> hum, k
[15:05] <seb128> I wonder why :-/
[15:06] <bdmurray> seb128: If I find time I'll dig some more, the test case seems pretty straightforward though.
=== jgrimm is now known as jgrimm-afk
[15:29] <stgraber> pitti: hmm, that's odd
[16:22] <nacc> slangasek: ugh, libkolab is going to be ugly; they did their own .ini management, i guess
[16:23] <nacc> slangasek: meaning they don't install to the typical locations :/
[16:23] <nacc> slangasek: will need to figure out if there is a good parallel for php7
[16:31] <nacc> Pharaoh_Atem: any update on libvirt-php?
[16:32] <slangasek> nacc: php-kolab doesn't appear to be central to the functionality of libkolab (no revdeps on that binary package); could be dropped from the packaging for 16.04, or left uninstallable
[16:32] <nacc> slangasek: yeah, i think that will be the far saner route for me, it's pretty gross and I don't know it will
[16:33] <nacc> *well
[16:35] <slangasek> nacc: right, just let me know if you want to change the packaging to drop the binary (preferred unless you expect this to be fixed in SRU), or if you want it left uninstallable in the archive
[16:36] <nacc> slangasek: yeah, i'll provide debdiffs for that; it's similar to the swig case imo, not maintained
[16:36] <nacc> and i'm not sure why kolab needs php bindings :)
=== wendar_ is now known as wendar
=== dpm-afk is now known as dpm
=== francisco is now known as Guest832
=== tvoss is now known as tvoss|dinner
=== afkthairus is now known as athairus
[17:54] <Pharaoh_Atem> nacc: well, it builds and seems to run
[17:55] <Pharaoh_Atem> but we don't have enough basic unit test coverage
[17:55] <Pharaoh_Atem> so that's something that we're working on
[18:01] <nacc> Pharaoh_Atem: ok, PR sent yet?
[18:01] <Pharaoh_Atem> they don't do PRs, but not yet
[18:01] <Pharaoh_Atem> I'm hoping to get everything in shape this week for that
[18:02] <Pharaoh_Atem> the code *is* available in https://gitlab.com/Conan_Kudo/libvirt-php7 in the php7 branch
[18:02] <nacc> Pharaoh_Atem: we're probably at the point where we're just going to have to drop it
[18:02] <nacc> not sure
[18:02] <nacc> i'll confer with slangasek
[18:02] <nacc> there are no rdeps in the repo, afaict
=== jgrimm-afk is now known as jgrimm
[18:03] <Pharaoh_Atem> well, since it's in universe and not part of a seed, I'm hoping I have enough time to get it submitted
[18:03] <nacc> Pharaoh_Atem: final freeze is next week
[18:03] <Pharaoh_Atem> yeah, it's the 14th, right?
[18:16] <nacc> slangasek: heh, do you own php-imlib in debian?
[18:19] <slangasek> nacc: "own"
[18:20] <nacc> slangasek: :)
[18:20] <slangasek> nacc: it's bindings for a language I no longer use, for a library that I no longer care about
[18:20] <nacc> slangasek: fair enough, i'm guessing it won't compile, will schedule for removal too
[18:22] <nacc> slangasek: so blocking php-mcrypt's removal right now is roundcube :/
[18:25] <Pharaoh_Atem> nacc: didn't roundcube say they weren't going to support php7 anytime soon?
[18:26] <nacc> Pharaoh_Atem: 1.2 supports it, in beta right now, release any day now
[18:26] <nacc> hopefully
[18:26] <Pharaoh_Atem> awesome
[18:29] <dobey> bdmurray: is there any way to get errors.u.c to retrace crashes that failed to retrace due to "the following packages are missing debug symbols" error?
=== jtaylor_ is now known as jtaylor
[18:34] <bdmurray> dobey: I could poke the database so that we try retracing the crash again.
[18:39] <jamespage> doko, nacc: quick peek at libcommons-net-java - its looks really odd - the binary "libcommons-net-java" is in main, its source is in universe...
[18:40] <nacc> jamespage: yeah, i think it's still showing up in component mismatches too, right?
[18:40] <nacc> jamespage: because of libcommons-net-java-doc ?
[18:41] <jamespage> nacc, yah - but I think its confusion due to a rename - libcommons-net2-java -> libcommons-net-java
[18:42] <jamespage> doko, I think this is a switch and binary promotion only
[18:42] <jamespage> libcommons-net2-java got renamed libcommons-net-java
[18:42] <jamespage> the binary -java is already in main
[18:42] <nacc> jamespage: ah i see
[18:44] <jamespage> nacc, doko: confirmed - libcommons-net2-java needs dropping and replacing with libcommons-net-java
[18:45] <jamespage> commons-vfs is the only main component in the release pocket keeping net2 in main
[18:45] <jamespage> the version in proposed drops the version
[18:45] <nacc> jamespage: thanks for digging into that
[18:53] <slangasek> nacc: roundcube, on my todo for today for precisely that reason
[18:55] <nacc> slangasek: thanks; i can poke upstream again if you want, but it does sound like they are going to release soon, with something very similar to what's in beta (and their src hasn't changed much since then)
[18:56] <nacc> their release manager is busy :)
[19:15] <slangasek> nacc: my only concern on roundcube was, just because you're willing to put in free time to do the SRU does not necessarily mean it's the best use of the SRU's time to process that SRU.  But the odds seem good that we'll get this in before release, so let's go ahead
[19:17] <nacc> slangasek: yeah, i understand
[19:31] <nacc> slangasek: http://pad.ubuntu.com/8eABivrkBv
[19:31] <nacc> Pharaoh_Atem: http://pad.ubuntu.com/8eABivrkBv
[19:32] <nacc> slangasek: going to lunch for a bit, will sync with you when i'm back
[19:53] <Pharaoh_Atem> nacc: does swig have support for php7 or is the done status referring to disabling php support in swig?
[19:59] <slangasek> nacc: you have libdigidocpp marked as 'done' but it doesn't look that way to me?  still build-depends: php5-dev in xenial
[20:34] <rharper> hi, I'm trying to get a copy of ifupdown source repo on launchpad, bzr branch lp:ubuntu/trusty/ifupdown doesn't work for me (http://paste.ubuntu.com/15637779/)
[20:36] <rharper> I'm looking into this bug https://bugs.launchpad.net/ifupdown/+bug/1565711 and wanted to see about picking out the just the changes that allow ifup to succeed for manual interfaces; i think that will resolve the issue in the bug; but it's hard to understand where that is in the debdiff between trusty and vivid
[20:36] <ubottu> Launchpad bug 1565711 in MAAS "vlan configuration/unconfigured interfaces creates slow boot time" [High,New]
[20:51] <mhall119> hi guys, who can look into an FFE for me?
[20:52] <teward> mhall119: you might have better luck in #ubuntu-release and poking the release team, though you might be waiting to tomorrow
[20:56] <mhall119> thanks teward
=== salem_ is now known as _salem
[21:18] <nacc> slangasek: done is relative to me :)
[21:18] <nacc> Pharaoh_Atem: disabling
[21:18] <rbasak> rharper: I don't trust UDD to ever not be broken.
[21:18] <rbasak> rharper: but you can "pull-lp-source ifupdown <version>"
[21:18] <rharper> rbasak: yeah, I can get the source
[21:18] <rharper> but I wanted the repo
[21:18] <nacc> slangasek: i can change done to 'waiting on sponsorship'
[21:18] <rharper> hoping to find smaller commits
[21:18] <rbasak> Use https://launchpad.net/ubuntu/+source/ifupdown/+publishinghistory for all previous versions.
[21:19] <rharper> the debian hg repo doesn't seem to have single function commits either
[21:19] <rbasak> I would git-dsc-commit all of them. That'll at least break down by upload
[21:19] <rharper> heh
[21:19] <rharper> I might have to do that
[21:22] <tjaalton> mdeslaur: hi, have you planned to still merge apache2 (2.4.18-2)? if yes, i've actually done it locally
[21:23] <mdeslaur> tjaalton: I hadn't planned on it, please go ahead
[21:24] <tjaalton> ok cool
[21:49] <nacc> slangasek: Pharaoh_Atem: found one way to force the dependency between the php modules; looking into how that's properly meant to be done
[21:49] <nacc> slangasek: Pharaoh_Atem to fix pecl-http
[21:50] <doko> jamespage, nacc: promoted
[21:52] <nacc> doko: thanks!
[22:04] <mwhudson> why does golang-1.6 appear to be in trusty updates *and* proposed on https://launchpad.net/ubuntu/+source/golang-1.6 ?
[22:17] <nacc> Pharaoh_Atem: would you be able to see if remi/fc have the same level of php-pecl-http and/or the same issue?
=== alexisb is now known as alexisb-afk
[22:30] <nacc> slangasek: you're probably right, and seems like maybe you did the same for lasso? except that php-dev pulls in implicit build-deps :/
[22:30] <nacc> i'm realizing that now
[22:31] <nacc> slangasek: i think both lasso and libpuzzle need autoconf
[22:31] <nacc> slangasek: do you want updated debdiffs or will you fix locally?
[22:32] <slangasek> nacc: hmm I've already uploaded and moved on so please shoot me a fresh debdiff
[22:32] <nacc> slangasek: will do
[22:39] <nacc> slangasek: and nm, libpuzzle already explicitly pulled in dh-autoreconf, so only lasso needs a fix
[22:43] <slangasek> nacc: yep, I see the lasso FTBFS mails streaming in
[22:43] <nacc> slangasek: yeah :)
[22:44] <nacc> slangasek: incr. debdiff posted to LP: #1566404
[22:44] <ubottu> Launchpad bug 1566404 in lasso (Ubuntu) "PHP bindings only support PHP5" [Undecided,New] https://launchpad.net/bugs/1566404
[22:54] <Pharaoh_Atem> nacc: certainly
[22:57] <nacc> Pharaoh_Atem: thanks! i'm really stumped but mostly because i don't know very well how to debug these modules; i'm still digging in the builds/sources, though
[22:57] <Pharaoh_Atem> okay
[23:18] <nacc> Pharaoh_Atem: slangasek: so i see that some extensions have a priorit= value in their configuration .ini. That helps with sorting them, I beleive (so, e.g., pdo.so is a priority=10, while pdo_*.so is a priority=20)
[23:19] <nacc> Pharaoh_Atem: slangasek: for now, would you be ok with me doing the same with raphf/propro/pecl-http until i hear back from ondrej if there is a better solution/
[23:20] <Pharaoh_Atem> nacc: that sounds reasonable
[23:25] <slangasek> nacc: no objection here
[23:25] <nacc> slangasek: Pharaoh_Atem: ok, thanks testing that now
[23:28] <nacc> slangasek: so afaict, zeroc-ice will only support php7 with 3.7.x, which is yet to be released (and no release date provided that i can find), are you ok with me just removing the php-zeroc-ice package?
[23:28] <nacc> slangasek: both we and debian are on 3.5.x fyi
[23:29] <slangasek> nacc: I am perfectly ok with removing any of these packages, binary or source as appropriate, so long as their reverse-dependencies are handled in the process
[23:30] <nacc> slangasek: ok, thanks, that will probably be easiest here
[23:30] <nacc> slangasek: i think we'll need to drop spotweb, but not sure yet, but no revdeps
[23:30] <nacc> squirrelmail is all in php, but i don't know if there is a php7 version
[23:30] <nacc> Pharaoh_Atem: any idea?
[23:30] <nacc> i've been searching w/o much luck
[23:47] <nacc> woo that worked
[23:49] <Pharaoh_Atem> nacc: I don't see anything of the sort, but I'm looking a bit more
[23:50] <Pharaoh_Atem> nacc: it looks like there's no real drive to move to php7
[23:51] <nacc> Pharaoh_Atem: for that pkg at elast, upstream was more focused ohn supporting the oldest phps