[tahoe-dev] [tahoe-lafs] #769: debian 'sid' package fails to run: pycryptopp-0.5.15 not available in debian form

[tahoe-lafs]

#769: debian 'sid' package fails to run: pycryptopp-0.5.15 not available in
debian form
-----------------------+----------------------------------------------------
 Reporter:  warner     |           Owner:  zooko
     Type:  defect     |          Status:  new  
 Priority:  critical   |       Milestone:  1.5.0
Component:  packaging  |         Version:  1.4.1
 Keywords:             |   Launchpad_bug:       
-----------------------+----------------------------------------------------

Old description:

> I just tried to run {{{tahoe --version}}} from a .deb I built from trunk
> (on my sid system), and it fails with the following error:
>
> {{{
> pkg_resources.VersionConflict: (pycryptopp 0.5.2-1 (/usr/lib/python2.5
> /site-packages), Requirement.parse('pycryptopp>=0.5.15'))
> }}}
>
> I should update the debian/control files to make this requirement visible
> to the debian package manager (i.e. it should not have let me install
> this tahoe), but apart from that, we need updated pycryptopp debs before
> we can release 1.5.0 .
>
> I think we're ok with zfec and foolscap packages.

New description:

 I just tried to run {{{tahoe --version}}} from a .deb I built from trunk
 (on my sid system), and it fails with the following error:

 {{{
 pkg_resources.VersionConflict: (pycryptopp 0.5.2-1 (/usr/lib/python2.5
 /site-packages), Requirement.parse('pycryptopp>=0.5.15'))
 }}}

 I've updated the debian/control files to make this requirement visible to
 the debian package manager (i.e. it should not let me install this tahoe),
 but apart from that, we need updated pycryptopp debs before we can release
 1.5.0 . We need them for all of the same platforms for which we provide
 Tahoe debs: etch/edgy/feisty/gutsy/hardy/hardy-amd64 .

 I think we're ok with zfec and foolscap packages.

--

Comment(by warner):

 I updated the tahoe debian/control rules to declare a dependency upon
 pycryptopp-0.5.15: the tahoe .debs now correctly refuse to install.

 Zooko: I set up a bunch of "flappserver upload-file" services for
 uploading tahoe .debs to the repository on hanford (which gets mirrored to
 allmydata.org). Let's do the same for the pycryptopp debs.

 In {{{buildslave at hanford}}}, do this one or more times:
 {{{
 flappserver add ~/.flappserver -C DIST/main/binary-i386 upload-file
 ~/tahoe-debs/dists/DIST/main/binary-i386
 }}}

 (setting DIST appropriately for each time)

 Each time you run that, it will emit a furl. Copy this to the buildslave,
 stored in something like ~/main-deb.furl . Then add an upload step to the
 buildmaster config, which runs:

 {{{
 flappclient --furlfile ~/main-deb.furl upload-file ../pycryptopp*.deb
 }}}

 You should also copy the "tahoe-update-apt.furl" and have a step to update
 the APT index by running

 {{{
 flappclient --furlfile ~/tahoe-update-apt.furl run-command
 }}}

 (take a look at any of the tahoe deb builders for an example)

 I don't know how you ought manage the variety of platforms, though. We
 build
 and host tahoe debs for etch/edgy/feisty/gutsy/hardy/hardy-amd64, so it'd
 be
 nice to provide pycryptopp debs for all of those. The tahoe .deb process
 only
 actually has rules for etch, lenny, and sid: basically we use the etch
 rules
 for the py2.4 platforms (etch and edgy), sid for sid, and lenny for
 everything else. But we run those rules on actual edgy/feisty/etc systems
 so
 they declare the right dependencies (in general you can't install a newer
 deb
 on an older system, because it will declare a dependency upon newer
 versions
 of libc, etc).

 You'd need to find some similar mapping for pycryptopp, and create debs
 for
 all the same platforms we do for Tahoe. It sounds like you're only
 currently
 creating debs for one of those platforms (sid), and that .deb probably
 won't
 install on any of the earlier ones.

-- 
Ticket URL: <http://allmydata.org/trac/tahoe/ticket/769#comment:3>
tahoe-lafs <http://allmydata.org>
secure decentralized file storage grid