MinGW - Minimalist GNU for Windows

On Sun, Jul 29, 2012 at 4:05 PM, Keith Marshall wrote:

> Obviously, I can kludge this in code, such as attached, but I don't like
> this hack.  Any objections to me removing the redundancy at source, in
> mingw-dist?

I have no objection to changing mingw-dist.  One thing to note is that
it also changes ``mingw-get list'' but I don't consider that an issue.

-- 
Earnie
-- https://sites.google.com/site/earnieboyd

On 29/07/12 21:14, Earnie Boyd wrote:
> I have no objection to changing mingw-dist.  One thing to note is that
> it also changes ``mingw-get list''

I know...

> but I don't consider that an issue.

Nor do I.  On the contrary, the redundancy appears in the output of
"mingw-get list ..." (or "mingw-get show ...") too.  The output from
both of these begins with the package identification header, (which
includes the package name); this is immediately followed by the title
and then the package description, so the redundancy is both ugly and
unnecessary in this context too.

-- 
Regards,
Keith.

On 7/29/2012 4:14 PM, Earnie Boyd wrote:
> On Sun, Jul 29, 2012 at 4:05 PM, Keith Marshall wrote:
> 
>> Obviously, I can kludge this in code, such as attached, but I don't like
>> this hack.  Any objections to me removing the redundancy at source, in
>> mingw-dist?
> 
> I have no objection to changing mingw-dist.  One thing to note is that
> it also changes ``mingw-get list'' but I don't consider that an issue.
> 

Go ahead and remove the redundant text.

--
Chuck

On 31/07/12 00:12, Charles Wilson wrote:
> Go ahead and remove the redundant text.

Done.  All pushed to the new git repository, and published to FRS.  This
makes the old CVS repository obsolete, so please don't use it any
longer; I guess we should lock it down, to prevent further usage.

I wish everything was as easy as one for loop, running a sed filter on
all .xml files in the tree, and completed in seconds :)

-- 
Regards,
Keith.

Op 31-7-2012 22:24, Keith Marshall schreef:
> On 31/07/12 00:12, Charles Wilson wrote:
>> Go ahead and remove the redundant text.
> Done.  All pushed to the new git repository, and published to FRS.  This
> makes the old CVS repository obsolete, so please don't use it any
> longer; I guess we should lock it down, to prevent further usage.
>
> I wish everything was as easy as one for loop, running a sed filter on
> all .xml files in the tree, and completed in seconds :)
>

Hi Keith,

I think you forgot to run an "mingw-get update" before you changed the 
xml files. I just noticed that dos2unix has been set back to version 
5.3.3. I will re-upload the latest xml files with the double name removed.

regards,

-- 
Erwin Waterlander
http://waterlan.home.xs4all.nl/

On 07/09/12 07:24, Erwin Waterlander wrote:
> Op 31-7-2012 22:24, Keith Marshall schreef:
>> On 31/07/12 00:12, Charles Wilson wrote:
>>> Go ahead and remove the redundant text.
>>
>> Done.  All pushed to the new git repository, and published to FRS.  This
>> makes the old CVS repository obsolete, so please don't use it any
>> longer; I guess we should lock it down, to prevent further usage.
>>
>> I wish everything was as easy as one for loop, running a sed filter on
>> all .xml files in the tree, and completed in seconds :)
>
> Hi Keith,
>
> I think you forgot to run an "mingw-get update" before you changed the
> xml files.

Why would I?  It is irrelevant.  I did an hg clone from the new git 
repository, (which, at the time should have been 100% consistent with 
the old CVS content).

> I just noticed that dos2unix has been set back to version 5.3.3.

Then, I guess that the changes for your newer version didn't get pushed 
to CVS, (or latterly to the git origin repository).

> I will re-upload the latest xml files with the double name removed.

That, alone, is not sufficient.  We need to ensure that *all* future 
updates get pushed to the new git repository; this is now the *sole* 
determinant of the current distribution state.

Earnie, should we not grant Erwin git push access for mingw-dist?


-- 
Regards,
Keith.

Op 7-9-2012 9:18, Keith Marshall schreef:
> On 07/09/12 07:24, Erwin Waterlander wrote:
>> Hi Keith,
>>
>> I think you forgot to run an "mingw-get update" before you changed the
>> xml files.
> Why would I?  It is irrelevant.  I did an hg clone from the new git
> repository, (which, at the time should have been 100% consistent with
> the old CVS content).
>
>> I just noticed that dos2unix has been set back to version 5.3.3.
> Then, I guess that the changes for your newer version didn't get pushed
> to CVS, (or latterly to the git origin repository).

