[00:07] <geser> cjwatson: as you seem to be pretty knowledgeable about package sets: do you know or have an idea why the "xubuntu" package set isn't included in the packagesets collection of the LP API?
[00:08] <cody-somerville> geser, I don't think one exists.
[00:10] <geser> it can be queried with edit-acl.py
[04:38] <netadmin> hi
[04:40] <netadmin> j #ubuntu-network
[04:41] <netadmin> ah sorry, i'm typo /
[05:36] <ScottK> Riddell: https://launchpad.net/ubuntu/natty/powerpc/libpackagekit-qt14/0.6.10-1 landed in Universe by mistake which is why kpackagekit won't build on powerpc.  Would you please promote it.
[06:26] <handmaster> hello. i made a client and a server. i have a break point in my server code, but how do i run my client?  my client is in bin/debug but double click on it does nothing.
[06:26] <handmaster> system monitor also does not show it even starting
[07:03] <dholbach> good morning!
[07:03] <Simira> morning Daniel
[07:03] <ebroder> Morning, dholbach
[07:03] <dholbach> hey Simira, hey ebroder
[07:03] <dholbach> Simira, long time no see - how are you doing?
[07:27] <dholbach> RoAkSoAx, congratulations!
[07:44] <pitti> Good morning
[07:44] <\sh> good morning pitti
[07:46] <RoAkSoAx> dholbach thank ypou!!
[07:46] <dholbach> :-)
[08:33] <tkamppeter> pitti, hi
[08:34] <pitti> hello tkamppeter
[08:35] <tkamppeter> pitti, for bug 690040 you are looking for returning CUPS back to init scripts? For me such a step looks like that Upstart is a completely broken concept.
[08:37] <tkamppeter> pitti, is there no possibility to get the sequence: start apparmor -> start cups -> wait for cups being ready -> start samba with upstart?
[08:37] <pitti> tkamppeter: it would make things a bit easier (share package/script with Debian again, avoid apparmor race condition)
[08:37] <pitti> tkamppeter: as I wrote in the bug, it'd be even better if apparmor could move to an upstart script
[08:38] <pitti> although, hmm
[08:38] <pitti> but yes, I think there's some trick how to do state based conditions, with environment variables
[08:38] <tkamppeter> pitti, I think this would really better, when using Upstart, everything should get moved to Upstart.
[08:38] <pitti> so, would require some tinkering, but with an apparmor upstart script it'd work better
[08:39] <pitti> tkamppeter: we just need to drop thaht silly "restart samba" bit from cups' job, and update the samba upstart job to wait on cups if cups is available
[08:39] <tkamppeter> The CUPS/Samba problem looks for me like that Samba already starts when the CUPS daemon is not yet ready.
[08:39] <pitti> I don't know how to do this currently, but we have some experts here :)
[08:40] <pitti> my other worry is that cups now starts a lot earlier
[08:40] <pitti> (but it doesn't need to really)
[08:40] <pitti> in terms of boot speed, and keeping the CPU free for the really urgent things
[08:41] <tkamppeter> pitti, if all startup dependencies are well defined, there should be no daemon starting too early or too late.
[08:41] <maco> pitti: would it be possible to make the apparmor start script emit an event?
[08:42] <tkamppeter> pitti, if you want CUPS to start after the gdm is up, make a dependency between CUPS and gdm.
[08:42] <maco> if making it fully upstartified is too much work...
[08:43] <pitti> maco: ah, "initctl emit"?
[08:43] <hyperair> what's wrong with blocking on "started samba"?
[08:43] <pitti> maco: yes, but event based waiting conditions don't work with optional components
[08:43] <maco> pitti: uhh...if that's the command keybuk put in his blog post the other day, then sure ;-)
[08:43] <hyperair> ahh
[08:43] <maco> oh
[08:44] <pitti> maco: as you can uninstall, or separately upgrade apparmor
[08:44] <pitti> hyperair: samba isn't installed by default, and optional
[08:44] <hyperair> pitti: yeah, i just realized.
[08:44] <pitti> hyperair: or actually the other way around
[08:44] <pitti> samba "start on started cups" doesn't work if you uninstall cups
[08:44] <pitti> or you upgrade the samba package
[08:44] <hyperair> right.
[08:44] <tkamppeter> pitti, one should add a feature to Upstart, like "wait for XXX if XXX is available".
[08:45] <pitti> tkamppeter: that's called "weak dependency", like the "Should-Start:" in the LSB init.d headers, FYI
[08:45] <pitti> tkamppeter: but it's hard to express in terms of events, I think
[08:46] <hyperair> pitti: how about.. start on local-filesystems or (local-filesystems and cups)
[08:46] <hyperair> pitti: and then add a pre-start hook to check if cups exists.
[08:47] <hyperair> pitti: would that work?
[08:47] <pitti> a || (a and b) -> that's just "a"?
[08:47] <pitti> hyperair: pre-start hook could work, yes
[08:47] <hyperair> pitti: er i was hoping it could end up starting twice, where the first time fails the check, and the second time starts it for real?
[08:48] <pitti> hyperair: bit expensive to write, though (as you need to poll for a process)
[08:48] <hyperair> pitti: make use of a rather large sleep?
[08:48] <pitti> hyperair: I don't know how upstart implements that
[08:48] <pitti> hyperair: that'd feel cheesy
[08:48] <hyperair> pitti: i know, but we have a lot of long sleeps in the bootchart and ureadahead scripts.
[08:48] <pitti> hyperair: my truly preferred option would be to add socket activation to upstart :)
[08:49] <hyperair> pitti: which feel cheesy as well. perhaps it's time to give upstart more power
[08:49] <hyperair> pitti: er socket activation? like xinetd?
[08:49] <pitti> like systemd
[08:49] <hyperair> hmm i haven't actually looked into systemd before
[08:58] <pitti> mdz: argh, the merge proposals are back at the TB moderation queue
[09:03] <diwic> doko_ or barry, since you wrote I should ping you with a python 2.7 error, we have bug #688535 which makes it impossible to report (some?) bugs with apport
[09:04] <diwic> doko_ or barry, seems like locale.format does not accept the same type of format strings anymore
[09:59] <hyperair> pitti: i have a solution for the cups/samba issue.
[09:59] <tkamppeter> hyperair, great. Please tell us.
[09:59] <hyperair> tkamppeter: in cups.conf, put: start on (starting NEED_CUPS=1 or ..... )
[10:00] <hyperair> tkamppeter: and in smbd.conf, put env NEED_CUPS=1\nexport NEED_CUPS
[10:00] <tkamppeter> hyperair, and what happens if samba is not installed.
[10:00] <pitti> hyperair: interesting
[10:01] <hyperair> tkamppeter: it's an "or" condition. cups will get started anyway.
[10:01] <hyperair> tkamppeter: just that order doesn't matter so much now.
[10:01] <hyperair> pitti: i got it from here: http://www.netsplit.com/2010/12/03/event-matching-in-upstart/
[10:01] <hyperair> i never knew you could put starting without any service name
[10:03] <tkamppeter> hyperair, but there are the following problems:
[10:03] <hyperair> tkamppeter: ?
[10:05] <tkamppeter> hyperair, 1. If Samba triggers the start of CUPS via setting NEED_CUPS, CUPS starts, regardless whether the requirements of CUPS, especially a running AppArmor and the loopback device lo are present.
[10:05] <hyperair> tkamppeter: that sucks.
[10:06] <hyperair> tkamppeter: if we put "and" would that help?
[10:06] <tkamppeter> hyperair, 2. If Samba triggers the start of CUPS it must still wait until the CUPS daemon is listening. Usually the daemon take a second or so until being ready.
[10:07] <tkamppeter> hyperair, if we put "and" and Samba is not installed, CUPS will never start.
[10:07] <hyperair> tkamppeter: okay, maybe we need to poke scott. =p
[10:10] <tkamppeter> hyperair, I think that would be the best.
[10:10] <hyperair> yeah
[10:10]  * hyperair thinks events and boolean operators don't really go well together =\
[10:10] <tkamppeter> hyperair, he could also do fixes or add features on Upstart.
[10:10] <hyperair> yeah
[10:23] <Keybuk> what's the thing that's not screen that does unicode
[10:23] <maco> tmux?
[10:24] <Keybuk> that's the one I was thinking of, thanks
[10:25] <ion> I’m using it. I’ve been quite happy with it.
[10:25] <maco> Keybuk: things i osmosis off of crimsun :P
[10:25] <hyperair> tkamppeter: oh hey look Keybuk's here.
[10:25] <maco> haha
[10:26] <hyperair> =p
[10:26] <maco> you're not gonna grab pitti too?
[10:26] <hyperair> looks like you did that. =)
[10:26] <maco> wait dangit.. if the english are all online, that means i really really really should go to bed
[10:26] <hyperair> Keybuk: so anyway, there was an issue with cups and samba, where samba needs to start after cups, but still be able to start if cups isn't installed. how does one design upstart jobs for this?
[10:27] <mok0> Hm, my sbuilder fails with "installing python2.7-minimal would break existing software"
[10:27] <Keybuk> hyperair: the problem with that is that samba is done with Upstart
[10:27] <Keybuk> whereas cups is done with sysvinit
[10:27] <hyperair> Keybuk: no, cups has an upstart job.
[10:27] <mok0> Don't understand why it wants to install python2.7-minimal...
[10:27] <maco> mok0: natty?
[10:27] <mok0> maco: yes
[10:28] <Keybuk> hyperair: oh, it didn't used to have
[10:28] <hyperair> Keybuk: yeah, but it does in maverick.
[10:28] <maco> mok0: python minimal isnt part of a base install?
[10:28] <hyperair> Keybuk: the current solution is to kill -HUP samba if cups is started after samba.
[10:28] <mok0> maco: I'll look
[10:28] <Keybuk> hyperair: the best fix for that is for cups to insert itself into samba's starting event
[10:28] <maco> mok0: i thought there was an email about python being in a very umm fun... state for a while as the 2.7 transitin happens
[10:28] <Keybuk> so when samba is started, it blocks until cups is running
[10:28] <hyperair> Keybuk: i proposed that, but then cups would not start if samba doesn't exist.
[10:29] <pitti> Keybuk: we had that, but that breaks upgrades of cups
[10:29] <pitti> Keybuk: as cups then waits forever if samba is already running
[10:29] <Keybuk> hmm
[10:29] <Keybuk> so you have two jobs that both depend each other if the other is installed
[10:29] <pitti> (or samba isn't installed at all)
[10:29] <Keybuk> otherwise don't?
[10:29] <pitti> Keybuk: not on each other, cups doesn't need samba
[10:29] <mok0> maco: it has python-2.6-minimal
[10:29] <mok0> maco: the package I want to build doesn't depend on python
[10:29] <pitti> Keybuk: we basically have samba should-start: cups
[10:30] <Keybuk> in samba.conf:
[10:30] <Keybuk> pre-start exec start cups ?
[10:30] <pitti> with an || true?
[10:30] <hyperair> but cups depends on things.
[10:30] <Keybuk> yeah
[10:30] <Keybuk> hyperair: the start cups can be
[10:31] <Keybuk> pre-start exec initctl emit need-cups
[10:31] <Keybuk> where cups.conf has on need-cups
[10:31] <Keybuk> if there's no cups.conf, need-cups will just finish straight away
[10:31] <Keybuk> if there's a cups.conf, need-cups gets picked up and blocked by it
[10:31] <hyperair> Keybuk: but what if samba isn't installed, and nothing emits needs-cups?
[10:31] <pitti> Keybuk: so do we need the needs-cups var, or should "pre-start exec start cups" suffice?
[10:32] <Keybuk> pitti: well, I was just looking at cups and samba
[10:32] <Keybuk> and it looks like they start on the same condition anyway
[10:32] <Keybuk> so pre-start exec start cups would work
[10:32] <Keybuk> probably best option
[10:32] <pitti> ah, that's much simpler indeed
[10:32] <pitti> thans
[10:32] <pitti> thanks, too
[10:33] <cjwatson> geser: lapack done.  (I don't seem to be getting these devel-permissions mails; odd)
[10:33]  * Keybuk makes sure this one is in the use cases for 2
[10:33] <Keybuk> I think it should just work, but I'll make sure there's a test case for it
[10:35] <cjwatson> geser: xubuntu in lp.packagesets> um, no idea, sorry
[10:35] <tkamppeter> Keybuk, pitti, do we take into account that CUPS has some delay? It takes a second or so after being started until the CUPS daemon is actually listening.
[10:36] <maco> mok0: but the 2.6 to 2.7 transition is going on now. dependies are probably broken somewhere in the chain
[10:36] <Keybuk> tkamppeter: you can do that in cups.conf with a post-start script that waits for it
[10:36] <cjwatson> ScottK: libpackagekit-qt14 promoted
[10:36] <Keybuk> upstart doesn't consider a job running until the post-start finishes
[10:36] <mok0> maco: I guess. But how do I get my sbuilder to work? :-(
[10:37] <tkamppeter> Keybuk, then this is solved for CUPS.
[10:37] <mok0> maco: the schroot has a kept-back update of python-minimal. Perhaps I can pin it
[10:37] <cjwatson> pitti: socket activation is on the upstart plan for natty, FYI
[10:37] <cjwatson> since you asked
[10:37] <pitti> cjwatson: cool!
[10:38] <Keybuk> cjwatson, pitti: lp:~scott/upstart/bridges
[10:38] <Keybuk> where "on the plan" includes "took scott 2 hours one night to implement"
[10:38] <cjwatson> well, yes :)
[10:40] <Keybuk> though it obviously needs testing and a few bug fixes
[10:40] <mvo> woah!
[10:48] <mdz> pitti: yeah, I noticed that too (merge proposals in moderation)
[10:48] <mdz> pitti: are you already talking to a Launchpad dev about it, or should I?
[10:49] <pitti> mdz: I'm not even sure what changed again; I haven't contacted LP folks yet
[10:49] <mdz> pitti: maybe nothing changed, and it was coincidence that the queue was empty (someone else cleared it out?)
[10:49] <Keybuk> mdz: oh, while you're here
[10:49] <Keybuk> you may notice some funny business going on with my LP account
[10:49] <AnAnt> Hello, I am getting this build failure on natty: http://launchpadlibrarian.net/60640251/buildlog_ubuntu-natty-i386.drawtiming_0.7.1-2_FAILEDTOBUILD.txt.gz  , yet it builds fine in maverick. Note that both natty & maverick have the save version of graphicsmagick. Build fails during linking, any clues ? Could it be related to doko's email about "gcc in natty now passes --as-needed by default to the linker" ?
[10:50] <mdz> Keybuk: are you in the office today? I thought I saw you walk by
[10:50] <Keybuk> LOOK OVER THERE!  A THREE HEADED MONKEY!
[10:50] <Keybuk> mdz: I am
[10:50] <doko_> pitti: could you have a look at #688535 (what diwic reported before)
[10:51] <AnAnt> doko_: ^
[10:52] <doko_> AnAnt: g++ -I/usr/include/GraphicsMagick   -DYYDEBUG=1 -g -O2  -Wl,-Bsymbolic-functions -o drawtiming -lGraphicsMagick++ -lGraphicsMagick   main.o parser.o scanner.o timing.o
[10:52] <doko_> move the objects before the libs
[10:52] <AnAnt> ok
[10:53] <AnAnt> doko_: is that a binutils-gold thing ?
[10:53] <mok0> Bah, pinning doesn't work, the python transition just screws everything up
[10:54] <mdz> pitti: I read http://raphaelhertzog.com/2010/11/15/save-disk-space-by-excluding-useless-files-with-dpkg/ and my first thought was "what about the bug reports we'll get when people break their systems this way?"
[10:54] <mdz> maybe apport should check for that before filing a bug?
[10:54] <mdz> Keybuk: what sort of funny business?
[10:54] <pitti> mdz: right, that was one of the things I was working on with Raphael during my OEM cycle
[10:54] <doko_> AnAnt: no, it is needed for the --as-needed default
[10:55] <Keybuk> mdz: I've now got two launchpad accounts
[10:55] <Keybuk> one with my canonical address and all the old bug subscriptions
[10:55] <Keybuk> and a new one with my home address and team memberships
[10:55] <pitti> mdz: we could, but if it's only used for filtering out /usr/share/doc/, things should still work
[10:55] <pitti> doko_: on my list
[10:56] <doko_> now that is intersting ...
[10:56] <doko_> checking for corosync/cpg.h... yes
[10:56] <doko_> Session terminated, killing shell...checking for cpg_initialize in -lcpg... make: *** [debian/stamp-autotools] Terminated
[10:56] <doko_> Terminated
[10:56] <doko_>  ...killed.
[10:56] <doko_> Build killed with signal 15 after 150 minutes of inactivity
[10:57] <pitti> doko_: ah, that worked in 2.6 still, apparently locale.format() got much stricter in 2.7
[10:58] <mdz> Keybuk: declaring launchpad bankruptcy?
[10:58] <mdz> I've thought about just getting myself unsubscribed from all bugs older than a certain date
[10:59] <pitti> doko_: fixing
[10:59] <Keybuk> mdz: well, with leaving
[10:59] <Keybuk> I don't want the 142,000 bug subscriptions
[10:59] <Keybuk> and blueprint subscriptions
[10:59] <Keybuk> and things I added to the launchpad registry when was on the bzr team and still get mails about
[10:59] <Keybuk> etc.
[11:00] <mdz> Keybuk: sure, but is it really easier to set up a whole new account than to get that cruft removed?
[11:00] <mdz> I'd rather not have to change LP accounts just to cut down on the amount of spam I receive
[11:00] <Keybuk> mdz: apparently so
[11:00] <Keybuk> we looked into the problem of just purging the data
[11:00] <doko_> pitti: thanks ... preparing for a flood of bug reports
[11:00] <Keybuk> and apparently it's so hard, nobody wants to contemplate
[11:01] <Keybuk> e.g. you could purge all the bug associations
[11:01] <Keybuk> but then the karma system would assert because you have more karma than you should have
[11:01] <Keybuk> etc.
[11:01] <Keybuk> whereas renaming accounts is an understood problem
[11:02] <cjwatson> launchpadlib to go through and unsubscribe everything? :)
[11:02] <cjwatson> (I realise it's too late)
[11:02] <Keybuk> cjwatson: you can't unassign yourself from bugs that have been marked as dups of things
[11:02] <Keybuk> not without un-dupping and re-dupping
[11:03] <Keybuk> and that wouldn't take into account all the ownerships I had in LP
[11:03] <maco> seriously?
[11:03] <maco> that's a stupid limitation
[11:03] <cjwatson> I thought that had been fixed ages ago ...
[11:03] <cjwatson> I guess not
[11:07] <mok0> dpkg: considering deconfiguration of python-minimal, which would be broken by installation of python2.7-minimal ...
[11:07] <mok0> ?
[11:08] <mok0> catch 22
[11:08] <pitti> mok0: is this a normal dist-upgrade?
[11:08] <pitti> it should upgrade python-minimal
[11:09] <mok0> pitti: it's my schroot environment
[11:09] <mok0> pitti: for natty
[11:09] <pitti> mok0: I mean, did you see this during dist-upgrade?
[11:09] <pitti> or what did you try?
[11:09] <mok0> pitti, in my natty builder, I did apt-get upgrade
[11:09] <pitti> right, upgrade won't suffice
[11:10] <pitti> you need dist-upgrade
[11:10] <mok0> pitti: and then apt-get install python2.7-minimal
[11:10] <Keybuk> cjwatson: yeah, the whole stack of things that stacked on top of stacks got scary
[11:10] <pitti> mok0: right, you can't install python2.7-minimal with python-minimal 2.6, that wreaks havoc; that's why we added the Breaks:
[11:10] <pitti> mok0: do a dist-upgrade, or install python-minimal instead
[11:10] <mok0> pitti: thx will try dist-upgrade
[11:11] <pitti> mok0: please let me know if that works properly
[11:11] <mok0> pitti, nope, same error
[11:12] <mok0> pitti, http://pastebin.com/6q5fgvGb
[11:12] <pitti> mvo: ^ any idea why apt just doesn't do that?
[11:13] <pitti> if you upgrade p-minimal to 2.7, then the breaks: is solved
[11:14] <pitti> mvo: instead of "Breaks: python-minimal (<< 2.7.1~)
[11:14] <pitti> mvo: .. should we add "Depends: python-minimal (>= 2.7.1~)" instead?
[11:14] <pitti> mvo: the thing that we need to avoid is to configure any python2.7* stuff with python-minimal 2.6 still installed
[11:16] <mvo> pitti: hm, is that reproducable in a chroot? I can look after lunch
[11:16] <pitti> mvo: I guess a maverick chroot (or a natty system with 2.6 installed) and dist-upgrading?
[11:17] <mok0> mvo, what I have is a natty sbuilder
[11:20] <mvo> pitti, mok0: thanks, let me check it
[11:28] <Riddell> bryceh: bug 690122
[11:32] <mvo> pitti: hm, I don't think the depends will work either (instead of the break) - that needs a closer look. why do we want to avoid 2.7* stuff with 2.6 minimal? (I will read scrollback, gtg for lunch now)
[11:32] <pitti> mvo: python2.7 mustn't call the 2.6 version of pycompile from the python-minimal package
[11:32] <pitti> mvo: (in its postinst)
[11:33] <pitti> mvo: why wouldn't a depends: work? because it's circular?
[11:34] <pitti> mvo: (that's why I suggested using breaks: to the older version)
[11:40] <mdz> cjwatson: you're chairing TB today, right?
[11:40] <cjwatson> mdz: yes
[11:40] <mdz> cjwatson: ok, thanks
[11:55] <doko> kenvandine: libdesktop-agnostic is another gir-repository issue. could you have a look?
[12:39] <ScottK> cjwatson: Thanks (libpackagekit-qt14) - kpackagekit built on powerpc now, so one more FTBFS down.
[12:48] <pitti> cjwatson: *phew*, I'm finally done with bug 415038, FYI; all fixed up now
[12:49] <cjwatson> ok, thanks, will have a look once I'm finished with current task
[12:50] <Riddell> kirkland: is jplayer useful as a local package?
[13:27] <sabdfl> hi folks, hotel network isn't allowing connections to port 587, or normal smtp, of smtp.canonical.com
[13:27] <sabdfl> any suggestions?
[13:28] <sabdfl> blech, wrong window!
[13:29] <cdbs> :)
[13:29] <cdbs> *:(
[13:33] <kenvandine> doko, i can look at that
[13:35] <smoser`> @pilot in
[13:35]  * dholbach hugs smoser
[13:36] <Simira> dholbach: I was right off to work this morning. How are you? We just filled up the house with another dog!
[13:37] <dholbach> Simira, oh wow! what kind?
[13:37] <Simira> dholbach: Rhodesian Ridgeback :D
[13:37] <dholbach> Simira, just this second I was about to take my dog out for a walk and get lunch
[13:38] <dholbach> Simira, wow - that's a bit bigger than your other dog, right? :)
[13:38] <Simira> http://www.simira.net/gallery/Hund/2010-11-24-Bergen-Hemsedal-div/slides/P1000883.html
[13:38] <Simira> slightly
[13:38] <Simira> 6 months and 35 kg now
[13:39] <dholbach> wow :)
[13:39] <Simira> dholbach: have a nice lunch! Make sure your dog gets his part!
[13:39] <dholbach> Simira, the dog will make sure - no problems :-P
[13:39] <dholbach> see you :)
[13:42] <doko> is Bilal Akhtar here in the channel?
[13:43] <cjwatson> doko: meet cdbs
[13:43] <mvo> pitti: hey, soory for the delay. the depends is circular, dpkg/apt do not like that for essential packages
[13:43] <mvo> pitti: I look at it again to see what can be done
[13:46] <doko> cdbs: ping
[13:48] <cdbs> doko: yes?
[13:48] <cdbs> I got your mail, but the other way to link the library wasn't working
[13:49] <cdbs> I tried many many times, including the way you mentioned in your mail to ubuntu-devel last month
[13:49] <jdstrand> pitti: haven't read all the backscroll, but the cups thing is known (as of a couple weeks). you just need to start it like mysql, with something like this in the upstart job file: http://paste.ubuntu.com/543589/
[13:50] <doko> cdbs: then please just file a bug.
[13:50] <doko> cdbs: are there other uploads like this one?
[13:51] <cdbs> doko: looking at your uploads, I don't see any such of them
[13:51] <cdbs> doko: the problem is, the package links agianst a library it itself builds
[13:52] <cdbs> and adding  --no-as-needed -lcourier-authlib doesn't seem to work --as-needed
[13:52] <doko> cdbs: right, then the build system has to be fixed
[13:52] <doko> I'll look at it
[13:52] <cdbs> doko: thanks, I 'll re-open bug
[13:53] <cdbs> oh, you already did that
[13:55] <pitti> mvo: how do you mean?
[13:55] <pitti> mvo: we currently have p-minimal depends: p27-minimal, and p27-minimal breaks: p-minimal (< 2.7)
[13:55] <pitti> mvo: and apparently that causes apt to hold back both, instead of upgrading both
[13:56] <pitti> jdstrand: right, i've seen it in avahi
[13:56] <pitti> jdstrand: but I really don't like it
[13:58] <jdstrand> I see that now after having read the bug
[13:59] <kirkland> Riddell: it's something that web applications could depend on and use
[13:59] <kirkland> Riddell: currently, there is a snapshot of jplayer embedded in the 'musica' application
[14:00] <kirkland> Riddell: but it would be better if 'musica' just depended on jplayer
[14:00] <jdstrand> pitti: it might be enough to test for /sys/kernel/security/apparmor/profiles, but a) we want to double check that with jj-afk and b) that is going to have to be updated once we lose the compatibility patch
[14:00] <kirkland> Riddell: other web apps could use it too
[14:00] <jdstrand> pitti: (that is instead of 'aa-status')
[14:00] <seb128> cjwatson, hey, could the desktop set get access to vte?
[14:00] <pitti> jdstrand: I actually meant calling apparmor_parser to force-start it
[14:00] <jdstrand> apparmor_parser is an ELF
[14:00] <kirkland> Riddell: or you could make your own homepage or blog or whatever and just 'apt-get install jplayer' and then embed music there
[14:01] <pitti> jdstrand: IMHO cups should just wait on apparmor to start
[14:01] <kirkland> Riddell: it's very HTML5-y ;-)
[14:01] <pitti> instead of a lot of programs having to manually call apparmor bits
[14:01] <jdstrand> pitti: right. we've talked about an apparmor upstart script, but it is fraught with peril. kees is way more up on it than I though, so he can get into that more
[14:01] <pitti> jdstrand: so, it's obviously the right solution for a maverick update
[14:03] <jdstrand> pitti: we've also considered an apparmor helper doodad that upstart could use (that would ship with upstart) that would do this as well. that hasn't happened yet
[14:03] <Riddell> kirkland: ok, accepted
[14:03] <jdstrand> pitti: but yes, the current situation is not ideal and not the long term plan, but it does work
[14:04] <kirkland> Riddell: cheers, thanks
[14:04] <kirkland> Riddell: hey, question for you ...
[14:04] <kirkland> Riddell: did I handle the debian/copyright file correctly?
[14:04] <kirkland> Riddell: the project says that it's dual licensed, MIT/GPL
[14:05] <kirkland> Riddell: in that case, as distributor, do we just pick one?  or do we put both licenses there, and let the end user pick one?
[14:05] <Riddell> kirkland: we don't tend to pick one, we tend to put both into the copyright file
[14:05] <doko> pitti, mvo: while you discuss this, please could you accept the python-defaults for -proposed?
[14:06] <kirkland> Riddell: ah, okay, i'll upload again adding the MIT license too
[14:06] <kirkland> Riddell: thanks
[14:08] <Riddell> kirkland: famfamfam-silk likewise needs a copyright change, ping me when you reupload it if you want a quick review
[14:09] <cjwatson> seb128: done
[14:10] <seb128> cjwatson, thanks
[14:10] <kirkland> Riddell: i'm adding that now
[14:12] <kirkland> Riddell: the license is in full in the file LICENSE in the root directory of the orig.tarball
[14:13] <kirkland> Riddell: that's the only reason i didn't embed it in debian/copyright
[14:13] <kirkland> Riddell: but i'm copying it there now
[14:13] <jdstrand> didrocks: I'm confused by your response to bug #690011
[14:14] <jdstrand> didrocks: you implied that I either did something wrong or didn't do something that I had no idea I would need to do (and surely other people wouldn't either)
[14:14] <seb128> didrocks, is everybody supposed to run unity --reset?
[14:14] <didrocks> jdstrand: unity --reset and ensure to have latest compiz
[14:15] <didrocks> seb128: I think it will impact everybody yes
[14:15] <seb128> didrocks, shouldn't add a session snippet doing that?
[14:15] <seb128> shouldn't we add...
[14:15] <jdstrand> didrocks: I understand that part. I don't understand why I need to do that or why that wasn't done for me or why I should know about it :)
[14:15] <seb128> it seems suboptimal to break everybody's session and tell them to run --reset
[14:15] <didrocks> seb128: that will be nice, but I didn't have the time to come with that solution, we don't have a script starting, right?
[14:15] <didrocks> seb128: right, but as long as upstream doesn't support migration path, and there was a rename this time
[14:16] <seb128> well we could add an autostart desktop in /usr/share/autostart
[14:16] <seb128> just for one day or two
[14:16] <jdstrand> I'll let seb128 take it from here...
[14:16] <didrocks> jdstrand: it's just upstream didn't rename every gconf path
[14:16] <didrocks> jdstrand: and they fix one after another
[14:16] <didrocks> (compiz upstream)
[14:16] <seb128> didrocks, what is gnome-session starting? compiz?
[14:16] <seb128> didrocks, is there any wayt to have the unity --reset in the session for a day?
[14:16] <jdstrand> 'Sorry, Compiz closed unexpectedly'
[14:17] <didrocks> seb128: can add that
[14:17] <seb128> jdstrand, that seems a crash, see if apport cna report it
[14:17] <jdstrand> oh, it is definitely a crash. I have no window manager :)
[14:17] <seb128> didrocks, that would be nice, that would avoid having to deal with people on IRC, bug reports, and to confuse users
[14:17] <didrocks> seb128: I can do taht now
[14:17] <seb128> didrocks, thanks
[14:17] <didrocks> seb128: hum
[14:17] <seb128> didrocks, you rock ;-)
[14:17] <jdstrand> I can't click the button-- my irc is in the foreground
[14:17] <didrocks> seb128: no, I need to put that in a script
[14:18] <seb128> jdstrand, yeah, go to a vt and DISPLAY=:0 compiz
[14:18] <seb128> then compiz --replace in your session
[14:18] <seb128> so it uses the right profile
[14:18] <didrocks> seb128: hum, we should be clever enough for that and let it until alpha2
[14:18] <seb128> I've workarounded those issues by adding a desktop launcher to start compiz
[14:18] <kirkland> Riddell: done; famfamfam-silk uploaded
[14:18] <didrocks> seb128: let's see if I can come up with something
[14:18] <seb128> so when it crashes I can double click on it :p
[14:19] <seb128> didrocks, then you need to set a gconf key I guess
[14:19] <didrocks> seb128: no, just check for the old one :)
[14:20] <seb128> didrocks, that would work ;-)
[14:20] <didrocks> seb128: let's see, 5 minutes :)
[14:20] <didrocks> seb128: you still have an old config, right?
[14:20] <seb128> yes
[14:20] <didrocks> (in a word, would you put your config in danger for the sake of it? :))
[14:20] <seb128> I didn't upgrade today yet
[14:20] <seb128> sure ;-)
[14:21] <jdstrand> whee, apport crashed too
[14:21] <didrocks> seb128: excellent, thanks \o/
[14:21] <seb128> jdstrand, welcome to natty :p
[14:21] <jdstrand> hehe
[14:21] <pitti> jdstrand: I fixed apport a few hours ago
[14:21] <jdstrand> of course, I've been here awhile ;)
[14:21] <seb128> jdstrand, the apport issue might be fixed already, pitti did a python2.7 upload
[14:21]  * jdstrand nods
[14:21] <pitti> but indeed, it's fun to see how all your applets and indicators crash differently every morning :)
[14:27] <kenvandine> doko, looks like there are a number of issues with libdesktop-agnostic, which might all be fixed in the upstream project, including some pretty big packaging changes
[14:27] <kenvandine> doko, i am going to ping the upstream guys to see if they are ready for a release
[14:27] <kenvandine> or if i should just grab a snapshot
[14:28] <doko> kenvandine: is an upstream release expected in the natty time frame?
[14:28] <kenvandine> i am going to find out
[14:28] <kenvandine> i don't know any of them
[14:29] <jdstrand> didrocks, seb128: thanks! I seem to have a desktop again now :)
[14:30] <seb128> jdstrand, great ;-)
[14:32] <didrocks> seb128: jdstrand nice :)
[14:39] <Riddell> siretart: what's the status of bug 581805 ?
[14:40] <kirkland> Riddell: thanks
[14:46] <dholbach> smoser, for example if we wait for upstream input before uploading we could say "Please subscribe sponsors once you had feedback", and/or subscribe ourselves to the bug
[14:47] <smoser> dholbach, yeah, but then it sits in that state.
[14:47] <smoser> right ?
[14:47] <smoser> an example (with your comments) is at https://code.launchpad.net/~dmitrij.ledkov/ubuntu/natty/htmldoc/fix-ftbfs/+merge/43393
[14:48] <dholbach> smoser, I think it's fair to say "I looked at it, it's good AFAICS, tested it, but I defer judgement to upstream"
[14:49] <dholbach> if we can't find anyone of us to make that judgement, we shouldn't all be looking at the patch all over again
[14:49] <dholbach> ^ are there other opinions on it?
[14:50] <smoser> on that one in particular, we should fix the ftbs right away and open a bug to track the upstream, right ?
[14:50] <dholbach> I just had a look at the changelog - it doesn't seem like any of the ubuntu developers touched it before
[14:50] <dholbach> I think dmitrij opened an upstream bug already
[14:50] <dholbach> hang on
[14:51] <dholbach> http://www.htmldoc.org/str.php?L235
[14:53] <dholbach> smoser, personally I think it's alright as a temporary measure to just fix the ftbfs and compile without optimisation for now as long as the upstream bug gets tended to
[14:55] <mdeslaur> pitti: could I get your opinion on bug 614717, please?
[14:56] <siretart> Riddell: what about it? 6 months I've asked how to proceed.
[14:56] <siretart> +ago
[14:57] <cjwatson> mdz: is sabdfl unable to attend as well as unable to chair?
[14:57] <cjwatson> mdz,Keybuk,pitti,kees: TB meeting in three minutes
[14:57] <cjwatson> (by my calendar anyway)
[14:57] <pitti> mdeslaur: commented in the bug
[14:58] <pitti> mdeslaur: well, it was me who introduced the change in the first place..
[14:58] <pitti> cjwatson: thanks; I'm in
[14:58] <mdeslaur> thanks pitti
[14:59] <pitti> mdeslaur: followed up agin
[15:00] <mdz> cjwatson: correct
[15:01] <mdeslaur> pitti: ah! it's only for the admin user?
[15:01] <pitti> mdeslaur: yes
[15:02] <mdeslaur> pitti: ah, perfect. WONTFIX
[15:02] <pitti> mdeslaur: and we don't install p-desktop-privs on servers either
[15:02] <mdeslaur> thanks pitti
[15:03] <siretart> Riddell: oh, that's not what I've written, I see. sorry for the confusion
[15:03] <pitti> mdeslaur: updated again
[15:03] <mdeslaur> thanks pitti :)
[15:12] <dholbach> smoser, was there another bug that should probably get off the list?
[15:12] <smoser> i dont really know how something makes the list
[15:13] <smoser> but, for instance, https://launchpad.net/bugs/613662
[15:13] <dholbach> smoser, ah, ok - it get the list of bugs that 'ubuntu-sponsors' is subscribed too and the ubuntu merge proposals that have their status set as "needs review"
[15:13] <smoser> we either need to decide to carry that patch , or say "no".  given RHEL and Suse carrying it, i'd be apt to carry.
[15:14] <siretart> Riddell: I was clearly confused. anyway, uploaded.
[15:14] <smoser> but I don't feel informed enough to make a decision.
[15:14] <dholbach> that's something I personally can't make a judgement on, but somebody like doko can probably help (#613662)
[15:15] <dholbach> smoser, I'd even feel less informed than you :-)
[15:15] <doko> smoser: do you volunteer to maintain the networking stack in eglibc?
[15:15] <doko> robbiew: ^^^
[15:16] <smoser> doko, i can do that in my sleep :)
[15:16] <smoser> or wait,
[15:16] <smoser> maybe that is why i said i don't feel informed enough to make a decision
[15:16] <dholbach> doko, AFAICS smoser was asking for advice, not saying "I'll go and upload it now" :)
[15:17] <doko> smoser: I'm fine to apply such a patch if you want to maintain it
[15:17] <robbiew> so we don't really have a "networking stack" person in either Foundations or Server....with that said, networking is a core, foundational component
[15:17] <smoser> doko, yeah, i would think you're capable of making a decision, but in order to get it off the list, we have to make said decision.
[15:18] <robbiew> doko: maybe it's something barry could maintain :P
[15:18] <robbiew> he used to work in Launchpad...they run on the network, right...heh
[15:19] <barry>  robbiew: ? :)
[15:20] <smoser> i'm not trying to make trouble. i promise.
[15:20] <doko> but you do ;P
[15:22] <robbiew> fwiw, I have an opening in foundations and I'm looking for networking skill...so we could just take it into foundations and  dump it on the poor sap....uh, I mean lucky person who gets the job :)
[15:23] <barry> robbiew: we should see if any of the twisted guys need a job :)
[15:23] <doko> smoser: ^^^ so best thing to delay that one
[15:24] <robbiew> smoser: or apply it and temporarily "maintain" it until I fill my opening
[15:25] <doko> smoser: apply in bzr, please don't upload
[15:26] <smoser> launchpad wouldn't let me anyway
[15:27] <cjwatson> robbiew: difficult to maintain just the networking part of eglibc (at the package level) without the rest of it too
[15:28] <robbiew> cjwatson: ah...good point...and doko is clearly dancing around it ;)
[15:29] <doko> robbiew, cjwatson: you know what I mean ...
[15:29] <robbiew> I do
[15:29] <robbiew> I do
[15:35] <Simira_> dholbach: is it a sign we don't feed the puppy enough when he starts chewing on Odin?
[15:36] <dholbach> Simira_, I guess not :-)
[15:37] <Simira_> hm, why do I have that _
[15:44] <jdstrand> kees: hey, so looking at your ifupdown change, I like how it is minimal, but it is not an obvious change to me. can you explain the 'instance' thing?
[15:47] <hmca> hello , i'm having some problems upgrading my system to python 2.7 under ubuntu, it's a server.... http://pastebin.com/KVbjW8Bt
[15:47] <kees> jdstrand: sure! basically, by defining an instance, a job is run multiple times for each of it's possible "or" conditions (among other things), with $JOB being set to the name of that condition.
[15:48] <kees> jdstrand: in the case of network-interface.conf, it also adds its $INTERFACE to fully describe each of those instances.
[15:48] <kees> jdstrand: it's a work-around, since we shouldn't have to run multiple times, but it works in that it blocks every case until it finishes. (and I added a stamp file so that later runs are as fast as possible)
[15:53] <jdstrand> kees: thanks, between that and 'man 5 init', I understand now
[15:53] <kees> okay, cool.
[15:54] <jdstrand> kees: it isn't totally clear why network-interface-security.conf needs to be declared an instance too, but I guess that may be part of the nature of the bug
[15:55] <kees> jdstrand: making it an instance-able job means the job is included in the dependency resolution for all of its conditions.
[15:56] <kees> jdstrand: it results in a number of side-effects. ultimately, the "always run before the thing it waits for" is the critical bit.
[15:56] <jdstrand> kees: ok. that seems to be an undocumented side-effect
[15:56] <kees> sudo initctl list
[15:56] <kees> network-interface-security (network-interface/br0) start/running
[15:56] <kees> network-interface-security (network-manager) start/running
[15:56] <kees> network-interface-security (network-interface/vnet0) start/running
[15:56] <kees> network-interface-security (network-interface/eth0) start/running
[15:56] <kees> etc
[15:56] <kees> instead of just the 1
[15:56] <jdstrand> (the dependency resolution bit)
[15:57] <kees> yeah, which is why I tried to describe it in the n-i-s.conf job itself.
[15:57] <jdstrand> yes, the comment is clear. the 'why' it works that way is not
[15:57] <jdstrand> kees: ok cool, thanks
[15:59] <bdrung> smoser: the debian changelog for bug #681012 is not verbose enough. please state the remaining changes
[15:59] <bdrung> smoser: and call it merge, not sync
[16:00] <smoser> bdrung, ok. i didn't think i should recopy those, but i will.
[16:00] <smoser> thanks for input.
[16:01] <hmca> hello doko,  i'm having a problem doing an upgrade of python o my server , "ScottK> hmca: Ask doko on #ubuntu-devel about that."  , can u help me ?http://pastebin.com/KVbjW8Bt
[16:01] <doko> pitti, mvo: any update? ^^^
[16:03] <pitti> I'm afraid I don't know how else to tell apt to upgrade the packages in the right order
[16:12] <mvo> doko: sorry, not yet, I got hold up
[16:13] <doko> pitti: so I'll revert the Beaks in python2.7-minimal? please could you accept the sru?
[16:13] <pitti> doko: well, *shrug*, it won't help these upgraders, and there are still tons of unresolved questions there
[16:13] <bdrung> smoser: let me know once you have done that
[16:13] <pitti> I just read the diff again, and it seemed plausible to me until you seemed to imply that the code I pointed out wasn't the fix
[16:14] <smoser> what did you mean "call it merge" (in the bug subject)?
[16:15] <doko> pitti: why do you object to that upload?
[16:15] <pitti> doko: so if you don't want to backport the particular fix, and there's no real solution available, I'll accept it, but as it's still unclear what the fix is, and you don't want to explain either, I can't take responsibility for this
[16:16] <doko> pitti: the fix for this issue is the version range change, the other changes
[16:17] <doko> - test the return status of the py_compile processes
[16:17] <doko> - properly byte-compile even if .pyc files are present
[16:17] <pitti> doko: "did I say that?" sounded like "no" to me; so that _is_ the code fix theN?
[16:17] <doko> - properly byte-compile .pyo files
[16:19] <pitti> right (but that wasn't my question); what actually specifies the vrange option? is that the call of pycompile in package postinst?
[16:19] <bdrung> smoser: yes, the title
[16:22] <smoser> bdrung, branch change is pushed
[16:23] <ari-tczew> could any archive admin accept NEW binaries of clementine?
[16:23] <smoser> and title updated
[16:40] <bdrung> smoser: uploaded
[17:02] <ari-tczew> does any Canonical guy know where can I find dyfet (David Sugar)?
[17:03] <dholbach> ari-tczew, https://launchpad.net/~dyfet lists a few mail addresses
[17:43] <kees> is there a versioning convention to indicate "please just sync this in the future" once an ubuntuN has happened? i.e. if I have foo-1.2-3, it got a 1.2-3ubuntu1, and now the need for that changes has gone away, will something like 1.2-3ubuntu2build1 trigger a sync when 1.2-4 comes around?
[17:44] <ScottK> kees: Nope.  You'll need to request the sync when the time comes.
[17:45] <kees> ScottK: okay, fair enough. I guess I'll upload an ubuntu2 with the change reverted so it's clear it's okay to sync.
[17:46] <ScottK> kees: When I've done this in the past I've explicitly said that in debian/changelog.
[17:46] <kees> ScottK: perfect :)
[18:00] <smoser> anyone able to sponsor a hardy backport ? https://bugs.launchpad.net/ubuntu/+source/mailman/+bug/244233 is *very* straightforward and I believe the bug is in good state for sponsoring.
[18:07] <ScottK> smoser: backport or update?
[18:07] <smoser> update.. but, don't bother just yet, i have something else to look at on it.
[18:16] <hallyn_> mvo: so to add a changelog entry in the packaging tree, is there a bzr command to do it?
[18:19] <jdstrand> pitti: I just went through all the apparmor SRU bugs and verified the fixes. Some of the bugs listed in pending-sru.html either didn't affect lucid or we didn't fix it in this update
[18:19] <jdstrand> pitti: for those bugs, I marked as 'verification-done' and closed the task appropriately
[18:19] <jdstrand> pitti: and added a comment and verified it didn't regress
[18:20] <jdstrand> pitti: I did that because to avoid confusion since pending-sru.html listed too many bugs
[18:21] <jdstrand> pitti: would it be helpful if I changed the tag to 'verification-done' on the remainder of those bugs or shall I leave that for you?
[18:21] <seb128> jdstrand, he left for today I think
[18:21] <seb128> he will probably read the backlog though
[18:21] <jdstrand> ah, so he did
[18:21] <jdstrand> I guess I'll stop talking to myself then :)
[18:21] <jdstrand> seb128: thanks
[18:22] <seb128> those bugs where in the .changes uploaded?
[18:22] <seb128> how come they are listed if they don't concern the version uploaded?
[18:22] <jdstrand> seb128: was a full version update and I used -v
[18:22] <jdstrand> seb128: it was a significant upload
[18:23] <seb128> ok
[18:23] <jdstrand> seb128: basically, we SRUd what is in maverick-updates into lucid-proposed, backing out certain patches (commented in the changelog)
[18:23] <jdstrand> there were also a few maverick only ones that never hit lucid
[18:23] <seb128> jdstrand, ok, I was rather curious, I think pitti knows the detail so no need to spend time going through that again ;-)
[18:23] <seb128> I was just curious if there was a bug in the sru script that builds the page
[18:23] <jdstrand> oh yes, he most certainly does :)
[18:24] <jdstrand> no
[18:24] <jdstrand> well, yes, but not worth fixing
[18:24] <seb128> k, thanks ;-)
[18:25] <bencc1> where can I ask questions about apt package dev?
[18:34] <ebroder> ScottK: By the way, have you had a chance to look at my backportpackage script? I want to make sure it handles all of the cases you care about
[18:34] <ScottK> ebroder: I have not.  I still have it on my TODO.
[18:34] <ebroder> Cool
[19:38] <hallyn_> kirkland: could you take a look at people.c.c:~serge/public_html/vmbuilder-460.tgz and consider sponsoring it, pretty please?
[19:57] <mvo> hey hallyn_ - sorry for the delay, I was at dinner
[19:58] <mvo> hallyn_: I use emacs and debian-changelogs-mode, when using dch I think you can use "CHANGELOG=changelog dch"
[20:00] <hallyn_> mvo: hm, i'll try that nxt time, thanks.  (i just did it by hand)
[20:04] <mvo> hallyn_: ok
[20:06] <hallyn_> mvo: and so from there, you create the source package (bzr-buildpackage -S) and then dput that right?
[20:06] <mvo> hallyn_: yeah, bzr-buildpackage -S (might need --merge, but that should not be needed as there is a .bzr-builddeb/defaults.conf)
[20:07] <mvo> hallyn_: and it will provide the .changes file in ../build-area/
[20:07] <mvo> hallyn_: if you are unsure I'm happy to have a look before oyu upload
[20:07] <mvo> hallyn_: I always do a debdiff before uploading, just in case (old habit)
[20:09] <hallyn_> mvo: thanks.  i just did a dpkg-source -x and looked at the result.  looks good
[20:09] <mvo> hallyn_: excellent !
[20:20] <bdrung> BlackZ: bug #690330 is a duplicate of bug #689025
[20:22] <BlackZ> bdrung: well, when I checked for bug containing the "merge" title, I didn't find anything..
[20:22] <BlackZ> bdrung: I assume the bug title has been changed or it was invalid or its status was "Fix released", "Invalid" or "Expired" ?
[20:23] <bdrung> BlackZ: look at the mailing list - it was a user request for "syncing" the debian version
[20:23] <bdrung> BlackZ: i fixed the title to be a proper merge request
[20:23] <BlackZ> bdrung: ah, I seen now. I was planning to merge it (today I talked to jdstrand)
[20:25] <BlackZ> bdrung: I will reply in the mailing list, then
[20:26] <SpamapS> @pilot in
[20:33] <bdrung> BlackZ: can you please check the six patches for sudo if they should be applied, forwarded, or dropped?
[20:34] <BlackZ> bdrung: *six patches* ?
[20:34] <BlackZ> bdrung: seems like to me there are just 2 patches currently applied in the Ubuntu package
[20:35] <bdrung> BlackZ: yes, look at https://bugs.launchpad.net/ubuntu/+source/sudo
[20:35] <bdrung> BlackZ: six patches attached to bug reports
[20:35] <BlackZ> bdrung: ah, I see what you mean
[20:35] <BlackZ> bdrung: sure, will give a look at them
[21:01] <smoser> @pilot out
[21:11] <pasteeater> siretart: http://pastebin.com/x6LgnDBE
[21:12] <pitti> jdstrand: please feel free to use v-done yourself; I thin I caught them all now
[21:13] <pasteeater> siretart: related to LP #690296.
[21:13] <pasteeater> i think...
[21:18] <jdstrand> pitti: ack, thanks!
[21:44] <kirkland> hallyn_: hey
[21:44] <kirkland> hallyn_: okay, vmbuilder ...
[21:45] <hallyn_> kirkland: yeah?
[21:45] <kirkland> hallyn_: i'm surprised you pointed me to a tarball, rather than a branch?
[21:45] <kirkland> hallyn_: any particular reason?
[21:45] <hallyn_> yes.  there is no 'branch'
[21:45] <kirkland> hallyn_: interesting ....
[21:45] <hallyn_> there is ap ackaging branch, and a source branch
[21:46] <kirkland> hallyn_: ah, and they're separate?
[21:46] <hallyn_> yup
[21:46] <kirkland> hallyn_: interesting
[21:46] <hallyn_> yup :)
[21:46] <soren> It's an upstream project.
[21:46] <hallyn_> not sure where in the sphere of UDD that fits in, but i'm sure it's somewhere
[21:46] <kirkland> (that's not how i handle any of my projects, but meh)
[21:46] <hallyn_> kirkland: we can change it if we want,
[21:46] <hallyn_> kirkland: but i don't want ot make a rash decision until i've tried it
[21:46] <kirkland> hallyn_: right, sure
[21:46] <kirkland> hallyn_: i'm not particular, just curious
[21:46] <hallyn_> frankly, this may actually be nicer for having one source tree for lots of releases
[21:47] <hallyn_> but, it's awkward in having to send over tarballs :(
[21:48] <ebroder> hallyn_: I thought you could bzr merge-upstream a branch
[21:49] <kirkland> hallyn_: uploaded ;-)
[21:49] <hallyn_> kirkland: thanks!
[21:49] <hallyn_> ebroder: out of the packaing branch?
[21:49] <hallyn_> packaging
[21:49] <hallyn_> mind you, i don't have archive upload rights, so *i* couldn't
[21:50] <kirkland> hallyn_: you can do the merge, but just push to a branch you own, in lp:~hallyn
[21:50] <kirkland> hallyn_: and then point me at that, and i'd branch yours and sponsor/upload/push
[21:51] <hallyn_> kirkland: ebroder: i'll try that for the next one, thanks.
[21:52] <kirkland> hallyn_: sure
[21:53] <kirkland> hallyn_: this one was easy enough
[21:53] <kirkland> hallyn_: perhaps for one that involves a lot more changes, it's nice to peruse bzr log, etc.
[21:55] <bdrung> ebroder: around?
[21:55] <ebroder> bdrung: Yeah
[21:56] <bdrung> ebroder: i like to improve u-d-t by adding test to it. there should be local test that will be run on building the package and internet requiring test that can be run from time to time manually (and before release)
[21:57] <ebroder> bdrung: Makes sense. I was considering adding an option to backportpackage take a .dsc file as an argument instead of a source package name. I think that would let you write tests for it
[21:58] <ebroder> *to take a .dsc file, obviously
[21:59] <bdrung> ebroder: you made the wrong assumption. i would like to see tests for backportpackage ;)
[21:59] <ebroder> bdrung: Like unit tests?
[21:59] <bdrung> ebroder: yes (i didn't used unit tests before)
[22:02] <ebroder> bdrung: I could probably write unit tests for some of it, but I don't think you can really do tests for, like, the launchpadlib stuff usefully
[22:02] <ebroder> Even if I had an object that mocked the lp API, it would just be feeding back the information that the functions were programmed to expect.
[22:03] <bdrung> ebroder: for the launchpadlib stuff we could write test that work on edge
[22:03] <ebroder> bdrung: Sure, or staging, but that doesn't get us offline tests
[22:04] <bdrung> ebroder: yes, but having online test is a gain - i would run the online test before uploading the package
[22:05] <ebroder> bdrung: Sure. Do you have infrastructure for doing unit testing already?
[22:05] <bdrung> ebroder: no and i don't know what kind of infrastructure is required
[22:06] <bdrung> ebroder: the offline tests should be run on package build time and the online test should be run with calling one command
[22:07] <ebroder> bdrung: Sure, I'm willing to setup infrastructure, but I'd prefer if it didn't block review of my branch
[22:07] <ebroder> Feel free to open a bug and assign it to me, though I likely wouldn't have time to work on it until this weekend
[22:07] <bdrung> ebroder: you can do it in a separate branch
[22:08] <ebroder> bdrung: Sure, and I would
[22:41] <bdrung> ebroder: your backportpackage branch is ready for merging?
[22:43] <ebroder> bdrung: I'd like ScottK to make sure the interface does everything he needs, but other than that, I'm happy with it
[22:43] <bdrung> ebroder: ok, i will look at it and merge it if there is nothing blocking
[22:47] <ScottK> I should be able to look at it tonight or in the morning.
[22:47] <ebroder> ScottK: Awesome, thanks
[23:02] <SpamapS> ugh.. the us archive servers are goingg... slllwooooowww today....
[23:05] <barry> SpamapS: are you sure?  they seem quick to me
[23:08] <SpamapS> barry: its something with Los Angeles I think
[23:08] <SpamapS> happens about once a month
[23:08] <SpamapS> I get like, 256kbit for a day or two
[23:09] <SpamapS> I'm sure its AT&T's fault
[23:09] <SpamapS> they're huge here.. and I'm on U-verse.. so sitting right on their backbone
[23:09] <barry> SpamapS: no doubt :)  i do see occasional problems with my isp (rcn cable) but i usually track it down to their dns being f'd
[23:10] <SpamapS> I've been using google's dns for a while now
[23:11] <barry> yeah, i really should switch, but in general they're pretty good.  sometimes it's easier just to live through the pain for day
[23:11] <SpamapS> They're about 0.5s faster than any name server AT&T has ;)
[23:11] <SpamapS> I love the idea of just pre-caching everything
[23:12] <SpamapS> flipping ttl on its ear and trying to actually keep everything in RAM