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