[00:17] <nacc> slangasek: so php7.0.7 has grown a new binary package (php7.0-dba), which is trying to live in main. It has a build and runtime dependency that live in universe, though, so excuses doesn't like that. Do we need to provide a hint somewhere that php7.0-dba should be in universe?
[02:28] <infinity> nacc: Nope, just needs to be demoted.  Doing now.
[03:40] <lifelong0811> Can anybody tell how to attend a develop project of ubuntu
[03:59] <Logan> nacc: what a mess, lol
[03:59] <Logan> the FTBFS page is starting to fill up with PHP packages :X
[03:59] <Logan> and a lot of them won't transition to release because of failing autopkgtests...because of phpunit :'(
[05:35] <cpaelzer> good morning
[05:58] <pitti> Good morning
[07:14] <smb> pitti, morning. Man, there one tries to be helpful and actually verify the grep thing and of course that's some kind of wrong again. :)
[07:14] <smb> cpaelzer, morning
[07:14] <pitti> smb: sorry, don't take this as a "you did wrong" (thanks for helping!), I just wanted to explain why this didn't get v-done for so long
[07:16] <smb> pitti, Oh no worries. I thought you knew me well enough to know I don't feel blamed here
[07:19] <mwhudson> pitti: i saw the docker.io autopkgtests running earlier, i thought they got blacklisted?
[07:20] <mwhudson> pitti: i see that docker migrated but i can't tell if they failed normally or you readded them to the blacklist or maybe they even passed
[07:25] <pitti> mwhudson: they didn't run, and I didn't hint it; I suppose it migrated because the tests are "always failed"?
[07:26] <pitti> http://autopkgtest.ubuntu.com/packages/d/docker.io/
[07:26] <mwhudson> pitti: huh guess so
[07:26] <pitti> and they did run+succeed on armhf/s390x (i. e. in LXC)
[07:26] <mwhudson> pitti: pretty sure i saw it on running.shtml though
[07:26] <pitti> mwhudson: presumably on the LXC platforms?
[07:26] <mwhudson> pitti: yeah, they don't really do anything in LXC though :-)
[07:27] <pitti> integration          SKIP Test requires machine-level isolation but testbed does not provide that
[07:27] <mwhudson> i thought it was i386 but well
[07:27] <pitti> heh, yes
[07:27] <mwhudson> not going to worry overmuch about it
[07:27] <mwhudson> oh wait, it did run on i386
[07:27] <mwhudson> http://autopkgtest.ubuntu.com/packages/d/docker.io/yakkety/i386/
[07:29] <pitti> mwhudson: ah right, I only blacklisted amd64
[07:29] <pitti> fails to install
[07:29] <mwhudson> yeah, that actually looks potentially interesting
[07:30] <pitti> but as it's alwaysfail, the tests don't protect against regressions
[07:33] <mwhudson> yeah, happens on amd64 too
[07:33] <mwhudson> whoops!
[07:39] <mwhudson> pitti: huh -s doesn't work for uninstallable packages?
[07:39] <pitti> mwhudson: that sounds fixable
[07:41] <pitti> mwhudson: untested, but should work: http://paste.ubuntu.com/17138812/
[07:41] <pitti> (brb)
[07:52] <Skuggen> Nice. My control file caused apt-get to segfault
[07:56] <mwhudson> well i no longer know how docker works
[09:25] <bdrung_work> pitti, I agree. it should be fixed in the kernel
[09:30] <rbasak> pitti: are you dealing with NIC renaming fallout? Bug 1519120 has a patch for vlan.
[09:31] <rbasak> (but I wouldn't be comfortable considering it without your review)
[10:02] <pitti> rbasak: looks straightforward enough to me; I've never used the vlan package though, but this looks plausible
[11:06] <dosaboy> bdmurray: hey, is 1524989 good to land in -updates anytime soon?
[11:45] <cpaelzer> rbasak: RAOF: hey, I took a look at bug 1524526 and after some analysis I came up with a fix that (maybe) wan't anticipated - drop the lucene-plugin completely
[11:46] <cpaelzer> rbasak: RAOF: I've given detailed reasons in the bug, but that certainly is worth a discussion if you would second that approach
[11:46] <cpaelzer> rbasak: RAOF: therefore pinging you in IRC about it
[11:47] <cpaelzer> TL;DR: it never worked + is deprecated by the upstream project - so why going for a potentially complex and error prone fix
[11:48] <cpaelzer> there surely is some darkness to removing packages I don't (want to) know that bites me with that suggestion :-)
[12:00] <rbasak> cpaelzer: thank you for the analysis. Your suggestion seems reasonable. Do we know what Debian think of this?
[12:00] <rbasak> And does this affect Debian too?
[12:14] <cpaelzer> rbasak: forgot to mention ... checking debian on this
[12:15] <lundmar> Hi, can I suggest that Ubuntu 16.04 add/enables completion support for installed snaps?
[12:16] <ogra_> lundmar, i think there is a bug already (and there is the #snappy channel too ;) )
[12:16] <lundmar> ogra_: thanks, I'll go #snappy
[12:17] <mdeslaur> xavigarcia: any idea why xenial shows a muted volume notification when I get to lightdm, and right after logging in?
[12:27] <cpaelzer> rbasak: Debian has the dependency that is in question enabled, since they don't have to care abotu main/univese
[12:27] <cpaelzer> I updated the bug so that all information is in one place
[12:27] <cpaelzer> We removed that build dependency on our merges
[12:27] <cpaelzer> not realizing it is breaking things
[12:36] <xavigarcia> mdeslaur, hhmm no idea. I should take a look myself...
[12:36] <mdeslaur> xavigarcia: has anyone reported that before?
[12:36] <xavigarcia> mseslaur: I don't think so... at least that I remember
[12:37] <xavigarcia> mdeslaur: does it only happen in Xenial?
[12:37] <mdeslaur> xavigarcia: it didn't happen in wily, and I upgraded my laptop to xenial last week and that's when it started
[12:37] <cpaelzer> rbasak: If we all agree on the approach, dovecot could by my first more complex merge also trying the importer
[12:38] <xavigarcia> mdeslaur: ok... then maybe it should be good to fill a bug
[12:38] <cpaelzer> rbasak: how would "dropping" a package being done as SRU (would it?)
[12:38] <cpaelzer> rbasak: the old broken ones will be always in the archive right
[12:38] <mdeslaur> xavigarcia: against what package, indicator-sound?
[12:40] <seb128> mdeslaur, if you restart the indicator does it display the notification as well?
[12:40] <xavigarcia> mdeslaur: yep
[12:41] <mdeslaur> seb128: yes, if I kill it, it respawns and displays it
[12:41] <seb128> mdeslaur, k, so it gets some sort of event on start, might make easier to debug
[12:41] <seb128> mdeslaur, is there anything in .cache/upstart/indicator-sound.log?
[12:42] <mdeslaur> (process:15411): indicator-sound-WARNING **: volume-control-pulse.vala:744: Unab
[12:42] <mdeslaur> le to connect to dbus server at 'unix:path=/run/user/1000/pulse/dbus-socket': Co
[12:42] <mdeslaur> uld not connect: No such file or directory
[12:46] <seb128> mdeslaur, I don't have that socket either but neither I get the warning
[12:47] <seb128> xavigarcia, ^ is that something you saw before?
[12:47] <xavigarcia> mdeslaur:mmmm nope... it seems pulse is not running properly
[12:49] <seb128> xavigarcia, I don't have that socket either on my system though?
[12:51] <xavigarcia> seb128: let me check mine
[12:51] <mdeslaur> sorry, my network died
[12:51] <mdeslaur> did I miss anything?
[12:52] <seb128> mdeslaur,
 mdeslaur, I don't have that socket either but neither I get the warning
 mdeslaur:mmmm nope... it seems pulse is not running properly
[12:52] <mdeslaur> huh
 xavigarcia, I don't have that socket either on my system though?
[12:52] <seb128> internet suggests that we don't load the pulseaudio dbus module by default on Ubuntu
[12:52] <seb128> unsure if that's true
[12:52] <seb128> mdeslaur, you don't have a weird pulse config like by-session mode or something
[12:52] <seb128> just in case
[12:52] <xavigarcia> seb128: Me either, but I remember the socket is used only at a certain point
[12:53] <mdeslaur> Hrm, whatever I have is the default
[12:53] <seb128> mdeslaur, I guess you can try to restart pulseaudio in debug and share the log
[12:53] <mdeslaur> or at least was the default when I installed a few releases ago
[12:53] <mdeslaur> let me file a bug first, one sec
[12:53] <seb128> no weird security-snappy version
[12:53] <seb128> or confinement? ;-)
[12:53] <seb128> of pulseaudio
[12:53] <ogra_> werid ?
[12:53] <ogra_> what do you mean by that ?
[12:53] <ogra_> :P
[12:53] <seb128> lalala
[12:53] <seb128> ;-)
[12:54] <ogra_> *grin*
[12:55] <mdeslaur> nothing weird, just a standard xenial desktop
[12:55] <mdeslaur> no snappy anything, no non-default confinement
[12:55] <mdeslaur> ok, filed bug 1590769
[12:58] <xavigarcia> mdeslaur: cool, I'll take a look to the bug, thanks!
[12:58] <mdeslaur> xavigarcia: let me know if you need anything, or want me to try anything
[13:01] <xavigarcia> mdeslaur: sure, thanks
[13:06] <seb128> mdeslaur, can you get the pulseaudio log?
[13:07] <seb128> mdeslaur, https://wiki.ubuntu.com/PulseAudio/Log
[13:08] <rbasak> cpaelzer: I'm not sure it's worth doing an SRU to remove the package. It's unusable now and it'd be unusable after the SRU so I'm not sure it's worth any regression risk.
[13:09] <rbasak> cpaelzer: I'm open to opinions on that though.
[13:11] <mdeslaur> seb128: sure, adding to bug
[13:22] <RAOF> cpaelzer: I'm happy with dropping the lucene plugin. At the point I started playing with this upstream hadn't deprecated the plugin :)
[13:22] <cpaelzer> RAOF: hi, didn't expect you around yet - thanks for the feedback
[13:23] <RAOF> cpaelzer: I'm in Montréal :)
[13:23] <cpaelzer> rbasak: RAOF: you are right it is broken before and after - but before (like now) installing and configuring it can break the other parts of dovecot
[13:23] <cpaelzer> RAOF: ah directory told me something mroe around the globe - sry
[13:24] <cpaelzer> RAOF: temporary?
[13:24] <RAOF> cpaelzer: Oh, I *live* in Hobart; I'm at a sprint.
[13:24] <cpaelzer> things make sense now :-)
[13:25] <cpaelzer> rbasak: I'm not voting for an SRU in any way, especially not for a complex one, but bumping it by one version and adding a breaks dovecot-core might prevent more fallout
[13:25] <cpaelzer> and inY it can be still dropped
[13:26] <seb128> mdeslaur, thanks, I don't see anything talking to be but let see if the audio guys have more clue ;-)
[13:26] <rbasak> cpaelzer: that's a good point. If we're going to add a Breaks though, might as well remove it.
[13:26] <smoser> doko, around ?
[13:26] <rbasak> cpaelzer: maybe we should get someone from the SRU team to weigh in.
[13:26] <cpaelzer> rbasak: I didn't know if removing is possible
[13:26] <smoser> i'm looking at bug 1584147 .
[13:26] <rbasak> cpaelzer: it isn't, but we can make it an empty package.
[13:27] <cpaelzer> rbasak: ok, that is kind of removed
[13:27] <smoser> i will verify that the debdiff at http://paste.ubuntu.com/17143030/ fixes it, but would you want to do that in debian ?
[13:27] <cpaelzer> rbasak: I agree that we need the SRU team to share their opinion on it, but IIRC we need to do it in the devel release first (I wonder if that applied here as well)
[13:28] <cpaelzer> rbasak: so one would need to do the merge to .24 and change the behaviour in Y and THEN push to the SRU Team for their preferred approach into X
[13:28] <cpaelzer> rbasak: does that sound right?
[13:29] <rbasak> cpaelzer: yeah that sounds right. I wonder if we need to do anything for an upgrade path in Yakkety.
[13:29]  * rbasak examines https://wiki.debian.org/PackageTransition
[13:30] <rbasak> Perhaps case 11, but I'm not sure. I would consult Adam or Colin or someone :)
[13:30] <cpaelzer> rbasak: there are no special conffiles to the pludin, and since nobody ever was able to enable it we can't hurt somebody
[13:30] <rbasak> cpaelzer: yes but I want to ensure it gets removed on upgrade rather than an old one hanging around.
[13:30] <rbasak> cpaelzer: unless the existing relations would force that anyway
[13:32] <cpaelzer> rbasak: let me nnote that in the bug, modify it that it becomes a merge bug, and ask them on the real case then
[13:32] <cpaelzer> rbasak: probably easier to discuss that on the prepared real example then right?
[13:33] <rbasak> cpaelzer: yes
[13:33] <rbasak> cpaelzer: also we'll want to do what Debian wants to do to save any future merge pain
[13:33] <cpaelzer> rbasak: Debian hasn't an issue with the main/universe - so they do nothing
[13:34] <cpaelzer> rbasak: the plugin isn't deprecated enough yet that they would drop it
[13:34] <rbasak> cpaelzer: oh - lucene isn't broken on Debian?
[13:34] <cpaelzer> rbasak: our merges always dropped the dependency
[13:34] <rbasak> Sorry, I missed that.
[13:34] <rbasak> OK, sounds like you're more on top of this than I am :)
[13:34] <cpaelzer> rbasak: about 1:10 back in the log
[13:35] <rbasak> I did miss that, sorry.
[13:35] <cpaelzer> rbasak: I'll try to go on on this and you feel free to interrupt or help whenever you think so - thanks for the support already
[13:35] <rbasak> cpaelzer: great. Thanks for driving!
[13:37] <clivejo> is there anyone here would sponsor uploads?
[13:40] <rbasak> clivejo: I suggest you specify what it is. People don't like committing to an unbounded amount of reviewing time, and different devs will take different amounts of time to review something depending on their familiarity in the area.
[13:41] <clivejo> Im trying to get KDE software packaged and into the archive
[13:43] <rbasak> clivejo: do you know about the sponsorship queue?
[13:44] <rbasak> clivejo: https://wiki.ubuntu.com/SponsorshipProcess and http://reqorts.qa.ubuntu.com/reports/sponsoring/index.html
[13:54] <clivejo> is there anyone here working on Qt?
[13:59] <dobey> clivejo: mirv is our main qt person, but he's away until mid july
[13:59] <clivejo> who is Timo?
[14:00] <ogra_> he is mirv
[14:27] <Saviq> pitti, hey, when trying to recycle https://requests.ci-train.ubuntu.com/static/britney/ticket-1511/vivid/excuses.html mterry got "You submitted an invalid request: Unknown release vivid" - is that known/expected?
[14:51] <pitti> Saviq: probably fallout from the debci reconstruction; I'll look at it ASAP (meeting prep first)
[14:51] <pitti> die, vivid, die :)
[14:58] <pitti> Saviq: fixed and retried
[14:59] <nacc> infinity: thanks!
[14:59] <nacc> Logan: yep, i'm pushing that to the top of my list
[15:05] <doko> smoser, I'd like to wait for the final upstream patch
[15:05] <smoser> doko, well, it went in
[15:05] <smoser> and i assume we'll grab 3.5.2 when it releases end of June.
[15:05] <smoser> so this is very short time, right ?
[15:05] <doko> yep
[15:06] <smoser> but its very painful for cloud images
[15:06] <smoser> like 6 minute boots rather than 10 seconds.
[15:07] <smoser> doko, i was just about to uplaod http://paste.ubuntu.com/17144867/
[15:07] <smoser> verified it fixes our issues in a patched vm.
[15:07] <smoser> i dont want to step on your toes, but i dont want to wait 3 weeks for a fix either.
[15:08] <pitti> yeah, huge pain on the autopkgtest side too
[15:09] <rbasak> Please add the Ubuntu delta. I think it's too painful to wait.
[15:09] <rbasak> If it's only the delta, it should be trivial to sync once Debian is fixed, right?
[15:09] <smoser> right. its our only delta from debian, and can just be dropped at 3.5.2 release.
[15:10] <smoser> http://paste.ubuntu.com/17144921/ <-- no longer includes the hashset named patch that was unused.
[15:10] <doko> smoser, well, the patch isn't yet final. the discussion continues on the ML. not sure why you can't fix cloud-init to set the env var at this point
[15:11] <rbasak> How about we just revert the upstream commit that broke it then until they have committed a final fix?
[15:11] <rbasak> We can't commit stuff that everyone agrees breaks things and then sit on it for weeks. That's hardly continuous quality.
[15:11] <doko> there will be a final fix this Monday. why rush this now?
[15:11] <smoser> i can change cloud-init, but carrying delta in that one package (using PYTHON_HASHSEED=99) just pushes it off to the next consumer
[15:12] <smoser> why a final fix this monday ?
[15:12] <rbasak> doko: because the longer we wait, the bigger the fallout because we blocked development and QA for longer.
[15:12] <smoser> i'm not aware of python developmetn process. i assumed its incorporation into trunk  and then also into the 3.5 branch meant final.
[15:12] <rbasak> What's the fallout in just reverting the broken upstream commit?
[15:14] <smoser> what did you mean by 'final' ?
[15:15] <doko> because 3.5.2 final will have this fix
[15:16] <smoser> you mean the release candidate.
[15:16] <smoser> dueo Sunday June 12.
[15:17] <smoser> doko, if you're going to pick that up and have it in debian and ubuntu on Sunday/Monday, then i'm ok to wait. but even then all we have to do to revert my 4 day patch would be to sync from debian.
[15:17] <smoser> (release schedule https://www.python.org/dev/peps/pep-0478/ )
[15:17] <doko> see the thread starting at https://mail.python.org/pipermail/python-dev/2016-June/144939.html
[15:20] <pitti> smoser: I thought PYTHONHASHSEED wasn't sufficient?
[15:20] <pitti> because of "import random"?
[15:20] <pitti> I already added the workaround to autopkgtest, if that workaroud would work for cloud-init, then we could apply it, but I thought it doesn't
[15:20] <smoser> pitti, right. it is not sufficient.
[15:20] <pitti> the only other known victim so far is systemd-cron, but that's not that interesting/urgent
[15:21] <smoser> i was working on a change yesterday to work around that too. but *still* all that does is push it off to the next consumer.
[15:21] <pitti> indeed, so we don't have a workaround, and applying the fix or reverting the original commit are our only options
[15:22] <smoser> and honestly, me changing cloud-init for 5 days to work around a bug seems worse than fixing the package for the interim time.
[15:22] <smoser> https://mail.python.org/pipermail/python-dev/2016-June/144939.html is a good read.
[15:22] <rbasak> doko: why do you want to defer fixing the python package right now?
[15:23] <rbasak> (whether it's reverting the original commit or applying an intermediate fix I don't care)
[15:28] <doko> rbasak, I'd like to avoid a differing behaviour in the Ubuntu package. I escalated this as a release blockerlast weekend, and with a fix promised for this weekend
[15:28] <rbasak> doko: why would a differing behaviour in the Ubuntu package be a problem if it only lasts for four days? Surely the differing behaviour that unblocks people is a good thing?
[15:32] <ddellav> can someone please promote these py3 packages to main? their py2 counterparts have already been included: http://paste.ubuntu.com/17145451/
[15:32] <doko> rbasak, why does it block you now, and not two weeks ago?
[15:33] <pitti> it has been a real nuisance/blocker for all that time :)
[15:33] <pitti> I just wouldn't like to wait three more
[15:34] <pitti> at least for me this essentially causes half a cloud to not work for testing (why it's working on the other is related to another issue, it's complicated)
[15:34] <Saviq> pitti, thanks
[15:35] <ddellav> coreycb jamespage monascaclient MIR submitted, please review and I'll add the ubuntu-mir team subscriber: https://bugs.launchpad.net/ubuntu/+source/python-monascaclient/+bug/1590836 also I dropped a message in #ubuntu-devel for someone to promote these packages for the MIR: http://paste.ubuntu.com/17145451/
[15:35] <doko> mehh ... well, updating to the branch then ...
[15:37] <ddellav> I also need python-microversion-parse & python-yaql to be promoted, MIRs are complete and approved: https://bugs.launchpad.net/ubuntu/+source/python-microversion-parse/+bug/1586061 https://bugs.launchpad.net/ubuntu/+source/python-yaql/+bug/1586069 respectively.
[15:40] <coreycb> ddellav, python-monascaclient bug looks good. I subscribed our team to bugs for it.
[15:41] <ddellav> coreycb ok, subscribed the mir team
[15:41] <pitti> cyphermox: can NM be told to create bridges and bonds?
[15:41] <pitti> (I thought it could)
[15:42] <cyphermox> yeah, it can
[15:43] <cyphermox> you in fact have two different ways to do bonds, using the standard method, or using libteam
[15:43] <cyphermox> part of it we may have disabled because it was slightly broken in the past, but it's worth looking at again
[15:50] <smoser> doko, it did block us painfully 2 weeks ago just as it does today. the difference is there is an upstream incorporated fix now.
[15:58] <smoser> well, BDFL responds at https://mail.python.org/pipermail/python-dev/2016-June/144953.html
[15:58] <smoser> i could respond to him and say i should get the prize
[15:58] <smoser> as cloud-init would hit that warning all the time.
[15:59] <pitti> cyphermox: thansk
[16:05] <rbasak> smoser: I think you should reply :)
[16:05] <pitti> smoser: heh, so does autopkgtest :)
[16:05] <pitti> (without the workaround)
[16:07] <nacc> elbrus: do you have any idea what this might be: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/armhf/c/cacti/20160609_124337@/log.gz (cacti regression on armhf with the latest php7.0)
[16:07] <nacc> elbrus: might be a transient timeout, it's hard for me to tell immediately
[16:28] <nacc> rbasak: fyi, i sent a PR to you on github for ubuntu-git-tools: https://github.com/basak/ubuntu-git-tools/pull/2 which will be needed to use the importer
[16:29] <rbasak> nacc: ah yes. I want to just move that all into the importer tree.
[16:29] <rbasak> nacc: sorry I forgot about that. I meant to mention it.
[16:31] <nacc> rbasak: yeah, are you ok if i import it directly (i'll replay the history)
[16:32] <rbasak> nacc: sure. I suggest you create a commit to rename or move it to a subdirectory as necessary, then create a merge commit that pulls in both trees.
[16:32] <rbasak> nacc: no need to replay then.
[16:33] <nacc> rbasak: ack
[16:33] <rbasak> nacc: git-write-tree(1) might help
[16:34] <rbasak> (and then git-commit-tree)
[16:36] <nacc> rbasak: yep
[16:44] <bdmurray> pitti: Do you know why http://autopkgtest.ubuntu.com/packages/t/tgt/wily/armhf/ might have failed?
[16:53] <dosaboy> bdmurray: ping
[16:53] <bdmurray> dosaboy: it's happened already
[16:54] <dosaboy> bdmurray: \o/
[16:55] <dosaboy> bdmurray: sorry to nag but i'm keen to see 1524989 land so I can submit another sru against that package
[16:55] <dosaboy> bdmurray: thanks for taking care of that
[16:56] <bdmurray> dosaboy: you could still upload one and have it wait in the queue until the other one ages
[16:57] <dosaboy> bdmurray: according to https://launchpad.net/ubuntu/+source/python-os-brick it has not yet been copied to -updates
[16:57] <dosaboy> am i missing something?
[16:57] <slangasek> pitti: so AFAICS, your force-skiptest of qtbase-opensource-src/5.5.1+dfsg-17ubuntu2~2 means that plasma-workspace's autopkgtest has been allowed to regress on armhf
[16:59] <bdmurray> dosaboy: I did the right things on my end. http://pastebin.ubuntu.com/17148377/
[16:59] <dosaboy> hmm weird
[17:00] <dosaboy> bdmurray: how long ago was that (assuming you're in a far flung tz)
[17:00] <slangasek> dosaboy: 13 minutes ago (https://launchpad.net/ubuntu/+source/python-os-brick/+publishinghistory)
[17:00] <slangasek> cf "Status: Pending"
[17:00] <dosaboy> slangasek: 10-4 that makes sense then
[17:01] <dosaboy> thanks guys
[17:14] <bdmurray> elbrus: there are no Launchpad-Bugs-Fixed in the .changes file produced by your upload of cacti for xenial.  Is that something you can easily fix?
[17:35] <nacc> rbasak: apologies for my ignorance, is there a good reason I can't just add my fork as a remote, fetch and just merge in my master? It will put everythin in the root directory, but that's ok, right? I can rename some files after the merge so it's clear what they are for (e.g., README -> README.workflow)
[17:48] <rbasak> nacc: I didn't think that would work. If it works then that's great ;)
[17:49] <nacc> rbasak: ok :) it seems to and gitk shows basically shows a git-merge with two histories (one from each master)
[17:49] <rbasak> nacc: that's exactly what I wanted. Thanks!
[17:50] <nacc> rbasak: yep, sounds good, i'll commit
[17:50] <nacc> oh i also found another corner-case bug
[17:50] <nacc> and possibly a conceptual issue for `usd-merge reconstruct`
[17:50] <nacc> i'll send you an e-mail
[17:50] <rbasak> OK
[17:50] <rbasak> nacc: or send to the ML maybe? Up to you.
[17:50] <nacc> rbasak: good point
[17:51] <nacc> rbasak: i'll send to ML and update on the current status (incl. the github -> lp transition).
[17:55] <elbrus> bdmurray: ouch, I made a typo "Lauchpad-Bugs-Fixed: 1588813"
[17:55] <elbrus> I made it on Debian, so I manually change the .changes file
[17:56] <elbrus> bdmurray: can I just reupload?
[17:57] <rbasak> elbrus: I believe you can, and bdmurray can pick up the second upload and reject the first later.
[17:57] <elbrus> rbasak: will try then
[17:58] <elbrus> nacc: yes, I believe that is transient
[17:58] <nacc> elbrus: ok, i'll ask someone to retry that one
[17:58] <elbrus> nacc: but also I can't say from here
[17:58] <elbrus> nacc: the wget command does take a while (downloads ~1500 pages)
[17:59] <rbasak> nacc, elbrus: retry button pressed.
[18:01] <elbrus> rbasak: bdmurray: reuploaded
[18:01] <nacc> rbasak: thanks! we'll ee
[18:15] <elbrus> nacc: looks more like a real regression (or something else going wrong with the server..)
[18:15] <elbrus> nacc: in the artifacs, there is a log.txt.
[18:15] <nacc> elbrus: ok, will look wheni get back from lunch
[18:16] <elbrus> it contains stuff like: HTTP request sent, awaiting response... No data received.
[18:16] <elbrus> 2016-06-03 15:42:44 ERROR 500: Internal Server Error.
[18:17] <elbrus> even serving a simple gif fails (has nothing to do with php (or cacti)
[18:17] <elbrus> eh, ignore my last line, not reading well (too tired I guess)
[18:19] <dannf> doko: wanted to check that you're good with this since it drops a patch you had added: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=808626#55
[18:31] <elbrus> infinity: ginggs: regarding bug 1562480, this may be related to Debian bug 695547 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=695547
[18:35] <doko> dannf, sure, looks fine
[18:35] <dannf> doko: thx
[18:48] <ginggs> doko: hi, do you think can we drop boost1.58 in yakkety? http://people.canonical.com/~ubuntu-archive/transitions/html/html/boost1.60.html i don't think those two build failures are due to boost1.60
[18:53] <dannf> doko: oh, i'll also grab your fix for #819090
[19:02] <bdmurray> elbrus: thanks!
[19:08] <infinity> elbrus: I don't see how they would relate.
[22:42] <nacc> elbrus: hrm, it seems like it started to regress with the older version of php7.0 as well (so not related to php7.0 directly): http://autopkgtest.ubuntu.com/packages/c/cacti/yakkety/armhf/
[22:44] <nacc> what is my best method for reproducing a armhf test failure?
[22:48] <doko> nacc, you should have access to the canonical internal porter boxes
[22:48] <nacc> doko: ack, wasn't sure if that was my best next step or if folks use qemu or anything
[22:49] <doko> nacc, before using qemu, buy a RaspberryPi ;)
[22:49] <nacc> doko: lol
[22:50] <teward> I have an rpi, I'd be happy to flash it, plug it in somewhere, and give you SSH
[22:50] <teward> since this is my parents' net I don't care about lol
[22:50] <nacc> teward: appreciate, let me see if i can figure out how to use the porter boxes first and then i'll get back to you :)
[22:51] <teward> nacc: ack, in the interim I'm flashing Xenial to the thing, but let me know if you need it :)
[22:52] <teward> nacc: assumption: you just need armhf, not specific RPI hardware :P
[22:53] <nacc> teward: yeah, it's a cacti test failure only on armhf (in yakkety)
[22:53] <mwhudson> nacc: two other options, the arm64 porter has armhf chroots on it (and is much faster and more reliable in my experience)
[22:53] <teward> ^
[22:53] <mwhudson> nacc: or spend a few cents with scaleway
[22:54] <nacc> mwhudson: ack, thanks for the tip!
[22:55] <mwhudson> although you can't install yakkety on scaleway so maybe that's not so useful here
[23:52] <nacc> pitti: fyi, i have php-imagick merged, but it will fail to build until I can dh-php installable, which is blocked by php7.0 breaking cacti