[00:37] <samthewildone> watching gremlins 2
[02:31] <Unit193> infinity: So, I'm presuming that even poking you about transitioning openbox from proposeod to release isn't going to happen, due to it being a major upgrade?  (Reason it hasn't transitioned, openbox-kde-session depends on a package that no longer exists, but this is a current problem with the package already in release.)
[02:32] <infinity> Unit193: So, fix the bug?
[02:35] <Unit193> Sure kde-workspace-bin → plasma-workspace would do it, but it'd still be an upgrade from 3.5.2 to 3.6.1 after FF, which at this point since it's seeded in Lubuntu I'm presuming is the problem.
[02:37] <infinity> Unit193: Not a problem.  Uploads to proposed need to beat FF, we're a bit more slack on when they migrate. :P
[02:37] <Unit193> Ahaha.  Nice. :P
[02:38] <infinity> Unit193: Anyhow, the only "problem" with the migration is the installability issue.  Fix that, and it'll be happy.
[02:39] <pitti> Good morning
[02:39] <pitti> hallyn: sounds like debian bug 798778?
[02:39] <ubottu> Debian bug 798778 in systemd "systemd 226's init.scope breaks docker.io 1.7.1~dfsg1-1." [Important,Open] http://bugs.debian.org/798778
[02:39] <Unit193> Howdy, pitti.
[02:39] <infinity> Unit193: For bonus points, do some grep-dctrl on universe/Packages.gz and see if anything else depends on kde-workspace-bin?  If someone ripped it out when it still had rdeps, that's broken. :/
[02:39] <pitti> hallyn: that's certainly the kind of change which could break LXC as well
[02:43] <Unit193> infinity: Only declarative-plasmoids and startactive as far as deps, there's a couple recommends, but meh.
[02:45] <infinity> Unit193: Yeah, don't care about recommends/suggests, but the other broken deps should be sorted too. :/
[02:45]  * infinity goes to look at who's to blame for that.
[02:45]  * Unit193 pretends he did *not* comment at all. >_>
[02:48] <infinity> Bah.  Riddell removed it in vivid.  This has been broken a while.
[02:48] <infinity> Riddell: Psst, you might not want to remove binaries when things still depend on them.
[02:49] <Unit193> :D
[02:51] <hallyn> pitti: hm, i don't think so
[03:43] <pitti> infinity: hm, do you happen to know why gccgo-5 builds all of gcc-5's libraries? that smells bad
[03:43] <pitti> like, you'd use the library depending on which one of gcc-5 or gccgo-5 happens to be higher
[03:52] <infinity> pitti: In wily?
[03:53] <pitti> infinity: and vivid too
[03:53] <infinity> pitti: Only in vivid.
[03:53] <pitti> infinity: I noticed another heap of test requests in http://people.canonical.com/~ubuntu-archive/proposed-migration/vivid/update_excuses.html which are totally in vain
[03:53] <infinity> pitti: Which doesn't have gcc-5.
[03:53] <pitti> infinity: wily too
[03:53] <infinity> pitti: gccgo-5 doesn't exist in wily.
[03:53] <pitti> infinity: but still, it's wrong in vivid too?
[03:53] <infinity> No, it's right in both.
[03:54] <infinity> gccgo-5 in vivid, gcc-5 in wily.
[03:54] <infinity> There's no overlap.
[03:54] <pitti> hm, how does apt-cache showsrc show it then
[03:54] <infinity> --only-source
[03:54] <infinity> showsrc will do binary->source mapping by default.
[03:55] <pitti> oh! go apt
[03:55] <pitti> infinity: thanks
[03:55] <sarnold> why do we still ship the old python-juju? https://bugs.launchpad.net/ubuntu/+source/juju/+bug/1426549
[03:55] <ubottu> Launchpad bug 1426549 in juju (Ubuntu) "drop pyjuju from vivid and newer" [Undecided,New]
[03:57] <infinity> sarnold: No idea.  I know they both coexisted for a long time because $reasons, but I doubt those reasons are valid anymore.
[03:58] <infinity> https://bugs.launchpad.net/ubuntu/+source/juju-core/+bug/1200878 was why it was reintroduced.
[03:58] <ubottu> Launchpad bug 1200878 in juju (Ubuntu) "Upgrade breaks existing pyjuju deployment" [High,Fix released]
[03:59] <sarnold> infinity: it seems unlikely to me that someone would intentionally want the old python juju in wily; if they really needed it, trusty is still there...
[04:00] <infinity> sarnold: Based on the comments on the bug, I'm inclined to agree.
[04:02] <infinity> sarnold: FWIW, no one saw that bug because I suspect the juju team blindly ignores all pyjuju bugs, and you didn't subscribe ubuntu-archive for us to just do the deed.
[04:03] <sarnold> infinity: ah, thanks for the tip.
[04:03] <pitti> @pilot in
=== udevbot changed the topic of #ubuntu-devel to: Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-vivid | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: pitti
[04:03] <sarnold> infinity: thans
[04:03] <sarnold> thanks
[05:35] <pitti> cyphermox: are you still working on bug 1492425, or want me to sponsor it?
[05:36] <ubottu> bug 1492425 in multipath-tools (Ubuntu) "multipath-tools: wily: the quilt patch handle_spaces_in_rev_attr.patch is misapplied" [High,Triaged] https://launchpad.net/bugs/1492425
[08:19] <smb> pitti, how does one recover from testbed failures (http://autopkgtest.ubuntu.com/packages/i/iscsitarget/) ?
[08:21] <pitti> smb: it's fallout from the per-kernel testing I'm currently working on
[08:21] <pitti> smb: I'm handling it, don't worry
[08:22] <smb> pitti, ok, thanks
[09:44] <thopre01> Hi there, which channel should I join to talk to PPA build admins?
[09:45] <thopre01> We (ARM) are providing a PPA for arm-none-eabi toolchain and would like to build it for ARM
[09:45] <thopre01> However it takes quite some time to build there
=== apw is now known as apw_
=== apw_ is now known as cafetiere
=== cafetiere is now known as apw
=== cjwatson is now known as cjwatson_
=== cjwatson_ is now known as cjwatson
[09:52] <cjwatson> thopre01: #launchpad
[09:52] <cjwatson> thopre01: but I can answer you here
[09:53] <cjwatson> thopre01: we have arm64 hardware in progress for an openstack cloud which will be providing virtualised arm (32-bit and 64-bit) builders
[09:54] <cjwatson> thopre01: at the moment, the only option available is qemu-user-static on x86, which is (a) unreliable and (b) slow; can't do anything about that for the present, but hopefully the openstack-based solution is no more than a month or two away now
[10:11] <lotuspsychje> someone knows wich package hold the generic firmwares of a wifi card?
[10:12] <lotuspsychje> i have this card rt2800pci and on offline method it doesn get picked up
[10:12] <lotuspsychje> but on cable it gets the generic firmware of it and works flawless
[10:13] <lotuspsychje> so i was wondering if theres a way to backup generic firmwares to usb somehow?
[10:13] <lotuspsychje> to install it offline
[10:15] <thopre01> cjwatson: Ok thanks
[10:15] <thopre01> We'll wait then
[10:35] <jamespage> pitti, hey - I just commented on the qemu bit of bug 1495895
[10:35] <ubottu> bug 1495895 in qemu (Ubuntu) "Unable to attach rados block device to instances" [High,Confirmed] https://launchpad.net/bugs/1495895
[10:36] <jamespage> I think we do need the dependency otherwise upgrades will likely explode for quite a few cloud deployments :-)
[10:37] <pitti> jamespage: you are worried about people doing dist-upgrade --no-install-recommends? (sounds like a YAFIYGI case to me..)
[10:38] <jamespage> pitti, yes I am worried about that - apparently disabling Recommends install is something that alot of cloud operations like todo
[10:40] <rbasak> smb: I think we're unblocked on my concerns for DPDK upload, so I'm happy for it to be uploaded to universe now. arges: as you reviewed already, please could you sponsor?
[10:40] <pitti> jamespage: hmkay; do we really need the dep on both -common and -utils?
[10:41] <jamespage> pitti, not sure - I'll checking with rharper when he starts
[10:41] <rbasak> smb, arges: oh, my notes from my chat with infinity. If we're depending on libdpdk0 as the ABI isn't well defined we should have a strict versioned dependency instead of just generally on "libdpdk0". And the symbols file should be arranged to fail the build if the symbols change (I think we have that already?)
[10:41] <pitti> and I figure changing the package description is overzealous (breaking translations and permanent delta, etc.)
[10:42] <pitti> jamespage: but okay, if you want a strict Depends: I can sponsor that
[10:42] <rbasak> Actually the strict versioned dependency on libdpdk0 should be on ovs I think. jamespage ^
[10:42] <rbasak> (as it's consuming it)
[10:42] <jamespage> pitti, I'm happy to sponsor - just wanted you to know why we need it
[10:42] <pitti> jamespage: ah, ok
[10:42] <smb> rbasak, cool. Hm, the symbols file is there at least. I believe that will cause the failure. The stricter dependency I would have to add
[10:43] <rbasak> smb: actually the stricter dependency is on jamespage's end I think.
[10:43] <smb> rbasak, ok... not sure how struct the aut generated ones are for other binaries produced
[10:43] <jamespage> rbasak, well that will be driven in the normal way by shlib:Depends so it will generate libdpdk0
[10:44] <smb> migth be already strict
[10:50] <rbasak> jamespage: yes but the point is that it should be strictly versioned to the version of the libdpdk0 package, since a libdpdk0 package update might change the ABI.
=== marcusto_ is now known as marcustomlinson
[11:34] <tkamppeter> hi, I have a problem with bug 1449875. I could fix it by adding a dependency to Ghostscript but the new dependency recommends tons of unneeded packages. Do all these get installed then, too?
[11:34] <ubottu> bug 1449875 in ghostscript (Ubuntu) "ghostscript fails on some EPS files" [Undecided,Confirmed] https://launchpad.net/bugs/1449875
[12:33] <Mirv> chrisccoulson: any chance to look at the bug #1482219? if Firefox 41 is released next week, all users including LTS users will lose the spell-checking. if you know what needs to be done, you could inform the upstream about what they still need to do.
[12:33] <ubottu> bug 1482219 in mozvoikko (Ubuntu) "xul-ext-mozvoikko isn't signed (cannot be loaded on Mozilla Firefox 41.0a2)" [High,Confirmed] https://launchpad.net/bugs/1482219
[12:34] <Mirv> chrisccoulson: I see the signed .xpi file has "META-INF" compared to the normal upstream tarball. maybe that can be used by the packaging, or how was the ubufox fixed?
=== ChrisTownsend1 is now known as ChrisTownsend
[13:24] <Mirv> chrisccoulson: it seems I figured it out, although I may not know what I'm doing.
[13:24] <Mirv> chrisccoulson: if you're there, are you available for sponsoring https://code.launchpad.net/~timo-jyrinki/ubuntu/wily/mozvoikko/new_upstream_signed_release/+merge/271643 + for vivid, trusty and precise?
[13:25] <Mirv> it's a main package
[13:25] <Mirv> (and I'm only a MOTU)
[14:18] <Mirv> ok, as chrisccoulson is not here, if any other core-dev can, please check the sponsoring queue and/or bug #1482219 MP:s. PPA builds available from the latest commits, and I've tested 14.04 LTS and 15.10.
[14:18] <ubottu> bug 1482219 in mozvoikko (Ubuntu) "[SRU] xul-ext-mozvoikko isn't signed (cannot be loaded on Mozilla Firefox 41.0a2)" [High,Confirmed] https://launchpad.net/bugs/1482219
[14:19] <Mirv> the problem here is that new Firefox comes next week already and SRU:s will take at least 7 days. only ubufox has been fixed to not break when the new Firefox comes.
[14:21] <Mirv> the sponsoring queue does not show it but there's the precise branch too
[14:29] <pitti> @pilot out
=== udevbot changed the topic of #ubuntu-devel to: Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-vivid | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
=== hggdh is now known as hggdh_
=== hggdh_ is now known as hggdh__
=== hggdh__ is now known as hggdh
[15:13] <Unit193> infinity: Also, https://launchpad.net/~unit193/+archive/ubuntu/staging/+sourcepub/5397648/+listing-archive-extra - http://paste.openstack.org/show/3qkwEuusUcN7Yjqohn78/ :P
[15:35] <hallyn> xnox: did you have any comments on http://mentors.debian.net/debian/pool/main/n/netcf/netcf_0.2.3-4.2.dsc ?
[15:36] <xnox> hallyn: http://mentors.debian.net/package/netcf is better url.
[15:36] <xnox> hallyn: still wrong version, should be 0.2.3-5
[15:36] <hallyn> wtf?  i changed that
[15:36] <xnox> you are maintainer now, right?
[15:36] <hallyn> oh, i used the wrong link :)
[15:36] <xnox> i see that there -5 upload as well
[15:36] <xnox> horum.
[15:36] <xnox> http://mentors.debian.net/package/netcf
[15:36] <hallyn> thought i'd deleted that other one
[15:36] <hallyn> and now i've deleted the whole thing
[15:37] <xnox> hallyn: never mind, the -5 one looks great.
[15:37] <xnox> hallyn: horum. well, reupload -5 again please =)
[15:37]  * hallyn re-dputs
[15:37] <xnox> hallyn: it was lovely for the whole 3 seonds
[15:37] <hallyn> should take about 30s to show up
[15:39] <hallyn> ... or longer
[15:43] <hallyn> xnox: well while mentors chews on it, http://people.canonical.com/~serge/netcf_0.2.3-5.dsc  (but that doesn't give you lintian output :( )
[15:55] <hallyn> xnox: https://mentors.debian.net/package/netcf is back up
[16:58] <chrisccoulson> Mirv, has mozvoikko had a preliminary review by the AMO team, or a full review? Normally, addons only require a preliminary review to be loaded in Firefox, but side-loaded addons (those not installed via the addon manager) require the more thorough full review
=== dpm is now known as dpm-afk
[16:59] <chrisccoulson> tbh, it would be better if this addon was just hosted on AMO like most other addons. The only reasons this one remained in the archive when we dropped all of the other Firefox extensions were that it wasn't hosted on AMO, and contained a binary component
[16:59] <chrisccoulson> The latter doesn't apply now (the addon is all JS)
[17:05] <infinity> tdaitx: https://launchpad.net/~adconrad/+archive/ubuntu/ppa/+build/7918795
[17:05] <infinity> tdaitx: So, no, glibc 2.22 doesn't fix squid's sadness.
=== mako_ is now known as mako
[17:06] <tdaitx> infinity, I was afraid of that =/
[17:08] <infinity> tdaitx: Might be fixed in git by jsm already.
[17:10] <chrisccoulson> Mirv, so, that mozvoikko hasn't been through a full review and Firefox refuses to load it here when installed via the package manager
[17:54] <infinity> tdaitx: If you were curious about the merge, for educational purposes, it's in ppa:adconrad/ppa
[17:55] <tdaitx> infinity, sweet, thanks =)
[18:37] <Mirv> chrisccoulson: ok. but how would it be part of Ubuntu's default language support if it'd not be in the archives?
[18:37] <Mirv> until that's possible, there's a reason to keep it in archives since otherwise the majority of normal users would simply notice no spell-checking available
[18:38] <Mirv> as extensions are not really familiar to most of average users
[18:38] <Mirv> chrisccoulson: thanks for the preliminary/full review information, I'll rely that to the upstream so that they can see what they can do about it
[18:42] <Mirv> chrisccoulson: if you have the correct PPA with Firefox to use for testing, please tell. I used 41.0~b9 from firefox-next and I got a warning about the new mozvoikko (and for some reason ubufox too) in the extensions dialog, but it still loaded and worked. on Firefox 40 using the packaged mozvoikko as well from the voikkotest2 PPA, I did have no warning anymore so that combination was puzzling me. proba
[18:42] <Mirv> bly just the wrong Firefox test version to use.
[18:44] <sarnold> Mirv: firefox 40 didn't have the signed requirements... chrisccoulson put some details in 1482219
[18:46] <Mirv> sarnold: I know it didn't require, but the warning 40 already showed went away with this new version with signing included
[18:47] <Mirv> so that's why I was puzzled when comparing to the 41 (or 42 dev edition locally unpacked). but it may be I'm using a wrong Firefox test version here, not something that will be distributed to the users.
[18:47] <Mirv> chris certainly knows the best, so I believe the full review here would be the way to go to have an archive version that continues to work after next week's Firefox release
=== samthewildone is now known as blackbat
=== blackbat is now known as gingermousekille
=== gingermousekille is now known as MFDOOM
=== MFDOOM is now known as samthewildone
[22:00] <samthewildone> lol