[04:55]  * SpamapS_ just made his first real upload.. :-D
[04:59] <TheMuso`> SpamapS: Awesome!
[05:08] <c2tarun> is there any tutorial available for how to create a plugin for any application?
[05:12] <TheMuso`> c2tarun: It depends on the application, and whether that application supports plugins.
[05:12] <c2tarun> TheMuso`: its kontact.
[05:12] <TheMuso`> c2tarun: Then you will have to find the developer documentation to look up the plugin API.
[05:13] <c2tarun> TheMuso`: actually I am trying to look into this http://community.kde.org/GSoC/2011/Ideas#Project:_VOIP_Plugin_for_Kontact I thought to do my side research first, but failed to find on google how to create a plugin
[05:14] <c2tarun> isn't there any basic steps for writing a plugin? :/
[05:14] <RAOF> c2tarun: It's entirely application-specific; there's no guarantee that kontact even supports plugins.
[05:15] <RAOF> (Although the GSoC idea suggests that it does ☺)
[05:15] <c2tarun> RAOF: yup. ok, so I'll ask in #kontact channel then :)
[05:15] <c2tarun> anyone here is participating in GSoC?
[05:15] <c2tarun> not as mentor.
[07:30] <dholbach> good morning
[07:51] <didrocks> good morning
[08:17] <pitti> Good morning
[09:03] <abhinav-> dholbach, thanks for your email reply :)
[09:03] <dholbach> abhinav-, sure :)
[09:07] <janimo> Riddell, hi, do you have a recent package example that used cmake and hardcoded /usr/lib/ paths that needs to be fixed for multiarch?I remember you mentioning something like this a while ago
[09:08] <janimo> there's a FTBFS  which may be caused by something similar https://launchpadlibrarian.net/67912682/buildlog_ubuntu-natty-armel.igstk_4.2.0-4_FAILEDTOBUILD.txt.gz
[09:14] <ohsix> hm
[09:14] <ohsix> seeing lots of 404s on changelogs in aptitude lately, did something change?
[10:14] <Riddell> janimo: cmake should be fixed to know to look in the multiarch directories
[10:15] <janimo> Riddell, so you only worked around that in a specific package? Is the cmake fix in progress?
[10:15] <janimo> is this affecting Kubuntu packages?
[10:16] <Riddell> janimo: cmake itself should be fixed with the debian/patches/ubuntu_multiarch_library_directory.diff patch
[10:48] <YokoZar> If a dummy package is removed entirely do we need to conflict/break it or can we just let it rot?  Will update manager remove dummy packages that no longer exist in the archive?
[10:52] <YokoZar> Nevermind, answered my own question:    "If a package is completely replaced in this way, so that dpkg does not know of any files it still contains, it is considered to have "disappeared".  It will be marked as not wanted on the system (selected for removal) and not installed.  Any conffiles details noted for the package will be ignored, as they will have been taken over by the overwriting package."
[10:52] <cjwatson_> in practice this never happens because there's always /usr/share/doc/$packagename/
[10:52] <cjwatson> or more or less never
[10:53] <YokoZar> hmm, that seems wrong somehow
[10:53] <cjwatson> I would declare Breaks anyway.  It's cheap.
[10:54] <cjwatson> actually, no, you want to get rid of the old package completely, don't you?  Conflicts+Replaces sounds appropriate
[10:55] <janimo> co
[10:55] <cjwatson> update-manager is useful for many things, but you shouldn't assume everyone is using it unless you have no other choice
[10:55] <cjwatson> (of course, presumably an old dummy package hanging around isn't actually going to do any harm, so use your judgement there)
[10:56] <YokoZar> Why not breaks/replaces?
[10:56] <Laney> breaks doesn't enforce removal
[10:56] <YokoZar> just deconfigure
[10:57] <Laney> you can still have the files unpacked
[10:57] <Laney> right
[11:00] <YokoZar> Will these conflict lines do bad things if I define a new virtual package by the same name as the dummy package?
[11:01] <YokoZar> I think that was my original intuition for wanting to use breaks
[11:01] <cjwatson> if you plan to do that, use versioned Conflicts
[11:01] <YokoZar> ahh, the one real use for versioned conflicts, makes sense
[11:02] <cjwatson> right
[11:02] <Laney> note that provides will only help for unversioned depends (if that's indeed what you are trying to take care of)
[11:11] <OdyX`> ScottK2: Aye. Bugs were filed. apiextractor: #748331 generatorrunner: #748333, shiboken: #748334 and pyside got renamed: #740177
[11:22] <Chipzz_> whoa, freenode is unstable today
[12:28] <chrisccoulson> @pilot in
[13:15] <nobuto> chrisccoulson: Could you review my debdiff on Bug #746538?
[13:15] <chrisccoulson> nobuto, sure
[13:15] <chrisccoulson> oh, it's for ubufox
[13:15] <chrisccoulson> heh, we seem to be carrying a monster patchset for that now
[13:16] <chrisccoulson> i should fork it ;)
[13:41] <UBuxuBU> can i have a ubuntu page on my website?
[13:43] <mterry> superm1, heyo, would you mind having a mythbuntu person look at https://code.launchpad.net/~mterry/ubuntu-seeds/mythbuntu.natty-gnome-system-tools/+merge/53423 ?  thanks
[13:46] <Daviey> mterry, Have you tested it?
[13:47] <mterry> Daviey, no?  it seemed straightforward.  But other flavors have used similar changes, so I believe it's safe
[13:53] <Daviey> mterry, Great, I see xubuntu has adopted it.. fine with me, merged.
[13:53] <Daviey> thanks for spotting it.
[13:53] <mterry> Daviey, I did the package split, so I felt obliged  :)
[13:54] <Daviey> heh
[14:02] <mterry> slangasek, are you on "archive admin" duty today?  I have a sync I'd love to see happen: bug 746448
[14:03]  * mterry isn't sure why he put archive admin in quotes  :)
[14:05] <cjwatson> mterry: I'll do a sync pass now
[14:05] <mterry> cjwatson, thanks!
[14:06] <mterry> cjwatson, note that that particular bug requires 3 syncs
[14:06] <cjwatson> if ubuntu-archive is subscribed to it, then I'll pick it up
[14:10] <mterry> cjwatson, well, they are all in the same bug.  perhaps I should have filed 3 separate ones?, but the other 2 are only needed to support new pylint
[14:10] <hallyn> skaet_: good morning - please let me know if there is anything else you need from me on bug 727342.  (As I say it tests well for me)
[14:10] <ScottK> OdyX: All approved now.  Should get sync'ed soon.  Thanks.
[14:10] <OdyX> ScottK: niiice. Thanks.
[14:14] <cjwatson> mterry: it's fine the way it is.
[14:30] <nobuto> chrisccoulson: Thanks for uploading!
[14:47] <OdyX> ScottK: Would pyside-tools (currently in unstable, got out of Debian:NEW recently) be considerable ? It's only new functionality, but pretty much needed for correct PySide operation ?
[14:47] <ScottK> OdyX: Yes, but it will need an FFe.
[14:47] <ScottK> Please file the sync request as an FFe request and I'll review it.
[14:48] <OdyX> ScottK: doing that now
[14:56] <OdyX> ScottK: https://bugs.launchpad.net/ubuntu/+bug/750295
[14:58] <ScottK> OdyX: Just approved it.  It should at least get to Ubuntu New on the next round of syncs.
[14:58] <OdyX> Nice.
[15:05] <skaet> hallyn,   have gone in and approved it.   Thanks for getting this fixed.
[15:10] <pitti> jdstrand, kees: releasing lucid kernels to -security/-updates: linux linux-backports-modules-2.6.24 linux-meta linux-restricted-modules-2.6.24 linux-ubuntu-modules-2.6.24
[15:11] <jonny> cjwatson: Is https://wiki.ubuntu.com/SeedManagement#CD%20builds still accurate? It doesn't look to have been update since there was a unified live/install CD. I've been hunting around to find the list of packages one expects on a Live CD - is there a better way than looking at filesystem.manifest (or filesystem.manifest-desktop) on the CD? For example a way that doesn't require I get the CD?
[15:17] <cjwatson> jonny: it looks fairly close to me, if you s/install/alternate/ and s/live/desktop/
[15:17] <cjwatson> jonny: you can look at the .manifest and .list files alongside the CD on cdimage.u.c
[15:20] <cjwatson> I've updated that documentation a bit - there's no point in it listing lots of seed names that are already in the STRUCTURE dependencies
[15:24] <jonny> cjwatson: thanks. Is there some documentation somewhere about how the livecd is build - this is curiosity speaking now :) - As I understand it, Germinate spits out a bunch of potentially intersecting lists of packages, is there a tool beyond apt that reconciles those and makes the cd inside a chroot or something?
[15:24] <jonny> *s/build/built ^
[15:26] <cjwatson> jonny: livecd-rootfs builds the live filesystem
[15:27] <cjwatson> https://code.launchpad.net/~cjwatson/ubuntu-cdimage/mainline (plus the submodules in configs/devel) does the rest of it
[15:27] <cjwatson> hm, let me fix the mirroring there
[15:30] <cjwatson> well, it should sort itself out in a bit
[15:48] <superm1> Daviey, can you regenerate that meta package and upload too?
[15:58] <YokoZar> is there an easy way to tell why apt wants to remove something on dist-upgrade?
[15:58] <ohsix> use aptitude? :D
[16:00] <YokoZar> ohsix: welp, aptitude wants to do something different from apt-get
[16:03] <ohsix> shrug
[16:03] <ohsix> at least aptitude lets you investigate its upgrade solution
[16:03] <ogra_> ugh, aptitude
[16:04] <juliank> YokoZar: There are debugging switchs to see this
[16:04] <YokoZar> yeah that was my thought
[16:04] <Daviey> superm1, ack, i wanted to check there wasn't anything else before doing so.
[16:05] <juliank> YokoZar: Try -o pkgProblemResolver=true
[16:05] <juliank> YokoZar: "-o Debug::pkgProblemResolver=true"
[16:07] <juliank> But it can be very verbose
[16:07] <YokoZar> juliank: $ sudo apt-get -o Debug:pkgProblemResolver=true dist-upgrade ?
[16:07] <juliank> YokoZar: yes
[16:07] <YokoZar> hmm doesn't seem to be changing the output up to the prompt...
[16:08] <YokoZar> (the do you want to continue prompt)
[16:11] <juliank> YokoZar: Try apt-get dist-upgrade -o Debug::pkgProblemResolver=1
[16:12] <juliank> YokoZar: You just missed a colon, it seems
[16:13] <YokoZar> yeah
[16:13] <YokoZar> now if I can make sense of this output...
[16:14] <juliank> YokoZar: you could put it on a paste bin and tell me what you're looking for
[16:15] <juliank> http://paste.ubuntu.com/
[16:16] <YokoZar> ahh I think I figured it out, obsolete version of a pacakge in an enabled PPA that was the same version as the fixed package I installed locally.  Apt wants to upgrade from dpkg -i installed package to one available on PPA, which in this case means getting the broken one.
[16:16] <YokoZar> which had the side effect of trying to remove a fixed package that was also fixed in the ppa
[16:18] <juliank> YokoZar: If needed, you can use pinning to overwrite this
[16:19] <YokoZar> Yup.  Thanks juliank
[16:25] <SpamapS> jhunt_: about the sendsigs killing OMITPIDS .. this seems somewhat broken.. I think the appropriate thing to do is to only care about processes with a goal of stop/ .. since the point of having no 'stop on' is that you run "forever" is it not?
[16:26] <SpamapS> jhunt_: so whynot just replace that kill with a loop to stop all remaining jobs except rc?
[16:36] <jhunt_> SpamapS: seems reasonable - that script just kinda "feels" too complex right now.
[16:36] <jhunt_> I'm interested in the "vanilla upstart approach" too as it would be
[16:36] <jhunt_> nice to keep separation between Upstart and SysV jobs (Upstart shouldn't
[16:36] <jhunt_> need SyV)
[16:36] <jhunt_> s/SyV/SysV
[16:37] <jhunt_> We might need Keybuks thoughts on the preferred method for that one though.
[16:54]  * YokoZar just vastly simplified some package rules files thanks to debhelper 7.
[16:54] <smoser> jhunt_, can you verify for me that upstart doesn't care if a file is dos format ?
[16:55] <smoser> i have to fix something in cloud-init when input is  dos format, i have to fix user scripts ("#!/bin/sh\r\n" -> "#!/bin/sh\n" ...)
[16:55] <smoser> i'd like your statement as to whether or not i should do that for upstart jobs
[16:58] <ion> It makes no sense to use \r\n in anything unixish.
[16:59] <cjwatson> ion: except for TCP/IP protocols
[16:59] <cjwatson> but yeah, files?  \n
[16:59] <smoser> agreed. but user input is from windows, and i would like to not change their content except when required.
[16:59] <smoser> because arbitrarily "fixing" things will break checksums that they might have calculated.
[17:01] <cjwatson> I'm fairly sure upstart/libnih treats \r like \n
[17:01] <smoser> at least that is why i wasn't going to change everything.
[17:02] <smoser> ie, if you did a wget of a file, you wouldn't want wget to change its content.
[17:05] <slangasek> mterry: sync> ack
[17:05] <mterry> slangasek, cjwatson grabbed it for me, but thanks
[17:09] <slangasek> mterry: ok, cool :)
[17:31] <SpamapS> jhunt_: I wonder if we can complete the transition to an upstart-only shutdown in oneiric.
[17:37] <jhunt_> SpamapS: would be good! I've added it to the wishlist: https://wiki.ubuntu.com/FoundationsTeam/OneiricPlanning#Ideas
[17:45] <SpamapS> jhunt_: so another thing I was wondering is whether we can implement grouping in upstart jobs. If we could say   initctl --exclude-group shutdown stop-all   .. and let upstart do this internally.. that gives us a very clean way to terminate everything
[17:47] <SpamapS> jhunt_: the problem with "disable spawning" is that you may need to spawn a few processes to shutdown cleanly.
[18:12] <bryceh> @pilot on
[18:12] <udevbot> (pilot (in|out)) -- Set yourself an in or out of patch pilot.
[18:12] <bryceh> @pilot in
[18:12] <bryceh> @pilot in
[18:35] <mterry> TheMuso, so ldtp and pyatspi2 don't get along packaging-wise (ldtp depends on pyatspi1 currently).  Is that just a packaging bug or is ldtp not compatible with atspi2?
[18:47] <tgardner> cjwatson, I'm thinking vga=788 isn't gonna work so well on bare metal. see bug #745947
[18:50] <akheron> bug #660483, what should I do now?
[18:51] <akheron> I've proposed a patch
[18:56] <bryceh> akheron, I'll take a look
[18:56] <bryceh> akheron, can you also add to the changelog the bug number that your patch fixes
[18:56] <bryceh> i.e.
[18:56] <bryceh> +  * Don't link to system's jquery.js, as it's too old (LP: #660483)
[18:58] <bryceh> akheron, sometimes I also like to mention the error message that goes away with the fix (so people with the problem can verify that this patch fixes it).  Totally not necessary though.
[18:59] <bryceh> akheron, if you post an update ping me and I can upload it for you, the change itself (removing the link) looks fine
[19:00] <akheron> bryceh: ok
[19:02] <cjwatson> tgardner: seems odd because that was actually a change inherited from Debian
[19:02] <tgardner> cjwatson, well, I've got it repro'd on at least one server.
[19:02] <cjwatson> tgardner: wait, is this a recent regression?
[19:03] <cjwatson> tgardner: they said it was fine in the alphas, and those used vga=788 too
[19:03] <tgardner> I wonder if it has to do with modularizing CONFIG_FB_VESA
[19:03] <cjwatson> I bet that we forgot to put vesafb in a udeb
[19:03] <tgardner> cjwatson, hmm, lemme check.
[19:03] <cjwatson> the installer has code to load it if it can
[19:03] <tgardner> actually, I'm sure of it
[19:04] <cjwatson> hm, it's in fb-modules
[19:04] <cjwatson> -rw-r--r-- root/root     14288 2011-04-01 00:11 ./lib/modules/2.6.38-8-generic/kernel/drivers/video/vesafb.ko
[19:04] <cjwatson> mind you, d-i is still on -7
[19:04] <tgardner> cjwatson, and in modules/fb-modules:vesafb
[19:05] <cjwatson> yeah
[19:05] <cjwatson> does it actually work when modularised, at the moment? :)
[19:06] <cjwatson> fb-modules is in the initrs
[19:06] <cjwatson> initrds
[19:07] <tgardner> cjwatson, dunno. I've been reading the stuff in Documentation/fb/fbcon.txt. it says if you specify vga= , then fbcon isn't loaded (which kind of looks like what is happening)
[19:07] <cjwatson> d-i explicitly loads fbcon
[19:08] <tgardner> cjwatson, I'm not nearly as familiar enough with this frame buffer stuff and early boot.
[19:09] <cjwatson> http://bazaar.launchpad.net/~ubuntu-core-dev/rootskel/ubuntu/view/head:/src/lib/debian-installer-startup.d/S40framebuffer-module-linux-x86
[19:12] <cjwatson> tgardner: you can add BOOT_DEBUG=3 and drive stuff by hand, FWIW
[19:12] <cjwatson> that gives you a shell at the start of /init
[19:13] <tgardner> cjwatson, ok, gimme a minute. this is easily reproducible using VMware
[19:14] <cjwatson> the execution flow is then the stuff in /init, then /sbin/debian-installer-startup, then /sbin/debian-installer
[19:14] <cjwatson> (but you shouldn't need the last bit)
[19:14] <cjwatson> it's nearly all shell, fairly easy to pick apart and run step by step
[19:14] <cjwatson> kvm doesn't show it (either default or -vga std)
[19:15] <tgardner> cjwatson, agreed, kvm was the first thing I tried.
[19:16] <tgardner> cjwatson, BOOT_DEBUG=3 on the syslinux command line, right?
[19:16] <cjwatson> yeah
[19:16] <tgardner> no joy
[19:16] <akheron> bryceh: ping, I added an updated patch
[19:17] <bryceh> akheron, thanks
[19:17] <cjwatson> tgardner: what variety of absence of joy?
[19:18] <cjwatson> oh, hm
[19:18] <cjwatson> you can type 'modprobe vesafb' blind
[19:18] <tgardner> cjwatson, a total absense of joy with vga=788 (e.g. no display whatsoever). I verified that BOOT_DEBUG=3 works without vga=788/
[19:19] <cjwatson> tgardner: that total absence of joy may be fixed by typing 'modprobe vesafb'?
[19:19] <cjwatson> fbcon is non-modular
[19:19] <cjwatson> is there a particular way to tell it to attach to a new fb, or is it just supposed to notice?
[19:20] <cjwatson> I'm open to the option of deleting vga=788 BTW, I just want to try as hard as possible not to since it really makes the installer a lot more pleasant
[19:20] <cjwatson> and actually, we used vga=788 in maverick
[19:20] <cjwatson> it's not a new thing in natty
[19:21] <tgardner> cjwatson, so if I blindly type 'modprob vesafb' then I get a console with BOOT_DEBUG=3. so, its definitely related to the modularization of VESAFB
[19:22] <bryceh> akheron, looks good, upload sponsored
[19:23] <akheron> bryceh: thanks
[19:23] <akheron> my first upload :)
[19:23] <bryceh> akheron, well then congrats :-)
[19:23] <cjwatson> tgardner: aha, so then the question is what happened to the existing code to run that
[19:25] <tgardner> cjwatson, at the point that the boot debug breaks, /proc isn't mounted.
[19:25] <cjwatson> indeed
[19:25] <cjwatson> cat /init
[19:25] <bryceh> akheron, for reference, in the future when you have patches to sponsor you can check the topic of this channel to see if someone is listed as Patch Pilot on duty, and if so give them a holler, and they'll help you get stuff uploaded
[19:25] <cjwatson> it's mounted right after that debug shell
[19:25] <akheron> bryceh: ok
[19:25] <tgardner> cjwatson, ok, that looks fine.
[19:26] <akheron> bryceh: I actually once worked on a new package, but fixing existing packages seems to be way easier :)
[19:26] <akheron> what comes to get the upload sponsored
[19:26] <akheron> *getting
[19:27] <cjwatson> tgardner: what does 'readlink /proc/self/fd/0' say, after you mount /proc?
[19:27] <tumbleweed> we are much more forgiving of lack of perfection in existing packages :)
[19:28] <tgardner> cjwatson, I exited busybox once to let init run, so /proc is now mounted, readlink /proc/self/fd/0 == /dev/console.
[19:28] <bryceh> akheron, 'upload sponsored' means your patch has been added to the ubuntu repository and will be live to natty users once the package has finished rebuilding (typically a couple hours, depends on the package and build server loads)
[19:29] <akheron> bryceh: yeah
[19:29] <akheron> bryceh: but this fix was actually targeted to the lucid backport only
[19:29] <bryceh> akheron, in this case since your patch is against lucid, it will also need to go through a review step
[19:29] <akheron> ah, ok
[19:29] <bryceh> subject: [ubuntu/lucid-backports] couchdb 1.0.1-0ubuntu3~lucid2 (Waiting for approval)
[19:30] <cjwatson> tgardner: hm, not quite the right test, one moment while I experiment
[19:30] <bryceh> I'm not sure how frequently lucid-backports gets reviewed though... could take anywhere from a few hours/days to maybe weeks
[19:30] <akheron> is there a backports team or such that does the approving?
[19:30] <bryceh> yes
[19:31] <akheron> ok, sounds good
[19:31] <akheron> and I'm not in that big a hurry, a few days is fine :)
[19:32] <bryceh> akheron, I'm not sure exactly who is on the team, but https://help.ubuntu.com/community/UbuntuBackports has some more information
[19:32] <cjwatson> tgardner: ok, reboot; in the first debug shell, 'modprobe vesafb; echo sh >/lib/debian-installer.d/S00sh' (no need to make it executable); exit twice; 'readlink /proc/self/fd/0'
[19:32] <cjwatson> in kvm, that gives me /dev/tty0
[19:32] <tgardner> cjwatson, ok, one sec while I get there
[19:34] <tgardner> cjwatson, readlink /proc/self/fd/0 == /dev/console
[19:35] <m4n1sh> pitti: send the brainstorm final mail to technical-board list. It might be in the moderation queue
[19:37] <cjwatson> tgardner: hm, so d-i's assumption is that that means serial
[19:37] <cjwatson> tgardner: is there a free vmware download that exhibits this, do you know?
[19:37] <tgardner> cjwatson, you can use it as an eval for 30 days AFAIK
[19:38] <cjwatson> ok, will just workstation do, do you think?
[19:38] <tgardner> cjwatson, yep, I'm using 7.1.4
[19:38] <cjwatson> ok, I can queue it up to give it a try, unless you want to continue
[19:39] <cjwatson> IIRC there is some weird interaction with stdin and the console in the depths of busybox init
[19:40] <tgardner> cjwatson, well, what would you like to try next? remember, I can get this on bare metal (buts a huge pain 'cause the server takes 3 minutes to boot)
[19:40] <tgardner> cjwatson, I could always de-modularize VESAFB for the -server flavour, but that seems like a hack.
[19:41] <cjwatson> I think what I ideally want is a set -x trace of debian-installer-startup, to see why it apparently isn't loading vesafb
[19:41] <cjwatson> there's a lot of blind typing involved there though
[19:42] <tgardner> cjwatson, ok, perhaps I'll let you handle it, ok?
[19:42] <cjwatson> after that ... not sure, might involve building a debug busybox init?
[19:42] <cjwatson> I'm happy to have a crack at it, although I do already have about a week's worth of work queued up that's beta-2-critical
[19:42] <cjwatson> but I guess we have an understood fallback option
[19:43] <tgardner> I'll dribble some notes in the bug report.
[19:43] <cjwatson> thanks - I'll give you a shout if it's looking impossible for me
[19:51] <tgardner> cjwatson, I'm sure you don't get enough email, so I've subscribed you to bug #745947. I'm sure this'll come up on skaet's radar pretty soon.
[19:52]  * tgardner --> lunch
[19:53] <cjwatson> ta
[19:58] <vish> SpamapS: hi, i think you also have to comment asking people to test the -proposed.. pitti uses a reply template for SRUs; otherwise people wont know how they have to test it.. (noticed it on the compiz bug)
[20:00] <vish> or was that the initial ACK? (/me confused, normally used to seeing pitti do those :D )
[20:01] <micahg> vish: that happens when it's accepted I believe
[20:01] <vish> ok, seems something new.. i blame pitt-i ! ;p
[20:02] <micahg> vish: or rather, when review/accepted at the same time, that notice is used since the package is building, it's hard to post it before it's actually accepted since you don't know when the package will build
[20:02] <vish> ahhh! its still building
[20:05] <SpamapS> vish: I do not have the ability to accept the package into -proposed yet, as pitti is still training me, so he will see that message and accept it.
[20:06] <SpamapS> I'd make a template, but I'm hoping we'll finish with the training-wheels soon and I can just use his template.
[20:06] <vish> SpamapS: cool, thanks! dint know that.. :) (thought you approved it)
[20:29] <SpamapS> vish: well I "approve" it, but Pitti pulls the big red handle to make it actually go. :)
[20:29] <vish> righto, i meant accepted :)
[20:30] <sladen> ivanka-train: cunning.  how did you manage that?
[20:31] <ivanka-train> sladen: which bit?
[20:31] <sladen> ivanka-train: not dropping IRC while transitioining?
[20:31] <ivanka-train> sladen: skillz
[20:32] <ivanka-train> sladen: it will drop - but network manager handles the tunnels rather well without throwing its toys out
[21:09] <hallyn> I pushed a package to lucid-proposed.  Where do I go to track whether I properly caused a package build?
[21:10] <micahg> hallyn: was it accepted yet?

