[01:06] <asac> stgraber: cjwatson: i dont think i asked for two layers of feeding to stable. lets chat tomorrow about it; if you still have quotes from back then, it might help me rememeber what i thought/meant that got interpreted like this :)
[01:12] <stgraber> asac: the two layers is what you asked to setup for the current implementation (utopic-proposed gets manually copied to utopic which then gets manually copied to stable) as you wanted more control as to what gets into stable than just have stable be a straight alias for utopic or whatever our stable series is
[01:19] <asac> stgraber: ok, i sense there might be confusion again as i am thinking about devel and stable only... and not really utopicetc.
[01:20] <asac> stgraber: with rtm feeding into stable-proposed soon, i guess that part of straight alias is void anyway ?
[01:20] <asac> e.g. utopic feeds to devel-proposed/devel and ubuntu-rtm/utopic feeds into stable-proposed/stable?
[01:21]  * asac thinks it would be easier to refer to uptopic as our current devel archive series (which kind of already exists as an alias for upload and apt, no?)
[01:22] <asac> and ubnutu-rtm/utopic referring to our "stable" archive series for touch in that senes
[01:22] <asac> assuming we have branched ubuntu-rtm i would think that ubuntu/utopic -> devel-proposed ... and ubuntu-rtm/utopic -> stable-proposed
[01:24] <asac> anyway, lets sync tomorrow when colin is awake too
[01:25]  * asac waves; be back in a few hours
=== kaputtrepariert is now known as liscicka
[04:43] <constantine> Hey guys. I was just curious: do Canonical use -flto option to compile packages? It looks like good optimization, but looks like nobody uses it for unknown reasons.
[04:51] <constantine> Probably nobody uses it cuz -flto option(stands for "link time optimization") relatively fresh. If this is the reason, then I hope I give good hint, how to make Ubuntu a bit faster ;)
=== shuduo is now known as shuduo_afk
=== liscicka is now known as listicka
=== arrrghhhAWAY is now known as arrrghhh
=== xiterrex is now known as Guest55257
[07:19] <dholbach> good morning
[07:38] <dholbach> Noskcaj, any luck with 1346056?
[07:40] <LocutusOfBorg1> ScottK, you there?
[07:41] <LocutusOfBorg1> sorry but I didn't like too much your upload https://launchpad.net/ubuntu/+source/wxpython3.0/3.0.0.0+dfsg-2ubuntu1
[07:41] <LocutusOfBorg1> you fixed a bug in the _wrong_ place
[07:41] <LocutusOfBorg1> the build failure is a fault in wxwidgets, and it has been spotted because ubuntu has a _bad_ cairo version
[07:41] <LocutusOfBorg1> so the right fix is:
[07:41] <LocutusOfBorg1> fix 1353362
[07:43] <LocutusOfBorg1> wait for wxwidgets3.0 to be uploaded in debian (hint: the fix is there http://anonscm.debian.org/cgit/freewx/wx.git/commit/?h=wx3.0-debian&id=7bbc39c4018cee0fa2e021e58ea79bd5de241785 )
[07:43] <LocutusOfBorg1> and then rebuild wxpython.
[07:43] <tvoss> seb128, good morning. Not sure you are the right person to ask, but I was looking at the dbus spec and stumbled across GetConnectionCredentials, which would be super useful to have. However, it's only supported from ver 1.7 onwards. Do you know if we have plans to update to that version?
[07:43] <LocutusOfBorg1> this is a bug in _every_ package using wxwidgets, not just wxpython, so please next time fix it properly ;) many thanks
[07:44] <seb128> tvoss, see https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1320422
[07:44] <ubottu> Launchpad bug 1320422 in dbus (Ubuntu) "Please merge dbus 1.8.2-1 (main) from Debian testing (main)" [Low,Incomplete]
[07:45] <seb128> tvoss, tyhicks is/was working on it
[07:46] <tvoss> seb128, ack and thx, will follow up with him then
[07:46] <seb128> thanks
=== arrrghhh is now known as arrrghhhAWAY
=== JanC_ is now known as JanC
=== vrruiz_ is now known as rvr
[08:59] <Noskcaj> dholbach, Just got back into town then. I made a crappy patch to remove turbogears2, but i'm waiting for a responce from the debian zope team about transaction before i do anything
[09:00] <dholbach> Noskcaj, ok cool - maybe you can follow up on the bug report to just mention where things stand
[09:00] <Noskcaj> ok
[09:04] <cjwatson> asac: the series in the ubuntu-rtm distribution is called 14.09 rather than utopic - since RTM isn't tied to the Ubuntu release cycle I didn't think it made sense to tie it to Ubuntu release codenames
[09:06] <cjwatson> asac: stgraber set it up for me on Friday as ubuntu-touch/ubuntu-rtm/14.09-proposed and ubuntu-touch/ubuntu-rtm/14.09, on the system-image side; I think that makes sense provided that we also have a stable alias (and maybe a stable-proposed alias, I don't care much).  The utility of that is that in a few months' time we can potentially keep working on updates to 14.09 while also preparing for a switch to 14.12 or whatever
[09:10] <doko_> Noskcaj, the best thing is to package it yourself, and then point the team to it
=== doko_ is now known as doko
[09:11] <Noskcaj> doko, I wanted to check if there was a reason for no updates other than "maintainer MIA"
[09:12] <doko> Noskcaj, you didn't write that in your email
[09:12] <Noskcaj> no, i should have
[09:12]  * Noskcaj leaves to get food
[09:16] <doko> mlankhorst, mesa ping
=== tvoss is now known as tvoss|lunch
[10:32] <asac> cjwatson: ok thanks! devel{-proposed} points to ubuntu-touch/ubuntu/utopic{-proposed} accordingly i guess?
[10:34] <cjwatson> asac: Just ubuntu-touch/utopic-proposed but yes
[10:34] <cjwatson> I think
[10:34] <asac> ack
[10:35] <cjwatson> Not totally sure how that works, as it's not in the config file
[10:36] <cjwatson> Oh, well, it's in http://system-image.ubuntu.com/channels.json
[10:36]  * asac reads
[10:36] <cjwatson> Some of those have "alias" entries
[10:38] <asac> yeah see it
[10:40] <asac> think makes sense as it is now
[10:53] <jamespage> cjwatson, morning
[10:54] <jamespage> cjwatson, do you have any ideas as to why a block device might have a first partition which is identifying as a character device?
[10:54] <jamespage> (context - https://bugs.launchpad.net/charms/+source/ceph-osd/+bug/1343199)
[10:54] <ubottu> Launchpad bug 1343199 in ceph-osd (Juju Charms Collection) "Ceph charms die horribly when the device behaves badly" [High,Triaged]
[10:57] <cjwatson> jamespage: err doubleyou tee eff
[10:57] <cjwatson> jamespage: get a udev trace maybe?
[10:57] <jamespage> cjwatson,  that was my reaction as well
[10:57] <jamespage> cjwatson, will try to
[10:57] <cjwatson> jamespage: that really should be impossible regardless of the structure of the partition table, so while looking into the partition table might illuminate the problem somehow, the fix shouldn't be there
[10:58] <jamespage> cjwatson, ack
[10:59] <cjwatson> I don't even know how you'd do that in a udev rule if you wanted to.  Doesn't that come from the kernel?
[11:00] <cjwatson> udev_device_new_from_devnum is probably the starting point for tracking it down within udev
=== MacSlow is now known as MacSlow|lunch
=== LocutusOfBorg1 is now known as locutusborg
=== locutusborg is now known as LocutusOfBorg1
[11:15] <jamespage> cjwatson, I've asked that one of the reporters debug when it happens again
[11:33] <doko> xnox, did you finish your work on creduce?
=== _salem is now known as salem_
=== tvoss|lunch is now known as tvoss
=== retoad is now known as retoaded
=== MacSlow|lunch is now known as MacSlow
[14:46] <ScottK> LocutusOfBorg1: Changing package depends won't provide a missing build-depend, so your change is orthogonal to mine.  In any case, once there's a version in Debian that will build on Ubuntu too, mine should definitely by sync'ed over.  Additionally, I find your approach very aggressive and unwelcome.  Calm down.
[14:51] <Mirv> a packaging ack for unity8 desktop file moves + removal of an upstart job would be appreciated: https://ci-train.ubuntu.com/job/landing-006-2-publish/50/artifact/packaging_changes_unity8-desktop-session_1.0.12+14.10.20140811-0ubuntu1.diff
[15:02] <jamespage> doko, apologies its taken me so long to get to the libcommons-logging-java/tomcat8 unpicking
[15:03] <jamespage> but I've hopefully fixed that now so comp mismatches might be a little more usable shortly
[15:07] <doko> jamespage, \o/
=== arrrghhhAWAY is now known as arrrghhh
=== bfiller is now known as bfiller_afk
[16:41] <arrrghhh> infinity, bdmurray was there some specific bug that needed squashing before updating the meta-release-lts page?
[16:41] <bdmurray> arrrghhh: coincidentally, I just did that
=== Ursinha is now known as Ursinha-afk
[16:42] <arrrghhh> ohai look at that
[16:42] <arrrghhh> thank you :)
[16:43] <infinity> arrrghhh: There were bugs we fixed last week.  The only bug over the weekend was that it was a weekend.
[16:44] <arrrghhh> works for me.  thanks so much!
[16:45] <rbasak> bdmurray: nack on bug 1252843. AIUI, the exact same problem will occur on V->W upgrade when V is installed on an HWE stack.
[16:45] <ubottu> bug 1252843 in update-manager (nUbuntu) "Permits upgrade from an LTS system on an HWE stack to a broken system" [Undecided,New] https://launchpad.net/bugs/1252843
[16:46] <infinity> slangasek: I uploaded a new shim-signed to unblock your shim in proposed (and now my d-i and the kernel), but what I didn't check is if you need/want to mirror your fallback stuff in -signed as well somehow.
[16:46] <infinity> slangasek: (My upload was just a straight rebuild to fix deps)
=== dosaboy_ is now known as dosaboy
[16:46] <slangasek> infinity: um!
[16:46] <bdmurray> rbasak: okay
[16:46] <rbasak> bdmurray: correction. U->V when on a V HWE stack.
[16:46] <slangasek> infinity: can you remove this from the queue or is it too late?
[16:46] <slangasek> infinity: shim is SUPPOSED to block in -proposed until the binary signing is done
[16:46] <infinity> slangasek: My upload WOULD have been a straight rebuilt to fix deps, if it hadn't FTBFS. :P
=== mnepton is now known as mneptok
[16:47] <slangasek> infinity: yeah, please don't touch this
[16:47] <infinity> slangasek: Err, oh.  Well, it's blocking everything else. :/
[16:47] <slangasek> why are things blocking on it?
[16:47] <rbasak> bdmurray: I think this bug affected a large number of people. I saw many complaints about a blank screen on boot, and this was both reproducible and sounded like a reasonably common use case.
[16:47] <infinity> slangasek: Oh, shim-signed CONTAINS the blob.  Right.  I was thinking it was like grub/linux.  Derp.
[16:47] <rbasak> bdmurray: agree that there's no point fixing HWE stack upgrades on P for this bug, but we should do something about it for T HWE.
[16:48] <infinity> slangasek: It's blocking because shim-signed has a versioned dep on shim, which causes d-i to FTBFS, which blocks the kernel.
[16:48] <slangasek> blahhh
[16:48] <infinity> slangasek: Perhaps this should be staged in a PPA, if the turnaround time it on the order of weeks instead of hours.
[16:48] <slangasek> infinity: so in the future, I guess that means we should upload shim to a distro ppa instead of directly to -proposed, yeah
[16:48] <slangasek> any way that we can route around this for d-i in the present instance?
[16:49] <infinity> slangasek: Can I delete shim/shim-signed from -proposed so d-i is happy, and then we can sort out what to do?
[16:49] <slangasek> infinity: only if you can recover it
[16:49] <infinity> slangasek: I can delete and copy it back in, sure.
[16:49] <slangasek> this binary has been submitted to Microsoft, it needs to not get lost :)
[16:49] <infinity> slangasek: Deletion isn't particularly fatal.
[16:50] <slangasek> where do you stash it to make sure it doesn't disappear?
[16:50] <infinity> slangasek: The librarian.
[16:50] <infinity> slangasek: We can just copy it back in over itself, like nothing happened.
[16:51] <slangasek> ok
[16:51] <slangasek> then yes, as long as we're sure it'll find its way back safely when it needs to, go ahead
[16:52] <infinity> slangasek: So, a landing that takes this long is a poor fit for a CI silo, perhaps we should just give you a devirt of your own (or a foundations one, so it's not a bus issue), and use that for shim exclusively.
[16:52] <cjwatson> foundations devirt sounds good for this
[16:52] <slangasek> agreed
[16:55] <infinity> slangasek: Want to create a "Shim Staging" PPA under ~canonical-foundations and I'll do the magic to make sure it's distro-sane, and copy these binaries there, so we don't lose them?
[16:56] <infinity> s/lose/forget about/
[16:57] <slangasek> infinity: de-virt me? https://launchpad.net/~canonical-foundations/+archive/ubuntu/shim
[16:57] <infinity> slangasek: Fixing it up now.
[16:59] <slangasek> and copy done, I think: https://launchpad.net/~canonical-foundations/+archive/ubuntu/shim/+packages
[17:00] <infinity> Oh, I was just doing that.
[17:00] <infinity> Looks good.
[17:00]  * infinity cancels his.
[17:14] <LocutusOfBorg1> ScottK, sorry if I seemed aggressive, wasn't in my mind to be ;)
[17:15] <LocutusOfBorg1> this is why I ended my question with the ";)"
[17:15] <LocutusOfBorg1> sorry again
[17:16] <LocutusOfBorg1> and anyway, sorry but I didn't understand your answer :D
[17:16] <LocutusOfBorg1> wxpython3.0 depends on wxwidgets3.0 and the build failure was in wx code
[17:17] <LocutusOfBorg1> so the fix should be done in wxwidgets3.0, rather than in wxpython
=== bfiller_afk is now known as bfiller
[17:21] <LocutusOfBorg1> because a program that uses libwxgtk3.0-dev should automatically drag in the mesa-common-dev package, rather than adding it manually
[17:21] <LocutusOfBorg1> (please correct me if I'm saying something wrong, and sorry again for being unpolite, it wasn't in my intentions)
[17:23] <psivaa> cjwatson: infinity: i'm investigating an issue with the i386 desktop VM installations
[17:23] <psivaa> the installation with the preseed http://paste.ubuntu.com/8018805/ succeeds but the host machine is not able to ssh to the client VM
[17:24] <cjwatson> can you tell whether the client VM's network is up?
[17:24] <psivaa> purging openssh-server and reinstalling in the VM fixes the issue. i.e. being able to ssh from the host machine
[17:25] <psivaa> cjwatson: i think the network is up since i am able to apt-get update from it (after logging in to the Virt machine manager UI)
[17:25] <cjwatson> psivaa: was openssh-server definitely installed beforehand?  I don't think pkgsel/include is honoured by ubiquity (in general it doesn't have much in the way of package selection)
[17:25] <cjwatson> psivaa: or are you handling that in a late_command hook instead?
[17:26] <psivaa> cjwatson: yes, i think utah deals with it
[17:26] <psivaa> cjwatson: and i confirmed that openssh-server was installed and sshd was running
[17:26] <cjwatson> psivaa: ok, could you take a backup copy of /etc/ssh/ before purging openssh-server and compare it with what's there afterwards?
[17:26] <psivaa> but sshd_config was empty
[17:26] <cjwatson> empty?  blink
[17:26] <cjwatson> psivaa: can you point me at the utah code here?
[17:27] <cjwatson> psivaa: also any installer logs you have
[17:28] <psivaa> http://d-jenkins.ubuntu-ci:8080/job/psivaa-utopic-desktop-i386-smoke-default/6/artifact/log/utah-72-boot.log has the openssh-server installation details and let me point to the utah code for it
[17:28] <cjwatson> jibel: Any guesses as to why I might be getting this kind of result from adt-run with adt-virt-qemu?  http://paste.ubuntu.com/8018927/
[17:28] <cjwatson> I just added the ls -lR / whoami there to rule out obvious permission issues
[17:30] <cjwatson> psivaa: The only reason I can see in openssh-server.postinst why this could happen is if something had touched /etc/ssh/sshd_config before openssh-server was installed
[17:30] <ScottK> LocutusOfBorg1: OK.  I don't claim it was the best solution, just that it worked.
[17:31] <psivaa> cjwatson: http://bazaar.launchpad.net/~utah/utah/dev/view/head:/utah/provisioning/provisioning.py#L741 and http://bazaar.launchpad.net/~utah/utah/dev/view/head:/utah/provisioning/provisioning.py#L798 would be relevant
[17:31] <cjwatson> psivaa: If that file exists, the postinst just modifies it rather than writing a fresh one.  I guess I could change it to test for empty-or-zero-size, but this seems like it must be a bug somewhere else
[17:32] <cjwatson> No mention of sshd_config in utah though
[17:32] <psivaa> cjwatson: i dont think we are touching the file before installing and on amd64 installs this is not an issue. the sshd_config comes with the entries needed
[17:32] <cjwatson> Definitely no idea why it might be arch-specific
[17:32] <cjwatson> psivaa: So, literally empty /etc/ssh/sshd_config, i.e. zero-bytes?
[17:33] <psivaa> cjwatson: it was empty.. dint check if it was with zero-bytes
[17:33] <psivaa> I'll run another test to check
=== Ursinha-afk is now known as Ursinha
[17:43] <LocutusOfBorg1> thanks ScottK , I hope I can ask you to sync as soon as we fix it in debian :) have a good day
[17:44] <ScottK> LocutusOfBorg1: Yes, I'd much prefer it sync'ed from Debian, just let me know.
[17:46] <LocutusOfBorg1> +1 I love fixing debian bugs and syncing ubuntu ;)
[17:47] <LocutusOfBorg1> hint: cairo needs merging, it will fix the "bug" at the actual debian style
[17:47] <LocutusOfBorg1> (cairo is the reason why nobody noticed the bug in debian)
[17:47] <LocutusOfBorg1> bug 1353362
[17:47] <ubottu> bug 1353362 in cairo (Ubuntu) "cairo needs merge from debian" [Undecided,New] https://launchpad.net/bugs/1353362
[17:47] <LocutusOfBorg1> (leaving sorry)
[17:52] <ScottK> zul: Your upload of ironic has been sitting in proposed for a month.  Fancy fixing it?
[18:04] <psivaa> cjwatson: http://pastebin.ubuntu.com/8019255/ is the /etc/ssh/ listing
[18:06] <psivaa> cjwatson: and /var/log/apt/history.log does not contain any reference to openssh-server
[18:07] <psivaa> neither does dpkg.log
[18:39] <jdstrand> @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: jdstrand
=== roadmr is now known as roadmr_afk
[18:40] <cjwatson> psivaa: That's incredibly confusing.  My guess is filesystem corruption - try forcing the installation to sync harder (er, in some way) before shutting down?
[19:22] <jibel> cjwatson, from the paste, I've no idea. Are you on trusty (the version string suggests so)? Is the package available somewhere? I'll have a look.
[19:45] <Lysian> Hi, in Precise Release Notes https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes, is a dead link to changes of 12.04.5 https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/ChangeSummary/12.04.5
=== Ursinha is now known as Ursinha-afk
=== roadmr_afk is now known as roadmr
=== Ursinha-afk is now known as Ursinha
[20:55] <jtaylor> doko: do you have a hint where to look to add -Wl,--no-as-needed before the sanaitizer links in the gcc commandline, some spec file maybe?
[20:57] <jtaylor> it is done for -lc -lgcc but I can't figure out where
[21:05] <jtaylor> mh I guess I found it in gcc.c
[21:33] <ScottK> Would someone please requeue the libkdegames test for i386.
[21:52] <xnox> doko: creduce.... no, doesn't ring a bell.
[21:59] <sarnold> hey xnox :)
[21:59] <xnox> sarnold: hola =)
[22:00] <doko> xnox, fixed it
[22:01]  * xnox this is a public service announcement: "nobody likes thinkpad's nipple. it's just that touchpad has horrible tap/drag/scroll sensitivity, awful touchpad button and feels like sandpaper rather than a good quality touchpad"
[22:02] <kklimonda> hmm, i really like x240 touchpad
[22:03] <kklimonda> and yeah, im not using the trackpoint at all now
[22:03] <xnox> i have x230 and it doesn't compare to e.g. macbook from 2006
[22:03] <ogra_> xnox, that totally contradicts what i always hear from thinkpadders who are buying them because they are nipple fans
[22:03] <kklimonda> mhm, they have revamped it in x240 again
[22:04] <xnox> ogra_: a thinkpad nipple is forced upon me =) taking my microsoft sculpt keyboard and mouse combo with me tomorrow
[22:05] <kklimonda> ogra_: i'm starting to think that people are just in an abusive relationship with their trackpoints ;)
[22:06] <ogra_> i find thinkpad nipples pretty awful ... though not as bad as the toshiba copy that i had to use once with a company laptop
[22:07] <kklimonda> i find thw nipple in x240 pretty bad, and now im left wondering if it has always been that way, or did they break it at some point
[22:07] <ogra_> i think they call them "accupoint" or some such
[23:32] <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:
[23:42] <bdmurray> rbasak: Did you try the debian patch for bug 1257186? it looks a bit different than the debdiff you posted.
[23:42] <ubottu> bug 1257186 in samba (Ubuntu Trusty) "memory leakage messages " [High,Triaged] https://launchpad.net/bugs/1257186
=== salem_ is now known as _salem