[00:52] <infinity> @pilot in
[01:11] <infinity> Does anybody else have update-notifier whining about ubuntu-emulator-runtime?
[06:12] <infinity> @pilot out
[07:03] <xnox> good morning! =)
[07:04] <hyperair> it's 3pm here. ;-)
[07:05] <hyperair> morning anyway. :)
[07:50] <xnox> hyperair: there i was thinking, i'm up early ;-)
[07:51] <hyperair> ;-)
[07:51] <Snow-Man> 3am here, so...
[07:51] <hyperair> wow, up even earlier!
[07:51] <Snow-Man> :)
[07:52] <Unit193> Nah, 3am is late, not early. ;)
[07:53] <Snow-Man> 3am might be 'passed out early due to excessive drinking, back up now and hacking on Postgres'... :D
[07:53] <Snow-Man> and wondering if we're really going to get all this snow that's forecasted
[07:53] <Unit193> We're not, most of it is going to bypass. :(
[07:54] <Snow-Man> The claim is 4-6" here, but it's all rain right now.
[07:54]  * Snow-Man is up near DC
[07:58] <Unit193> Already got some, driving would be fun.
[08:00] <Snow-Man> hmm, looks like it's just started to snow now
[08:21] <mapreri> Can someone sync how-can-i-help?
[08:27] <Noskcaj> mapreri, File a sync bug?
[08:32] <mapreri> Noskcaj: ok
[10:58] <cjwatson> mapreri: done
[10:59] <mapreri> cjwatson: thanks, I was going to file the sync bug.
[11:19] <mlankhorst> why was egl and gbm disabled on ppc64el and arm64? works just fine
[11:33] <Laney> I mailed u-d-a if someone could moderate it
[11:44] <cjwatson> Laney: done
[11:44] <Laney> ta
[12:35] <xnox> ogra_: you have my diffs, sort your bugs yourself.
[12:35] <xnox> ogra_: it should be a good starting point, i'll work on something where my work is not revert for no good reason.
[12:35] <ogra_> xnox, thats the rule, i dont make the rules
[12:36] <ogra_> xnox, and i dont have a working diff for enable-modem
[12:36] <xnox> ogra_: well, that revert introduces a regression.
[12:36] <ogra_> how so ?
[12:37] <ogra_> xnox, the breakage was introduced with this change to the image: http://people.canonical.com/~ogra/touch-image-stats/20140301.1.changes
[12:37] <ogra_> there was nothing else changed but ofono
[12:38] <ogra_> if that introduces a regression then i dont get how
[12:38] <xnox> ogra_: because ofono-scripts are reverted to python2.
[12:38] <ogra_> xnox, yes
[12:39] <xnox> ogra_: and the bugs and crashes are not related to python3 switch.
[12:39] <ogra_> but they dont produce crashes anymore
[12:39] <xnox> ogra_: use that old package now, with python3 scripts.
[12:39] <xnox> ogra_: so, i should go and dput back the switch to python3 for the scripts?
[12:39] <ogra_> since the landing team isnt upstream, how are they supposed to know ...
[12:39] <xnox> ogra_: do you understand what I'm getting at?
[12:39] <ogra_> they can only roll back the whole landing
[12:40] <xnox> ogra_: no, but you've asked me to work on it, to presumably avoid the pointless revert.
[12:40] <ogra_> if you can verify that it doesnt cause the issues, sure
[12:40] <xnox> ogra_: (that's how i understodd it)
[12:40] <ogra_> right
[12:40] <xnox> ogra_: isntead revert has happened anyway.
[12:40] <ogra_> i didnt know that didrocks did such a quick shot here
[12:40] <xnox> ogra_: and i've spent my time, now, pointlessly.
[12:40] <xnox> ogra_: and it's now further blocking mine and barry's work on python3.
[12:40] <ogra_> since we didnt plan to build an image that soon
[12:41] <ogra_> xnox, revert the revert (or ask didrocks to do it) and apply your fixes ...
[12:41] <xnox> ogra_: can you please take that old package, replace /usr/share/ofono/scripts with python3 versions.
[12:41] <xnox> ogra_: and check if you get the crashes?
[12:41] <xnox> (you'll need python3-gi if it's not installed)
[12:41] <ogra_> so keeping ofono-scripts installed and only reverting the ofono package ?
[12:41] <ogra_> lets see if dpkg allows
[12:42] <xnox> no, dpkg will not =)
[12:42] <xnox> so stash / copy override / unpack python3 ofono-scripts on top.
[12:44] <ogra_>  ofono-scripts depends on ofono (>= 1.12+bzr6856-0ubuntu1); however:
[12:44] <ogra_>   Version of ofono on system is 1.12+bzr6853-0ubuntu1.
[12:44] <ogra_> hmm
[12:45]  * ogra_ forces
[12:45] <ogra_> and rebooting ...
[12:46] <ogra_> root@ubuntu-phablet:/# ls /var/crash/
[12:46] <ogra_> _usr_share_ofono_scripts_enable-modem.0.crash
[12:46] <ogra_> xnox, ^^^
[12:46] <ogra_> with old ofono and new (py3) ofono-scripts
[12:46] <xnox> $ cat /var/crash/_usr_share_ofono_scripts_enable-modem.0.crash
[12:47] <ogra_>  dbus.exceptions.DBusException: org.ofono.Error.Failed: Operation failed
[12:47] <xnox> ogra_: at least paste the traceback from the bottom of it....
[12:47] <ogra_> same issue as always
[12:47] <xnox> ogra_: great! =) your revert will do you no good ;-)!
[12:47] <ogra_> xnox, didrocks reverted to the plast ofono source package
[12:47] <xnox> ogra_: what did you force and what do you have installed?
[12:48] <ogra_> which will pull the py2 scripts back in
[12:48] <xnox> ogra_: cause ofono/ofono-scripts have a hard-dep version numbers....
[12:48] <ogra_> i had the old ofono (pre py2) and the new -scripts (with py3) installed together
[12:48] <ogra_> there is a versioned dep between them
[12:48] <ogra_> right
[12:49] <xnox> i need to look at diffs of what didrocks uploaded.
[12:49] <ogra_> he just rolled back to the old deb source package
[12:49] <ogra_> with a bumped changelog
[12:52] <xnox> ogra_: can you give me ssh to flo's adb?
[12:52] <ogra_> xnox, not without ripping my firewall apart completely ... probably psivaa can
[12:53] <ogra_> psivaa, ^^
[12:53] <ogra_> xnox, but that should all be reproducable on any device ... even on grouper
[12:54] <xnox> ogra_: right, i'll see about reproducing this on grouper.
[12:55] <ogra_> flo is just a better grouper :P
[12:55] <ogra_> (well, completely different HW ... but still :) )
[12:57] <psivaa> xnox: do you still need access to the device in the lab? I need to check that with ev and retoaded before giving access though
[12:58] <ev> psivaa: we can give access to a device so long as it's temporary and you take it out of play for the CI engine
[12:59] <xnox> psivaa: i'll let you know if i need access.
[12:59] <psivaa> xnox: ev: ack, thanks
[13:01] <xnox> didrocks: are you going to update https://wiki.ubuntu.com/UbuntuDevelopment/RevertLog with ofono revert upload?
[13:06] <Laney> xnox: I'm uploading that splitty split split now
[13:06] <xnox> Laney: \o/ =) !
[13:07] <Laney> Packages++
[13:07] <xnox> Laney: btw, that last split, i've read as "spliff" and i was like hang on a minute!
[13:07] <Laney> got to celebrate somehow ...
[13:07] <Laney> actually, by going to the cafe down the road and doing the crossword :P
[13:08] <Laney> #thuglyf
[13:08] <xnox> =)))))
[13:47] <didrocks> xnox: sure, when I get the time to do it
[13:47] <didrocks> ogra_: we talked in the morning meeting about it… that I would revert
[13:47] <xnox> didrocks: is it ok with you, if i upload revert of your revert, which also fixes the observed crashes?
[13:48] <xnox> didrocks: did you talk to people who prepared that upload of ofono?
[13:48] <ogra_> didrocks, right, i just didnt expect you to be that fast
[13:48] <didrocks> xnox: watch the phone ML
[13:48] <ogra_> since there was no urge to do it quickly
[13:48] <didrocks> xnox: this was discussed here
[13:48] <didrocks> xnox: ok to upload revert of the revert if you did tests the autopilot tests with the onofo-phonesim
[13:49] <xnox> didrocks: ok. thanks.
[13:49] <xnox> didrocks: on mailing list, i see ricardo acknowledging the issue and hoping to work on fixing it today. Which was mailed 4h ago.
[13:50] <didrocks> xnox: right, but we need to get back to a better image sooner
[13:50] <didrocks> xnox: as we're going to kick one now
[13:50] <didrocks> and getting the testing results by the evening meeting
[13:50] <xnox> didrocks: define "better" =) an image which pulls back in python2 and python2-gobject is, in my opinion, not better but one that regresses =)
[13:51] <didrocks> xnox: better == less crashers
[13:51] <didrocks> so yeah, python2 vs crashers
[13:51] <didrocks> I take python2, sorry
[13:51] <xnox> didrocks: turn off whoopsie, if you count crashes =)))) *giggles*
[13:51] <xnox> didrocks: plus the crash was not of any process that is shipped on the image.
[13:51] <didrocks> xnox: sure, sending the patch and announcing that to ubuntu-devel?
[13:52] <xnox> didrocks: the crash was in external package, which is installed for testing only.
[13:52] <didrocks> xnox: yep
[13:52] <xnox> didrocks: you still count that towards good/bad image? strange.
[13:52] <didrocks> xnox: I do, developers are running the AP tests
[13:52] <didrocks> seeing the crash
[13:52] <ogra_> xnox, didrocks only thinks in AP tests :)
[13:52] <xnox> didrocks: ok.
[13:52] <didrocks> and discare their own failure because "it's due to the crash"
[13:53] <didrocks> ogra_: I do care of an image we can promote, not only AP tests, but dogfooding as well
[13:53] <xnox> didrocks: well, tell them not to do that =) attribute random things to random crap.
[13:53] <ogra_> didrocks, right
[14:59] <shadeslayer> jibel: https://jenkins.qa.ubuntu.com/job/upgrade-kubuntu-precise-trusty-desktop-backports-amd64/7/console < is that just a temporary failiure in the LXC backend?
[15:01] <jibel> shadeslayer, yes it is. post-upgrade tests started before the container is running. It is fixed.
[15:02] <shadeslayer> ah ok
[15:02] <shadeslayer> jibel: are the results posted on some mailing list I can follow? instead of checking that page everyday?
[15:47] <roadmr> hello! I have a problem with apt-get. Package A lives in a private PPA, and depends on package B which lives on another private PPA. apt-get install A says "Depends: B but it is not going to be installed". However, apt-get install B succeeds; further, apt-get install AB *also* succeds. What could be happening?
[15:47] <roadmr> er, apt-get install A B
[15:48] <seb128> mardy, hey, is there any reason to not just land u-s-s and -online-accounts synced in a CI train silo  and be done with that v2 plugin thing?
[15:51] <jibel> shadeslayer, there is an ubuntu-testing-notifications ML, but it is sometimes pretty high volumes, otherwise I can subscribe you to kubuntu upgrade tests only.
[15:52] <shadeslayer> jibel: yeah would be nice
[15:52] <shadeslayer> maybe Riddell / apachelogger too ^^
[15:57] <mardy> seb128: AFAIK, you can't have the same project in different silos
[15:57] <mardy> seb128: ATM, online-accounts is on silo 5, and there are more changes I plan to land soon
[15:57] <mardy> seb128: I wouldn't like to be blocked because of this
[15:58] <seb128> mardy, indeed not, I see you already have landing prepared in silo5, but once that's cleared we could do one synced with u-s-s for the reset?
[15:59] <Laney> I did the change now already
[15:59] <seb128> k
[15:59] <seb128> let's stop arguing about that then and just land the damn thing :p
[15:59] <seb128> (well after the ringtone)
[15:59] <Laney> where's the lander list again?
[16:00] <Laney> boiko is away today, want to check who does telephony
[16:00] <seb128> Laney, https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0Au6idq7TkpUUdC05a2ZQSmgwU2NFYnJQOE9qMDRYa3c&usp=drive_web#gid=1
[16:00] <seb128> bfiller
[16:00] <Laney> ty
[16:01] <Laney> bfiller: We'd like to get https://code.launchpad.net/~laney/telephony-service/accountsservice/+merge/201630 in, any objections to training it?
[16:06] <bfiller> Laney: no objections, as long as it's tested and works
[16:06] <Laney> bfiller: Ya, and it'll get re-tested in the silo
[16:06] <Laney> thanks
[16:09] <cjwatson> jdstrand,sbeattie: Do you know why python3-apparmor-click depends on python3-click?  It doesn't seem to actually use anything from it.
[16:10] <cjwatson> (Which makes it a non-issue for the work I'm doing at the moment, but I wanted to check as some of the API in python3-click is going away)
[16:10] <cjwatson> (Or rather being moved elsewhere)
[16:12] <jdstrand> cjwatson: interesting-- no we don't seem to do any imports from python3-click
[16:13] <jdstrand> cjwatson: probably a holdover from earlier code iterations
[16:13] <jdstrand> I've added a todo to test and drop that in the next upload
[16:22] <cjwatson> jdstrand: Thanks
[16:38] <dobey> anyone else using evolution having it consistently crash on startup today too?
[16:45] <seb128> dobey, no, bt?
[16:48] <dobey> seb128: https://bugs.launchpad.net/ubuntu/+source/evolution/+bug/1287250
[16:48] <seb128> dobey, can you subscribe me to it?
[16:49] <dobey> seb128: done
[16:50] <seb128> dobey, weird, that's a segfault in gsettings, that didn't change recently (neither glib nor dconf)
[16:51] <dobey> yeah, weird, but now i can't read my e-mail. evo is crashing on every startup :(
[16:55] <seb128> dobey, weird, maybe ping desrt on #ubuntu-desktop about it. Is the segfault always in gsettings?
[16:57] <ara> seb128, remember the gnome-settings-daemon upload that fixed https://bugs.launchpad.net/oem-priority/+bug/408903
[16:57] <ara> seb128, and it may have caused this regression: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/1248368
[16:57] <seb128> ara, yes, I saw your email as well, the recent weeks just have been crazy with ff
[16:58] <ara> the regression only affects 1 person,and we are not able to reproduce
[16:58] <dobey> hmm, weird
[16:58] <dobey> i started in calendar and it worked ok
[16:58] <ara> yes, I can imagine, but I was talking to bdmurray and he wanted your opinion :)
[16:58] <dobey> but was crashing all the time in the default view of mail (i don't really use calendar or other things much)
[16:58] <dobey> and now it starts ok again :(
[16:59] <ara> if you are unsure, that's fine, but we will need to prepare another gnome-settings-daemon upload without those changes to fix the other issue in the queue
[16:59] <ara> I am fine either way
[17:03] <seb128> ara, hum, who tested the SRU?
[17:05] <ara> seb128, the original or the potential regression?
[17:05] <seb128> ara, sorry, I got slightly confused by comment #7 on the regression bug
[17:05] <seb128> which was stating that the versions are the same before/after dist-upgrade
[17:07] <seb128> ara, I've a test machine next to me, let me put 12.04.
[17:07] <seb128> 4 on an usb stick and test that
[17:08] <ara> seb128, thanks
[17:08] <seb128> ara, yw
[17:50] <alow> infinity: hi it's me the node.js/v8 guy on powerpc again. I've just done another cleanup sweep of the code - what's the best way to push these changes into http://packages.ubuntu.com/source/trusty/libv8-3.14?
[18:09] <psusi> in order to get a package synced from debian at this point, doesn't it need subscribed to ubuntu-archive?  bug #1286027 was subscrubed to the release team but they switched it to sponsors since it's only a bug fix so no FFE is needed...
[18:09] <psusi> shouldn't that be archive not sponsors?
[18:11] <cjwatson> No, no reason archive has to be subscribed to sync bugs.
[18:11] <cjwatson> Syncs became self-service for uploaders a couple of years ago.
[18:11] <psusi> ohh, I thought sync requests normally were subscribed to archive
[18:11] <cjwatson> They were ... years ago
[18:11] <cjwatson> https://lists.ubuntu.com/archives/ubuntu-devel-announce/2012-January/000923.html
[18:12] <psusi> hrm... so I guess I finally need to get my app in for full devel and then I could do it myself?
[18:12] <cjwatson> Indeed
[18:12] <psusi> neat
[18:12] <cjwatson> Or indeed a per-package permission for that package.
[18:12] <psusi> that reminds me... what's a guy got to do to get upload access to parted in debian? ;)
[18:13] <psusi> I'm feeling pretty comfortable at this point so it's probably time to just apply for full devel
[18:13] <cjwatson> There's the DM process
[18:14] <psusi> yea, I'm a dm... what I meant was that the maintainer of the package is listed as a team rather than an individual... and it's maintained in git... so not only do I need someone to dak me up, but I need git access too
[18:14] <cjwatson> ok, maybe ask me later this week, trying to finish off https://code.launchpad.net/~cjwatson/click/libclick/+merge/209105 right now
[18:15] <psusi> ok... I'm hoping to get a new upstream parted released next week and get it into debian as soon as those partman pateches I submitted are applied
[18:16] <cjwatson> I wouldn't mind converting Debian parted to git-dpm to go with just about everything else I have a hand in maintaining these days, too
[18:17] <psusi> ohh, I thought it already was
[18:17] <cjwatson> It'd probably make sense to do that before the new upstream
[18:17] <cjwatson> Nah, I think it just has patches sitting unapplied in git
[18:18] <cjwatson> (before> because that way you can use git to resolve the patch queue rather than having to do it in quilt)
[18:19] <psusi> hrm... reading up more on this now
[18:20] <cjwatson> http://lists.alioth.debian.org/pipermail/pkg-grub-devel/2014-January/013883.html is a summary
[18:20] <cjwatson> Also https://lists.debian.org/debian-ssh/2014/02/msg00007.html
[18:21] <psusi> this might be handy for util-linux too when lamont finally gets around to uploading it and making me the maintainer ( poke poke ;)
[18:22] <cjwatson> I absolutely love it, if it isn't clear :)
[18:23] <psusi> hehe, I gather that... now just trying to understand how it works ;)
[18:23] <cjwatson> It does have a bit of the git thing where its documentation consists of commit graphs, so it took me a while
[18:24] <psusi> I had been trying to come up with a sane way of managing patches in git after seeing the util-linux git repo, but gave up
[18:24] <psusi> and just went back to plain old 3.0 quilt source packages
[18:26] <cjwatson> Yeah, nothing previously had sold me on it as being worth bothering
[18:28] <cjwatson> The key is the non-pushed pseudo-fast-forwarding branch, where you have a rebasing branch consisting of upstream + all your patches in sequence, and you merge it onto your master or equivalent any time you change it, so you get to rebase *and* keep the history
[18:28] <cjwatson> And then various bits of gold-plating so that you don't have to have that branch explicitly around all the time and getting in the way
[18:28] <psusi> I was thinking it would take something like a branch for upstream, and another for the debian stuff, or a submodule or something
[18:30] <cjwatson> git-dpm indeed has a branch which consists only of upstream + patches and doesn't have the rest of the packaging, in order that you can cherry-pick between upstream and the patched branch
[18:30] <cjwatson> But you only check that out when you're working on it (via "git-dpm checkout-patches"), otherwise it's round-tripped to files in debian/patches/
[18:32] <psusi> how do you keep the debian/changelog and debian/patches/ in sync with that then?
[18:32] <psusi> if they aren't part of the same commit?
[18:32] <cjwatson> They're part of the merge
[18:33] <cjwatson> So git-dpm update-patches merges the rebasing tip, and updates debian/patches/ at the same time
[18:33] <psusi> one branch for upstream changes, one branch with a paralell set of commits that update the changelog, and a 3 way merge?
[18:33] <cjwatson> If you want to update debian/changelog too then you can use git-dpm dch which wraps it up for you, or you can edit it afterwards and use git commit --amend
[18:34] <cjwatson> I'm not sure "parallel" is the right way to look at it
[18:34] <cjwatson> You could check out say git://anonscm.debian.org/pkg-ssh/openssh.git and look at it with gitk
[18:34] <psusi> ohh, I see, the debian/patches isn't in git, it is auto generated by the wrapper tool from the git commits?
[18:35] <cjwatson> The wrapper checks it into git so that when you do a checkout you get something that looks just like the generated source package
[18:35] <cjwatson> But you indeed don't modify those files manually
[18:35] <cjwatson> They're the output of git format-patch basically, with support for tweaking the file names
[18:36] <psusi> I see... so the change log entry is a verbatim copy of the git commit message, and the DEP-3 headers are... auto generated too?
[18:36] <cjwatson> You put them in your commit message
[18:36] <cjwatson> So if you're cherry-picking you generally need to amend the commit message, but that's no great problem
[18:36] <psusi> hrm.... nifty
[18:36] <lamont> cjwatson: did you see anything about how grub hates my disk and grub-prober exits(1) because of "unknown filesystem"?
[18:36] <cjwatson> nope ...
[18:36] <lamont> if not, I'll dig into it
[18:37] <cjwatson> (also being increasingly insistent called for dinner)
[18:37] <cjwatson> *insistently
[18:37] <psusi> by jove, it sounds like this really *is* the best of both worlds
[18:37] <lamont> psusi: is this git-dpm the package, or what package? (before I read lots of scrollback)
[18:37] <psusi> lamont: yes.. cjwatson was telling me about git-dpm
[18:38] <lamont> ta
[18:38]  * lamont adds that to his "after util-linux" tasklist
[18:42]  * psusi is getting excited about git-dpm but is worried he's going to be a wonk and do all the manipulation by hand isntead of using git-dpm
[18:43] <slangasek> the obvious way to guard against this would be to commit yourself to providing workflow documentation for git-dpm on wiki.debian.org as you go <hint ;)>
[18:45] <psusi> lol
[18:47] <tarpman> good morning. can anyone suggest the best way to move forward with bug 937200? should I propose a merge for trusty, forward the patch to debian bts, ping doko personally, ??
[18:49] <tarpman> ... "wait a bit longer" is also valid, I'm sure people are busy :)
[18:50] <psusi> the more I stare at this commit graph the more I love it
[18:52] <psusi> hrm... does it only work with upstream tarballs though, or can you directly *merge* from upstream?
[18:52] <psusi> i.e. upstream git repo, not upstream tarball that has been imported
[19:04] <Noskcaj> seb128, ping
[19:05] <Noskcaj> The u-c-c and u-s-d merges i put up are so there can be a gnome-desktop FFe.
[19:05] <Logan_> hi Noskcaj
[19:06] <Noskcaj> hey Logan_
[19:36] <alow> hey infinity are you around?
[19:37] <seb128> Noskcaj, hey, you could have written that in the description ;-)
[19:37] <Noskcaj> seb128, sorry, i was unsure how well versed you where in the current status of ubuntu-gnome
[19:38] <seb128> Noskcaj, not at all, though I know about gnome-desktop update being something they want
[19:38] <seb128> Noskcaj, -1 from me on that ffe, but I'm not one to device on ffes, so let's see what the release team says
[19:38] <Noskcaj> ok
[19:39] <seb128> device->decide (doh, autofingers)
[19:40] <Noskcaj> seb128, one other thing, would it be worth merging all of miniupnpc 1.6-3 this later in the cycle? bug 1264664
[19:43] <seb128> Noskcaj, no opinion on that, out of that it should get a ffe (e.g subscribe ubuntu-release, etc)
[20:49] <cjwatson> psusi: you can directly merge from upstream, though what you generally do in practice is "git-dpm import-tar" which tacks a commit onto the upstream release point corresponding to any differences between git and the tarball
[20:50] <cjwatson> if upstream is "close enough" then you might get away with it, though I think I'm coming to the view that that's a false optimisation
[21:42] <cjwatson> slangasek: you mean like https://wiki.debian.org/PackagingWithGit/GitDpm ? :-)
[21:42] <cjwatson> Though it definitely needs more
[21:42] <cjwatson> Like dealing with new upstreams
[22:19] <stokachu> barry: https://github.com/cask/cask
[22:21] <barry> stokachu: ah, nice.  anything that helps emacsers out is a winner in my book
[22:21] <stokachu> barry: thought you'd like that :)
[22:56] <slangasek> cjwatson: right, something like that :-)  so it mentions two options for getting started, "import .dsc files" or "start from scratch" - is there any howto for "take existing package VCS and convert it over"?
[22:57]  * lamont looks around for someone with a machine/vm/whatever running trusty with root on an LV on a VG that still has space for another LV to test something for him
[22:57] <lamont> cjwatson: ^^ it seems that grub-probe hates lvm snapshots, fwiw
[22:57] <lamont> still working towards verifying that
[22:58] <cjwatson> lamont: damnit, I'm sure we've fixed that at least once before
[22:58]  * lamont runs off for a few while rsync churns
[22:58] <cjwatson> slangasek: not that the wiki shouldn't be extended, but the man page is actually pretty good
[22:58] <lamont> cjwatson: that would be a grave bug, imo
[22:58] <cjwatson> lamont: probably :-/
[22:58] <lamont> mostly since I couldn;t even install the build-deps for grub2 because of grub-probe.
[22:59] <cjwatson> slangasek: though the short answer is that "git-dpm init /path/to/upstream/tarball" (possibly with --patches-applied) does it
[23:00] <cjwatson> of course for a VCS that isn't git it isn't really git-dpm's problem ... may I recommend http://www.catb.org/~esr/reposurgeon/
[23:03] <slangasek> cjwatson: right, I'm assuming step 1) make sure your package repo is git, step 2) dpmify your existing source package regardless of which format it's currently using
[23:06] <cjwatson> run on master, git-dpm init takes the existing tree, creates a sequence of commits starting from the "upstream" branch corresponding to each successive patch in debian/patches/, then merges the tip of that into your master branch in a commit that also (a) creates the debian/.git-dpm control file (b) changes all the files in debian/patches/ into git-dpm's canonical form, which basically looks like git format-patch output
[23:07] <cjwatson> if you're me, you want to use --record-patch-name so that it doesn't change all the file names, and you end up doing "git-dpm checkout-patched; git rebase -i upstream; ...; git-dpm update-patches --amend" immediately afterwards to clean up all of the commit messages and such
[23:07] <cjwatson> but that's just neatness
[23:08] <slangasek> cool
[23:08] <slangasek> how is git-dpm's support for non-git-format-patch-dep3 headers?
[23:09] <cjwatson> it doesn't have any, you get to accept them turning into git format
[23:09] <cjwatson> I thought for a while and decided I was OK with that as a trade-off
[23:10] <cjwatson> given that the information is still there, just differently formatted
[23:12] <slangasek> cjwatson: I'm ok with it changing the header, I just want it to import the existing one without me having to hand-check it
[23:12] <slangasek> so s/Description/Subject/, e.g.
[23:13] <cjwatson> oh, yeah, it imports well enough modulo whitespace occasionally being glitchy
[23:13] <cjwatson> as in it doesn't outdent space-indented Description continuation blocks
[23:14] <cjwatson> but that's fairly trivial, and I haven't encountered any information loss
[23:58] <doko> cjwatson, ftbfs