Re: [Asdf-devel] Wanted: Debian packager
Here's the patch I've committed on my local release branch, but haven't pushed to common-lisp.net yet, pending maintainer approval. Note that 1- the email listed at the end of the top entry of the changelog has to be the same as the person who's going to sign the package with his PGP key as registered on mentors.debian.net, before the package is uploaded. So if someone else is going to upload this or future packages, the address should be amended (and also added in the debian/control file). 2- lintian ../cl-asdf*.changes is your friend. 3- To create the package I'm using the version of the release script that's in master, 4- A good exercise in further bootstrapping ASDF would be convert bin/asdf-builder to a trivial cl-launch script + a system asdf-build (or meta-asdf? whatever), and the Makefile to a trivial wrapper that invokes it (except for the initial bootstrap of the concatenated build/asdf.lisp), and the Makefile targets into as many secondary systems of asdf-build. I'm refraining from doing more of it, since I'm moving to new projects. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org A single flaw in someone else's beliefs, they are discredited. Repeated obvious flaws in your own, you keep the blind faith. Government saves! On Fri, May 16, 2014 at 8:57 AM, Kambiz Darabi <darabi@m-creations.com> wrote:
Hello,
On 2014-05-16 07:12 CEST, Faré <fahree@gmail.com> wrote:
That said, I can do the asdf debian package one last time for 3.1.2. I've experimented a bit and come up with a better recipe. Apparently the trick to avoid dealing with complications is to work in a branch where the only changes since the upstream release tag are in the debian/ directory. If you let me do it, I'll do it in the release branch. I updated the bin/asdf-builder script to do the release (moving code from the Makefile and making it better — scripting is SO much better in Lisp). Of course, the script as exists in the release branch is insufficient, and since it does a git clean -xfd we need to extract it from master under another name everytime. So: I committed some debian-only changes in my release branch (not pushed — but I can do it if you approve, and even upload), and ran: git show master:bin/asdf-builder > bin/x && chmod a+x bin/x && ./bin/x debian-package and it looks like it worked. I can push all that if you want, or show you how to do it. It's a matter of git checkout release ; git show master:debian/changelog > debian/changelog ; edit debian/changelog
I have never packaged for Debian, but I use it since rex (1996). With a bit of hand-holding, I might be able to do the packaging work.
Where can I fetch your changes?
Kambiz Darabi
On Fri, May 16, 2014 at 7:12 PM, Faré <fahree@gmail.com> wrote:
4- A good exercise in further bootstrapping ASDF would be convert bin/asdf-builder to a trivial cl-launch script + a system asdf-build (or meta-asdf? whatever), and the Makefile to a trivial wrapper that invokes it (except for the initial bootstrap of the concatenated build/asdf.lisp), and the Makefile targets into as many secondary systems of asdf-build. I'm refraining from doing more of it, since I'm moving to new projects.
Actually, * I didn't use cl-launch in this case, because that would add one more dependency to the build * Also, the way asdf-builder loads asdf is a demonstration of how to do it in a super-robust super-portable script for someone's self-contained CL project, whereas the way cl-launch loads asdf is a demonstration of how to do it when you trust the user's basic configuration. * tonight's procrastination was for me to convert the Makefile to a Lisp script. I was expecting to create a meta-asdf.asd file with plenty of secondary systems, but found that since I was only handling dummy targets, and only one top-level one, I ended up not needing any of that — plain functions did it all, and the most advanced macro I needed was something to handle make-style overriding of environment-variables. I was a bit disappointed, but it's better that way. See it all in branch minimakefile (not fully tested). * In any case, with the code in the master branch, you can use ./bin/asdf-builder debian-package to release the version in release, or ./bin/asdf-builder debian-package master to release from master, and it's all implemented in Lisp, with a few extra checks that were too hard to do in shell for me to bother to do them before. The minimakefile branch similarly has more functionality and more robustness thanks to moving all non-trivial code from shell to CL. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org When various people have incompatible values, Democracy means mass murderous ethnic cleansing is the only alternative to group-based oppression.
Faré wrote:
Here's the patch I've committed on my local release branch, but haven't pushed to common-lisp.net yet, pending maintainer approval.
That's fine with me; you have my blessing. Kambiz, if you'd like to take over, that would be a huge help. I don't think I'm going to be able to maintain enough of a bleeding-edge install to be packaging. Contact me off list if you need support and/or access to the repo. best, r
Note that
1- the email listed at the end of the top entry of the changelog has to be the same as the person who's going to sign the package with his PGP key as registered on mentors.debian.net, before the package is uploaded. So if someone else is going to upload this or future packages, the address should be amended (and also added in the debian/control file).
2- lintian ../cl-asdf*.changes is your friend.
3- To create the package I'm using the version of the release script that's in master,
4- A good exercise in further bootstrapping ASDF would be convert bin/asdf-builder to a trivial cl-launch script + a system asdf-build (or meta-asdf? whatever), and the Makefile to a trivial wrapper that invokes it (except for the initial bootstrap of the concatenated build/asdf.lisp), and the Makefile targets into as many secondary systems of asdf-build. I'm refraining from doing more of it, since I'm moving to new projects.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org A single flaw in someone else's beliefs, they are discredited. Repeated obvious flaws in your own, you keep the blind faith. Government saves!
On Fri, May 16, 2014 at 8:57 AM, Kambiz Darabi <darabi@m-creations.com> wrote:
Hello,
On 2014-05-16 07:12 CEST, Faré <fahree@gmail.com> wrote:
That said, I can do the asdf debian package one last time for 3.1.2. I've experimented a bit and come up with a better recipe. Apparently the trick to avoid dealing with complications is to work in a branch where the only changes since the upstream release tag are in the debian/ directory. If you let me do it, I'll do it in the release branch. I updated the bin/asdf-builder script to do the release (moving code from the Makefile and making it better — scripting is SO much better in Lisp). Of course, the script as exists in the release branch is insufficient, and since it does a git clean -xfd we need to extract it from master under another name everytime. So: I committed some debian-only changes in my release branch (not pushed — but I can do it if you approve, and even upload), and ran: git show master:bin/asdf-builder > bin/x && chmod a+x bin/x && ./bin/x debian-package and it looks like it worked. I can push all that if you want, or show you how to do it. It's a matter of git checkout release ; git show master:debian/changelog > debian/changelog ; edit debian/changelog I have never packaged for Debian, but I use it since rex (1996). With a bit of hand-holding, I might be able to do the packaging work.
Where can I fetch your changes?
Kambiz Darabi
On Sun, May 18, 2014 at 5:28 AM, Robert P. Goldman <rpgoldman@sift.info> wrote:
Faré wrote:
Here's the patch I've committed on my local release branch, but haven't pushed to common-lisp.net yet, pending maintainer approval.
That's fine with me; you have my blessing.
Kambiz, if you'd like to take over, that would be a huge help. I don't think I'm going to be able to maintain enough of a bleeding-edge install to be packaging.
I found that this magic command helps: 1- edit files in debian/ and debian/ only ... if you need to patch things beside packaging, it's going to be more complex than I know how to deal with. 2- commit them, maybe commit --amend if no one else has seen your previous attempts... 3- git clean -xfd ; git-buildpackage --git-debian-branch=release --git-upstream-tag="%(version)s" --git-tag --git-retag --git-force-create --git-ignore-branch I've uploaded a new package 2:3.1.2-2 at http://mentors.debian.net/package/cl-asdf after a few attempts. In case of difficulties, #debian-mentors on irc.oftc.net is here to help. Finally, not only am I in the process of getting away from ASDF, I also am getting away from Debian: I'm not using it at home anymore (I'm a convert to NixOS), and at work I'm using Ubuntu boxes but they are mostly work-managed. Actually, this all prompted me to rewrite asdf's build and test infrastructure from Lisp to CL. Much better now. See branch minimakefile, that I hope Robert will let me merge into master soon. (Also pending merge into master: branch syntax-control). —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The whole modern world has divided itself into Conservatives and Progressives. The business of Progressives is to go on making mistakes. The business of the Conservatives is to prevent the mistakes from being corrected. — G.K. Chesterton
Hello, I wrote a message with detailed questions some days ago, which I obviously didn't send and I also don't find in my drafts folder :( So, sorry for the delay and here I go again: On 2014-05-20 20:57 CEST, Faré <fahree@gmail.com> wrote:
I found that this magic command helps:
1- edit files in debian/ and debian/ only ... if you need to patch things beside packaging, it's going to be more complex than I know how to deal with. 2- commit them, maybe commit --amend if no one else has seen your previous attempts... 3- git clean -xfd ; git-buildpackage --git-debian-branch=release --git-upstream-tag="%(version)s" --git-tag --git-retag --git-force-create --git-ignore-branch
I looked at the changes in minimakefile branch and tried to follow the steps you outline in the (not yet implemented) release function. I assume that that function is meant to automate all of the release process and not only the debian packaging, so some of my questions below might be silly in this light, but I will ask though.
(defun release () "Release the code (not implemented)" #| RELEASE or PUSH checklist: make test-all
Which implementations do you test with before uploading a new package? Which version of those implementations do you use?
defaultLisps = ccl clisp sbcl ecl ecl_bytecodes cmucl abcl scl allegro lispworks allegromodern gcl xcl mkcl
I got as far as abcl (1.3.1, the current release), but the test hangs for hours and although abcl is described as 'damn slow' in run-tests.sh, I thought this might be a real issue. What would be the recommended next step? Can I run the tests with higher verbosity? If I cannot resolve the problem myself, do I contact the maintainers?
make test-load-systems s=fare-all
I assume fare-all is one of your libs, but couldn't find it although I searched a bit.
make bump v=3.0 edit debian/changelog # RELEASE only...
I noticed that debian/changelog is very detailed and contains much more information than I could deduce from the commit messages. Is it edited by the devs during the development cycle? If not, I hope it wouldn't be my duty to come up with such detailed and knowledgeable information about the changes.
git commit git tag 3.0 # for example ... make debian-package
I had to install: fare-mop named-readtables optima fare-quasiquote inferior-shell fare-utils Would it possible/desirable to have them as git submodule or git subtree in the repo for the build to be independent of the versions of the dependencies? The current version of master in version.lisp-expr is 3.1.2.3. I changed it to 3.1.2 to avoid the error
Debian version 2:3.1.2-3 doesn't match asdf version 3.1.2.3
but unfortunately, I get the following backtrace:
./bin/asdf-builder debian-package master building package version 2:3.1.2.3-1 Unhandled SB-INT:SIMPLE-PROGRAM-ERROR in thread #<SB-THREAD:THREAD "main thread" RUNNING {1002A8B3B3}>: unknown &KEY argument: :DIRECTORY
Backtrace for: #<SB-THREAD:THREAD "main thread" RUNNING {1002A8B3B3}> 0: (RUN (GIT-BUILDPACKAGE (--GIT-DEBIAN-BRANCH= "master") (--GIT-UPSTREAM-TAG= "%(version)s") --GIT-TAG --GIT-RETAG --GIT-FORCE-CREATE --GIT-IGNORE-BRANCH) :DIRECTORY #P"/opt/repo/asdf/" :SHOW T) [more,optional]
I've uploaded a new package 2:3.1.2-2 at http://mentors.debian.net/package/cl-asdf after a few attempts.
You set version.lisp-expr to 3.1.2 manually before building the package?
In case of difficulties, #debian-mentors on irc.oftc.net is here to help. Finally, not only am I in the process of getting away from ASDF, I also am getting away from Debian: I'm not using it at home anymore (I'm a convert to NixOS), and at work I'm using Ubuntu boxes but they are mostly work-managed.
I would probably set up a debian vm to have a clean env for building the package. I still have questions regarding the release workflow but for the moment, I'd like to get the technical part straight. Thank you Kambiz
Hello, I wrote a message with detailed questions some days ago, which I obviously didn't send and I also don't find in my drafts folder :( So, sorry for the delay and here I go again: On 2014-05-20 20:57 CEST, Faré <fahree@gmail.com> wrote:
I found that this magic command helps:
1- edit files in debian/ and debian/ only ... if you need to patch things beside packaging, it's going to be more complex than I know how to deal with. 2- commit them, maybe commit --amend if no one else has seen your previous attempts... 3- git clean -xfd ; git-buildpackage --git-debian-branch=release --git-upstream-tag="%(version)s" --git-tag --git-retag --git-force-create --git-ignore-branch
I looked at the changes in minimakefile branch and tried to follow the steps you outline in the (not yet implemented) release function. I assume that that function is meant to automate all of the release process and not only the debian packaging, so some of my questions below might be silly in this light, but I will ask though.
(defun release () "Release the code (not implemented)" #| RELEASE or PUSH checklist: make test-all
Which implementations do you test with before uploading a new package? Which version of those implementations do you use?
defaultLisps = ccl clisp sbcl ecl ecl_bytecodes cmucl abcl scl allegro lispworks allegromodern gcl xcl mkcl
I got as far as abcl (1.3.1, the current release), but the test hangs for hours and although abcl is described as 'damn slow' in run-tests.sh, I thought this might be a real issue. What would be the recommended next step? Can I run the tests with higher verbosity? If I cannot resolve the problem myself, do I contact the maintainers?
make test-load-systems s=fare-all
I assume fare-all is one of your libs, but couldn't find it although I searched a bit.
make bump v=3.0 edit debian/changelog # RELEASE only...
I noticed that debian/changelog is very detailed and contains much more information than I could deduce from the commit messages. Is it edited by the devs during the development cycle? If not, I hope it wouldn't be my duty to come up with such detailed and knowledgeable information about the changes.
git commit git tag 3.0 # for example ... make debian-package
I had to install: fare-mop named-readtables optima fare-quasiquote inferior-shell fare-utils Would it possible/desirable to have them as git submodule or git subtree in the repo for the build to be independent of the versions of the dependencies? The current version of master in version.lisp-expr is 3.1.2.3. I changed it to 3.1.2 to avoid the error
Debian version 2:3.1.2-3 doesn't match asdf version 3.1.2.3
but unfortunately, I get the following backtrace:
./bin/asdf-builder debian-package master building package version 2:3.1.2.3-1 Unhandled SB-INT:SIMPLE-PROGRAM-ERROR in thread #<SB-THREAD:THREAD "main thread" RUNNING {1002A8B3B3}>: unknown &KEY argument: :DIRECTORY
Backtrace for: #<SB-THREAD:THREAD "main thread" RUNNING {1002A8B3B3}> 0: (RUN (GIT-BUILDPACKAGE (--GIT-DEBIAN-BRANCH= "master") (--GIT-UPSTREAM-TAG= "%(version)s") --GIT-TAG --GIT-RETAG --GIT-FORCE-CREATE --GIT-IGNORE-BRANCH) :DIRECTORY #P"/opt/repo/asdf/" :SHOW T) [more,optional]
I've uploaded a new package 2:3.1.2-2 at http://mentors.debian.net/package/cl-asdf after a few attempts.
You set version.lisp-expr to 3.1.2 manually before building the package?
In case of difficulties, #debian-mentors on irc.oftc.net is here to help. Finally, not only am I in the process of getting away from ASDF, I also am getting away from Debian: I'm not using it at home anymore (I'm a convert to NixOS), and at work I'm using Ubuntu boxes but they are mostly work-managed.
I would probably set up a debian vm to have a clean env for building the package. I still have questions regarding the release workflow but for the moment, I'd like to get the technical part straight. Thank you Kambiz
I already replied to this same message in another thread: Date: Wed, 21 May 2014 21:06:07 +0200 Message-ID: <CAN7nBXeX8Puhp0MqEKeWmUYbhZ97d62QTLoTEyYB=maiCzKU=A@mail.gmail.com> Subject: Re: RFS: Please upload cl-asdf package From: =?UTF-8?B?RmFyw6k=?= <fare@tunes.org> To: Kambiz Darabi <darabi@m-creations.com>, Debian Common Lisp Team <pkg-common-lisp-devel@lists.alioth.debian.org> —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org We [the French] will accept any master who will let us enjoy the good life, with good food, sweet romance and long vacations; and we'll use that good life to corrupt whoever will rule us into embracing our way of life. Yet we'll abandon him for a stronger master the moment that his weakness is apparent. On Sun, May 25, 2014 at 9:34 AM, Kambiz Darabi <darabi@m-creations.net> wrote:
Hello,
I wrote a message with detailed questions some days ago, which I obviously didn't send and I also don't find in my drafts folder :(
So, sorry for the delay and here I go again:
On 2014-05-20 20:57 CEST, Faré <fahree@gmail.com> wrote:
I found that this magic command helps:
1- edit files in debian/ and debian/ only ... if you need to patch things beside packaging, it's going to be more complex than I know how to deal with. 2- commit them, maybe commit --amend if no one else has seen your previous attempts... 3- git clean -xfd ; git-buildpackage --git-debian-branch=release --git-upstream-tag="%(version)s" --git-tag --git-retag --git-force-create --git-ignore-branch
I looked at the changes in minimakefile branch and tried to follow the steps you outline in the (not yet implemented) release function. I assume that that function is meant to automate all of the release process and not only the debian packaging, so some of my questions below might be silly in this light, but I will ask though.
(defun release () "Release the code (not implemented)" #| RELEASE or PUSH checklist: make test-all
Which implementations do you test with before uploading a new package? Which version of those implementations do you use?
defaultLisps = ccl clisp sbcl ecl ecl_bytecodes cmucl abcl scl allegro lispworks allegromodern gcl xcl mkcl
I got as far as abcl (1.3.1, the current release), but the test hangs for hours and although abcl is described as 'damn slow' in run-tests.sh, I thought this might be a real issue.
What would be the recommended next step? Can I run the tests with higher verbosity? If I cannot resolve the problem myself, do I contact the maintainers?
make test-load-systems s=fare-all
I assume fare-all is one of your libs, but couldn't find it although I searched a bit.
make bump v=3.0 edit debian/changelog # RELEASE only...
I noticed that debian/changelog is very detailed and contains much more information than I could deduce from the commit messages. Is it edited by the devs during the development cycle? If not, I hope it wouldn't be my duty to come up with such detailed and knowledgeable information about the changes.
git commit git tag 3.0 # for example ... make debian-package
I had to install:
fare-mop named-readtables optima fare-quasiquote inferior-shell fare-utils
Would it possible/desirable to have them as git submodule or git subtree in the repo for the build to be independent of the versions of the dependencies?
The current version of master in version.lisp-expr is 3.1.2.3. I changed it to 3.1.2 to avoid the error
Debian version 2:3.1.2-3 doesn't match asdf version 3.1.2.3
but unfortunately, I get the following backtrace:
./bin/asdf-builder debian-package master building package version 2:3.1.2.3-1 Unhandled SB-INT:SIMPLE-PROGRAM-ERROR in thread #<SB-THREAD:THREAD "main thread" RUNNING {1002A8B3B3}>: unknown &KEY argument: :DIRECTORY
Backtrace for: #<SB-THREAD:THREAD "main thread" RUNNING {1002A8B3B3}> 0: (RUN (GIT-BUILDPACKAGE (--GIT-DEBIAN-BRANCH= "master") (--GIT-UPSTREAM-TAG= "%(version)s") --GIT-TAG --GIT-RETAG --GIT-FORCE-CREATE --GIT-IGNORE-BRANCH) :DIRECTORY #P"/opt/repo/asdf/" :SHOW T) [more,optional]
I've uploaded a new package 2:3.1.2-2 at http://mentors.debian.net/package/cl-asdf after a few attempts.
You set version.lisp-expr to 3.1.2 manually before building the package?
In case of difficulties, #debian-mentors on irc.oftc.net is here to help. Finally, not only am I in the process of getting away from ASDF, I also am getting away from Debian: I'm not using it at home anymore (I'm a convert to NixOS), and at work I'm using Ubuntu boxes but they are mostly work-managed.
I would probably set up a debian vm to have a clean env for building the package.
I still have questions regarding the release workflow but for the moment, I'd like to get the technical part straight.
Thank you
Kambiz
Hi, On 2014-05-25 17:51 CEST, Faré <fahree@gmail.com> wrote:
I already replied to this same message in another thread:
Date: Wed, 21 May 2014 21:06:07 +0200 Message-ID: <CAN7nBXeX8Puhp0MqEKeWmUYbhZ97d62QTLoTEyYB=maiCzKU=A@mail.gmail.com> Subject: Re: RFS: Please upload cl-asdf package From: =?UTF-8?B?RmFyw6k=?= <fare@tunes.org> To: Kambiz Darabi <darabi@m-creations.com>, Debian Common Lisp Team <pkg-common-lisp-devel@lists.alioth.debian.org>
sorry for the noise. Thank you for the response. Cheers Kambiz
participants (4)
-
Faré -
Kambiz Darabi -
Kambiz Darabi -
Robert P. Goldman