Perhaps I followed the wrong procedure. I always uploaded the files 
directly to the catalogue in the Files section. Should I have used CVS 
in the past?

>
>> I will re-upload the latest xml files with the double name removed.
> That, alone, is not sufficient.  We need to ensure that *all* future
> updates get pushed to the new git repository; this is now the *sole*
> determinant of the current distribution state.

You mean that all files under the Files section are first pushed to git, 
and then automatically synced to Files? How does it work?

>
> Earnie, should we not grant Erwin git push access for mingw-dist?
>
>

-- 
Erwin Waterlander
http://waterlan.home.xs4all.nl/

On Fri, Sep 7, 2012 at 3:18 AM, Keith Marshall wrote:
>
> Earnie, should we not grant Erwin git push access for mingw-dist?
>

Yes, it is done by modifying the REPO_DIR/hooks/pre-receive script as
well as a checkbox on SF member controls.  We might want to create a
better method of control; what we have now is a bit loose.  I'll have
time to login to mingw.shell.sf.net next week.

-- 
Earnie
-- https://sites.google.com/site/earnieboyd

> Op 31-7-2012 22:24, Keith Marshall schreef:
>> Done.  All pushed to the new git repository, and published to FRS.  This
>> makes the old CVS repository obsolete, so please don't use it any
>> longer; I guess we should lock it down, to prevent further usage.

I've been trying to determine if we should have SF remove the CVS
repository?  But for the time being perhaps we should remove all
karma.

-- 
Earnie
-- https://sites.google.com/site/earnieboyd

On Fri, Sep 7, 2012 at 3:45 AM, Erwin Waterlander wrote:
> Perhaps I followed the wrong procedure. I always uploaded the files
> directly to the catalogue in the Files section. Should I have used CVS
> in the past?
>

Yes.

>
> You mean that all files under the Files section are first pushed to git,
> and then automatically synced to Files? How does it work?

And you need to push to the FRS.

-- 
Earnie
-- https://sites.google.com/site/earnieboyd

Op 7-9-2012 13:45, Earnie Boyd schreef:
> On Fri, Sep 7, 2012 at 3:45 AM, Erwin Waterlander wrote:
>> Perhaps I followed the wrong procedure. I always uploaded the files
>> directly to the catalogue in the Files section. Should I have used CVS
>> in the past?
>>
> Yes.
>
>> You mean that all files under the Files section are first pushed to git,
>> and then automatically synced to Files? How does it work?
> And you need to push to the FRS.
>
Okay. Can you help me a little bit? I have only a little experience with 
git.

How do I clone the repo? The command shown at 
http://sourceforge.net/projects/mingw/develop gives me an empty repo.

$ git clone ssh://waterlan@...>
Cloning into 'mingw'...
The authenticity of host 'mingw.git.sourceforge.net (216.34.181.91)' 
can't be established.
RSA key fingerprint is 86:7b:1b:12:85:35:8a:b7:98:b6:d2:97:5e:96:58:1d.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'mingw.git.sourceforge.net,216.34.181.91' 
(RSA) to the list of known hosts.
Password:
warning: You appear to have cloned an empty repository.


And how do I push back to the master repo, and how to the FRS?

regards,

-- 
Erwin Waterlander
http://waterlan.home.xs4all.nl/

On Fri, Sep 7, 2012 at 9:38 AM, Erwin Waterlander wrote:
> Op 7-9-2012 13:45, Earnie Boyd schreef:
>> On Fri, Sep 7, 2012 at 3:45 AM, Erwin Waterlander wrote:
>>> Perhaps I followed the wrong procedure. I always uploaded the files
>>> directly to the catalogue in the Files section. Should I have used CVS
>>> in the past?
>>>
>> Yes.
>>
>>> You mean that all files under the Files section are first pushed to git,
>>> and then automatically synced to Files? How does it work?
>> And you need to push to the FRS.
>>
> Okay. Can you help me a little bit? I have only a little experience with
> git.
>
> How do I clone the repo? The command shown at
> http://sourceforge.net/projects/mingw/develop gives me an empty repo.
>
> $ git clone ssh://waterlan@...>

This is the default repository set up by SF which is unused.  You can
look at http://mingw.git.sourceforge.net/git/gitweb-index.cgi to find
a list of all the repositories.  For the xml files you want to replace
the last /mingw with /mingw-dist which will not be empty.

>
> And how do I push back to the master repo, and how to the FRS?
>

With the repo simply ``git push origin master''.  But you'll get a
notice that you cannot until we add you to the permissions for that
repository.

