This is a maintenance and bugfix release. There should be no incompatibilities, and many small fixes. The one new feature is an optional speedup to system search. Users who have large directory trees to search, and stable sets of systems, can build a system search cache that will substantially speed up finding and loading system definitions.
Because this version does not cause compatibility issues, we strongly suggest that implementations move to replace 3.1.3 with 3.1.4.
Thanks to Faré for many bug fixes, to Dave Cooper for testing, and all who reported bugs and provided patches.
Best, R
Hi Faré,
thank you for packaging and uploading again. I didn't notice that you have already performed the build and uploaded to mentors until I came to the uploading step.
If I understand correctly, my signing key and my email should be registered somewhere. I have created an account on mentors.debian.net and sent my pgp key to pgp.mit.edu and keyring.debian.org.
Then I tried to dput the package, which finishes successfully, but the package doesn't show up on 'my packages' (maybe because there is already your identical version?).
Do you have a pointer to some step-by-step documentation for newbies? I have already read [1], [2], and [3] but find it a bit difficult to figure out all of the details.
Thanks
Kambiz
[1] https://mentors.debian.net/intro-maintainers
[2] https://mentors.debian.net/sponsors
[3] https://wiki.debian.org/DebianMentorsFaq
On 2014-10-10 16:34 CEST, Robert Goldman rpgoldman@sift.net wrote:
This is a maintenance and bugfix release. There should be no incompatibilities, and many small fixes. The one new feature is an optional speedup to system search. Users who have large directory trees to search, and stable sets of systems, can build a system search cache that will substantially speed up finding and loading system definitions.
Because this version does not cause compatibility issues, we strongly suggest that implementations move to replace 3.1.3 with 3.1.4.
Thanks to Faré for many bug fixes, to Dave Cooper for testing, and all who reported bugs and provided patches.
Best, R
Asdf-devel mailing list Asdf-devel@common-lisp.net http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
Dear Kambiz,
On Fri, Oct 10, 2014 at 6:53 PM, Kambiz Darabi darabi@m-creations.com wrote:
thank you for packaging and uploading again. I didn't notice that you have already performed the build and uploaded to mentors until I came to the uploading step.
Oops, I didn't know you were on it. Thanks for trying. Next time, I'll leave it all up to you! Mind that the correct release script is in the minimakefile branch, that I believe Robert is evaluating for merge into master. Also mind that said release script is too dumb to handle patches, and only works if your git tag 3.1.4 is the same as the HEAD of the build branch (by default, release). You can use git tag -f 3.1.4 to make several attempts. But of course, now that the upstream and debian maintainers are distinct, you can't do that anymore, or only as a temporary local kluge. Two solutions: * modify the release script to actually handle debian patches the hard way, whereby we fork a debian branch off of the release branch, and create files in debian/patches/ as necessary. Yuck. * cheat better, so that the release script doesn't use the version 3.1.4 as the base tag, but whatever is at the HEAD of the release branch; then you commit your debian changes to release (or debian) and commit --amend until you're happy. When you're done, you (if you are a committer) or the maintainer can merge your changes into master.
If I understand correctly, my signing key and my email should be registered somewhere. I have created an account on mentors.debian.net and sent my pgp key to pgp.mit.edu and keyring.debian.org.
You need to upload it to mentors.debian.net. Its name must match exactly what is used in the debian/changelog and debian/control files and also whatever Emacs uses to sign when using debian changelog mode (based on your /etc/passwd entry and/or other Emacs variables ?). During the last few releases, I had the problem that Emacs would of late sign my name using UTF-8 accents, and my key (until yesterday) wasn't registered to my name with such accents. Beware.
Then I tried to dput the package, which finishes successfully, but the package doesn't show up on 'my packages' (maybe because there is already your identical version?).
Yeah, mentors was confused by a combination of my and your files. I deleted the package and re-uploaded it.
Do you have a pointer to some step-by-step documentation for newbies? I have already read [1], [2], and [3] but find it a bit difficult to figure out all of the details.
In general, I use the build script to build the package, and before or after uploading (depending on how up-to-date my installation is), lintian will tell me all the things that have bitrotten since last time. Then, I cry, follow the links, maybe connect to irc.oftc.net channel #debian-mentors for help, and do lots of trials and errors, using git commit --amend and git tag -f 3.1.4, until eventually I get a trial without error.
[1] https://mentors.debian.net/intro-maintainers
Maybe you could download and review my version, which corresponds to
I recommend you don't bother with the scripts in master, and instead use the tools in the minimakefile branch, due to be merged RSN.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Violent revolutions, like the state, place the initiation of violence at the center of their moral universe. The rebels believe it is morally justifiable to initiate violence to accomplish their goals. Therefore, the victor in that revolution is of little consequence because society will still be ruled by those who grant moral sanction to the initiation of violence to impose their will on others.
Violent revolution is akin to changing lanes on the highway, or even changing to a different car. It may seem different for a bit, but you're still heading in the same direction. You won't see real change toward a free society until you get off the goddamn highway of violence and embrace the non-aggression principle. — Joseph Moutard
Hi Faré,
On 2014-10-11 04:20 CEST, Faré fare@tunes.org wrote:
On Fri, Oct 10, 2014 at 6:53 PM, Kambiz Darabi darabi@m-creations.com wrote: [...] Mind that the correct release script is in the minimakefile branch, that I believe Robert is evaluating for merge into master. Also mind that said release script is too dumb to handle patches, and only works if your git tag 3.1.4 is the same as the HEAD of the build branch (by default, release). You can use git tag -f 3.1.4 to make several attempts. But of course, now that the upstream and debian maintainers are distinct, you can't do that anymore, or only as a temporary local kluge. Two solutions:
- modify the release script to actually handle debian patches the hard way,
whereby we fork a debian branch off of the release branch, and create files in debian/patches/ as necessary. Yuck.
Yes, I was bitten by it and this solution is really messy.
- cheat better, so that the release script doesn't use the version 3.1.4
as the base tag, but whatever is at the HEAD of the release branch; then you commit your debian changes to release (or debian) and commit --amend until you're happy.
With the change in [1] I can build off a branch 3.1.4, which I would create temporarily for the debian release process.
[...] I recommend you don't bother with the scripts in master, and instead use the tools in the minimakefile branch, due to be merged RSN.
Yes, with those tools and the change in [1] it was a breeze. Thank you! I hope Robert will merge the branch eventually.
When you're done, you (if you are a committer) or the maintainer can merge your changes into master.
I would propose the following workflow:
- I create a branch '3.x.y' and commit/amend until I'm happy
- I push the branch to my github repo
- Robert and others review the changes
- I build the package off that branch and upload it
This way, Robert and others will have the opportunity to veto the upload.
Robert and others on the list, what do you think?
Cheers
Kambiz
[1] https://github.com/darabi/asdf/commit/3e57db9e1e3488ed0269ea1d301fa29f0b83ed...
On Sat, Oct 11, 2014 at 6:47 AM, Kambiz Darabi darabi@m-creations.com wrote:
[...] I recommend you don't bother with the scripts in master, and instead use the tools in the minimakefile branch, due to be merged RSN.
Yes, with those tools and the change in [1] it was a breeze. Thank you! I hope Robert will merge the branch eventually.
OK. What about: 1- we wait for some Debian uploader to upload my package. 2- meanwhile you create a package 2:3.1.4-2 using your tools as a demo. 3- after everyone is satisfied, you either publish your package (if it provides additional features) or don't but either way you're 100% ready for next release — pushing is just ./tools/asdf-tools publish-debian-package
When you're done, you (if you are a committer) or the maintainer can merge your changes into master.
I would propose the following workflow:
- I create a branch '3.x.y' and commit/amend until I'm happy
That sounds good... except that if the tag already exists (as created by Robert when releasing), then you might not be able to create a same-named branch. You could call it the debian branch, or just work off the release branch, in a forked github repository (or the official one, when everyone's happy).
I push the branch to my github repo
Robert and others review the changes
I build the package off that branch and upload it
This way, Robert and others will have the opportunity to veto the upload.
Robert and others on the list, what do you think?
Sounds great to me.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org hMoney is like an arm or leg — use it or lose it. — Henry Ford
Looking at your patch https://github.com/darabi/asdf/commit/3e57db9e1e3488ed0269ea1d301fa29f0b83ed...
1- When you comment out (--git-upstream-tag="%(version)s"), which tree does it use as upstream? The current one? I suppose that will work.
2- What does --git-submodule do? Is it supposed to include the contents of ext/ in the tarball? That's something we explicitly do NOT want in general — at least, we want to NOT include any of them in the .all.deb. Is the issue that otherwise robots can't build the package because the asdf-tools are used at build time and then we need to package each of the dependencies in its own .deb? But I believe we are NOT using the asdf-tools at package build time, only while extracting the package from source.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Tomorrow will be different from today and from anything that existed in the past. Tomorrow is a utopia. The only question is to determine which.
Hi Faré,
On 2014-10-11 16:55 CEST, Faré fare@tunes.org wrote:
Looking at your patch https://github.com/darabi/asdf/commit/3e57db9e1e3488ed0269ea1d301fa29f0b83ed...
1- When you comment out (--git-upstream-tag="%(version)s"), which tree does it use as upstream? The current one? I suppose that will work.
It uses upstream/3.1.4. I renamed the upstream origin to point at my github fork.
2- What does --git-submodule do? Is it supposed to include the contents of ext/ in the tarball?
If you mean cl-asdf_3.1.4.orig.tar.gz, then yes, it includes the content of ext/ in the tarball.
How else could people apt-get source cl-asdf and be able to build the package themselves?
That's something we explicitly do NOT want in general — at least, we want to NOT include any of them in the .all.deb.
_all.deb is another story: it contains the subdirectories which are specified explicitly in debian/cl-asdf.dirs:
build/ uiop/ uiop/contrib/ contrib/ tools/
Is the issue that otherwise robots can't build the package because the asdf-tools are used at build time and then we need to package each of the dependencies in its own .deb? But I believe we are NOT using the asdf-tools at package build time, only while extracting the package from source.
IIUC, asdf-tools are needed for the build process itself, so they should be part of the source package such that a debian user who would like to build the package him/herself would be able to do so.
And because the .gitmodules information is lost during debian packaging, it is necessary to have the code of the ext/ submodules in the .orig.tar.gz. Otherwise nobody could build the package without hunting the dependencies.
Or do I misunderstand something?
Kambiz
On Sat, Oct 11, 2014 at 1:24 PM, Kambiz Darabi darabi@m-creations.com wrote:
1- When you comment out (--git-upstream-tag="%(version)s"), which tree does it use as upstream? The current one? I suppose that will work.
It uses upstream/3.1.4. I renamed the upstream origin to point at my github fork.
OK. So you can play git tag -f games with upstream/ which doesn't impact Robert's ability to tag 3.1.4. Nice.
2- What does --git-submodule do? Is it supposed to include the contents of ext/ in the tarball?
If you mean cl-asdf_3.1.4.orig.tar.gz, then yes, it includes the content of ext/ in the tarball.
How else could people apt-get source cl-asdf and be able to build the package themselves?
I don't believe you need it at all: the asdf-tools script is required for doing the magic git manipulations that create the files constituting the debian package (*.dsc, *.orig.tar.gz, ...), but once you have them, you don't need asdf-tools anymore, nor any of its dependencies. The debian build scripts do NOT invoke asdf-tools. Only the release process uses it, and it's done by the maintainer and/or you, not by debian users.
Is the issue that otherwise robots can't build the package because the asdf-tools are used at build time and then we need to package each of the dependencies in its own .deb? But I believe we are NOT using the asdf-tools at package build time, only while extracting the package from source.
IIUC, asdf-tools are needed for the build process itself, so they should be part of the source package such that a debian user who would like to build the package him/herself would be able to do so.
And because the .gitmodules information is lost during debian packaging, it is necessary to have the code of the ext/ submodules in the .orig.tar.gz. Otherwise nobody could build the package without hunting the dependencies.
Or do I misunderstand something?
Right now there is no use of asdf-tools in the debian build process. If there ever is, the Right Thing(tm) to do would be to use dim's quicklisp-to-debian scripts to package each of the dependencies and include them as builddeps, and NOT to use ext/ for this purpose.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Suicidal terrorists may have short shelf lives. — John McCarthy
-
Faré -
Kambiz Darabi -
Robert Goldman