[00:10] <persia> SpamapS, `quilt header` might be useful if you're using 3.0 (quilt)
[00:34] <SpamapS> persia: I think I'm just mixing two different dev styles and its messing with my workflow a bit. ;) I see now where if I'm not using bzr branches, its very simple.
[00:34] <SpamapS> Been doing everything with UDD methods but I wasn't sure how to do merges that way.
[00:36] <persia> SpamapS, For UDD, you'd submit a merge request.  Won't change the content of things.
[00:37] <persia> You still need to use `quilt header` or equivalent to set your patch headers, and you still want to review the diff before you request a merge on LP.
[00:38] <persia> Personally, I suspect using `debdiff` is the least annoying way to be able to see the summarised changes between two source packages, but you may be able to convince `bzr diff` to give you that, assuming both branches are in the same (correct) state.
[00:46] <SpamapS> persia: the issue with UDD is that you have to run bzr-buildpackage -S --dont-purge to generate the patches, then copy them back in. Granted, we should use quilt directly, but I'm just suggesting that this, IMO, very cool feature of debsrc 3.0 is sort of broken right now for bzr-buildpackage usage (unless I missed how to make it do this)
[00:46] <persia> You're supposed to use quilt, and then commit that with bzr, or work towards getting 3.0 (bzr) accepted, and work with packages in that source format.
[00:47] <SpamapS> Also I didn't realize that there was any problem with just leaving the generated patch "as is" .. nobody cared the last time I uploaded with the same patch boilerplate in place.
[00:47] <persia> Just changing code using normal bzr workflows is nearly guaranteed to fail.
[00:48] <persia> It ought be done right.  If someone didn't look, that's their mistake.  Folks that intentionally make mistakes usually end up with reprimands, so it's likely not safe to expect the same person to ignore it in the future.
[00:48] <ScottK> SpamapS: I think having the bzr history thanks to UDD is very useful, but I'm not convinced we know how to mix VCS and patch systems in a way that isn't harder than either alone.
[00:48] <SpamapS> persia: this is the first I've known its a mistake, and I'll be correcting it. :)
[00:49] <SpamapS> ScottK: Agreed.. it feels broken as-is. 3.0 (bzr) would be awesome.
[00:49] <persia> ScottK, For Format 1.0 packages, we have a working way to deal with bzr.  For Format 3.0 (quilt), it's sufficiently complex that it's often easier to post a debdiff after using bzr-buildpackage -S --dont-purge or similar, sadly.
[00:50] <persia> SpamapS, 3.0 (bzr) won't help for most packages, as most come from Debian, and the Debian maintainers often don't use bzr.
[00:50] <ScottK> 3.0($VCS) is still pretty well not figured out anyway.
[00:50] <persia> Indeed.
[00:51] <SpamapS> awesome, well its good to know that I am not alone in thinking this feels a bit duct-tape-and-chewing-gum-ish. :)
[00:51]  * SpamapS must be going, and so disappears ... <POOF>
[09:08] <ari-tczew> nxvl: ping
[09:34] <ari-tczew> sponsoring overview not updating anymore again :(
[10:29] <nxvl> ari-tczew: pong
[10:30] <ari-tczew> nxvl: could you take a look whether we can sync terminator from Debian unstable?
[10:30] <nxvl> ari-tczew: yes we can
[10:30] <ari-tczew> nxvl: the one remaining file in Ubuntu delta is /po/.intltool-merge-cache
[10:30] <nxvl> just sync it
[10:31] <nxvl> i only upload to ubuntu when my debian sponsor is taking long and we have a freeze comming
[10:31] <nxvl> and i upload the same to both distros
[10:31] <nxvl> so go ahead
[10:31] <ari-tczew> nxvl: thanks
[14:14] <ari-tczew> debfx: thanks for your working on merges
[14:21] <tumbleweed> ari-tczew: hah, it was AlanBell's merge proposal into lp:asher that broke the sponsoring overview :)
[14:21] <tumbleweed> AlanBell: care to delete that (and yes that bug should be fixed)
[14:22] <vish>  *lp:dasher
[14:23] <tumbleweed> yes. btw easy bug, I'll propose a fix
[14:24]  * vish guilty of asking AlanBell to do that :s … 
[14:24] <vish> i dint notice it was the upstream branch at first, took me a couple of mins to realize it but AlanBell was fast ;)
[15:53] <AlanBell> tumbleweed: sure, the conversation is continuing upstream on that one
[15:53] <AlanBell> what do you want me to delete?
[15:53] <tumbleweed> AlanBell: the merge proposal into lp:dasher
[15:54] <AlanBell> it is gone
[15:54] <tumbleweed> AlanBell: thanks :)
[15:55] <AlanBell> I never quite understood the point of the lp:dasher sync from gnome
[15:55] <AlanBell> if the package comes from Debian
[15:56] <tumbleweed> AlanBell: if someone wanted to do a daily-build PPA for dasher, the sync would be a prerequisite
[15:56] <AlanBell> ah ok
[15:56] <tumbleweed> also, if someone wants to work on (or fork) dasher, in launchpad (i.e. someone who doesn't know git), it would be helpful. (although you obviously have to submit something upstream to get upstream's attention)
[15:57] <AlanBell> at the moment as far as I can tell it isn't used for anything
[15:57] <AlanBell> yeah, just confused me because I didn't know where the real upstream was
[15:58] <tumbleweed> AlanBell: yeah, this one looks dead and should be deleted...
[15:58] <AlanBell> a daily build ppa is an interesting thought
[15:59] <AlanBell> but as dasher in Maverick is reasonably non-crashy I am not sure how important it would be
[16:00] <tumbleweed> AlanBell: filed https://answers.edge.launchpad.net/launchpad-code/+question/129762
[16:06] <AlanBell> cool thanks
[16:39] <vish> tumbleweed¦ i asked that Q in #lp about the abandoned svn, and they said someone might have requested it..
[16:39] <vish> also, it seems mirroring from git to svn to lp o.0
[16:41] <vish> hmm, no! its just constantly trying from svn when its now moved to git..!
[17:37] <bilalakhtar> maco: There? Should I go ahead with merging netkit-tftp or you are doing it?
[17:39] <ari-tczew> bilalakhtar: did you see mail about wu-ftpd? it's free for you
[17:43] <bilalakhtar> ari-tczew: ah yes, doing that right now as you speak :)
[18:23] <bilalakhtar> back, sorry for the abrupt quit
[21:35] <sebner> RainCT: debious? Wth?
[21:50] <iulian> Heh.
[22:04] <RainCT> sebner: :P.
[22:05] <RainCT> sebner: I hadn't blogged for a couple weeks, had to write something :P.
[22:05] <sebner> RainCT: yet another dubios gui for debian packaging :P
[22:08] <RainCT> sebner: Well, I got tired of seeing awful GUIs out there so I made this mockup. Turns out it's pretty much like james_w's design (which I had forgotten).
[22:08] <sebner> RainCT: I guess the problem is not the awful GUI but the idea in general :P
[22:09] <RainCT> sebner: Nah, I think a well-done GUI could end up being useful.
[22:11] <sebner> RainCT: dunno about that, what do you criticise on the available guis?
[22:11] <RainCT> Eg. I'd love to be able to open a maverick package, change the target in debian/changelog to lucid, press "upload to PPA" and have it do everything (including test-building if I'd choose to do so)
[22:11] <RainCT> sebner: All GUIs I've seen so far were bad jokes with stuff like "checkinstall" buttons
[22:14] <sebner> heh
[22:14] <sebner> RainCT: sed, dput, pbuilder :P
[22:37] <RainCT> sebner: Yup, that's typing many lines (cp -R <...> /tmp; cd /tmp/...; sed; debuild ....; pbui...; dput;) vs a button. Not really that much difference but the later "feels" easier.
[22:48] <sebner> RainCT: well, if it's done properly
[23:39] <AlanBell> I am having a first play with packaging recipies to do daily builds, but it is failing to build for me, not sure if I have stuffed up the instructions somewhere
[23:39] <AlanBell> https://code.edge.launchpad.net/~alanbell/+recipe/daily-dash-of-dasher
[23:39] <AlanBell> actually, just failed on Maverick and Natty, but build successfully on Lucid
[23:41] <AlanBell> Maverick build log is here http://launchpadlibrarian.net/57749157/buildlog.txt.gz