=== jrib is now known as Guest71999
=== paul__ is now known as Elbrus
=== Bodsda_ is now known as Bodsda
=== bambee_ is now known as bambee
[10:53] <hakermania> Hello there, when trying to compile my application to the testing ubuntu 11.10 oneiric I face this bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=624950 ... which is from Mon, 2 May 2011, 2 months old... So, in the end it says 'the patch has been integrated to SVN trunk.', which means that it should be the fix in the newest version, right? I hope I post in the right channel
[10:53] <ubottu> Debian bug 624950 in libcv-dev "libcv-dev: error: 'ptrdiff_t' does not name a type" [Serious,Fixed]
[10:54] <hakermania> Yes :) thanks ubottu (bot, right :P ?) It is fixed, but is it released?
[10:59] <jtaylor> yes fixed in debian
[10:59] <jtaylor> but that version does not seem to be in ubuntu yet
[11:00] <jtaylor> on the other hand it was fixed in oneiric 2 hours ago too
[11:00] <jtaylor> bug 791527
[11:00] <ubottu> Launchpad bug 791527 in OpenCV Manager "libcv-dev: error: 'ptrdiff_t' does not name a type" [Undecided,New] https://launchpad.net/bugs/791527
[11:01] <jtaylor> weird that it wasn't merged instead
[11:01] <hakermania> jtaylor: Should I update my system? (apt-get update)
[11:02] <jtaylor> hakermania: yes but it might not been published yet
[11:02] <jtaylor> e.g. armel is still building
[11:02] <jtaylor> if it doesn't update wait a few hours
[11:03] <hakermania> jtaylor: Thanks a lot! I was furious to realize that the app wan't compiling :)
[11:04] <jtaylor> lots won't compile in oneiric, the compiler is much stricter + has a bunch of flags that breaks buggy compilation
[11:06] <hakermania> jtaylor: Yes, the compiler is stricter, i realized that. But I was strict with my program too, in 11.04 I didn't even get a warning from it, now, till the point it compiled before showing the bug error I already had 2 warnings xD
[11:11] <hakermania> jtaylor: When it is published it will be shown on the update manager?
[11:11] <jtaylor> yes
[11:11] <jtaylor> you can also download it now from launchpad
[11:12] <jtaylor> https://launchpad.net/ubuntu/+source/opencv
[13:02] <siretart> highvoltage: yes, I should probably have rather merged the upload. still, from the changelog it doesn't look like that the debian package builds properly against libav 0.7
[13:02] <siretart> highvoltage: never mind
[13:03] <siretart> jtaylor: ^^
=== yofel_ is now known as yofel
=== ttx` is now known as ttx
[21:20] <zooko> Dear people of #ubuntu-motu: we're talking about the release schedule for Tahoe-LAFS v1.9.0.
[21:20] <zooko> http://tahoe-lafs.org/pipermail/tahoe-dev/2011-July/006529.html
[21:22] <zooko> The question is: how many days before Oneiric Feature Freeze is our effective deadline for Tahoe-LAFS v1.9.0?
[21:22] <zooko> I think, based on my experience with getting previous releases of Tahoe-LAFS into previous releases of Ubuntu, that it will take at least three days to get Tahoe-LAFS upgraded and uploaded for Oneiric.
[21:22] <zooko> If that's right, then we can set ourselves a deadline of releasing Tahoe-LAFS v1.9.0 for August 7.
[21:25] <lifeless> zooko: if you're working backwards, I suggest giving yourself a bit more leeway
[21:25] <lifeless> Oneiric is only a short term support release anyhow
[21:26] <zooko> lifeless: well we're crunched between giving more leeway between Tahoe-LAFS 1.9.0 release and Oneiric Feature Freeze and giving ourselves more leeway between finishing and testing certain new patches and Tahoe-LAFS v1.9.0 release. :-)
[21:26] <zooko> So, you think it could take more than 3 days for someone to upload a new Tahoe-LAFS release?
[21:27] <lifeless> are there any changes that would affect the packaging?
[21:27] <lifeless> e.g.
[21:27] <lifeless> new setuid binaries
[21:27]  * zooko thinks
[21:27] <lifeless> new packages we should split out
[21:27]  * zooko looks at the tahoe-lafs trac
[21:27] <lifeless> new dependencies that might not be already packaged?
[21:28] <lifeless> version bumps on dependencies that are packaged but might not have been refreshed ?
[21:28] <lifeless> cause if its really straight forward, then its arguably only about 10 minutes
[21:32] <zooko> We're considering a version bump on Twisted, but I'm sure Oneiric will already have the new version...
[21:32] <zooko> Let's see... http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1274
[21:32] <zooko> We may require Twisted >= 10.1.
[21:37] <zooko> Hm, then there is this new functionality -- a "drop-box-like" behavior for Tahoe-LAFS:  http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1429
[21:37] <zooko> I guess the Twisted requirement already satisfies that, so it wouldn't require packaging changes.
[21:40] <lifeless> you'll be adding a daemon I presume ?
[21:43] <zooko> Asking davidsarah on #tahoe-lafs to double-check, but I believe the current tahoe-lafs daemon will do this added job of inotify-responding, so: no.
[21:44] <jtaylor> just make sure it actually works this time
[21:44] <jtaylor> are there any plans on fixing tahoe in natty?
[21:54] <zooko> Hm, what's the status of those bugs...
[21:54]  * zooko looks
[21:54] <jtaylor> no change
[21:55] <jtaylor> options I see, patch out the unnecessary version dependency or ask for a SRU exception update of pycryptopp
[21:58] <zooko> Hm, I can't find the tickets, other than https://bugs.launchpad.net/ubuntu/+source/tahoe-lafs/+bug/769935
[21:58] <ubottu> Ubuntu bug 769935 in tahoe-lafs (Ubuntu) "missing python-mock dep?" [Undecided,New]
[21:58]  * davidsarah looks
[21:58] <zooko> Is this the URL to find all tickets associated with the Ubuntu package "tahoe-lafs"?
[21:58] <zooko> https://bugs.launchpad.net/ubuntu/+source/tahoe-lafs
[21:59] <lifeless> zooko: yes
[21:59] <jtaylor> yes but the pycryptopp was fixed in oneiric, so you have to include fix released bugs in your search
[22:00] <davidsarah> so, I thought that rebuilding tahoe would automatically get the new pycryptopp (on Natty). is that not the case?
[22:00] <jtaylor> no, natty still has the old pycrytopp and updating it would require acknowledge of the release team
[22:00] <davidsarah> ok
[22:01] <davidsarah> so we should have a tahoe ticket for this
[22:02] <davidsarah> does installing 'python-mock' cause any regression for packages that use the other, colliding 'mock'?
[22:02] <jtaylor> there are more than one mock?
[22:02] <davidsarah> yes
[22:03]  * davidsarah tries to find the ticket about that
[22:03] <davidsarah> https://bugzilla.redhat.com/show_bug.cgi?id=601725
[22:03] <ubottu> bugzilla.redhat.com bug 601725 in mock "mock has a namespace collision with python-mock" [High,Assigned]
[22:03] <jtaylor> you mean python-mocker?
[22:03] <davidsarah> maybe that was only on redhat?
[22:04]  * davidsarah rereads that bug -- have forgotten the details
[22:06] <zooko> Yes, that's only Fedora/RH.
[22:07] <davidsarah> ok
[22:09] <davidsarah> so, this is purely an Ubuntu packaging issue for which an updated package is available in this branch: https://code.launchpad.net/~jtaylor/ubuntu/oneiric/tahoe-lafs/tahoe-lafs-fix , and so it doesn't need a fix in upstream Tahoe, right?
[22:11] <jtaylor> yes, but the question is how to fix it
[22:11] <jtaylor> patching out the version dedency is the simplest solution
[22:11] <jtaylor> but that would cause problems for people using a non-packaged old pycryptopp version
[22:11] <jtaylor> but I assume that should be very unlikely
[22:11] <zooko> Hm.
[22:12]  * davidsarah is confused
[22:12] <zooko> jtaylor: there is one place in the python source to change that dep.
[22:12] <davidsarah> what do you mean by "patching out the version dependency"?
[22:12]  * zooko fetches URL
[22:13]  * davidsarah is lost in a maze of twisty little packaging bugs, all alike
[22:13] <jtaylor> davidsarah: http://bazaar.launchpad.net/~jtaylor/ubuntu/oneiric/tahoe-lafs/tahoe-lafs-fix/view/head:/debian/patches/lower_pycryptopp_dep.patch
[22:13] <davidsarah> thanks
[22:14] <davidsarah> huh. that patch can't be a correct fix
[22:15] <davidsarah> since it only loosens the version requirement (i.e. allows pycryptopp 0.5.14..!20, but also still allows pycryptopp >= 0.5.20)
[22:15] <zooko> http://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/src/allmydata/_auto_deps.py?annotate=blame&rev=4976#L64
[22:16] <zooko> The place in the Tahoe-LAFS source where the pycryptopp dependency is specified in Pythonic terms.
[22:17] <jtaylor> davidsarah: I was under the impression that the only reason it needs 5.20 is the security fix?
[22:17] <jtaylor> which does not affect natty as it uses the up to date system libcrypto++ instead of the vurnable embedded one
[22:26] <zooko> jtaylor: yes, that's correct.
[22:26] <zooko> So as far as I can think, your patches are correct.
[22:27] <zooko> It would be better to upgrade the pycryptopp in Natty.
[22:28] <zooko> Only for the reason, as you mentioned, that relaxing the constraint in the Python code means someone who is relying on that python code (the Python code as provided by Ubuntu) but not using Ubuntu's package of pycryptopp, might use an older and insecure version of libcryptopp.
[22:28] <zooko> But, that's really not something we should try to fix.
[22:28] <zooko> They would have to go to a lot of effort to build an older, insecure libcryptopp into a .deb...
[22:38] <davidsarah> jtaylor: there's no guarantee that Tahoe is using the system libcrypto++
[22:38] <davidsarah> that is, we can't change this upstream because Tahoe in general is not necessarily using a system libcrypto++
[22:39] <davidsarah> (and even the version packaged with Natty possibly is not; it depends on the PYTHONPATH)
[22:40] <jtaylor> yes but how likely is it that someone is still using a old non package pycrypto in natty?
[22:41] <davidsarah> s/pycrypto/pycryptopp/ (pycrypto is something completely different!)
[22:42] <davidsarah> it's entirely possible. anyone who installed pycryptopp using easy_install might have that situation
[22:43] <davidsarah> (either easy_install of pycryptopp directly, or another python package that depends on it)
[22:44] <davidsarah> s/it depends on the PYTHONPATH/it depends on the PYTHONPATH, .pth files, anything installed into a site directory, and the phase of the moon)
[22:45] <jtaylor> well bet we request an stable update, if that gets rejected the patch is the only option (maybe with an additional warning)
[22:45] <jtaylor> s/bet/best/
[22:45] <jtaylor> does anyone use python-beaker? an rdep of pycryptopp
[22:46] <zooko> I don't know if anyone does.
[22:49] <davidsarah> I don't understand -- we can repackage Tahoe but not pycryptopp? Why?
[22:50] <davidsarah> the problem is that Ubuntu's pycryptopp fixed a security bug but didn't declare that it was an upstream version that had fixed the bug, so there was no reliable way to detect the fix
[22:50] <davidsarah> that's a pycryptopp packaging problem, not a Tahoe one
[22:52] <zooko> Yeah, pycryptopp uses its version number to comprise both pycryptopp and its embedded Crypto++.
[22:52] <jtaylor> well in stable release updates should be minimal to not introduce regressions
[22:52] <zooko> That's why Tahoe-LAFS says that it requires a newer pycryptopp -- solely because this newer pycryptopp came with a newer embedded Crypto++.
[22:52] <jtaylor> updating to a 12 versions newer upstream can cause all kinds of problems
[22:52] <zooko> Which is irrelevant if you aren't using the embedded version of Crypto++ that came with pycryptopp source.
[22:53] <zooko> Ah, well upgrading pycryptopp is pretty safe.
[22:53] <zooko> I haven't made any major changes to it in forever.
[22:53] <jtaylor> tahoe on the other hand is broken in the first place so it can't get much worth, and the proposed fix is also small
[22:53] <zooko> All those version number changes are mostly for build-time packaging tweaks.
[22:53] <zooko> Well, I think you're right in *this* case, but for future reference there is something worse than broken: working and insecure. :-)
[22:54] <zooko> I.e., worse than not doing anything useful and erroring and quitting, is running and exposing your data to thieves or exposing your computer to being taken over. :-)
[22:55] <zooko> So here are all of the changes in pycryptopp:
[22:57] <davidsarah> "well in stable release updates should be minimal to not introduce regressions" -- don't agree, where this involves using code that does not correspond to any upstream version
[22:58] <davidsarah> each upstream version has been tested as a whole. OS packagers *often* end-up introducing bugs by trying to cherry-pick changes
[22:58] <davidsarah> if this didn't happen so frequently, I might agree with the principle of making minimal changes
[22:59] <zooko> http://tahoe-lafs.org/trac/pycryptopp/browser/trunk/NEWS.rst
[23:00]  * zooko looks at the revision control log from pycryptopp-0.5.14.
[23:00] <zooko> http://tahoe-lafs.org/trac/pycryptopp/log/trunk/?action=stop_on_copy&mode=follow_copy&rev=772&stop_rev=&limit=128
[23:02] <zooko> So there are a lot of changes, but they are all either (a) build tweaks (often for different systems such as Mac OS X), (b) added unit tests, (c) packaging tweaks to generate version numbers differently or the like,
[23:02] <zooko> (d) applying bugfixes to the internal copy of Crypto++.
[23:02] <zooko> I'm not saying that these changes mightn't cause problems.
[23:02] <zooko> But, they are sort of limited in the kinds of problems that they would cause.
[23:03] <zooko> *Most* of the problems that could be caused by these changes would be limited to the build phase.
[23:03] <zooko> As opposed to anything a user who downloaded the new package would see.
[23:04] <zooko> Yep, I finished looking at all the patches, and that's about the sum of it.
[23:04] <zooko> The only patch that doesn't fall into one of those four categories is this one:
[23:05] <zooko> http://tahoe-lafs.org/trac/pycryptopp/changeset/759/trunk/
[23:05] <zooko> Which comments-in a feature that nobody currently uses.
[23:06] <jtaylor> it adds a feature?
[23:06] <zooko> So in sum, jtaylor, I wouldn't worry about too much disruption from upgrading pycryptopp.
[23:06] <zooko> Yeah, it makes another Python module importable.
[23:06] <jtaylor> k I'll do some brief testing tomorow and request ack on an update
[23:06] <jtaylor> do you still plan on syncing debian and ubuntu packages?
[23:06] <zooko> Before that patch you can import pycryptopp.publickey.rsa and pycryptopp.cipher.aes and so forth.
[23:07] <zooko> After that patch you in addition can import pycryptopp.publickey.ecdsa, but currently nobody does so.
[23:07] <zooko> jtaylor: I don't intend to spend time on syncing debian and ubuntu myself in the near future -- I'm working on Tahoe-LAFS v1.9 and related things.
[23:07] <jtaylor> adding features is usually not problematic, removing them on the other hand is
[23:07] <jtaylor> k then I'll also fix the missing mock problem in oneric
[23:08]  * davidsarah checks that calling init_ecdsa can't cause a problem
[23:08] <zooko> I'll be willing to look into any bug report that arise from upgrading pycryptopp or anything else.
[23:08] <zooko> Well, it does have unit tests, ds...
[23:09]  * davidsarah reads http://tahoe-lafs.org/trac/pycryptopp/browser/trunk/pycryptopp/publickey/ecdsamodule.cpp#L505
[23:11] <davidsarah> yep, that's pretty much the same as http://tahoe-lafs.org/trac/pycryptopp/browser/trunk/pycryptopp/publickey/rsamodule.cpp#L365
[23:11] <davidsarah> so a very low-risk addition
[23:37] <stlsaint> anyone care to assist with this lintian error:  newer-standards-version 3.9.2 (current is 3.8.4)
[23:37] <stlsaint> the debain/source/control file shows version 3.9.2
[23:37] <jtaylor> ignore that, the lintian in ubuntu is just to old
[23:37] <stlsaint> ha wow
[23:38] <jtaylor> lucid or?
[23:38] <stlsaint> jtaylor: yep lucid
[23:38] <jtaylor> if you use the oneiric lintian the error will disappear
[23:38] <stlsaint> jtaylor: does the same apply to these two: native-package-with-dash-version & debian-watch-file-in-native-package
[23:39] <jtaylor> no
[23:39] <jtaylor> is it a native package?
[23:40] <jtaylor> native packages should not have -X in their version string
[23:41] <jtaylor> a native package is a package where debian is upstream, stuff like dpkg and apt
[23:42] <stlsaint> jtaylor: oh sorry was reading on those errors, no the package is not native