=== _salem is now known as salem_
=== salem_ is now known as _salem
[00:36] <xnox> tedg: it does boot here. Is that x86 or armhf? which rev # & channel?
[00:36] <xnox> (well it did, whenever i last re-initialised emulators locally ~ friday)
[00:36] <xnox> i guess i didn't catch pitti.
[01:00] <rcj> infinity, you said 'What you want here is "foo-lts-trusty, Depends: foo" and "foo, Breaks/Replaces: foo-lts-trusty (<< transitional version)"'
[01:01] <rcj> infinity, for the other transitional packages they have Conflicts/Replaces rather than Breaks/Replaces and only the conflicts limits the package by providing the transitional version number.
[01:01] <rcj> Not sure what is needed.
[01:02] <infinity> rcj: Which "other transitional packages"?
[01:02] <infinity> rcj: The proper way to do file overwrites is a versioned Breaks/Replaces.  It used to be a versions Conflicts/Replaces many years ago, and some people are resistant to change. :P
[01:03] <rcj> infinity, okay.  The open-vm-tools package had a open-vm-dkms transitional package when I picked it up.
[01:04] <rcj> infinity, and the breaks and replaces both will specify the version, correct?
[01:04] <infinity> rcj: Yeahp.
[01:04] <rcj> infinity, thank you.
[01:04] <infinity> rcj: Yeah, ignore the ickiness of that old transitional package, it's a little goofy.
[01:05] <rcj> infinity, I'll leave that alone as I add the new ones
[03:47] <hamiltont> cjwatson: online?
[04:02] <TheMuso> hamiltont: He is likely asleep atm, you may want to try in 5-6 hours if you are around.
[04:02] <hamiltont> thanks! No rush
[04:18] <pitti> Good morning
[04:19] <pitti> xnox: thanks for the heads-up; I can't say I much like the startpar task patch either, I just really wonder why it doesn't work
[04:45] <pitti> infinity: FYI, I see the bug with eglibc's autopkgtest failure, fixing now; sorry about that
=== _salem is now known as salem_
=== salem_ is now known as _salem
=== ufukle is now known as lisca
=== marcusto_ is now known as marcustomlinson_
[06:10] <slangasek> hrm.  Why does 'dch -r' think the current target release is called 'the'?
[06:15] <dholbach> good morning
[06:22] <didrocks> hey dholbach!
[06:23] <dholbach> salut didrocks
[06:23] <pitti> hey dholbach
[06:23] <pitti> bonjour didrocks
[06:23] <dholbach> hey pitti
[06:23] <dholbach> @pilot in
=== udevbot changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: dholbach, jdstrand
[06:23]  * pitti hugs dholbach
[06:23] <didrocks> Guten Morgen pitti :)
[06:23] <pitti> dholbach: morning gymnastics^Wsponsoring, eh? :-)
[06:24] <dholbach> yeah :-)
[06:25] <pitti> does anyone know, where can I find a list of supported frameworks for a click's "framework" field?
[06:29] <pitti> ah, found https://wiki.ubuntu.com/Click/Frameworks after some googling
[06:30] <pitti> that still doesn't explain how they are related, i. e. if ubuntu-sdk-14.04-qml-dev1 is a subset or a superset of ubuntu-sdk-14.04
[07:18] <pitti> cjwatson: how can I map a click framework name such as ubuntu-sdk-14.04-qml-dev1 to a set of packages that must be installed (like ubuntu-sdk-libs)? I don't see this in Provides: or the touch seeds
[07:23] <pitti> cjwatson: or, I figure a click package's autopkgtest should perhaps just have the correct one in its test deps
=== psivaa-afk is now known as psivaa
[07:55] <mapreri> pitti: what do you mean with "if pencil2d's programs/CLI is the same as pencil2d's?"
[07:56] <pitti> mapreri: if pencil's programs are called the same way (option names, file formats, etc. -- I don't know what it is) as pencil2d's, then a transitional package makes sense
[07:56] <pitti> mapreri: if it's something different, then we should just drop the pencil package
[07:56] <pitti> mapreri: so in this case, as it's a GUI app, it's mainly about file format compatibility
[07:57] <mapreri> pitti: pencil2d is the pencil fork. For now the interface is quite similar. The file format is the same, yes (as far as I can see they are moving to a new file format, but keeping backward-compatibility)
[07:58] <pitti> mapreri: right, then making the pencil source build a transitional pacakge to pencil2d only makes sense to me
[07:58] <mapreri> Withe commit like https://github.com/pencil2d/pencil/commit/23f40954299c77730e37b8e83bca0c2555035f27 but the old format is keep
[07:58] <pitti> mapreri: note that you will also need some Breaks:/Replaces: on pencil2d
[07:58] <pitti> mapreri: which you can do on the Debian side (htey are harmless there)
[07:59] <mapreri> pitti: do you know of a way to have an ubuntu-specific control file on debian? (like the series.ubuntu for the patches)
[08:00] <pitti> mapreri: in principle you could even add the transitional package to the Debian pencil2d source and only build that binary on Ubuntu; but it's a bit of a hack, and we can just keep the pencil source until the next LTS
[08:01] <pitti> mapreri: no, that doesn't work; but you can do something like: if dpkg-vendor --is ubuntu; then export DH_OPTIONS=-Npencil
[08:01] <pitti> mapreri: then the pencil transitional will only be built on Ubuntu, not on debian
[08:02] <mapreri> uh, great. in the meantime I file a bug for the pencil removal
[08:03] <pitti> mapreri: for conditional dependencies you could use substvars, but IMHO it's not worth the effort; having the Breaks/Replaces: on Debian is no big deal
=== zequence_ is now known as zequence
[08:25] <tvoss> cjwatson, doko seems like the symbols for std::once and std::once_callable have changed and libstdc++ has been updated in the archive to 4.9
[08:47] <Mirv> it'd seem to me the new gcc-4.9 4.9.0-6ubuntu1 breaks phone
[08:48] <Mirv> I mean 4.9.0-7ubuntu1. apt-get dist-upgrade + reboot from the morning's image (includes gcc + pulseaudio updates) gives me just google logo, downgrading to 4.9.0-6ubuntu1 and it works again
[09:04] <doko> tvoss, is this using the package in -proposed?
[09:04] <doko> Mirv, is this a runtime issue, or a build issue?
[09:04] <tvoss> doko, I don't think so, -proposed is not enabled by default
=== chrisccoulson_ is now known as chrisccoulson
[09:06] <ogra_> tvoss, in silos it was accidentially disabled ... if that build is from a silo PPA you might want to re-try (all silo PPAs now use proposed by default again as they should)
[09:06] <tvoss> thostr_, ^
[09:06] <doko> tvoss, ARM only?
[09:06] <Mirv> doko: this what I'm seeing is a runtime issue. everyone with a phone should be able to reproduce it by flashing the latest image and upgrading it to the latest gcc
[09:06] <tvoss> doko, seems so
[09:06] <tvoss> thostr_, is https://launchpadlibrarian.net/177744514/buildlog_ubuntu-utopic-armhf.unity-scope-click_0.1%2B14.10.20140616-0ubuntu1_FAILEDTOBUILD.txt.gz from a silo build?
[09:07] <thostr_> tvoss: yes
[09:07] <thostr_> can try to rebuild now however.. ogra_ when did you change the setting?
[09:07] <doko> there is a binutils issue reported yesterday by Laney, which is fixed by the current upload. so please lets see wait for this build
[09:08] <ogra_> thostr_, robru did last night (at least he was supposed to, i didnt check all silos) ... which silo was that i can take a look
[09:09] <pitti> dpm: hm, do you know why https://translations.launchpad.net/ubuntu/utopic/+source/dialer-app is still empty? shouldn't that have the template from yesterday's upload?
[09:09] <pitti> dpm: or does this again need to be approved?
[09:09] <thostr_> ogra_: silo 18 that is
[09:10] <pitti> dpm: oh indeed - https://translations.launchpad.net/ubuntu/utopic/+source/dialer-app/+imports -- can you hit the magic buttons there?
[09:10] <ogra_> thostr_, has proposed on right now
[09:10] <pitti> dpm: (I hope it will still make today's full LP export, otherwise we'll need to wait a week or so)
[09:10] <ogra_> (i sadly cant tell *when* it was switched on)
[09:11] <thostr_> ogra_: so, can I trigger a rebuild now?
[09:11] <ogra_> yep
[09:12] <thostr_> ogra_: building...
[09:12] <Laney> doko: yay
[09:12] <ogra_> :)
[09:12] <Laney> did you upload it to sid too?
[09:12]  * ogra_ crosses fingers
[09:12] <dpm> pitti, argh, yes, every new template needs to be approved (just did that now). I had followed the conversation on ubuntu-phone, but I hadn't realized the upload had already happened
[09:12] <dpm> pitti, let me chech when the export is scheduled to start
[09:12] <doko> Laney, yes
[09:12] <mapreri> pitti: like this? http://anonscm.debian.org/gitweb/?p=collab-maint/pencil2d.git;a=commitdiff;h=9620a0cf477847f221b9ee0bc1f9493bb4bfc4ed
[09:13] <ogra_> sil2100, see above :)
[09:13] <ogra_> (the translations, not my PPA conversation)
[09:13] <dpm> pitti, so the export starts at 10:30 UTC today and we should be good to go
[09:13] <pitti> dpm: *phew*, thanks :)
[09:14] <cjwatson> pitti: use "click chroot -aARCH -fFRAMEWORK create" to create the chroot - it knows which packages are supposed to be used
[09:14] <pitti> cjwatson: ah, thank you
[09:15] <doko> tvoss, is this reproducible with the unity-scope-click package in utopic?
[09:15] <cjwatson> pitti: not currently exported otherwise
[09:15] <pitti> mapreri: "Ubuntu has had"
[09:15] <tvoss> doko, best to ask thostr_
[09:15] <mapreri> uh, right...
[09:15] <pitti> mapreri: Replaces/Breaks versions need to be (<< version_of_transitional_package), not these old ones
[09:16] <doko> thostr_, ^^^
[09:16] <thostr_> doko: yes, IIRC
[09:16] <tvoss> thostr_, could you share the respective MP that triggered the build failure in the silo?
[09:16] <pitti> mapreri: also, the debian/changelog in that commit is a total mis-match
[09:17] <pitti> mapreri: this is perhaps using git-dch and you forgot to revert, or something?
[09:17] <mapreri> pitti: yes, the changelog isn't related, I commit it without thinking (commit -a -.-)
[09:17] <thostr_> tvoss: for click that is https://code.launchpad.net/~dobey/unity-scope-click/merge-devel/+merge/223276
[09:17] <pitti> mapreri: otherwise LGTM, but the B/R versions need fixing
[09:18] <sil2100> ogra_: I must say I'm a bit confused with this
[09:24] <seb128> ev, bdmurray: hey, https://errors.ubuntu.com/?package=unity8&period=year ... that seems buggy to me, is there a known issue? 1 unity8 report as a total over all releases seems too low?
[09:25] <seb128> even with the db change, we for sure got more than 1 report of issue since
[09:29] <ogra_> sil2100, the translation files are not exported yet by the app packages
[09:30] <ogra_> so we might be missing more than just dialer atm
[09:32] <seb128> tvoss, hey, do you know if that's a known issue? http://paste.ubuntu.com/7657512/
[09:33] <tvoss> seb128, nope, haven't seen that before. ricmm ^
[09:34] <seb128> tvoss, sorry, ricmm just replied on -touch, I asked there before noticing you were not on the channel
[09:34] <tvoss> seb128, ah, xchat keeps on forgetting about my channels :(
[09:58] <ogra_> doko, could it be that we get C++ issues with the new libgcc ?
[09:59] <ogra_> i see several reports of phnes stopping working after upgrading only that package
[09:59] <doko> ogra_, I think it's a libstdc++6 issue, but will have to confirm
[10:00] <ogra_> oSoMoN, ^^
[10:00] <doko> so just replacing libstdc++6 with the old one should be enough
[10:00] <oSoMoN> ogra_, doko: upgrading libgcc1 triggers the upgrade of libstdc++6 too, so that sounds right
[10:05] <tvoss> doko, the issue with the missing symbols for std::*once is reproducible with https://code.launchpad.net/~thomas-voss/dbus-cpp/bump-so-name-and-major-version/+merge/223224
[10:05] <tvoss> too
[10:05] <tvoss> doko, see https://jenkins.qa.ubuntu.com/job/dbus-cpp-utopic-armhf-ci/17/console
[10:07] <Wellark> I'm also seeing these: https://launchpad.net/~ci-train-ppa-service/+archive/landing-002
[10:07] <Wellark> libprocess-cpp in the archive is broken
[10:07] <Wellark> or missing symbols that is
[10:07] <ogra_> doko, looks like more fallout ^^
[10:08] <tvoss> Wellark, it's not process-cpp missing symbols, but the underlying libstdc++
[10:08] <Wellark> tvoss: well, sure. but my trail ends with process-cpp :)
=== Ghoul_ is now known as Aetherspawn-
[10:08] <tvoss> Wellark, sure
[10:10] <Wellark> but that would mean that the archive is broken..
[10:10] <tvoss> Wellark, yup
[10:10] <ogra_> one lib is ...
=== vrruiz_ is now known as rvr
[10:21] <dholbach> @pilot out
=== udevbot changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: jdstrand
=== MacSlow is now known as MacSlow|lunch
[10:24] <doko> tvoss, ogra_: do you have a fast arm machine for a build? I only have porter-armhf which is a slow dual core
[10:24] <tvoss> doko, I'm building on the phone
[10:25] <tvoss> doko, my chromebook is in use by the family
[10:25] <ogra_> i use chroots since a while and my chromebook is collecting dust in the basement
[10:26] <ogra_> (and on saucy or something, would need a few hours for updating etc)
[10:26] <sil2100> dholbach: o/ just reminding about adding me for next month!
[10:27] <ogra_> doko, if sil2100 has a spare silo you could use distro builders for that inside a silo PPA
[10:27] <doko> no, havingPPA's myself
[10:27] <sil2100> ogra_, doko: for such occassions we always have landing-000 PPA
[10:27] <ogra_> doko, using HW builders ?
[10:28] <cjwatson> ogra_: yes
[10:28] <cjwatson> (~ubuntu-toolchain-r)
[10:28] <ogra_> ah
[10:48] <doko> Laney, new binutils in -proposed, can you recheck?
[10:50] <Laney> ok
[10:59] <Laney> doko: looking good so far
[11:08] <Laney> doko: yep, worked
[11:08] <Laney> ta
[11:10] <doko> tvoss, ^^^so rechecking with the updated binutils would be good. still doesn't solve the libstdc++6 issue, my test build is however running
[11:10] <tvoss> doko, ack. thostr_ could you kick a rebuild of your ppa? should get the new binutils from proposed
[11:16] <shadeslayer> pitti: did you fix something with autopkgtest? :) seems like debhelper is being installed by default now
[11:34] <pitti> shadeslayer: I fixed build-depends-indep: handling this morning; but this would have entirely crashed the test very early unless it happened to have a trailing comma
[11:34] <pitti> shadeslayer: debhelper isn't installed by default
[11:34] <pitti> shadeslayer: which test was that?
[11:34] <shadeslayer> https://jenkins.qa.ubuntu.com/job/utopic-adt-killbots/2
[11:34] <shadeslayer> https://jenkins.qa.ubuntu.com/job/utopic-adt-killbots/1 was the one that failed
[11:35] <pitti> shadeslayer: that didn't fail due to debhelper, but UTF-8 in debian/control
[11:35] <pitti> shadeslayer: I fixed that two days ago, and rolled it out this morning
[11:35] <pitti> i. e. handling UTF-8 files under C locale (argh)
[11:36] <shadeslayer> ah ok then
[11:39] <jdstrand> @pilot out
=== udevbot changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
[11:45] <seb128> arges, hey, could you review the libgphoto SRU for trusty? it's a follow up to fix a typo in the current proposed version
[11:46] <seb128> if somebody from the SRU team could also do copies to updates that would be nice
[11:46] <seb128> some items at 13 days old and validated
[11:46] <seb128> slangasek, bdmurray, infity, stgraber, ...: ^
[11:48]  * cjwatson does a few
[11:48] <seb128> cjwatson, thanks
[11:59] <tvoss> doko, so the binutils change did not help. Seems like we need to rebuild process-cpp
[11:59] <doko> tvoss, ?
[12:00] <tvoss> doko, thostr_ tried rebuilding his silo with only the changed binutils from proposed
[12:18] <doko> cjwatson, tvoss: now explicit deps on g++-4.9 ?
[12:19] <cjwatson> doko: Yes, it gives them control over when to switch given that it appears they need to change SONAME at the same time
[12:19] <cjwatson> doko: We've made it clear that it's not carte blanche to stay with old GCC versions
[12:20] <cjwatson> It's just timing control
[12:22] <doko> ok
[12:23] <cjwatson> And limited to those cases where this control's actually needed - i.e. we know we're using experimental features
=== davidcalle_ is now known as davidcalle
=== MacSlow|lunch is now known as MacSlow
=== _salem is now known as salem_
[13:19] <shadeslayer> pitti: btw I don't suppose you know of any dep 3 parser
[13:19] <shadeslayer> for patches
[13:25] <arun_> hello guys !!! I am having some verification problem with reprepro thing !!!1
[13:33] <Saviq> lool, hey, do you think you could package doxyqml 0.2.0 please https://github.com/agateau/doxyqml/releases ?
[13:33] <Saviq> lool, you seem to be the maintainer :)
[13:48] <lool> Saviq: hehe
[13:48] <lool> Saviq: sure
[13:48] <Saviq> lool, got a source built if you want it :)
[13:49] <Saviq> lool, only change in packaging seems to be tests are split into unit and functional
[14:11] <pitti> shadeslayer: no, I don't know of any
[14:14] <arges> seb128: ok i'll look at libgphoto2
[14:15] <seb128> arges, thanks
[14:15] <pitti> thanks arges; sorry for the typo
[14:15] <arges> : )
[14:17] <doko> Laney, can I close 1328838?
[14:17] <shadeslayer> pitti: thx
[14:17] <Laney> bug 1328838
[14:17] <ubottu> bug 1328838 in gcc-4.9 (Ubuntu) "Can't x-build ubuntu-system-settings with 1.0.4ubuntu1: /usr/lib/arm-linux-gnueabihf/libapt-pkg.so: undefined reference to `std::__throw_out_of_range_fmt(char const*, ...)@GLIBCXX_3.4.20'" [Undecided,New] https://launchpad.net/bugs/1328838
[14:17] <Laney> doko: yep
[14:17] <bdmurray> seb128: I don't know of any issue that would make the unity8 numbers low
[14:17] <Laney> wait
[14:17] <Laney> oh yes, since the revert
[14:17] <Laney> yes
[14:18] <bdmurray> seb128: looking at the old database the highest occurring crash over the year only has 43 occurrences
[14:18] <doko> well, we need to keep these in sync for cross building
[14:18] <Laney> yep
[14:19] <Laney> you made that true again
[14:19] <seb128> bdmurray, hum, ok, that seems weirdly low, seeing the number of mentions we get on IRC for example
[14:20] <mlankhorst> darktama: it seems to be caused by the i2c support
[14:20] <Laney> mlankhorst: !!!
[14:20] <Laney> I forgot to try your thing
[14:20] <Laney> do you still want me to?
[14:20] <mlankhorst> oops wrong window :P
[14:20] <mlankhorst> go for it, not sure how useful it is though
[14:20] <bdmurray> seb128: "number of mentions we get on irc"?
[14:21] <Laney> umm
[14:21] <Laney> if not useful then I won't bother
[14:21] <seb128> bdmurray, we have people mentioning unity8 crashes and reporting them
[14:21] <seb128> bdmurray, I just wonder where they end up if not on e.u.c
[14:22] <mlankhorst> Laney: yeah I did some fixes that went in the right direction, but threading's hard :P
=== Ursinha is now known as Ursinha-afk
[14:23] <bdmurray> seb128: In utopic whoopsie now logs the OOPS ID of a reported crash in /var/log/syslog so we could ask for the OOPS ID and from them and figure it out.
[14:23] <bdmurray> seb128: there is a pending SRU for that in Trusty too
[14:24] <seb128> bdmurray, ok, thanks
=== Ursinha-afk is now known as Ursinha
[14:34] <doko> cjwatson, so my gcc-4.9 test build is ok. can we copy the binaries from the ubuntu-toolchain-r/ppa PPA into -proposed once the i386 build finishes?
[14:35] <doko> tvoss, thostr_, ogra_, Mirv: the ubuntu-toolchain-r/ppa PPA has a fixed gcc-4.9
[14:36] <brendand> stgraber, why am i getting these errors? http://paste.ubuntu.com/7658715/
[14:36] <thostr_> doko: so, ci should work now again?
[14:36] <doko> it is not yet in -proposed
[14:37] <stgraber> brendand: either because lxcbr0 doesn't exist or because your kernel somehow lacks veth support
[14:37] <stgraber> brendand: the latter tends to happen when you haven't rebooted your machine in a while + flushed all kernels from disk as veth.ko is no longer there to be loaded
[14:37] <brendand> stgraber, if lxcbr0 is supposed to be in ifconfig, then no i don't have it
[14:38] <brendand> stgraber, i did delete a lot of kernels recently
[14:38] <stgraber> brendand: ok, what LXC and Ubuntu version is that?
[14:38] <brendand> stgraber, utopic
[14:38] <stgraber> brendand: sudo status lxc-net
[14:39] <brendand> stgraber, lxc-net start/running
[14:39] <cjwatson> doko: Yes, should be fine, go for it
[14:39] <tvoss> doko, what was the issue in the end?
[14:39] <brendand> stgraber, version: 1.0.3-0ubuntu5build1
[14:39] <stgraber> brendand: can you pastebin /var/log/upstart/lxc-net.log?
[14:39] <stgraber> brendand: that version is a tiny bit old (I uploaded 1.0.4 last week) but that really shouldn't matter so we may as well figure out what happened before you upgrade
[14:39] <brendand> stgraber, doesn't seem to exist
[14:40] <stgraber> brendand: hmm, ok, odd. Can you try "sudo stop lxc-net && sudo start lxc-net" then, see what happens?
[14:40] <brendand> stgraber, whoops - just needed sudo: http://paste.ubuntu.com/7658732/
[14:41] <stgraber> brendand: ah, ok
[14:41] <stgraber> brendand: do you have bind9 or some other DNS server installed on that box that'd bind port 53 on all interfaces?
[14:41] <brendand> stgraber, yeah. for whatever reason i do have bind9
[14:42] <brendand> stgraber, remove it?
[14:43] <stgraber> brendand: yeah, remove it, make sure it's no longer running, then restart the lxc-net job, that should fix things.
[14:44] <stgraber> brendand: basically LXC starts a dnsmasq service for DHCP and DNS on lxcbr0, so if another daemon already claimed all interfaces, that fails, which in turn makes the rest of the job fail
[14:44] <stgraber> you're the second one reporting this happening though, so I'm starting to wonder if we somehow pulled bind9 into our base install by accident...
[14:45] <stgraber> not according to cdimage.u.c at least
[14:45] <tseliot> bdmurray: are you around?
[14:45] <bdmurray> tseliot: yes
[14:46] <tseliot> bdmurray: I have two packages associated with some SRUs. Can you help please? nvidia-prime (precise-proposed) [LP: #1326257, LP: #1296020], ubuntu-drivers-common (trusty-proposed) [LP: #1306928, LP: #1296020, LP: #1310023]
[14:46] <ubottu> Launchpad bug 1326257 in ubuntu-drivers-common (Ubuntu Trusty) "[nvidia-prime] Cannot adjust brightness in guest session and results in black screen while changing the resolution" [High,In progress] https://launchpad.net/bugs/1326257
[14:46] <ubottu> Launchpad bug 1296020 in ubuntu-drivers-common (Ubuntu Trusty) "[Asus U36JC] Non-existent display detected in both intel driver and nvidia driver (Optimus Laptop) (ubuntu trusty 14.04)" [Critical,In progress] https://launchpad.net/bugs/1296020
[14:46] <ubottu> Launchpad bug 1306928 in ubuntu-drivers-common (Ubuntu Trusty) "Broadcom STA driver gets autoinstalled on BCM4313, where it's no longer needed" [High,In progress] https://launchpad.net/bugs/1306928
[14:46] <ubottu> Launchpad bug 1310023 in ubuntu-drivers-common (Ubuntu Trusty) "14.04: Nvidia Prime is unable to switch to the Nvidia card" [High,In progress] https://launchpad.net/bugs/1310023
[14:46] <rcj> stgraber, Would you have time to look at a updated open-vm-tools for trusty for that SRU?  It's been uploaded to fix a breaks/replaces problem.
[14:47] <rcj> stgraber, or I can ask infinity since he raised the issue.
[14:48] <stgraber> rcj: looking
=== quadrispro_ is now known as quadrispro
[14:49] <bdmurray> tseliot: I'm still a bit swamped with the error tracker, but I'll try and have a look.
[14:49] <tseliot> bdmurray: thanks
[14:53] <stgraber> rcj: accepted
[14:54] <rcj> stgraber, excellent
[15:27] <thostr_> doko: any estimate when things should be finally fixed/landed in ci?
[15:29] <doko> thostr_, just copied
[15:30] <doko> tvoss, some binutils change between Jun 04 and Jun 12, feel free to pick one
[15:30] <thostr_> doko: so, rebuild should now work?
=== Laney is now known as mrage
[15:30] <doko> thostr_, you need to wait until the package is published
=== mrage is now known as Laney
[15:32] <thostr_> doko: once published, can you ping #ubuntu-ci-eng?
[16:09] <doko> thostr_, I'm afk now, please have a look yourself. they are published but not yet mirrored
=== salem_ is now known as _salem
[17:15] <tjaalton> cjwatson: hey, it's probably a normal feature that grub2 menu gfx operates very slowly on a highres framebuffer?
[17:15] <tjaalton> takes a while to redraw the screen
[17:15] <tjaalton> like on a 3200x1800 screen..
[17:17] <cjwatson> tjaalton: sometimes hard to get suitable acceleration in place
[17:18] <cjwatson> I improved some of that a while back but no doubt it could do with somebody sitting down for another profiling/optimisation pass ...
[17:19] <tjaalton> alright
[17:20] <tjaalton> I might have a go at some point
=== _salem is now known as salem_
[17:28] <ddsss> when packaging a .deb - is there a special directory I should use for an example config file?
[17:30] <jtaylor> using dh_installexamples is probably not wrong
[17:31] <infinity> ddsss: If it's an example strictly for the user's interest, /usr/share/doc/<package>/examples/ (which is where dh_installexamples will put it), if it's going to be used by the package (ie: a postinst does "cp example.conf /etc/example.conf"), it needs to be in /usr/share/<package> as the doc directory is pruged in some setups.
[17:32] <ddsss> infinity, does the same goes for an example upstart script?
[17:32] <infinity> ddsss: An example is an example, not sure the content makes a difference here. ;)
[17:32] <ddsss> infinity, gotcha. thanks!
[17:33] <infinity> ddsss: It's the intended use that matters, if the PACKAGE is referencing it, it can't be in doc, if it's just for the user's reading and learning pleasure, it belongs in doc.
[17:35] <ddsss> infinity, awesome. awesome to the max.
=== PaulW2U is now known as G4MBY
[18:03] <bdmurray> popey: do you have another test case for bug 1278780? I'm specifically looking to crash unit8.
[18:03] <ubottu> bug 1278780 in apport (Ubuntu) "apport takes too long to write crash report, appears to lock up phone" [High,Triaged] https://launchpad.net/bugs/1278780
[18:09] <sergiusens> slangasek jdstrand no rush on this one, but am I good to migrate back to gc golang? Or is the recommendation still being worked on?
[18:10] <slangasek> sergiusens: we have a long term plan to migrate to gc; I don't think we had settled whether we should start using it today in the absence of dynamic linking support
[18:10] <slangasek> I think I would prefer to see us continue with gccgo for right now, unless you're running into specific problems
[18:11] <sergiusens> slangasek: no, no problems at all on my side
[18:19] <popey> bdmurray: thats a while back, not had that recently, sorry.
[18:20] <bdmurray> popey: okay, thanks
[18:24] <popey> ogra_: looks like my booting got significantly worse after doing a completely clean install (and adding full disk encryption) http://people.canonical.com/~alan/bootcharts/deep-thought/deep-thought-trusty-20140616-4.png
[18:25] <ogra_> popey, heh, well, encryption ... gotta pay a price for that
[18:26] <ogra_> the gren grass on the right looks seriously worrying though
[18:26] <ogra_> your disk seems to be doing mad stuff there
[18:26] <popey> yeah, its bonkers
[18:27] <popey> might reboot a few times to get some more stats, later, after dinner
[18:27] <ogra_> yeah
[18:28] <ogra_> is it actually taking 1:30 til you have a desktop on screen ?
[18:28]  * ogra_ doubts that ... looks like it simply doesnt go into idle which keeps bootchart going on until it times out after 1:30
[18:30] <popey> ogra_: sometimes it is fine http://people.canonical.com/~alan/bootcharts/deep-thought/deep-thought-trusty-20140616-1.png
[18:30] <popey> <30s
[18:30] <popey> it may have been sat at the login screen#
[18:30] <ogra_> right
[18:31] <ogra_> well, that disk stuff deserves examination for sure ... you got something that peaks it every few seconds
=== salem_ is now known as _salem
=== _salem is now known as salem_
[18:37] <hallyn_> xnox: hey, did you get a chance to look at http://people.canonical.com/~serge/netcf-src-0.2.4/netcf_0.2.4-1.dsc ??
[18:37] <hallyn_> (for debian upload)
[18:46] <ddsss> are most ubuntu packages  - source packages? or binary ones?
[18:47] <infinity> ddsss: They're all both.  Source packages produce binrary packages.
[18:48] <ddsss> im trying to build a source package - sort of stuck.
[18:49] <infinity> ddsss: You probably want #ubuntu-motu
[18:50] <ddsss> infinity, what's that - beginners channel?
[18:50] <infinity> ddsss: They deal with beginner packaging issues there, yes.
=== roadmr is now known as roadmr_afk
=== salem_ is now known as _salem
=== _salem is now known as salem_
[20:22] <ddsss>  .deb source packages are not directly installable - right?
[20:22] <jpds> ddsss: Build the .deb with 'debuild'.
[20:23] <ddsss> jpds, what's the difference from c++ source files and deb-src sources?
[20:24] <jpds> ddsss: deb-srcs include the debian/ directory which explains how the .deb is built.
[20:25] <ddsss> jpds, so then someone else compiles deb-srcs packages for each platform?
[20:25] <jpds> ddsss: Someone else?
[20:25] <jpds> ddsss: We don't crowd-source the .deb building.
[20:26] <ddsss> jpds, I mean - isthere some automated UBuntu build-server or something?
[20:26] <jpds> ddsss: https://launchpad.net/builders
=== roadmr_afk is now known as roadmr
[20:27] <jpds> ddsss: build serverS - is the term you're looking for.
[20:28] <ddsss> jpds, aha - I see.
[20:30] <ddsss> jpds, so whebever someone "dputs"new source package - that triggers a build for various architectures?
[20:30] <jpds> ddsss: Yes.
[20:31] <ddsss> jpds, but people can also upload binary packages as well - right?
[20:31] <jpds> ddsss: No.
[20:32] <jpds> ddsss: Everything must be built from sauce.
[20:32] <ddsss> jpds, aha. I see.
=== salem_ is now known as _salem
[21:04] <ddsss> jpds, when building source package  - does it matter if program is using cmake instead of automake?
[21:07] <dobey> no
[21:08] <dobey> well unless you're trying to use autotools to build a cmake source
[21:08] <dobey> how to build the thing is defined in debian/rules
[21:08] <dobey> ddsss: you should probably be asking these questions in #ubuntu-packaging or #ubuntu-motu though
[21:09] <dobey> as was suggested earlier
[21:09] <ddsss> dobey, thanks. switching to  #ubuntu-packaging :)
[21:11] <hallyn> xnox: zul: all right i have a working libvirt-with-cgmanager.  jsut a few more tests then i intend to push to utopic.
[21:48] <jtaylor_> hm is the backport builddepending on backports issue fixed now?
[21:49] <jtaylor_> ah found the bug in my too large email archive, seems fixed, thx infinity  :)
[21:49] <stgraber> oh, is it? neat
[21:49] <jtaylor_> bug 888665
[21:49] <ubottu> bug 888665 in Launchpad itself "Backports can't build-depend on other backports" [High,Fix released] https://launchpad.net/bugs/888665
[23:00] <bluesabre> mdeslaur, I was wondering if there is anything holding these up?
[23:00] <bluesabre> https://bugs.launchpad.net/ubuntu/+source/xfce4-power-manager/+bug/1326740
[23:00] <ubottu> Ubuntu bug 1326740 in xfce4-power-manager (Ubuntu Trusty) "[SRU] Please backport xfce4-power-manager 1.2.0-3ubuntu6 to trusty" [Undecided,In progress]
[23:00] <bluesabre> https://bugs.launchpad.net/ubuntu/+source/light-locker-settings/+bug/1326741
[23:00] <ubottu> Ubuntu bug 1326741 in light-locker-settings (Ubuntu Trusty) "[SRU] Please backport light-locker-settings 1.2.1-0ubuntu2 to trusty" [Undecided,In progress]
[23:00] <bluesabre> let me know if you need anything additional from me :)
[23:08] <sarnold> bluesabre: someone needs to verify the SRUs https://wiki.ubuntu.com/QATeam/PerformingSRUVerification
[23:18] <Unit193> sarnold: A bit hard to do if it isn't in proposed yet.
[23:19] <sarnold> Unit193: oh :)
[23:19] <sarnold> I just saw the verification-needed tag and jumped straightaway to a conclusion..
[23:20] <Unit193> Can blame bluesabre for trying to confuse you. ;)
[23:20] <bluesabre> Ah, sorry about that, the SRU steps are a bit confusing :)
[23:30] <xnox> hallyn: \o/
[23:30] <xnox> hallyn: I thought i uploaded netcf, let me check my mails
[23:49] <hallyn> xnox: was that a "boy it's late i oughta be in bed' stretch?  :)
[23:49] <hallyn> xnox: rmadison -u debian didn't seem to show it, but maybe it's hung somewhere