[00:38] <nacc> bdmurray: where does 'DpkgHistoryLog.txt' come from normally?
[00:38] <nacc> bdmurray: as in what file from the local user's system, or what command generates it?
[00:45] <nacc> slangasek: i was collecting/perusing the bugs we've gotten on php7.0 with failed upgrades. I think in all cases where we see the debconf backtrace ("Use of uninitialized value $reply in scalar chomp at /usr/share/perl5/Debconf/FrontEnd/Passthrough.pm line 66"), the invocation is from aptdaemon and running apt manually at the terminal fixes it. Is aptdaemon used only by update-manager? Or is it used
[00:45] <nacc> eventually by all of the various tools?
[00:46] <slangasek> nacc: only by update-manager
[00:46] <nacc> slangasek: ok, good to know
[00:46] <slangasek> maybe some other GUI frontends, but certainly not from apt on cli
[00:47] <nacc> slangasek: i tried to reproduce it in a VM and I was unable to in a few attempts, so i'm just trying to think of different approaches
[00:47] <slangasek> I seem to regularly hit it here on my laptop whenever I apply updates but have not had the patience to debug it
[00:48] <nacc> slangasek: ok, that's good to know -- and do you see it for multiple packages? I can leave this VM around and see if it triggers it eventually
[00:49] <slangasek> nacc: I see it for any package that uses debconf in its maintainer scripts, regardless of whether that would have triggered a debconf prompt to be displayed.
[00:49] <nacc> slangasek: interesting
[00:51] <slangasek> this includes kernel upgrades :P
[00:51] <slangasek> (which is why I don't have much patience for debugging it)
[00:51] <nacc> slangasek: and that would correspond to what we see as this seems to trigger for some people on the MRE SRUs, where no debconf prompts should occur
[01:05] <bdmurray> nacc:  $ grep DpkgHistory /usr/share/apport/package-hooks/*
[01:06] <bdmurray> nacc: /var/log/apt/history.log so its incorrectly labelled
[01:06] <nacc> bdmurray: thanks!
[06:47] <cpaelzer> good morning
[06:47] <rbasak> o/
[08:16] <ogra_> mdeslaur, i didnt modify anything on purpose, what happened ?
[08:41] <rbasak> chrisccoulson: any opinion on bug 1632870 please?
[09:35] <cpaelzer> rbasak: I was reading the bug you linked and I'm puzzled
[09:35] <cpaelzer> rbasak: I think I get all what was outlined there on pepperflashplugin-nonfree vs partner based adobe-flashplugin
[09:36] <cpaelzer> rbasak: but I'm missing one bit (surely out of ignorance on the history of flash plugins)
[09:36] <cpaelzer> rbasak: but what I did for years is install flashplugin-installer - how does that fit into the puzzle there?
[09:37] <cpaelzer> note: I'm still reading through all the length of this
[09:37] <cpaelzer> if it is down somewhere
[09:39] <cpaelzer> rbasak: found it at about 60% of the bug - that is from ubuntu-restricted-addons
[09:47] <cpaelzer> rbasak: wow, that is a complex maze in this bug - your current question is for your SRU duty to consider accepting them into proposed or not?
[10:07] <LocutusOfBorg> pitti, hi, sync systemd from experimental? :p
[10:07] <LocutusOfBorg> btw seems that you are fixing the autopkgtest failures, right? I see activity con git
[10:16] <rbasak> cpaelzer: yeah, I thought chrisccoulson might be an appropriate person to review or comment as he usually uploads adobe-flashplugin.
[10:16] <rbasak> But it does look entirely appropriate for an SRU to me. We shipped the package, it's broken, we should fix it.
[10:17] <rbasak> And decisions about what to recommend or remove should probably be limited to the development release.
[10:17] <rbasak> (where possible)
[10:20] <cpaelzer> rbasak: yeah my opinion (very unimportant) would also to fix it especially as it is a security issue
[10:21] <cpaelzer> rbasak: removing in relase - no-no, removing in zesty or later devel maybe, but even there I don't see the full reason
[10:21] <cpaelzer> rbasak: there are more things which have multiple possible implementations
[10:21] <rbasak> Thanks. I'm definitely +1 on fixing it. I'm asking chrisccoulson in case he has any comment or suggestion on the approach taken.
[10:21] <cpaelzer> rbasak: OTOH (for the furture removal in devel) I agree that a removal might simplify this mess at least a bit
[10:22] <rbasak> Because as you point out, it's a pretty complex area right now :-/
[10:22] <cjwatson> jbicha: thanks for the icoutils sync - had been going to do that this morning :)
[10:22] <cpaelzer> rbasak: sure, waiting for chrisccoulson is better
[10:22] <cpaelzer> rbasak: yet I didn't want to leave your open question for opinions end up totally unconsidered :-)
[10:24] <pitti> LocutusOfBorg: I won't sync it for zesty (feature freeze); if someone wants it and wants to do the FFE, be my guest of course :)
[10:25] <pitti> LocutusOfBorg: I'm only aware of the root-unittests failure on armhf, talked about that with xnox yesterday (no hw access any more, so can't reproduce/investigate myself)
[12:07] <mdeslaur> ogra_: our techboard meeting keeps getting modified when people modify other meetings on the phone
[12:07] <mdeslaur> ogra_: I assume you meant to modify something else
[12:21] <chrisccoulson> rbasak, I don't really have an opinion on pepperflashplugin-nonfree, and that bug is quite long (I've not read the whole thing)
[12:22] <chrisccoulson> ideally the package wouldn't exist at all (flashplugin-installer exists so that ubuntu-restricted-addons can recommend it)
[12:22] <rbasak> chrisccoulson: that's fine, thank you for looking. I just wanted to check if you had an opinion :)
[12:22] <rbasak> chrisccoulson: OOI, how do adobe-flashplugin and flashplugin-installer fit together?
[12:23] <chrisccoulson> in fact, I think it's fairly bad that we have a flash plugin installer in the archive that requires users run a command outside of the normal update process to upgrade it
[12:24] <rbasak> I wasn't clear on why that is.
[12:24] <chrisccoulson> I wonder whether I should just add the ppapi plugin to flashplugin-installer - it has to download it anyway
[12:45] <tjaalton> doko: llvm 4 & snapshot ftbfs on powerpc, but build fine on debian.. https://launchpadlibrarian.net/305798779/buildlog_ubuntu-zesty-powerpc.llvm-toolchain-4.0_1%3A4.0~+rc2-1_BUILDING.txt.gz
[12:58] <tjaalton> doko: any ideas if it's a bug in llvm or something else?
[13:31] <doko> tjaalton: no, I didn't look. and we'll drop powerpc this cycle
[13:31] <doko> should have happened in Feb afaik
[13:33] <tjaalton> ahh
[13:33] <tjaalton> ok
[13:33] <tjaalton> forgot about that
[14:15] <handsome_feng> jbicha, hi, what do you mean by tagged the wrong commit? The last commit is "Remove the debian/ directory" in ukui-menu.
[14:17] <jbicha> handsome_feng: hi!
[14:18] <jbicha> https://github.com/ukui/ukui-menu/releases shows that you tagged 0f027ad but that's not the last commit
[14:18] <jbicha> https://github.com/ukui/ukui-menu/commits/master
[14:20] <handsome_feng> I remove the previous releases and update it, since it has the same tag "v1.0.0", and then it shows 10 commits to master since this release...
[14:21] <jbicha> handsome_feng: you could use a new tag like 1.0.1?
[14:23] <handsome_feng> jbicha, I have updated the release just now, :)
[14:32] <jbicha> handsome_feng: thanks, can I upload to zesty from https://github.com/ukui/debian-packages/tree/master/ukui-menu/debian now?
[14:33] <handsome_feng> jbicha: sure! thank you!
[14:39] <jackpot51> cyphermox: jbicha: happyaron: Can we talk about the patch to network-manager-applet? It is a single line change to src/libnma/Makefile.am which fixes the ability to use libnma from Python
[14:39] <cyphermox> jackpot51: don't need to discuss this, let's jfdi ;)
[14:40] <jackpot51> awesome - then Zesty's installer won't crash for students at university, or corporate customers
[14:40] <jackpot51> XD
[14:40] <cyphermox> well, it already shouldn't crash, no?
[14:40] <jackpot51> It crashes on any WPA 2 enterprise network
[14:41] <jackpot51> My patch to ubiquity fixes that crash by implementing WPA 2 enterprise
[14:42] <cyphermox> afaik that doesn't crash, it just doesn't work
[14:42] <cyphermox> (well, it doesn't work if you try to use the network panel in ubiquity, you already could use nm-applet directly instead
[14:42] <jackpot51> It will say something like "Installer has crashed. Entering recovery mode" and then go to a desktop
[14:42] <cyphermox> ok
[14:43] <jackpot51> There is no try...except around connecting to the Wifi network, so a DbusException from network manager is uncaught
[14:44] <jackpot51> My patch adds the try..except block in the gtk and kde components, as well as using libnma to support WPA 2 enterprise in gtk components
[14:44] <jackpot51> Line 63 here: https://git.launchpad.net/~network-manager/network-manager/+git/ubuntu-applet/tree/src/libnma/Makefile.am#n63
[14:44] <jackpot51> Needs to change to this: NMA_1_0_gir_INCLUDES = NM-1.0 Gtk-3.0
[14:48] <jackpot51> cyphermox: What do I need to do to "jfdi"? :P
[14:48] <cyphermox> nothing, I have your patch I'll upload it
[14:48] <jackpot51> Thanks very much!
[14:50] <jbicha> cyphermox: thanks
[14:51] <spacebear> hi is their any ubuntu devs around
[14:52] <dobey> usually, that's what this channel is
[14:53] <spacebear> I've been directed to the right place ty
[18:46] <salty-horse> hey. ibus seems broken in zesty (can't switch back from layout after changing it). is it officially being phased out?
[18:57] <jbicha> salty-horse: no
[18:59] <salty-horse> jbicha, is any integration done by ubuntu developers, or should I take it up with the ibus team?
[19:02] <jbicha> salty-horse: start with a Launchpad bug, but if you think the issue is upstream you can try talking to them too
[19:31] <nacc> rbasak: found a few issues with the -devel pointer changes, testing them now
[23:16] <nacc> slangasek: been doing some digging, cjwatson's comment 10 in LP: #500175 is interesting
[23:16] <nacc> i think it's the most detailed analysis i've found so far
[23:18] <nacc> cjwatson: in case you're interested, context is LP: #1597001 and several php7.0 bugs with the same symptom (all using update-manager)
[23:58] <nacc> rbasak: awesome, so nice to be able to verify i didn't break anything by my fixed changes now
[23:58] <nacc> rbasak: so i just compared a from-scratch import of tftp-hpa to what is already pushed by you
[23:59] <nacc> rbasak: all the series branches match and the devel pointers are different (because they now have a merge-based history)