=== salem_ is now known as _salem
[01:30] <RAOF> Hey, doko_! Is there any SRU review I could trade you to get a small, upstream reviewed patch applied to libstdc++? :) https://bugs.launchpad.net/gcc/+bug/1439451
[01:30] <ubottu> Launchpad bug 1439451 in gcc-4.9 (Ubuntu) "std::uncaught_exception() returns true after catching an exception thrown with std::rethrow_exception" [Undecided,New]
=== Guest22972 is now known as gusnan
[02:50] <sarnold> why does errors.ubuntu.com still show 12.10, 13.04, and 13.10 things on the front page? none of those have been supported in ages..
[02:50] <sarnold> and poor trusty and utopic are missing entirely
[03:26] <MrHeavy> The OpenStack repository at http://ubuntu-cloud.archive.canonical.com/ubuntu/ has a package (openstack-dashboard) with dependencies that don't exist. Is there anywhere in Launchpad that I should look around for them in queue?
[03:27] <MrHeavy> The packages in question are: python-xstatic-term.js, python-xstatic-angular-irdragndrop
[03:28] <MrHeavy> I can't even find Debian spkgs for these :/
=== gusnan is now known as Guest56910
=== marcusto_ is now known as marcustomlinson
[06:37] <flexiondotorg> infinity, Saw you update on the bug. Thanks for investigating.
=== marcusto_ is now known as marcustomlinson
[07:37] <jhenke> morning
[07:38] <jhenke> any firefox maintainer here?
[07:38] <jhenke> I am looking for someone to get into the reason for this bug after todays firefox update (afaik only affects vivid) https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1439532
[07:38] <ubottu> Launchpad bug 1439532 in firefox (Ubuntu) "Firefox 37 does not enable MSE required for YouTube HTML5 player" [Undecided,New]
[07:46] <asac> jhenke: chrisccoulson might be around later
[07:47] <asac> shouldnt be that long unless he is on vacation or something
[07:49] <jhenke> asac thanks, will wait for him
=== ming is now known as Guest92609
[09:35] <jhenke> chrisccoulson are you online?
=== dantes is now known as eddantes
=== eddantes is now known as eddantes_afk
=== greyback__ is now known as greyback
[10:18] <Laney> what creates /run/network/ifstate ?
[10:23] <ogra_> Laney, the networking upstart job ?
[10:23] <ogra_> (not sure)
[10:24] <Laney> upstart? what's that? :)
[10:24] <ogra_> haha
[10:24] <ogra_> yeah, living in the past here :)
[10:38] <lfrlucas> Why is policykit-1 still on proposed (trusty)?  28 days have passed
[10:39] <mgedmin> Laney, isn't it ifupdown?
[10:40] <Laney> I don't see where it's supposed to be done under systemd
[10:40] <Laney> It seems that ifup does create it when it's bringing an interface up but nothing makes an empty file on boot
[10:43] <Laney> probably just wants a tmpfiles.d entry
[11:32] <peleg> Hi there. I have installed ubuntu 14.04.2 on a new Dell Latitude E7450, and there seems to be a BIOS bug which makes keystrokes randomly repeat. This is an old known issue, at least in the forums. See for example http://en.community.dell.com/support-forums/software-os/f/3525/p/19618638/20748484
[11:32] <peleg> I have posted a question in ubuntu-certified launchpad: https://answers.launchpad.net/ubuntu-certification/+question/264500
[11:32] <peleg> and in askubuntu as well: http://askubuntu.com/questions/604382/dell-latitude-e7450-repeating-keystrokes-issue
[11:40] <peleg> Since canonical works closely with Dell, I was thinking that perhaps they should (a) publish a warning and (b) get a formal announcement from Dell about it
=== _salem is now known as salem_
=== gusnan is now known as Guest53886
[12:24] <nrosvall> Hi, I'm working on a quite big software project. Now when Unity 8 is coming and all that new stuff I'm wondering how much Unity 7 and 8 api will be different
=== Guest53886 is now known as gusnan
[12:24] <nrosvall> say indicators? will indicators written for unity 7 work with unity 8?
[12:25] <nrosvall> (not sure if this is the right place to ask)
=== MacSlow is now known as MacSlow|lunch
[12:51] <rbasak> nrosvall: try #ubuntu-desktop maybe?
=== MacSlow|lunch is now known as MacSlow
[13:25] <smoser> hey. i need some systemd help
[13:25] <smoser> bug 1438520
[13:25] <ubottu> bug 1438520 in cloud-init "cloud-init on vivid upgrade causes sigterm, which aborts 'runcmd' execution" [Undecided,Confirmed] https://launchpad.net/bugs/1438520
[13:26] <smoser> one of cloud-init's jobs runs apt-get dist-upgrade, and that job upgrades cloud-init (if there is one available).
[13:26] <smoser> something in that interaction with systemd means that subsequent cloud-init jobs aren't run.
[13:27] <smoser> this worked with upstart, and its important for us to get right (because otherwise you can't have clodu-init safely upgrade for you)
[13:27] <smoser> xnox, maybe or i know that didrocks has some experience with systemd also.
[13:27] <xnox> yo
[13:28] <xnox> smoser: so what happens? cloud-init service gets killed, and not started on post-upgrade... remaining cloud-init services don't run either?
[13:29] <Riddell> tseliot: hola?
[13:29] <xnox> hm. =/ i don't have time to dig into that at the moment, sorry.
[13:30] <tseliot> Riddell: hey,
[13:30] <smoser> xnox, yes. i'll try to put an explanation of the problem into the bug. then maybe if you have time you can read.
[13:35] <didrocks> smoser: just ping me once you have the explanation's summary into the bug, I'll try to have a look by EOW
[13:35] <smoser> didrocks, ok. thanks.
[13:35] <Riddell> tseliot: oh, so sddm can probably do the thing on starting X
[13:35] <Riddell> tseliot: but there's no hook to run a script on shutting X down
[13:35] <Riddell> tseliot: what happens if nvidia-prime gets set up but not removed?
[13:35] <tseliot> Riddell: yes, I had to implement that myself in lightdm
[13:36] <Riddell> does it mean nvidia and intel do eternal battle for the graphics?
[13:36] <tseliot> Riddell: hybrid graphics (as in disabling the discrete GPU) won't work on log out. Switching between GPUs will require a reboot
[13:37] <Riddell> tseliot: so that sounds better than not working at all?
[13:37] <tseliot> Riddell: sure but users will complain
[13:38] <Riddell> tseliot: right but will they complain more than if they can't install it without breaking sddm
=== gusnan is now known as Guest4119
[13:39] <Riddell> and who are all these users with two GPUs? they seem like a very fussy lot :)
[13:39] <tseliot> Riddell: the nvidia settings panel will tell them to log out to switch to the other GPU, then they log out, log back in, and everything will be broken, as you'll get the driver using the wrong libriaries
[13:39] <tseliot> *libraries
[13:40] <tseliot> Riddell: yes, I think there are a lot of users
=== zigo_ is now known as zigo
=== Guest4119 is now known as gusnan
[13:53] <tseliot> Riddell: it should be relatively easy to add that feature to sddm
[14:09] <Riddell> tseliot: reported it for now https://github.com/sddm/sddm/issues/393 https://github.com/sddm/sddm/issues/394
[14:09] <Riddell> tseliot: how do I change nvidia-prime packaging to have sddm alternate?
[14:13] <tseliot> Riddell: it already does this: Depends: lightdm (>= 1.9.1) | gdm | kdm. I can add a simple "|sddm", assuming that's the package name
[14:13] <tseliot> Riddell: does kubuntu use systemd?
[14:18] <Riddell> tseliot: yes please add |sddm .  yes we use systemd
[14:19] <smoser> GunnarHj, can you take a look at bug 1439711
[14:19] <ubottu> bug 1439711 in language-selector (Ubuntu) "cedilla-brazil.sh writes errors on login: line 21: [: too many arguments" [Undecided,New] https://launchpad.net/bugs/1439711
[14:19] <tseliot> Riddell: ok, I'll do that now. Furthermore I've just written some untested code that should give you the same feature on log out
[14:19] <Riddell> tseliot: ooh?
[14:19] <tseliot> Riddell: the one that executes a script after X is stopped
[14:20] <cjwatson> smoser: Wasn't that fixed by https://launchpad.net/ubuntu/+source/language-selector/0.142
[14:20] <cjwatson> ?
[14:20] <Riddell> tseliot: that's exciting :)
[14:20] <cjwatson> smoser: Should be closed I think.
[14:21] <Riddell> tseliot: let me know if you have something I should add to the sddm package
[14:22] <tseliot> Riddell: sure. In the meantime, let's see if I got it right. Is the DisplayCommand entry meant to be set in the Xsetup script? If so, my code should work as expected
[14:24] <Riddell> tseliot: DisplayCommand entry?
=== doko_ is now known as doko
[14:24] <tseliot> Riddell: that's the entry for the command to execute after X starts: https://github.com/sddm/sddm/blob/master/data/man/sddm.conf.rst.in
[14:26] <tseliot> Riddell: so I'm wondering if adding DisplayCommand="path_to_my_script" in the Xsetup script would work
[14:26]  * tseliot has never used sddm
[14:26] <tseliot> if that works, then I have code to add another entry
[14:28] <Riddell> tseliot: DisplayCommand is "A script to execute when starting the display server"
[14:29] <Riddell> tseliot: I don't think setting DisplayCommand in Xsetup will do anything, it gets set in sddm.conf
[14:30] <tseliot> Riddell: aah, so there is an sddm.conf file. Ok, it should work then
[14:32] <Riddell> tseliot: sddm --example-config  will Print the complete current configuration to stdout
[14:37] <tseliot> Riddell: ah, so that shows that DisplayCommand=/usr/share/sddm/scripts/Xsetup . I think we really need to get something like https://github.com/sddm/sddm/issues/217 first
[14:38] <tseliot> Riddell: as you don't want to have the scripts executed for users who don't need them
[14:38] <Riddell> tseliot: that would obviously be nicer but is it a problem if it's executed for users who don't need it?
[14:39] <tseliot> Riddell: luckily, it's not. As we check the hardware
[14:41] <Riddell> phew :)
[14:48] <tseliot> Riddell: after I add my code, you will have to add two entries: DisplayCommand and DisplayStopCommand, pointing to Xsetup and Xstop respectively
[14:49] <tseliot> Riddell: or, rather, point to the same scripts that we have in nvidia-prime and be done with it
[14:52] <Riddell> tseliot: DisplayCommand points to Xsetup by default, I guess your code will point DisplayStopCommand to Xstop by default and that can run nvidia-switch
[14:52] <tseliot> Riddell: yep. You will have to ship a custom .conf file if you want hybrid gfx to work
[14:58] <tseliot> Riddell: I'll try to compile sddm with my patch. Hopefully the packaging is relatively simple
[15:20] <infinity> Laney: Really, you want to wrap my C gnome-terminal with a python script and triple the startup time? :/
[15:26] <Laney> I want to not break existing configurations
[15:28] <Laney> I forgot to add new Depends though, whoopsie
[15:29] <infinity> Laney: I don't suppose you could just reintroduce the option in C instead?
[15:29] <infinity> Laney: I guess for "normal" people who never see the terminal, it's a non-issue, but for people who hit Ctrl-ALt-T more than anything else on their keyboard, it's a noticeable performance regression to fire up a python interpreter first.
[15:30] <Laney> It's not as easy as that, you have to start a second server instance and connect to this one
[15:30] <tseliot> Riddell: my patch built :)
[15:32] <tseliot> Riddell: and this is what sddm --example-config says now: http://paste.ubuntu.com/10724675/
[15:37] <Adri2000> is anyone moderating devel-permissions@ ?
[15:50] <tseliot> Riddell: I've made a pull request for my code: https://github.com/sddm/sddm/pull/395
[15:54] <bdmurray> tedg: Didn't you create some code for calling apport's recoverable_problem some where or generating RecoverableProblem reports?
[15:55] <infinity> tseliot: Why do you have a .patch in nvidia-prime that does nothing?  Accidental cruft?
[15:55] <tseliot> infinity: in 0.8.1?
[15:56] <infinity> tseliot: Yeah, 0001-debian-control-add-sddm-and-systemd-as-alternate-dep.patch in the base directory.  Doesn't need to be there, it's obviously applied to debian/control already.
[15:56] <tedg> bdmurray, We have some cut-and-paste code that we've been passing around, I started an MR for it, but it needs tests: https://code.launchpad.net/~ted/whoopsie/recoverable-problem/+merge/219066
[15:56] <tseliot> infinity: aargh I forgot to remove it
[15:56] <infinity> tseliot: Go ahead and delete it and reupload the same version.
[15:56] <tseliot> infinity: ok, thanks
[15:57] <infinity> tseliot: On a side note, why the dependency on "upstart | systemd" at all?
[15:57] <bdmurray> tedg: right, I found that mp. Where can I see the cut and paste code?
[15:57] <tseliot> infinity: it's no longer there. It's only in that patch
[15:57] <tedg> bdmurray, It's there, the recoverable error file. I cleaned up the API for that MR, but it's basically the same.
[15:57] <infinity> tseliot: Daemons don't generally depend on init systems.  And, even if they did, you're not getting the *system* init with that dep.
[15:57] <tedg> bdmurray, It's in a bunch of different projects.
[15:57] <infinity> tseliot: Oh, indeed, it's not there in the real debian/control.  Check.
[15:58] <tseliot> infinity: reuploaded
[15:58] <bdmurray> tedg: Could you name one of those? I'm trying to sort out some issues with the DuplicateSignature.
[15:59] <infinity> tseliot: Better, and accepted.
[15:59] <tedg> bdmurray, Sure, UAL. https://bazaar.launchpad.net/~indicator-applet-developers/ubuntu-app-launch/trunk.15.04/view/head:/libubuntu-app-launch/recoverable-problem.c
[15:59] <tseliot> infinity: thanks
[16:00] <tedg> bdmurray, Are you looking for the duplicate signature we're using?
[16:00] <bdmurray> tedg: Also do you know of a way to create a recoverable problem in an app? Just calling recoverable_problem does that I think it should.
[16:01] <hallyn> jodh: hey,
[16:01] <tedg> bdmurray, It does, yes, but you have to pass the additional parameters to the stdin of the utility. Which isn't that friendly for most app developers, hence the wrapper.
[16:01] <bdmurray> tedg: I'm trying to figure out why bug 1316763 isn't work
[16:01] <ubottu> bug 1316763 in apport (Ubuntu Trusty) "bucketing of recoverable problems is done poorly" [Medium,Triaged] https://launchpad.net/bugs/1316763
[16:01] <jodh> hallyn: hi
[16:01] <hallyn> so for bug https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1432683 i'm going to be needing systemd and upstart packages
[16:01] <ubottu> Launchpad bug 1432683 in lxc (Ubuntu) "apt-get install lxc doesn't load required apparmor profiles" [Critical,Triaged]
[16:02] <tedg> bdmurray, I think the issue is that we have the same duplicate signature for different apps
[16:02] <hallyn> moving /lib/init/apparmor-profile-load from cgroup-bin to init-system-helpers.
[16:02] <hallyn> jodh: do you have planned uploads soon for those?
[16:02] <tedg> bdmurray, For instance "bad-url" can come from anyone
[16:02] <bdmurray> tedg: right, and I modified recoverable_problem to change that and it works for me
[16:02] <bdmurray> "Use package name in duplicate signature for recoverable problems. "
[16:04] <hallyn> jodh: if not i'll happily push later today
[16:04] <jodh> hallyn: nothing planned from me, no.
[16:05] <hallyn> jodh: do you know if pitti had anything planned?  there's no team bzr tree or anything i should go through?
[16:05] <infinity> hallyn: Hrm, I thought rbasak was going to finish that move, did he get distracted?
[16:06] <infinity> rbasak: Didn't you have pending uploads for the /lib/init/apparmor-profile-load thing?
[16:06] <hallyn> infinity: yeah he had to move on
[16:06] <infinity> hallyn: Ahh, kay.
[16:06] <hallyn> afaik.  let's see what rbasak says
[16:06] <hallyn> the apparmor package did get pushed, that was step 1...
[16:06] <rbasak> Yeah sorry, been distracted.
[16:06] <tedg> bdmurray, Hmm, I hadn't see that patch. Not sure why that wouldn't be working.
[16:06] <rbasak> I can aim to push the rest in the next week or two if you want me to.
[16:07] <hallyn> rbasak: i'd menat to do it, just got sick.  i'm back and was planning to push the next steps today
[16:07] <bdmurray> tedg: Right, I've no idea either. So do you know of a way to cause a recoverable problem in the web browser or something?
[16:07] <tedg> bdmurray, We're gonna have a bunch from Utopic though, is that in Utopic?
[16:07] <hallyn> either way
[16:07] <rbasak> hallyn: OK - I'll leave it to you then? I was aware you were sick but also didn't want to step on your toes (and had been occupied with Docker)
[16:08] <tedg> bdmurray, Just launch a bad URL: "url-dispatcher foo://bar"
[16:08] <bdmurray> tedg: yes, it made it into utopic and I tried it on RTM
[16:08] <hallyn> rbasak: i'll do it then - thx, ttyl
[16:08] <bdmurray> tedg: okay, great
[16:08] <tedg> bdmurray, You might need to do that with a longer living process ID though, so it has time to grab info.
[16:09] <tedg> bdmurray, The command line utility might be too fast for apport
=== ximion is now known as ximion-afk
[16:26] <doko> RAOF, discussing with upstream. I don't like to apply patches which are not yet upstream.
[16:31] <bdmurray> tedg: whenever I launch url-dispatcher I receive "** (process:3928): WARNING **: Unable to get name 'com.canonical.URLDispatcher'"
[16:31] <tedg> bdmurray, Not the service the command line util. Thought it was on the image...
[16:31] <hallyn> rbasak: i'm looking at http://paste.ubuntu.com/10725004/.  except that the apparmor patch was wrong (the new script isn't executable) so i'l lhvae to wait for one more push :(
[16:32] <rbasak> hallyn: ah yes. We discussed that. Can't transfer executable bit in a debdiff. Sorry!
[16:34] <tedg> bdmurray, It basically does: gdbus call --session --dest com.canonical.URLDispatcher --object-path /com/canonical/URLDispatcher --method com.canonical.URLDispatcher.DispatchURL foo://bar " "
=== dantes is now known as eddantes
[16:40] <infinity> hallyn: No one's stopping you from uploading an apparmor with the +x bit set...
[16:40] <bdmurray> tedg: "Error: GDBus.Error:com.canonical.URLDispatcher.BadURL: URL 'foo://bar' is not handleable by the URL Dispatcher
[16:40] <bdmurray> (According to introspection data, you need to pass 'ss')"
[16:47] <doko> bdmurray, wgrant: could you have a look at https://bugs.launchpad.net/ubuntu/+source/pywbem/+bug/1434991 ? you touched these packages for trusty-updates
[16:47] <ubottu> Launchpad bug 1434991 in pywbem (Ubuntu) "python attributeError 'SSLTimeoutError' after upgrade" [Undecided,Confirmed]
[16:48] <bdmurray> doko: don't you mean caribou?
[16:50] <doko> bdmurray, ohh, maybe, you just signed
[16:51] <bdmurray> doko: yeah, looking at the changelog it was caribou's SRU
[17:22] <infinity> LocutusOfBorg1: Hey, regarding vbox dkms stuff, I'll push you some patches when I've got it all unwound.  I have great motivation for the package to be in sync between Debian and Ubuntu, and zero interest in maintaining a fork. :P
[17:41] <teward> infinity: thanks again for the assist yesterday :)
[17:42] <teward> and apologies on the delay in uploading the nginx change, i got busy last night, then my internet crapped again.
[17:55] <hallyn> infinity: yup, i was just waiting to make sure there's no competing upload comigng from security.  ther eisn't
[18:11] <gQuigs> does snappy or ubuntu core follow the same release cycle as normal releases?  or is the current version permanently dev rolling?
[18:13] <ogra_> gQuigs, #snappy is a better place for such questions i guess
[18:14] <ogra_> (currently it is rolling, like the phone ... not sure what will happen after vivid release though)
[18:15] <smoser> Laney, what bug were you talking about ? un-breaking and gnome-terminal
[18:15] <gQuigs> ogra_: thanks
[19:05] <tedg> bdmurray, That's correct, you want the error that it wasn't handlable, because that's when it files the recoverable error.
[21:10] <aeoril> darkxst I am back now.  I looked at bug 1315442 - you may remember this is the last bug I was working on with you. It is status "new" and "confirmed" but not triaged.  I had a fix ready for it some time ago, but was wondering if I needed to do anything to the status before I submit a merge proposal since it is not triaged.  Also, since I have been away so long, I will have to re-orient
[21:10] <aeoril> myself on it and re-test the fix because I do not remember exactly where I left of on it
[21:10] <ubottu> bug 1315442 in gdm (Ubuntu Trusty) "Extra "fi" in /etc/init.d/gdm" [Undecided,Confirmed] https://launchpad.net/bugs/1315442
[21:16] <aeoril> off on it*
[21:16] <darkxst> aeoril, hi, just submit you merge proposal or debdiff
[21:18] <darkxst> technically it could be marked triaged, but if your going to fix it, status doesnt matter too much
[21:19] <aeoril> darkxst ok.  I think I was going to do a debdiff - last thing I had to you in my IRC log files was:
[21:19] <aeoril> [17:30] <aeoril> darkxst oh, ok - so no problem then.  So, just to make sure, 'dhc -i' (add my comment to ChangeLog), (make my code change), 'sudo apt-get build-dep gdm', 'builddeb -S', 'debdiff old.dsc new.dsc > debdiff_name.debdiff', then attach debdiff to bug ... /??
[21:20] <darkxst> aeoril, yes, debdiff is fine for gdm
[21:20] <aeoril> ok, cool - I will try to remember now everything I need to do!  It has been a while, and am a little foggy. Thanks!
[21:25] <aeoril> darkxst just to remind myself, when I use "dhc -i" and add a new version number, then "run builddeb -S", it will create a new new .dsc file with my changes in it with the name based on my new version number in ChangeLog, so I will have the original .dsc and the new one to run debdiff against, which will then only have my changes shown in it, then attach that to the bug and make a comment
[21:25] <aeoril> to the effect "I have fixed this - look at the attached debdiff" or whatever?
[21:26] <aeoril> well, add a comment with and attach the debdiff to it ...
[21:28] <aeoril> darkxst also, I need to do all this on a vivid machine, not trusty?
[21:28] <darkxst> its `dh -i`, but yes
[21:29] <darkxst> you need to fix the vivid package first, but you can do that from trusty and test in a vivid VM
[21:29] <GunnarHj> smoser: infinity fixed it yesterday, as you already have noticed. Sorry for making that stupid mistake.
[21:38] <aeoril> darkxst isn't it actually "dch -i"? (to update the changlog)
[21:38] <aeoril> changelog*
[21:39] <darkxst> aeoril, yes, seems I can't type before coffee
[21:39] <aeoril> darkxst just now having coffee?  You must be in Australia or something! :)
=== elijah_ is now known as elijah
=== ssweeny` is now known as ssweeny
[21:49] <aeoril> darkxst I am having to remind myself - bzr branch lp:gdm will get the latest code from launchpad, which will be a vivid package?  Then I "dch -i", update the changelog, make my code changes, then I "sudo apt-get builddep gdm" then "run builddeb -S" on it to create the .dsc and other necessary stuff, then the appropirate sbuild commnad to build for vivid, then test the binaries created by
[21:49] <aeoril> sbuild on a vivid vm after installing, then if it all works, 'debdiff old.dsc new.dsc > debdiff_name.debdiff', make a new comment "I fixed it!" and attach debdiff to comment on bug?  (sorry to ask so many questions - I want to make sure I am understanding/remembering how to build on trusty and test on vivid correctly)
[21:50] <bdmurray> barry: If you are about could you merge https://code.launchpad.net/~brian-murray/aptdaemon/bug-1436725/+merge/255152
[21:51] <barry> bdmurray: i'm almost eod and trying to finish something before then.  if you haven't gotten it merged by tomorrow, please ping me
[21:52] <bdmurray> barry: I'm on holiday tomorrow, its a 5 character string change and isn't a huge bug anyway
[21:53] <infinity> aeoril: I wouldn't guarantee that lp:gdm will be what you want.  If your intent is to produce debdiffs as your final product, not merge proposals, just stick with "pull-lp-source gdm", which is going to more reliably get you the current archive version.
[21:53] <barry> bdmurray: i'll keep the tab open, but i may not get to it until tomorrow ;)
[21:54] <aeoril> infinity then don't I need to do that on vivid?  darkxst mentioned I could build a vivid package on trusty then test on vivid - wouldn't "pull-lp-source gdm" on trusty bring me a trusty package?
[21:54] <infinity> aeoril: No, pull-lp-source defaults to the current devel release.  You could also explicitly say "pull-lp-source gdm vivid" though.
[21:56] <aeoril> infinity oh, ok - I did not understand.  I thought it pulled for the version of the os you were running it from.  Thanks!  I will read the man page on it now
[21:57] <aeoril> infinity "If no  version  or  release  is  specified,  the  latest  version  in  the development release will be downloaded." (from the man page) - thanks! :)
[21:59] <aeoril> infinity but, just to clarify, I would need to use the appropriate sbuild command for vivid (I have the sbuild environment already set up for vivid) to build the binaries from that source for vivid to test on my vivid vm?
[22:00] <aeoril> In other words, was the rest of what I said accurate in my list of what I need to do other than the part about how to get the source code?
[22:01] <aeoril> (to build on trusty)
[22:01] <infinity> aeoril: Well, for sbuild, you can set the default target in .sbuildrc
[22:01] <infinity> aeoril: Mine is always set to the devel release, you can set yours to whatever you like.
[22:01] <infinity> $distribution = 'vivid';
[22:02] <infinity> aeoril: But if you prefer not to set a default then, yes, you'd need to "sbuild -d vivid foo.dsc"
[22:19] <aeoril> infinity I used "sbuild-launchpad-chroot" to make my sbuild environments, so I would use (IIRC) something like "sbuild --dist=vivid --arch=amd64 -c vivid-proposed+restricted-amd64-sbuild <dsc>" to do my build - see https://lists.ubuntu.com/archives/ubuntu-devel/2013-October/037726.html
=== Neo31` is now known as eo31
=== eo31 is now known as Neo31`
=== Neo31` is now known as Neo31
=== FatBack changed the topic of #ubuntu-devel to: penis
[22:44] <cyphermox> @pilot out
=== udevbot changed the topic of #ubuntu-devel to: penis | Patch Pilots:
[22:44] <cyphermox> boo udevbot.
=== Unit193 changed the topic of #ubuntu-devel to: Archive: Feature Freeze | 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:
[22:46] <cyphermox> Unit193: thanks.
[22:47] <Unit193> cyphermox: Sure, though he's still in here.  (BTW, DalekSec == me)
[22:48] <cyphermox> ah,
[22:48] <cyphermox> well, I'm attempting to take care of that but I don't have access
[22:48] <cyphermox> cjwatson: kees: lamont: ^?
[22:52] <sarnold> thanks hggdh
[22:52] <wgrant> Has someone reported him to staff?
[22:52] <wgrant> He's crossed project boundaries now, so a K-line is in order.
[22:52] <hggdh> sarnold: welcome.
[22:52] <teward> wgrant: i know sarnold hopped into #freenode briefly
[22:52] <wgrant> Ah, great.
[22:52] <teward> wgrant: and i'm trying to find a live staffer to get heavy weapons upon the user asap, but...
[22:53] <hggdh> wgrant: not yet, in the middle of a meeting
[22:53] <sarnold> wgrant: I did, but I suspect little will come of it. :/
=== slangase` is now known as slangasek
[23:03] <aeoril> darkxst infinity I have run into a problem - I used "pull-lp-source gdm" to get the latest source for gdm, and have made my changes and am ready to build, but it is not a bazaar branch, so I cannot run "bzr builddeb -S" to create the new .dsc file.  Should I make it a bazaar branch using "bzr init" or whatever so I can do that, or is there some other better way?
[23:03] <aeoril> (I looked all over the Internet and found nothing so far)
[23:05] <wgrant> aeoril: debuild -S
[23:05] <wgrant> bzr builddeb is a wrapper around debuild.
[23:06] <aeoril> wgrant ok, thanks :)
[23:12] <aeoril> wgrant yay!  and debdiff worked great!  Now, just to sbuild and test on vivid machine! :)
=== salem_ is now known as _salem
[23:25] <hggdh> wgrant: for the record, no staff seems to be available. Ah well, we tried.
[23:29] <teward> hggdh: i grabbed hold of one
[23:29] <hggdh> teward: cool. Let's see what will come of it.
[23:30] <teward> hggdh: they only just woke up afaict, but if you want, you can poke kloeri, the one who i grabbed hold of
[23:30] <teward> lurking the gab channel still helps xD
[23:30] <hggdh> kloeri already saw the beast
[23:32] <teward> hggdh: and i believe they're going to handle it
[23:33] <teward> although i suggested the use of IRC operator heavy weapons, the response i got was "I'm handling it"