[21:10] <hallyn> how do I tell? :)
[21:10] <micahg> hallyn: you can look at launchpad.net/ubuntu/+source/foo to see about any package in the archive
[21:10] <tgardner> hallyn, https://launchpad.net/ubuntu/lucid/+queue
[21:10] <hallyn> (sorry, by 'pushed' i meant 'bzr push', not dput)
[21:11] <hallyn> ok, thanks, lemme check those
[21:11] <micahg> hallyn: ah, that's different :)
[21:11] <micahg> hallyn: you should be able to do bzr lp-open in the dir I think
[21:12] <hallyn> hm, i don't think i did it right
[21:14] <micahg> hallyn: which package?
[21:14] <hallyn> lp:ubuntu/lucid-proposed/qemu-kvm
[21:14] <hallyn> it did update in bzr
[21:15] <hallyn> but from the bzr source page i don't see how to go to package builds
[21:15] <micahg> hallyn: that doesn't work yet
[21:15] <micahg> hallyn: you can to create a source package like normal from the bzr branch and upload
[21:21] <hallyn> micahg: doh.  are you saying that only doesn't work for -proposed?
[21:21] <hallyn> or for anything?
[21:21] <micahg> hallyn: you can't build from branch unless it's a source recipe for a PPA
[21:22] <micahg> AFAIK
[21:22] <hallyn> micahg: good to know.  i didn't know that :)
[21:22] <micahg> hallyn: once you push the bzr branch, you can have to still use bzr-builddeb to create a source package
[21:22] <hallyn> thanks, will just dput then
[21:22] <hallyn> well do, thx
[21:22] <hallyn> (was just trying to be as UDD as possible :)
[21:48] <hallyn> slangasek: so i did a bzr push to lp:ubuntu/lucid-proposed/qemu-kvm, thinking (wrongly) that would kick a build.  Now I can't dput the src package from the same tree bc it sees it already there.  Should I bzr uncommit and push --force?  Is there something better to do?
[21:48] <slangasek> hallyn: I don't understand what you mean, "it sees it already there".  Can you paste me the error?
[21:49] <hallyn> it rejected in email, i can fwd that
[21:49] <slangasek> yes please
[22:17] <slangasek> hallyn: so the reason for the reject is that the 0.12.3+noroms-0ubuntu9.4 *version* already exists; it appears to have been a security update, so it was never uploaded to lucid-proposed
[22:17] <slangasek> hallyn: you'll want to untag your version from the lucid-proposed branch, merge in the version from lucid-updates/lucid-security, and re-push your changes on top
[22:17] <hallyn> slangasek: d'oh, but that's not in lucid yet either right?
[22:18] <hallyn> (i checked the bzr tree and didn't see it there)
[22:18] <slangasek> hallyn: the "lucid" bzr branch is never updated after the release
[22:19] <hallyn> ah
[22:19] <slangasek> so this is only in the updates and security branches
[22:19] <hallyn> even with an SRU?
[22:19] <slangasek> yes
[22:19] <slangasek> SRUs are published in -updates
[22:19] <hallyn> oh!
[22:19] <hallyn> got it
[22:19] <hallyn> slangasek: thanks much.  i think it's clear to me now
[22:19] <slangasek> sure thing :)
[23:13] <bryceh> @pilot out
[23:14] <hallyn> slangasek: yay, upload worked.  (now just waiting for approval)
[23:31] <Keybuk> jono: hey
[23:38] <jono> hey Keybuk
[23:38] <jono> hows tricks?
[23:38] <Keybuk> good thanks, you?
[23:41] <poolie> hi keybuk
[23:41] <poolie> RAOF_, hi, can you have a look at bug 749817 for me?
[23:41] <poolie> is there anything i can do to help move it along?
[23:51] <penguin42> poolie: You might like to attach the output of intel_reg_dumper from the intel-gpu-tools package in both the normal and broken states
[23:52] <poolie> ok, thanks
[23:52] <penguin42> I also wonder, shouldn't that be against xserver-xorg-intel or whatever the correct intel specific name is?
[23:53] <RAOF_> penguin42: No, we like X bugs to be filed against xorg.
[23:53] <penguin42> RAOF_: Oh ok, didn't know that - I'd moved a few to the specific ones in the past
[23:53] <Keybuk> jono: but in answer to your tweet, no
[23:53] <Keybuk> I'm not attending LF Collab this week
[23:54] <RAOF_> penguin42: No, that's generally right.  We just encourage people to *file* bugs against xorg, where we can dispatch them appropriately.
[23:54] <penguin42> ok
[23:57] <jono> Keybuk, np