[00:00] <ockham_> tumbleweed: the previous autotools based approach catered for that, too
[00:00] <EvilResistance> is there any way to pass to backportpackage when it tries to extract the source package of <somepackage> to ignore the gpg key checks during extraction?
[00:00] <ockham_> tumbleweed: oops, another copy&paste incident
[00:00] <EvilResistance> because i'm doing backportpackage -s precise -d oneiric -w <dir> php5, and it won't extract the source
[00:02] <cjwatson> Ah, apparently the publisher's about to come back on
[00:02] <tumbleweed> EvilResistance: it should be ignoring the gpg signature
[00:02] <EvilResistance> ah yeah, there it is
[00:02]  * EvilResistance misread the error
[00:02] <EvilResistance> cjwatson:  eta?
[00:02] <EvilResistance> (assumign they told you)
[00:02] <ockham_> tumbleweed: ok, fixed the import * part. is there any way I can take care of /etc in setup.py?
[00:03] <cjwatson> EvilResistance: the publisher runs at *:03
[00:03] <tumbleweed> ockham_: I wouldn't try to. setup.py is normally for installing a python module, its data, and possibly, at a push some manpages.
[00:03] <cjwatson> EvilResistance: it currently takes around half an hour
[00:04] <ockham_> tumbleweed: docs are ok, too?
[00:04] <cjwatson> although I expect it will have a bit more to do this time round
[00:04] <EvilResistance> cjwatson:  i'd assume so there were TONS of builds afaict :P
[00:04] <tumbleweed> ockham_: if it's trying to put them in /usr/share/doc/$packagename, that's probably too debian-specific for setup.py
[00:04] <cjwatson> Not radically more so than usual, I'd expect :-)
[00:05] <EvilResistance> cjwatson:  the backlog of it, though... :P
[00:05] <cjwatson> Oh, BTW, this is the distro publisher, I don't know about the PPA publisher
[00:05] <EvilResistance> yeah the PPA publisher is my focus
[00:05] <tumbleweed> EvilResistance: have you seen the armhf backlockg?
[00:05] <ockham_> tumbleweed: uhm, what then?
[00:05] <cjwatson> May well be coming back soon as well but it's on a different schedule.
[00:05] <cjwatson> They were both disabled at the same time.
[00:06] <cjwatson> I think the PPA publisher runs every five minutes rather than every hour.
[00:06] <tumbleweed> ockham_: what then? bed time for me.
[00:06] <EvilResistance> now on an entirely unrelated question, a company i work with wants to set up an apt repository for ubuntu, but doesnt want it to be an apt mirror.  i said i'd research getting it done, but not actually do it.  any of you know how i'd attack that problem?
[00:06] <EvilResistance> or should I just go post on the ubuntuforums or whatnot
[00:06] <ockham_> tumbleweed: ok.
[00:06] <cjwatson> They should specify what they mean: a repository of add-ons to Ubuntu, or a private mirror of Ubuntu itself that isn't exposed to the world
[00:07] <EvilResistance> well the way i understood their request is they dont want a mirror of Ubuntu at all
[00:07] <EvilResistance> they want a repo that acts similar to what a PPA does: hold *additional* packages
[00:07] <EvilResistance> stuff not already in the ubuntu main repos.
[00:09] <cjwatson> OK.  There's a variety of packages for managing that kind of thing.  Names that come to mind are reprepro and mini-dinstall.
[00:09] <cjwatson> reprepro seems the most popular at the moment, from what I've gathered.
[00:10] <EvilResistance> for the sake of the actual server admins at this company, got any links to documentation/instructions for setting up and configuring?
[00:10] <cjwatson> (Or it's possible to roll your own around apt-ftparchive, or try to set up something industrial-scale like dak or Launchpad - but I wouldn't advise either of those two)
[00:10] <cjwatson> I do not, sorry.
[00:10] <EvilResistance> not a problem
[00:11] <EvilResistance> i assume google will turn up something :P
[00:11] <cjwatson> reprepro seems to come with documentation in the package.
[00:13] <EvilResistance> after a quick google i'm glad i'm just researching it, not the one actually *doing* the setup and config xD
[00:13] <EvilResistance> although it would be JUST MY LUCK if I get told to set it up >.>
[00:15] <cjwatson> Oh, I just found mini-buildd-rep as well, which is another option.
[00:15] <cjwatson> They may also need to attach build servers to it.  sbuild/buildd is probably a sane choice, but there's mini-buildd-bld too.  (I have no idea of the latter's quality.)
[00:16] <EvilResistance> isnt sbuild/buildd what lp builders use?
[00:16] <EvilResistance> or something...
[00:16] <cjwatson> LP builders use sbuild
[00:16] <cjwatson> (Albeit currently a rather old fork)
[00:16] <cjwatson> buildd is more or less what Debian builders run; Launchpad has its own build farm
[00:18] <cjwatson> sbuild builds a single source package; since you're familiar with pbuilder already, pbuilder is more or less analogous to sbuild
[00:20] <EvilResistance> pbuilder and sbuild are only slightly different, no?  the end result is a built package.
[00:27] <cjwatson> EvilResistance: Right.
[00:28] <cjwatson> pbuilder is slower for doing lots of builds, though, as it wants to unpack a tarball every time.  sbuild is more flexible.
[00:29] <EvilResistance> could a private apt repository with addons be configured to use pbuilder over sbuild if they arent producing tons of packages/addons?
[00:30] <EvilResistance> (see, if i explore every angle, then the company won't feel the need to say "Go Do More Research!" :P)
[00:31] <cjwatson> I wouldn't see why you'd want to bother; but it's no doubt possible.  Whether any of them actually have a config knob for that I wouldn't know.
[00:32] <cjwatson> I just upload to Debian or Ubuntu where somebody else manages this for me ;-)
[00:32] <EvilResistance> :P
[00:32] <EvilResistance> yeah, but you're a MOTU, you have that right xD
[00:32] <EvilResistance> standard users dont get that
[00:32] <EvilResistance> and corporations/companies that want private repositories dont either :P
[00:32] <cjwatson> sure, I wasn't being serious
[00:32] <cjwatson> I'm told that publishers and builds are all back up
[00:32] <EvilResistance> :P
[00:33] <EvilResistance> *all* publishers?
[00:33] <cjwatson> so I'm told
[00:33] <EvilResistance> yeah wgrant just changed the topic in #launchpad
[00:33] <EvilResistance> :P
[00:33] <micahg> cjwatson: in that case, I'll go poke about why the buildds aren't picking up builds :)
[00:33] <cjwatson> There's still some build database trouble.
[00:34] <micahg> ah, just saw comments in another channel
[00:34] <cjwatson> Let wgrant work on it :-)
[00:34] <wgrant> I think they'll resolve themselves in 15-20 minutes.
[00:34] <wgrant> micahg: They're all security builds, I guess?
[00:34] <wgrant> In a private PPA?
[00:34] <micahg> wgrant: oh, that could be
[00:34] <micahg> wgrant: I have no idea, didn't look, just saw the backlog on +builders
[00:34] <wgrant> Ah.
[00:35] <wgrant> Private builds don't start until they're published, and there's a massive publisher backlog.
[00:35] <EvilResistance> heh
[00:35] <EvilResistance> so if i were to upload to a PPA a package, then its likely it wouldnt get published until sometime next year?
[00:35] <EvilResistance> (figuratively speaking)
[00:36] <wgrant> Hopefully it'll all clear up in about 20 minutes.
[00:36]  * EvilResistance points at the word "hopefully"
[00:36] <EvilResistance> ;P
[00:36] <wgrant> The build queues might take another 6-7 hours.
[00:39] <micahg> ah, I'm not in a rush for anything, was just curious
[00:43] <EvilResistance> wgrant:  heh, i'm not in a rush either :P
[00:47] <jtokarchuk> alpha or actual release? ;o on precise
[07:54] <dholbach> good morning
[10:46] <Laney> morning
[10:48] <l3on> hey guys.. can we take a look at bug 896695 ?
[10:49] <l3on> it's solved, but set as duplicated of a discussion that doesn't see the end in the immediate future
[10:51] <l3on> this is the url of bug → https://bugs.launchpad.net/ubuntu/+source/clang/+bug/896695
[11:10] <handschuh> Hi, will there be a REVU-day in this month, or is there some rough schedule about when the next REVU day will be?
[11:19] <geser> handschuh: probably never, REVU is on the way to get deprecated
[11:21] <handschuh> geser: ok so whats the new way of getting packages into ubuntu? (or is it not decided yet?)
[11:28] <geser> handschuh: the currently preferred way is to go through Debian and sync it to Ubuntu
[11:29]  * ogra_ never saw revu as a tool to get packages into ubuntu ... its simply a easy tool to review packages, nothing more
[11:29] <handschuh> geser: thank you for the information
[11:29] <geser> it's still possible to get a package directly into Ubuntu if you find someone willing to do the review (e.g. from a team which is interested to get this package into Ubuntu)
[11:31] <handschuh> so, https://wiki.ubuntu.com/MOTU/Contributing#Preparing_New_Packages should be changed then
[11:33] <Laney> wendar: are you working on adding the deprecation notice to revu?
[11:33] <Laney> p.s. hi!
[12:53] <mhall119> can someone help me?  I'm getting the following error on a python package using dh_python:
[12:53] <mhall119>  /usr/bin/fakeroot debian/rules clean
[12:53] <mhall119> dh clean --with python2
[12:53] <mhall119> dh: unable to load addon python2: Can't locate Debian/Debhelper/Sequence/python2.pm in @INC
[12:53] <mhall119> targetting lucid
[12:57] <akheron> mhall119: I may be wrong but I think it requires debhelper 8
[12:58] <cjwatson> it doesn't; but dh_python2 isn't in lucid yet
[12:58] <Zhenech_> no, it needs python 2.6.something from debian or whenever you introduced it
[12:59] <cjwatson> for now I'm afraid you have to fall back to python-{central,support} for lucid
[12:59] <cjwatson> even though those are now deprecated
[13:00] <mhall119> oh, ok
[13:02] <mhall119> when I tried python-central and cdbs, it was putting my code in /usr/lib/python2.7/site-packages
[13:03] <mhall119> instead of /usr/share/pyshared/
[13:03] <mhall119> and while dist-packages is on my path, site-packages is not
[13:03] <Zhenech_> it should do links on install though
[13:10] <pqatsi> Ive always used apt-pinning for "version blendings" and now this appear to do not work very well or concise. Ive tryed to ask in #ubuntu about this but the awnser i got is "precise isnt suported", but im blending versions for backporting development. Anyways, where i can find a information about how apt-pinning works for ubuntu?
[13:11] <pqatsi> since even pinning using apt.conf/preferences.conf dont appear in apt policies and install packages using apt-get install xpto/precise marks for update from precise, but mantain higher priority for oineric
[13:11] <pqatsi> (If a paste helps with my question: http://pastebin.com/ks0jz4L2)
[13:12] <cjwatson> mhall119: python setup.py install --install-layout=deb
[13:12] <cjwatson> although dh_auto_install should do that for you
[13:12] <cjwatson> (dunno about cdbs, I avoid it)
[14:56] <wendar> Laney: it's on my list for this week, yeah. But no worries if someone beats me to it. :)
[15:58] <ockham_> is there any way to use the bash exclusion operator in debian/rules?
[15:59] <ockham_> as in
[15:59] <ockham_> cp source/!(not_this_file) target
[16:01] <ockham_> i'm using the above in a loop, and get
[16:02] <ockham_> /bin/sh: 3: Syntax error: "(" unexpected (expecting "done")
[16:02] <ockham_> same stuff works when directly entered into a terminal
[16:04] <Zhenech_> no
[16:04] <Zhenech_> dont asume bash functionality
[16:07] <ockham_> aww, to bad
[16:07] <Zhenech_> sh != bash
[16:08] <Zhenech_> and you want your package to build on machines w/o bash
[16:08] <ockham_> is there any textbook example of excluding files in shell commands in debian/rules then?
[16:14] <broder> tumbleweed: i'm finding your reverse-depends script/service to be incredibly useful, by the way
[16:14] <tumbleweed> broder: glad to hear that :)
[16:33] <Kiall> Has anyone had difficulty with cowbuilder-dist installing the wrong apt lines into the image? It always installs the host's distros lines
[16:34] <tumbleweed> Kiall: hrm, that's the exact opposite of pbuilder-dist, which was always using archive.ubuntu.com
[16:34] <Kiall> Well, it uses archive.ubuntu.com .. but always "oneiric" and never lucid or precise :)
[16:34] <tumbleweed> that sounds problematic :P
[16:35] <Kiall> Yea .. I've been scratching my head (on and off!) for a day or two  ;)
[16:35]  * tumbleweed has never used cowbuilder, but I'd appreciate a bug report (and even better, a patch)
[16:36] <Kiall> cowbuilder is basically pbuilder, but with cow rather than tgz images
[16:36] <tumbleweed> right, but people are reporting bugs on it that we don't see with pbuilder
[16:36] <Kiall> (cowbuilder basically just wraps pbuilder)
[16:36] <tumbleweed> and cowbuilder-dist wraps cowbuilder :P
[16:37] <Kiall> Yea ;)
[16:37] <tumbleweed> in fact, investigation on any of these bugs would be welcome https://bugs.launchpad.net/ubuntu/+source/ubuntu-dev-tools?field.searchtext=cowbuilder-dist
[16:42] <Kiall> tumbleweed: well, I've spotted why it always uses http://archive.ubuntu.com/ubuntu/ … Its hardcoded ;)
[16:43] <tumbleweed> Kiall: we fixed that recently
[16:43] <Kiall> ah, I guess that hasnt landed in oneiric yet so...
[16:43] <tumbleweed> no, it won't
[16:43] <tumbleweed> grab a daily build / the bzr branch if you want to fix bugs in it
[16:44] <Kiall> Normally I'm up for that, but right now I need to get the CI server building packages right ;)
[16:45]  * tumbleweed suggests sbuild for production use
[16:45] <Kiall> may I ask why? (Other than personal preferences :P)
[16:46] <tumbleweed> partly that, it's also what the buildds use
[16:46] <Kiall> The LP builders?
[16:46] <tumbleweed> it does a great job of building packages, out of the box
[16:47] <tumbleweed> the LP builders run an ancient fork of sbuild, but that's hopefully going to be resolved soon
[16:48] <Kiall> I'll have a look, any suggested docs/wiki pages etc? Looking at the debian wiki page for it now...
[16:49] <tumbleweed> mk-sbuild makes it easy to set up
[16:50] <Kiall> Thanks, Will have a look
[16:50] <tumbleweed> here's something a little more manual: https://wiki.ubuntu.com/SecurityTeam/BuildEnvironment
[16:51] <tumbleweed> like cowbuilder, it doesn't use a tarball for each chroot
[16:51] <tumbleweed> but it uses schroot, which is really handy for other things
[17:18] <Kiall> tumbleweed: I think I'm onto something with the cowbuilder-dist issue
[17:19] <Kiall> the command ran by (p|cow)builder-dist is something along these lines:
[17:19] <Kiall> "... ARCH=amd64 DIST=precise cowbuilder ... --distribution precise .."
[17:19] <Kiall> --distribution makes it work with pbuilder
[17:20] <Kiall> but cowbuilder wants "DISTRIBUTION=.." rather than "DIST="
[17:20] <tumbleweed> right, DISTRIBUTION is the variable pbuilder is actually going to use
[17:21] <tumbleweed> DIST is what many people use to drive their .pbuilderrcs (but that's normally people not using pbuilder-dist)
[17:21] <tumbleweed> e.g. https://wiki.ubuntu.com/PbuilderHowto
[17:21] <Kiall> yea - but pbuilder/cowbuilder-dist use DIST, rather than DISTRIBUTION
[17:21] <Kiall> and hence it gets ignored by cowbuilder
[17:21] <tumbleweed> Kiall: what I'm saying is that that's partially intentional
[17:22] <Kiall> but it works with pbuilder since pbuilder also understands the --distribution precise
[17:22] <Kiall> Sure, I get that..
[17:22] <tumbleweed> right, I'm sure there's no harm in setting DISTRIBUTION, but we may need to set DIST too, for people with existing pbuilderrcs
[17:23] <Kiall> But - Currently, cowbuilder-dist does not provide the dist to cowbuilder using any method it understands, hence it is defaulting the the host's dist
[17:23] <tumbleweed> yup, that I can understand
[17:27] <Kiall> Humm - maybe I'm wrong, adding that aint helping
[18:38] <psusi> so MOM says auto merge of a package failed... the instructions say you fix the merges, build the source package, then upload it ( with dput? )... how does bzr fit into this picture?  Are the MOM instructions just outdated and you should now do this with bzr?
[18:39] <tumbleweed> most of the time, it's a lot easier to do a merge with MOM output than bzr
[18:40] <tumbleweed> applied quilt patches make merging with bzr branches less fun than it should be
[18:41] <psusi> indeed
[18:41] <psusi> so if I do it the mom way, how won't that leave the lp bzr branch out of date?
[18:42] <tumbleweed> the bzr branch will be updated by the importer, just like it would be for any other upload
[18:53] <psusi> hrm... I thought the importer updated the debian branch, but the ubuntu one you just push to and the archive auto imports from that?
[18:54] <cjwatson> it does both
[18:54] <cjwatson> if there's a commit on the Ubuntu branch with a tag matching the upload it wants to import then it leaves it alone
[18:55] <cjwatson> if there's a commit after the last tag on the Ubuntu branch then it imports the new upload but moves the commit aside to a new branch and files a merge proposal for it
[18:55] <cjwatson> otherwise it imports the new upload
[18:56] <psusi> cool.. so if I use grab-merge and fix it up... I can't dput it, so... what do I do then?
[18:58] <cjwatson> attach a debdiff to a bug; current Debian -> your merge is probably the best one although some people also attach current Ubuntu -> your merge
[19:00] <broder> i like to look at current ubuntu -> merge | filterdiff -i '*/debian/*', but i consider that sufficiently advanced technique that i don't expect it from sponsorees
[19:00] <cjwatson> You can construct either one from the other anyway, so :)
[19:01] <cjwatson> (well, from the other plus archives)
[19:20] <pcpratts> hey everyone.  my config script is being executed twice during an apt-get install
[19:20] <pcpratts> any ideas why?
[19:21] <EvilResistance> what the heck is with the php source package in precise being dependent on a precise-only version of mysql-client :/
[19:21] <tumbleweed> pcpratts: http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html
[19:21] <pcpratts> tumbleweed: again, you saved the day!  thanks!
[19:22] <pcpratts> thanksssssssssssssss!
[19:22] <tumbleweed> there's a graphical version somewhere...
[19:22] <tumbleweed> there http://wiki.debian.org/MaintainerScripts
[19:23] <pcpratts> ooo.  even easier!
[19:25] <psusi> hrm... actually, just doing the bzr merge works like a charm
[19:25] <tumbleweed> psusi: please use bzr merge-package not merge
[19:26] <tumbleweed> otherwise it can miss out metadata that'll confuse the importer (and other users) later
[19:26] <psusi> what's that do?
[19:26] <psusi> otherwise it works the same way?
[19:26] <tumbleweed> yes
[19:26] <psusi> hrm... ok
[19:27] <psusi> thank god for packages that don't already have the quilt patches applied in bzr ;)
[19:32] <pcpratts> I love open source
[19:49] <pcpratts> my config script to prompt the user with debconf is called twice: once when the screen says: Preconfiguring packages and again when the screen says Setting up package
[19:50] <cjwatson> yes, that's intended
[19:50] <cjwatson> your config script must be idempotent - that is, if called twice it must behave as if it were called once, and it must not re-ask questions (which generally means you shouldn't force questions to the unseen state)
[19:50] <pcpratts> cjwatson: I am prompting the user twice.  my config says:
[19:50] <pcpratts> case "$1" in
[19:50] <pcpratts>     configure)
[19:50] <pcpratts> oh okay
[19:51] <pcpratts> yeah, I see now
[19:51] <pcpratts> where should I reset the dbconf variables?
[19:51] <pcpratts> anywhere?
[19:51] <pcpratts> debconf*
[19:51] <cjwatson> the reason it is this way is to allow preconfiguration without actually requiring it
[19:51] <cjwatson> as a general rule, you shouldn't
[19:52] <pcpratts> okay
[19:52] <pcpratts> thanks
[19:52] <cjwatson> why do you want to?  there are sometimes exceptions, but you must be careful
[19:54] <pcpratts> eh, when I was debugging I wanted to make sure I could type it in everytime I did dpkg -i
[19:54] <pcpratts> but it probably doesn't matter now
[19:54] <cjwatson> use debconf-communicate
[19:54] <cjwatson> echo RESET your/question/name | sudo debconf-communicate your-package-name
[19:55] <cjwatson> (NOT in your maintainer script, but from a terminal while debugging)
[19:55] <cjwatson> so yeah, it sounds like you should just omit the reset in your config script and then you'll be good
[19:55] <pcpratts> :) thanks.  yep, just read not in your maintainer script
[19:55] <pcpratts> yeah I think so
[20:18] <psusi> how often is harvest supposed to update?
[20:29] <broder> much more frequently than it is
[20:29] <broder> (which appears to currently be never)
[20:29] <broder> i keep meaning to bug dholbach to get him to bug canonical IS about it
[20:31] <psusi> yea, I just found an entry that should have been removed back in july...
[20:46] <psusi> how do you get bzr bd to pass options like -us -uc to builddeb?
[20:46] <broder> -- -us -uc
[20:46] <jtaylor> bzr bd -- -us -uc
[20:46] <psusi> ahh
[20:52] <psusi> wait a second... why does bzr bd leave me with a .tar.bz2 instead of a .diff.bz2?
[20:55] <psusi> the ubuntu/debian changes relative to the orig tarball should be in a diff shouldn't they?
[20:55] <jtaylor> debian.tar.bz2?
[20:55] <psusi> yea
[20:55] <jtaylor> thats how the diff is called with 3.0 pacakges
[20:55] <psusi> ugh
[20:55] <psusi> damn... seems to break debdiff
[20:56] <jtaylor> in what way?
[20:56] <psusi> it claims there are no differences
[20:57] <psusi> ohh, wait, works when I give it the .dsc files instead of the .changes ;)
[21:07] <philipballew> Who would I talk to about an outdated package?
[21:08] <jtaylor> depends on the package
[21:09] <philipballew> jtaylor, kismet. Its like 4 years old in the repos and the dev's are hoping this can be fixed
[21:12] <jtaylor> hm looks like it needs a new maintainer in debian
[21:12] <philipballew> exactly. Is there anything that we can do here?
[21:13] <philipballew> also the kismet dev makes a deb for you to add to the repos but its not debian rules friendly
[21:15] <philipballew> http://www.kismetwireless.net/download.shtml
[21:19] <jtaylor> interested in taking of the package maintenance yourself?
[21:19] <philipballew> I can, I am really crappy at packaging however. but I am trying to learn all that. I downloaded and am going to be reading the ubuntu packaging guide soon
[21:20] <philipballew> over christmas break I can learn packaging
[21:22] <philipballew> well I already know how to package. I just need to make myself more comfortable with advanced packages
[21:23] <jtaylor> thats good, best you get involved in debian and try to find a sponsor there, ubuntu will automatically get the new package
[21:23] <tumbleweed> philipballew: I queried the maintainers status in the MIA database. The MIA team is aware that he's inactive
[21:23] <tumbleweed> I think it's fairly NMUable
[21:24] <philipballew> jtaylor, whats the best way to do that?
[21:25] <philipballew> tumbleweed, Thank you. i think I will try to see if I can get this in by lts
[21:25] <jtaylor> #debian-mentors and mentors mailing list are good places for information if you have any technical issues just ask there or in #ubuntu-packaging
[21:26] <jtaylor> if you can get the package in a team it usually makes sponsoring easier
[21:26] <pcpratts> I took out db_fset variable seen false in most places from my config.  now installation works on the first time.  after a remove and install again, things fail with exit status 30.  the way I can revert back to it working again is to do: dpkg --purge --force-remove-reinstreq <package_name>
[21:27] <EvilResistance> how do i figure out what source package provides certain binaries?
[21:27] <EvilResistance> a search on LP?
[21:27] <philipballew> jtaylor, thats in irc.debian.net right?
[21:27] <tumbleweed> jtaylor: right, but hijacking a package into a team is probably going a little far for an NMU :P (and I can't think of any relevant teams)
[21:27] <jtaylor> EvilResistance: apt-cache show package | grep Source
[21:27] <pcpratts> EvilResistance: packages.ubuntu.com ?
[21:27] <lifeless> EvilResistance: apt-cache show <binary> will report the source package name
[21:28] <EvilResistance> lifeless:  thanks
[21:28] <jtaylor> tumbleweed: no upload in 3 years known mia isn't that enough for an hijack?
[21:28] <pcpratts> regarding my previous question: I solved it.  thanks.
[21:29] <pcpratts> I think I had an infinite loop if the password confirmation was not right
[21:30] <tumbleweed> jtaylor: the hijack process is to announce that you are planning on hijacking before you hijack: http://wiki.debian.org/qa.debian.org/removals (if someone wants to file such a bug, that'd be awesome)
[21:45] <EvilResistance> should i be worried about these broken pipe errors being thrown whilst using backportpackage ?  http://pastebin.com/feqRTmS6
[23:08] <psusi> someone said earlier I should use bzr merge-package instead of merge, but it doesn't seem to be smart enough to deapply quilt patches before the merge, and won't take --force to do the merge after I manually deapply them... how can I work around this?
[23:12] <tumbleweed> psusi: I know there are scripts out there to make it less painful, but don't know where offhand
[23:12] <tumbleweed> bug 845860 says barry was going ot write something...
[23:17] <psusi> hrm.. so there's no way to avoid the bogus deapply/reapply commits in the history?
[23:18] <tumbleweed> yah, that seems like a horrible solution
[23:18] <tumbleweed> I recall a better one
[23:25]  * psusi wonders why --lca isn't the default