[01:23] <EvilResistance> do any of you know how i can download the source for a package that is in precise
[01:24] <EvilResistance> i'm aware that dget might work, but i'm unsure the link to use
[01:24] <ajmitch> 'apt-get source packagename' if you have the source entries enabled
[01:24] <EvilResistance> ajmitch:  its in precise.  i'm on natty
[01:24] <ajmitch> it might be more useful to use pull-lp-source if you're not on precise
[01:24] <EvilResistance> the plan is to repackage
[01:25] <EvilResistance> ajmitch:  would dget <path-to-lp-.dsc-file> work?
[01:25] <ajmitch> it would, afaik that's pretty much what pull-lp-source does without you having to find the .dsc file
[01:26] <broder> pull-lp-source is a bit more intelligent because it'll try to use a mirror for everything but the .dsc file to avoid hammering lp quite so much
[01:28] <EvilResistance> broder:  considering its only 3 files, *shrugs*
[01:28] <broder> there are also mirrors closer to you than lp
[01:28] <EvilResistance> i've got the source, but i have a feeling the "natty" build for the source will explodify once it hits the PPA
[01:28] <EvilResistance> :P
[01:28] <EvilResistance> broder:  maybe so, but i'm on an excessively fast hard line
[01:28] <broder> but it sounds like you should also take a look at backportpackage
[01:29] <EvilResistance> broder:  there's a backportpackage command?
[01:29] <EvilResistance> o.O
[01:29] <broder> EvilResistance: my experience is that lp is the limiting factor for downloads from lp, not your connection
[01:29] <broder> EvilResistance: it's only intended for simple, no-change backports, but it sounds like that's what you're trying to do
[01:29] <EvilResistance> broder:  indeed.  how would I go about obtaining this program?
[01:30] <EvilResistance> remember, i'm on Natty, not on Precise
[01:30] <broder> EvilResistance: it was added to ubuntu-dev-tools during the natty development cycle
[01:30] <EvilResistance> huh
[01:30] <EvilResistance> whats the command syntax?
[01:31] <broder> try the manpage? i'm happy to explain if it's not clear, but i tried to make it clear and would prefer to know if it's not
[01:32] <EvilResistance> hm
[01:32] <EvilResistance> the manpage is clear
[01:33] <EvilResistance> but you should consider having the actual program's on-fail help message include the synopsis a bit
[01:33] <broder> it does have a --help
[01:35] <EvilResistance> indeed
[01:35]  * EvilResistance begins using
[01:35] <EvilResistance> i assume, though...
[01:35] <EvilResistance> it requires a PPA in order to upload the backport to?
[01:35] <broder> it can also do local builds
[01:35] <EvilResistance> thereby allowing LP to build the backported package?
[01:35] <EvilResistance> ah
[01:35] <EvilResistance> assume for a minute i dont want to build it at this system
[01:35] <EvilResistance> :P
[01:35] <broder> then yeah, you'd want to upload to a PPA
[01:36] <EvilResistance> syntax then for that option = --upload=<launchpad PPA target> ?
[01:36] <broder> yeah. using the standard syntax, which is "ppa:your-lp-username/your-ppa-name"
[01:36] <broder> just like you'd pass to dput
[01:36] <EvilResistance> cept dput has it all in the configs xD
[01:36] <EvilResistance> ok
[01:37] <broder> actually, iirc, backportpackage just shells out to dput, so whatever it would take as an upload target, backportpackage can also take
[01:38] <EvilResistance> woah explosion!
[01:39] <EvilResistance> ohhhhhh
[01:39]  * EvilResistance ran into this issue BEFORE
[01:39]  * EvilResistance slaps his computer
[01:40] <EvilResistance> broder:  any way for me to pass to the program what PGP key it should use to sign?L
[01:40] <broder> EvilResistance: bah, yeah, i ran into this the other day. you can put it in ~/.devscripts, which debuild looks at
[01:40] <EvilResistance> right now its trying user@systemhostmask
[01:40] <EvilResistance> broder:  syntax?
[01:40] <broder> echo DEBUILD_DPKG_BUILDPACKAGE_OPTS="-k1A2B3C4D" >> ~/.devscripts
[01:42] <EvilResistance> if i have a key that has other uids on it, can i specify one of the non-first uids?
[01:42] <EvilResistance> or do i just get to use the primary uid of said key?
[01:43] <EvilResistance> actually nevermind
[01:43] <EvilResistance> 'tis irrelevant :P
[01:44] <broder> sorry, my gpg-fu is pretty limited
[01:44] <EvilResistance> :P
[01:44] <broder> i know you can pass things like -kevan@ebroder.net though
[01:44] <broder> so i would assume subkeys are fine
[01:44] <EvilResistance> how can i pass  that to the system?
[01:44]  * EvilResistance must know!
[01:44] <EvilResistance> :P
[01:44] <EvilResistance> well... its kinda irrelevant, but meh
[01:44] <EvilResistance> :P
[01:44] <broder> huh? i mean you can set the -k argument in ~/.devscripts to be an e-mail address
[01:45] <EvilResistance> oh really?
[01:45] <EvilResistance> didnt know that :P
[01:46] <broder> the way this works is that debuild looks at DEBUILD_DPKG_BUILDPACKAGE_OPTS in ~/.devscripts, and always prepends those arguments to what you pass on the cmd line
[01:46] <broder> since backportpackage uses debuild, you can take advantage of this
[01:46] <EvilResistance> indeed
[01:46] <EvilResistance> what i really like about this
[01:46] <EvilResistance> is it throws in the ~dist part
[01:46] <EvilResistance> so i can backport  to numerous versions :)
[01:46] <EvilResistance> *ASSUMING* it builds correctly
[01:47] <broder> that's the idea - it's modeled after how ubuntu's backports work (http://help.ubuntu.com/community/UbuntuBackports, not that those docs are great)
[01:47]  * EvilResistance threw it up to a  ppa:lpid/backports ppa
[01:47] <EvilResistance> where lpid is my id ;P
[01:50] <EvilResistance> i forget...\
[01:50] <EvilResistance> the dput ACCEPT or REJECT messages....
[01:50] <EvilResistance> are they emailed to the primary email for the LP account?
[01:50] <broder> yes, assuming that lp was able to verify your signature and cross-reference that to a user account
[01:51] <EvilResistance> any idea on the estimated duration of that?
[01:51] <EvilResistance> i.e.  how long it takes for it to shoot off the email
[01:51] <EvilResistance> or confirm the receipt of the dput?
[01:51] <broder> usually <5 minutes
[01:52] <EvilResistance> cool
[01:52] <EvilResistance> hmm
[01:52] <EvilResistance> out of curiosity...
[01:52] <EvilResistance> if the original source has the architecture listed for multiple architectures...
[01:52] <EvilResistance> will the builders *build* for all architectures?
[01:53] <broder> PPAs only build for i386 and amd64
[01:53] <EvilResistance> ahh
[01:53] <EvilResistance> i see
[01:53] <EvilResistance> even so
[01:53] <broder> there aren't any ARM PPA builders
[01:53] <EvilResistance> i meant will they concurrently build
[01:53] <EvilResistance> i.e. both amd64 and i386 are listed
[01:53] <broder> you get one builder for each arch
[01:53] <EvilResistance> but only amd64 is building now
[01:53] <EvilResistance> it has i386 as "NeedsBuilding"
[01:54] <EvilResistance> ahh.  "Start in 4 minutes"
[01:54] <broder> an i386 builder can't build amd64 binaries, and vice versa
[01:54] <EvilResistance> ...
[01:54] <broder> there are separate pools of builders for each arch, and builds queue up separately
[01:54] <EvilResistance> lets assume for a minute i've **built** numerous packages for the system
[01:54] <EvilResistance> :P
[01:54] <EvilResistance> typically my packages are architecture-independent
[01:55] <EvilResistance> (i.e. 'all')
[01:55] <EvilResistance> THIS is architecture dependent
[01:55]  * EvilResistance sees why amd64 is building now and i386 is not
[01:55] <broder> right, arch: all packages are special
[01:55] <EvilResistance> wth...
[01:55] <EvilResistance> "Dependency Wait..."
[01:56] <broder> that means your package build-depends on something that's not available
[01:56] <broder> probably a versioned dependency that was bumped after natty was released
[01:56] <EvilResistance> wtf's "swig2.0"
[01:56]  * EvilResistance checks
[01:57] <EvilResistance> wth...
[01:57] <EvilResistance> it only exists in *oneiric*?
[01:57] <EvilResistance> "Generate scripting interfaces to C/C++ code"
[01:57]  * EvilResistance has the oh wait
[01:57]  * EvilResistance notices it was searching  only in oneiric
[01:58] <EvilResistance> ah
[01:58] <EvilResistance> i see
[01:58] <EvilResistance> it does exist in natty
[01:58] <EvilResistance> in universe
[01:58] <broder> you're backporting a package from main?
[01:58] <EvilResistance> wth
[01:58] <EvilResistance> broder:  is ZNC in main?
[01:59] <broder> nope
[01:59] <EvilResistance> then you have your answer
[01:59] <broder> did you look at the version of swig2.0 it build-deps on?
[02:00] <EvilResistance> i'd ask how to check that
[02:00] <EvilResistance> but i didnt download the source ;P
[02:00] <EvilResistance> the system did and didnt really store it anywhere
[02:00] <EvilResistance> note i was backporting to Maverick first
[02:01] <EvilResistance> and Maverick doesnt have swig2.0
[02:01]  * EvilResistance will try natty next
[02:01] <EvilResistance> i need it in at least natty ;P
[02:01] <EvilResistance> as for my Debian servers, i'm assumign they're all screwed :P
[02:02] <EvilResistance> unless PPAs allow for Debian builds to be done
[02:02] <EvilResistance> but iirc, there isnt a sid chroot anywhere :P
[02:02] <broder> no, PPAs are for Ubuntu only
[02:02] <EvilResistance> as i suspected
[02:02] <EvilResistance> :P
[02:17] <EvilResistance> ... i'm about ready to explode ubuntu
[02:17] <EvilResistance> configure: error: SWIG version >= 2.0.4 is required.  You have 1.3.40.  You should look at http://www.swig.org
[02:18] <EvilResistance> and that's natty
[02:18] <EvilResistance> wait... what the fsck?
[02:18] <EvilResistance> 2.0.1-2: amd64 i386   <--- that's whats in natty
[02:19] <EvilResistance> WHY IS IT TRIGGERING AN ERROR?!?!?
[02:19] <EvilResistance> for swig
[02:19] <EvilResistance> oh wait
[02:19] <ajmitch> because it needs 2.0.4, but has a lower version, and is complaining about some other strange version number?
[02:19] <EvilResistance> it wouldnt work anyways
[02:20] <EvilResistance> *grumbles about how fscking annoying ubuntu is being*
[02:21]  * ajmitch fails to see why this is ubuntu's fault to grumble about
[02:25] <EvilResistance> i assume i'm free to attempt to backport any package that exists?
[02:25] <EvilResistance> assuming i can get to the dsc
[02:28] <micahg> EvilResistance: you want swig2.0 in oneiric
[02:28] <EvilResistance> micahg:  i want swig2.0 >= 2.0.4 backported into natty is what i want
[02:29] <EvilResistance> i'm not going to be upgrading my VPSes into Oneiric given all the stability issues i'm seeing people whine about
[02:29] <micahg> yeah, so both oneiric and natty have that version
[02:29] <micahg> oops
[02:29] <micahg> I meant oneiric and precise :)
[02:30] <EvilResistance> my patience with ubuntu has dwindled now.
[02:30] <EvilResistance> and when i try to backport swig2.0 it fails too
[02:31] <EvilResistance> dh_autoreconf_clean
[02:31] <EvilResistance> make: dh_autoreconf_clean: Command not found
[02:31] <EvilResistance> because of that
[02:31] <micahg> run 'sudo mk-build-deps -i -r' in the build directory
[02:31] <EvilResistance> what build directory?
[02:31] <EvilResistance> i'm using backportpackage
[02:31] <EvilResistance> its not storing ithe stuff anywhere afaict
[02:32] <micahg> right, you still need some build deps installed, you can either find out which one (apt-file search dh_autoreconf_clean) or use the other command I gave you to install them all
[02:33] <micahg> dh-autoreconf will take care of that issue
[02:35]  * EvilResistance hopes that swig2.0 2.0.4-3ubuntu1 will correctly build in natty
[02:35] <EvilResistance> micahg:  that was what i needed, thanks
[02:39] <EvilResistance> micahg:  assumign swig2.0 correctly builds on the natty systems...
[02:40] <EvilResistance> micahg:  is there a way i can tell the builders to use the PPA that i'm building znc .202 on to use swig2.0 from that same PPA?
[02:40] <EvilResistance> assuming of course it builds
[02:40] <micahg> EvilResistance: will happen automatically once its built
[02:40] <micahg> and published
[02:40] <EvilResistance> i see
[02:41] <EvilResistance> so the builders will automagically check the ppa to see if it contains newer versions of build-deps?
[02:41] <EvilResistance> if not, resort to standard ubuntu archives?
[02:41] <micahg> right
[02:42] <micahg> well, sort of
[02:43]  * EvilResistance needs a definite "This will work" solution >.>
[02:44] <micahg> well, you've got the right idea, it'll work, that's just not exactly how :), I think the PPA is like another apt source on the buildds
[02:46] <EvilResistance> i see.
[02:46] <EvilResistance> oh another question.
[02:47] <EvilResistance> will backportpackage identify correctly whether or not there is already a backport attempt?
[02:47] <EvilResistance> i.e. the verison number i have here is ~natty1~ppa1
[02:47] <EvilResistance> or do i need to add additional options to have it recognize it should be natty2 or something
[02:48] <micahg> yeah, I think there's an option to specify the suffix
[02:49] <EvilResistance> now i just need to hope that the thing wont implode on build
[02:49] <EvilResistance> afaict, its building swig2.0 backported oneiric -> natty without incident
[02:49] <micahg> you can use the defaults on the first upload
[02:49] <EvilResistance> i havent gotten a build fail alert
[02:50] <EvilResistance> whooo it backported :P
[02:50] <EvilResistance> now its being published :P
[02:51] <EvilResistance> micahg:  know offhand the command i have to use to provide the correct next-version suffix?
[02:51] <EvilResistance> the manpages are kinda buried under tabs right now
[02:53] <micahg> EvilResistance: pass -h for a list (-S is what you want in this case)
[02:58] <EvilResistance> micahg:  i got a confirmation from wgrant that the launchpad builders will, if the build-dep exists in the PPA the package is being built for, it will detect it
[02:58] <EvilResistance> we will now know if that is true or not :P
[02:59] <EvilResistance> ... after ~ppa2 is detected ;P
[03:00] <EvilResistance> s/it will//
[03:00] <wgrant> It is true :)
[03:00] <wgrant> Has been for 4.5 years :)
[03:00] <wgrant> They'd be pretty useless if it wasn't true.
[03:01] <EvilResistance> wgrant:  you NEVER KNOW :P
[03:01] <EvilResistance> i've seen some pretty screwy systems ;P
[03:01] <EvilResistance> s/systems/errors/
[03:01] <EvilResistance> with launchpad
[03:01] <micahg> EvilResistance: oh, I know it's true, I didn't say otherwise, I was strictly speaking about the mechanics :)
[03:01] <EvilResistance> micahg:  :P
[03:01] <wgrant> Launchpad is one of those, but it's not *that* screwy.
[03:01]  * EvilResistance is running at somehting similar to defcon 2, so... PP
[03:01] <EvilResistance> confirming my thoughts isnt a bad thing
[03:01] <EvilResistance> brb
[03:02]  * micahg wonders when he'll get bored enough to dig into soyuz
[03:04] <bbigras__> If bug #887349 in papyon affect empathy and emesene since both arn't able to connect to MSN, should the bug marked as such?
[03:04] <EvilResistance> ~ppa2 is accepted, and build status is...
[03:05] <EvilResistance> bbigras__:  i think those might be separate bugs... no?
[03:05] <EvilResistance> i.e.
[03:05] <EvilResistance> papyon isnt necessarily related to those two?
[03:05] <EvilResistance> unless i am wrong
[03:06] <EvilResistance> WTH "Failed ot build"
[03:06] <bbigras__> EvilResistance: Empathy uses papyon for MSN, I saw the bug in empathy's debug window. Not sure about emesene.
[03:06] <micahg> bbigras__: no, the issue can probably be solved in papyon, so not worth marking the other two unless fixes need to be made there or you're getting a lot of dupes
[03:07] <EvilResistance> The following packages have unmet dependencies:
[03:07] <EvilResistance>  swig2.0 : Conflicts: swig but 1.3.40-3ubuntu1 is to be installed
[03:07] <EvilResistance> E: Broken packages
[03:07] <EvilResistance> micahg:  wgrant:  any solutions?
[03:07] <EvilResistance> it at least confirms there's a conflict
[03:08] <bbigras__> micahg: Ok I wasn't sure if the two projects needed to be aware of the bug or not. Yes the bug is in papyon. Thanks.
[03:08] <EvilResistance> micahg:  wgrant:  if either of you need the buildlogs, let me know i can get you the links.
[03:10] <wgrant> EvilResistance: You apparently build-depend on both swig and swig2.0, which is not allowed.
[03:10] <EvilResistance> ...
[03:10] <EvilResistance> wgrant:  that's strange...
[03:10] <wgrant> It may be strange, but it's also true.
[03:11] <EvilResistance> wgrant:  considering the package that needs the build-dep is a backport of a precise package, would i also need to backport swig from precise -> natty?
[03:11] <EvilResistance> er
[03:11] <EvilResistance> oneiric -> natty
[03:11] <EvilResistance> or is the znc build-deps strange?
[03:11] <wgrant> You're probably in the best position to answer that.
[03:30] <EvilResistance> can someone help me debug this from debuild -S?  http://pastebin.com/YmFTFZNJ
[03:32] <wgrant> EvilResistance: You should use dch to edit changelogs.
[03:32] <wgrant> Your date formatting is incorrect.
[03:33] <EvilResistance> wgrant:  how can i just add to the changelog?
[03:34] <EvilResistance> dch modifies the last changelog entry
[03:34] <wgrant> dch -i
[03:55] <EvilResistance> wgrant:  thanks.  i wasnt aware that existed :P
[03:55] <EvilResistance> on another note...
[03:55] <EvilResistance> ITS FINALLY BUILDING!!!
[04:04] <EvilResistance> wgrant:  i owe you a beer, sir.
[04:04] <EvilResistance> micahg:  i also owe you a beer.
[04:04] <EvilResistance> broder:  you too. :P
[04:04]  * EvilResistance finally has this working after HOURS at it
[04:08] <EvilResistance> is there a way for me to import/copy the swig2.0 package from oneiric into my PPA?
[04:09] <StevenK> 1
[04:29] <micahg> EvilResistance: glad you got it working
[04:29] <EvilResistance> micahg:  yep, took enough tries
[04:29] <EvilResistance> micahg:  i ended up having to dget the source
[04:29] <EvilResistance> and then modify the control file
[04:29] <micahg> the fun of backports ;)
[04:30] <EvilResistance> well
[04:30] <EvilResistance> at least backports from Precise
[04:30] <EvilResistance> which was just stuff from sid
[04:31] <micahg> EvilResistance: backportpackage is the closest thing to source copy from archive to PPA ATM AFAIK
[04:31] <EvilResistance> yeah i basically just did that ;P
[04:31] <EvilResistance> -d oneiric -s oneiric :P
[04:32] <micahg> EvilResistance: why would you do that though?
[04:32] <EvilResistance> although i should have set the prefix to null
[04:32] <EvilResistance> micahg:  because i'm weird :p
[04:32] <micahg> if you use backport package in that context, I think it'll just use the archive version for builds
[04:33] <EvilResistance> it might
[04:33]  * EvilResistance shrugs
[04:33]  * EvilResistance was curious if it'd work
[04:33] <micahg> backportpackage makes the version lower so that upgrades work properly
[04:33] <EvilResistance> the only thing i've got left to contend with is compiling znc .202 for oneiric
[04:34] <EvilResistance> since its still theoretically a backport ;P
[04:40] <EvilResistance> oh god damn it
[04:40]  * EvilResistance somehow uploaded the oneiric package into natty within the PPA
[04:40]  * EvilResistance is now annoyed
[05:10] <achiang> what's the name of the tool that can re-wrap the Depends?
[05:11] <achiang> ah, wrap-and-sort
[06:12] <EvilResistance> is it feasible to backport a backported package to an even earlier version?
[06:13] <EvilResistance> i.e. i backported swig2.0 from oneiric to natty and maverick.
[06:13] <micahg> run backport package on it?
[06:13] <EvilResistance> but on the backported version
[06:13] <micahg> yeah
[06:13] <micahg> or on the original if it's a no change backport
[06:14] <EvilResistance> true
[06:14] <EvilResistance> since the backported package IS swig2.0 which successfully backported (one at a time) to maverick
[06:14] <EvilResistance> since its the build dep for znc .202
[06:15] <EvilResistance> if it backports correctly it *might* get the newest ZNC working all the way back to the last LTS :P
[06:15] <EvilResistance> in which case i will be happy
[06:16] <EvilResistance> and so will the ZNC people :P
[06:16] <EvilResistance> since they kept saying that Ubuntu needs to update more often
[06:17] <EvilResistance> ... uhm...
[06:17] <EvilResistance> micahg:  https://launchpadlibrarian.net/84683243/buildlog_ubuntu-maverick-amd64.znc_0.202-1%7Emaverick1-ppa2_FAILEDTOBUILD.txt.gz  <--
[06:18] <EvilResistance> seems it wont build after all
[06:18] <EvilResistance> help with debugging?
[06:18] <EvilResistance> please?
[06:18] <EvilResistance> :P
[06:18] <EvilResistance> (might be that lucid is just plain old,  but meh)
[06:19] <micahg> sorry, I've got some work I need to finish up tonight, maybe someone else can help
[06:19] <EvilResistance> :P
[06:19] <EvilResistance> well its the same fail on i386 as amd64
[06:19] <EvilResistance> so meh
[06:19] <EvilResistance> i've got to be up in 7 hours anyways
[06:19]  * EvilResistance should be asleep
[06:20] <hyperair> looks like a bug in dh_python3
[06:20] <hyperair> ['adsf'] should be a list containing 'adsf'
[06:20] <EvilResistance> but only on lucid
[06:20] <hyperair> but it tried to do a hash lookup on something..
[06:20] <hyperair> oh only on lucid?
[06:20] <EvilResistance> hyperair:  it built correctly on maverick and later
[06:20] <hyperair> maybe it's supposed to run on python3..
[06:20] <hyperair> er
[06:20]  * hyperair shrugs
[06:20] <hyperair> there's probably a bug in the buildd in lucid or something
[06:20] <hyperair> a bug in dh_python3 perhaps
[06:20] <EvilResistance> hyperair:  https://launchpad.net/~trekcaptainusa-tw/+archive/backports/+packages
[06:20] <EvilResistance> for reference
[06:20] <EvilResistance> there's packages for maverick and natty
[06:21]  * hyperair shrugs. sorry, i can't really spend much time on this
[06:21] <EvilResistance> ... and a znc package for oneiric
[06:21] <hyperair> i'm supposed to be studying
[06:21] <EvilResistance> i'll go stab the #launchpad peoples
[06:21] <hyperair> heh
[06:21] <hyperair> have fun
[06:21] <EvilResistance> perhaps they can fix the builders
[06:21] <EvilResistance> except i'll stab them tomorrow
[06:21] <micahg> #ubuntu-packaging for PPA build failures not related to launchpad itself
[06:21] <EvilResistance> because i'm fscking tired
[06:21] <EvilResistance> micahg:  could it not be a build problem in the builders?
[06:21] <micahg> not likely
[06:22] <hyperair> more likely a bug in python3
[06:22] <hyperair> maybe #debian-python can help
[06:22] <hyperair> on irc.oftc.net
[06:22] <EvilResistance> i'll start with #ubuntu-packaging
[06:22] <EvilResistance> fwiw i dont want to deal with debian people now
[06:23] <hyperair> heh
[06:23]  * hyperair is a debian person though. =p
[06:23] <hyperair> going to be anyways
[06:23] <EvilResistance> with the exception of motu people here ;P
[06:23] <hyperair> =p
[06:27]  * micahg would like to be a Debian person one day
[06:44] <freakabcd> hi all
[06:45] <freakabcd> any idea if octave 3.4.3 will be packaged officially?
[06:45] <freakabcd> the current version 3.2.4 is old
[06:46] <freakabcd> or perhaps someone can guide me on how i can make deb packages from existing "making a deb package for octave" files (if they exist)
[06:56] <EvilResistance> freakabcd:  out of curiosity-
[06:56] <EvilResistance> did you look at what was in debian sid
[06:56] <EvilResistance> to see if the newest version is in there somewhere?
[06:56] <freakabcd> no. it is the same 3.2
[06:57] <freakabcd> i suppose you guys are going to simply use the debian pkg
[06:57] <freakabcd> i mean use their setup and stuff. (with some tweaks) since it is similar enough
[06:57] <EvilResistance> well
[06:57] <EvilResistance> they usually start with whatever's in sid
[06:57] <freakabcd> where can i get the source(s) for the building?
[06:57] <EvilResistance> and then downgrade/upgrade as needed
[06:57] <freakabcd> i suppose we could have a package before debian gets it :)
[06:57] <EvilResistance> *shrugs*
[06:58] <EvilResistance> freakabcd:  just getting the source for 3.4.3 miight not be enough
[06:58] <freakabcd> no
[06:58] <EvilResistance> because you need to create a source package
[06:58] <freakabcd> i meant the sources for the extras
[06:58] <EvilResistance> oh
[06:58] <EvilResistance> that
[06:58] <EvilResistance> um...
[06:58] <EvilResistance> not sure
[06:59] <EvilResistance> you could try searching for the sources in the apt archives
[06:59] <EvilResistance> i think lp has a list of all ubuntu packages :/
[06:59] <freakabcd> i know how to build octave 3.4.3 and infact i have it already built. just thought i could make a pkg if its easy enough to tweak the setup for 3.2 pkg
[08:04] <dholbach> good morning
[08:08] <ajmitch> morning dholbach
[08:08] <dholbach> hey ajmitch
[08:09] <ajmitch> how are you today?
[08:09] <dholbach> good good - how about yourself?
[08:13] <ajmitch> I'm alright, just been out at a developers meetup :)
[08:16] <dholbach> and? was it any good?
[08:16] <ajmitch> yeah, it's a monthly event, head to the pub afterwards & chat :)
[08:17] <dholbach> nice :)
[08:18] <ajmitch> which reminds me, I need to take a screenshot of this unity bug :)
[10:41] <Laney> morning
[10:41] <Laney> dholbach: could you set -t please?
[10:41] <Laney> also, safe journey home?
[10:41]  * Laney got stopped by security at MCO
[10:42] <dholbach> -t?
[10:42] <Laney> in this channel
[10:42] <Laney> you haz op powers
[10:43] <dholbach> hum
[10:43] <dholbach> I might be too stupid to do it
[10:43] <Laney> /mode #ubuntu-motu -t
[10:43] <dholbach> yeah, safe trip home, but I'm still quite tired
[10:43] <Laney> should do it
[10:43] <Laney> indeed
[10:43] <Laney> slept until 1.30pm yesterday
[10:43] <Laney> ty
[10:47] <nigelb> Laney: stoped by security?
[10:47] <Laney> they thought my laptop's power cable was suspicious
[10:48] <nigelb> ah.
[10:50] <nigelb> Laney: When I was young, your family had a hilarious time.  The security person thought a particular dish/crockery looked sucipious and made us open the bag.  They didn't tel us what they wewre looking for and they couldn't find it either. Mom guessed and showed it to the security lady leading to much laughter :)
[10:50] <nigelb> s/your/*our*
[11:22] <Laney> oh, I asked for -t for a reason
[11:25] <tumbleweed> ah, thanks I'd been meaning to do that too
[14:20] <scott-work> is MOTU responisble for the ia32-libs package?  if not, can anyone suggest a channel i can purse an answer in?
[14:25] <tumbleweed> what's the question+
[14:25] <tumbleweed> ?
[14:26] <scott-work> tumbleweed: i get keep a notification that it fails to build and this is causing other packages in the ubuntu studio package set to fail to build
[14:26] <scott-work> i seem to remember that someone mentioned something funny about that package as well
[14:26] <scott-work> unfortunately i cannot remember the specifics about that converstaion
[14:26] <scott-work> converstation
[14:26] <scott-work> errr. conversation
[14:27] <scott-work> tumbleweed: correction, ia32-libs fails to produce installabile binaries
[14:28] <tumbleweed> aha, that I can understand. ia32-libs only depends on multi-arched libraries, these days. And not everything that it depends on has been converted to multiarch yet
[14:29] <tumbleweed> scott-work: https://lists.ubuntu.com/archives/ubuntu-devel/2011-October/034279.html
[14:30] <scott-work> oustanding tumbleweed!  thank you for that information
[14:30] <scott-work> since i am at work i will most likely need to digest all of it later
[14:31] <tumbleweed> heh, np
[14:35] <freeflying> dpm: ping
[14:49] <dpm> hi freeflying
[14:50] <freeflying> dpm: can you please join #ubuntu-cn-translators
[14:51] <dpm> freeflying, yup
[14:51] <freeflying> dpm: thanks
[15:54] <l3on_> Hi all... someone could help me with:
[15:54] <l3on_> http://debomatic.debian.net/unstable/pool/dtn_2.8.0+hg3523-1/dtn_2.8.0+hg3523-1.buildlog
[15:54] <l3on_> rmdir: failed to remove `debian/dtn/usr/local/lib/perl/5.12.4/auto/dtnapi': Directory not empty
[15:54] <l3on_> dh_usrlocal: rmdir debian/dtn/usr/local/lib/perl/5.12.4/auto/dtnapi returned exit code 1
[16:17] <broder> l3on: don't have a lot of time to stick around at the moment, but from a quick glance it looks like the library is getting installed into /usr/local instead of /usr
[16:18] <l3on> broder, I know.. and dh_usrlocal is going to fix it... but I've some problems with him
[16:19] <l3on> my rules:
[16:19] <l3on> http://paste.ubuntu.com/732136/
[16:19] <broder> l3on: no, dh_usrlocal doesn't fix up things that install in /usr/local
[16:19] <l3on> ah :/
[16:19] <broder> you should read its manpage
[16:19] <l3on> I read it..
[16:20] <l3on>  It finds subdirectories of usr/local in the package build directory, and removes them, replacing them
[16:20] <l3on>        with maintainer script snippets
[16:20] <broder> right. placeholder directories, not files
[16:20] <l3on> ah, so ... what could be a solution  ?
[16:20] <broder> and it doesn't move them out of /usr/local
[16:21] <broder> i don't know. you need to figure out how to make your build system install into /usr instead of /usr/local
[16:21] <l3on> ok, thank you :)
[17:48] <EvilResistance> if i want to submit a backport for consideration, so its backported to natty and oneiric, but the package i'm backporting is from debian sid/Precise, do i have to wait until  Precise is released?
[17:50] <EvilResistance> or can i submit the backport for consideration?
[17:57] <micahg> EvilResistance: no, you don't have to wait until release, but ideally it should be a stable version
[17:59] <EvilResistance> micahg:  what if i can provide evidence of stability?
[17:59] <EvilResistance> you're aware of what i've been backporting
[17:59] <EvilResistance> its basically an upstream code release
[17:59] <EvilResistance> ... just backported :P
[17:59] <EvilResistance> with a single change to the debian/control file to remove a conflict in ubuntu
[17:59] <micahg> EvilResistance: no, that was just a suggesting, not necessarily a requirement
[17:59] <EvilResistance> indeed
[18:00] <EvilResistance> micahg:  who/where should i start the process?
[18:00] <micahg> EvilResistance: requirements are build, install, run,
[18:00] <micahg> https://help.ubuntu.com/community/UbuntuBackports#How_to_request_new_packages
[18:01] <EvilResistance> wait....
[18:01] <EvilResistance> i'll have to file two backport requests?
[18:01] <EvilResistance> one for natty one for oneiric?
[18:04] <EvilResistance> micahg:  will anything in universe be considered for backporting?
[18:04] <EvilResistance> or no?
[18:04] <micahg> sure
[18:04] <micahg> EvilResistance: well, as long as it doesn't have a lot of reverse dependencies and the ones it has are tested
[18:07] <EvilResistance> micahg:  if the only thing that needed backported alongside this package was a single build-dep, and the rest of the dependencies for building exist already in Natty, with that single exception, would i need to file a dual backport request?  or can i request both of those packages backported?
[18:08] <EvilResistance> via separate requests
[18:12] <micahg> EvilResistance: I think separate requests with a cross-reference in the description would be good IMHO
[18:17] <EvilResistance> micahg:  could i post them in the same?  for example, this is what i'm writing in thusfar: http://pastebin.com/sH7pTDBx
[18:18] <EvilResistance> brb, low power
[18:19] <EvilResistance> micahg:  back, only had to move 20 feet :P
[18:21] <EvilResistance> micahg:  i'd rather not use more bw than i already have :P
[18:21]  * EvilResistance is on bw-limited networking at a university
[18:22] <EvilResistance> so if i can get it all in one request, that'd make my life easier
[18:23] <micahg> sorry, I'm going to have to let one of the backporters field this, I'm very busy right now
[18:23] <EvilResistance> ok
[18:23]  * EvilResistance isnt sure who the backporters are unfortunately :P
[19:01] <l3on> Hi... does someone know how can I pass "-l" parameter to dh_shlibdeps using ovveride_dh_auto_install
[19:01] <l3on> I've tried this:
[19:01] <l3on> http://paste.ubuntu.com/732294/
[19:01] <l3on> but it does not work
[19:01] <Zhenech> override_dh_shlibdeps?
[19:01] <l3on> ah ok :
[19:01] <l3on> :)
[19:01] <l3on> can you show me ? :)
[19:01] <l3on> override_dh_shlibdeps:
[19:02] <l3on>   dh_shlibdeps "-l/blbalbal/blballba"
[19:02] <l3on> is it ok ?
[19:02] <Zhenech> yes
[19:02] <l3on> ok, trying :)
[19:02] <EvilResistance> can someone point me to someone on IRC who is a member of the Ubuntu backports team?
[19:02] <Zhenech> you can override evey dh_command
[19:02] <jtaylor> manpge: With recent versions of dpkg-shlibdeps, this option is generally not needed.
[19:02] <jtaylor> do you really need it?
[19:05] <l3on> jtaylor, the question is for me?
[19:06] <jtaylor> yes
[19:06] <l3on> Yep, if I don't use it then build fails
[19:07] <jtaylor> you are building multiple flavors of the same library?
[19:07] <l3on> I think it's because $(CURDIR) is not "standard"
[19:07] <jtaylor> whats the error message you get?
[19:07] <l3on> this is the problem:
 dpkg-shlibdeps: error: Cannot continue due to the error above.
 Note: libraries are not searched in other binary packages that do not have any shlibs or symbols file.
 To help dpkg-shlibdeps find private libraries, you might need to set LD_LIBRARY_PATH.
 dh_shlibdeps: dpkg-shlibdeps -Tdebian/python-dtn.substvars debian/python-dtn/usr/lib/pyshared/python2.7/_dtnapi.so returned
[19:09] <jtaylor> whats the "error above"?
[19:09] <l3on> ehm... I've no more the log
[19:10] <l3on> btw, now it works ! → http://debomatic.debian.net/unstable/pool/dtn_2.8.0+hg3523-1/dtn_2.8.0+hg3523-1.contents
[19:11] <jtaylor> pysupport is deprecated
[19:11] <jtaylor> public library but not lib packagename?
[19:11] <l3on> mmm
[19:12] <l3on> Do you think I need it ?
[19:14] <l3on> well I don't understand this:
[19:14] <jtaylor> probably depends on your sponsor :)
[19:14] <l3on> http://www.debian.org/doc/packaging-manuals/perl-policy/ch-site.html#s-site_dirs
[19:14] <l3on> it means I have to put my perl module in /usr/local/ ?
[19:15] <l3on> but debian policy forbids me to provide a packages with file in /usr/local :/
[19:15] <jtaylor> local installed usually means not installed by a package
[19:15] <l3on> ah ok
[19:15] <jtaylor> nothing in usr/local should be overriden by package upgrades
[19:22] <roaksoax> /win/win 8
[19:28] <l3on> instead of python-support I should use python-shared ?
[19:38] <jtaylor> dh_python2
[19:39] <jtaylor> http://wiki.debian.org/Python/TransitionToDHPython2
[19:42] <l3on> jtaylor, do you have a sample to show me ?
[19:44] <jtaylor> there is not really much to show, add --with python2 to the dh $@ line and remove XS- XB-PythonVersion from control and see what happens
[19:44] <l3on> ok :)
[19:45] <jtaylor> btw are you building in precise? in your contents there is only a 2.7 library
[19:45] <jtaylor> if you b-d on python-all-dev it will build for all versions
[19:49] <l3on> ah ok, I'll try :)
[19:50] <l3on> python-all-dev (>= 2.6.6-3~) is it fine ?
[19:51] <jtaylor> yes
[19:52] <jtaylor> note that dh_python2 is not available in lucid, so if you want to support that you may want to stick with pysupport
[19:53] <l3on> ah damn :/
[19:53] <l3on> I need this package for debian stable and ubuntu natty (last LTS)
[19:54] <EvilResistance> um...
[19:54] <soren> Natty wasn't LTS.
[19:54] <EvilResistance> you realize the last LTS was lucid right?
[19:54] <jtaylor> stable has it so far I know
[19:54] <EvilResistance> l3on:  ^
[19:54] <ScottK> It does.
[19:54] <l3on> ehm... lucid :/
[19:54] <ScottK> Someone's working on a backport.  Ask barry.
[19:55] <jtaylor> no complaint, but "someone is working on it" since month :)
[19:55] <l3on> ok, I return on pysupport :)
[19:55] <broder> actually, someone has been nominally working on it for a year
[19:55] <broder> but who's counting
[19:56] <EvilResistance> broder:  are you the one who wrote the manpage for backportpackage?
[19:56] <broder> EvilResistance: yes
[19:56] <tumbleweed> jtaylor: longer than a month. at least 6 months
[19:56] <EvilResistance> oh cool :P
[19:56] <tumbleweed> oh broder got there :)
[19:56] <EvilResistance> broder:  you wouldnt happen to be part of the backports team would you?
[19:56] <broder> i am
[19:56] <EvilResistance> broder:  could i get you to review a backport request i threw up for natty?
[19:56] <broder> tumbleweed: it was definitely discussed at uds-n
[19:56] <EvilResistance> or will you eventually see it?
[19:57] <broder> EvilResistance: i can look. what's the bug #?
[19:57] <EvilResistance> sec
[19:57] <EvilResistance> 887707 under natty backports
[19:58] <EvilResistance> https://bugs.launchpad.net/natty-backports/+bug/887707
[19:58] <broder> EvilResistance: can you please split that out into 2 bugs? some of our tools require that
[19:59] <EvilResistance> broder:  yeah i can
[19:59] <EvilResistance> broder:  sec.
[19:59] <EvilResistance> broder:  actually, can you wait for about 5 minutes?
[20:00] <EvilResistance> trying to debug a do-dist-upgrade
[20:00] <broder> EvilResistance: that's fine. there is likely some additional work that will need to be done, so i'll put that on the bug
[20:01] <EvilResistance> i marked that one as invalid anyways
[20:01] <EvilResistance> :P
[20:01] <ajmitch> fwiw, swig2.0 in precise has a swig binary package that doesn't conflict with swig2.0, so there wouldn't need to be source changes to znc
[20:02] <broder> is it actually necessary to depend on both? or should we be fixing the package in unstable/precise?
[20:03] <ajmitch> I think it should be only build-depending on one, but it was added back in as an unversioned build-dependency, it's mentioned in znc's changelog
[20:04] <ajmitch> it appears to be for debian backports, funnily enough :)
[20:04] <broder> bah. that sounds a lot like a broken build system
[20:04] <EvilResistance> ajmitch:  the conflict is with `swig`
[20:04] <EvilResistance> not `swig2.0`
[20:04] <EvilResistance> ran into this on the builders
[20:05] <broder> EvilResistance: right. i don't understand why swig still needs to be in the b-d list
[20:05] <EvilResistance> `swig` and `swig2.0` conflict
[20:05] <EvilResistance> broder:  it was in the build-deps on sid :/
[20:05] <broder> right. why?
[20:05] <ajmitch> the oneiric versions of swig & swig2.0 conflict
[20:05] <broder> ScottK: it's been a long time since i approved a non-leaf backport. what are the rules on r-build-dep testing again?
[20:05] <EvilResistance> broder:  https://bugs.launchpad.net/natty-backports/+bug/887757  https://bugs.launchpad.net/natty-backports/+bug/887758
[20:05] <EvilResistance> broder:  split as requested, both refer to each other
[20:06] <EvilResistance> (i.e. links exist)
[20:06] <ScottK> broder: Test all the rdepends unless there's a very good reason to believe testing a subset is OK.
[20:06] <broder> including b-d? ok
[20:06] <ScottK> Yes.
[20:06] <ScottK> For something like swig that's kind of important.
[20:06] <broder> right, that's why i wanted to double-check
[20:14] <filip_> Hi. I have a problem creating a PPA package that contains files with diacritics and spaces in filename.
[20:15] <broder> EvilResistance: oh, good - you're only requesting a oneiric->natty backport of swig2.0
[20:15] <broder> that's actually much easier than i was afraid it would be
[20:15] <broder> since nothing in the archive actually used swig2.0 in natty
[20:15] <EvilResistance> broder:  :P
[20:15] <l3on> jtaylor, thank you so much :)
[20:15] <EvilResistance> broder:  yeah, its an oneiric->natty nochange backport
[20:15] <l3on> I learn many things today :(
[20:15] <l3on> :)
[20:15] <EvilResistance> broder:  same as i had to do to get the damned buildds to build znc
[20:16] <broder> EvilResistance: i thought you were asking for precise->natty for swig2.0, which would have been harder because we have to backport to oneiric as well
[20:16] <l3on> I've to go now... see you and thanks again :)
[20:16] <EvilResistance> broder:  swig2.0 existed in oneiric
[20:16] <EvilResistance> and was sufficient to build znc 0.202 in oneiric
[20:16] <EvilResistance> case in point: my ppa
[20:16] <broder> EvilResistance: got it. give me a moment to ACK the swig2.0 backport and i'll look at the znc one
[20:16] <EvilResistance> broder:  before actually *filing* the backport requests... i did my homework :p
[20:17] <EvilResistance> and tested within my backports pap
[20:17] <broder> EvilResistance: and we backporters appreciate that!
[20:17] <broder> :)
[20:17] <EvilResistance> ppa*
[20:17] <EvilResistance> broder:  although be aware...
[20:17] <EvilResistance> i'm considering filing the znc backport for precise -> oneiric as well
[20:17] <EvilResistance> same debian/control change
[20:17] <EvilResistance> otherwise it builds as swig2.0 in oneiric is sufficient for building
[20:18] <filip_> Could anybody point me to any resource on how to put diacritics+spaces in the file name, please? The packaging process always fails, even when I tried to put the filenames in quotes in the debian/install file.
[20:19] <filip_> (maybe I will ask in #ubuntu-packaging...)
[20:19] <broder> EvilResistance: we will actually require that. in order for the natty->oneiric upgrade to work correctly for users that install znc from backports, we need the package in oneiric to have a higher version number than the one in natty, so we need a backport there as well
[20:20] <broder> but we can evaluate that all within the one bug - i'll be there in a sec
[20:20] <jtaylor> filip_: spaces in filenames does not work with dh_install debian bug 198507
[20:21] <filip_> jtaylor: thanks
[20:21] <jtaylor> you will hve to install them manually in rules
[20:22] <filip_> jtaylor: do you think there is any better workaround than renaming them in the debian/postinstall script?
[20:22] <jtaylor> install them in debian/rules with standard shell tools
[20:22] <EvilResistance> broder:  indeed, i wasnt sure the exact methodology, but according to my tests within the PPAs, the znc 0.202 (sid/precise -> oneiric) has built
[20:22] <EvilResistance> broder:  as for testing, i dont have an oneiric server around
[20:22] <filip_> jtaylor: thank you, I will try that
[20:22] <EvilResistance> but this should get the people from znc to stop yelling about ubuntu users having older versions
[20:23] <broder> EvilResistance: i'm also going to adjust the title of the bugs to what our tools expect
[20:23] <broder> (makes it easier for the archive admins when the handle the backport)
[20:25] <EvilResistance> broder:  indeed.  there wasnt a specified title format in the "How to request" page
[20:25] <broder> the docs certainly could use some love
[20:26] <broder> did you test all of the packages generated by znc, or just the znc package itself?
[20:27] <EvilResistance> broder:  they all actively installed by just installing `znc`
[20:27] <EvilResistance> broder:  they built and executed, but extremely thorough testing wasnt completed.
[20:27] <EvilResistance> from what i can tell
[20:27] <EvilResistance> the other packages provide additional modules into ZNC
[20:28] <broder> EvilResistance: we don't need extensive testing - our standard is "builds, installs, runs", and our standard for "run" is pretty low
[20:28] <EvilResistance> broder:  it does execute and the modules they install load correctly
[20:28] <EvilResistance> broder:  otherwise ZNC would freak and continually segv
[20:28] <broder> ok. that sounds good. we will need you to come up with some way to verify oneiric as well before we can approve the backport
[20:28] <broder> but everything looks good other than that
[20:28] <EvilResistance> broder:  throw me an oneiric VPS and i'll make it run :P
[20:28] <EvilResistance> actually
[20:29] <EvilResistance> *downloads oneiric server*
[20:29] <EvilResistance> i have VMS!
[20:29] <EvilResistance> :P
[20:31] <EvilResistance> broder:  would verifying using the PPA i have (which includes the oneiric backport for znc 0.202) work?
[20:31] <EvilResistance> on the oneiric VM
[20:31] <EvilResistance> (which is a full oneiric server install on VBox)
[20:32] <broder> yeah, that would be fine
[20:33] <EvilResistance> now if only this would download a bit faster
[20:34] <EvilResistance> its at 55% download of the ISO
[20:38] <EvilResistance> broder:  how long are  ya going to be here
[20:38] <EvilResistance> i dont wnat to inconvenience you if you have somehwere else to be
[20:38] <EvilResistance> *98% download completion*
[20:40] <broder> EvilResistance: i'm in the US, so it's the middle of my day or so. i'll be around, but am probably not going to take another look until end of my work day
[20:40] <EvilResistance> broder:  OK.  i'm currently loading up the VM now
[20:40] <EvilResistance> so this shouldnt take too long :P
[20:41] <EvilResistance> broder:  should i jsut post a bug comment saying "Confirmed to run in Oneiric"?
[20:41] <EvilResistance> if/when i confirm it
[20:41] <broder> EvilResistance: yes, that's fine
[20:42] <EvilResistance> ok
[21:13] <ResistNow> broder: this is the Oneiric ZNC instance, 0.202
[21:14] <ResistNow> broder: if you're around this is the confirmation it works
[21:14] <ResistNow> its within an ubuntu server 11.10 VM inside VirtualBox
[21:14] <ResistNow> i'm going to write down to the bug now that i confirmed it works.
[21:14] <broder> ResistNow: you don't need to prove it to me :)
[21:14] <broder> we're happy to take your word that you've done the testing, as long as we think you understand what testing we're asking for
[21:15] <EvilResistance> broder:  i like proving it ;P
[21:15] <EvilResistance> just in case ;P
[21:15] <EvilResistance> bug updated
[21:15] <EvilResistance> to include the testing
[21:16] <broder> EvilResistance: ok. that should be sufficient. i'll look at it again when i get home from work
[21:16] <EvilResistance> ok
[21:16] <EvilResistance> also make sure that when its backported they fix the build-deps
[21:16] <EvilResistance> because of that small conflict
[21:16] <EvilResistance> (which i outlined in the bug description)
[21:17] <broder> yeah, understood
[21:23] <EvilResistance> broder:  i would request this be backported all the way to lucid but the build deps for ZNC are either too old, or buggy... :P
[21:23] <EvilResistance> (in Lucid)
[23:30] <blair> Does ubuntu ever sync from debian experimental packages?  i'm looking at hdf5 in particular, which is at 1.8.7 (which we need) while ubuntu has 1.8.4
[23:31] <micahg> blair: yes, but that's unlikely to happen for an LTS w/out a *really* good reason
[23:32] <EvilResistance> broder:  just checking up on ya, seeing if you're alive or if its your end-of-day yet.
[23:32] <EvilResistance> ;P
[23:32] <broder> not yet. i'm on pacific time and got in late, so probably still have about 3 hours to go
[23:33] <EvilResistance> ok.  wasnt sure.
[23:33] <EvilResistance> holy god, i have two battery indicators o.o
[23:34] <blair> micahg, so would the appropriate thing to do is to request a bump from 1.8.4 to 1.8.7 using the existing packages?  debian has changed the packages extensively?
[23:34] <EvilResistance> blair:  you mean try and backport 1.8.7 to your system?
[23:34] <EvilResistance> that's not exactly *easy*
[23:34] <EvilResistance> because lets say you're on lucid
[23:34] <EvilResistance> if you were to try and backport something to lucid
[23:35] <blair> EvilResistance, no, i'm looking forward to the 12.04 release, i want to get us from Fedora 13 to 12.04
[23:35] <EvilResistance> it has to backport and not conflict with maverick, natty, etc.
[23:35] <EvilResistance> blair:  oic
[23:35]  * EvilResistance goes quiet
[23:35] <blair> one of our open source projects depends upon hdf 1.8.7 while 12.04 currently has 1.8.4
[23:35] <micahg> blair:  there's a soname bump, so unlikely to happen w/out a good reason or Debian doing it (we already have a lot of transitions to finish)
[23:37] <micahg> it's ~25 packages
[23:37] <micahg> umm, actually seems to be quite a bit more
[23:39] <micahg> blair: I'd suggest talking to the Debian maintainer about getting the transition started there
[23:39] <micahg> we still have 3 months until feature freeze, so that should be enough time to finish if it's desired in Debian