Bug#762015: Subject: RFS: s3fs-fuse/1.78-1 [ITP #601789] -- FUSE-based file system backed by Amazon S3
Jakub, thank you for a review, answers inline .orig.tar.gz is not bitwise-identical to the one uscan downloads. Why? It seems git-buildpackage has repacked the tarball, I've done new upload with the correct orig tarball. Current standards version is 3.9.6. (But beware that Lintian doesn't know about it yet!) I've check the package against new standards version, no changes required. You don't have to specify full debian-policy version in the Standards-Version field. Only the first three components (that is, 3.9.5 or 3.9.6) have to be specified. (Policy §5.6.11) I used to write the full version in all my packages. If this is a problem, I'll fix it. I think it's customary not to put any space between ( and = in relationship fields. Fixed. There are some stray(?) 0x81 bytes in doc/man/s3fs.1 (line 74) and src/s3fs_util.cpp (line 878). Thank you, I haven't noticed them. I've prepared a patch and sent it to upstream already. As for spelling errors, I've sent the request to upstream author. Some of those found by spellintian seem to be false positives (ressize variable meant resource size). [1,2] For now I have added quilt patch for stray chars but left spelling errors to be merged by upstream. [1]: https://github.com/s3fs-fuse/s3fs-fuse/pull/62 [2]: https://github.com/s3fs-fuse/s3fs-fuse/pull/63 2014-09-26 14:28 GMT+03:00 Jakub Wilk jw...@debian.org: [I don't intend to sponsor this package. Sorry!] * Andriy Senkovych jolly_ro...@itblog.org.ua, 2014-09-17, 22:00: http://mentors.debian.net/debian/pool/main/s/s3fs-fuse/s3fs-fuse_1.78-1.dsc .orig.tar.gz is not bitwise-identical to the one uscan downloads. Why? Current standards version is 3.9.6. (But beware that Lintian doesn't know about it yet!) nitpicking mode=extreme You don't have to specify full debian-policy version in the Standards-Version field. Only the first three components (that is, 3.9.5 or 3.9.6) have to be specified. (Policy §5.6.11) I think it's customary not to put any space between ( and = in relationship fields. /nitpicking There are some stray(?) 0x81 bytes in doc/man/s3fs.1 (line 74) and src/s3fs_util.cpp (line 878). codespell(1) finds a bunch of typos: README:64: happend == happened src/s3fs_util.cpp:499: infomation == information src/s3fs_util.cpp:501: infomation == information src/s3fs_util.cpp:535: infomation == information src/s3fs_util.cpp:537: infomation == information src/openssl_auth.cpp:134: destory == destroy src/curl.cpp:532: existance == existence src/curl.cpp:1908: occured == occurred src/curl.cpp:3475: charactor == character src/curl.cpp:3479: charactor == character src/curl.cpp:3514: charactor == character src/curl.cpp:3516: Charactor == Character src/s3fs.cpp:2043: responce == response src/s3fs.cpp:2565: occured == occurred src/s3fs.cpp:2691: Destory == Destroy src/s3fs.cpp:2947: occured == occurred src/s3fs.cpp:2955: Destory == Destroy src/s3fs.cpp:3903: compatability == compatibility spellintian[0] finds a few more: src/fdcache.h: ressize - resize src/fdcache.cpp: ressize - resize src/s3fs.cpp: ressize - resize src/curl.h: failuer - failure [0] https://bitbucket.org/jwilk/spellintian -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140926112824.ga3...@jwilk.net -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cams_sfjk+n1eq-7nzw7nq+ez-iw5gyosg2quzm0jla1cqzx...@mail.gmail.com
Packaging AngularJS application as part of the python twisted application
Dear mentors, python hackers, Debian developers I'm maintaining buildbot[1] packages for quite some time. While current packaging of this application is not that hard, the upcoming 0.9 release includes a new web interface organized as python module called 'buildbot_www'. This module is in fact an AngularJS web application that build-depends on nodejs and npm. The current procedure of release this module implies following steps: 1) git clone git://github.com/buildbot/buildbot 2) git checkout -tb nine origin/nine 3) cd www 4) python setup.py sdist The last command performs the actual building of the python module: 1) npm/bower downloads necessary Javascript libraries (download 152Mb of js libraries in .tar.gz) 2) the main (minified/uglified) Javascript file is generated 3) other js/css resources are generated using tools like coffeescript and less 4) html files are generated as well In the end these files are included in the resulting python module tarball. It is totally valid python sdist tarball that can be packaged using ordinary rules of Python packaging. But according to the Debian policy this tarball cannot be considered as a source tarball since it contains generated code, minified js/css etc. I have raised the discussion on the upstream mailing list[2]. Their intention is understandable: current approach allows python developers to work on python code whithout bothering with nodejs/npm while frontend devs could easily hack web iterface without need of python backend. Thanks to the conversation on IRC with Ben Finney, I've detected some potential ideas that should be addressed upstream: 1) provide valid (from Debian's PoV) source tarball for buildbot_www Python module 2) have separate source tarball with bundled javascript dependencies that can be handled by DebSrc 3.0 format as additional upstream tarball; also make possible to use this external tarball in the build process without need of internet connection, It would be possible to replace external js deps with ones already packaged for Debian as well, for example. What steps can be done in such case? What can be done better? Please share your thoughts. I believe, there would appear more similar projects in the future, so the conversation should be useful for a lot more people. Thanks. [1]: http://buildbot.net [2]: http://thread.gmane.org/gmane.comp.python.buildbot.devel/9744 -- Best regards, Andriy Senkovych -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAMS_SFKWukZ4Kzekcxg29z=s6jxfwyaquyl8pwn9ceho_aq...@mail.gmail.com
Re: Build Debian packages for multiple architectures
Niels, Adam, thanks. Do I understand correctly that the following workflow is sufficient? 1) developer uploads source package (generated with dpkg-buildpackage -S) 2) binary packages with together arch=all is performed on a single architecture (using dpkg-buildpackage -b) 3) binary-only packages are built for other architectures (dpkg-buildpackage -B) 4) if the package builds successfull on all architectures — merge *.changes file into a single one (using mergechanges) and all files are uploaded to the repository Thanks, I didn't know about mergechanges script. -- Best regards, Andrii Senkovych 2013/3/18 Niels Thykier ni...@thykier.net: On 2013-03-18 18:15, Adam Borowski wrote: On Mon, Mar 18, 2013 at 06:17:01PM +0200, Andrii Senkovych wrote: Hello, debian-mentors I'm sorry in advance if this is the wrong list to ask. TL;DR: how to build and upload properly packages that provide both arch=all and arch=any binary packages without conflicts like file already exists with different checksum during upload stage? 1) upload source package ond binary packages for one arch (this upload seems to include the packages with 'all' arch as well) 2) upload binary packages for all other architectures So, the question is: how should I build packages for multiple architectures without such problems? dpkg-buildpackage -B This runs only the binary-arch target but not the rest. Also, see mergechanges(1) from devscripts, which can you from signing several changes files. ~Niels -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51474d14.5040...@thykier.net -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAMS_SF+N7Vm4kOjC27i978dob7vK1xOp5f=zyÛSj_KsTXU=q...@mail.gmail.com
Build Debian packages for multiple architectures
Hello, debian-mentors I'm sorry in advance if this is the wrong list to ask. TL;DR: how to build and upload properly packages that provide both arch=all and arch=any binary packages without conflicts like file already exists with different checksum during upload stage? Some time ago I've tried to manage my own debian repository with reprepro. I had almost no problems when repository contained packages with arch 'any'. Usually I just build packages on my machine and upload the results to the repository with dupload tool. However when there appeared packages that should be built for any supported architecture, some questions raised. It is certain that I still could build amd64 and i386 packages on my own machine. I realized I could upload source packages separately from the binary ones that simplified things a little. For example, if source package provides one binary package with arch 'any' and another one with 'all', I could upload it to the repository in two steps: 1) upload source package ond binary packages for one arch (this upload seems to include the packages with 'all' arch as well) 2) upload binary packages for all other architectures Everything's good in theory, but when I actually did this, all binary-only uploads included both arch-specific and arch-independent packages. This led to conflicts during upload phase because the repository already included binary packages with arch=all, but with different checksums. I have tried all sorts of dpkg-buildpackage flags with no success. After all these efforts I decided to ask you. So, the question is: how should I build packages for multiple architectures without such problems? Thank you. -- Best regards, Andrii Senkovych -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAMS_SF+pEK7soJdr7AYzHfDHdQ+tY12_rZLtBDQwpvf=dmv...@mail.gmail.com
