=== salem_ is now known as _salem
=== _salem is now known as salem_
=== salem_ is now known as _salem
[03:05] <tjaalton> jderose: yo, still there?
[07:37] <pitti> flexiondotorg: it's okay, NEW delays aren't taken into account for FF
[09:44] <Riddell> cjwatson: you say I can update packagekit up to some version?
[09:55] <cjwatson> Riddell: 1.0 will break click until mvo gets round to landing that branch
[09:55] <cjwatson> I know not where that stands
[09:56] <Riddell> mvo: hola, where do you stand? I can update to 0.9 I think should be enough for what I need (my gsoc project to install bits) but obviously latest would be nicer
[09:57] <mvo> Riddell: at debconf right now, I can try to get to it next week but time is very limited currently due to other duties, the branch should basicly be ready, its missing tests and some more manual testing
[09:57] <Riddell> mvo: groovy, I'll see if I can update to 0.9 to make feature freeze then we can test your stuff next week
[09:58] <Laney> Riddell: to make feature freeze?
[09:58] <Laney> it was yesterday
[09:59] <Riddell> ah, hmm
[09:59] <Riddell> oops :)
[09:59] <Laney> Happy to see you guys appstreaming though as I'm kind of interested in that stuff for us too
[09:59] <Laney> ximion showed me appstream.kubuntu.co.uk
[10:00] <Riddell> Laney: yeah I need to chat to him about what the next steps are for that
[10:00] <Laney> PPAs seem a bit hard
[10:00] <Laney> I guess you care about that too
[10:01] <Riddell> mm, I've not through about that
[10:02] <Laney> think it will need some kind of LP integration
[10:02] <Laney> even if that's a dispatch/collect job or something
[10:02]  * Laney doesn't really know
[10:08] <rbasak> sil2100: I'll sponsor your patch in bug 1471903 if there isn't any further objection. ogra_, do you have any other comment in response to bdmurray's response?
[10:08] <ubottu> bug 1471903 in live-build (Ubuntu) "-updates, -security missing from apt lists" [High,In progress] https://launchpad.net/bugs/1471903
[10:08] <ogra_> rbasak, you mean beyond asking to wait for signoff from the product team (pat mcgowan is back on monday) ?
[10:09] <sil2100> rbasak: hey! Thanks, no, I didn't hear anything new... also, infinity seemed to be in favour of the same change as well
[10:09] <rbasak> ogra_: signoff for what reason?
[10:09] <ogra_> rbasak, note that mako already has probs installing from scratch today due to the smaller cache size
[10:10] <ogra_> rbasak, the product team usually makes all size related decisions for these images
[10:10] <sil2100> ogra_: this can basically land to wily now anyway, the PT will decide if we want the change in the stable images or not
[10:11] <sil2100> Since this is not only about the phone images but all images everywhere
[10:11] <ogra_> sil2100, well, you deal with the support in #ubuntu-touch for mako users then :P
[10:11] <sil2100> uh oh, we recommend using rc images for mako as well!
[10:11] <rbasak> ogra_: so you're saying that I can't upload any bugfix that will increase size without product team approval? I realise this is a bit special, but that doesn't sound reasonable in the general case for me.
[10:12] <ogra_> i'm not really fond of bypassing the product team with that one, but up to you
[10:12] <ogra_> rbasak, for the phone images they are our consumer and need to make sure what we pdoruce fits on the vendors devices
[10:12] <ogra_> *produce
[10:13] <ogra_> if we add bits to the seed of the phones we usually coordinate with them
[11:07] <rbasak> ScottK: around? I'm reviewing kickinz1's merge of amavisd-new and am a bit confused about debian/22-amavisd-new-postfix. It doesn't seem to be used or end up in a binary package in the current version in Wily. kickinz1 has moved it to debian/etc/conf.d/ where I think it will get used. Does this sound right to you?
[11:08] <rbasak> I wonder if Debian restructured debian/ and this part of the delta got left behind or something. But clearly if we do this the binary package delta will change from the user's perspective. Maybe this is an accidentally disappeared confflie from the past?
[11:08] <rbasak> Or should it ship with amavisd-new-postfix only?
[11:09] <rbasak> ivoks: ^^ looks like you touched this back in the day. Any ideas please?
[11:09] <ivoks> checking
[11:11] <ivoks> without looking at the source
[11:11] <ivoks> 22-amavisd-new-postfix should be amavisd-new-postfix's amavis configuration
[11:11] <ivoks> it should ship only with amavisd-new-postfix package
[11:12] <rbasak> OK, thanks
[11:12] <ivoks> but, i haven't touched this in 5 years :)
[11:12] <rbasak> Where should amavisd-new-postfix drop that file when installed?
[11:12] <ivoks> where other amavis' configuration is. iirc that's /etc/amavis/conf.d
[11:13] <rbasak> OK that makes sense.
[11:13] <ivoks> looking at source
[11:14] <ivoks> hm
[11:14] <ivoks> that file was never utilized
[11:14] <rbasak> I wonder how that got lost though. Seems unlikely that amavisd-new-postfix.install would get lost in a merge.
[11:14] <ivoks> at least not in 14.10
[11:14] <ivoks> er 15.04
[11:14] <rbasak> Yeah - hence my confusion
[11:14] <ivoks> that file enables antispam and antivirus functionality :D
[11:15] <ivoks> without it amavisd-new-postfix is not very useful
[11:15] <ivoks> but
[11:15] <rbasak> Nor is it in Precise.
[11:15] <ivoks> hm
[11:15] <ivoks> maybe default changed
[11:15] <ivoks> give me a second
[11:15] <rbasak> Thanks
[11:16] <ivoks> it didn't
[11:17] <ivoks> yeah, i built that in 2010
[11:17] <ivoks> but has been merged few times since then
[11:20] <ivoks> rbasak: bottom line, it needs to be shipped with amavisd-new-postfix, in /etc/amavisd/conf.d/
[11:20] <ivoks> rbasak: but you might want to double check with ScottK
[11:21] <rbasak> OK, thanks.
[11:21] <ivoks> didn't help you there :)
[11:21] <rbasak> kickinz1: ^^
=== marcusto_ is now known as marcustomlinson
[11:21] <rbasak> Well, it's nice to know that someone knows what's going on here.
[11:21] <rbasak> IMHO, we should retire the deltas relating to mail-delivery-stack etc.
[11:21] <rbasak> But that's a discussion for another day.
[11:22] <ivoks> idea behind m-d-s was to have single packet that will set 'best practices' for mail server
[11:22] <ivoks> at first, amavisd-new-postfix was not included in that because antispam and antivirus functions impact mail delivery
[11:23] <rbasak> Yeah. Trouble is that it tries to shoehorn both service orchestration and configuration management into packaging, which doesn't really work well IMHO. Made sense at the time, but we have better tools nowadays.
[11:23] <ivoks> and when you go into realm of not delivering an email for some reason, then you need to be sure you have no false positives (which is impossible)
[11:23] <ivoks> yeah, i get that
[11:23] <rbasak> I'd like to see all this stuff implemented into charms and then pulled out of packaging.
[11:24] <rbasak> (in all that free time I have)
[11:24] <ivoks> i did start that effort long time ago
[11:24] <ivoks> never finished it :/
[11:35] <ScottK> rbasak: it's been even longer for me the ivoks since I touched it.  The mail stack stuff is unmaintained for a very long time. I agree about dropping it.
[11:38] <ivoks> there you go
[11:41] <rbasak> ScottK, ivoks: OK, thanks. For this cycle, I think maybe we can merge without changing anything from what is there already - so let's not ship 22-amavisd-new-postfix at all just like we weren't doing before since that won't regress anyone.
[11:41] <rbasak> We can talk about dropping this stuff next cycle.
[11:41] <ivoks> yeah, it should be announced
[11:42] <ivoks> and before we drop it, at least have a replacement strategy
[11:42] <rbasak> kickinz1: ^^
[11:42] <ivoks> juju this and that to get it like you had
[11:42] <ivoks> for that we need charms
=== _salem is now known as salem_
=== Tm_Tr is now known as Guest13976
[12:51] <dholbach> tkamppeter, do you know who can take a look at https://bugs.launchpad.net/hplip/+bug/1486732?
[12:51] <ubottu> Launchpad bug 1486731 in HPLIP "duplicate for #1486732 hplip-3.15.7-plugin.run doens't return" [Undecided,Confirmed]
[12:51] <dholbach> I'm seeing the same thing
[13:17] <jderose> tjaalton: was off to bed, but here now :)
[13:35] <jcastro> ivoks: wrt. charming the mail stack, I can put it on our team's wishlist, is your code pushed to the store?
[13:46] <ivoks> jcastro: let me take a look
[13:46] <ivoks> jcastro: ah, now i remember
[13:46] <ivoks> at that time charms were unable to fetch information that was required to do this
[13:47] <ivoks> https://code.launchpad.net/~ivoks/charms/precise/mail-stack-delivery/trunk
[13:47] <ivoks> i think the problem was the fact that juju was unable to tell me which node departed
[13:47] <ivoks> so, i was suposed to come up with a workaround for which i had no time then
[13:48] <jcastro> ivoks: I'll toss it on our list, can't promise everything, but it'd be nice to provide that for people
[13:51] <ivoks> jcastro: ok
[14:04] <tkamppeter> dholbach, the two bug reports are for Arch Linux, but I contacted the HP guys directly anyway.
[14:05] <dholbach> tkamppeter, thanks
[15:01] <tjaalton> jderose: ah, nothing special, just that skl on wily needs work on the kernel still
[15:03] <jderose> tjaalton: ah, right.  so was i correct that this patch set you proposed is why skylake is shiny on Vivid, Trust+Vivid HWE and badly broken on Wily?
[15:04] <tjaalton> it only fixes a known gpu hang and probably prevents some others
[15:04] <tjaalton> you need to give i915.preliminary_hw_support=1 to actually use the kernel module
[15:07] <jderose> tjaalton: ah, thanks, great tip! i did notice that kms doesn't seem to be used on Wily... so the horrible GPU performance is actually because the GPU isn't used at all?
[15:07] <tjaalton> right
[15:07] <jderose> okay, that's very helpful. means i can do reasonable testing in the mean time :D
[15:08] <tjaalton> yep
[15:21] <jderose> tjaalton: if you don't mind my asking, what's your assessment of Ubuntu on skylake hardware overall? any show stopping issues?
[17:20] <ejat> anyone can explained why there is 153 packages not upgrade ?
[17:20] <ejat> http://paste.ubuntu.com/12142510/
[17:21] <cjwatson> dist-upgrade not upgrade
[17:22] <cjwatson> upgrade on its own is only very slightly useful, especially when we're in the middle of a C++ transition requiring a bunch of library packages to be renamed
[17:22] <ejat> cjwatson: if i do dist-upgrade .. there is 97 to remove and 5 not upgraded.
[17:22] <cjwatson> yes, you have to inspect the list to be removed
[17:22] <cjwatson> feel free to pastebin that
[17:23] <cjwatson> (well, the full output)
[17:23] <ejat> http://paste.ubuntu.com/12142547/
[17:23] <ejat> scary after doing the inspection
[17:24] <cjwatson> so a lot of those are correct but there's evidently something up with libreoffice
[17:24] <cjwatson> I mean, the libraries, those are basically just swapping existing ones out for v5 variants
[17:25] <ejat> owh ..
[17:25] <ejat> so ok for me to proceed removing all that 97 ?
[17:25] <cjwatson> no
[17:25] <cjwatson> "there's evidently something up with libreoffice"
[17:25] <ejat> owh .. okie .. sorry bout it ..
[17:26] <ejat> what should i do know ?
[17:26] <ejat> file a bugs ?
[17:26] <cjwatson> pastebin 'apt-get -oDebug::pkgProblemResolver=true dist-upgrade'
[17:27] <cjwatson> also make sure that you only have wily in sources.list, not wily-proposed
[17:28] <cjwatson> pitti: language-pack-kde-{ia,wa} are uninstallable in wily - missing -base and non-kde packages by the looks of it?
[17:30] <ejat> cjwatson: http://paste.ubuntu.com/12142592/
[17:31] <ejat> no proposed
[17:32] <cjwatson> ejat: I suspect you have some old package installed that it doesn't want to remove for some reason, since our analysis tools say libreoffice is installable in wily.  What does 'apt-get -oDebug::pkgProblemResolver=true install libclucene-core1v5' say?
[17:33] <willcooke> g'night all
[17:34] <cjwatson> Investigating (0) libstreamanalyzer0v5 [ i386 ] < none -> 0.7.8-1ubuntu5 > ( libs )
[17:34] <cjwatson> Broken libstreamanalyzer0v5:i386 Conflicts on libstreamanalyzer0 [ i386 ] < 0.7.8-1ubuntu2build1 > ( libs )
[17:34] <cjwatson>   Considering libstreamanalyzer0:i386 103 as a solution to libstreamanalyzer0v5:i386 0
[17:34] <cjwatson>   Holding Back libstreamanalyzer0v5:i386 rather than change libstreamanalyzer0:i386
[17:34] <cjwatson> I think that's where it starts going wrong
[17:35] <ejat> cjwatson: http://paste.ubuntu.com/12142634/
[17:36] <cjwatson> I wonder why libstreamanalyzer0 has such a high score
[17:37] <ejat> is it only me who face it ? or got some others reporting it too ?
[17:38] <zul> mterry: ping
[17:40] <mterry> zul, hello
[17:41] <zul> mterry: im just looking at the python-pymysql MIR, the server team is subscribed to the bug report, however the debian bug report, the reason why the test is failing in the debian bug is because mysql not installed
[17:41] <cjwatson> ejat: please could you create a tarball of /var/lib/apt/, /var/cache/apt/, and /var/lib/dpkg/, and attach it to a new bug against Ubuntu apt along with the debug output from dist-upgrade above?  I've spent as much time on this as I can for a Friday evening, but it smells like an apt bug to me, it's odd that it doesn't seem to be preferring libstreamanalyzer0v5 over the non-v5 version
[17:42] <cjwatson> with such a tarball it should be possible to recreate the bug elsewhere
[17:42] <mterry> zul, I was also seeing the failure locally.  Is there a missing build-dep then?
[17:43] <zul> mterry: other than mysql not being installed
[17:43] <zul> mterry: there isnt afaik
[17:44] <mterry> zul, maybe I'm missing something, but "mysql not being installed" sounds like a missing Build-Depend?
[17:44] <zul> mterry: yeah mysql
[17:45] <zul> mterry: ill see what i can do
[17:48] <ejat> can upload such big file /var/cache/apt/ to launchpad?
[17:49] <ejat> cjwatson: ?
[17:59] <anna__> I get this: Skipping dist/deb_dist/nuitka_0.5.14~pre9+ds-1_amd64.changes: Can't locate Date/Parse.pm in @INC (you may need to install the Date::Parse module)
[18:00] <anna__> Any idea, why all my pbuilders starting doing that recently? The package libtimedate-perl appears to be installed... so that's strange
[18:11] <ejat> cjwatson: bug #1487569
[18:11] <ubottu> bug 1487569 in apt (Ubuntu) " a lot of files to be removed when execute apt-get dist-upgrade" [Undecided,New] https://launchpad.net/bugs/1487569
[18:46] <tjaalton> jderose: not at all.. it should be pretty stable, but the display side is lacking. new bios code can break current modesetting etc..
[18:57] <jderose> tjaalton: gotcha, thanks. and thanks for the FYI about bios being able to break kms, very good to know.
[19:30] <jderose> tjaalton: when you say new bios can break KMS... do you mean newer Intel video bios?
[19:57] <mterry> bdmurray, FYI, ~ubuntu-server is looking after bandit package in main now
[21:00] <tjaalton> jderose: right
[21:01] <jderose> tjaalton: gotcha, thanks!
=== salem_ is now known as _salem
=== _salem is now known as salem_
=== salem_ is now known as _salem
[23:19] <slangasek> mdeslaur: I'm doing some cleanup of the edk2 package, including providing OVMF_{CODE,VARS}.fd as split files which is apparently what's needed for proper per-VM EFI variable support.  However the virt-manager we have doesn't appear to have proper integration with this (though our libvirt does).  You don't happen to have any prerelease packages based on the 1.2.0 virt-manager in Debian experimental,
[23:19] <slangasek>  do you?
[23:20] <mdeslaur> slangasek: I don't, no
[23:20] <mdeslaur> slangasek: I can look at this next week if you'd like
[23:20] <slangasek> mdeslaur: ok.  I may just upload this untested then, since it's backwards-compatible with what we're currently doing and somebody else can figure out the new stuff
[23:20] <slangasek> mdeslaur: that would be keen but it's by no means high priority