X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com X-Original-DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.com; h= content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=zBg9LHxD/DQ1+EOoB86UFEkqXcw=; b=Oy+CA6 pKL8nb2/v7dXXGETSRl1hGat7sX8zFcOFmRK3Xo2QszWcpAEEdjcDHabnNkfVw8S 3vUZlrM55y9XeeQSQBErizM7awkywZpmdj/FurYgb9AGsjkCK+2zjCrlu7CbJR9d DUibqyU0VLVEgb1cmEyvf7Vor+gzR2lMCOXls= X-Original-DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=smtpout; bh=zBg9LHxD/DQ1+E OoB86UFEkqXcw=; b=RnS83+UKKUq18bnF+D0bQ1P+5kevQ5wZNV4/CWvZt9pDyO 1tFfGtZbjvHIN6J3vT/8DtoxhPUvSR0JYRtbiMk4ZAqzpcgL8yXoSTOvyfyzJ6Km mKvyv0Lm0WS1NYngTJiByljBdiiuL06gwrf2GfVBcoDQWBKpvPtZNR8XQWVYo= X-ME-Sender: X-Sasl-enc: uMGV+27lhsZggX5jTbFtNnno2wi3mJjEUgh8x5vJgbGM 1482609775 Subject: Re: [geda-user] [pcb] Plans for Next Release of pcb References: <74d9e3df-7aaa-cb29-5584-8c52d19227b1 AT sbcglobal DOT net> <585E6661 DOT 8070806 AT xs4all DOT nl> <2778f2e7-cd44-7823-a80b-a6ca0635c9f8 AT iee DOT org> To: geda-user AT delorie DOT com From: "Girvin Herr (girvin_herr+gherr_lists AT fastmail DOT com) [via geda-user AT delorie DOT com]" Message-ID: <51bfdfb7-e4fd-c3c8-2a9b-3abd99ad37de@fastmail.com> Date: Sat, 24 Dec 2016 12:01:22 -0800 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <2778f2e7-cd44-7823-a80b-a6ca0635c9f8@iee.org> Content-Type: multipart/alternative; boundary="------------1568D59C84E0B0D3ACD6BF87" Reply-To: geda-user AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: geda-user AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk This is a multi-part message in MIME format. --------------1568D59C84E0B0D3ACD6BF87 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 12/24/2016 04:50 AM, M. J. Everitt (m DOT j DOT everitt AT iee DOT org) [via geda-user AT delorie DOT com] wrote: > As a prospective proxy maintainer for Gentoo, please let me know when > you roll a tarball, and I'll run through the Gentoo packaging process, > and do some preliminary build/run-testing and feed back. > If wanted, I can do the same for a Slackware Linux package. I am currently running Slackware 14.1 (k3.10.103), but I have a copy of the latest 14.2 and plan to install it early next year. The only change I can see is that the package architecture went from i486 in 14.1 to i586 in 14.2, but that is trivial. Of course, the dependencies have changed. Another option would be to contact the SlackBuilds.org pcb package maintainer, Felix Pfeifer: pfeifer [dot] felix [at] googlemail [dot] com He might be willing to do this task and put the resulting packages on SlackBuilds. geda-gaf on SlackBuilds.org seems to be maintained by a different maintainer, Stephen Van Berg: stephen_van_berg at earlicker dot com > I would second a more consistent version numbering system, as this > makes version-tracking easier for packagers too, so pcb v4 would > indeed be a good choice if settled upon! Consistency, yes. But the form doesn't matter for Slackware packaging. x.y.z is just as fine as yyyymmdd. The only caveat is that dashes may not be used in the version string. I usually change them to underscores or remove them entirely if in yyyy-mm-dd. Girvin Herr > > Good luck, thanks, and keep us posted on the list :) > > Michael. > > On 24/12/16 12:23, Peter Clifton (petercjclifton AT googlemail DOT com) [via > geda-user AT delorie DOT com] wrote: >> Nice to hear work is going on with mainline pcb as well... >> >> One thing prior to release. We ought to git rm the debian directory >> that added to the repository. >> >> This matches preferred distro policy, and makes life easier for the >> official packagers (so they can use our sources directly without >> having to repackage them to remove the debian dir. >> >> I checked this with our debian packagers some while back to confirm, >> but never got around to making the delete. >> >> Peter >> --------------1568D59C84E0B0D3ACD6BF87 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 12/24/2016 04:50 AM, M. J. Everitt (m DOT j DOT everitt AT iee DOT org) [via geda-user AT delorie DOT com] wrote:
As a prospective proxy maintainer for Gentoo, please let me know when you roll a tarball, and I'll run through the Gentoo packaging process, and do some preliminary build/run-testing and feed back.

If wanted, I can do the same for a Slackware Linux package.  I am currently running Slackware 14.1 (k3.10.103), but I have a copy of the latest 14.2 and plan to install it early next year.  The only change I can see is that the package architecture went from i486 in 14.1 to i586 in 14.2, but that is trivial.  Of course, the dependencies have changed.

Another option would be to contact the SlackBuilds.org pcb package maintainer, Felix Pfeifer:  pfeifer [dot] felix [at] googlemail [dot] com
He might be willing to do this task and put the resulting packages on SlackBuilds.

geda-gaf on SlackBuilds.org seems to be maintained by a different maintainer, Stephen Van Berg:  stephen_van_berg at earlicker dot com

I would second a more consistent version numbering system, as this makes version-tracking easier for packagers too, so pcb v4 would indeed be a good choice if settled upon!
Consistency, yes.  But the form doesn't matter for Slackware packaging.  x.y.z is just as fine as yyyymmdd.  The only caveat is that dashes may not be used in the version string.  I usually change them to underscores or remove them entirely if in yyyy-mm-dd.

Girvin Herr


Good luck, thanks, and keep us posted on the list :)

Michael.

On 24/12/16 12:23, Peter Clifton (petercjclifton AT googlemail DOT com) [via geda-user AT delorie DOT com] wrote:
Nice to hear work is going on with mainline pcb as well...

One thing prior to release. We ought to git rm the debian directory that added to the repository.

This matches preferred distro policy, and makes life easier for the official packagers (so they can use our sources directly without having to repackage them to remove the debian dir.

I checked this with our debian packagers some while back to confirm, but never got around to making the delete.

Peter


--------------1568D59C84E0B0D3ACD6BF87--