Re: Question about version in submitting patches

[Kambiz Darabi]

Hi,

in addition to Pascal's great summary, you can also have a
look at the Semantic Versioning web site:

https://semver.org/

Cheers


Kambiz

- On 27 Nov, 2020, at 15:47, Pascal Bourguignon p...@informatimago.com 
wrote:

> Hi!
> 
> Le 27/11/2020 à 13:51, Marco Antoniotti a écrit :
>> Hi
>>
>> Sorry for the general noise, not necessarily related to the issue at hand.
>>
>> I know I am a P.I.T.A.,  but I kind of concluded that versions of the kind
>>
>>     MMDD
>>
>> Are better than
>>
>>     major.minor.small.itsy.bitsy.bit
>>
>> What do you think?
> 
> 
> Well, using a timestamp as version number is not as informative for the
> user as the semantic major.minor.bug version number.
> 
> The usual meaning being that:
> 
> - the major is incremented when incompatible changes to the API are
> made: users updating from one major to another should expect to have to
> invest some work to upgrade their stuff for the new version.
> 
> - the minor is incremented when compatible changes to the API are made
> (additions to the API, or change, with a compatibility layer provided):
> users updating from one minor to another can expect to only have to
> recompile their stuff for the new version, if at all, and no more work.
> 
> - the bug is incremented when bug corrections are made, without any
> change to the API: user updating from one bug to another can expect
> total compatibility and no work at all on their part.
> 
> 
> Instead of that, if you use a timestamp as version number, you now have
> to keep metadata, such as what versions are LTS (long term support), or
> other such attributes.  This works for whole distributions, but not for
> single libraries.
> 
> 
> --
> __Pascal Bourguignon__

RFS: cl-asdf/3.3.1 - Another System Definition Facility

[Kambiz Darabi]

Hello,

I have packaged the new upstream release 3.3.1 of the Common Lisp ASDF
software and looking for a sponsor:

 Package name: cl-asdf
 Version : 2:3.3.1-1
 Upstream Author : Robert P. Goldman <rpgold...@sift.info>
 URL : https://common-lisp.net/project/asdf/
 License : Expat
 Section : lisp

The cl-asdf source package builds this binary package:

cl-asdf- Another System Definition Facility

The package appears to be lintian (2.5.59) clean, apart from:

- testsuite-autopkgtest-missing

which is in level 'info'. I will try to fix it for the next release after 
reading
the documentation.

To access further information about this package, please visit the following 
URL:

  http://mentors.debian.net/package/cl-asdf

Alternatively, you can download the package with dget using this command:

  dget -x 
http://mentors.debian.net/debian/pool/main/c/cl-asdf/cl-asdf_3.3.1-1.dsc

Changes since the last upload:

  New upstream release 3.3.1:

  * UIOP compatibility fix: Introduced new replacement "timestamp"
comparison functions, because of inadvertent change in the
API. Functions that are compatible with the old semantics are retained
as "stamp" comparison functions, but will eventually be deprecated.
  * Upgrade fix: Upgrade from 3.2.1 needed repair.
  * Syntax manipulation: Fix for bugs that could be introduced when the
default readtable was manipulated during the loading of a
defsystem-depends-on system.
  * Tests: tests for new capabilities and bugs
  * Documentation: a number of improvements and clarifications.


Thank you


Kambiz Darabi
--
m-creations gmbh
Acker 2
55116 Mainz
Germany

Debian package: signing-key.asc

[Kambiz Darabi]

Hello,

there are questions from the Debian dev who helps publishing the package
about the signing key which is in the debian/ subtree.

Can someone please comment?

Thank you


Kambiz


- Forwarded Message -
From: "Sébastien Villemot" <sebast...@debian.org>
To: "Kambiz Darabi" <dar...@m-creations.com>
Cc: 878...@bugs.debian.org
Sent: Friday, 13 October, 2017 5:07:45 PM
Subject: Re: Bug#878167: RFS: cl-asdf/3.3.0 - Another System Definition Facility

