[00:00] <bdrung_> (need one night to grab all) :)
[00:00] <bdrung_> xnox: + 1,2 GiB from my ppas
[00:03]  * stochastic throws his hands up in a moment of "I give up" frustration, but thanks bdrung_ for all his help thus far.
[00:03] <bdrung_> yw
[00:05] <bdrung_> stochastic: the problem is that the patch is already applied to this file
[00:06]  * stochastic is new to dpatch and doesn't understand what he's done wrong
[00:09] <bdrung_> stochastic: you could use quilt instead
[00:09] <bdrung_> stochastic: or if you want a very simple patch system, you could use cdbs + simple-patchsys
[00:09] <stochastic> I don't know quilt and the docs said it's much more difficult to setup
[00:09] <stochastic> is there something wrong with dpatch?
[00:10] <bdrung_> stochastic: i don't know if it is dpatch's fault or caused by something else.
[00:15] <stochastic> bdrung_ well I guess i have no other option than to give up on this package
[00:15] <stochastic> bdrung_ thanks anyway
[00:16] <bdrung_> stochastic: if you ask me tomorrow i may digg into this issue
[00:17] <stochastic> dtchen, thanks for adding ubuntu-devel to the Jack in Main discussion
[00:17] <dtchen> stochastic: np
[00:29] <stochastic> bdrung, could you test out the latest upload?
[00:29] <bdrung> yes
[00:32] <bdrung> stochastic: same issue
[00:35] <bdrung> stochastic: remove the autogen.sh call. it is not necessary (the configure file exists)
[00:39] <stochastic> bdrung, removed and uploaded
[00:48] <bdrung> stochastic: i have fixed the rebuild bug (i broke the butterfly on the wheel)
[01:11] <bdrung> Zhenech: got my mail?
[01:28] <sbalneav> Hello.  I'm having a problem working on a package for a backport to hardy.  The upstream tarball requires that I patch up some build requirements in configure.ac and rerun autoconf before the package will build.  Does anyone know the correct debian/rules magic for that?
[01:39] <bdrung> sbalneav: you have to run autoreconf before you run ./configure
[01:40] <bdrung> sbalneav: you may want to use a patch system for the patch
[01:40] <sbalneav> The package itself uses cdbs
[01:41] <sbalneav> have you got an example you could point me at?
[01:42] <bdrung> sbalneav: for autoconf there are some variables, you could set
[01:44] <sbalneav> the configure.ac basically defines a couple of "minimum" package levels.  The package works fine with older versions, so I just need to bump them down.
[01:44] <bdrung> sbalneav: you can set DEB_AUTO_UPDATE_AUTOCONF to the version you want
[01:45] <bdrung> sbalneav: which package?
[01:45] <sbalneav> sabayon.
[01:46] <sbalneav> I've been working getting a version going for karmic, but many people would like a version for hardy.
[01:46] <sbalneav> I'd like to create a backport in my ppa.
[01:51] <bdrung_> sbalneav: try to add "DEB_AUTO_UPDATE_AUTOCONF := 2.61" to your rules file
[01:51] <sbalneav> ok
[06:08] <stochastic> would any motu with a spare minute please glance through http://revu.ubuntuwire.com/p/xjadeo
[06:47] <dholbach> good morning
[07:26] <fabrice_sp> good morning dholbach :-)
[07:26] <dholbach> hiya fabrice_sp!
[07:26] <iulian> Morning dholbach, fabrice_sp.
[07:26] <dholbach> hey iulian
[07:26] <fabrice_sp> good morning iulian
[07:26] <dholbach> looks like we could do a bit of sponsoring before feature freeze :)
[07:27] <iulian> Indeed.
[07:27] <fabrice_sp> speaking about sponsoring :-)
[07:27] <dholbach> yes? :)
[07:27] <fabrice_sp> about bug #416262 : I don't think aptoncd will make his path to Debian before FF, so I propose to update the package in Ubuntu
[07:29] <fabrice_sp> it's the same content as the Debian upload, but the package has not being sponsored yet, and I'm travelling this morning, until 3rd of Sptember (Holidays! :-) )
[07:30] <dholbach> fabrice_sp: nice! enjoy your holidays!
[07:30] <dholbach> where are you going?
[07:33] <dholbach> brb
[07:35] <warner> hey, quick question. dput reported a successful upload of my four packages (foolscap, zfec, pycryptopp, tahoe) to revu.ubuntuwire.com several hours ago, but I'm not seeing them on the REVU "New Packages" list. Is there anywhere I should look to find out about upload errors?
[07:39] <fabrice_sp> dholbach, thanks :-) I'm going to Canary's Island ;-)
[07:41] <dholbach> nice :)
[07:41] <warner> iulian: zooko said I should ping you once the Tahoe packages were uploaded, but I'm not sure if you'll be able to see them yet
[07:43] <iulian> warner: Have you uploaded them to REVU?
[07:44] <warner> yes, in theory, although I'm not seeing them on http://revu.ubuntuwire.com
[07:44] <warner> (dput reported success, to the right server)
[07:44] <iulian> jpds: ^^
[07:45] <iulian> Or any other REVU admin.
[07:46] <warner> the only thing I can think of is that my launchpad email address is slightly different than the package's debian/changelog's top-most address
[07:46] <warner> but they're all signed by the same GPG key that I registered with launchpad this afternoon
[07:47] <iulian> warner: Have you logged in to REVU?
[07:48] <warner> yup, the page says "Logged in as warner." at the top right now
[07:49] <iulian> Hmm, no idea.  You'll have to talk to a REVU admin (already pinged one).
[07:49] <warner> thanks
[07:50] <warner> iulian: do you know offhand if you or zooko filed ITPs for these packages? I don't know how to search launchpad for them (being more familiar with debian, myself). I don't have proper Closes:/LP: entries in the package changelogs yet.
[07:51] <iulian> warner: I cannot remember, sorry.
[07:51] <warner> s'ok, thanks
[07:51] <warner> is there a launchpad ITP page?
[07:52] <lifeless> no
[07:52] <lifeless> its not structurally different to other bugs
[07:52] <lifeless> also ITP is a bit of a buggy concept
[07:53] <lifeless> RFP is sensible, as is REVU, but declaring intent... may as well JFDI
[07:53]  * warner nods
[07:53] <warner> so the "LP:" entry in the changelog is defined as closing an RFP bug as opposed to an "ITP" bug?
[07:54] <warner> and such RFP bugs are to be found.. filed under the submitter's proposed package name?
[07:54] <lifeless> personally, I don't bother having an initial bug to close.
[07:55] <lifeless> https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
[07:55] <warner> great! I'll ignore that lintian warning then :)
[07:55] <lifeless> it says to file one, but like I say.. meh.
[07:56]  * lifeless waits for the flames
[07:56] <warner> I'll quote you when the REVU comments start coming in, then :)
[07:57] <warner> ah, tahoe has a needs-packaging bug filed already, #417136
[07:57]  * warner updates the changelog
[07:58] <lifeless> right, if there is one definitely close it.
[07:58] <warner> and zfec has #289430 ..
[07:58] <lifeless> But creating a bug saying I'm doing X, only to close it a few minutes later is well... nuts.
[07:59] <lifeless> its like writing a note while you do the dishes saying "I'm doing the dishes"
[07:59] <warner> huh, sounds like twitter :)
[07:59] <lifeless> shudder
[07:59] <lifeless> so buildbot. Unit tests.
[07:59] <lifeless> (I do have the right person don't I?)
[08:00] <warner> um
[08:00]  * warner looks shifty
[08:00] <warner> sure, shoot
[08:00] <lifeless> so, have you seen subunit?
[08:01] <warner> nope
[08:01] <lifeless> https://launchpad.net/subunit/
[08:01] <lifeless> project of mine.
[08:01] <warner> cool. should we take this to #buildbot ?
[08:06] <warner> huh, weird that the two needs-packaging bugs have numbers that are so far apart
[08:17] <siretart> any emacs fans around?
[08:17] <lifeless> hahaha
[08:18] <lifeless> oops, did I type that out loud?
[08:18] <siretart> if yes, please package emacs23, using the package from debian before thursday
[08:18] <siretart> lifeless: I bet you did :)
[08:34] <StevenK> siretart: Uh huh, did you even read the sync request bug about emacs23 from Debian?
[08:51] <siretart> StevenK: ups? no. do you have the bug no at hand?
[08:52] <StevenK> siretart: Bug 408085
[08:53] <siretart> thanks
[08:54] <siretart> StevenK: ah, ok. best would probably be not a plain sync, but a hard dependency on the non-dfsg-free docs (they are fsf-free)
[08:55] <StevenK> siretart: Then say so, and deal with the bug
[09:32]  * SiDi is looking for an Ubuntu maintainer for Exaile, please pm me if you want to help. Thanks in advance.
[10:55] <sluimers> I know it's a stupid question but, what does MOTU stand for?
[10:56] <\sh> sluimers: Masters Of The Universe
[10:57] <sluimers> cool, and do they package stuff and put it in the Ubuntu archive? Because that's what it looks like to me.
[10:58] <sluimers> Anyway, I have a little problem and I got sent here.
[10:59] <\sh> sluimers: https://wiki.ubuntu.com/MOTU <- all you need to know about MOTU
[11:02] <bdrung_> stochastic:  i have fixed the rebuild bug (i broke the butterfly on the wheel)
[11:02]  * sluimers reads some more from MOTU
[11:03] <bdrung_> stochastic: here is what i did: http://paste.ubuntu.com/259208/
[11:38] <AnAnt> Hello, what happened to python-xml package ?
[11:41] <iulian> It got removed a long time ago IIRC.
[11:42] <geser> Deleted  on 2009-06-08: obsolete and broken; reverse-deps must be migrated to core python modules. LP: #343242
[11:45] <AnAnt> geser: thanks
[11:47] <AnAnt> ah, the bug is still open
[11:48] <AnAnt> reopened rather
[11:48] <AnAnt> oh, won't fix
[12:01] <AnAnt> ok, python2.6 would do !
[12:01] <AnAnt> thanks
[12:06] <Q-FUNK> hi!  I'd be interested in feedback on MartinEricRacine/UploadRightsApplication especially on how it's supposed to differ from my previous (succesful) application as ubuntu member.
[12:11] <gnomefreak> is there a reason we dont support lexmark hardware?
[12:12] <directhex> lack of drivers, at a guess?
[12:14] <gnomefreak> thier site doesnt have linux drivers that i can see nor tarball so i am pretty much out of luck?
[12:15] <directhex> very likely. how's the printer db on openprinting look?
[12:15] <directhex> some companies are more pro-linux than others with their printers. lexmark stuggle to be pro-windows, let alone anything else
[12:17] <gnomefreak> maybe ill try nspluginwrapper
[12:20] <directhex> nspluginwrapper? i'm not sure how loading 32-bit flash in 64-bit firefox will help
[12:21] <directhex> which model? http://openprinting.org/printer_list.cgi?make=Lexmark suggests about 50% should work
[12:23] <gnomefreak> x6150
[12:24] <gnomefreak> directhex: thanks for the link looking at it atm
[12:25] <gnomefreak> no known scanner drivers :(
[12:31] <gnomefreak> directhex: its not nspluginwrapper sorry wrong thing. i cant recall the name of the package im looking for that will run .exe drivers
[12:32] <directhex> gnomefreak, ndiswrapper. note that "ndis" means "Network Driver Interface Specification"
[12:34] <gnomefreak> directhex: yeah i saw that and i remember that is what i used to set up wifi
[12:39] <james_w> error: plugins/builder/plugins/builder/plugins/builder/plugins/builder/plugins/builder/plugins/builder/plugins/builder/plugins/builder/plugins/builder/plugins/builder/plugins/builder/plugins/builder/plugins/builder/plugins/builder/plugins/builder/plugins/builder/plugins/builder/plugins/builder/plugins/builder/plugins/builder/plugins/builder/plugins/builder/plugins/builder/plugins/builder/plugins/builder/plugins/builder/plugins/builder/plugins/buil
[12:39] <james_w> der/plugins/builder/plugins/builder/plugins/builder/plugins/builder/plugins/builder/plugins/builder/plugins/builder/plugins/builder/plugins/builder/plugins/builder/plugins/builder/plugins/builder/plugins/builder: Too many levels of symbolic links
[12:39] <james_w> oops
[12:42] <soren> Oh, dear :)
[12:43] <soren> directhex: Lexmark used to be /very/ Windows-only, but at some point they started writing and releasing Linux drivers themselves.
[12:44] <soren> directhex: This must have been in 2001-ish.
[12:44] <gnomefreak> soren: sort of
[12:44] <gnomefreak> atleast i cant find the scanner drivers for it i already have too many printers
[12:47] <gnomefreak> i guess im going to use it on wmy win box and just email it to myself
[13:13] <james_w> anybody have a minute for a review of http://revu.ubuntuwire.com/p/lazr.restfulclient ?
[13:13] <james_w> needed for the new launchpadlib
[13:14] <ttx> james_w: about bug 416420
[13:15] <james_w> hey ttx
[13:15] <ttx> james_w: hey :)
[13:15] <ttx> james_w: that sounds like a bad idea because it brings all the new maven-repo-helper infra into main, through eucalyptus
[13:15] <ttx> furthermore version 3 is untested
[13:15] <james_w> feel free to back it out
[13:16] <ttx> james_w: how should I proceed to do that ?
[13:16] <james_w> it was ACKed my a MOTU and looked sane, I don't invest any further than that in sync requests
[13:16] <james_w> depends how much you want to revert
[13:16] <ttx> well, going back to where it was 24 hours ago, is it possible ?
[13:16] <james_w> if you just want to go back to the previous package then you can grab that from lp, increment the version with some sort of "really" version number and upload it
[13:17] <ttx> hmmm
[13:17] <james_w> source package is on https://edge.launchpad.net/ubuntu/+source/backport-util-concurrent/2.2+dfsg-1ubuntu1
[13:18] <ttx> I'll try the middle way, try to see if we can work with the new version and just revert the new maven-repo stuff
[13:18] <ttx> if we can't, I'll play the "really" trick
[13:18] <ttx> james_w: thanks
[13:21] <james_w> np
[13:21] <iulian> james_w: The information from README.txt is already included in HACKING.txt.  Do you want this?
[13:23] <james_w> iulian: you mean the license text?
[13:24] <iulian> james_w: Yup.
[13:24] <james_w> dropped README.txt
[13:26] <iulian> james_w: Go ahead and upload.
[13:26] <james_w> thanks iulian
[13:43] <iulian> Unable to start the settings manager 'gnome-settings-daemon'.
[13:43] <iulian> Without the GNOME settings manager running, some preferences may not take effect. This could indicate a problem with Bonobo, or a non-GNOME (e.g. KDE) settings manager may already be active and conflicting with the GNOME settings manager
[13:43] <iulian> Weird.
[13:44] <iulian> Theme changed automatically and when I tried to set it back I got this message.
[13:51] <geser> james_w: you seems to be missing XS-Python-Version and XB-Python-Version in lazr.restfulclient so it only gets available for python2.6 (see also the depends on python; and the lintian warning)
[14:02] <james_w> thanks geser
[14:03] <geser> james_w: and the \ in "python setup.py install --root=\$(CURDIR)..." looks also misplaced
[14:04] <geser> james_w: and I see now that python is twice in Build-Depends
[14:13]  * hyperair grumbles about liferea being unresponsive and slow
[14:14] <james_w> thanks geser
[14:14] <pochu> hyperair: :(
[14:14] <hyperair> pochu: :(
[14:14] <hyperair> pochu: it seems to like churning up my hard disk and hanging.
[14:17] <pochu> hyperair: 1.6?
[14:19] <hyperair> pochu: ye, 1.6
[14:39] <zooko> iulian: hello!  My partner Brian Warner built Debian packages for Tahoe-LAFS and uploded them to REVU.  :-)
[14:42] <zooko> Time for me to walk my children to school...
[15:00] <jtimberman> Chef and other packages it depends on look to be going into Karmic (uploaded to NEW or already in). Is there a document that describes how to get universe packages backported (I'm willing to do the packaging of course) to LTS and other releases?
[15:01] <ghostcube> fta: when does youre daily build repo get updated normally for songbird
[15:06] <ScottK> !backports | jtimberman
[15:07] <bddebian> Heya gang
[15:08] <ScottK> Heya bddebian.
[15:08] <bddebian> Hi ScottK
[15:09] <sistpoty|work> hi bddebian
[15:11] <bddebian> Heya sistpoty|work
[15:26] <lfaraone> Hey, if a MOTU acks a sync request, why does it still need to be manually reviewed by a Archive Admin?
[15:27] <james_w> what do you mean?
[15:27] <geser> lfaraone: not reviewed, but processed
[15:27] <james_w> it's a manual process of processing them
[15:27] <james_w> and that involves checking that it has an ACK etc.
[15:27] <lfaraone> james_w: would it be difficult to create criteria that would make it automagic?
[15:27] <james_w> and sometimes you spot something, and surely it's better to comment then?
[15:27] <james_w> yeah
[15:28] <james_w> the fact that LP doesn't support syncing entirely within LP yet
[15:28] <jtimberman> manual process of uploading i recall is deliberate.
[15:28] <jtimberman> at least from the debian side.
[15:28] <lfaraone> james_w: Well, "if reporter is in MOTU and report is assigned to AA, and is set by member of MOTU to "confirmed""...
[15:28] <james_w> you could cron it, but as we are using bugs there are too many corner cases...
[15:30] <james_w> lfaraone: what about the process bothers you?
[15:30] <SiDi> Noob question : if i'm packaging an plugin from an app X that is python based, should i add python to the plugin's deps, knowing that it already depends on X ?
[15:30] <RoAkSoAx> ivoks, you busy?
[15:31] <lfaraone> james_w: well, it seems to be inefficient, and I suffer from impatience. (such mundane tasks should, imho, be automated)
[15:31] <lfaraone> SiDi: Yes.
[15:31] <james_w> lfaraone: yes, they should, and there is work underway to do so
[15:36] <ivoks> RoAkSoAx: yes
[15:40] <SiDi> lfaraone, okey, thanks
[15:40] <lfaraone> james_w: Okay.
[15:43] <JontheEchidna> POX_: ping
[15:43] <POX_> JontheEchidna: You sent me a contentless ping.  This is a contentless pong.  Please provide a bit of information about what you want and I will respond when I am around.
[15:43] <JontheEchidna> heh
[15:44] <JontheEchidna> POX_: Hey, seems kadu ftbfs with the latest gcc. I found a patch here that should fix it: http://starowa.one.pl/~uzi/kadu/kadu-gcc44.patch
[15:44] <JontheEchidna> google-translated forum post: http://tinyurl.com/lkthqq
[15:50] <mpt> Hi folks. Is there a bug tag already being used for packages that have unhelpful summaries or descriptions?
[15:50] <mpt> And if not, what would be a good name for this tag? :-)
[15:51] <james_w> mpt: https://wiki.ubuntu.com/Bugs/Tags
[15:51] <james_w> so no, apparently not
[15:52] <mpt> apart from 'string-fix', tangentially
[15:52] <james_w> that would work
[15:52] <mpt> and 'desktop-file', for applications
[15:53] <james_w> though it may be more of "rewrite the description" rather than "it should be theirs and not there's"
[15:53] <Hobbsee> mpt: 'unhelpful' would be a good name, but i'm sure that's not PC ;)
[15:53] <james_w> why not?
[15:53] <james_w> "unhelpful-description" if you want to avoid every bug being tagged that :-)
[15:54] <mpt> Actually I was thinking of spelling/grammar/layout errors as well
[15:54] <Hobbsee> james_w: something about not being positive enough
[15:55] <james_w> mpt: string-fix would seem to be appropriate then
[15:55] <mpt> "description" would be a bit too specific, but "metadata" would be too vague
[15:55] <james_w> I thought you were looking more specifically
[15:55] <sistpoty|work> huhu siretart, I already found a sponsor, DktrKranz will make use of his new DD powers :)
[15:56] <siretart> DktrKranz: congrats :-)
[15:56] <siretart> sistpoty|work: :-)
[15:58] <DktrKranz> siretart: thanks :)
[15:58] <DktrKranz> I'm not the only MOTU to cheer ;)
[15:59] <DktrKranz> sistpoty|work: btw, if you're in a hurry, please go ahead :)
[15:59] <sistpoty|work> DktrKranz: no, I'm not in a hurry :)
[16:01] <POX_> JontheEchidna: kadu should work fine with GCC 4.4 since 0.6.5.2-2 (dunno what version Ubuntu has). BTW: patryk is now a DD so I no longer sponsor kadu
[16:01] <Laney> what are we congratulating DktrKranz for?
[16:01] <POX_> please ask for a sync with Debian
[16:01] <POX_> Laney: he's a DD now
[16:02] <porthose> DktrKranz, congrats! :)
[16:02] <DktrKranz> do not forget pochu, he's DD too
[16:02] <Laney> oh, nice!
[16:02] <sistpoty|work> congrats, pochu!
[16:02] <directhex> and direc, no, wait :(
[16:03] <Laney> sponsor stuff plz
[16:03] <directhex> yeah, DktrKranz is the new debian mono & haskell sponsor!
[16:03] <pochu> sistpoty|work, Laney: ty!
[16:03] <sistpoty|work> directhex: maybe mono gets you penalties in NM :P
[16:03] <slytherin> for person in motu_list if DD=yes then congratulations. :-)
[16:04] <DktrKranz> directhex: haha
[16:04] <directhex> sistpoty|work, i'd need to check the list of current front desk people to know how much reality matches that
[16:04] <sistpoty|work> heh
[16:04] <Laney> schestow...oh crap
[16:04] <slytherin> dholbach: ping
[16:05] <DktrKranz> porthose: thanks
[16:05] <DktrKranz> :)
[16:05] <RoAkSoAx> congrats DktrKranz
[16:06] <DktrKranz> hey RoAkSoAx, thanks
[16:06] <dholbach> slytherin: pong
[16:06] <jbernard__> does anyone have some time to revu libcgroup (http://revu.ubuntuwire.com/p/libcgroup)?
[16:06] <DktrKranz> RoAkSoAx: btw, advocated lekhonee
[16:07] <slytherin> dholbach: ttf-indic-fonts needs a merge. One of the fonts have been deemed non-free and removed from the package. I would do it myself but I do not have good understanding of package structure.
[16:07] <sebner> DktrKranz: congratulations! mauahahahaha
[16:07] <RoAkSoAx> DktrKranz, yeah I saw it, thanks a lot!! I'm on my search for another advocator :)
[16:07] <dholbach> slytherin: hum... can you have a chat with ArneGoetje about that?
[16:07] <slytherin> Via email?
[16:08] <dholbach> as he's based in Taiwan he might be off the internet now
[16:08] <slytherin> DktrKranz: Congrats.
[16:08] <slytherin> dholbach: I will try the merge on weekend then.
[16:08] <DktrKranz> sebner: thanks, but no need a topic for that (and you forgot emilio, btw)
[16:08] <JontheEchidna> POX_: We synced -4, still fails
[16:08] <dholbach> slytherin: super, thanks
[16:09] <JontheEchidna> POX_: thanks for the heads up about maintainership, tho
[16:10] <sebner> DktrKranz: your idea, your fault :P  emilio?
[16:10] <Laney> so yeah
[16:11] <Laney> about goocanvasmm in pkg-gnome svn... ;)
[16:11] <DktrKranz> sebner: my idea? :P... pochu is DD too
[16:11] <sebner> DktrKranz: Oh really? I have to send new emails too to the dev-lists :P
[16:11] <DktrKranz> LOL
[16:13] <dholbach> congrats DktrKranz
[16:13] <pochu> sebner: no need for it :)
[16:14] <sebner> pochu: upps, just sent the mails :P Congrats also from me
[16:15] <pochu> thanks :) hope to see you in the queue at som epoint ;)
[16:15] <sebner> pochu: too late :P
[16:15] <pochu> DktrKranz: you're released! \o/
[16:15]  * cody-somerville hugs pochu and DktrKranz.
[16:16] <DktrKranz> sebner: I have to find a good hideout now :)
[16:16] <sebner> pochu: DM at some point this year
[16:16] <sebner> DktrKranz: yeah, mail replies are starting \o/
[16:16] <pochu> sebner: party, yohoo!
[16:16] <RoAkSoAx> congrats pochu
[16:17] <Laney> I never saw the mail on debian-newmaint
[16:17] <Laney> where was it announced?
[16:17] <pochu> topic> http://qa.ubuntuwire.com/ftbfs/ . Luca Falavigna (DktrKranz) and Jaunty is released
[16:17] <pochu> maybe it's not yet
[16:17] <Laney> alreet
[16:17] <DktrKranz> Laney: you got a welcome mail once your account is created
[16:17] <DktrKranz> *get
[16:18] <Laney> ah
[16:18] <DktrKranz> s/welcome/2_pages_long_here_what_you_have_do_to/
[16:18] <iulian> DktrKranz, pochu: Congratulations.
[16:19] <DktrKranz> thanks dholbach iulian!
[16:19] <pochu> thanks guys
[16:20] <DktrKranz> pochu: they probably mean s/thanks/sponsor me something/ :)
[16:21] <pochu> =)
[16:21] <Laney> thanks, now get to work reviewing my packages!
[16:22]  * Laney cracks the whip
[16:22]  * sebner asks himself if he should change the topic to: New Debian Sponsors: pochu and DktrKranz :O
[16:30] <sistpoty|work> sebner: can you sanitize and clean up the topic a little bit, now that you're the last one you touched it? (e.g. you could mention that we're all doomed, err that FF starts on Thursday)
[16:31] <sebner> sistpoty|work: haha! uiuiui, really doomed. I'm sorry
[16:31] <sistpoty|work> sebner: just guessing on the rate of "just before feature freeze" breakage :P
[16:32] <Laney> topic is a bit of a mess isn't it
[16:32] <sistpoty|work> excellent!
[16:32] <sistpoty|work> thanks sebner
[16:33] <sebner> sistpoty|work: thanks for the hint. /me was just too excited xD
[16:33]  * DktrKranz can now hide
[16:33] <sistpoty|work> sebner: sure, no problem, I just thought that also the old topic could need cleanup :)
[16:34] <Laney> Jaunty is released?
[16:34] <sebner> sistpoty|work: 2 Fliegen mit einer Klappe ^^
[16:34] <Laney> old news int it?
[16:34] <sebner> Laney: still the actual release though
[16:34] <sebner> and we want SRU'S
[16:35] <Laney> don't think it's topic worthy
[16:36]  * sebner hides now
[16:37]  * Laney wonders why that links is in the topic at all
[16:37] <Laney> seems only motu-sru would want to use it
[16:37]  * sebner didn't set it :)
[16:37] <Laney> infact both of the main links go to a blank page
[16:38]  * Laney would link to sponsor queue, debcheck, uehs
[16:38] <sistpoty|work> Laney: just do it :P
[16:38] <Laney> I somehow broke my irssi
[16:38] <Laney> so I can't tab complete the topic
[16:41] <Laney> rawr
[16:43] <iulian> Looks better now.
[16:48] <Riddell> kklimonda: ping
[16:49] <Riddell> kklimonda: you uploaded a SRU for zabbix?  there's no patch on the bug report and no motu-sru approval
[16:49] <dholbach> mok0: bug 271260 :)
[16:49] <dholbach> mok0: didn't know there was somebody interested in packaging sahana as well
[16:54] <kklimonda> riddell: hmm.. there were two similar bugs and I think I have prepared a single debdiff that fixed both of them.
[16:55] <Riddell> kklimonda: the only thing in the changelog is "  * debian/zabbix-server-{mysql,pgsql}.zabbix-server.init: - Create pid directory in /var/run on start (LP: #172775)"
[16:56] <Riddell> and indeed that's the only change in the debdiff
[16:56] <kklimonda> riddel: oh, wait - i have no upload rights so i havent uploaded it. ;)
[16:59] <kklimonda> i don't know what got uploade to be honest as I'm out of town for the last week or so. I remember getting an email from LP about it and that's it. if you could say what's wrong I'd appreciate it. :)
[17:02] <james_w> is there a special procedure for transferring a conffile from one package to another?
[17:07] <Riddell> kklimonda: what's wrong is the lack of patch or motu-sru approval on bug 172775
[17:09] <james_w> no, not any more apparently
[17:09] <Riddell> kklimonda: looks like Devid Antonio Filoni <d.filoni@ubuntu.com> uploaded it
[17:10] <kklimonda> riddel: i agree that i should probably attach patch to both bugs, i thoght that as they are similar it would be easier to work on both of them in one bug.
[17:11] <Riddell> kklimonda: I have no idea what the other bug is
[17:12] <kklimonda> as for the lack of sru ack I kow about it, I was talking with on of motu-sru guys about it but hwe had some concerns and then had to go before i've managed to explain them. But I haven't uploaded them myself, actually I wouldn't do it without a sru ack.
[17:14] <Riddell> kklimonda: so what is this other bug which is so similar?
[17:14] <kklimonda> bug 96644
[17:16] <Riddell> kklimonda: right, that's what I need to know.  I'll accept the package
[17:16] <geser> kklimonda: according to the signature it was "Devid Antonio Filoni" who uploaded your changes
[17:17] <prefrontal> is there any chance that i can get my package into karmic?
[17:17] <prefrontal> or should i not even try getting into the game this late
[17:29] <bdrung> how can i set the default key for signing debian packages?
[17:31] <slytherin> prefrontal: it depends on the state of package. feature freeze is on 27th August.
[17:31] <slytherin> bdrung: set environment variable DEBEMAIL to the email address of your key.
[17:32] <bdrung> slytherin: i have two key that fit the DEBEMAIL
[17:32] <slytherin> then I don't know the solution.
[17:32] <jmarsden> bdrung: /etc/devscripts.conf I think
[17:33] <jmarsden> DEBSIGN_KEYID=whatever
[17:33] <slytherin> bdrung: DEBSIGN_KEYID
[17:34] <prefrontal> slytherin, alright i will give it a shot.. and try to make it perfect ;)
[17:37] <bdrung> jmarsden: thanks, that works.
[17:37] <jmarsden> bdrung: No problem.
[17:45] <jbernard__> i uploaded libcgroup (http://revu.ubuntuwire.com/p/libcgroup) to REVU, if anyone has some cycles to review it I'd be very grateful
[18:04] <Riddell> jtimberman: chef should point to /usr/share/common-licenses/Apache-2.0 in its copyright file
[18:06] <jtimberman> Riddell: is that blocking?
[18:06] <Riddell> jtimberman: no I've accepted it
[18:06] <Riddell> but fix it for next upload
[18:06] <jtimberman> Riddell: Definitely! Thank you.
[18:07] <jtimberman> Riddell: Won't be long, we're preparing to release 0.7.10 "soon" :-)
[18:46] <fta> ghostcube, daily :)
[18:47] <fta> ghostcube, ... about 5pm UTC
[18:48] <ghostcube> fta, last update is from saturday
[18:49] <ghostcube> thats why i asked about :)
[18:50] <ghostcube> cause ff anbd tb are pushing dailies into my apt but not songbird heh maybe anything changed ?
[18:55] <fta> ghostcube, probably
[18:55] <fta> songbird 1.4.0~a~svn20090822r14624 vs songbird 1.4.0~a~svn20090822r14624
[18:55] <fta> No new src snapshot. Skip
[18:55] <fta> so yes, no upstream change
[18:57] <fta> ghostcube, but i will probably stop & orphan it. i'm no longer using it and i don't have time to properly maintain it
[18:58] <ghostcube> fta, ok no prob just wanted to mention :)
[19:00] <fta> debian was supposed to take over, they didn't
[19:00] <fta> bug 94494
[19:00] <fta> hm, debian 412437
[19:02] <ghostcube> oo
[19:03] <ghostcube> not possible to get it to experimental ppa from the devel guys ?
[19:03] <ghostcube> i mean you have the build up so they could take it
[19:03] <ghostcube> ScottK, would thgis be possible
[19:22] <stochastic> bdrung, changes pushed to revu
[19:23] <stochastic> can any motu with a spare minute and a kind heart look over http://revu.ubuntuwire.com/p/xjadeo (I'd love to make feature freeze)
[20:09] <josephpiche> not sure where to ask this, but I would like to use launchpad for a stale gpl'd project I will be taking over and co-maintaining with someone, but I'm wondering if launchpad has mailing-lists?
[20:12] <xnox> josephpiche: wrong chanell =) try #launchpad. And yes it does. It is part of teams feature - that is a team can have a mailing list =)
[20:12] <josephpiche> oh, sorry, thanks
[20:26] <zooko> Hey folks, is there something else that I need to do to get Tahoe-LAFS reviewable on REVU?  https://bugs.launchpad.net/allmydata.org/+bug/417136/comments/3
[20:41] <bdrung> stochastic: you have to add cdbs as build dependency and you can drop autoconf (because we do not run autogen any more)
[20:41] <stochastic> bdrung, fixing that now.  Thanks.
[20:42] <bdrung> stochastic: and you should apply this: http://paste.ubuntu.com/259463/
[20:42] <bdrung> (wrong patch direction)
[20:42] <stochastic> bdrung, but the licenses are for version 2 or at your option, any later version
[20:43] <stochastic> we discussed this and you said the lintian warning can be ignored
[20:44] <bdrung> stochastic: one file is v2 only and therefore is the complete package v2 only
[20:46] <bdrung> stochastic: in http://dep.debian.net/deps/dep5/ they use the lowest allowed version
[20:46] <stochastic> bdrung, debuild is giving me this lintian warning now: E: xjadeo source: no-architecture-field
[20:46] <bdrung> e.g.
[20:46] <bdrung>     License: GPL-2+
[20:46] <bdrung>      On Debian systems the full text of the GNU General Public
[20:46] <bdrung>      License can be found in the `/usr/share/common-licenses/GPL-2'
[20:46] <bdrung>      file.
[20:46] <james_w> zooko: did they first log in to REVU?
[20:46] <stochastic> bdrung, okay, I've changed the GPL line
[20:46] <james_w> zooko: doing that makes it import the key so that uploads can be checked against it
[20:46] <RainCT> Hey
[20:47] <james_w> zooko: if yes, then the usual issue is a mistake in signing
[20:47] <bdrung> stochastic: aha, that was the problem. you need a empty line in the control file after the build-depends
[20:47] <RainCT> Can sb remind me whether FF starts *the* 27th or *after* the 27th?
[20:47] <bdrung> (to seperate the source part from the binary part)
[20:47] <james_w> RainCT: at the start of IIRC
[20:48] <james_w> i.e. ~28 hours from now
[20:48] <RainCT> Oh, so only one day remaining
[20:48] <RainCT> ok thanks
[20:48] <sebner> james_w: I thought at the end. As long as somewhere on earth is 27th August. Or was is 26th? Anyways, something with somewhere on earth ^^
[20:49] <bdrung> stochastic: i prefer having one build-dependency per line (so it is easier if you have patches), but thats up to you
[20:49] <james_w> sebner: that's the release :-)
[20:49] <sebner> james_w: right, but I'm sure we did that for FF at some point in the past
[20:49] <RainCT> btw, how do I set a spec as postponed?
[20:49] <stochastic> bdrung, is there any chance this is going to make Feature Freeze?
[20:49] <sebner> james_w: as long as it's before FF somewhere on earth new upstream releases can swim in
[20:50] <bdrung> stochastic: if you find a motu, then yes.
[20:50] <warner> james_w: I'm the tahoe uploader.. yes, I'm pretty sure that I first logged into REVU. I know I'm logged in now. It there any way to check that REVU picked up my GPG key from launchpad?
[20:50] <james_w> hi warner
[20:50] <james_w> a revu admin could perhaps do it
[20:50] <james_w> warner: try the upload again now
[20:50] <warner> ok
[20:50] <stochastic> james_w do you have time to do a revu of a package?
[20:51] <james_w> "dput -f revu whatever_source.changes"
[20:51] <warner> -f, right
[20:51] <james_w> stochastic: maybe later
[20:51] <RainCT> warner: what's the problem?   /me is a REVU admin
[20:51] <james_w> stochastic: what does the package do?
[20:51] <james_w> the more interesting the more likely :-)
[20:51] <warner> RainCT: four packages I uploaded (successfully, it appeared) yesterday didn't show up on the REVU web page
[20:51] <stochastic> james_w, it's a video player that syncs with the Jack audio server to allow soundtrack editors to watch their music in sync with the video
[20:52] <bdrung> stochastic: here you have the lintian warning:
[20:52] <bdrung> N:    For example, if the package says something like "you may redistribute it
[20:52] <bdrung> N:    and/or modify it under the terms of the GNU General Public License as
[20:52] <bdrung> N:    published by the Free Software Foundation; either version 2, or (at your
[20:52] <bdrung> N:    option) any later version", the debian/copyright file should refer to
[20:52] <bdrung> N:    /usr/share/common-licenses/GPL-2, not /GPL.
[20:52] <warner> re-uploading "tahoe-lafs" now
[20:52] <RainCT> warner: which ones?
[20:52] <warner> tahoe-lafs, python-foolscap, python-zfec, python-pycryptopp
[20:52] <stochastic> bdrung, already fixed it and uploaded
[20:52] <james_w> stochastic: ok, I'll see if I have time
[20:52] <POX_> warner: why didn't you ask me to check them?
[20:52] <warner> POX_: I didn't see you around :)
[20:53] <stochastic> james_w, thanks.
[20:53] <bdrung> stochastic: do you want to maintain this package in debian, too?
[20:53] <warner> POX_: I've got a git-buildpackage archive for all four if you'd like a copy
[20:53] <POX_> warner: just send me RFS mail (as described on the ~piotr/sponsor page)
[20:53] <stochastic> bdrung, maybe, I'm not too familiar with debian maintenance though
[20:53] <RainCT> bdrung: Er.. Isn't it /GPL-2 when it's "version 2" (without "or later") and either GPL-X or just /GPL at your option when it's "or later"? (that's how I do it)
[20:54] <warner> POX_: ok, will do. Is that for inclusion in debian or ubuntu? (zooko told me about the upcoming ubunbtu freeze, so I've been focussing on that)
[20:54] <POX_> warner: about python-pycryptopp - ping zooko (he's the Debian maintainer, no? :)
[20:54] <warner> :)
[20:54] <bdrung> RainCT: not any more. the current lintian want versioned gpl links in both cases
[20:54] <POX_> that's about Debian only (but then I know who to ask to have it in Ubuntu)
[20:54] <RainCT> warner: no error for any of those here
[20:54] <warner> tahoe-lafs reuploaded, now doing foolscap/zfec/pycryptopp
[20:55] <RainCT> bdrung: grr, I'll file a bug against it then! :P
[20:55] <bdrung> :)
[20:55] <warner> RainCT: huh, I don't see "tahoe" on http://revu.ubuntuwire.com/ , nor on my profile page http://revu.ubuntuwire.com/u/warner
[20:55] <bdrung> RainCT: this is the statement from lintian:
[20:55] <bdrung> N:    The copyright file refers to the versionless symlink in
[20:55] <bdrung> N:    /usr/share/common-licenses for the full text of the GPL, LGPL, or GFDL
[20:55] <bdrung> N:    license. This symlink is updated to point to the latest version of the
[20:55] <bdrung> N:    license when a new one is released. The package appears to allow
[20:55] <bdrung> N:    relicensing under later versions of its license, so this is legally
[20:55] <bdrung> N:    consistent, but it implies that Debian will relicense the package under
[20:55] <bdrung> N:    later versions of those licenses as they're released. It is normally
[20:56] <bdrung> N:    better to point to the version of the license the package references in
[20:56] <bdrung> N:    its license statement.
[20:56] <Laney> pastebin please
[20:56] <bdrung> ok, next time
[20:56] <RainCT> warner: are you sure you uploaded to REVU?
[20:57] <warner> Uploading to revu (via ftp to revu.ubuntuwire.com):
[20:57] <warner>   Uploading zfec_1.4.5-1.dsc: done.
[20:57] <warner> ..
[20:57] <warner> Successfully uploaded packages.
[20:57] <warner> looks like it :)
[20:57] <RainCT> bdrung: so why isn't that an informational warning? they may prefer to do it their way but it's not the lintian maintainer's choice how I'm going to distribute packages :P
[20:58] <warner> I am doing this from a sid box, however. But I added the recommended stanza to my ~/.dput.cf
[20:59]  * RainCT adds to his todo-when-i'm-back-home: "be angry with the lintian guys" :P
[20:59] <RainCT> warner: ah, you've uploaded the _i386.source
[20:59] <warner> I built the packages on a (remote) karmic box, copied them back to my (home) sid system, debsign'ed them, then dput'ed them
[20:59] <bdrung> RainCT: it's pedantic
[21:00] <RainCT> bdrung: Ah, thought I'd be I: then. No complaints then :)
[21:00] <RainCT> warner: instead of _source.changes
[21:00] <warner> RainCT: zfec and pycryptopp are arch-specific, tahoe and foolscap are not. I *was* wondering why I wound up with "_i386.changes" for everything.. seemed weird.
[21:00] <RainCT> warner: you need to  debuild -S -sa,  then you'll get a _source.changes files
[21:01] <warner> RainCT: does that imply something funny in the way I'm building these files? It didn't create a _source.changes file
[21:01] <warner> ah, ok
[21:01] <stochastic> bdrung, is that last comment on http://revu.ubuntuwire.com/p/xjadeo valid?  I thought the new way of doing things was to say Ubuntu-Developers not Ubuntu-MOTU?
[21:01] <RainCT> you get a _<arch>.source when you build the .deb
[21:01] <bdrung> stochastic: it's invalid / outdated. so ignore it :)
[21:01] <RainCT> and I should really change REVU to  long an error when someone uploads that (or maybe even fix it to work with such updates)
[21:02] <warner> RainCT: ah, I see, so I don't need to build .debs at all (for REVU's purpose), just the source package
[21:02] <RainCT> warner: right
[21:02] <warner> ok, I'll spin up my karmic box and rebuild.. should be re-uploaded within the hour
[21:02] <warner> thanks!
[21:02] <RainCT> warner: wait, don't worry
[21:02] <warner> ok
[21:03] <RainCT> I've just seen that renaming the file to _source it works fine :)
[21:03] <RainCT> so I'll just do that for you ;)
[21:03] <warner> cool :)
[21:06] <warner> two of the packages have ITP bugnumbers that should be added, and they all have -1 version numbers (instead of the -0ubuntu1 that I see elsewhere)
[21:06] <warner> sometime this afternoon I'll update those
[21:09] <RainCT> even better:   508 Siegfried-Angel Gevatter Pujals   2009-08-25 Process any .changes file instead of only _source ones. TODO: Remove the leftover .deb files.
[21:09] <RainCT> _<arch>.source uploads to REVU work now :)
[21:15] <Laney> pre-ff sponsor queue review anyone?
[21:16] <ghostcube> hi folks https://bugs.launchpad.net/ubuntu/+source/xine-lib/+bug/152487
[21:16] <ghostcube> is there any news about this
[21:21] <RainCT> (ok and .deb files are removed now.. hope I didn't break anything :))
[21:23] <stochastic> ghostcube, wrong channel, ask in #ubuntu-bugs, but yes, there is a movement to get Jack into main (and thus allow xine to compile against it).  see bug #416778 and add your comments to the listed discussions
[21:25] <ghostcube> stochastic, thx
[21:27] <zooko> What's the question for the Debian pycryptopp maintainer?
[21:27] <warner> uploading new tahoe-lafs and zfec packages now (added ITP, changed version to -0ubuntu1, upload _source.changes instead of _i386.changes)
[21:28] <zooko> warner: :-)  :-)  :-)
[21:31] <ghostcube> stochastic, i posted this not beacuse of the bug only because i thought motus may know what changes in the main and universe repo :)
[21:31] <ghostcube> but thx for th elinks i read them and all i would say in my bad english is already written there in a very good english :)
[21:33] <james_w> Laney: how about a REVU instead?
[21:34] <warner> RainCT: so, if I'm doing 'debuild -S -sa', does that mean that I won't get lintian reports on problems in the .deb (because it didn't build one)?
[21:34]  * Laney whines
[21:34] <Laney> which package?
[21:34] <james_w> bzr-builder
[21:34] <james_w> small bzr plugin written by me
[21:34] <james_w> I can find someone else if you would rather not
[21:35] <Laney> nah I'll do it
[21:37] <james_w> ah, helps if I actually dput
[21:37] <stochastic> if Laney is doing REVUs I want in!
[21:37] <stochastic> ;)
[21:38] <Laney> I owe james_w lots of favours!
[21:38] <RainCT> warner: right
[21:42] <warner> RainCT: so I should probably build without -S, separately, to learn about lintian problems with the .deb, right?
[21:42] <james_w> stochastic, jbernard__: done
[21:43] <stochastic> james_w, thanks, making that change now.
[21:44] <RainCT> warner: Yeah. Well, actually you should build the .deb using some chroot (pbuilder/cowbuilder/whatever. I recommend checking out pbuilder-dist/cowbuilder-dist from ubuntu-dev-tools) to see whether the build dependencies et all are correct
[21:45] <Laney> man
[21:45] <Laney> I kind of wish I went to Forest
[21:45] <stochastic> james_w, changes uploaded
[21:48] <warner> RainCT: yeah, I'm slowly working on a pbuilder setup (I'm using an EC2 host, since I don't have a karmic box at home, so the process is moving somewhat slowly)
[21:48] <Laney> :O
[21:49] <RainCT> warner: You don't need a Karmic box for a Karmic pbuilder. That's what's so cool about chroots!
[21:49] <RainCT> warner: "pbuilder-dist karmic create" - (wait up to a couple hours depending on connection speed) - there you go
[21:50] <warner> does sid know how to do that?
[21:51] <james_w> I believe so
[21:51] <RainCT> warner: Yeah I think I got pbuilder-dist working there. You'll just have to pull it yourself from http://bazaar.launchpad.net/~ubuntu-dev/ubuntu-dev-tools/trunk/files
[21:51] <warner> ok, I'll give it a try
[21:51] <Laney> james_w: do you mean to have that setup.py change in the diff?
[21:52] <james_w> yeah, brown paper bag :-)
[21:52] <james_w> I made the tarball from the revision before I committed the version number change
[21:52] <Laney> fun
[21:52] <james_w> I can release a 0.1.1 if you really want
[21:53] <Laney> no it's not a problem at all
[21:53] <Laney> just checking you meant it
[21:54] <warner> what do I do to pull that, 'bzr clone http://../ubuntu-dev-tools' ?
[21:54] <zooko> warner, POX: did you have a question for me as the Debian maintainer of pycryptopp?
[21:54] <Laney> warner: bzr branch lp:ubuntu-dev-tools
[21:54] <warner> Laney: thanks
[21:54] <POX_> zooko: yes, your package is outdated in Debian
[21:55] <POX_> new upstream release is available, didn't upstream tell you? ;)
[21:55] <zooko> :-)
[21:56] <POX_> zooko: I think you (as upstream) should slap yourself (as Debian maintainer)! ;)
[21:56] <zooko> Heh heh heh.
[21:57] <zooko> So, I'm letting myself off easy, because the only changes to upstream are irrelevant to Debian, as they have to do with the "included bundled convenience copy" of Crypto++, which Debian of course doesn't use.
[21:57] <zooko> Hm, but there actually is a serious issue here.
[21:57] <warner> tahoe-1.5.0 requires a newer version
[21:57] <zooko> The Crypto++ library in Debian has a bad bug if used on ARM architecture.
[21:57]  * zooko looks for a bug report about that.
[21:58] <zooko> Right, so the reason that Tahoe-1.5.0 requires the new version is in case someone is using the build of pycryptopp which uses its own bundled copy of Crypto++ (and they are on ARM architecture).
[21:58] <zooko> I can see that it would be nice if I uploaded a new pycryptopp to Debian.
[21:59] <zooko> I would need a big of hand-holding from POX or warner to accomplish that...
[21:59] <zooko> At the same time, perhaps we could patch Tahoe-LAFS itself to accept pycryptopp-0.5.14 in Debian?
[21:59] <POX_> zooko: I will help you tomorrow (you can start with "dch -v 0.5.15-1 -m 'New upstream release'") as I'm working on phatch right now (with stani)
[22:00] <stani> sorry zooko ;-)
[22:00] <zooko> POX: thanks!  I'm available around 5:30 UTC-6 until around 7:00 UTC-6 and then around 17:30 UTC-6 to around 21:00 UTC-6 on weekdays.
[22:00] <warner> hm, you mean make the debian patch for tahoe-1.5.0 downgrade the dependency? Not sure if the debian/ubuntu world considers that reasonable or not.
[22:00] <zooko> warner: what do you think of relaxing the requirement?
[22:01] <zooko> It seems reasonable to me in this case because the only reason for "pycryptopp >= 0.5.15" is the bug in the included convenience copy of Crypto++.
[22:01] <warner> zooko: I've got an updated pycryptopp package for jaunty and karmic, and I can have a good one for sid by the end of the day (using the "rip out most of setup.py/setup.cfg" technique I wrote about yesterday)
[22:01] <zooko> Although I guess this should really be fixed by specifying Crypto++ >= 5.6.0 as a *build* dependency for pycryptopp!
[22:01] <zooko> warner: that would be great!  Also I would love to get some more education from you on how that is done.
[22:02] <warner> zooko: I wouldn't object to relaxing the requirement, but it feels slightly weird to have the dependencies be non-monotonically increasing. But yeah, the "right way" is to bump the build dependency. I believe it's possible to specify different required versions for different architectures, which might capture the requirement better.
[22:02] <warner> I'll send you mail about the process once I figure it out for myself :)
[22:03] <zooko> That would be interesting -- if on ARM or other CPU without non-aligned load-store, we require Crypto++ >= 5.6.0 as a build-dep.
[22:03] <zooko> Else, we require Crypto++ >= 5.5.2 or so.
[22:03] <warner> might make it easier to build for some folks, or on older releases, or something
[22:03] <warner> might just be noisy
[22:03] <zooko> And, once that build-dep is specified for pycryptopp, then in my opinion Tahoe-LAFS on *Debian/Ubuntu* should require pycryptopp >= 0.5.14.
[22:04] <POX_> Debian has libcrypto++ 5.6.0-3 so if you need it, just add versioned build dependency
[22:04] <stochastic> james_w you wouldn't be able to take another look on revu now that the changes you requested have been made, would you?  (let me know if I'm pestering too much)
[22:07] <Laney> james_w: Looks good. Newer standards-version and maybe consider team maintenance/packaging if you want
[22:07] <Laney> and I can't find anything about pycompat but that might be me
[22:08] <Laney> happy for you to go ahead
[22:09] <warner> I guess I should set Maintainer: to ubuntu-motu@lists.u.c, and add myself as an XSBC-Original-Maintainer, yeah?
[22:10] <Laney> ubuntu-devel-discuss now, I think
[22:10] <warner> ok, thanks
[22:40] <c_korn> is there a way to execute the config file of debconf if a package is updated ?
[22:40] <c_korn> or removed and reinstalled (not purged)
[22:40] <james_w> thanks Laney
[22:41] <Laney> no worries
[23:15] <LLStarks> hi
[23:47] <stochastic> james_w, thanks.