For the FRS, the same way you've done it before.  FRS is the SF File
Release System which is what you see at
https://sourceforge.net/projects/mingw/files/.

-- 
Earnie
-- https://sites.google.com/site/earnieboyd

Op 7-9-2012 16:49, Earnie Boyd schreef:
> On Fri, Sep 7, 2012 at 9:38 AM, Erwin Waterlander wrote:
>
>
>> Okay. Can you help me a little bit? I have only a little experience with
>> git.
>>
>> How do I clone the repo? The command shown at
>> http://sourceforge.net/projects/mingw/develop gives me an empty repo.
>>
>> $ git clone ssh://waterlan@...>
> This is the default repository set up by SF which is unused.  You can
> look at http://mingw.git.sourceforge.net/git/gitweb-index.cgi to find
> a list of all the repositories.  For the xml files you want to replace
> the last /mingw with /mingw-dist which will not be empty.

Okay, thanks. This helps.

>
>> And how do I push back to the master repo, and how to the FRS?
>>
> With the repo simply ``git push origin master''.  But you'll get a
> notice that you cannot until we add you to the permissions for that
> repository.

I committed my changes. I also noticed that mingw32-libunistring was 
missing in the repo. So I added that one too (to my local clone).

Indeed, I cannot push.

>
> For the FRS, the same way you've done it before.  FRS is the SF File
> Release System which is what you see at
> https://sourceforge.net/projects/mingw/files/.

This means, I manually lzma my xml files, and upload them via a browser 
or ftp.

I never looked into the mingw cvs/git repo before. But it is logical 
that you keep the xml files under version control. It would be handy if 
I had write permission to mingw-dist. Or else somebody else must check 
in the xml files I uploaded to FRS.

regards,

-- 
Erwin Waterlander
http://waterlan.home.xs4all.nl/

On 9/7/2012 3:18 AM, Keith Marshall wrote:
> That, alone, is not sufficient.  We need to ensure that *all* future
> updates get pushed to the new git repository; this is now the *sole*
> determinant of the current distribution state.

I thought that only those elements that are considered either "core" or 
"extension" needed to have their .xml under version control in the 
mingw-dist repository -- "contrib" elements did not.  Was I wrong about 
that?

--
Chuck

On 07/09/12 16:57, Charles Wilson wrote:
> On 9/7/2012 3:18 AM, Keith Marshall wrote:
>> That, alone, is not sufficient.  We need to ensure that *all* future
>> updates get pushed to the new git repository; this is now the *sole*
>> determinant of the current distribution state.
>
> I thought that only those elements that are considered either "core" or
> "extension" needed to have their .xml under version control in the
> mingw-dist repository -- "contrib" elements did not.  Was I wrong about
> that?

No, you are correct.  However, dos2unix is one of the core packages, so 
the requirement for version control (within mingw-dist) applies.

Regarding contrib packages, we wouldn't normally grant the contributor 
write access to the repository, so we wouldn't want to manage version 
control for them.  However, in the case of contributed packages which 
are maintained by a contributor who also maintains core packages, then 
that contributor may find it convenient to control them in mingw-dist. 
Perhaps we should add a contrib directory, to facilitate that.

One thing is certain: once a package is controlled in mingw-dist, then 
any updates which are not committed there may be lost.

-- 
Regards,
Keith.

On 07/09/12 16:25, Erwin Waterlander wrote:
> This means, I manually lzma my xml files,

No.  Here are the steps you should follow, after checking out a clean 
git clone from SF:

   $ cd mingw-dist
   $ autoconf
   $ mkdir build
   $ cd build
   $ ../configure
   $ make

Only when you've done this, which creates a complete set of current 
.xml.lzma files in your build tree, should you proceed to apply any XML 
changes in the source tree; (when you do this, don't touch the issue 
numbers -- make will adjust them automatically).

After you've applied your source changes, you run make again (in the 
build tree).  This will regenerate the .xml.lzma for the sources you've 
modified; it will also collect links to everything you need to upload to 
FRS, in "unpublished" sudirectories of each build directory.

> and upload them via a browser or ftp.

