[00:07] <broder> EvilResistance: ok. waiting for a build to finish at work, so i uploaded znc
[00:07] <EvilResistance> cool thanks.
[00:08] <broder> it'll still need an archive admin to look at it, which i'd expect them to do within the next couple of days (probably around the same time they process the swig2.0 backport)
[00:27] <EvilResistance> indeed.  i assume they'll process the swig2.0 backport first as the ZNC backport requires that for a build-dep?
[00:27] <broder> presumably. if not, there's a button i can click to retry the znc build
[00:28] <blair> micahg, i haven't looked, but you're saying that 1.8.4 is not ABI compatible with 1.8.7?
[00:28] <EvilResistance> if all else fails, there's always the backports ppa of mine
[00:28] <EvilResistance> it contains a sufficient version from oneiric->natty
[00:28] <EvilResistance> until  at least the backports become official
[00:28] <micahg> blair: correct, or so it seems from the package name changes
[00:29] <blair> micahg, i'm not suggesting to take their 1.8.7 which does look like a lot of changes, but just using new upstream tarballs with the existing 1.8.4 debian/ directory
[00:31] <micahg> blair: yes, but if they did those changes, it's most likely for an ABI break
[00:31] <blair> that would be bad form for the HDF people then
[00:36] <blair> micahg, looks like there was an unintentional ABI changes between 1.8.4 and 1.8.7: http://linuxtesting.org/upstream-tracker/versions/hdf5.html , but in 1.8.7 they increases the .so number at least
[00:37] <micahg> blair: right
[00:38] <blair> i also emailed upstream, but no response yet http://lists.debian.org/debian-gis/2011/11/threads.html
[00:38] <blair> s/upstream/debian/
[00:41] <blair> micahg, so there's reluctance to bump the .so before an LTS release?  is there a way to query apt-cache to see the number of packages that depend on hdf5 to see how much would need to be rebuilt?
[00:43] <blair> it would be good to get the latest stable release in before locking off on the version for 5 years ;)
[00:43] <micahg> blair: there's a reluctance to start a transition due to a soname bump w/out support from Debian since we have quite a few outstanding already, I would have phrased your e-mail more along the lines of asking Debian when they plan to start the transition in unstable and (if you care to) how you can help
[00:44] <micahg> blair: and the freeze for this is feature freeze (Feb 16 IIRC)
[00:45] <micahg> blair: apt-rdepends -r
[00:46] <EvilResistance> micahg:  can that be used to find rdepends for packages not within your current distribution (i.e. to find rdeps for packages in Oneiric from a natty system)
[00:46] <micahg> Debian doesn't freeze until later next year, also, they might not even be planning this transition for wheezy
[00:46] <micahg> EvilResistance: I think so, I believe it operates on your cache (assuming what you want is in an apt repo)
[00:47] <micahg> EvilResistance: oh, in that case, no, you'd probably need to use chdist
[00:47] <broder> micahg, EvilResistance: or the new site that tumbleweed just finished! :)
[00:47] <broder> http://qa.ubuntuwire.org/rdepends/?package=bash
[00:47] <micahg> sorry, misread the question the  first time
[00:47] <broder> takes package=, release=, and arch= arguments
[00:47] <EvilResistance> um...
[00:47] <broder> arch=source takes a source package name instead of binary, and returns build-depends
[00:47] <EvilResistance> broder:  if i'm not mistaken, MIME types are fubar'd on that site
[00:47] <EvilResistance> its serving it up as a .JSON
[00:48] <EvilResistance> and the system is prompting a download
[00:48] <EvilResistance> either that or the backend is screwed
[00:48] <broder> EvilResistance: it's intended to be the backend for other tools, not really to be used directly
[00:48] <EvilResistance> oic :P
[00:48] <EvilResistance> broder:  you should write a tool that interfaces with it!
[00:48] <EvilResistance> :)
[00:48] <EvilResistance> :P *
[00:48] <broder> we plan to write several
[00:48] <blair> micahg, i get the reluctance.  i got the december date from https://wiki.ubuntu.com/PrecisePangolin/ReleaseSchedule, where it says LTSDebianImportFreeze
[00:49] <EvilResistance> blair:  that's when they no longer will import from debian
[00:49] <micahg> blair: actually, that was moved to Jan 9, that's the last auto import, fixes after that from Debian will require someone to request a sync
[00:49] <EvilResistance> afaik
[00:49] <broder> micahg: actually, i thought it was pushed back further than that...
[00:50] <broder> to the beginning of the rally or so
[00:50] <micahg> broder: that's the 9th :)
[00:50] <broder> oh, stupid calendar just listing the thursdays :)
[00:51] <EvilResistance> out of curiosity
[00:51] <EvilResistance> are these release calendars stored in ical format or something that can be imported into an actual calendar program?
[00:55] <blair> micahg, took your advice, sent another note to the gis team
[01:18] <micahg> blair: good luck, if Debian can get the transition done before feature freeze, I think we can do the syncs/rebuilds, but obviously can't promise
[01:19] <blair> micahg, thanks!
[01:20] <micahg> blair: thanks for driving this, I"m sure others will want it as well
[01:22] <micahg> blair: BTW, second e-mail looks spot on
[01:23] <blair> micahg, thanks
[08:09] <dholbach> good morning
[12:44] <highvoltage> good morning
[13:27] <sagaci> hi
[13:46]  * tumbleweed still seems to be sleeping in a US timezone, so good morning, highvoltage
[13:47]  * Laney used the pub method
[13:47] <tumbleweed> care to expand?
[13:49] <highvoltage> tumbleweed: aparently comsuming some alcahol can mess with your internal clock, so drinking a bit after changing timezone can help you adjust (aparently)
[13:49] <Laney> hah, that was not what i meant
[13:49] <Laney> be in a pub as a means of forcing oneself to stay awake
[13:49] <tumbleweed> forcing myself to stay awake has been working fine
[13:50] <tumbleweed> it's the waking up in the morning that's disastrous
[13:50] <highvoltage> when I travel from US timezone to european I just take a two hour nap en then I'm in sync again
[13:50] <tumbleweed> if I do listen to the alarm clock, the entire day is wasted in a daze. If I don't, I get a productive afternoon
[13:51]  * tumbleweed doesn't have much practice with cross-timezone travel
[16:20] <Laney> tumbleweed: http://paste.debian.net/144171/ if you want some encoding fun
[16:20] <Laney> just merged your branch
[16:40] <tumbleweed> Laney: I just fixed something similar to that
[16:42] <Laney> neat
[16:57] <saimanoj> hello
[16:59] <Laney> tumbleweed: already had that commit :(
[16:59] <Laney> hi saimanoj
[17:00] <saimanoj> hi Laney
[17:00] <saimanoj> tell me something about motu.
[17:01] <Laney> erm, what would you like to know?
[17:01] <Laney> we look after the packages in the 'universe' and 'multiverse' parts of the ubuntu archive
[17:02] <Laney> !motu
[17:12] <tumbleweed> Laney: hrm, it was only an hour ago, or so
[17:13] <Laney> yeah, i got it
[17:13] <Laney> if you mean 94afd1acf7823e0e46f90a5abc11584d83d43276
[17:13] <tumbleweed> yeah
[17:13] <tumbleweed> what timestamp were you dumping since?
[17:13] <Laney> 9:something
[17:20] <tumbleweed> Laney: oh, it was orc_1:0.4.16-1
[17:20] <Laney> yus
[17:20] <Laney> the paste says
[17:20] <tumbleweed> duh
[17:21] <Laney> personally, i blame slomo
[17:21] <tumbleweed> debugging while cooking is not recommended
[17:23] <tumbleweed> http://wiki.python.org/moin/UnicodeEncodeError explains that one nicely
[17:28] <tumbleweed> deb822 looks like it decodes bytestrings to unicode sometimes (but not always)
[17:29] <tumbleweed> hackity hackity hack
[17:30] <Laney> this remains very upsetting
[17:33]  * tumbleweed avoids the urge to debug that properly
[17:33] <tumbleweed> pushed
[17:35] <Laney> nice
[17:36] <Laney> please pull before next time(!)
[17:37] <tumbleweed> ah, you've been busy too
[17:38] <Laney> nah, just synced it up
[19:35] <achiang> barry: ping
[19:35] <barry> achiang: pong
[19:37] <achiang> barry: hey, asking here because unsure where else, feel free to redirect conversation elsewhere if you know. question is -- do you know of a python module that can do AES encryption? i guess it's not part of the stdlib, but maybe something else has been packaged?
[19:37] <barry> achiang: http://sandbox.rulemaker.net/ngps/m2/
[19:38] <barry> achiang: `apt-get install m2crypto` should do it
[19:38] <achiang> barry: awesome, thanks! do you know the license, btw?
[19:39] <achiang> barry: nm, i'll just grab the source and find out myself
[19:39] <barry> achiang: yeah, it looks a little complicated ;)
[19:40] <barry> i.e. not gpl, but gpl compatible
[19:44] <tumbleweed> +1 on m2crypto, it's nice. But all the usual caveats of rolling your own encryption scheme apply
[19:52] <achiang> this is to fix a package i'm packaging for debian
[19:52] <achiang> they have an apache-2.0 file in the rest of their GPL-2 package
[19:53] <achiang> so we need to find an alternative
[19:53] <achiang> an external dependency on m2crypto would solve the issue
[19:54] <ajmitch> it's not GPL 2+ ?
[19:54] <barry> m2crypto?  i don't think so
[19:55] <ajmitch> I meant the package itself, since GPL 3 is compatible with apache license 2.0
[19:56]  * ajmitch came across a package recently when reviewing that had an interesting mix of bundled libraries, with a variety of licenses including apache 1.1, 2.0, GPL2, GPL3 plus many more :)
[19:59] <achiang> ajmitch: the package is GPL-2+, but upstream does not want to move to GPL-3+
[20:00] <ajmitch> awkward
[20:01] <achiang> this package has GPL-2, GPL-2+, Apache-2, Expat, and "Tummy Public License"
[20:01] <achiang> now we're down to just GPL-2+ and Expat, after getting the crypto thing fixed [the crypto bits were apache-2]
[20:01] <ajmitch> expat should be fine, iirc
[20:02] <achiang> yeah, i checked
[20:02] <achiang> expat is fine
[20:02] <ajmitch> trying to explain to upstream why they can't use certain libraries together can be a bit of a challenge
[22:05] <tumbleweed> Laney: breezy successfully imported (only 1 traceback for a missing changelog). Running the rest now.
[23:10] <Laney> woot
[23:11] <tumbleweed> hrm, wasn't there also a bug in the dup-finding code?
[23:26] <broder> tumbleweed: the abstraction boundry that ubuntutools.rdepends is creating seems a bit weird - e.g. i can't get at the fact that bash has a reverse-enhances from autojump from its api
[23:26] <broder> i feel like i wolud want an api function that basically fetches and parses the json then spits it out
[23:32] <tumbleweed> broder: sounds reasonable