=== vrruiz_ is now known as rvr
[06:15] <darkxst> @pilot in
=== udevbot changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: darkxst
[07:47] <mitya57> Trevinho, hi, so are you still going to do a libwnck upstream release?
[07:58] <dholbach> good morning
[08:42] <caribou> We don't support direct upgrades from Precise to Xenial, right ?
[08:47] <rbasak> caribou: correct. Must go via Trusty.
[08:47] <caribou> rbasak: thanks
[09:31] <ginggs> doko, can you remove the armhf binary for julia 0.4.2-3 please? it is holding up the suitesparse transition. i don't yet know why 0.4.3 FTBFS on armhf in ubuntu (debian is fine), and 0.4.2-3 now also FTBFS on  armhf.
[09:37] <darkxst> @pilot out
=== udevbot changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
[09:43]  * dholbach hugs darkxst
[09:48] <Trevinho> mitya57: hi, yes... I'll do that soon
[09:48] <darkxst> dholbach, np ;)
[09:51] <seb128> darkxst, btw that font/seed bug, it has an approved MIR
[09:51] <seb128> you commented saying it needs one
[09:53] <mitya57> Trevinho, ta
[09:53] <darkxst> seb128, yeh saw aaron's comment
=== tepper.freenode.net changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: darkxst
=== cpaelzer is now known as cpaelzer_afk
=== cpaelzer_afk is now known as cpaelzer
=== cpaelzer is now known as cpaelzer_afk
=== _salem is now known as salem_
=== xnox_ is now known as xnox
=== plars_ is now known as plars
[13:07] <caribou> Can someone explain why grab-merge outlines conflicts on files that are part of the pristine tarball ?
[13:07] <sil2100> dholbach: hey! Regarding
[13:07] <sil2100> unity-settings-daemon
[13:07] <sil2100> dholbach: this is a CI Train released package, the MPs were for the train to release them ;)
[13:07] <sil2100> Since it's managed in bzr
[13:07] <caribou> shouldn't those only be touched by patches in debian/patches ?
[13:08] <sil2100> dholbach: so no need for that to be sponsored, it'll be released as part of a silo
=== cpaelzer_afk is now known as cpaelzer
[13:22] <dholbach> sil2100: I'm sorry - I uploaded it to xenial
[13:25] <mitya57> dholbach, sil2100: we should probably remove these two entries then
[13:25] <mitya57> http://bazaar.launchpad.net/~ubuntu-dev/ubuntu-sponsoring/trunk/view/head:/sponsors-page.py#L23
[13:25] <mitya57> u-s-d and u-c-c
[13:25] <seb128> no we shouldn't
[13:25] <sil2100> dholbach: no worries, I already published the big silo with all 3 projects
[13:26] <seb128> those are projects that we maintain and we want to have changes sponsored
[13:27] <mitya57> seb128, ok… I don't see why these two should be special and different from other Canonical-is-upstream stuff, though…
[13:28] <seb128> well other projects should probably be on the sponsoring list as well
[13:29] <seb128> since those are things that are part of Ubuntu and uploaded to the archive
[13:29] <mitya57> Then fine :)
[13:29] <Laney> https://launchpad.net/~unity-settings-daemon-team/+members#active
[13:29] <Laney> anyone in ubuntu-desktop can indeed sponsor these changes
[14:14] <__marco> Hello. I am sorry to boring you, but I would like to receive a comment about https://bugs.launchpad.net/ubuntu/+source/vde2/+bug/776818
[14:14] <ubottu> Launchpad bug 776818 in vde2 (Ubuntu) "[MIR] vde2" [Undecided,Incomplete]
[14:16] <__marco> vde2 is a big package and its inclusion in main is not feasible, but the inclusion of one of its library is enough to support vde in qemu
[14:18] <__marco> Its inclusion in Ubuntu 16.04 would be a big goal, but the bug report seems stagnant.
[14:18] <__marco> Should I open a new bug report for the inclusion of that library only?
[14:22] <seb128> __marco, no need of a new report no
[14:22] <seb128> (doh, nicknames starting with a _ are annoying to type!)
[14:23] <Unit193> seb128: Irssi is for the lazy, it knows that and will complete "marc<tab>" with __marco. :P
[14:26] <seb128> Unit193, clever ;-)
[14:56] <Mirv> pitti: regarding https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-023/excuses.html - could we get some retries for the failed non-overridden ones? none of the failures seem to have something to do with alt-tab behavior that the update changes. also one qtmir i386 rerun needed at https://requests.ci-train.ubuntu.com/static/britney/vivid/landing-023/excuses.html
[14:58] <Mirv> pitti: kwin is probably something to do with "new hybris or not" as seen at http://autopkgtest.ubuntu.com/packages/k/kwin/xenial/amd64/
[15:08] <__marco> Unit193: weechat does the same
=== popey_ is now known as popey
[15:50] <seb128> bdmurray_, hey, is there a known issue with the retracers? most of 16.04 entries on the weekly view have no symbols
=== arges_ is now known as arges
[15:53] <seb128> bdmurray_, e.g
[15:53] <seb128> nautilus (11) /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.4705.0+b1681 → /usr/bin/nautilus+46a8f → /usr/bin/nautilus+36b57 → /usr/bin/nautilus+48719 → /usr/bin/nautilus+487d3 → /usr/bin/nautilus+4916a → /usr/bin/nautilus+49692 → /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4705.0+feff → /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4705.0+2250e → /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4705.0+2ad8c → /usr/lib/x86_64-lin
[15:53] <seb128> ux-gnu/libgobject-2.0.so.0.4705.0+2b0bf → /usr/lib/x86_64-linux-gnu/libgtk-3.so.0.1800.6+35c9fa → /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4705.0+16748 → /usr/bin/nautilus+71c9b → /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4705.0+14d25
[15:53] <seb128> ups, sorry, I didn't think that it would copy chars not rendered on screen
[15:56] <bdmurray_> seb128: Do you have a url I could take a look at?
=== bdmurray_ is now known as bdmurray
[15:57] <seb128> bdmurray, https://errors.ubuntu.com/problem/cb2fdb3c6dbe918d9e1c57027213f63dc685e402
[15:57] <seb128> https://errors.ubuntu.com/problem/8b87caa038f87a22ec7dda992a85a22f583d6144
[15:57] <seb128> https://errors.ubuntu.com/problem/1d6559c22aacf083d27a9f591f320d97706adc22
[15:57] <seb128> https://errors.ubuntu.com/problem/ea90702c93dd24bd24156ea1bb7c013b070292b7
[15:57] <seb128> 4 components differents
[15:57] <seb128> apt nautilus u-c-c gnome-disks
[15:58] <seb128> there are quite some others examples on the weekly view
[15:59] <bdmurray> seb128: I'll dig into it.
[15:59] <seb128> thanks
=== cpaelzer is now known as cpaelzer_afk
=== cpaelzer_afk is now known as cpaelzer
[16:30] <tinoco> hello. im having problems understanding where mstflint xenial package is coming from
[16:30] <tinoco> https://code.launchpad.net/ubuntu/+source/mstflint
[16:30] <tinoco> it looks like there isn't a xenial lp branch for latest debian merge
[16:30] <tinoco> xenial is merged with sid but i can't find its bzr branch
[16:31] <tinoco> does someone know why ?
[16:31] <tinoco> the merge request came from: https://bugs.launchpad.net/ubuntu/+source/mstflint/+bug/1528791
[16:31] <ubottu> Launchpad bug 1528791 in mstflint (Ubuntu) "Update mstflint to the latest upstream " [Wishlist,Fix released]
[16:38] <cjwatson> tinoco: https://lists.ubuntu.com/archives/ubuntu-devel/2015-November/039010.html
[16:38] <cjwatson> tinoco: just grab the source package
[16:39] <tinoco> cjwatson: ok. will work with debdiffs only for SRUs then
[16:39] <tinoco> cjwatson: tku
[16:39] <cjwatson> that was always a good idea anyway, the importer's behaviour was always especially ropey for SRUs
[16:39] <cjwatson> even when it worked at all
[16:39] <tinoco> cool
[16:51] <mitya57> And that reminds me that half of our packaging.ubuntu.com guide still describes UDD workflow
[16:58] <tinoco> mitya57: i was going to send an email to ubuntu-devel regarding this
[16:59] <pitti> kees, infinity: TB meeting reminder
[16:59] <infinity> stgraber: And you.
[17:14] <doko> xnox, is numactl supposed to ftbfs on s390x?
[17:18] <awe__> seb128, thanks for reviewing my bluez mp; just updated it based on your comments
[17:18] <seb128> awe__, thanks, let me have a look
[17:20] <seb128> awe__, looks good, approved
[17:20] <awe__> thanks seb128
[17:20] <seb128> awe__, you might want to set a commit message, CI landings tend to want one
[17:20] <seb128> yw!
[17:21] <tinoco> doko: xnox: PR/SM manages physical CPU dispatchers and it changes whenever a LPAR is activated/deactivated (or, if IFL is shared, dispatcher can change vCPU mappings).
[17:21] <tinoco> so.. i don't see numactl working on s390x even for LPAR deployments
[17:22] <doko> tinoco, ta
[17:22] <tinoco> you can get a "virtual topology" having an idea if CPUs are close to each other at that particular moment
[17:22] <tinoco> but the topology is "virtual"
[17:22] <tinoco> not related to the physical one
[17:22] <awe__> seb128, ack
[17:28] <awe__> seb128, commit msg added; thanks again!
[17:29] <seb128> awe__, yw!
[17:41] <xnox> doko, ¯\_(ツ)_/¯
[17:42] <doko> tinoco, is openmpi "supported" on s390x? e.g. I just test built it: https://launchpad.net/~doko/+archive/ubuntu/toolchain/+build/8929782
[17:42] <tinoco> doko: despite the fact that running mpi jobs on s390x is way expensive
[17:42] <tinoco> it should work for tcp/ip intercommunication
[17:43] <doko> tinoco, cool, then we don't have to care about mpich
[17:43] <tinoco> doko: i haven't ever seen someone running openmp/mpi stuff
[17:43] <tinoco> considering that s390x had 1 fp per cycle
[17:43] <tinoco> :o)(
[17:43] <tinoco> now it has 2 :o
[17:44] <doko> sure, but it makes things easier when we can handle it in the archive like all other archs
[17:45] <tinoco> doko: +1
[17:46] <tinoco> i dont think they "depend" on something that would ftbfs
[17:46] <tinoco> mpi implementations might rely on infiniband (librdma/libmlx/libibverbs)
[17:46] <tinoco> that *could* in theory be problematic. but then, for s390x, we could remove those dependencies
[17:46] <tinoco> and stick with tcpip
=== cpaelzer_ is now known as cpaelzer_afk
[18:03] <xnox> doko, +1 to switch to openmpi.
=== sgclark_sleeping is now known as sgclark
=== Logan_ is now known as Logan
=== sforshee` is now known as sforshee
=== buxy_bak is now known as buxy
[19:21] <pitti> caribou: hey! are you planning on merging rsyslog again, to fix bug 1534106? it's a real nuisance and breaks juju-local quite hard :/
[19:21] <ubottu> bug 1534106 in rsyslog (Ubuntu) "rsyslogd crashed with SIGSEGV with juju-local configuration" [High,Triaged] https://launchpad.net/bugs/1534106
=== debfx_ is now known as debfx
=== andyrock_ is now known as andyrock
=== dobey_ is now known as dobey
[20:15] <xnox> pitti, could you please let systemd through? multipath tools brekage is known and being work on.
[20:15] <pitti> xnox: I thought it was already fixed
[20:15] <xnox> horum. let me check harder then.
[20:21] <pitti> xnox: I retried it this morning, see http://autopkgtest.ubuntu.com/packages/m/multipath-tools/xenial/i386/ -- the retry ran with ubuntu11
=== salem_ is now known as _salem
[20:22] <xnox> pitti, yeah, i see it fails to remove loopbacks, cause the device is still busy.
[20:22] <xnox> i think kpartx -av, followed by -dv is too quick, and needs "udevadm settle" in between.
[20:22] <pitti> xnox: I suppose that's just a race in the test now, though?
[20:22]  * pitti lets it through then, not related to the new systemd
[20:22] <xnox> let me upload that, and see if that improves things.
[20:23] <pitti> xnox: hint committed
=== enrico_ is now known as enrico
[20:42] <mdeslaur> is anyone planning on trying to get wine back in sync with debian?
=== cyphermox_ is now known as cyphermox
=== mhall119_ is now known as mhall119
=== dannf` is now known as dannf
=== lionel_ is now known as lionel
=== mthaddon` is now known as mthaddon
=== cpaelzer_afk is now known as cpaelzer_