You may choose whatever method suits you best; I normally use sftp. 
Just be sure to upload everything which appears in your

   mingw-dist/build/*/unpublished

directories.  Then, when you've confirmed that everything has been 
safely uploaded, you may delete the content of those.

> I never looked into the mingw cvs/git repo before. But it is logical
> that you keep the xml files under version control. It would be handy if
> I had write permission to mingw-dist.

Yeah, we'll sort that out for you.  We'll also need to augment the 
existing .cvsignore with a .gitignore, (and perhaps also a .hgignore).

> Or else somebody else must check in the xml files I uploaded to FRS.

No.  It's better if you can do it yourself.  It's also a good idea for 
you to push promptly, (and to always pull immediately before each batch 
of updates), lest two of us happen to modify the same source within a 
common update interval, and induce an issue number race.

-- 
Regards,
Keith.

Op 7-9-2012 19:20, Keith Marshall schreef:
> On 07/09/12 16:57, Charles Wilson wrote:
>> On 9/7/2012 3:18 AM, Keith Marshall wrote:
>>> That, alone, is not sufficient.  We need to ensure that *all* future
>>> updates get pushed to the new git repository; this is now the *sole*
>>> determinant of the current distribution state.
>> I thought that only those elements that are considered either "core" or
>> "extension" needed to have their .xml under version control in the
>> mingw-dist repository -- "contrib" elements did not.  Was I wrong about
>> that?
> No, you are correct.  However, dos2unix is one of the core packages, so
> the requirement for version control (within mingw-dist) applies.
>
> Regarding contrib packages, we wouldn't normally grant the contributor
> write access to the repository, so we wouldn't want to manage version
> control for them.  However, in the case of contributed packages which
> are maintained by a contributor who also maintains core packages, then
> that contributor may find it convenient to control them in mingw-dist.
> Perhaps we should add a contrib directory, to facilitate that.
>
> One thing is certain: once a package is controlled in mingw-dist, then
> any updates which are not committed there may be lost.
>

I don't need write access if one of you is willing to commit the 
dos2unix xml files. I'm fine with that.

regards,

-- 
Erwin Waterlander
http://waterlan.home.xs4all.nl/

On Fri, Sep 7, 2012 at 1:20 PM, Keith Marshall wrote:
> On 07/09/12 16:57, Charles Wilson wrote:
>> On 9/7/2012 3:18 AM, Keith Marshall wrote:
>>> That, alone, is not sufficient.  We need to ensure that *all* future
>>> updates get pushed to the new git repository; this is now the *sole*
>>> determinant of the current distribution state.
>>
>> I thought that only those elements that are considered either "core" or
>> "extension" needed to have their .xml under version control in the
>> mingw-dist repository -- "contrib" elements did not.  Was I wrong about
>> that?
>
> No, you are correct.  However, dos2unix is one of the core packages, so
> the requirement for version control (within mingw-dist) applies.
>
> Regarding contrib packages, we wouldn't normally grant the contributor
> write access to the repository, so we wouldn't want to manage version
> control for them.  However, in the case of contributed packages which
> are maintained by a contributor who also maintains core packages, then
> that contributor may find it convenient to control them in mingw-dist.
> Perhaps we should add a contrib directory, to facilitate that.
>
> One thing is certain: once a package is controlled in mingw-dist, then
> any updates which are not committed there may be lost.

We could reverse the logic of the pre-receive script and open it up
for everyone who is a member of the project and  has the git
repository checked on the member admin form for the mingw-dist
repository or another mingw-dist-contrib repository.  Only if someone
screws it up more than once would we lock out that user.

-- 
Earnie
-- https://sites.google.com/site/earnieboyd

Keith Marshall schreef, Op 7-9-2012 19:55:
> On 07/09/12 16:25, Erwin Waterlander wrote:
>> This means, I manually lzma my xml files,
> No.  Here are the steps you should follow, after checking out a clean
> git clone from SF:
>
>     $ cd mingw-dist
>     $ autoconf
>     $ mkdir build
>     $ cd build
>     $ ../configure
>     $ make
>
> Only when you've done this, which creates a complete set of current
> .xml.lzma files in your build tree, should you proceed to apply any XML
> changes in the source tree; (when you do this, don't touch the issue
> numbers -- make will adjust them automatically).
>
> After you've applied your source changes, you run make again (in the
> build tree).  This will regenerate the .xml.lzma for the sources you've
> modified; it will also collect links to everything you need to upload to
> FRS, in "unpublished" sudirectories of each build directory.

Okay, thanks. When I have write permission I will try. I just released a 
new dos2unix.

>
>> and upload them via a browser or ftp.
> You may choose whatever method suits you best; I normally use sftp.

My favourite is lftp.

> Just be sure to upload everything which appears in your
>
>     mingw-dist/build/*/unpublished
>
> directories.  Then, when you've confirmed that everything has been
> safely uploaded, you may delete the content of those.
>
>> I never looked into the mingw cvs/git repo before. But it is logical
>> that you keep the xml files under version control. It would be handy if
>> I had write permission to mingw-dist.
> Yeah, we'll sort that out for you.  We'll also need to augment the
> existing .cvsignore with a .gitignore, (and perhaps also a .hgignore).
>
>> Or else somebody else must check in the xml files I uploaded to FRS.
> No.  It's better if you can do it yourself.  It's also a good idea for
> you to push promptly, (and to always pull immediately before each batch
> of updates), lest two of us happen to modify the same source within a
> common update interval, and induce an issue number race.
>

