=== tmpRAOF is now known as RAOF
[04:44] <pitti> Good morning
[06:30] <dholbach> good morning
[06:32] <ari-tczew> hello dholbach
[06:33] <dholbach> hey ari-tczew
[06:39] <dodeluser> hello. I got a special question about this tutorial: https://help.ubuntu.com/community/LiveCDCustomization#Advanced_Customizations
[06:40] <dodeluser> I do not understand this line: sudo chroot edit mkinitramfs -o /initrd.gz 2.6.15-26-k7
[06:40] <dodeluser> someone can help me?
[06:44] <dholbach> @pilot in
=== udevbot changed the topic of #ubuntu-devel to: Archive: wily open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: dholbach
[08:41] <flexiondotorg> dholbach, As pilot could you take a look at https://code.launchpad.net/~ubuntu-mate-dev/indicators-gtk2/indicator-application-gtk2/+merge/244116
[08:41] <flexiondotorg> dholbach, I've discussed this with infinity.
[08:42] <flexiondotorg> dholbach, infinity was able to get it to build and pass the test, just as I was when testing in a PPA.
[08:42] <flexiondotorg> dholbach, infinity and I agreed to wait to merge and upload for the 15.10 cycle.
[08:42] <flexiondotorg> dholbach, Any chance you could merge and upload today please?
=== doko_ is now known as doko
[09:09] <tseliot> pitti: hi, u-d-c seems to fail to build (i.e. to pass all the tests) on armhf and arm64. Is there a way to skip some of the tests based on the architecture?
=== davidcalle_ is now known as davidcalle
[09:10] <tseliot> pitti: that's in wily
[09:12] <pitti> tseliot: I don't think you want to skip based on the architecture, but rather availability of the nvidia-experimental pacakge or hybrid-detect, or whatever the test checks?
[09:13] <pitti> tseliot: and yes, you can do that; we already conditionally skip some tests
[09:13] <pitti> tests/ubuntu_drivers.py:    @unittest.skipUnless(os.path.isdir('/sys/devices'), 'no /sys dir on this system')
[09:13] <pitti> tseliot: just odd that this worked in vivid, looks like something in nvivia-experiemntal changed between vivid and wily?
[09:14] <pitti> https://launchpad.net/ubuntu/+source/ubuntu-drivers-common/1:0.4.5 succeeded on all arches, after all
[09:14] <tseliot> pitti: maybe nvidia-experimental was finally removed
[09:14] <tseliot> pitti: or it was never there for arm
[09:15] <tseliot> that's a transitional package
[09:15] <tseliot> actually, it was
[09:16] <tseliot> pitti: also, we no longer have nvidia-current and nvidia-current-updates
[09:17] <pitti> tseliot: ah, nvidia-experimental is a dummy package from the tests, it never existed in actual ubuntu
[09:18] <tseliot> pitti: we had nvidia-$ver-experimental at some point, but the version was in the name too
[09:20] <pitti> so this looks like an issue/regression in python-apt, or something missing in the fake apt repo setup
[09:20] <tseliot> oh
[09:20] <pitti> in test_system_driver_packages_chroot() there is no nvidia-experimental being set up
[09:20] <pitti> only in test_system_device_drivers_chroot()
[09:21] <pitti> so that somehow seems to leak to the other test
[09:21] <tseliot> pitti: also the error on arm64 seems to be different
[09:21] <tseliot> an AssertionError vs the KeyError on armhf
[09:21] <pitti> tseliot: probably the same issue, though -- the apt cache is bogus
[09:22] <tseliot> :/
[09:23] <pitti> aptdaemon and python-apt didn't change, but apt did
[09:25] <tseliot> pitti: shall we just skip the test for now? I'm trying to get a fix into wily before I actually SRU it
[09:25] <pitti> no, please don't skip it
[09:25] <pitti> this is an actual regression or bug somewhere which should be investigated
[09:26] <tseliot> no doubt about it being a bug that needs to be fixed
[09:27] <pitti> and it's not likely to be specific to armhf, I guess it would randomly occur on any arch; so doing a few test builds in wily-proposed locally would be a good first step?
[09:27] <pitti> the fix is committed to git already, so you can SRU it anyway
[09:28] <tseliot> pitti: ok, it works for me then
[09:28] <dholbach> flexiondotorg, will take a look
[09:29] <flexiondotorg> dholbach, Thanks!
[10:03]  * zyga recalls a discussion about [dg]conf sandboxing 
[10:03] <zyga> and recalls the path issue
[10:04] <zyga> and recalls windows virtual store feature
[10:04] <zyga> http://www.codeproject.com/Articles/66275/Windows-Vista-File-and-Registry-Virtualization
[10:25] <dholbach> LocutusOfBorg1, I'll update the changelog entries in the patches on 1417563, ok?
[10:42] <jamespage> anyone know whether its possible to use multicast on the launchpad builders?
[10:42] <jamespage> (context - http://paste.ubuntu.com/11077249/ - test failure in designate)
[10:43] <jamespage> interestingly that works just fine in a virtualized PPA builder
[10:50] <cjwatson> jamespage: don't think we really define that either way
[10:50] <cjwatson> that's a kernel module, I suppose?
[10:51] <jamespage> cjwatson, maybe - I was just surprised by the diff between virtualized ppa and distro builders
[10:52] <cjwatson> jamespage: well, everything will become more like the former soonish
[10:52] <cjwatson> it's a bit odd, I would have expected that kind of module to be autoloaded IIRC
[10:54] <jamespage> cjwatson, it might be the SO_REUSEPORT flag that's actually prohibited
[10:54] <jamespage> that does have some security implications I guess
[10:55] <jamespage> cjwatson, what kernel do the distro builders run on?
[10:55] <cjwatson> jamespage: look at the top of any build log
[10:55] <jamespage> yeah - sorry - just realized that
[10:55] <jamespage> its 3.2.0
[10:56] <cjwatson> right, and reuseport was 3.9
[10:56] <jamespage> cjwatson, yeah - https://git.openstack.org/cgit/openstack/designate/commit/?id=c09a295c403e19811bf748d88155b368412c31bd
[10:56] <jamespage> looks like upstream have a workaround
[10:56] <jamespage> picking that now
[10:56] <cjwatson> and the virt builders are 3.13
[10:58] <cjwatson> oh, right, the non-virt builders are still on precise base systems
[10:59] <cjwatson> we won't be fixing that directly, we'll be moving all builds into scalingstack architecture by architecture instead
[10:59] <cjwatson> (well, some of the non-virt builders, it varies)
=== MacSlow is now known as MacSlow|lunch
[11:04] <LocutusOfBorg1> dholbach, please hold on, I can update them :)
[11:05] <LocutusOfBorg1> seems that Debian has new releases ready
[11:07] <dholbach> LocutusOfBorg1, it's done already
[11:25] <dholbach> @pilot out
=== udevbot changed the topic of #ubuntu-devel to: Archive: wily open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
=== MacSlow|lunch is now known as MacSlow
[12:40] <LocutusOfBorg1> dholbach, thanks!
[12:41] <dholbach> anytime
[12:41] <pitti> smoser: hey Scott! do you plan to merge cloud-utils with Debian? (I'm interested in the fix for debian bug 783826), or is cloud-utils independently maintained in Ubuntu?
[12:41] <ubottu> Debian bug 783826 in cloud-utils "cloud-utils: growpart uses deprecated sfdisk options" [Important,Fixed] http://bugs.debian.org/783826
=== _salem is now known as salem_
=== rbanffy_ is now known as rbanffy
[13:03] <cyphermox> good morning!
[13:03] <cyphermox> @pilot in
=== udevbot changed the topic of #ubuntu-devel to: Archive: wily open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: cyphermox
[13:05] <smoser> pitti, i have a fix for that . do we have htat sfdisk in ubuntu now?
[13:06] <pitti> smoser: in wily-proposed
[13:06] <smoser> ok. let me see if i can't get it uploaded.
[13:06] <pitti> smoser: it doesn't migrate as it curently unconditionally Breaks: cloud-utils; that'll become versioned once cloud-utils gets fixed
[13:07] <pitti> smoser: i. e. it's "safely" stuck in -proposed, I mostly wanted to know how we apply the fix
[13:11] <smoser> cloud-utils is in ubuntu, debian maintain separately.  i should probably look to merge with them at some point. lp:~smoser/cloud-utils/growpart-sfdisk-2.26 has the fix .
[13:13] <pitti> smoser: ah, you developed that independently? fedora and Debian have a fix too
[13:15] <pitti> smoser: ok, thanks! I'll adjust the Breaks: in util-linux once this hits wily, then it can migrate
[13:18] <smoser> pitti, well, i kind of re-impleented what htey had.
[13:19] <smoser> this new path with sfdisk 2.26 actually gets us to a point where we could use sfdisk for gpt partition table growth also.
[13:27] <xnox> doko: can you make -Wabi the default in debian & ubuntu and then grep logs / make buildd log scanner pick them up ( https://qa.debian.org/bls/ ) i guess it would already, no?
[13:29] <doko> xnox, did you check, what it will pick up? because nobody did this experiment
[13:30] <xnox> doko: well, actually that's the wrong one. I'm after -Wabi-tag as per dual abi docs https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html
[13:31] <xnox> doko: boost started to intentionally use 03 abi string et.al. in a few places because they started to get bug reports about mixed abi.
[13:31] <xnox> or rather use things that didn't change abi.
[13:31] <xnox> Not all uses of the new ABI will cause changes in symbol names, for example a class with a std::string member variable will have the same mangled name whether compiled with the old or new ABI. In order to detect such problems the new types and functions are annotated with the abi_tag attribute, allowing the compiler to warn about potential ABI incompatibilities in code using them. Those warnings can be enabled with the -Wabi-tag option.
[13:32] <xnox> that's what i'm afraid off.... when symbol names mangle the same way, but are in fact different.
[13:32] <doko> argh
[13:32] <xnox> doko: looking at fedora they did f22 release with gcc-5 but changed _GLIBCXX_USE_CXX11_ABI to be 0
[13:32] <doko> no, cxx11 symbols mangle differently
[13:32] <xnox> and they ware doing f23 release with _GLIBCXX_USE_CXX11_ABI to 1. Not sure if that's good or not.
[13:33] <doko> yes, they didn't have the time
[13:33] <doko> suse is doing it directly
[13:33] <xnox> "for example a class with a std::string member variable will have the same mangled name whether compiled with the old or new ABI." -> surely things will explode if something uses that member variable in 03 & 11 context, no?!
[13:35] <smoser> pitti, just realized util-linux should break cloud-guest-utils, not cloud-utils. i think.
[13:35] <pitti> smoser: ah, Debian didn't split it; sure, I'll adjust that together with the versioned breaks: then
[13:37] <doko> xnox, who says this? note, that currently can't check this without a custom build, had to disable the dual abi
[13:40] <xnox> doko: call me conservative, but when upstream docs say "things can break" i give them a benefit of a doubt that "the world will be on fire"
[13:40] <xnox> ... and given latest election results, we are all conservative here in the UK, supposedly. ( /me ponders if Laney will find this comment funny )
=== elopio_ is now known as elopio
=== marcusto_ is now known as marcustomlinson
[14:05] <doko> xnox, which upstream, boost or libstdc++?
[14:08] <xnox> doko: boost.
[14:08] <xnox> doko: libstdc++ did it for e.g. exceptions. (internally)
[14:09] <xnox> doko: well, some portions of boost upstream (maintiner of boost-filesystem for example did that)
[14:09] <xnox> but they do believe it is not sustainable.
[14:10] <doko> yes, the old experimental c++11 abi and the new stable c++11 abi are not compatible
[14:10] <doko> that's the reason why I disabled the dual abi for now
[14:28]  * Laney votes for xnox 
[14:47] <infinity> Unit193: It's in the trusty branch.
=== dholbach_ is now known as dholbach
[15:10] <bdmurray> mpt: Do you have a suggestion on what color to use for Wily in the Error Tracker?
[15:12] <mpt> bdmurray, the current sequence goes through the primary and secondary colors ROYGBV … Have we gone through a complete cycle of that? (I don’t remember, and can’t tell while bug 1073560 and bug 1053410 are unfixed)
[15:12] <ubottu> bug 1073560 in Errors "Legend doesn't scale to the number of versions shown" [Medium,Confirmed] https://launchpad.net/bugs/1073560
[15:12] <ubottu> bug 1053410 in Errors "Graph doesn't go back as far as the first recorded errors" [Low,Triaged] https://launchpad.net/bugs/1053410
[15:13] <mpt> bdmurray, if we haven’t, the answer is easy. :-) If we have, maybe repeat the cycle but go lighter
[15:14] <mpt> (since “by 12.04 standards” makes hardly any difference any more)
[15:14] <bdmurray> mpt: 15.04 is the bright green https://errors.ubuntu.com/?release=Ubuntu%2015.04&period=day
[15:15] <mpt> Ah, right, so we’ve already started the “go lighter” cycle, since 12.04 was dark green
[15:16] <mpt> which means that Wily would be … light blue?
[15:16] <mpt> a lighter blue than 12.10
[15:24] <ogra_> pitti, dont you like #snappy anymore ?
[15:24] <ogra_> :)
[15:29] <pitti> ogra_: ah, must have lost it in last bip reconnect, sorry
[16:22] <doko> jamespage, maven mismatches ...
=== d_ed is now known as d_edt
=== d_edt is now known as d_ed
=== sforshee` is now known as sforshee
[20:41] <markelite> UK
[20:42] <markelite> no, ignore that
[20:42] <elfy> ok
[20:43] <smoser> is it sane/possible to Recommends with an |
[20:43] <smoser> i'd like:
[20:44] <smoser> Recommends: util-linux (>= 2.26) | gdisk
[20:53] <smoser> slangasek, ^ ?
[20:53] <slangasek> smoser: that's legitimate, sure
[20:54] <smoser> ok. thanks.
[20:54] <lifeless> IIRC left hand is chosen in the absence of any other constraints
[20:54] <smoser> yeah, that shwat i thought
[20:54] <slangasek> yes
[20:55] <slangasek> so in this case you probably want gdisk | util-linux (>= 2.26), to force install of gdisk to satisfy the recommends on those systems too old to have util-linux 2.26
[20:56] <smoser> ?
[20:56] <smoser> really ?
[20:56] <smoser> i dont follow that.
[20:56] <smoser> if the left hand side matches (util-linux >=2.26) then that is preferable.
[20:57] <smoser> no?
[20:58] <smoser> oh well. /me assumes slangasek is right and uploads and goes afk
[20:59] <smoser> pitti, just uploaded 0.27-0ubuntu16 which should work
[20:59] <slangasek> smoser: if util-linux 2.26 is already installed, the recommends is a no-op
[20:59] <slangasek> but if it's not installed that probably means it's not available
[20:59] <slangasek> smoser: however this is all a corner case
[21:00] <smoser> k. thanks.
=== mwhudson_ is now known as mwhudson
=== salem_ is now known as _salem
=== _salem is now known as salem_
=== salem_ is now known as _salem
=== _salem is now known as salem_
=== greyback__ is now known as greyback