Also, there is a GPG key under debian/upstream/signing-key.asc, but I see no
signature on upstream website (https://common-lisp.net/project/asdf/archives/).

Am I missing something? Or should the key be removed?

Thanks,

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  http://sebastien.villemot.name
⠈⠳⣄  http://www.debian.org
-BEGIN PGP SIGNATURE-

iQIzBAABCAAdFiEEU5UdlScuDFuCvoxKLOzpNQ7OvkoFAlng1sEACgkQLOzpNQ7O
vkr1GxAAkOEUhLmOOHxIQE6/WWIWz5cxj77/Z3Dv2b6uHrljrS+GCWivzzcii9MD
yJ3bjdj793MAVK4cXbLywxP5ZXQ9Aw65FuV+mi3kNa9lw3bvNFIbqsyckSgcL5Iz
Q7BzUOyJiWOLVe7gOuTlHNDa+0eOvk0pycZ2QFI4nT7harAvj+9rlQW8IL7WwoDX
XYDWD7TogpMDRBf0EUb32vYF2lVZomlO9KCU/mD3OmUnxmb9Zfwc23dsJcXCOcMZ
2d67F8sr0fuDZBgpPOHmPU2/+tr7GGlGNQoULML2D2XCawMK0LNBU+JfzZbOY0N/
br1yuIjhEbIlamId+/0q6aMcBZJGh+FxsEZVXQL7ULIP3N6USnhnHghZUNK/NpbU
JUZGkrWFnSwC6kH7prMrbB/Jjia+CWDqqa/QIUQm9ixPIUj4VvZ29rnBht9lPq34
HgAYtZb08Xk9JJ9odHHg4HA5wpGTN2W/4DEiHqLfjwZSa3L2aq8NqPglAuDfJr/L
kuGHxDXNTahxZHuh5BTREC+vVZekC7kgORffHvfVDma+iypW0xp9z/YZMHpxcG+z
ZDDq8TDyOm2S4yIZDpc/LUbZnZyg4OnVDFC8JMMDt7HnD5otOe26HLlucXaPX3e3
9oJ7FnC13StJqdpwdG4NwlOQucl2S50ub0BNG4VJqQZgKibWp+I=
=wDBH
-END PGP SIGNATURE-

Uploaded 3.3.0 Debian package

[Kambiz Darabi]

Hello,

just FYI. I uploaded the Debian package, now awaiting mentors' feedback.

Cheers


Kambiz


- Forwarded Message -
From: "Kambiz Darabi" <dar...@m-creations.net>
To: "Submit Bugs" <sub...@bugs.debian.org>
Sent: Tuesday, 10 October, 2017 7:14:39 PM
Subject: RFS: cl-asdf/3.3.0 - Another System Definition Facility

Package: sponsorship-requests
Severity: normal

Dear mentors,

I have packaged the new upstream release 3.3.0 of the Common Lisp ASDF
software:

 Package name: cl-asdf
 Version : 2:3.3.0-1
 Upstream Author : Robert P. Goldman <rpgold...@sift.info>
 URL : https://common-lisp.net/project/asdf/
 License : Expat
 Section : lisp

The cl-asdf source package builds this binary package:

cl-asdf- Another System Definition Facility

The package appears to be lintian clean apart from a 
orig-tarball-missing-upstream-signature
warning which I cannot fix due to building the package from git with gbp.

To access further information about this package, please visit the following 
URL:

  http://mentors.debian.net/package/cl-asdf

Alternatively, one can download the package with dget using this command:

  dget -x 
http://mentors.debian.net/debian/pool/main/c/cl-asdf/cl-asdf_3.3.0-1.dsc


Changes since the last upload:

cl-asdf (2:3.3.0-1) unstable; urgency=medium

  Package changes:

  * Update Standards-Version to 4.1.1

  New upstream milestone:

  * Build-plan: Extensively revised the build plan process so that
:DEFSYSTEM-DEPENDS-ON would work correctly, even when depended on systems
change (which didn't work before). See our ELS demonstration about it:
"Delivering Common Lisp Applications with ASDF 3.3"
< https://github.com/fare/asdf2017 >
  * Internals: to support the above, many ASDF internals have changed.
ASDF now has the notion of multiple build phases to a common build session
(which generalizes the previous build cache). ASDF considers loading a .asd
file as an operation DEFINE-OP, and tracks as dependencies files mentioned
during in :LOAD-FILE-FORM statements, etc. Some code has moved to new
files or among old files, and between packages. Actions are now
uniformly represented as a CONS of an OPERATION and a COMPONENT, where
in some cases previously only the class of the operation was
preserved. Forcing is constrained to be uniform across all phases of a
top level ASDF operation invocation. Fixed the protocol for
resetting systems being (re)defined, allowing subclasses to define
default slot values. Remove *LOAD-SYSTEM-OPERATION*, as the current
maintainer of ECL, for which it was originally designed, decided
that it could never be made to work properly, after all.
  * ASDF: Tweak dependencies between ASDF and UIOP. To avoid DEFINE-OP
circularity, asdf.asd with no longer causes uiop.asd to be loaded.
A standalone UIOP won't be loaded at all unless it's strictly more recent
than ASDF.
  * Tests: tests for new capabilities and bugs. Test backtraces can be disabled.
  * Documentation: a number of improvements and clarifications.
  * Feature: a new feature :asdf3.3
  * ECL: restored the deprecated function MAKE-BUILD, removed in 3.2.0,
in a way that works on top of supported APIs (we still recommend you migrate
to these supported APIs). Also stop using the deprecated COMPUTE-INIT-NAME.
  * Deprecation: starting to emit STYLE-WARNINGs for deprecated
functions.  Will gradually escalate to true WARNINGs and then ERRORs.



Thank you


Kambiz Darabi
--
m-creations gmbh
Acker 2
55116 Mainz
Germany

Creating one's own quicklisp distribution (was: Work-around built-in ~/common-lisp/ in search path?)

[Kambiz Darabi]

Hi Robert,

a side note: have you ever considered creating your company-internal
quicklisp distribution?

We are in the same situation of needing defined versions of dependencies
indepent from what is in the current quicklisp dist. We solve this by
having a repository with a file which contains a list of git repos where
the master branches contain what we want to distribute in the dist.

Using shirakumo-dist [1], a new release is created with:

(asdf:load-system :m-creations-dist)
(m-creations-dist::redist)

You can then rsync the release/ subdir to a web server and your
colleagues can use the release with

(ql-dist:install-dist "http://quicklisp.sift.internal/dist1.txt;)


Nicolas Hafner pointed me to his shirakumo-dist [1] which in turn uses
Quickdist [2] which I took as blueprint for ours [3].


HTH


Kambiz


[1] https://github.com/Shirakumo/dist

[2] https://github.com/orivej/quickdist

[3] https://github.com/m-creations/m-creations-dist


On 2016-11-16 19:01 CET, Robert Goldman  wrote:

> Here's my issue:
>
> 1. I have a bunch of lisp libraries that I use on everyday things
> installed in ~/common-lisp/.  One of the systems in there is an older,
> modified version of fiveam that my company uses in many projects.
>
> 2. I have a project where we use libraries from quicklisp to make it
> easier to handle dependencies.  For this project, I run a function that
> resets the ASDF source-registry, and uses a special copy of quicklisp (a
> copy that writes its systems in a different location).
>
> 3. I cannot build my system because the version of fiveam in
> ~/common-lisp/ shadows the version of fiveam from quicklisp, which I need.
>
> 4. I don't see any OBVIOUS way to tell ASDF to ignore my ~/common-lisp/
> directory.  I can do the following:
>
>   (setf asdf:*default-source-registries*
> (remove 'asdf/source-registry::default-user-source-registry
> asdf:*default-source-registries*))
>
> but that seems really hard-core.  Would it be reasonable to make the
> defaults a little easier to override?
>
> Maybe something that's equivalent to --no-userinit and --no-sysinit when
> starting lisp -- something that will remove the user-specific entries or
> system-specific entries, respectively?
>
> I don't believe I can simply wipe the defaults, because then I might
> miss some SBCL libraries that come with the system default settings.
>
> Cheers,
> r

Debian packaging changes

[Kambiz Darabi]

Hi,

I just wanted to inform that I now have full access to the debian git
repo (thank you Faré) and have pushed the current debian/ subdir to

git://git.debian.org/git/pkg-common-lisp/cl-asdf

For those interested: I have uploaded the 3.1.7 Debian package and asked
for sponsorship at

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819181

@Robert: I had some issues for which I created a pull request at
gitlab. Could you please have a look?

https://gitlab.common-lisp.net/asdf/asdf/merge_requests/2

Thank you


Kambiz

Re: cl-asdf debian package repo

[Kambiz Darabi]

On 2016-03-24 01:07 CET, Faré  wrote:

> Never mind, I found a way to add you as an admin.
>
> My apologies for now seeing your email 13 days earlier.

No problem.

Now I can push to the repo with the address:

git+ssh://@git.debian.org/git/pkg-common-lisp/cl-asdf.git


Thank you


Kambiz

Re: cl-asdf debian package repo

[Kambiz Darabi]

Hi Faré,

On 2016-03-10 15:01 CET, Kambiz Darabi <dar...@m-creations.com> wrote:

> Hi
>
> On 2016-03-10 06:00 CET, Faré <fah...@gmail.com> wrote:
>
>> On Sun, Mar 6, 2016 at 2:33 AM, Kambiz Darabi <dar...@m-creations.com> wrote:
>>> Dear all,
>>>
>>> now that a new ASDF release seems to be imminent, I would like to repeat
>>> my question from November 2015: can someone give me push access to the
>>> debian git repo for the package?
>>>
>> Wow, I didn't know I was admin. Apparently, I can log into this account 
>> indeed!
>>
>> Can you create an account and tell me your login, so I may add you to the 
>> group?
>
> https://alioth.debian.org/users/darabi-guest/
>

did you get around to do this?

I would like to package the 3.1.7 release for inclusion in Debian
testing.

Thanks


Kambiz

Re: Fw: cl-asdf debian package repo

[Kambiz Darabi]

Hi

On 2016-03-10 06:00 CET, Faré <fah...@gmail.com> wrote:

> On Sun, Mar 6, 2016 at 2:33 AM, Kambiz Darabi <dar...@m-creations.com> wrote:
>> Dear all,
>>
>> now that a new ASDF release seems to be imminent, I would like to repeat
>> my question from November 2015: can someone give me push access to the
>> debian git repo for the package?
>>
> Wow, I didn't know I was admin. Apparently, I can log into this account 
> indeed!
>
> Can you create an account and tell me your login, so I may add you to the 
> group?

https://alioth.debian.org/users/darabi-guest/

Thanks


Kambiz

Fw: cl-asdf debian package repo

[Kambiz Darabi]

Dear all,

now that a new ASDF release seems to be imminent, I would like to repeat
my question from November 2015: can someone give me push access to the
debian git repo for the package?

The page https://alioth.debian.org/projects/pkg-common-lisp lists the
following people as project admins:

- Peter Van Eynde
- Christoph Egger
- François-René Rideau

Thank you


Kambiz

 Start of forwarded message 
From: Kambiz Darabi <dar...@m-creations.com>
To: pkg-common-lisp-devel <pkg-common-lisp-de...@lists.alioth.debian.org> 
Cc: Robert Goldman <rpgold...@sift.net>, Faré
 <fah...@gmail.com>
Subject: cl-asdf debian package repo
Date: Wed, 18 Nov 2015 10:28:52 +0100

Dear Debian Common Lisp Team,

I would like to take over the packaging of cl-asdf with approval of the
upstream maintainer Robert Goldman.

The existing debian git repo [1] has been abandoned at some point in
time and the debian/ subdir moved into the upstream repo [2].

We would like to separate the debian dir into its own repo again and the
most natural place for it would be to go back to [1].

What would be needed to give me the necessary permissions to use that
repo?


Thank you


Kambiz Darabi


[1] git://git.debian.org/git/pkg-common-lisp/cl-asdf.git
[2] https://gitlab.common-lisp.net/asdf/asdf

 Start of forwarded message 
From: Faré <fah...@gmail.com>
Date: Tue, 17 Nov 2015 16:57:35 -0500
Subject: Re: ASDF 3.1.6 debian package
To: Kambiz Darabi <dar...@m-creations.com>
Cc: Robert Goldman <rpgold...@sift.net>

...

> Can you give me push permissions to
> git://git.debian.org/git/pkg-common-lisp/cl-asdf.git or do I have to ask
> on pkg-common-l...@debian.org?
>
I do not have write access to this server. Please ask the
pkg-common-lisp team, and/or get added to the team if you're not yet a
member. (I was never officially a DM — are you?)

 End of forwarded message 
 End of forwarded message 

Re: Issues with new testing scripts

[Kambiz Darabi]

On 2016-01-02 19:42 CET, Robert Goldman  wrote:

> Sorry -- I appreciate your work to improve the process, Kambiz, but ASDF
> has just turned, against my will, into an laboratory for developing a
> CL-based scripting system.  I am absolutely unwilling to see it turn
> into a testing ground for the bleeding edge of distributed version
> control, as well.

No problem at all. I was just trying to show another possibility to
tackle the problem with the current tool set, which you expressed. But
from a purely technical point of view, which is seldom the only basis
for a decision.

Kambiz

Re: Issues with new testing scripts

[Kambiz Darabi]

On 2016-01-02 00:33 CET, Robert Goldman <rpgold...@sift.net> wrote:

> On 1/1/16 Jan 1 -6:18 AM, Kambiz Darabi wrote:
>> On 2016-01-01 09:59 CET, Kambiz Darabi <dar...@m-creations.com> wrote:
>> 
>>> Happy New Year,
>>>
>>> On 2015-12-31 16:12 CET, Robert Goldman <rpgold...@sift.net> wrote:
>>>
>>>> On 12/31/15 Dec 31 -5:46 AM, Kambiz Darabi wrote:
>>>>> On 2015-12-29 01:58 CET, Robert Goldman <rpgold...@sift.net> wrote:
>>>>>
>>>>>> The problem of having clones not get auto-populated seems not worse than
>>>>>> needing to do a magical incantation when you merge stuff back and forth
>>>>>> at the cost of garbling your repo.
>>>>>
>>>>> The complete magical incantation reads:
>>>>>
>>>>> git subtree add --prefix=ext/alexandria --squash 
>>>>> https://gitlab.common-lisp.net/alexandria/alexandria.git master
>>>>>
>>>>> and to update it to the lastest master, replace 'add' with 'pull'.
>>>>>
>>>>>> The submodules cause annoying quiet failures, but even when the annoying
>>>>>> quiet failures happen, you don't end up mangling your repo.
>>>>>
>>>>> The problem with submodules is that every single person who checks out
>>>>> the repo is concerned with it, whereas git subtree has to be performed
>>>>> only by one single person and for all others it just works without them
>>>>> even knowing that there is a 'subtree' being used somewhere. 
>>>>
>>>> Can you explain that stuff about needing to squash? I read the subtree
>>>> tutorial and that discussion just seemed like gibberish to me.  Very far
>>>> from clear.  Maybe it's easier than the discussion made it seem.  As I
>>>> read it, it seemed to be saying that if you didn't remember to do
>>>> --squash at the right times you would end up with a repo clogged with
>>>> duplicate commits.
>>>>
>>>> If that's the case...ugh.  But perhaps it was just a bad explanation?
>>>> Or does your subtree add expression above ensure that the squashing
>>>> becomes the default?
>>>
>>> My command above does contain the '--squash' option. The git-subtree
>>> author just chose the wrong default: usually, you are not interested in
>>> seeing each and every commit in the external repo.
>>>
>>> But again, if you do the wrong thing, it's just a matter of:
>>>
>>> git reset --hard HEAD~2
>>> git subtree add/pull --squash ...
>>>
>>>> If we could figure this out maybe subtrees would be easier.  But if you
>>>> have to remember to squash every time, forget it
>>>
>>> IMO such commands should be automated with a makefile entry, so you
>>> wouldn't have to remember the --squash option.
>
> Unfortunately, right now the makefile is in the worst condition of the
> whole project, because of the recent merge of minimakefile, which by its
> nature was largely untestable (since exercising its functionality would
> change the repository, and even the upstream repository).

AFAICS there are only two places where a remote repo ist changed:

https://gitlab.common-lisp.net/asdf/asdf/blob/master/tools/git.lisp#L18
https://gitlab.common-lisp.net/asdf/asdf/blob/master/tools/git.lisp#L44

So testing makefile changes is only a matter of renaming the remotes
'origin', 'cl.net', and 'github'.

One can even git clone locally, add the local 'remotes', name them
appropriately and test the changes.

> Indeed, just recently, I wasn't able to use the makefile to fix my
> problems with the addition of new ext/ submodules because. the
> makefile didn't work until the submodules were added.

This is also a point in favor of subtree, as the dependencies are then
part of the repo.

These 9 lines were necessary to implement the new behaviour:

https://gitlab.common-lisp.net/darabi/asdf/commit/fc24dae0a7ba8ccbe7633584da2b26846f37a48e#e603f9495ad27b4e1779e05c500c25f6cf682de8_77_60

I found it quite easy to find the correct place to modify the code
although I'm not at all familiar with the code base.

>> I pushed a branch to my repo which contains the necessary changes:
>> 
>> https://gitlab.common-lisp.net/darabi/asdf/tree/ext-subtree
>> 
>> The specification of what to get where and which version is in
>> ext/dependencies.lisp-expr
>> 
>> and
>> 
>> git checkout ext-subtree
>> make ext
>> 
>> does the job.
>
> I'm happy to consider switching

Re: Issues with new testing scripts

[Kambiz Darabi]

On 2016-01-02 09:05 CET, Faré  wrote:

>>> One thing I *like* about submodules, is that they are optional. So if
>>> I already have regular checkouts of libraries (and I do), I can use
>>> them instead of those of make ext.
>>
>> IMO it would be better to have fixed versions of the dependencies which
>> are used by each and every developer and packager.
>>
>> This is in my experience the basis of a solid and reliable build.
>>
> Yes, BUT, subtree makes it harder to distribute asdf independently
> from other libraries, which is very, very, very bad. People who use
> asdf for any serious purpose whatsoever already have their own library
> layout, packaging and versioning.

I agree fully. Only developers/packagers should need the dependencies in
ext/ and only for building and testing asdf and for nothing else.

> The last thing they want is to deal with headaches because asdf has
> another set of copies of some of the libraries that
> non-deterministically may or may not appear first when recursively
> scanning a tree. OK, since 3.1.5, the .cl-source-registry.cache should
> make that not a problem anymore. Still a potential source of confusion
> and space waste.
>
> One solution would be to have a "raw" repository for asdf alone, and a
> separate repository asdf-dev that uses git subtree to provide asdf and
> all its dependencies together.

Two repositories are maybe too much hassle. We could also have a master
branch which doesn't contain ext/* and is only updated with a new
release.

Users who just git clone https://gitlab.../asdf.git would end up with
the latest stable version which doesn't contain the ext/ dependencies
and therefore don't risk to use them when asdf is checked out in a tree
which is scanned recursively.

Developers and implementation vendors should be warned explicitly about
this change and instructed to check out the correct branch before
building/testing.

And asdf-tools can check for existence of the dependencies in ext and
warn the developers/packagers accordingly.


Kambiz

Re: Issues with new testing scripts

[Kambiz Darabi]

On 2016-01-01 18:12 CET, Faré <fah...@gmail.com> wrote:

> On Fri, Jan 1, 2016 at 7:18 AM, Kambiz Darabi <dar...@m-creations.com> wrote:
>> I pushed a branch to my repo which contains the necessary changes:
>>
>> https://gitlab.common-lisp.net/darabi/asdf/tree/ext-subtree
>>
>> The specification of what to get where and which version is in
>> ext/dependencies.lisp-expr
>>
>> and
>>
>> git checkout ext-subtree
>> make ext
>>
>> does the job.
>>
> Wait, if you still need to make ext, what is the advantage of subtree
> vs submodules?

You don't need to 'make ext' as someone who just checks out the repo.

A developer performs 'make ext' once in a while to update to current
versions of the dependencies, run the tests and then push the new
version of the dependencies. Or to reset a buggy HEAD of one of the
dependencies to a known working version.

> One thing I *like* about submodules, is that they are optional. So if
> I already have regular checkouts of libraries (and I do), I can use
> them instead of those of make ext.

IMO it would be better to have fixed versions of the dependencies which
are used by each and every developer and packager.

This is in my experience the basis of a solid and reliable build.


Kambiz

Re: Issues with new testing scripts

[Kambiz Darabi]

On 2016-01-01 09:59 CET, Kambiz Darabi <dar...@m-creations.com> wrote:

> Happy New Year,
>
> On 2015-12-31 16:12 CET, Robert Goldman <rpgold...@sift.net> wrote:
>
>> On 12/31/15 Dec 31 -5:46 AM, Kambiz Darabi wrote:
>>> On 2015-12-29 01:58 CET, Robert Goldman <rpgold...@sift.net> wrote:
>>> 
>>>> The problem of having clones not get auto-populated seems not worse than
>>>> needing to do a magical incantation when you merge stuff back and forth
>>>> at the cost of garbling your repo.
>>> 
>>> The complete magical incantation reads:
>>> 
>>> git subtree add --prefix=ext/alexandria --squash 
>>> https://gitlab.common-lisp.net/alexandria/alexandria.git master
>>> 
>>> and to update it to the lastest master, replace 'add' with 'pull'.
>>> 
>>>> The submodules cause annoying quiet failures, but even when the annoying
>>>> quiet failures happen, you don't end up mangling your repo.
>>> 
>>> The problem with submodules is that every single person who checks out
>>> the repo is concerned with it, whereas git subtree has to be performed
>>> only by one single person and for all others it just works without them
>>> even knowing that there is a 'subtree' being used somewhere. 
>>
>> Can you explain that stuff about needing to squash? I read the subtree
>> tutorial and that discussion just seemed like gibberish to me.  Very far
>> from clear.  Maybe it's easier than the discussion made it seem.  As I
>> read it, it seemed to be saying that if you didn't remember to do
>> --squash at the right times you would end up with a repo clogged with
>> duplicate commits.
>>
>> If that's the case...ugh.  But perhaps it was just a bad explanation?
>> Or does your subtree add expression above ensure that the squashing
>> becomes the default?
>
> My command above does contain the '--squash' option. The git-subtree
> author just chose the wrong default: usually, you are not interested in
> seeing each and every commit in the external repo.
>
> But again, if you do the wrong thing, it's just a matter of:
>
> git reset --hard HEAD~2
> git subtree add/pull --squash ...
>
>> If we could figure this out maybe subtrees would be easier.  But if you
>> have to remember to squash every time, forget it
>
> IMO such commands should be automated with a makefile entry, so you
> wouldn't have to remember the --squash option.

I pushed a branch to my repo which contains the necessary changes:

https://gitlab.common-lisp.net/darabi/asdf/tree/ext-subtree

The specification of what to get where and which version is in
ext/dependencies.lisp-expr

and

git checkout ext-subtree
make ext

does the job.


Cheers


Kambiz

Re: Issues with new testing scripts

[Kambiz Darabi]

Hi,

On 2015-12-19 23:52 CET, Robert Goldman  wrote:

> I'm having two issues with the new testing scripts:
>
> [...]
>
> 2.  This was just a nuisance:  three new submodules have been added, and
> "git submodule init" must be re-run when that happens.
>
> I have no idea why the git maintainers thought that a call to git
> submodule update should quietly fail to update un-initialized submodules
> (fail to update yes, QUIETLY fail to update, no).  But going forward we
> need to trumpet any changes to the submodules because of this attribute
> of git

This is the reason why I prefer 'git subtree' to 'git submodule': with
subtree the content of the ext/... directories become an integral part
of the parent repo. A simple git pull/git fetch is enough to receive the
dependencies at the correct version.

At the same time, it is possible to 'split out' the sub-repo, e. g. to
push a patch to upstream.

Kambiz

Re: Suggestions for procedure going forward

[Kambiz Darabi]

> On Thu, Nov 19, 2015 at 12:55 AM, Robert Goldman  wrote:
>> On 11/18/15 Nov 18 -11:33 PM, Steven Núñez wrote:
>>> With git you can, and usually do, have many branches, including
>>> personal ones. The pull request will be against a specific
>>> branch. I only read this message of the thread, so hope I'm
>>> answering the right question. Github has some good tutorials.
>>
>> Well the question isn't really about having many branches.  The question
>> is what happens when you have stable and development branches, and you
>> want to "jump" the stable branch to mark retiring an old stable version
>> and starting a new one?  Doesn't that involve a nasty merge or rebase?
>>
>> I can do some research, but I was hoping someone knew the answer
>>
> My bet is that they use versioned names for branch, and so never have to jump.
>
> There is no branch called "stable", there is just the 3.1 branch, the
> 3.2 branch, etc.

That's exactly what we do, just not so fine-grained at the minor number
but cutting off the release name at the major number.

We use a 'release-3' branch which contains the tags 3.0.0, 3.1.0, 3.2.0,
etc. and when the deveopment branch is ready for preparing 4.1.0, we
branch off a 'release-4' which will be tagged 4.0.0 at some point in
time.

Depending on how often we change the major version number, we either
keep the release-x branches in the repo indefinitely (which is usually
the case) or we merge them back into development ('master' in Faré's
proposal) using

git checkout master
git merge -m "Merging branch release-3 with -s ours" -s ours

After that, the content of master is exactly the same as before, but
branch release-3 is merged into master without any conflicts.

Using this method, history is preserved, but the branch can be safely
removed to avoid old branches littering the repo.

HTH


Kambiz

Re: Suggestions for procedure going forward

[Kambiz Darabi]

On 2015-11-17 18:11 CET, Robert Goldman  wrote:

> [...] 
> So I'd like to split ASDF development into stable and testing or
> something like that.
>
> Does anyone have experience doing that?  If so, please post suggestions
> for process to ASDF-devel.

If we have to support version 3.x and 4.y of a code base, then we create
a 'release-3' branch at feature freeze time and keep it after release,
so 3.1, 3.2 etc. are created from the tip of 'release-3' where we
cherry-pick (mostly bugfix) changes from master.

In the meantime, development of version 4 continues in master and when
we freeze the features for that version, we create a 'release-4' branch
which is then curated until 4.1 can be released.

This is a quite transparent model which most developers understand
immediately.

HTH


Kambiz

Re: ASDF 3.1.5 test suite issues on ACL (8.2 and 10.0 GM)

[Kambiz Darabi]

Hi,

On 2015-09-16 20:06 CEST, Faré  wrote:

> On Wed, Sep 16, 2015 at 11:46 AM, Robert Goldman  wrote:
>> [...]
>> I regret the inclusion of the bundle operations [...]

> You're underestimating what the bundle operations brought to ASDF 3,
> even on "non-C-hosted" implementations. They do work and bring a lot:
> [...]
> * image-op and program-op couldn't have been fully portable without
> bundle-operations, and wouldn't have been attempted. 

I use program-op on a regular basis and it has replaced a very complex
scripting machinery which I gladly got rid of.

Thanks


Kambiz

Re: [Asdf-devel] ASDF 3.1.4 released today

[Kambiz Darabi]

Hi Faré,

On 2014-10-11 04:20 CEST, Faré f...@tunes.org wrote:

 On Fri, Oct 10, 2014 at 6:53 PM, Kambiz Darabi dar...@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/3e57db9e1e3488ed0269ea1d301fa29f0b83ed4e


___
Asdf-devel mailing list
Asdf-devel@common-lisp.net
http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel

Re: [Asdf-devel] ASDF 3.1.4 released today

[Kambiz Darabi]

Hi Faré,

On 2014-10-11 16:55 CEST, Faré f...@tunes.org wrote:

 Looking at your patch
 https://github.com/darabi/asdf/commit/3e57db9e1e3488ed0269ea1d301fa29f0b83ed4e

 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

___
Asdf-devel mailing list
Asdf-devel@common-lisp.net
http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel

Re: [Asdf-devel] ASDF 3.1.4 released today

[Kambiz Darabi]

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 rpgold...@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

___
Asdf-devel mailing list
Asdf-devel@common-lisp.net
http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel

Re: [Asdf-devel] Merging experimental-submodules

[Kambiz Darabi]

I don't know how many people are devs and how many people just 'users'
in the sense that they clone the repo and use it without caring about
the dependencies of asdf.

But your point is definitively valid.

Cheers


Kambiz

On 2014-08-30 22:46 CEST, Faré fah...@gmail.com wrote:

 Actually, I believe git submodule is a *huge* plus in this case, since
 it means you can choose whether or not you want to checkout the
 dependencies. I for one don't usually want them to interfere with my
 otherwise checked out dependencies.

 —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org
 In Italia i fascisti si dividono in due categorie:
 i fascisti e gli antifascisti. — Ennio Flaiano


 On Sat, Aug 30, 2014 at 9:12 AM, Kambiz Darabi dar...@m-creations.com wrote:
 Hello,

 with apologies for not having done the job in the first place, I would
 recommend using subtrees [1] instead of submodules. The most promiment
 difference for people who check out and use the repo is that they don't
 have to deal with 'git submodule init, git submodule update'.

 The subtree is already in the checked out source as if it was an
 integral part of it, and it is fixed to a certain commit at the time
 when the git subtree command was issued by the maintainer(s) which
 minimises the risk of checking out an incompatible version with git
 submodule update.

 I have pushed an updated version of your experimental-submodules branch
 to

 https://github.com/darabi/asdf/commits/experimental-submodules

 As you can see, all files are already present:

 https://github.com/darabi/asdf/tree/experimental-submodules/ext/cl-ppcre

 With git subtree split, it is easily possible to fix bugs in the ext/*
 repos and contribute them back to the original repo.

 I will update the README with the exact commands which were necessary to
 create the subtrees and which ones to use to update/split the repos, if
 that file is the correct place for the documentation (maybe you would
 prefer having one single README at the top-leve).

 Cheers


 Kambiz


 [1] https://github.com/git/git/blob/master/contrib/subtree/git-subtree.txt


 On 2014-08-28 03:49 CEST, Robert P. Goldman rpgold...@sift.info wrote:

 Now is the time to speak up if there's any reason I should *not* merge
 the experimental-submodules branch, which will make ASDF freestanding by
 pulling in its build dependencies.

 I'll probably merge this and push sometime tomorrow.

 Cheers,
 r

 ___
 Asdf-devel mailing list
 Asdf-devel@common-lisp.net
 http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel

 ___
 Asdf-devel mailing list
 Asdf-devel@common-lisp.net
 http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel

___
Asdf-devel mailing list
Asdf-devel@common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel

Re: [Asdf-devel] Merging experimental-submodules

[Kambiz Darabi]

Hello,

with apologies for not having done the job in the first place, I would
recommend using subtrees [1] instead of submodules. The most promiment
difference for people who check out and use the repo is that they don't
have to deal with 'git submodule init, git submodule update'.

The subtree is already in the checked out source as if it was an
integral part of it, and it is fixed to a certain commit at the time
when the git subtree command was issued by the maintainer(s) which
minimises the risk of checking out an incompatible version with git
submodule update.

I have pushed an updated version of your experimental-submodules branch
to

https://github.com/darabi/asdf/commits/experimental-submodules

As you can see, all files are already present:

https://github.com/darabi/asdf/tree/experimental-submodules/ext/cl-ppcre

With git subtree split, it is easily possible to fix bugs in the ext/*
repos and contribute them back to the original repo.

I will update the README with the exact commands which were necessary to
create the subtrees and which ones to use to update/split the repos, if
that file is the correct place for the documentation (maybe you would
prefer having one single README at the top-leve).

Cheers


Kambiz


[1] https://github.com/git/git/blob/master/contrib/subtree/git-subtree.txt


On 2014-08-28 03:49 CEST, Robert P. Goldman rpgold...@sift.info wrote:

 Now is the time to speak up if there's any reason I should *not* merge
 the experimental-submodules branch, which will make ASDF freestanding by
 pulling in its build dependencies.

 I'll probably merge this and push sometime tomorrow.

 Cheers,
 r

 ___
 Asdf-devel mailing list
 Asdf-devel@common-lisp.net
 http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel

___
Asdf-devel mailing list
Asdf-devel@common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel

Re: [Asdf-devel] minimakefile branch

[Kambiz Darabi]

Hi Faré,

do you think it is now obsolete to create a test git repo which contains
the dependencies as git subtrees?

There is probably a small value in having a repo with versions of the
dependencies which are known to work. But I'm not sure about the
trade-off of having an additional repo.

Sorry that I didn't get around creating that repo earlier but I will
have some time during the next week and could do so, if deemed
necessary.

Cheers


Kambiz

On 2014-07-20 03:01 CEST, Faré fah...@gmail.com wrote:

 I hadn't tested the minimakefile branch with quicklisp, so of course
 it wasn't working. Fixed. All you need to bootstrap the asdf-tools is
 a recent quicklisp (and possibly removing antique cl-ppcre packages
 from debian that might take precedence).

 I just realized that with quicklisp, asdf:load-system seems to load
 already-installed quicklisp packages, but not install new ones, for
 which you need ql:quickload. Xach, is that on purpose?

 —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org
 I'll start exercising as soon as I'm into shape.

 ___
 Asdf-devel mailing list
 Asdf-devel@common-lisp.net
 http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel

___
Asdf-devel mailing list
Asdf-devel@common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel

Re: [Asdf-devel] asdf and dependencies

[Kambiz Darabi]

Hi Faré,

yes, definitely. I was on a business travel and had little time, but now
I'm back and seeing the light at the end of the tunnel.

I will create such a repo shortly and update you.

Cheers


Kambiz

On 2014-07-08 21:46 CEST, Faré fah...@gmail.com wrote:

 Dear Kambiz,

 are you still interested in making a git repository with asdf +
 dependencies as modules? It would help development and make Robert
 more comfortable with the minimakefile branch.

 —♯ƒ • François-René ÐVB Rideau •ReflectionCybernethics• http://fare.tunes.org
 Do not handicap your children by making their lives easy.
 — Robert Heinlein, Time Enough For Love

___
Asdf-devel mailing list
Asdf-devel@common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel

Re: [Asdf-devel] converting asdf build test to Lisp

[Kambiz Darabi]

On 2014-05-20 05:02 CEST, Robert Goldman rpgold...@sift.net wrote:

 A remaining problem is that now getting an ASDF development environment
 starts to be more difficult.  How are we to manage installing the
 dependencies if the ASDF development head is going to be *ahead* of the
 state of Quicklisp (and, I believe now, *incompatibly* ahead)?

Trying to set up a build environment for the minimakefile branch, I also
had to hunt the dependencies.

 It was already difficult for me using the bump script, but most of the
 makefile required only ASDF and a standard Linux or Mac +
 MacPorts|Homebrew install. I'm just worried about circular dependencies
 if we need to get a bunch of CL libraries to make this turn over.

Would you consider using git subtree?

The dependencies can live in a vendor subdir but are part of the repo,
which means that they don't have to be pulled in with a separate
checkout step (as is the case with git submodule).

It is even possible to 'splice out' changes to the dependencies
(e.g. bugfixes) and push them to their respective git repos.

The downside is that dependencies which are not maintained in git repos
would need a git mirror.

I performed the corresponding commands for

- inferior-shell
- cl-ppcre
- lisp-invocation

which you can find in the lib/ dir in

https://github.com/darabi/asdf/commits/minimakefile

I use git subtree quite often and find it is a good way of keeping
dependencies in one repo, if it is necessary.

Cheers


Kambiz

___
Asdf-devel mailing list
Asdf-devel@common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel

Re: [Asdf-devel] Wanted: Debian packager

[Kambiz Darabi]

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é fah...@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

___
Asdf-devel mailing list
Asdf-devel@common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel

Re: [Asdf-devel] Wanted: Debian packager

[Kambiz Darabi]

Hi,

On 2014-05-25 17:51 CEST, Faré fah...@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=?= f...@tunes.org
 To: Kambiz Darabi dar...@m-creations.com,
 Debian Common Lisp Team pkg-common-lisp-de...@lists.alioth.debian.org

sorry for the noise. Thank you for the response.

Cheers


Kambiz

___
Asdf-devel mailing list
Asdf-devel@common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel

Re: [Asdf-devel] Wanted: Debian packager

[Kambiz Darabi]

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é fah...@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


___
Asdf-devel mailing list
Asdf-devel@common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel

Re: [Asdf-devel] Wanted: Debian packager

[Kambiz Darabi]

Cross-posted to asdf-devel before subscribing:

 Start of forwarded message 
From: Kambiz Darabi dar...@m-creations.com
To: Faré fah...@gmail.com
Cc: Robert Goldman rpgold...@sift.info,  Debian Common Lisp Team 
pkg-common-lisp-de...@lists.alioth.debian.org,  ASDF-devel 
asdf-devel@common-lisp.net
Subject: Re: [Asdf-devel] Wanted: Debian packager
Date: Fri, 16 May 2014 08:57:10 +0200

Hello,

On 2014-05-16 07:12 CEST, Faré fah...@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
 End of forwarded message 

___
Asdf-devel mailing list
Asdf-devel@common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel