From: Erwin W. <wat...@xs...> - 2012-04-03 20:56:55
|
Keith Marshall schreef, Op 3-4-2012 22:25: > On 03/04/12 19:54, Erwin Waterlander wrote: >> The idea is to only replace the mingw32-cygutils-dos2unix package and >> keep the ming32-cygutils package, and likewise for the msys variant. The >> mingw32-cygutils-dos2unix package has no 'doc' and 'lic' component. > The 'doc' and 'lic' components are furnished by mingw32-cygutils. > AFAICS, beyond providing this documentation, together with additional > documentation for other utilities which are not provided, once the > mingw32-cygutils-dos2unix is deprecated, mingw32-cygutils ceases to > provide anything useful; both need to die together. You are right. > >> The source and license files are already specified in my xml files. >> So I think I can keep the xml files as they are. > See above. Your dos2unix package provides its own documentation and > licence components. These deprecate the corresponding mingw32-cygutils > equivalents; your XML needs to reflect this. > OK. I updated the mingw32-dos2unix.xml file. After adding the mingw32-cygutils old doc and lic packages, you can see that the doc and lic packages get updated: c:\mingw>mingw-get install mingw32-cygutils-dos2unix mingw-get: *** WARNING *** c:\mingw\var/lib/mingw-get/data/profile.xml: user configuration file missing mingw-get: *** INFO *** c:\mingw\var/lib/mingw-get/data/defaults.xml: trying system default configuration install: dos2unix-5.3.3-1-mingw32-bin.tar.lzma installing dos2unix-5.3.3-1-mingw32-bin.tar.lzma mingw-get: *** ERROR *** package dos2unix-5.3.3-1-mingw32-bin.tar.lzma is already installed upgrade: dos2unix-5.3.3-1-mingw32-doc.tar.lzma removing release cygutils-1.3.4-1-mingw32-doc.tar.lzma installing dos2unix-5.3.3-1-mingw32-doc.tar.lzma upgrade: dos2unix-5.3.3-1-mingw32-lic.tar.lzma removing release cygutils-1.3.4-1-mingw32-lic.tar.lzma installing dos2unix-5.3.3-1-mingw32-lic.tar.lzma regards, -- Erwin Waterlander http://waterlan.home.xs4all.nl/ |
From: Charles W. <cwi...@us...> - 2012-04-04 04:33:36
|
On 4/3/2012 4:25 PM, Keith Marshall wrote: > The 'doc' and 'lic' components are furnished by mingw32-cygutils. > AFAICS, beyond providing this documentation, together with additional > documentation for other utilities which are not provided, once the > mingw32-cygutils-dos2unix is deprecated, mingw32-cygutils ceases to > provide anything useful; both need to die together. Good point. The mingw32 variant of cygutils was there ONLY as the overarching provider of the mingw32(cygutils)dos2unix tools. If you remove them (e.g. supplant them with Erwin's tools), then all you're left with is a couple of documentation tarballs. So it appears that mingw32-cygutils.xml should be deleted, and removed from mingw32-package-list.xml. However, if we want to allow "rollback" capability to the cygutils version of dos2unix, then this "bin" needs to stay: <component class="bin"> ... <release tarname="cygutils-dos2unix-1.3.4-1-mingw32-bin.tar.lzma"> <licence tarname="cygutils-%-mingw32-%-lic.tar.%" /> <source tarname="cygutils-%-mingw32-%-src.tar.%" /> <requires eq="mingw32-libpopt-*-mingw32-*-dll-0.tar" /> </release> </component> For rollback on the "doc" and "lic" packages, you'd also need: <component class="doc"> ... <release tarname="cygutils-1.3.4-1-mingw32-doc.tar.lzma"> <licence tarname="cygutils-%-mingw32-%-lic.tar.%" /> <source tarname="cygutils-%-mingw32-%-src.tar.%" /> </release> </component> <component class="lic"> ... <release tarname="cygutils-1.3.4-1-mingw32-lic.tar.lzma"> <licence tarname="cygutils-%-mingw32-%-lic.tar.%" /> <source tarname="cygutils-%-mingw32-%-src.tar.%" /> <requires eq="mingw32-libpopt-*-mingw32-*-dll-0.tar" /> </release> </component> Alternatively, remove all references to anything cygutils-* from mingw32-dos2unix (except the alias) -- but then you're no longer able to "rollback". Note that similar arguments apply to msys-dos2unix.xml -- except that msys-cygutils.xml should stay, as msys-cygutils-bin still has useful stuff. -- Chuck |
From: Erwin W. <wat...@xs...> - 2012-04-04 17:03:26
|
Charles Wilson schreef, Op 4-4-2012 6:33: > On 4/3/2012 4:25 PM, Keith Marshall wrote: >> The 'doc' and 'lic' components are furnished by mingw32-cygutils. >> AFAICS, beyond providing this documentation, together with additional >> documentation for other utilities which are not provided, once the >> mingw32-cygutils-dos2unix is deprecated, mingw32-cygutils ceases to >> provide anything useful; both need to die together. > Good point. The mingw32 variant of cygutils was there ONLY as the > overarching provider of the mingw32(cygutils)dos2unix tools. If you > remove them (e.g. supplant them with Erwin's tools), then all you're > left with is a couple of documentation tarballs. > > So it appears that mingw32-cygutils.xml should be deleted, and removed > from mingw32-package-list.xml. > > However, if we want to allow "rollback" capability to the cygutils > version of dos2unix, then this "bin" needs to stay: > > <component class="bin"> > ... > <release tarname="cygutils-dos2unix-1.3.4-1-mingw32-bin.tar.lzma"> > <licence tarname="cygutils-%-mingw32-%-lic.tar.%" /> > <source tarname="cygutils-%-mingw32-%-src.tar.%" /> > <requires eq="mingw32-libpopt-*-mingw32-*-dll-0.tar" /> > </release> > </component> > > For rollback on the "doc" and "lic" packages, you'd also need: > > <component class="doc"> > ... > <release tarname="cygutils-1.3.4-1-mingw32-doc.tar.lzma"> > <licence tarname="cygutils-%-mingw32-%-lic.tar.%" /> > <source tarname="cygutils-%-mingw32-%-src.tar.%" /> > </release> > </component> > > <component class="lic"> > ... > <release tarname="cygutils-1.3.4-1-mingw32-lic.tar.lzma"> > <licence tarname="cygutils-%-mingw32-%-lic.tar.%" /> > <source tarname="cygutils-%-mingw32-%-src.tar.%" /> > <requires eq="mingw32-libpopt-*-mingw32-*-dll-0.tar" /> > </release> > </component> > > Alternatively, remove all references to anything cygutils-* from > mingw32-dos2unix (except the alias) -- but then you're no longer able to > "rollback". > > Note that similar arguments apply to msys-dos2unix.xml -- except that > msys-cygutils.xml should stay, as msys-cygutils-bin still has useful stuff. > > Hi, I made the changes that Charles proposed. A new xml file is at http://waterlan.home.xs4all.nl/mingw/dos2unix/ I want to test it, but I don't know how to 'rollback' to an older version with mingw-get. regards, -- Erwin Waterlander http://waterlan.home.xs4all.nl/ |
From: Keith M. <kei...@us...> - 2012-04-04 18:51:47
|
On 04/04/12 18:03, Erwin Waterlander wrote: > I made the changes that Charles proposed. A new xml file is at > http://waterlan.home.xs4all.nl/mingw/dos2unix/ > > I want to test it, but I don't know how to 'rollback' to an older > version with mingw-get. With the current publicly released version, you can't. I have a sandbox version which can do it -- see my other recent thread on the subject of forcing a specific package version. I'll try to post a snapshot of that (on my personal SF pages) tomorrow or Friday. -- Regards, Keith. |
From: Charles W. <cwi...@us...> - 2012-04-05 14:01:02
|
On 4/4/2012 1:03 PM, Erwin Waterlander wrote: > I made the changes that Charles proposed. A new xml file is at > http://waterlan.home.xs4all.nl/mingw/dos2unix/ > > I want to test it, but I don't know how to 'rollback' to an older > version with mingw-get. I've integrated the latest version with mingw-dist, and it all seems to work as expected. I was trying to upload, but...there are permission problems on the server. Some of the following are unrelated to my current problem, but they still need to be fixed. Here is what I *would* need for *EVERYBODY* to do, if it actually worked. ssh -t $USER,mi...@sh... create cd /home/frs/project/mingw find . -user $USER -print0 | xargs -0 chgrp mingw find . -type d -user $USER ! -perm /g+w -print0 |\ xargs -0 chmod 775 find . -type f -user $USER ! -perm /g+w -print0 |\ xargs -0 chmod 664 ...where "everybody" ALSO includes the user whose login id is "dummy". Thanks, sourceforge admins, that's really helpful! However, (1) everything appears to have 'root' group ownership, and (2) we don't seem to be able to actually change the group to *our* group ('mingw'). That means that group write permission is meaningless...which means that NOBODY except the original creator of a directory can ever upload anything TO that directory, or create a subdir underneath it. That's so completely broken that I don't even have the words. Earnie, can you report this to the admins? At the very least, they should do the following: cd /home/frs/project/mingw chgrp -R mingw * chmod -R g+w * find . -user dummy -print0 | xargs chown earnie --- FWIW, everybody should ssh to sourceforge (the 'ssh -t' command, above), and edit ~/.bash_profile to add umask 002 --- -- Chuck Erwin: chmod 775 MinGW/Contributed/PDCurses |
From: Erwin W. <wat...@xs...> - 2012-04-05 20:00:20
|
Charles Wilson schreef, Op 5-4-2012 16:00: > On 4/4/2012 1:03 PM, Erwin Waterlander wrote: > >> I made the changes that Charles proposed. A new xml file is at >> http://waterlan.home.xs4all.nl/mingw/dos2unix/ >> >> I want to test it, but I don't know how to 'rollback' to an older >> version with mingw-get. > I've integrated the latest version with mingw-dist, and it all seems to > work as expected. I was trying to upload, but...there are permission > problems on the server. Some of the following are unrelated to my > current problem, but they still need to be fixed. > > Here is what I *would* need for *EVERYBODY* to do, if it actually worked. > > ssh -t $USER,mi...@sh... create > cd /home/frs/project/mingw > find . -user $USER -print0 | xargs -0 chgrp mingw > find . -type d -user $USER ! -perm /g+w -print0 |\ > xargs -0 chmod 775 > find . -type f -user $USER ! -perm /g+w -print0 |\ > xargs -0 chmod 664 > > ...where "everybody" ALSO includes the user whose login id is "dummy". > Thanks, sourceforge admins, that's really helpful! > > However, (1) everything appears to have 'root' group ownership, and (2) > we don't seem to be able to actually change the group to *our* group > ('mingw'). That means that group write permission is > meaningless...which means that NOBODY except the original creator of a > directory can ever upload anything TO that directory, or create a subdir > underneath it. > > That's so completely broken that I don't even have the words. > > Earnie, can you report this to the admins? At the very least, they > should do the following: > cd /home/frs/project/mingw > chgrp -R mingw * > chmod -R g+w * > find . -user dummy -print0 | xargs chown earnie > > > --- > FWIW, everybody should ssh to sourceforge (the 'ssh -t' command, above), > and edit ~/.bash_profile to add > > umask 002 > --- > > > Erwin: > chmod 775 MinGW/Contributed/PDCurses Hi, Whatever I try, I can't change any permission. I don't get any error message like "permission denied" or such. -bash-3.2$ pwd /home/frs/project/mingw/MinGW/Extension -bash-3.2$ ll total 8 -rw-r--r-- 1 23450 root 510 Nov 13 18:47 MinGW-Contributed-README drwxr-xr-x 3 waterlan root 80 Nov 1 17:12 PDCurses drwxr-xr-x 3 244842 root 80 Nov 1 04:13 libunistring -bash-3.2$ chmod 775 PDCurses -bash-3.2$ ll total 8 -rw-r--r-- 1 23450 root 510 Nov 13 18:47 MinGW-Contributed-README drwxr-xr-x 3 waterlan root 80 Nov 1 17:12 PDCurses drwxr-xr-x 3 244842 root 80 Nov 1 04:13 libunistring regards, -- Erwin Waterlander http://waterlan.home.xs4all.nl/ |
From: Keith M. <kei...@us...> - 2012-04-08 00:25:09
|
On 04/04/12 19:51, Keith Marshall wrote: > I have a sandbox version which can do it -- see my other recent thread > on the subject of forcing a specific package version. I'll try to post > a snapshot of that (on my personal SF pages) tomorrow or Friday. Didn't have it ready for Friday, but it's there now: https://sourceforge.net/projects/keithmarshall.u/files/ To perform a roll back, use 'mingw-get upgrade ...', e.g.: $ mingw-get upgrade "dos2unix-bin<5.0" would roll back to the last release pre-dating v5.0, which should be the old cygutils version. You can use '>', '>=', '=', '<=', or '<' as the version selector, or even a range such as '>=2.0<=5.0', (which, in this case wouldn't match any existing version). This snapshot also includes the Lua-5.2 scripting engine; I've posted an updated copy of mingw32-mingw-get.xml[*], to illustrate how that may be used, in conjunction with the new '--desktop' and '--start-menu' options, to create windows shell links (aka shortcuts). [*] If you looked at my original illustration of this concept, please note that this is an improved version, making use of additional Lua modules I've provided in libexec/mingw-get. -- Regards, Keith. |
From: Erwin W. <wat...@xs...> - 2012-04-09 15:06:55
|
Keith Marshall schreef, Op 8-4-2012 2:24: > Didn't have it ready for Friday, but it's there now: > https://sourceforge.net/projects/keithmarshall.u/files/ > > To perform a roll back, use 'mingw-get upgrade ...', e.g.: > > $ mingw-get upgrade "dos2unix-bin<5.0" > > would roll back to the last release pre-dating v5.0, which should be the > old cygutils version. You can use '>','>=', '=', '<=', or '<' as the > version selector, or even a range such as '>=2.0<=5.0', (which, in this > case wouldn't match any existing version). > Hi, Thanks Keith. It works (see below). So I think we can say now that the xml files are correct. Charles, you said you wanted to do the initial installation and changes of the xml files... best regards, Erwin C:\mingw>mingw-get upgrade "dos2unix-bin<5.0" mingw-get: *** WARNING *** c:\mingw\var/lib/mingw-get/data/profile.xml: user configuration file missing mingw-get: *** INFO *** c:\mingw\var/lib/mingw-get/data/defaults.xml: trying system default configuration upgrade: cygutils-dos2unix-1.3.4-1-mingw32-bin.tar.lzma removing release dos2unix-5.3.3-1-mingw32-bin.tar.lzma installing cygutils-dos2unix-1.3.4-1-mingw32-bin.tar.lzma C:\mingw>dos2unix --version dos2unix version 0.1.3 converts the line endings of text files from DOS style (0x0d 0x0a) to UNIX style (0x0a) C:\mingw>mingw-get upgrade "msys-dos2unix-bin<5.0" mingw-get: *** WARNING *** c:\mingw\var/lib/mingw-get/data/profile.xml: user configuration file missing mingw-get: *** INFO *** c:\mingw\var/lib/mingw-get/data/defaults.xml: trying system default configuration upgrade: cygutils-dos2unix-1.3.4-4-msys-1.0.13-bin.tar.lzma removing release dos2unix-5.3.3-1-msys-1.0.17-bin.tar.lzma installing cygutils-dos2unix-1.3.4-4-msys-1.0.13-bin.tar.lzma C:\mingw>mingw-get upgrade msys-dos2unix-bin mingw-get: *** WARNING *** c:\mingw\var/lib/mingw-get/data/profile.xml: user configuration file missing mingw-get: *** INFO *** c:\mingw\var/lib/mingw-get/data/defaults.xml: trying system default configuration upgrade: dos2unix-5.3.3-1-msys-1.0.17-bin.tar.lzma removing release cygutils-dos2unix-1.3.4-4-msys-1.0.13-bin.tar.lzma installing dos2unix-5.3.3-1-msys-1.0.17-bin.tar.lzma -- Erwin Waterlander http://waterlan.home.xs4all.nl/ |
From: Charles W. <cwi...@us...> - 2012-04-09 15:19:46
|
On 4/9/2012 11:06 AM, Erwin Waterlander wrote: > Thanks Keith. It works (see below). So I think we can say now that the > xml files are correct. Charles, you said you wanted to do the initial > installation and changes of the xml files... Yes, I will -- but *supposedly* I'm waiting on Earnie to bump my "role" from "release technician" to "shell access" since that's what SF support says we need to do, in order to upload stuff now. Never mind that I already HAVE shell access, and still can't upload stuff. Now, maybe this is just a terminology thing. And a "shell access role" has nothing to do with the fact that I can 'ssh' into a 'shell' on sourceforge. I don't really know. But I was waiting to hear, on the sf bug ticket, if Earnie had or plans to take any action. Until *something* changes, I can't upload the files. -- Chuck |
From: Keith M. <kei...@us...> - 2012-04-09 15:36:51
|
Chuck, On 09/04/12 16:19, Charles Wilson wrote: > Yes, I will -- but *supposedly* I'm waiting on Earnie to bump my "role" > from "release technician" to "shell access" since that's what SF support > says we need to do, in order to upload stuff now. > > Never mind that I already HAVE shell access, and still can't upload stuff. > > Now, maybe this is just a terminology thing. And a "shell access role" > has nothing to do with the fact that I can 'ssh' into a 'shell' on > sourceforge. I don't really know. AFAICT, you already have all the privilege you should need -- you're a project administrator, so you have exactly the same level of privilege as I, or Earnie, or Cesar; you should have sufficient clout to bump status for yourself, or any other project member. The only thing you can't do by yourself, AFAIK, is drop your own administrator status. > But I was waiting to hear, on the sf bug ticket, if Earnie had or plans > to take any action. Until *something* changes, I can't upload the files. If you can't do so, then it just doesn't work as SF say it should. Perhaps you should add your own comment to Earnie's ticket, and tell Chris Tsai that he's talking from his posterior. -- Regards, Keith. |
From: Erwin W. <wat...@xs...> - 2012-04-09 15:38:50
|
Charles Wilson schreef, Op 9-4-2012 17:19: > On 4/9/2012 11:06 AM, Erwin Waterlander wrote: >> Thanks Keith. It works (see below). So I think we can say now that the >> xml files are correct. Charles, you said you wanted to do the initial >> installation and changes of the xml files... > Yes, I will -- but *supposedly* I'm waiting on Earnie to bump my "role" > from "release technician" to "shell access" since that's what SF support > says we need to do, in order to upload stuff now. > > Never mind that I already HAVE shell access, and still can't upload stuff. > > Now, maybe this is just a terminology thing. And a "shell access role" > has nothing to do with the fact that I can 'ssh' into a 'shell' on > sourceforge. I don't really know. > > But I was waiting to hear, on the sf bug ticket, if Earnie had or plans > to take any action. Until *something* changes, I can't upload the files. > > It should be possible via the WebUI, isn't it? Not so long ago I uploaded the dos2unix packages via the web browser. regards, -- Erwin Waterlander http://waterlan.home.xs4all.nl/ |
From: Charles W. <cwi...@us...> - 2012-04-09 18:24:00
|
On 4/9/2012 12:51 PM, Keith Marshall wrote: > Maybe I can do this because I own the directory, and you can't because > you don't. I don't know, but this does seem strange... I haven't made another attempt since the original report. I will try this again tonight...Knowing sf, I wouldn't be surprised if something was "silently" fixed between then and now. ("who, us? Everything should be fine! And always has been!) -- Chuck |
From: Keith M. <kei...@us...> - 2012-04-15 13:41:17
|
On 09/04/12 16:06, Erwin Waterlander wrote: > Thanks Keith. It works (see below). So I think we can say now that the > xml files are correct. Uhmm ... not quite! $ ./mingw-get install msys-dos2unix install: dos2unix-5.3.3-1-msys-1.0.17-bin.tar.lzma installing dos2unix-5.3.3-1-msys-1.0.17-bin.tar.lzma install: dos2unix-5.3.3-1-msys-1.0.17-doc.tar.lzma installing dos2unix-5.3.3-1-msys-1.0.17-doc.tar.lzma install: dos2unix-5.3.3-1-msys-1.0.17-lic.tar.lzma installing dos2unix-5.3.3-1-msys-1.0.17-lic.tar.lzma Okay, thus far, but (after patching mingw-get to apply the wild-card for subsystem version, as mentioned elsewhere, when the user doesn't specify it explicitly, and correcting a couple of other defects) ... $ ./mingw-get upgrade msys-dos2unix=1.3.4-4 mingw-get: *** WARNING *** http://prdownloads.sourceforge.net/mingw /cygutils-dos2unix-1.3.4-4-msys-1.0.13-doc.tar.lzma?download: opened with unexpected status: code = 404 mingw-get: *** WARNING *** please report this to the mingw-get maintainer mingw-get: *** ERROR *** Get package: http://prdownloads.sourceforge.net/mingw/cygutils-dos2unix-1.3.4-4- msys-1.0.13-doc.tar.lzma?download: download failed mingw-get: *** WARNING *** http://prdownloads.sourceforge.net/mingw /cygutils-dos2unix-1.3.4-4-msys-1.0.13-lic.tar.lzma?download: opened with unexpected status: code = 404 mingw-get: *** WARNING *** please report this to the mingw-get maintainer mingw-get: *** ERROR *** Get package: http://prdownloads.sourceforge.net/mingw/cygutils-dos2unix-1.3.4-4- msys-1.0.13-lic.tar.lzma?download: download failed mingw-get: *** WARNING *** http://prdownloads.sourceforge.net/mingw /cygutils-dos2unix-1.3.4-4-msys-1.0.13-doc.tar.lzma?download: opened with unexpected status: code = 404 mingw-get: *** WARNING *** please report this to the mingw-get maintainer mingw-get: *** ERROR *** Get package: http://prdownloads.sourceforge.net/mingw/cygutils-dos2unix-1.3.4-4- msys-1.0.13-doc.tar.lzma?download: download failed mingw-get: *** WARNING *** http://prdownloads.sourceforge.net/mingw /cygutils-dos2unix-1.3.4-4-msys-1.0.13-lic.tar.lzma?download: opened with unexpected status: code = 404 mingw-get: *** WARNING *** please report this to the mingw-get maintainer mingw-get: *** ERROR *** Get package: http://prdownloads.sourceforge.net/mingw/cygutils-dos2unix-1.3.4-4- msys-1.0.13-lic.tar.lzma?download: download failed upgrade: cygutils-dos2unix-1.3.4-4-msys-1.0.13-bin.tar.lzma removing release dos2unix-5.3.3-1-msys-1.0.17-bin.tar.lzma installing cygutils-dos2unix-1.3.4-4-msys-1.0.13-bin.tar.lzma upgrade: cygutils-dos2unix-1.3.4-4-msys-1.0.13-doc.tar.lzma mingw-get: *** WARNING *** not removing installed release mingw-get: *** WARNING *** dos2unix-5.3.3-1-msys-1.0.17-doc.tar.lzma is still installed mingw-get: *** ERROR *** required package file is not available mingw-get: *** ERROR *** cannot upgrade to cygutils-dos2unix-1.3.4-4- msys-1.0.13-doc.tar.lzma mingw-get: *** ERROR *** due to previous download failure upgrade: cygutils-dos2unix-1.3.4-4-msys-1.0.13-lic.tar.lzma mingw-get: *** WARNING *** not removing installed release mingw-get: *** WARNING *** dos2unix-5.3.3-1-msys-1.0.17-lic.tar.lzma is still installed mingw-get: *** ERROR *** required package file is not available mingw-get: *** ERROR *** cannot upgrade to cygutils-dos2unix-1.3.4-4- msys-1.0.13-lic.tar.lzma mingw-get: *** ERROR *** due to previous download failure The problem here is that msys-dos2unix.xml refers to non-existent -doc and -lic archives for the msys-cygutils-dos2unix release; these should actually refer to msys-cygutils-doc and msys-cygutils-lic respectively, (*without* the -dos2unix qualifier). Attached patch msys-dos2unix-20120415-1.xml.diff suggests a naive work around for this. However, while it does work... $ ./mingw-get upgrade msys-dos2unix=1.3.4-4 upgrade: cygutils-dos2unix-1.3.4-4-msys-1.0.13-bin.tar.lzma removing release dos2unix-5.3.3-1-msys-1.0.17-bin.tar.lzma installing cygutils-dos2unix-1.3.4-4-msys-1.0.13-bin.tar.lzma upgrade: cygutils-1.3.4-4-msys-1.0.13-doc.tar.lzma removing release dos2unix-5.3.3-1-msys-1.0.17-doc.tar.lzma installing cygutils-1.3.4-4-msys-1.0.13-doc.tar.lzma upgrade: cygutils-1.3.4-4-msys-1.0.13-lic.tar.lzma removing release dos2unix-5.3.3-1-msys-1.0.17-lic.tar.lzma installing cygutils-1.3.4-4-msys-1.0.13-lic.tar.lzma ...it is *not* a good solution; it binds the cygutils-doc and -lic components too tightly to msys-dos2unix, such that the -doc and -lic components of the latter will *supplant* those of the former, when what is really required is that they *complement* them. A better solution, which I have gone ahead and implemented, is illustrated by the second attached patch, msys-dos2unix-20120415-2.xml.diff; this retains the over-qualified -doc and -lic component names, but declares them as virtual (meta) packages, (by virtue of <download tarname="none" />), then causes them to require the equivalent real package components. $ ./mingw-get upgrade msys-dos2unix=1.3.4-4 upgrade: cygutils-dos2unix-1.3.4-4-msys-1.0.13-bin.tar.lzma removing release dos2unix-5.3.3-1-msys-1.0.17-bin.tar.lzma installing cygutils-dos2unix-1.3.4-4-msys-1.0.13-bin.tar.lzma install: cygutils-1.3.4-4-msys-1.0.13-doc.tar.lzma installing cygutils-1.3.4-4-msys-1.0.13-doc.tar.lzma upgrade: cygutils-dos2unix-1.3.4-4-msys-1.0.13-doc.tar.lzma removing release dos2unix-5.3.3-1-msys-1.0.17-doc.tar.lzma installing cygutils-dos2unix-1.3.4-4-msys-1.0.13-doc.tar.lzma install: cygutils-1.3.4-4-msys-1.0.13-lic.tar.lzma installing cygutils-1.3.4-4-msys-1.0.13-lic.tar.lzma upgrade: cygutils-dos2unix-1.3.4-4-msys-1.0.13-lic.tar.lzma removing release dos2unix-5.3.3-1-msys-1.0.17-lic.tar.lzma installing cygutils-dos2unix-1.3.4-4-msys-1.0.13-lic.tar.lzma -- Regards, Keith. |
From: Erwin W. <wat...@xs...> - 2012-04-15 15:37:34
|
Op 15-4-2012 15:41, Keith Marshall schreef: > ...it is *not* a good solution; it binds the cygutils-doc and -lic > components too tightly to msys-dos2unix, such that the -doc and -lic > components of the latter will *supplant* those of the former, when what > is really required is that they *complement* them. A better solution, > which I have gone ahead and implemented, is illustrated by the second > attached patch, msys-dos2unix-20120415-2.xml.diff; this retains the > over-qualified -doc and -lic component names, but declares them as > virtual (meta) packages, (by virtue of<download tarname="none" />), > then causes them to require the equivalent real package components. > > $ ./mingw-get upgrade msys-dos2unix=1.3.4-4 > upgrade: cygutils-dos2unix-1.3.4-4-msys-1.0.13-bin.tar.lzma > removing release dos2unix-5.3.3-1-msys-1.0.17-bin.tar.lzma > installing cygutils-dos2unix-1.3.4-4-msys-1.0.13-bin.tar.lzma > install: cygutils-1.3.4-4-msys-1.0.13-doc.tar.lzma > installing cygutils-1.3.4-4-msys-1.0.13-doc.tar.lzma > upgrade: cygutils-dos2unix-1.3.4-4-msys-1.0.13-doc.tar.lzma > removing release dos2unix-5.3.3-1-msys-1.0.17-doc.tar.lzma > installing cygutils-dos2unix-1.3.4-4-msys-1.0.13-doc.tar.lzma > install: cygutils-1.3.4-4-msys-1.0.13-lic.tar.lzma > installing cygutils-1.3.4-4-msys-1.0.13-lic.tar.lzma > upgrade: cygutils-dos2unix-1.3.4-4-msys-1.0.13-lic.tar.lzma > removing release dos2unix-5.3.3-1-msys-1.0.17-lic.tar.lzma > installing cygutils-dos2unix-1.3.4-4-msys-1.0.13-lic.tar.lzma > Hi, Looks good. Erwin |
From: Charles W. <cwi...@us...> - 2012-04-10 03:18:12
|
On 4/9/2012 2:23 PM, Charles Wilson wrote: > On 4/9/2012 12:51 PM, Keith Marshall wrote: >> Maybe I can do this because I own the directory, and you can't because >> you don't. I don't know, but this does seem strange... > > I haven't made another attempt since the original report. I will try > this again tonight...Knowing sf, I wouldn't be surprised if something > was "silently" fixed between then and now. ("who, us? Everything should > be fine! And always has been!) sftp uploads (of new files, and overwriting old files) works now...even if/when I don't actually own the target file or directory, nor have the appropriate unix perms. From an ssh session, I was also able to delete mingw32-cygutils.xml.lzma (but I owned that file, so it's not a good test). So..."it" appears to now be working. It wasn't a few days ago; I got access denied errors of some kind (don't recall the exact message at this late date). Go figure. As long as we're happy to promote all the Release Technicians to Shell Access, I guess sf can close the ticket. FWIW, I've checked in all the new mingw-dist files and uploaded the modified .lzma elements...so, congrats to Erwin: dos2unix has now officially replaced cygutils-dos2unix for both mingw32 and msys. Sorry for the ordeal and thanks for your patience; isn't it fun to be a trailblazer? -- Chuck |
From: waterlan <wat...@xs...> - 2012-04-10 07:05:03
|
On 2012-04-10 05:17, Charles Wilson wrote: > FWIW, I've checked in all the new mingw-dist files and uploaded the > modified .lzma elements...so, congrats to Erwin: dos2unix has now > officially replaced cygutils-dos2unix for both mingw32 and msys. > Sorry > for the ordeal and thanks for your patience; isn't it fun to be a > trailblazer? > It is a lot of fun :) Thanks Charles and Keith for the support! Wrt to dos2unix, mingw/msys is now on par with Cygwin and practically all Linux distributions. Which means it is command-line compatible, which is handy when dos2unix is used in scripts. Redhat, Suse, and Gentoo use this implementation from the start. Many other Linux distributions switched lately (Debian, Ubuntu, Mint, Mandriva, ...) best regards, -- Erwin Waterlander http://waterlan.home.xs4all.nl/ |
From: Erwin W. <wat...@xs...> - 2012-02-23 17:04:16
|
Op 22-2-2012 23:29, Keith Marshall schreef: > On 22/02/12 18:59, Erwin Waterlander wrote: >> The current mingw-cygutils-dos2unix package ... > The current package is called "mingw32-cygutil-dos2unix"; I assume your > "mingw-..." is an accidental omission, but just in case, you need to > > s/mingw/mingw32/g > > in all instances please. I meant "mingw32". > >> ... has one alias "mingw-dos2unix". > That's not what I see: > > <package name="mingw32-cygutils-dos2unix" alias="cygutils-dos2unix"> You are right. Actually I was looking at the msys version of the cygutils xml file when I wrote that: <package name="msys-cygutils-dos2unix" alias="msys-dos2unix"> >> The name of the new package is "mingw-dos2unix". > That needs to be "mingw32-dos2unix", so you may rewrite the header as: > > <package name="mingw32-dos2unix" > alias="dos2unix cygutils-dos2unix mingw32-cygutils-dos2unix"> > > (You are allowed only one "alias" attribute, but it may specify multiple > aliases, separated by spaces). Because there is an msys version and a mingw32 version, I was thinking to omit the "dos2unix" alias. A user will have to select either msys-dos2unix or mingw32-dos2unix. So what I propose now is: For the msys version: <package name="msys-dos2unix" alias="msys-cygutils-dos2unix"> For the mingw32 version: <package name="mingw32-dos2unix" alias="mingw32-cygutils-dos2unix cygutils-dos2unix"> This way it stays backward compatible. I could add an "dos2unix" alias to the latter, making the mingw32 version the default when somebody installs 'dos2unix'. >> Where should I upload the new files? The current cygutils-dos2unix >> package resides under 'Extension'. Should I put them under >> Extension/dos2unix/5.3.2/. Or, because it's a contributed package,under >> Contributed/dos2unix/5.3.2/ > Keeping it as an "extension" package seems best to me. > I have uploaded the package files under MSYS/Extension and MinGW/Extension. Before I upload the xml files, does Charles need to modify the xml files for cygutils? regards, -- Erwin Waterlander http://waterlan.home.xs4all.nl/ |
From: Earnie B. <ea...@us...> - 2012-02-23 17:23:27
|
On Thu, Feb 23, 2012 at 12:04 PM, Erwin Waterlander wrote: > > Because there is an msys version and a mingw32 version, I was thinking > to omit the "dos2unix" alias. A user will have to select either > msys-dos2unix or mingw32-dos2unix. > If there are both our practice is to default to mingw32 so please do not omit the dos2unix alias. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Erwin W. <wat...@xs...> - 2012-02-23 17:54:33
|
Earnie Boyd schreef, Op 23-2-2012 18:23: > If there are both our practice is to default to mingw32 so please do > not omit the dos2unix alias. OK. I added the dos2unix alias. I think the xml files are now ready for upload. See http://waterlan.home.xs4all.nl/mingw/dos2unix/ -- Erwin Waterlander |
From: Earnie B. <ea...@us...> - 2012-04-05 14:38:24
|
On Thu, Apr 5, 2012 at 10:00 AM, Charles Wilson wrote: > > ...where "everybody" ALSO includes the user whose login id is "dummy". > Thanks, sourceforge admins, that's really helpful! And some are owned by some unnamed user with only an UID showing. > > However, (1) everything appears to have 'root' group ownership, and (2) > we don't seem to be able to actually change the group to *our* group > ('mingw'). That means that group write permission is > meaningless...which means that NOBODY except the original creator of a > directory can ever upload anything TO that directory, or create a subdir > underneath it. > > That's so completely broken that I don't even have the words. > > Earnie, can you report this to the admins? At the very least, they > should do the following: > cd /home/frs/project/mingw > chgrp -R mingw * I tried this, no complaint but nothing changed. > chmod -R g+w * Ditto. > find . -user dummy -print0 | xargs chown earnie I didn't try this one because it should not work. I've opened a ticket https://sourceforge.net/apps/trac/sourceforge/ticket/25126 to have the group owner changed to mingw and the permissions of all directories and files changed to add the write bit for the group. > > > --- > FWIW, everybody should ssh to sourceforge (the 'ssh -t' command, above), > and edit ~/.bash_profile to add > > umask 002 Thanks for that. Done. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Charles W. <cwi...@us...> - 2012-04-05 17:24:24
|
On 4/5/2012 10:38 AM, Earnie Boyd wrote: > On Thu, Apr 5, 2012 at 10:00 AM, Charles Wilson wrote: >> >> ...where "everybody" ALSO includes the user whose login id is "dummy". >> Thanks, sourceforge admins, that's really helpful! > > And some are owned by some unnamed user with only an UID showing. It seems that, when logged into an interactive session, they only copy your OWN uid/gid into your local chroot /etc/passwd -- so only the files you own show an actual username; everything else shows the numeric UID. If you use sftp, then the other UIDs are correctly translated to their real user name. Except for 'dummy', which is always 'dummy'. >> Earnie, can you report this to the admins? At the very least, they >> should do the following: >> cd /home/frs/project/mingw >> chgrp -R mingw * > > I tried this, no complaint but nothing changed. Exactly, which is why "they" need to do it as root. >> chmod -R g+w * > > Ditto. ditto ditto. > >> find . -user dummy -print0 | xargs chown earnie > I didn't try this one because it should not work. Right, that's something only root -- aka sf admins -- can do. > I've opened a ticket > https://sourceforge.net/apps/trac/sourceforge/ticket/25126 to have the > group owner changed to mingw and the permissions of all directories > and files changed to add the write bit for the group. Thanks. >> >> --- >> FWIW, everybody should ssh to sourceforge (the 'ssh -t' command, above), >> and edit ~/.bash_profile to add >> >> umask 002 > > Thanks for that. Done. I'm not sure if ~/.bash_profile is used during sftp sessions; I'll have to investigate that. But at least the above will fix perms for anything created during an interactive session. -- Chuck |
From: Keith M. <kei...@us...> - 2012-04-05 23:51:24
|
On 05/04/12 21:00, Erwin Waterlander wrote: > Whatever I try, I can't change any permission. I don't get any error > message like "permission denied" or such. Yet another SF cock-up! I'm getting a strong feeling of deja vu here; I've already been through the exercise of changing the permissions on everything I own, just a few months ago. IIRC, last time around everything was 644, owned by me, (or whoever else), and the group was mingw. I used sftp's 'chmod 664 *' to reset everything I owned appropriately. On that occasion, I got messages to say that permissions were being changed for the files which I owned, and error messages in respect of each file owned by others. A subsequent sftp 'ls -l' confirmed that 664 had been applied. Today, I see that all permissions have reverted to 644, and that the group has *changed* to root. Furthermore, the sftp chmod command, which did work previously, now reports success in respect of *every* file, regardless of ownership, yet it actually does NOTHING AT ALL; every file remains, stubbornly, at mode 644. Somebody at SF should be keel-hauled, for this cock-up. Earnie, do you mind if I add a comment to your ticket, to this effect? -- Regards, Keith. |
From: Earnie B. <ea...@us...> - 2012-04-06 12:37:49
|
On Thu, Apr 5, 2012 at 7:51 PM, Keith Marshall wrote: > > Somebody at SF should be keel-hauled, for this cock-up. Earnie, do you > mind if I add a comment to your ticket, to this effect? > Of course not, go ahead. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Keith M. <kei...@us...> - 2012-04-09 16:51:38
|
On 09/04/12 16:19, Charles Wilson wrote: > I can't upload the files. It seems unlikely that you would make this statement, without testing the hypothesis, but... I just used sftp to upload a fresh copy of msys-rxvt.xml.lzma, from my local sandbox, to replace the original copy owned by you, (hopefully without actually changing its content). That seemed to be successful. The ownership is still shown as yours, but the timestamp does show that the file has been updated, and the WebUI confirms that it is new, (within the last ten minutes). Maybe I can do this because I own the directory, and you can't because you don't. I don't know, but this does seem strange... -- Regards, Keith. |
From: Earnie B. <ea...@us...> - 2012-04-09 18:24:08
|
On Mon, Apr 9, 2012 at 12:51 PM, Keith Marshall wrote: > On 09/04/12 16:19, Charles Wilson wrote: >> I can't upload the files. > > It seems unlikely that you would make this statement, without testing > the hypothesis, but... > And if you have tested the "hypothesis" please comment on the ticket. -- Earnie -- https://sites.google.com/site/earnieboyd |