Okay. I'll do it.

best regards,

-- 
Erwin Waterlander
http://waterlan.home.xs4all.nl/

On 08/09/12 07:59, Erwin Waterlander wrote:
> When I have write permission I will try. I just released a
> new dos2unix.

Unless I've missed something, you should now be good to go.

-- 
Regards,
Keith.

Op 8-9-2012 11:16, Keith Marshall schreef:
> On 08/09/12 07:59, Erwin Waterlander wrote:
>> When I have write permission I will try. I just released a
>> new dos2unix.
> Unless I've missed something, you should now be good to go.
>

Yes, it works fine now. Also the building of the xml.lzma files works 
perfectly.

I pushed my changes to mingw-dist and uploaded two new dos2unix xml.lzma 
files to FRS.

I did not add mingw32-libunistring, because it is in the Contributed 
section (like PDCurses).

Thanks Earnie and Keith for all the help.

regards,

-- 
Erwin Waterlander
http://waterlan.home.xs4all.nl/

On 09/09/12 08:09, Erwin Waterlander wrote:
> I pushed my changes to mingw-dist and uploaded two new dos2unix xml.lzma
> files to FRS.

Thanks, Erwin.  Please also update the ChangeLog, and push that too.

-- 
Regards,
Keith.

Op 9-9-2012 10:30, Keith Marshall schreef:
> On 09/09/12 08:09, Erwin Waterlander wrote:
>> I pushed my changes to mingw-dist and uploaded two new dos2unix xml.lzma
>> files to FRS.
> Thanks, Erwin.  Please also update the ChangeLog, and push that too.
>

Done.

-- 
Erwin Waterlander
http://waterlan.home.xs4all.nl/

On 09/09/12 10:18, Erwin Waterlander wrote:
> Op 9-9-2012 10:30, Keith Marshall schreef:
>> On 09/09/12 08:09, Erwin Waterlander wrote:
>>> I pushed my changes to mingw-dist and uploaded two new dos2unix xml.lzma
>>> files to FRS.
>>
>> Thanks, Erwin.  Please also update the ChangeLog, and push that too.
>
> Done.

Thanks, but I'm puzzled: neither of your post-commit e-mail messages 
seem to show updates to the mingw32/issue.log or msys/issue.log files. 
Those should be automatically updated when you run make, and it's 
imperative that they be captured in the commit -- it is they which drive 
the automatic issue number generation, and collection of unpublished 
files with each update.

Perhaps you neglected to 'git add' them, prior to committing?  Does
'git status' still show them as dirty, in your working tree?

-- 
Regards,
Keith.

Op 9-9-2012 11:52, Keith Marshall schreef:
> On 09/09/12 10:18, Erwin Waterlander wrote:
>> Op 9-9-2012 10:30, Keith Marshall schreef:
>>> On 09/09/12 08:09, Erwin Waterlander wrote:
>>>> I pushed my changes to mingw-dist and uploaded two new dos2unix xml.lzma
>>>> files to FRS.
>>> Thanks, Erwin.  Please also update the ChangeLog, and push that too.
>> Done.
> Thanks, but I'm puzzled: neither of your post-commit e-mail messages
> seem to show updates to the mingw32/issue.log or msys/issue.log files.
> Those should be automatically updated when you run make, and it's
> imperative that they be captured in the commit -- it is they which drive
> the automatic issue number generation, and collection of unpublished
> files with each update.
>
> Perhaps you neglected to 'git add' them, prior to committing?  Does
> 'git status' still show them as dirty, in your working tree?
>

I forgot to 'git add' them. I have pushed them now. Thanks for noticing.

-- 
Erwin Waterlander
http://waterlan.home.xs4all.nl/

On Sun, Sep 9, 2012 at 7:19 AM, Erwin Waterlander wrote:
>
> I forgot to 'git add' them. I have pushed them now. Thanks for noticing.
>

I usually will do ``git status'' prior to committing to make sure I
haven't missed something obvious.  A ``git add -u'' will always add
the modifications to the tracked files without needing to name each
one.

-- 
Earnie
-- https://sites.google.com/site/earnieboyd