[00:02] <tdaitx> slangasek, ftbfs fixed for bluez-tools in LP: #1489661
[00:02] <ubottu> Launchpad bug 1489661 in bluez-tools (Ubuntu) "bluez-tools FTBFS on wily-proposed due to AM_LDFLAGS misuse" [Undecided,New] https://launchpad.net/bugs/1489661
[00:16] <Logan> slangasek: ok, I'll test build and then sync
[00:16] <Logan> I'll deal with the transition fallout as well
[00:24] <Logan> doko: regarding https://launchpad.net/ubuntu/+source/gtkmm2.4/1:2.24.4-1.1ubuntu1
[00:24] <Logan> can we sync over that, even though Debian didn't make the std change?
[01:05] <infinity> Odd_Bloke: Sorry, I fell ill and disappeared.
[01:10] <slangasek> Logan: if Debian is not making the package name change for the ABI transition, you should *not* sync over it but instead merge it with conflicts/replaces going the other direction, so that users can still sanely upgrade within wily
[01:11] <cyphermox> tdaitx: still around? I was looking at your bluez-tools diff
[01:11] <tdaitx> cyphermox, yeah
[01:11] <cyphermox> tdaitx: maybe just missing patch tags
[01:12] <tdaitx> cyphermox, I set it on LP earlier
[01:13] <tdaitx> cyphermox, or did I miss something else?
[01:13] <cyphermox> ah, sorry I mean DEP-3 tags on the patch itself: http://dep.debian.net/deps/dep3/
[01:14] <cyphermox> but it's tiny and pretty obvious it's from you :)
[01:15] <tdaitx> cyphermox, thanks, I didn't knew about these
[01:19] <tdaitx> cyphermox, does any of the tools we use help on getting that done?
[01:20] <tdaitx> otherwise I will just write down a template so I don't forget this =)
[01:21] <cyphermox> tdaitx: good question, I don't know. I just add them manually; usually mostly just From:, Subject: amd Bug-Ubuntu:
[01:21] <tdaitx> cyphermox, ok, should I added those to the patch and submit the debdiff to debian again? what about lp?
[01:23] <cyphermox> I leave that up to you, if you want to submit it just to Debian I'll add them for you when I sponsor
[01:27] <tdaitx> cyphermox, alright, thanks for your help, please keep bringing those issues forward when you see them, lots to learn ;-)
[01:35] <tdaitx> cyphermox, found it: quilt header -e --dep3
[01:35] <cyphermox> oh, cool
[01:35] <tdaitx> that inserts a template
[01:35] <cyphermox> thanks, I'll make note of that :)
[01:36] <cyphermox> figured there might be a way, but it wasn't bugging me enough to just vi it in
[01:39] <tdaitx> there was a "quilt header -e" citation in deb maintainer manual, when I looked at the man page I noticed that --dep3 param, easy as that
[01:43] <AwlsomeAlex> Hello?
[02:00] <cyphermox> good night!
[02:09] <Luke> how can I set a global prompt for all users?
[02:30] <hallyn> cyphermox: hey, were you going to push the new golang to wily today?
[03:01] <pitti> Good morning
[03:21] <tdaitx> slangasek, opencsg FTBFS on armhf because it cant find libGLES2... that happens because:
[03:21] <tdaitx> 1. it uses qmake-qt4 to create the Makefile, but qt4-x11 is being compiled with libgles2-mesa-dev in armel/armhf (against libgl1-mesa-dev and libgl1u-mesa-dev in other archs)
[03:21] <tdaitx> 2. it depends on glew, but glew depends on libgl1-mesa-dev and libgl1u-mesa-dev, thus the libgles2 dependency is not set anywhere
[03:22] <tdaitx> thus either glew has to be build using libgles2 in armel/armhf or qt4-x11 must use libgl1/libgl1u for armel/armhf
[03:22] <tdaitx> slangasek, ^
[03:23] <tdaitx> slangasek, not sure which one is the right way to go (or if there is a third alternative)
[04:41] <Logan> slangasek: it is making the package name change, whereas we didn't
[05:26] <lotuspsychje> good morning to all
[05:26] <lotuspsychje> is it possible to add the broadcom firmware drivers to ubuntu-restricted-extras so users with bc chipsets can install ubuntu more easyly?
[05:41] <pitti> this is already done by ubuntu-drivers-common and in the installer
[05:41] <pitti> hardware drivers don't belong into ubuntu-restricted-extras, as these would be useless or even detrimental for users who don't have that hardware
[05:41] <pitti> lotuspsychje: ^
[05:42] <lotuspsychje> pitti: does it need to have internet connection for ubuntu-drivers-common?
[05:43] <pitti> I believe we shipt the driver on the ubuntu images, so the installer grabs it from there
[05:43] <lotuspsychje> pitti: because many users on 14.04 complain in #ubuntu their broadcom doesnt get recognized
[05:43] <lotuspsychje> pitti: or has this been fixxed in 14.04.3?
[05:44] <pitti> not particularly, it was working in 14.04 already for at least some chips
[05:44] <lotuspsychje> pitti: maybe its the default broadcom driver and not the firmware thats added?
[05:45] <lotuspsychje> they have to do this sometimes: https://help.ubuntu.com/community/WifiDocs/Driver/bcm43xx#STA_-_No_Internet_access
[05:46] <pitti> but there might have been some changes to replace bcmwl with the one shipped by the upstream kernel
[05:46] <pitti> (no further idea I'm afraid, it's been many years since I had such a thing)
[05:47] <lotuspsychje> this user had no internet access on eth0, maybe thats why?
[05:48] <pitti> the *intention* is that the driver is on the image
[05:48] <lotuspsychje> pitti: ok tnx for investigating
[05:49] <pitti> lotuspsychje: and http://releases.ubuntu.com/14.04.3/ubuntu-14.04.3-desktop-amd64.list still does ship it
[05:49] <pitti> /pool/restricted/b/bcmwl/bcmwl-kernel-source_6.30.223.248+bdcom-0ubuntu0.1_amd64.deb
[05:49] <pitti> so that's not it
[05:49] <pitti> you need to enable [ ] Install non-free drivers in the installer for that
[05:50] <pitti> on the wiki page you cited it also just installs that deb from the cd-rom, so in principle it ships everything that's needed
[05:50] <lotuspsychje> pitti: didnt ntocie there was such option yet?
[05:51] <lotuspsychje> pitti: yeah i know the cdrom trick does it, but for most n00b users its a little hard to find
[05:51] <pitti> last time I installed on a laptop with broadcom, it "just happened", but since then I'm afraid I don't know off-hand what's going wrong
[05:51] <pitti> a bug report with installer logs would be helpful for that
[05:52] <lotuspsychje> pitti: if that occurs again on some user, ill push to bug it
[05:52] <pitti> thanks!
[05:52] <lotuspsychje> pitti: thank you for lighting things up
[06:02] <pitti> caribou: hm, I'm adjusting your rsyslog merge to 8.12.0-1; 8.9 is quite old, not even in testing any more
[06:09] <pitti> caribou: followed up to the bug
[07:17] <pitti> doko: hmm, I hinted gcc-5, but http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt says it renders packages uninstallable -- any recent dependency change in that version?
[07:40] <smb> rbasak, on ffe... have now sponsors and sru team subscribed to bug 1487538. are there specific sponsors I should ask in this special case?
[07:40] <ubottu> bug 1487538 in Ubuntu "[needs-packaging] [FFE] Add dpdk to wily universe" [Wishlist,New] https://launchpad.net/bugs/1487538
[07:48] <rbasak> smb: thank you for pushing ahead with DPDK, and sorry I've been tied up. I need to get that email to upstream sorted out. Has the FFe been approved? Need that before sponsoring. Maybe arges can sponsor as he reviewed previously?
[07:49] <rbasak> smb, arges: can we sync on DPDK status later today, maybe? I'd like to go through my email draft with arges with a focus on getting it done and sent if possible.
[07:49] <smb> rbasak, can ask him today. somehow thought first upload and then accept it as ffe from the new queue
[07:50] <rbasak> I've seen a release team member complain about it when done that way round before. So I presume they want to ack first.
[07:51] <smb> rbasak, we can do that. I am having a dentist appt. soon but something like 1UTC onwards (or as soon as arges becomes concious)
[07:52] <doko> pitti, yes, it adds some breaks. so maybe I should just "binNMU" these
[07:54] <rbasak> smb, arges: invite sent. Feel free to move.
[07:55] <rbasak> (is arges up by then?)
[07:55] <smb> rbasak, I can live with that and I believe he should
[07:55] <rbasak> That's 8am for him
[07:57] <smb> ok, if he was like me, rather not but he might. we will see
=== sitter_ is now known as sitter
=== vrruiz_ is now known as rvr
=== sitter_ is now known as sitter
[09:34] <melodie> hi
[10:01] <Odd_Bloke> infinity: No worries; I'm back around now.
[10:19] <pitti> Laney: I dumped my brain into https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure#Deployment FYI
[10:20] <pitti> Laney: does this sound reasonably comprehensible to you?
[10:22] <sarnold> pitti: nice
[10:23] <pitti> sarnold: thanks :)
[10:24] <sarnold> (i'll give it a Good Read later.. it just looked good on a quick skim :)
[10:37] <caribou> pitti: I'm fine with redoing the merge for 8.12.0-1 but this won't happen today. Hopefully by EOD monday, is that ok with you ?
[10:37] <pitti> caribou: sure!
[10:38] <caribou> pitti: I'll also drop the rsyslog.dmesg.upstart job
[10:38] <pitti> caribou: no, please don't drop the upstart job
[10:38] <pitti> caribou: just consider if you need the corresponding (and newly added) .service for this
[10:39] <caribou> pitti: oh, that's what I meant, sorry
[10:39] <pitti> caribou: ah, ok :)
[10:56] <doko> xnox, did you continue to work on boost rebuilds?
[11:09] <doko> tjaalton, https://launchpad.net/ubuntu/+source/openscad/2015.03-1+dfsg-2build1/+build/7844937  any reason that libgl1-mesa-swx11 is not built in wily?
[11:11] <tjaalton> doko: it doesn't exist, debian experimental got rid of it too recently
[11:13] <doko> tjaalton, could you fix openscad then?
[11:13] <tjaalton> perhaps
[11:13] <tjaalton> we haven't had swx11 for a few years
[11:15] <pitti> Laney: I filled in the remaining sections too, now; Please let me know if something is unclear
[11:15] <tjaalton> doko: can you fix llvm-3.7 to build on i386 ;)
[11:17] <tjaalton> opengl 4.1 for radeon depends on it, and mesa 11.0-rc migrated to it
[11:18] <doko> heh, I looked at it, but didn't find anything yet. builds in unstable
[11:18] <tjaalton> apparently it's caused because we build some i686 optimization
[11:18] <tjaalton> there's an upstream bug open since february :/
[11:18]  * tjaalton tries to find it
[11:19] <tjaalton> https://llvm.org/bugs/show_bug.cgi?id=22661
[11:19] <ubottu> llvm.org bug 22661 in compiler-rt "No compiler-rt library is built when configured for i686-linux" [Normal,New]
[11:19] <tjaalton> should be that
[11:24] <doko> ohh
[11:25] <doko> ok, even with a patch
[11:35] <doko> tjaalton, https://launchpad.net/ubuntu/+source/llvm-toolchain-3.7/1:3.7~+rc4-1ubuntu1  and see the Conflicts/Replaces
[11:40] <tjaalton> doko: I'll worry about the backport closer to the release :)
[11:44] <jtaylor> doko: do you know why the bash package uses its internal malloc instead of glibc's?
[11:44] <jtaylor> performance?
[11:46] <doko> I have to dig around. does something not work?
[11:47] <jtaylor> yes, something LD_PRELOADS a library using posix_memalign during init, and later it then uses bash's free
[11:47] <jtaylor> -> crash
[11:47] <jtaylor> it is a somewhat strange app that can probably be fixed, but I'm curious about the reason for the internal malloc
[11:48] <jtaylor> it seems fedora bash uses glibc malloc as that is unaffected
[11:49] <jtaylor> or its because our bash is a pie executable?
[11:55] <doko> Riddell, looks like you're reverting / overwriting many of the changes I made during the GCC 5 uploads ...
[11:55] <doko> kde-runtime now b-d on boost1.55 again
=== MacSlow is now known as MacSlow|lunch
[12:00] <Odd_Bloke> arges: cloud-init has been in {p,t,v}-proposed for 7 days now and the fixes have all been validated; would you mind migrating it?
[12:14] <mitya57> pitti, I have a question about autopkgtest.ubuntu.com. When I search for "sphinx", it shows me this: http://mitya57.me/tmp/searcharea.png (amd64 marked as failed),
[12:14] <mitya57> but http://autopkgtest.ubuntu.com/packages/s/sphinx/ indicates that it's ppc64el that fails, not amd64.
[12:14] <mitya57> I guess it is a bug somewhere?
[12:15] <mitya57> As I can see amd64 never failed (on the new server), and ppc64el never succeeded.
[12:21] <pitti> mitya57: ah yes, a funny display bug; mind reporting that against http://bugs.debian.org/src:debci ? then it's at the right place already
[12:23] <mitya57> Ok, will report now.
[12:39] <mitya57> pitti: debian #797198
[12:39] <ubottu> Debian bug 797198 in debci "debci: search page displays wrong architectures as failing" [Normal,Open] http://bugs.debian.org/797198
[12:40] <pitti> mitya57: thanks! I think I've seen this too
[12:42] <rbasak> smb, arges: mind if we postpone dpdk sync until a bit later. I'm feeling a bit under the weather.
[12:44] <smb> rbasak, In my case depends how long that bit is, have not heard of ar ges yet. So it might suit him to get awake
[13:03] <dobey> pitti: hey, how do we figure out why something in debci is running out of memory?
[13:04] <pitti> dobey: ah, what package does that affect? I can give it a bigger instance
[13:04]  * pitti pats his "big_packages" list in worker.conf
[13:04] <dobey> pitti: ubuntu-system-settings-online-accounts seems to be hitting this issue
[13:05] <pitti> dobey: really? looks like the autopilot-gtk lib ABI mismatch to me
[13:05] <pitti> (which breaks a lot of tests indeed)
[13:05] <dobey> pitti: and that causes ENOMEM?
[13:05] <pitti> there's a silo that needs to be released, fallout from the g++ 5 transition
[13:06] <pitti> it causes this "IndexError: list index out of range" for sure
[13:06] <pitti> I think the ENOMEM is a red herring
[13:07] <pitti> at least I'll retry all these once the silo lands (/me bats eyelashes towards sil2100), my hope is that they'll all just work again
[13:07] <pitti> the history on http://autopkgtest.ubuntu.com/packages/u/ubuntu-system-settings-online-accounts/wily/amd64/ suggests that it worked fine before with the 2 GB of RAM that it has
[13:08] <dobey> and it worked fine at some point since the gcc5 transition too
[13:17] <hallyn> mwhudson: cyphermox: my laptop would really like to upgrade but won't get past the broken golang.  Wlil the new golang hit wily today, or should i wget the 70 or so debs and dpkg -i them?
[13:20] <cyphermox> hallyn: oh, whether you'll get golang 1.5 final depends on mwhudson, but let me fix the issue with the package now
[13:21] <dobey> broken golang?
[13:21] <hallyn> dobey: yeah, file moved from golang-go.tools to golang-go
[13:21] <hallyn> broken pkg not golang itself
[13:21] <hallyn> cyphermox: ok, last i saw the bug it looked like mwhudson was done
[13:22] <hallyn> feh maybe i'll make a pkg in ppa which does the breaks/replace :)
[13:22] <dobey> golang-go breaks/replaces golang-golang-x-tools, which golang-go.tools depends on though; so an upgrade should just remove the latter
[13:23] <dobey> something does still Suggests: golang-go.tools though, and probably shouldn't
[13:25] <hallyn> not sure whether you're telling me what the pkg should do, or suggesting an easier way fo rme to get past the apt-get dist-upgrade failures
[13:26] <cyphermox> hallyn: he's just re-doing the analysis I had already done.
[13:28] <cyphermox> hallyn: though you could just remove golang-go.tools and golang-golang-x-tools
[13:30] <dobey> hallyn: what i'm saying is that for me, "apt-get dist-upgrade" just removed the golang-go.tools and golang-golang-x-tools packages
[13:37] <hallyn> dobey: it did?   hm, so it sounds like i have something pinning those then.  interesting
[13:37] <hallyn> (note i'm not the only one wit hthis failure, someone else opened the bug :)
[13:38] <hallyn> all right, just removed all the pkgs
[13:38] <dobey> hallyn: yeah, although i think i have -proposed enabled there too
[13:38] <dobey> so maybe it's fixed in proposed :)
[13:39] <dobey> yeah, i do have proposed enabled there
=== MacSlow|lunch is now known as MacSlow
[14:24] <tsimonq2> Hey, Launchpad is giving me a weird error when I try to change the affected package(+editstatus)...what is the proper way to edit the affected package?
[14:24] <infinity> tsimonq2: Not enough info really to know what went wrong.
[14:25] <infinity> tsimonq2: But often it's that you're trying to assign a project bug to an Ubuntu package, instead of an Ubuntu bug.
[14:25] <infinity> (Which isn't the most intuitive thing to sort out sometimes, but the URL you're on is a hint)
[14:26] <infinity> tsimonq2: Would help if you defined "weird error".
[14:26] <tsimonq2> Sorry
[14:26] <pitti> dobey: armhf/ppc64el are uninstallable, but i386/amd64 succeeded again; autopilot-gtk and xpathselect landed
[14:27] <tsimonq2> It gives me an error of: There is no package named 'nautilus-columns' published in Ubuntu. when in the selector, it shows up
[14:27] <dobey> pitti: yeah, unity8-autopilot seems to be uninstalalble on those archs, and is causing lots of "always failed" there
[14:28] <infinity> tsimonq2: It's not wrong.
[14:28] <Odd_Bloke> arges: Thanks!
[14:28] <infinity> tsimonq2: https://launchpad.net/ubuntu/+source/nautilus-columns
[14:28] <pitti> dobey: lots of valid candidates now \o/
[14:28] <infinity> tsimonq2: Try assigning to a package that exists.
[14:28] <dobey> pitti: yeah. mir boottest is failing still though :(
[14:29] <tsimonq2> infinity: Then why does it show up in the selector?
[14:30] <infinity> tsimonq2: Because it probably existed at one point in the distant past.
[14:30] <tsimonq2> infinity: When I click Select...
[14:30] <tsimonq2> Oh ok
[14:30] <infinity> tsimonq2: But is no longer in any current releases.
[14:30] <tsimonq2> infinity: Ok, thank you for your time :)
[14:40] <cjwatson> tsimonq2: That's https://bugs.launchpad.net/launchpad/+bug/42298
[14:40] <ubottu> Launchpad bug 42298 in Launchpad itself "package picker lists unpublished (invalid) packages" [High,Triaged]
[14:41] <tsimonq2> cjwatson: Well that needs to be fixed XD
[14:41] <tsimonq2> cjwatson: High priority XD
[14:42] <cjwatson> tsimonq2: I have some work in progress for it, but it's a non-trivial wodge of complicated performance-sensitive SQL
[14:42] <cjwatson> The last attempt to deal with it crashed and burned, so not going to rush it :-)
[14:46] <Simounet> Hi there. Do you know how I can assign a bug to one of the webupd8's package? https://bugs.launchpad.net/bugs/1489842
[14:46] <ubottu> Launchpad bug 1489842 in Ubuntu "Nautilus columns fields not working on grid view" [Undecided,New]
[14:52] <pitti> dobey: hm, unity8-autopilot uninstallable on armhf? didn't we use to have a phone on arm or something? :-)
[14:52] <pitti> dobey: I'll retry the mir boottest
[14:53] <pitti> oh wait, I already did that; last three attempts failed
[14:53] <dobey> yeah, i'm not sure what's failing exactly though
[14:53] <dobey> but it's blocking my package from transitioning :(
[14:53] <leszek> hi
[14:54] <infinity> cjwatson: Was that fresh in your mind from recently looking at it, or are you turning into wgrant?
[14:54] <pitti> doko: retrying one more time; I'm quite used to overriding boottests, brittle as they are
[14:54] <pitti> err, dobey ^
[14:54] <pitti> dobey: so if you want me to do that, I can
[14:55] <dobey> well i don't know anything about mir, so i don't know if it's always been failing there or not
[14:55] <leszek> chrisccoulson: can you please explain me how you solved this issue ? https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1471949  We try to build firefox with kde integration patches on launchpad ppa but the resulting 32bit deb crashes with the same symptoms
[14:55] <ubottu> Launchpad bug 1471949 in gcc-mozilla (Ubuntu Precise) "Firefox 39 crashes on startup or within a few seconds on Precise/x86" [Critical,Fix committed]
[14:55] <cjwatson> infinity: Open browser tab :)
[14:56] <cjwatson> infinity: wgrant does that in real life without mechanical assistance.
[14:56] <infinity> cjwatson: I've noticed.
[14:56] <cjwatson> Mere mortals like me have to outsource some of those brain cells.
[14:57] <infinity> cjwatson: I always assumed rapid computer lookup or firefox history help, until I saw him rattle off bug numbers over beer.
[14:57] <wgrant> It's not something to aspire to.
[14:58] <cjwatson> Of course over beer the chances of having one's bluff called are a *bit* less
[14:58] <wgrant> Heh
[14:58] <infinity> cjwatson: But call it, we did.
[14:58] <leszek> chrisccoulson: and one addition. We build for trusty.
[14:58] <infinity> cjwatson: This is why the smart phone was invented.
[15:04] <slangasek> tdaitx: glew can't be built with gles2, it's gl only; and qt4-x11 is not going to use gl1 for arm, because that means losing accelerated drivers.  Option 3 is to make opencsg do something smarter than asking qmake for GL library information (because qmake).  I thought robru had looked at one of these earlier, don't remember if it was opencsg or not - you might want to compare notes
[15:05] <slangasek> Logan: whereas we didn't> the launchpad link you posted clearly shows a package name change for gtkmm2.4
[15:07] <tdaitx> slangasek, k, thanks
[15:18] <doko> barry, skipped: enum34 (0 <- 103)
[15:18] <doko>     got: 249+0: a-68:a-44:a-35:i-36:p-35:p-31
[15:18] <doko>     * amd64: python3-pykmip, python3-zeroconf
[15:35] <barry> doko: as soon as zigo's update to experimental's pykmip lands, i'll sync that to wily.  thought i'd already dealt with zeroconf, but i can't find it, so will deal
[15:37] <barry> oh, looks like git was updated but it wasn't uploaded
[15:38] <pitti> dobey: \o/ fourth time is the charm (mir boottest)
[15:56] <chrisccoulson> leszek, if you're building for trusty, don't use the gcc in trusty-updates
[15:56] <leszek> ok
[16:03] <flexiondotorg> cjwatson, Does Ubiquity have any support for fcitx?
[16:03] <cjwatson> flexiondotorg: I don't know
[16:03] <cjwatson> grep source or ask cyphermox
[16:26] <dobey> pitti: great. thanks
[16:27] <Logan> slangasek: sorry, there was a context switch
[16:27] <Logan> slangasek: the original one I was talking to you about was gtkglextmm, where we didn't make the name change but Debian did
[16:28] <Logan> but they also bumped a build dependency on gtkmm2.4 to Debian's latest version, which included all of the Ubuntu changes except for changing the std
[16:28] <Logan> so I was asking doko if we could just pull that in and whether the std change was necessary
[16:30] <cyphermox> flexiondotorg: it doesn't do anything special about it, that I know. might want to grep the source as cjwatson suggested
[16:31] <smoser> cyphermox, https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1489959
[16:31] <ubottu> Launchpad bug 1489959 in multipath-tools (Ubuntu) "power8 scsii disks get blacklisted from multipath / curtin installed system doesnt boot" [Undecided,New]
[16:31] <smoser> wonder if you have any thougths tehre, or would be able to debug that.
[16:35] <cyphermox> do you just add multipath-tools in curtin? You'd also probably need sg3-utils
[16:35] <cyphermox> (if it's udebs you want sg3-udeb)
[16:36] <smoser> if you need that, should you not depend ?
[16:36] <smoser> cyphermox, 'apt-get install multipath-tools-boot' is all curtin does.
[16:36] <smoser> so even a recommends would get pulled in
[16:37] <cyphermox> at which point is this then? when starting the install or after the system is installed?
[16:37] <smoser> well, the install detects that it needs multipath (by looking for identical block devices, not by using multipath at all)
[16:38] <cyphermox> sure
[16:38] <smoser> and then installs multipath-tools-boot if necessary , configures target and expects boot to work.
[16:39] <smoser> by configures, i mean :
[16:39] <smoser>  - writes 'user_friendly_names yes' to /etc/multipath.conf
[16:39] <cyphermox> ok, so you need to pull in sg3-utils-udev too, and probably check whether /etc/multipath/wwids and /etc/multipath/bindings are copied from the installation into the installed system (and the initramfs is updated)
[16:40] <smoser>  - writes /etc/multipath/bindings for the boot device
[16:40] <smoser>  - updates initramfs.
[16:40] <cyphermox> in the bug there isn't enough information to tell -- if you add all of multipath -v3  I could tell
[16:40] <cyphermox> ah
[16:40] <cyphermox> yes, then it's probably the wwids file missing
[16:40] <smoser> i attached -v3
[16:40] <smoser> i dont thinks o.
[16:40] <smoser> even in running environment '-ll' does nothing
[16:40] <smoser> when it should
[16:41] <cyphermox> hm, it shouldn't complain about the properties missing
[16:41] <cyphermox> what does multipath -t say?
[16:42] <doko> Logan, context?
[16:42] <smoser> sg3-utilshttp://paste.ubuntu.com/12215510/
[16:42] <smoser> http://paste.ubuntu.com/12215510/
[16:42] <Logan> doko: I was wondering if we could sync over the changes in https://launchpad.net/ubuntu/+source/gtkmm2.4/1:2.24.4-1.1ubuntu1
[16:42] <Logan> or if we need to merge in the std=c++11 change (which wasn't applied in Debian)
[16:43] <doko> Logan, sync it. I think they reverted back to an older glibmm
[16:43] <smoser> cyphermox, thats on the wily system that booted without  multipath , then i apt-get install multipath. it did correctly (as you implied) gety sg3-utils. but seems still to not consider those disks as multipath. when in vivid it does.
[16:45] <cyphermox> check if udevadm info --query=all --name=/dev/sda shows SCSI_IDENT_* properties
[16:45] <cyphermox> that's pretty much all there is to it -- these properties are used instead of just ID_SERIAL to decide if it should be multipath devices
[16:46] <smoser> http://paste.ubuntu.com/12215543/
[16:46] <cyphermox> and you said sg3-utils-udev is installed?
[16:47] <infinity> multipath-tools depends on it, I don't see how he could be missing it.
[16:47] <smoser> for reference, same trusty: http://paste.ubuntu.com/12215554/
[16:47] <smoser> and yes, sg3-utils-udev is installed.
[16:47] <infinity> But it might need some udev prodding if it's installed post-boot?
[16:48] <smoser> cyphermox, with vpn... can you get to 10.245.71.133 ?
[16:48] <cyphermox> well, the initramfs needs to be updated but postinst probably should have done it
[16:48] <smoser> i can let you poke at a trusty box and a wily box if you can.
[16:48] <smoser> initramfs is updated.
[16:48] <infinity> And rebooted since?
[16:48] <smoser> curtin does that explicitly. making 14 times on average that initramfs gets updated in an install :)
[16:48] <cyphermox> I think he wants to see the devices first
[16:49] <cyphermox> but even then, multipath -ll shouldn't say that the devices are blacklisted
[16:49] <infinity> Well, if we've not rebooted, updating initramfs makes no difference. :P
[16:49] <infinity> And adding udev rules post-boot also does nothing.
[16:49] <cyphermox> well, udev would need to be prodded anyway
[16:49] <cyphermox> smoser: I can get to it but I have no access
[16:49] <smoser> right. my expectation is that multipath -ll should work
[16:50] <smoser> cyphermox, ok. i'll let you in then
[16:50] <infinity> You'd have to re-trigger udev if you want the new rules to kick in.
[16:50] <cyphermox> yep
[16:50] <smoser> infinity, well, presumably that would happen on reboot.
[16:50] <infinity> Probably just 'udevadm trigger -s scsi' or similar.
[16:50] <smoser> and it does in trusty -> vivid and did in wily up until recently.
[16:50] <infinity> smoser: Sure, on reboot it would, which was why I was trying to clear up if this was broken after your apt-get, after reboot, or both.
[16:51] <infinity> smoser: Specifically, the lack of SCSI_IDENT stuff in your paste.
[16:52] <cyphermox> smoser: you can't compare trusty/vivid to wily when there's been a major update
[16:52] <smoser> cyphermox, ok. you should be able to ssh into ubuntu@10.245.71.133 (wily) and for reference ubuntu@10.245.71.134 (trusty)
[16:52] <smoser> both systems be nice and rebooting probably need to ask someone else about.
[16:52] <smoser> ie, doko is using the wily system right now.
[16:53] <cyphermox> ran udevadm trigger -s scsi, that's it
[16:54] <infinity> cyphermox: I win?
[16:54] <flexiondotorg> cyphermox, Thanks. I did grep the code, no mention of fcitx. I was just checking there wasn't some additional functionality tucked away in the indicators.
[16:55] <cyphermox> infinity: well, it's still not creating the paths, but if the devices are already loaded it might be hard
[16:56] <infinity> cyphermox: But that made the extra attributes show up?
[16:56] <smoser> yeah. it did.
[16:56] <cyphermox> no multipath-tools-boot installed won't help rebooting on multipath
[16:56] <infinity> cyphermox: If so, you could retrigger the multipath events afterwads, I suspect.
[16:56] <cyphermox> infinity: yep
[16:56] <cyphermox> the properties show up now
[16:57] <infinity> cyphermox: Alternately, one could manually install s-thing-udev, udevadm trigger, then install multipath-tools, which might get it in the right order to not have to do more triggering.
[16:57] <infinity> cyphermox: Bonus point, perhaps s-thing-udev could trigger -s scsi in its postinst, and this would Just Work?
[16:58] <cyphermox> infinity: yeah
[16:58] <cyphermox> still there are other devices on that system and they should be getting picked up
[16:58] <smoser> http://bazaar.launchpad.net/~curtin-dev/curtin/trunk/view/head:/curtin/commands/curthooks.py#L468
[16:58] <smoser> thats what curtin does for installation of mutipath
[16:59] <smoser> we explicitly write multipath.conf and multipath/bindings
[17:00] <cyphermox> there is definitely no multipath-tools-boot or /etc/multipath/bindings on that system right now
[17:00] <smoser> right. because i disabled installation
[17:00] <smoser> because if i enable it, it doesnt boot
[17:01] <cyphermox> so we're currently looking at two very different issues
[17:02] <cyphermox> along with writing the bindings file you really should add writing a wwids file
[17:02] <smoser> where does that go and what would it look like ?
[17:03] <cyphermox> it's format is pretty much /<SCSI_IDENT_LUN_T10>/  per-device or something like it
[17:03] <cyphermox> it goes along with bindings in /etc/multipath/
[17:03] <cyphermox> just running multipath -v0 will write both files for you though
[17:04] <smoser> but not on diamond ?
[17:04] <smoser> # multipath -v0 ; echo $?
[17:04] <smoser> 1
[17:04] <smoser> or are you saying you need a reboot?
[17:04] <cyphermox> oh wait
[17:05] <cyphermox> multipath -W will write the wwids file for you
[17:05] <cyphermox> for some reason on diamond it's not liking any of the devices
[17:05] <smoser> :)
[17:05] <smoser> yes, thats the problem :)
[17:05] <cyphermox> meh
[17:06] <cyphermox> it's also not really in the best of state to be debugging this
[17:06] <smoser> why ?
[17:06] <smoser> its booted off one device, but it has 5 others that are not used.
[17:09] <smoser> cyphermox, so why does 'multipath -ll' not work now ?
[17:10] <cyphermox> Aug 28 17:10:24 | sdf can't store path info
[17:10] <cyphermox> ^ I don't know
[17:11] <smoser> ok,thank you for your help.
[17:16] <smoser> is it ok if i leve you to poke at that, and can you give me some suggestion of how i should install and configure multipath support ? we've not had to write a WWID file in trusty -> vivid.
[17:17] <smoser> it appears maybe i need to write the wwid in /etc/multipath/wwids ? which personally seems quite silly if i've declared the same id in /etc/multipath/bindings.
[17:18] <cyphermox> I doubt writing the wwids will help in this case, looks like a legit bug for these devices
=== davmor2 is now known as davmor2_HOLS
[17:19] <smoser> ok. well i'll leave you to debug, ok ?
[17:19] <smoser> thank you again for your help.
=== wendar_ is now known as wendar
[17:37] <slangasek> Logan: ah yes :)
[17:51] <Logan> doko: Bug 1489980
[17:51] <ubottu> bug 1489980 in gtkmm2.4 (Ubuntu) "Sync gtkmm2.4 1:2.24.4-2 (main) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/1489980
=== mwenning is now known as mwenning-rr5
=== brainwash_ is now known as brainwash