[00:00]  * micahg still needs to kill sqlite (2.x) as well
[00:15] <ajmitch> micahg: it worries me when I see people filing bugs complaining that sqlite 2.x support has been removed from a package
[00:15] <ajmitch> since it was deprecated upstream several years ago now
[00:15] <micahg> ajmitch: indeed, I was waiting for this to be done in Debian
[00:16] <micahg> but as the maintainer keeps failing to file the removal bugs, I'm just going to do it for precise and file bugs with the changes
[00:16] <ajmitch> ok
[00:16] <ajmitch> it should only be universe packages, I hope
[00:17] <micahg> yep
[00:17] <micahg> and unseeded
[00:21]  * ajmitch feels sorry for the maintainer of openclipart in debian, binary packages come to over 1G
[00:23] <ajmitch> I wonder if that's worth syncing to precise, it's just large content that's unseeded
[00:24] <micahg> as we've had the same upstream since hardy, that doesn't sound like a bad idea
[00:24]  * ajmitch was just checking what large file debmirror was stuck on :)
[00:26] <ajmitch> I suspect I'll need to try & build it locally first
[00:26] <micahg> :)
[00:26] <ScottK> Not that much time before release.
[00:27] <ScottK> (unless you left NZ and have actual bandwidth)
[00:27] <micahg> hehe
[00:27] <micahg> ajmitch: I can do that if you like
[00:27] <ajmitch> ScottK: that's why I'd sync it & let LP pull in the source
[00:27] <micahg> ajmitch: does it need any paperwork?
[00:28] <ajmitch> micahg: major new upstream of unseeded package? yeah, probably needs an FFe, I haven't checked for one
[00:28] <micahg> ajmitch: only needs FFe if it has new features
[00:28] <micahg> or major build system changes
[00:28] <ajmitch> define 'new features' when it's clip art :)
[00:29] <ajmitch> http://packages.debian.org/changelogs/pool/main/o/openclipart/current/changelog doesn't list much
[00:29] <micahg> bug 537105
[00:30] <ajmitch> micahg: if you're feeling like burning bandwidth, go ahead :)
[00:30]  * micahg has the BW :)
[00:31] <ajmitch> ok then
[00:38] <jtaylor> can one get apt-cacher-ng to cache pull*-source?
[00:40] <ajmitch> you may be able to get pull-debian-source to go through apt-cacher-ng, probably less likely with pull-lp-source
[00:40] <ajmitch> generally you wouldn't be pulling the source down multiple times though?
[00:41] <jtaylor> I do often
[00:42] <ajmitch> why not keep an unmodified copy of the source around?
[00:43] <ajmitch> or do you start up a fresh vm & work in that?
[00:43] <jtaylor> I usally dump stuff in /tmp
[00:43] <jtaylor> unless I anticipate using it in future
[00:43] <jtaylor> I often anticipate wrong :/
[00:43]  * ajmitch has a bad habit of keeping stuff lying around
[00:44] <ajmitch> it wasn't that long ago that I was cleaning up breezy chroots
[00:54] <micahg> ajmitch: openclipart is a long build as well :-/
[00:57] <ajmitch> micahg: boy am I glad you volunteered ;)
[00:58] <micahg> and ~3GB of disk space
[00:59] <micahg> well, I've got this hardware not doing much until after dinner :)
[00:59] <micahg> umm, last build took 10 hrs on roseapple
[01:00] <ajmitch> s/dinner/breakfast/ ?
[01:00] <micahg> and only 1.2 GB
[01:00] <micahg> ajmitch: nah, I have work to do tonight :)
[01:40] <ScottK> FYI, haskell New'ing seems done.
[01:41] <Pikkachu> hi, I'm trying to apply a simple patch to pidgin since hours
[01:41] <Pikkachu> am I supposed to read all of this simple doc? https://wiki.ubuntu.com/PackagingGuide/Complete
[01:42] <jalcine> Where's Laney? >.> *smells more Haskell.
[01:42] <Pikkachu> I just want to make a patched package, possibly source package that I can upload to my PPA
[01:55] <micahg> ajmitch: openclipart failed after an hour, seems we need a basis link patch that the other packages that use libreoffice got
[01:56] <ajmitch> micahg: better to fail after 1 hour than after 9
[01:57] <ajmitch> micahg: want me to look for what patch is needed tonight?
[01:57] <micahg> ajmitch: if you have time, that would be great
[01:57] <micahg> ajmitch: want the buildlog?
[01:58] <ajmitch> ok, I'll give it a shot, build log will be useful
[01:58] <micahg> ajmitch: pastebin ok?
[01:58] <ajmitch> or email if it's large
[01:58] <micahg> ajmitch: almost 10M
[01:59] <ajmitch> ok, just email it then, I'll take a look later :)
[01:59] <jalcine> My clock's silly.
[02:04] <micahg> ajmitch: sent
[02:11] <ajmitch> micahg: thanks
[02:12] <ajmitch> did you ask for an FFe earlier, or do you think it's not needed?
[02:12] <micahg> ajmitch: I was going to wait for the build to finish to see what changed
[02:13] <ajmitch> fair enough
[02:23] <micahg> ajmitch: I found debian 663747
[02:23] <ajmitch> right, I was going to grab the previous version from snapshot.d.o to compare, with that patch I don't need to :)
[02:49] <Pikkachu> is there any problem in building packages form ntfs partitions?
[06:29] <micahg> Laney: one thing all the haskell rebuilds have done is rocket you to #4 uploader for precise
[06:33] <ajmitch> heh, so that's why he did it...
[06:34] <ajmitch> he has done quite a few uploads, judging from that graph
[06:34] <micahg> ajmitch: you're #44 ATM :)
[06:35] <ajmitch> micahg: I expect that to jump a few places, I synced another ~25 since the last updated time at the bottom of the page
[06:36] <ajmitch> http://people.canonical.com/~ubuntu-archive/transitions/ghc.html has a few packages listed that should be installable now, so we're close
[06:36] <micahg> ajmitch: I think about 12 higher
[06:37] <ajmitch> though that's just an indicator of number of syncs done, not actual effort :)
[06:37] <micahg> true :)
[06:42]  * ajmitch wonders how long this openclipart build may take
[06:57]  * ajmitch shall also have to file an FFe for vagrant, to bring it up to 1.0 in precise
[07:53] <dholbach> good morning
[07:54] <ajmitch> morning dholbach
[08:00] <dholbach> hi ajmitch
[08:51] <Laney> yeah, they should only count as one upload really
[08:53] <ajmitch> argh, dreaded "No space left on device"
[08:55] <Rhonda> <nelson point="ajmitch">HA HA!</nelson>
[08:56] <ajmitch> so cruel :(
[08:56] <geser> ajmitch: how much more missing?
[08:56] <micahg> ajmitch: how much space did it take already?
[08:56] <Rhonda> deinstall openoffice.org ;)
[08:57] <ajmitch> micahg: I had 5.7GB free after the build had failed
[08:57]  * Rhonda has to get rid of a fair amount of music from her harddisk everytime she has to compile wesnoth …
[08:57] <ajmitch> Rhonda: I'm building stuff that build-deps on libreoffice :)
[08:57] <micahg> ajmitch: you got further than I did, I think mine was only up to ~4.5GB
[08:57] <Rhonda> hah! knew it!
[08:57] <ajmitch> micahg: I've cleared another couple of GB, trying again
[08:58] <ajmitch> surely ~9GB free is enough, right?
[08:58] <Rhonda> nope
[08:58] <ajmitch> :(
[08:58] <micahg> ajmitch: you've apparently never tried to compile libreoffice or webkit :)
[08:58] <Rhonda> I think 7G was barely enough when I tried to help out with openoffice
[08:58] <ajmitch> Rhonda: building openclipart, I saw that 2.0 was uploaded to debian
[08:58] <Rhonda> and that was AGES ago
[08:58] <micahg> Rhonda: it build-deps on libreoffice, not builds it
[08:58] <ajmitch> micahg: I'm not that crazy
[08:58] <Rhonda> k
[08:59] <micahg> ajmitch: no idea since Debian doesn't have build logs for arch all packages
[08:59] <micahg> last version in precise only took 1GB build space
[08:59] <ajmitch> I also had this thing thrashing an awful lot as it took ~2GB for an image
[08:59] <ajmitch> last version in precise was quite a bit smaller
[08:59]  * micahg builds "smaller (<10GB)" builds in RAM
[09:00]  * ajmitch starts the 2 minutes of hate
[09:00]  * micahg goes to sleep
[09:00] <ajmitch> you're as bad as a friend of mine showing off his new laptop with 16GB of RAM :)
[09:00] <micahg> ajmitch: how do you think I build stuff in RAM :)
[09:01] <ajmitch> yeah I guessed that
[09:01] <ajmitch> he works on unity, so probably needs all of that :)
[09:01]  * micahg wants more RAM for his laptop, but needs to wait for 8GB DIMMs to come down in price
[09:01]  * ajmitch would like a new laptop, but the new SSD will have to do for now
[09:01] <ajmitch> it's made a huge difference anyway
[09:02] <micahg> I think I'll need an SSD when I add more ram as well :)
[09:02] <ajmitch> when this is thrashing because it has only 4GB RAM, I see disk I/O of about 130MB/sec in iotop
[09:02] <micahg> anyways, really need to sleep now :)
[09:02] <ajmitch> night ;)
[09:20] <Rhonda> ajmitch: build it in a ramdisk!!
[09:21] <Rhonda> oh, should have read the complete backlog
[09:57] <vibhav> While fixing errors in the description, do I need to file bugs even for spelling error in the description?
[10:06] <ikonia> vibhav: topyli just told you in #ubuntu-offtopic, why ask again
[10:10] <vibhav> Is the Ubuntu Pad down!?
[12:15] <Rhonda> hmm, would a FFe for pgadmin3 bug fix release be out of scope?  I am currently building …
[12:17] <tumbleweed> bug fixes don't need FFes (unless they bring in other new features / big changes)
[12:22] <Rhonda> tumbleweed: The changes are quite a fair bit, and I fear not all of them are marked as fixes
[12:23] <Rhonda> The upstream log from 1.14.0 to 1.14.2 has a fair amount of entries :)
[12:24] <tumbleweed> that does sound like a bugfix point-release, though, so I'd be inclined to approve it
[12:24] <Rhonda> Have to get it building first anyway.  Trying to enable debugging symbols, they are giving me troubles right now.
[13:21] <ScottK> jtaylor: If you were up for preparing a numpy update to bring the python3 bits in, I'd be up for reviewing the FFe and doing the New review.
[13:42] <Laney> ajmitch: are you feeling the pinch? http://www.guardian.co.uk/world/2012/mar/19/marmite-shortage-new-zealand-spread
[14:30] <mfisch> I have a ftbfs fix that is a new upstream release, and also has a couple new features in it.  Do I need to file a separate FFe bug still?
[14:31] <tumbleweed> we grant FFes for that kind of thing pretty quickly
[14:32] <mfisch> tumbleweed: so I should still file a new bug then
[14:33] <ScottK> Yes
[14:34] <mfisch> okay will do
[14:49] <mfisch> I filed my FFe.  Now do I need to do a merge proposal?  And if so, to which bug (original or ffe) would I attach it?
[14:50] <tumbleweed> mfisch: you can do the FFe in the original bug
[14:50] <mfisch> too late
[14:51] <tumbleweed> but to answer your question it doesn't really matter. Just make sure that both will get closed by the upload
[14:51] <Rhonda> merge them?
[14:51] <mfisch> ScottK: replied "yes" when I asked if I should file a new bug for the FFe
[14:51] <ScottK> mfisch: Sorry, I misunderstood the question.
[14:52] <ScottK> The existing bug would have been fine.
[14:52] <mfisch> Should I close this new one and move the info over?
[14:52] <mfisch> new: Bug #959347
[14:52] <mfisch> old: Bug #935385
[14:54] <tumbleweed> mfisch: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=646177#32 <- I'll happily sponsor it for you in Debian
[14:54] <mfisch> tumbleweed: it would make much more sense there
[14:54] <tumbleweed> (IIRC I sponsored the last upload of it there)
[14:55] <mfisch> tumbleweed: got a wiki page link on what I need to do to get it there?
[14:56] <tumbleweed> mfisch: it's in a team repository (DPMT) https://wiki.ubuntu.com/Debian/PythonModulesTeam
[14:57] <tumbleweed> but if this is just a once-off fix you are doing, just send a debdiff to that bug, and CC me
[14:57] <mfisch> tumbleweed: you mean send to the debian bug?
[14:57] <tumbleweed> yes
[14:58] <mfisch> tumbleweed: okay, well I will close my FFe and just say "fixing upstream" and then get you the debdiff later today
[14:58] <tumbleweed> it's a new upstream version, so just a diff of the debian directory contents matters
[14:59] <mfisch> tumbleweed: all I did was dch -i, which will need to be redone and rm -rf debian/patches (after validating that they were already applied)
[15:00] <tumbleweed> mfisch: nice
[15:01] <mfisch> tumbleweed: so should I still close out the FFe?
[15:03] <tumbleweed> that can by closed by the sync. But you should close the Debian and Ubuntu FTBFS bugs
[15:04] <tumbleweed> (I mean, close them in the upload, the FFe bug can be closed by the syncer)
[15:06] <mfisch> tumbleweed: talking to you today explains why I never found a guy named "stefanor" on IRC when I was looking last week ;)  I failed to check your launchpad page
[15:06] <tumbleweed> hah
[15:06] <tumbleweed> I used to use that as an IRC nick, but didn't like it so much
[15:06] <mfisch> tumbleweed: maybe you also want to sponsor this one which we've discussed before: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=662227
[15:06] <mfisch> tumbleweed: fix is attached to the bug
[15:07] <tumbleweed> "I have a different way to fix this." <- that's pretty much what I suggested :)
[15:08] <tumbleweed> I've been slacking a little with my sponsorishp recently, but maybe I can do some tonight...
[15:10] <mfisch> tumbleweed: while I was looking for "stefanor" someone else accepted my original fix.  But if we fix it right in Debian we can remove the Ubuntu changes
[15:11] <highvoltage> wow, you're old-school if you're still looking for stefanor :)
[15:15] <mfisch> highvoltage: just an oversight based on his launchpad user-id and not checking his actual launchpad page
[15:19] <tumbleweed> mfisch: test_decode.test_documents.test_nonexistent ... SKIP: you need to run this test with LANGUAGE unset <- seems like we should be doing that
[15:20] <highvoltage> mfisch: ah
[15:21] <mfisch> tumbleweed: okay let me try that out later this morning
[15:21] <tumbleweed> mfisch: actually, no, other tests need that
[15:25] <mfisch> tumbleweed: the changelog says he is skipping "tests in unsuitable environments"
[15:25] <mfisch> skipping some tests I mean
[15:27] <tumbleweed> right, and that's what we see
[16:18] <mfisch> tumbleweed: what are the next steps?
[17:48] <jtaylor> ScottK: great I already merged the changes numpy for personal use
[17:48] <jtaylor> I'll do some sanity checking and request a ffe
[17:50] <micahg> jtaylor: is this the gcc -print-multiarch change or something else?
[17:51] <ScottK> micahg: It's the python3 stuff that just got uploaded to Debian.
[17:51] <jtaylor> the multiarch thing has been merged already
[17:51] <micahg> ah, ok
[17:54] <jtaylor> then only scipy is missing :)
[18:24] <psusi> what is it that normally installs udev hooks?  the kpartx package has an initramfs/hooks file, but it doesn't seem to be installed
[18:28] <PaoloRotolo> Hi all!
[18:29] <yellowduino> hello!
[18:33] <yellowduino> I have a question
[18:34] <yellowduino> I tried checking out totem-pl-parser branch, and its packaging status is OUT-OF-DATE
[18:34] <yellowduino> and I see in ubuntu package-import that its import actually failed
[18:34] <yellowduino> what should I do about it?
[18:34] <micahg> yellowduino: you can make sure there's a bug at bugs.launchpad.net/udd for that type of failure
[18:35] <yellowduino> ok
[18:35] <yellowduino> will do
[18:36] <ajmitch> micahg: I shouldn't have let you talk me into building opeclipart - it's still going :)
[18:36] <micahg> ajmitch: heh
[18:37] <jtaylor> ScottK: https://bugs.launchpad.net/ubuntu/+source/python-numpy/+bug/959588
[18:37] <jtaylor> its a bit short on the text but I guess you are familiar with the problem anyway
[18:38] <ScottK> jtaylor: Just add a debdiff and I'm good.
[18:39] <jtaylor> almost ready
[18:44] <ScottK> barry: Once jtaylor has finished his python-numpy FFe and I approve it, can you sponsor the package (so I'm free to do the New review) ^^^?
[18:45] <jtaylor> ffpushed
[18:52] <barry> ScottK, jtaylor sure, just point me in the right direction
[18:52] <jtaylor> barry: https://code.launchpad.net/~jtaylor/ubuntu/precise/python-numpy/python3-numpy/+merge/98257
[18:53] <jtaylor> there is still a testsuite failure, but its already present in precise so no regression
[18:53] <jtaylor> also I saw now normal runtime issues yet
[18:54] <barry> jtaylor: and it's still not running the tests during the build?
[18:54] <jtaylor> it is, but its ignoring the result
[18:54] <barry> jtaylor: test failures in both py2 and py3?
[18:55] <jtaylor> yes
[18:55] <barry> okay
[18:56] <barry> jtaylor, ScottK i'll merge your branch and do a local build.  ScottK ping me when the ffe is approved and i'll upload it
[18:59] <barry> blarg.  bzr can't merge it :(
[18:59] <ScottK> barry: FFe approved.
[19:00] <jtaylor> I did some crazy criss cross merging at the time I did not think we could still get it in precise
[19:02] <barry> jtaylor: bug 923688 :/
[19:03] <barry> jtaylor: any chance you can unwind that into a non-cross-crossed branch?  or should i just grab the diff?
[19:03] <jtaylor> I can add a debdiff
[19:03] <barry> jtaylor: +1
[19:07] <barry> jtaylor: just let me know when it's ready and which bug its attached to
[19:07] <jtaylor> attached to bug 959588
[19:08] <barry> jtaylor: got it
[19:15] <pinchealeman> I suspect it's too late for this, but I wanted to see what the best way to go about bumping the version of auditd distributed in precise; auditd-2.2 has some nifty field comparisons that would be very helpful
[19:16] <micahg> !ffe | pinchealeman
[19:17] <ScottK> pinchealeman: If you can get Debian to update it and we can update from there, it might not be too late.
[19:17] <micahg> pinchealeman: you also need someone to package the update
[19:17] <ScottK> At this point someone would need to package it otherwise.
[19:17] <micahg> yeah, Debian updating would be better
[19:17] <ScottK> barry: Ping me after you upload and I'll look at New.
[19:18] <barry> ScottK: will do.  just double checking w/a  local build now
[19:18] <pinchealeman> yeah. they're slow :). the last bug I saw on debian.org about auditd was a request to update to 2.1.3
[19:18] <ScottK> Sure.  No rush.
[19:18] <pinchealeman> thanks though, I'll push on them.
[19:22] <jtaylor> micahg: hdf needs lots of sourceful uploads
[19:22] <jtaylor> I don't think its such a good idea to try that now
[19:23] <jtaylor> lots of sorting out new upstreams potential ffe's and backporting
[19:23] <ScottK> Just to be clear, the no rush was for barry.
[19:25] <micahg> jtaylor: I know blair was hoping for it, maybe he can help with the packaging/paperwork
[19:25] <micahg> it should be almost all leaf or interdependent packages
[19:27] <ajmitch> such a nice, sunny day, I'd love to be able to see my monitor :)
[19:32] <barry> jtaylor: unhappy: http://pastebin.ubuntu.com/891153/
[19:33] <jtaylor> hm I must have messed something up when cleaning the diff
[19:33] <barry> jtaylor: ping me when you have a new one
[19:33] <jtaylor> whats that in the log: «PKGBUILDDIR»
[19:34] <barry> jtaylor: that's sbuild's way of stripping out the temporary prefix (i think)
[19:34] <barry> i mostly ignore that
[19:36] <jtaylor> :/ a new python update went in, lots of downloading again ...
[19:42] <ajmitch> micahg: I fear that I don't have enough RAM & time to build this monster package now, the png optimisation looks to be what's taking most of the RAM & time :)
[19:44] <micahg> ajmitch: ok, have a debdiff?
[19:44] <ajmitch> micahg: of course just as I said that to you it finished processing the file it was stuck on for 45 minutes
[19:46]  * ajmitch is just getting a debdiff for it now - it'll be 95% what was in the debian bug
[19:47] <micahg> ajmitch: interesting factoid: openclipart is an anagram for Nicer Laptop :)
[19:48] <ScottK> Someone has too much free time.
[19:48] <ajmitch> haha
[19:48] <ajmitch> micahg: I'll pick out the one I want & you can ship it to me
[19:48] <micahg> ScottK: lunch break :)
[19:50] <ajmitch> micahg: right, only took 5 minutes to get a debdiff, that's not too bad :P
[19:51] <micahg> ajmitch: it has to clean everything, I was going to ask how much disk space the build was taking
[19:51] <ajmitch> < 9 GB, since I only had that much free when I started :)
[19:57] <jtaylor> starting 6 cowbuilders with c++ packages was not such a good idea
[19:57] <jtaylor> two linking processes are eating 70% of my memory :(
[19:57] <ajmitch> hah
[19:57] <jtaylor> load 16 :)
[19:57] <jtaylor> 18 even
[20:06] <jtaylor> c++ is crazy why does it need 4.5 gb memory to link ...
[20:06] <jtaylor> oh no its only compiling, how much is linking going to need :/
[20:07] <micahg> jtaylor: I take it you've never compiled chromium or webkit
[20:10] <ajmitch> micahg: when I was young & foolish, I used to regularly build kdelibs/kdebase from CVS
[20:12] <yellowduino> I'm trying to use dch, and DEBFULLNAME is indeed exported, but the changelog is written with my username and hostname instead of DEBFULLNAME and DEBMAIL
[20:12] <yellowduino> any ideas?
[20:13] <micahg> ajmitch: did we decide if we need an FFe or not?
[20:15] <ajmitch> micahg: it was going to depend on what the differences may be in the built packages
[20:16] <ajmitch> or we could just ask someone on the release team :)
[20:16] <ajmitch> yellowduino: using DEBEMAIL, rather than DEBMAIL?
[20:17] <yellowduino> I'm using DEBEMAIL indeed, my typo earlier
[20:17] <yellowduino> echo $DEBFULLNAME and $DEBEMAIL shows the correct values, but dch doesn't
[20:18] <micahg> yellowduino: exported in the current shell or in general?
[20:18] <yellowduino> in general (bashrc), and I made sure that also in the current shell, same one I'm running dch at
[20:20] <ajmitch> does ~/.devscripts override the environment variables, or other way round?
[20:22] <Rhonda> other way round
[20:22] <Rhonda> envs should always have strongest say
[20:23] <ajmitch> right, that's what I expected
[20:23] <Rhonda> everything else I would consider a bug
[20:23]  * ajmitch has a habit of using emacs instead of dch :)
[20:23] <Rhonda> vim
[20:23] <ajmitch> battle to the death?
[20:23] <yellowduino> butterflies :)
[20:25] <yellowduino> ok, I found the problem. I misunderstood what being exported means - the variables were defined in bashrc but not exported.
[20:26] <micahg> yellowduino: env | grep DEB should verify for you
[20:26] <yellowduino> awesome, good to know
[20:26] <yellowduino> thanks
[20:40] <barry> jtaylor: any luck?
[20:40] <jtaylor> my machine is still deadlocked by a build
[20:40] <barry> dang
[20:40] <jtaylor> and its and 92% I don't want to stop it :)
[20:40] <jtaylor> it also does not happen in oneiric
[20:47] <barry> jtaylor: dang
[20:49] <jtaylor> its probably also a bug in the debian package, its will ftbs when dh_strip is fixed :/
[21:18] <jtaylor> barry: build worked in my precise chroot
[21:19] <barry> jtaylor: was that with your posted debdiff or a new one?
[21:19] <jtaylor> should have been the same as the branch
[21:19] <barry> c
[21:20] <barry> jtaylor: hmm.  that one definitely failed for me.  i suppose i could upload it and we could cross our fingers
[21:20] <jtaylor> no
[21:20] <jtaylor> there are a bunch of broken symlinks that should be looked at
[21:21] <barry> jtaylor: k.  i'll be here for at least another 40m today, so just ping me when you have something you want me to upload
[21:21] <jtaylor> probably tomorrow
[21:21] <barry> jtaylor: np, that'll be fine
[21:30] <ajmitch> micahg: have you started building openclipart yet? if so, the build will fail at the very end due to a typo of mine :)
[21:30] <ScottK> Ah.  The best kind of typo.
[21:30] <ajmitch> of couse
[21:31] <micahg> ajmitch: nope, not until later
[21:31] <ajmitch> ScottK: the one that shows up after > 12 hours of building
[21:32] <ScottK> Yes.  The one that comes right when you've put in all the effort and really start to think you're on the verge of success.
[21:32] <ScottK> That kind.
[21:32] <ajmitch> it was when running dpkg-deb, so I know it was at the end
[21:32] <ajmitch> stray } in Conflicts
[21:33] <ScottK> Can you just rerun the build with -nc?
[21:33] <ajmitch> it was run in sbuild, it already cleaned up
[21:33] <ScottK> Oops.
[21:34] <ScottK> I don't know if there's an sbuild equivalent, but there's a pbuilder hook you can use not to clean up on failure that's very nice for this kind of situation.
[21:34] <ajmitch> most of the build was format conversion & png optimisation, I don't know if -nc would help
[21:45] <jtaylor> barry: created a new chroot and took the prestine debdiff and it still works, is your chroot dirty?
[21:46] <barry> jtaylor: it shouldn't be :(
[21:46] <barry> jtaylor: but if it works for you then maybe i should go ahead and upload it anyway...
[21:49] <jtaylor> you can try, the link problem I thought was there seems correct
[21:49] <jtaylor> just an -ls -l not a dh_link that failed
[21:52] <barry> jtaylor: i wonder why it would fail for me on removing .cpython-*d*.so
[21:52] <barry> oh, i see the ls -l error higher up
[21:54] <barry> jtaylor: i could try building locally again and then poke around the chroot.  but if it builds with that original debdiff okay for you, then i'd be okay just uploading it
[21:54] <barry> jtaylor: your call
[21:55] <jtaylor> you can add a ignore to the rm just to be save
[21:55] <jtaylor> is probably better anyway
[21:55] <jtaylor> add a - before the rm in line 106
[21:55] <jtaylor> or rm -f
[21:58] <jtaylor> sure the chroot is clean? your log shows it did not install a couple python stuff
[22:03] <barry> jtaylor: i do install some python stuff in precise-amd64-source just to save installation time.  it's never been a problem before though, and i did just update my chroots before i tried to build the package
[22:03] <barry> i'll try your suggestion though for the heck of it
[22:04] <barry> jtaylor: line 106 are you sure?
[22:05] <jtaylor> sry line 100
[22:06] <barry> ah, that's better.  i was afraid i had a bad diff
[22:06] <barry> building again now
[22:07] <jtaylor> I do not see in the logs why it should not have worked
[22:07] <jtaylor> dh_install -v would be interestig
[22:10] <barry> jtaylor: let me see how this goes.  i'm nearing the end of my day so i think if this works locally, i'll just go ahead and upload it.
[22:10] <barry> if not, we can circle back tomorrow
[22:13] <jtaylor> we can also just wait, maybe someone else wants to test build it
[22:13] <jtaylor> if its 2 to 1 we upload :)
[22:14] <jtaylor> but ignoring the rm result is the right way to go, I'll forward it
[22:19] <barry> so ignoring the rm did build, and a quick scan of the build log seems sane.  let me pastebin that
[22:20] <barry> jtaylor: http://pastebin.ubuntu.com/891423/
[22:20] <barry> jtaylor: if that's good for you, i'm happy to upload it
[22:22] <jtaylor> the rm worked this time?
[22:23] <barry> jtaylor: with the -rm
[22:23] <jtaylor> there should still be an error emssage in that case
[22:24] <barry> yeah, hmm. no error this time.
[22:25] <barry> jtaylor: i'm prepare to declare victory
[22:25] <jtaylor> python2 packages are fine, so it won't break anything existing
[22:26] <barry> jtaylor: cool.  i will upload it then
[22:27] <jtaylor> why did I start building paraview ._. had to increase my partition twice already for that thing
[22:30]  * barry -> away
[23:02] <ScottK> barry and jtaylor: depwait for numpy ought to be resovled after the publisher runs.
[23:03] <jtaylor> wasn't nose3 added quite a while ago oO
[23:03] <ScottK> It was in Universe.
[23:03] <ScottK> Just got it promoted.
[23:03] <jtaylor> is main based on binary packages not source packages?
[23:04] <ScottK> Both.
[23:04] <ScottK> Binary main must come for source main, but not all binaries of a source in main are necessarily in main.
[23:05] <ScottK> In this case where the source is already in main, getting an additional binary promoted is not hard.
[23:42] <jtaylor> micahg: hdf5 first build round finished, 21 success, 44 fails, 12 due to dependencies missing, rest still need to be checked
[23:42] <ajmitch> that's not a great success rate
[23:42] <jtaylor> more than I expected
[23:47] <jtaylor> <off