Withdrawing from the project
As I mentioned in the cygwin mailing list: I'm withdrawing from the project. I'm sending a separate note here with information about the cygwin-apps part of this decision. The upset perl script lives in ~cygwin/setup. This is also a git repository. When you push to it, it updates the active version of upset so be careful. The companion Makefile which runs upset is also in this repository/directory. Scripts for keeping cygwin alive: /sourceware/infra/bin/check-cygwin-mirrors Keeps the mirror list alive, creates the mirrors web page, and mirrors list file. Check cygwin-admin crontab file for how it is run. Someone should change the crontab to have it send email to them. It used to notify me and I temporarily just changed it to sourcemas...@sourceware.org. /sourceware/infra/bin/cygssh Adds a new user when fed SSH key for upload access mail. I've been running this script as root. I don't remember why now. Presumably it can be run as the just-created cygwin-admin user. If this actually does need root you'll need to coordinate with overseers. If I missed something look in /sourceware/infra/bin or in the cygwin-admin crontab. I'd be happy to receive well wishes or answer questions about my decision in private email (me period cgf period cx) but please don't send me questions asking how to do something on sourceware.org or within cygwin itself. I'd like to make this a clean break. So long, farewell, auf wiedersehen, goodbye. cgf
Re: [ITA] Git et al
On Sat, Jul 19, 2014 at 08:29:41AM +0100, Adam Dinwoodie wrote: I've still not been able to clone the Cygwin source code from CVS -- I've been testing by cloning the cygwin-apps repo Yaakov referenced above -- but the errors look like a version incompatibility, and I don't think there's much I can do about that. If someone who knows more about CVS and Git could take a look at the output and confirm that hypothesis, I'd be grateful: $ git cvsimport -v -d :pserver:anon...@cygwin.com:/cvs/src src Initialized empty Git repository in /home/add/test/.git/ Running cvsps... WARNING: malformed CVS version str: Server: WARNING: Your CVS client version: [Client: Concurrent Versions System (CVS) 1.12.13 (client/server)] and/or server version: [Server: ] are too old to properly support the rlog command. This command was introduced in 1.11.1. Cvsps will use log instead, but PatchSet numbering may become unstable due to pruned empty directories. cvs [log aborted]: reading from server: Connection reset by peer DONE; creating master branch fatal: refs/heads/origin: not a valid SHA1 fatal: master: not a valid SHA1 fatal: You are on a branch yet to be born checkout failed: 32768 As I say, the cvsimport of the cygwin-apps repo is going just fine, so I don't think this is a fundamental problem with my build any more. Fingers crossed for an up-to-date Git release soon. Thanks for looking into this again. FWIW, the CVS on sourceare.org/cygwin.com is cvs-1.11.23-16.el6.x86_64. I've used it to import Cygwin's CVS into git so I know that it is possible. There is a limitation on cvsps though. As I understand it newer versions don't work with git. cvsimport also only works with cvsps v2 but that shouldn't be a problem since that's what we've got in Cygwin. cgf
Re: [ATTN maintainer] mined
On Fri, Jul 18, 2014 at 10:36:21AM +0200, Corinna Vinschen wrote: On Jul 18 06:39, Achim Gratz wrote: The mined directory for both architectures contain temporary files that apparently sftp has left there (they have the suffix SftpXFR.PID I think). These should be removed, but maybe the transfer script that moves the files from the upload area could be extended to ignore or delete such files so they never get distributed to the mirrors. I removed them on sourceware. If this happens again, please leave it for me to investigate. There is no reason why SftpXFR.PID files should be showing up in release directories. cgf
Re: cygport upload command?
On Mon, Jul 07, 2014 at 09:14:29PM -0400, Andrew Schulman wrote:
Using cygport, I think that packaging has become quite easy now. At least,
once the cygport script is built and working, updating a package to a new
release is as easy as updating the version number in the cygport script,
then running 'cygport ... download all'.
Except for one thing: the upload step. Maintainers still have to go
through the procedure at
https://sourceware.org/cygwin-apps/package-upload.html. Although it's
easier than the old manual upload process, it's still a little tedious and
error-prone.
Yaakov, would you consider adding an 'upload' command to cygport, that
would handle the uploading details? That would take away the last bit of
manual work in a routine package update.
If you don't have the time or interest to add an upload command yourself,
would you consider a patch? I've spent some time looking through cygport
code, and I might have time to give it a try, or maybe someone else would.
FWIW, this is the script that I use. Obviously the path to the upload
directory would have to be changed.
cgf
#!/usr/bin/perl
use strict;
use Getopt::Long;
my $arch = 'all';
GetOptions('a|arch:s'=\$arch);
use constant {
FTP = '/usr/bin/lftp'
};
my @arch = ();
if ($arch eq 'all') {
@arch = ('x86', 'x86_64');
} else {
@arch = $arch;
}
my $exit = 0;
for $arch (@arch) {
# ftp -c 'connect sftp://cygwin:@cygwin.com/; cd x86/release; mirror -eRN2
mutt; put /dev/null -o !ready'
chdir /netrel/uploads/$arch or die $0: couldn't cd to
/netrel/uploads/$arch - $!\n;
for my $p (@ARGV) {
print Uploading $p($arch)...\n;
my $res = system FTP, '-c', connect sftp://cygwin:\@cygwin.com/; cd
$arch/release; mirror -eR $p; put /dev/null -o !ready;
$exit ||= $res;
if (!$res) {
print done\n;
} else {
warn $0: $p upload failed\n if $res;
}
}
}
exit $exit;
Re: SSH key for upload access
On Fri, Jul 04, 2014 at 07:58:20AM +1000, Mark Hessling wrote: Name: Mark Hessling Package: regina-rexx BEGIN SSH2 PUBLIC KEY Comment: 2048-bit RSA, converted by mark@Windows7-64bit from OpenSSH B3NzaC1yc2EDAQABAAABAQCns1wj8gQNs/lmzMaqhPAyFAcCLFIm1Cqfkf7o5E yGAoMAVEMTnK3A1M0s1iGUhuX5k2r3EGPdLfsocfTRyw0+Ok5aj64sZVJc1/kaKkXw866M KTOhxlGlbilepL2y7I0BrzUcMlcA+hGjyo//5019aOBFrlV9NoglADl4GJc9RWNMe/GkLe W1kgOLZCufB8QPwsvE5cTcD4qov5A0P46HC3d1VHEA3cQzJCsNuOUdHIlXeDv/hUVWhRVs GSaqLoxpC3QRCSn8MVRQ44k56kW6gcSk2ro5YcEgtm5xMGDgbK1akTvC0GW4dnUNA5ElOi M6ZRWei2SEpT7l8KkYBFf7 END SSH2 PUBLIC KEY Activated. cgf
Re: [ITP] regina-rexx-3.8.2-1
On Thu, Jul 03, 2014 at 12:49:52PM +0200, Corinna Vinschen wrote: I've added you as regina-rexx maintainer. Can you please send your ssh key per https://sourceware.org/cygwin-apps/package-upload.html Sigh. You have to first add... Oh! Wait. Nevermind. *Blush* cgf
Re: tmux-1.9a2 ctrl+b not working
On Thu, Jun 26, 2014 at 01:56:18PM -0700, DJ Sylvester wrote: I searched Google. I looked at sourceforge tickets http://sourceforge.net/p/tmux/tickets/ I've read this Cygwin tmux announcement: https://cygwin.com/ml/cygwin-apps/2014-06/msg00018.html I've reinstalled tmux with cygwin-x86 installer. I've had no luck. ctrl+b command is not working for me. I'm running a default mintty as installed by cygwin-x86 on Win-7 with a few aliases defined, nothing else. My.tmux.conf file is empty. To reproduce: 1. start tmux 2. ctrl+b % (outputs 5u) 3. ctrl+b (no outputs, does nothing) 4. ctrl+b c (no outputs, does nothing) No commands are working. Not sure what to try next. Sorry but this isn't the right mailing list for reporting problems. Please use the cygwin mailing list for problem reports, just like it says at https://cygwin.com/lists.html#available-lists .
Re: SSH key for upload access
On Tue, Jun 10, 2014 at 07:21:30PM +0200, Thomas Wolff wrote: Name: Thomas Wolff Package: mined BEGIN SSH2 PUBLIC KEY Comment: 2048-bit RSA, converted from OpenSSH by root@MyBookLive B3NzaC1yc2EBIwAAAQEAwMSnVCjNhyiGNhBC/+uPheB4BgG+n7RVmVMiBUJkIy 19fDeLc+0bWgzKLEXl00e0KytGgz6gS3sbDYfv8Ukh9eAnQ9iev31fZmb2UpmXtJCpQHrK tT3kT3FME+sDX3zYCnpXyOGUP0v0DwUSbRdsMyzH3YKw8XJ60b2gi5PX1wTENR0L4fnXUr +3Wya4jXUR5d5Az7/Yn9HrBc68qogHn+TwBFZUhXMtlcThKoRBA7160Td7sUeTc1FoqvlD saneqqnZCgX0qhWZp9V+eNHMnMkNoSwhdDtM+7IRI0doTI7BlzLbiZp1mZOUNWDtdaZwIn Jbtk5T/FDLw+VIQQWmcQ== END SSH2 PUBLIC KEY Activated.
Re: SSH key for upload access
On Fri, Jun 06, 2014 at 08:07:16PM -0400, Chris J. Breisch wrote: Name: Chris J. Breisch Package: man-db BEGIN SSH2 PUBLIC KEY Comment: 4096-bit RSA, converted by Chris@Chris-PC from OpenSSH B3NzaC1yc2EDAQABAAACAQCzGcbs64ShqbQOi1hpyrCVay5NAsV+DG+39LnIlv tiP07M8+92jo4UQUcXXLhXevoktmm6xPbzqote/TcNXUmjh7ZRCs5FW16X/++CqxKK3nMu lRrMoAVZ0+T8rNZ1FNFq11BsF5irJqtU3NetCOdo0ihCUCYxzjSWctolq98vLwIyb2VUnX BPPUH4Ez+1ZAyUIa7ppSMWDeny55sovGGqODbLrYbhhfiP5ubFwNqMr73BU8xN4W2tXkUl VBA8uIwdEMwsSzD1rfJ1BCLsgVc2Rh2CWSvcA4Ryj5ycD+Rn2r20ttbxK598JfYD5Lnw2H HYAZRmq16kmN1K6/WczBrcWAFIohlHVMIhr6LA7MSXXqPO7en/EGQ+XaIoAZdN3KjHFhxM FJGBRhmdrSSno9s9BsOKYABN1K08oLV0jOYzop/4dByVubkByaXJSzgyGD/ckISlndYkIz Nw1KkvP3Ta0iPiyxQpmHMtkVDEG8BDassr9MhH7WSgZcN1hKE9BmXgz36tepLP5jxKWlxb DsomiCokufHIJGJiuNiIuNwPDEoB8XeNCzKYEXnEFT03sGHrmjTc2236rM3lvkw+MfuGGo VmIhzcasQPlSdG64LZhOaX8pTHiGG5pHDK7NRtZZuFrhE5dFUV5LBiFFCP4lSXYMQ90O3k Me/IFsdBwJIqBQ== END SSH2 PUBLIC KEY Activated.
Re: Native links break zsh
On Wed, Jun 04, 2014 at 12:56:45PM +0400, Yuriy Chernyshov wrote: Hi! After adding export CYGWIN='winsymlinks: nativestrict' command to my .zshrc file I'm experiencing the problem with zsh HISTFILE. The message says: History locking file failed: No such file or directory. I don't know how this is related since HISTFILE isn't a link at all. This is not a bug reporting mailing list. You've already posted this topic to the cygwin list and you have had responses to your message. Please continue the discussion there. I'm unsubscribing you from cygwin-apps.
s/Chuck Wilson/Former Maintainer/
I see that Yaakov just removed Chuck Wilson (ostensibly temporarily) as a maintainer. That makes me very sad. I sincerely hope that Chuck is just busy in real life. It is rather frustrating to be concerned about someone and have no way to know for sure that they are ok. cgf
Re: Problem running tcl/tk
On Tue, May 20, 2014 at 09:41:42AM +0400, Pavel Fedin wrote: I experience problem running tcl/tk applications. Attempt to do so results in: Wrong mailing list.
Re: [ITA] pinfo
On Tue, May 13, 2014 at 03:03:19PM -0400, Andrew Schulman wrote: I'd like to adopt the pinfo package, since I use it. I have a new build of the latest version, 0.6.10, ready for x86 and x86_64, with a new cygport build script. I'm not sure if there's anything else I need to do. If there's no objection, I think I can just add pinfo to my !packages file in the upload directory, and I'm the new maintainer? Nope. https://sourceware.org/cygwin-apps/package-upload.html#FAQ cygwin-pkg-maint is the master file. cgf
Re: revise Package Contributor's Guide?
Jon, You are now the official maintainer of this page. Congratulations! Go ahead and make whatever changes you see fit to this page. cgf
Re: [ITA] ping
On Fri, Apr 25, 2014 at 06:41:47PM +0200, Corinna Vinschen wrote: On Apr 25 18:32, Marco Atzeri wrote: On 25/04/2014 16:58, Corinna Vinschen wrote: On Apr 24 20:33, Marco Atzeri wrote: just as I built the 64 bit version and it seems to work, with the same limitation of 32 bit counterpart. to download (remove the index.html's) : wget -r -np -nH --cut-dirs=0 \ http://matzeri.altervista.org/x86_64/ping/index.html find x86_64 -name index.html -o -name md5.sum | xargs rm Looks good, as far as the binary package is concerned. However, since the package is apparently orphaned, wouldn't you like to take over maintainership completely? While youre' at it, you could convert the package to cygport and, consequentially, to xz packaging... Thanks, Corinna I doubt the xz compression is worth... $ ls -sh1 *bz2 32K ping-1.0-1-src.tar.bz2 12K ping-1.0-1.tar.bz2 Perhaps not, but having a maintainer is ;) Ditto. And we are moving to .xz so... cgf
Re: [PATCH setup 3/3] Add the last element of URL path to site chooser, if interesting.
On Tue, Apr 22, 2014 at 09:53:15AM +0200, Corinna Vinschen wrote: On Apr 21 19:12, Jon TURNEY wrote: On 21/04/2014 15:10, Christopher Faylor wrote: On Mon, Apr 21, 2014 at 12:16:27PM +0100, Jon TURNEY wrote: If I add the site http://mirrors.kernel.org/sources.redhat.com/cygwinports/ to setup's mirror list, using the GUI or --site option, I get two indistinguishable entries named http://mirrors.kernel.org in the mirror list box. So, to make the site chooser list entries more distinguishable, add the last element of the URL path to the site chooser, if it exists and isn't 'cygwin' (or some other alternatives used by current mirrors) As Corinna pointed out in Nov 2010, there is still a corner case of URLs which share protocol, hostname and the last element of the URL path being indistinguishable. Additionally, it will need updating for any new mirrors which don't use one of the expected strings for the last path element in the URL. I'd actually be ok with just displaying the whole URL even if it ends with Cygwin. Is there a reason not to do that? Last time this was discussed [1], I think you felt that the current site list and dialog box is too small to display the full URL usefully. [1] http://cygwin.com/ml/cygwin-apps/2010-11/msg00134.html The dialog has still a lot of space to the left and right of the URL list window. We could resize it to take the full available space even in the smallest dialog size. I think that would be sufficient most of the time. And the dialog can be resized if it doesn't suffice. I agree. I was going to suggest resizing (maybe I did before too). We'd like to get a new version of setup.exe released soon. I think these changes would be nice to have in it. Any chance you could do that Jon? cgf
Re: [PATCH setup 3/3] Add the last element of URL path to site chooser, if interesting.
On Mon, Apr 21, 2014 at 12:16:27PM +0100, Jon TURNEY wrote:
If I add the site http://mirrors.kernel.org/sources.redhat.com/cygwinports/ to
setup's mirror list, using the GUI or --site option, I get two
indistinguishable
entries named http://mirrors.kernel.org in the mirror list box.
So, to make the site chooser list entries more distinguishable, add the last
element of the URL path to the site chooser, if it exists and isn't 'cygwin'
(or
some other alternatives used by current mirrors)
As Corinna pointed out in Nov 2010, there is still a corner case of URLs which
share protocol, hostname and the last element of the URL path being
indistinguishable. Additionally, it will need updating for any new mirrors
which
don't use one of the expected strings for the last path element in the URL.
2014-04-19 Jon TURNEY jon.tur...@dronecode.org.uk
* site.cc (init): If interesting, show the last element
of URL, as well as the protocol and sitename in the site chooser.
Signed-off-by: Jon TURNEY jon.tur...@dronecode.org.uk
---
site.cc | 21 +
1 file changed, 21 insertions(+)
diff --git a/site.cc b/site.cc
index 48ec0aa..70f6303 100644
--- a/site.cc
+++ b/site.cc
@@ -173,6 +173,27 @@ site_list_type::init (const string _url, const string
_servername,
idx = 0;
} while (idx 0);
key += url;
+
+ /* add last element of url if it exists, and isn't cygwin to
displayed_url */
+ if (path_offset+1 url.length())
+{
+ string url_path = url.substr(path_offset+1);
+
+ /* trim any trailing / */
+ if (url_path.at(url_path.length()-1) == '/')
+url_path.erase(url_path.length()-1);
+
+ /* add the last path element, if it exists, and isn't cygwin
+ (or some aliases used by existing sites) */
+ string::size_type pos = url_path.rfind('/');
+ string lpe = url_path.substr(pos+1);
+ if ((pos != string::npos) (lpe.compare(cygwin) != 0)
+ (lpe.compare(cygwin.com) != 0) (lpe.compare(cygwin32) != 0)
+ (lpe.compare(gnu-win32) != 0))
+{
+ displayed_url.append( ( + lpe + ));
+}
+}
}
I'd actually be ok with just displaying the whole URL even if it ends with
Cygwin.
Is there a reason not to do that?
cgf
Re: Web page describing upload procedure
On Tue, Apr 15, 2014 at 07:20:38PM -0600, Eric Blake wrote: On 10/23/2013 12:46 PM, Christopher Faylor wrote: https://sourceware.org/cygwin-apps/package-upload.html Can we get a link to this page listed on the older contribution guide: cygwin.com/cygwin-pkg-maint That isn't a contribution guide. That's a list of package maintainers. Modifying that file would require that I modify the script which reads that file. I don't see any reason to do that.
Re: SSH key for upload access
On Tue, Apr 15, 2014 at 07:23:38PM -0600, Eric Blake wrote: Name: Eric Blake Package: m4 BEGIN SSH2 PUBLIC KEY Comment: 4096-bit RSA, converted by eblake@home from OpenSSH B3NzaC1yc2EDAQABAAACAQDahsY06ilBIRHkSiXtTxF01fLt6WSaIOL+hNqPLf tAGp8bZ3GyExNlQe1zu2PLPAeZ+idfu/JFxk6eQ3Z/uqTZI7U6IWTiJqutJVoagTmr/ucq BYsfnAmmF/Q7t5uHzugzxKxe6WvTGWqU9jVvuXZZSZ4WlmjeXU0QZ3pUwlknlUljLI8BLM Os4cnrNO4THpFgscKL1nNFZwD2BKH0v7SLbao7KIDi8eM+IRoZjGC8mOeNn+Ib81YOf7EN J+Tk5SJP3LY3gDuG5kY/Cpo0qf2BJvMnJH4pvPnZe0ceuNdEKNe5KKEHqOpqpdH/ZkLp6F yvWyGCHxafJW1wrAevpWBDlP6fGdw1WkFmd9qhuLiyitDLAtBDJxWCOxhSP8yyBI4blBCO WNS1grcQUgZzjoAY+UM5azw2/4HmhzsJpLOuXzWXSs5LvbBpIXUjb8CtVi/j9On6KKQL5u sCxXNCT7XqUeFAzl9BWCZiX76tEa/iGvs+WTznSXytOB/PlA9kJB7ZU/BDECaNqBb3jGTC a7Tx5HWITNCx060WVR3PNqugOXK0RAHYVBIi10qeccYEygD5LMkT4lfdT5+W65jH/qzrg/ Z7u1XOHyluZLQjJ6EW350QUR/GcI4kaCeP/gcZkv+unddft2RaxK51oWYNU40dQ697nyF4 fMrmZhWOgiLPgw== END SSH2 PUBLIC KEY Activated. cgf
Re: inetutils upset messages
On Thu, Apr 10, 2014 at 07:38:08AM +0200, Achim Gratz wrote: Christopher Faylor writes: On Wed, Apr 09, 2014 at 11:28:25PM +0200, Achim Gratz wrote: It appears that the new setup.ini is generated before any file removals have happened, but after the copies have been done. No, that is not right. The setup.ini is created last. Then I have no idea how a setup.ini could have been created that refered to files that were already (correctly) removed from the ftp area. I've checked the timestamps on both and they were showing the same modification times. After sleeping on this, I see what happened now. I'll fix this in upset ASAP. cgf
Re: inetutils upset messages
On Thu, Apr 10, 2014 at 01:17:20PM -0400, Christopher Faylor wrote: On Thu, Apr 10, 2014 at 07:38:08AM +0200, Achim Gratz wrote: Christopher Faylor writes: On Wed, Apr 09, 2014 at 11:28:25PM +0200, Achim Gratz wrote: It appears that the new setup.ini is generated before any file removals have happened, but after the copies have been done. No, that is not right. The setup.ini is created last. Then I have no idea how a setup.ini could have been created that refered to files that were already (correctly) removed from the ftp area. I've checked the timestamps on both and they were showing the same modification times. After sleeping on this, I see what happened now. I'll fix this in upset ASAP. Should be fixed. cgf
Re: inetutils upset messages
On Thu, Apr 10, 2014 at 08:23:04PM +0200, Achim Gratz wrote: Christopher Faylor writes: After sleeping on this, I see what happened now. I'll fix this in upset ASAP. Should be fixed. Thank you very much for your patience. I'll keep my paws from this for a while, though. :-) There was nothing to be patient about since the real problems were all mine. Just about everything that you did should have been caught but upset wasn't up to the task. The current upload system is better than what we had but it is still too delicate for normal humans. Give me another ten years and I'll probably improve it. cgf
Re: inetutils upset messages
On Wed, Apr 09, 2014 at 11:28:25PM +0200, Achim Gratz wrote: Christopher Faylor writes: Nevermind. Stupid coding error. It appears that the new setup.ini is generated before any file removals have happened, but after the copies have been done. No, that is not right. The setup.ini is created last. cgf
Re: inetutils upset messages
On Thu, Apr 10, 2014 at 12:32:59AM +0200, Achim Gratz wrote: Achim Gratz writes: Christopher Faylor writes: Nevermind. Stupid coding error. It appears that the new setup.ini is generated before any file removals have happened, but after the copies have been done. I don't know if that will produce yet another error from upset (so far there are none), but since I was trying to get rid of the 1.9.1-1 packages the setup.ini refers to nonexistent prev files until the next run. Sorry for that. Rats, upset is now upset… in any case, the intention was that inetutils-server-1.9.1-1.tar.xz should have been removed. The deletion cookies have been deleted from my upload area, but it doesn't appear to have had any effect on the ftp, probably since it triggered the error earlier than the removal. Did you try to delete inetutils-server after the first error showed up? That wouldn't have had any effect. The file deletion cookies are always deleted regardless of error state but that shouldn't matter too much because it shouldn't have been possible to get into a state where files were moved and the distro was compromised. So there is still a *#($ bug there. I guess I'll have to set up my test bed again and try to figure out how this happened. Would you happen to have a timeline for what you did, like: 22:41 UTC created -inetutils-1.9.1-1-src.tar.xz 23:06 UTC oops. 23:09 UTC created a -inetutils-debuginfo/-inetutils-debuginfo-1.9.1-1.tar.xz ? Maybe I can figure out from that what happened. cgf
Re: [ITA] base-files
On Tue, Apr 08, 2014 at 08:05:39PM +0200, Achim Gratz wrote: Christopher Faylor writes: Package updates happen every five minutes so you were probably only a minute or so from having inetutils upload privileges. I've seen that and almost put the update out, but I have one question: I gave the patched tar file a release number of 1p1 so that Chuck can continue to increment his releases as he wishes. That works fine when using genini, but I'm not sure what if upset would accept this as a valid package. If you think that's OK, then I'll set the !ready flags. That's very thoughtful of you but I think I'd rather not experiment with version number ordering. I think you should just bump the -N part to the next higher number and let Chuck deal with bumping his version number twice. I think that will be less confusing to upset and the end user. On a side note: I REALLY REALLY hope Chuck is ok and is just on vacation or something. cgf
Re: [ITA] base-files
On Tue, Apr 08, 2014 at 08:30:02PM +0200, Achim Gratz wrote: Christopher Faylor writes: That's very thoughtful of you but I think I'd rather not experiment with version number ordering. I think you should just bump the -N part to the next higher number and let Chuck deal with bumping his version number twice. I think that will be less confusing to upset and the end user. Done and the update is triggered. Hopefully that works out with no errors from upset. If I may ask another question, is there a way to get the generated setup.ini files directly, before they get pushed out to the mirrors? You can always download them directly from ftp.cygwin.com but I wouldn't advertise that fact too heavily. We have mirrors to keep the load on cygwin.com/sourceware.org as light as possible. cgf
inetutils upset messages
upset: *** /var/ftp/pub/cygwin/x86_64/setup.ini: warning - package inetutils-server refers to nonexistent external-source: inetutils This is a valid error since there was no inetutils-1.9.1-2-src.tar.xz I fixed that but I don't understand is how this ended up in the release area in that state. ... Nevermind. Stupid coding error. In the *future* this should not leave the release area in an inconsistent state. Btw, I should mention that the setup.ini generation happens once an hour at (currently) 2 minutes past the hour. I do tend to change that when I'm working on a problem but once an hour should be a constant unless there is a serious problem requiring complete shutdown of setup.ini generation. cgf
Re: [ITA] base-files
On Mon, Apr 07, 2014 at 02:19:10PM -0400, Christopher Faylor wrote: On Mon, Apr 07, 2014 at 02:08:42PM +0200, Corinna Vinschen wrote: On Apr 5 12:20, Achim Gratz wrote: Corinna Vinschen writes: FYI, I contacted Chuck off-list 6 days ago but he didn't reply yet. Same here. I hope Chuck will still reply in the next couple of days, but if not, we have to find some solution to be able to go forward. I am updating some packages this weekend, so if someone can make me temporarily maintainer for inetutils-server I'll repackage it without /etc/default/etc/shells and upload together with base-files and the other updates. Chris, can we do this by simple changing cygwin-pkg-maint temporarily? Yep. That would work. In theory, you shouldn't have to drop Chuck as a maintainer. You could have both Achim and Chuck as inetutils-server maintainers. cgf
Re: [ITA] base-files
On Mon, Apr 07, 2014 at 08:55:52PM +0200, Corinna Vinschen wrote: On Apr 7 14:20, Christopher Faylor wrote: On Mon, Apr 07, 2014 at 02:19:10PM -0400, Christopher Faylor wrote: On Mon, Apr 07, 2014 at 02:08:42PM +0200, Corinna Vinschen wrote: On Apr 5 12:20, Achim Gratz wrote: Corinna Vinschen writes: FYI, I contacted Chuck off-list 6 days ago but he didn't reply yet. Same here. I hope Chuck will still reply in the next couple of days, but if not, we have to find some solution to be able to go forward. I am updating some packages this weekend, so if someone can make me temporarily maintainer for inetutils-server I'll repackage it without /etc/default/etc/shells and upload together with base-files and the other updates. Chris, can we do this by simple changing cygwin-pkg-maint temporarily? Yep. That would work. In theory, you shouldn't have to drop Chuck as a maintainer. You could have both Achim and Chuck as inetutils-server maintainers. How so? Simply both maintainers in the same line, like this: inetutils Charles Wilson, Achim Gratz or two lines? inetutils Charles Wilson inetutils Achim Gratz The latter. The former would be viewed as one person named Charles Wilson, Achim Gratz. cgf
Re: [ITA] base-files
On Mon, Apr 07, 2014 at 09:39:46PM +0200, Achim Gratz wrote: Corinna Vinschen writes: Done. Achim, if you would be so kind... I'll do it tomorrow evening as the latest update of the !package file hasn't picked it up yet. I have an early morning meeting tomorrow and need to fetch some sleep, so I don't want to wait another hour… hope this is OK. Package updates happen every five minutes so you were probably only a minute or so from having inetutils upload privileges. cgf
Re: SSH key for upload access
On Wed, Apr 02, 2014 at 11:04:28PM +0400, Pavel Fedin wrote: Name: Pavel Fedin Package: onc-rpc-devel BEGIN SSH2 PUBLIC KEY ssh-rsa B3NzaC1yc2EBJQAAAIEAuC/0iEv59SbHi2blQMbqLAKC0kkg4AVWMtJWv+lBQBXz9bTsRk80gZ1AQGqpU7QFma/B2ZEAw6kJphx0uwQt7wjvorkyY5thUhkIUo8F27zT+++Wqu7JFCiRHu7CQ9Wrmt9nLr4W7Sad/KwjL1ROBFy8hW4THAMu3ncpqcNzbfM= rsa-key-20140402 END SSH2 PUBLIC KEY Can't install this: uudecode failed. Looks like you didn't run your key through ssh-keygen as suggested at: https://sourceware.org/cygwin-apps/package-upload.html The SSH key above should be generated from one of your public keys, e.g.: ssh-keygen -e -f ~/.ssh/id_rsa.pub
Re: [ITP] onc-rpc-devel-2_19_20140211-1
On Thu, Mar 27, 2014 at 10:02:37AM +0100, Corinna Vinschen wrote: On Mar 24 17:14, Pavel Fedin wrote: Hello! So why not just provide a single onc-rpc-devel, that should be entirely sufficent. onc-rpc-headers is obsolete, ignore it. The idea of creating onc-rpc-devel came to me in order to merge headers and rpcgen. Did you send your ssh key per https://sourceware.org/cygwin-apps/package-upload.html already? It won't do any good until he's in cygwin-pkg-maint. This. Is a recording.
Re: [ITA] base-files
On Sun, Mar 16, 2014 at 06:09:22PM +0100, Achim Gratz wrote: Corinna Vinschen writes: Other than that, it looks good to me. I'd say, let's go for it when you're ready. I still need to wait for Chuck to create an inetutils package without /etc/defaults/etc/shells. Then we'll probably need someone with sourceware access to create the four !ready files so that the upload gets done in synchrony. The files are moved a 14 minutes past the hour. Just don't upload a couple of minutes befor that time and you won't require error-prone external help. cgf
Re: SSH key for upload access
On Mon, Mar 03, 2014 at 08:48:36AM +0100, Michael Wild wrote: Name: Michael Wild Package: tmux BEGIN SSH2 PUBLIC KEY B3NzaC1yc2EDAQABAAACAQDXSw+vo3bC3xBiXB+q1csKoosY29+t1Rcs1Lu4mp DmZ2gYRqSHkGeFTXtCeAsC+QfwoNzQwvU3/IHUyxZQxREZbBkaNdYM86Ys7+kpcOAUABOo +aFersL24CcmirhyWorjfI13bLmviu52XUqKd5VKjNAV5J00iQSUVr+xhcVprpeNg9/wWn NIuHPB/kmj/tAnK+Ssqx1MWpE+EicXam9FS9/8DGTuW6aTI4mm2aMDj3tdZmS+QO9L/RaU 9S9X+aHxzD101DgrtJjCHBA/aJ7Lv9NSNXdhGasSkIRMESVqyCw6+fXl3Xqb5qIKuLijs0 AvYCO5Iwx3xjlOwWrxIsDElumrDvNaSRomgb0q7Czwx2KBLWrc0qTR3GuJBCdbB7BTtUK1 fn3S3lu5+g40cfYCTekBAhoJrR3beOH9v/LYZNphfzRwXRmOcoldvChMKzqW+VJ+chi0/C qY9TCo9nc1sKcTnyHpAwKuAm3tzo+4WktQ93OeezcwvPWNWoh16K4BYkG6OBkGaSsSc+3O LV0a1kvEquMDcYBWj7j1FUeWI2U28Ns/HBnb/NluK59hFHC8PoJ2zkViRgYVlpkWb9+0KW uSKEX6pHz144juVvs5tCFXBJl1RJ5WokxXbAjwKy9fNk8pEFNZ1bz3j1RhB0O0coO5uzz+ TPbyVOvT6Zwraw== END SSH2 PUBLIC KEY Added to cygwin-pkg-maint and account activated. cgf
Re: [PATCH] setup: add Windows 8.1 to manifest
On Tue, Feb 25, 2014 at 07:06:27PM +0100, Achim Gratz wrote: Corinna Vinschen writes: I added the 8.1 GUID to setup on 2013-11-19 already. Did we have no new release since then? I don't think that version was ever released on cygwin.com. I'll release a new version ASAP. cgf
Re: [PATCH] setup: add Windows 8.1 to manifest
On Tue, Feb 25, 2014 at 01:13:29PM -0500, Christopher Faylor wrote: On Tue, Feb 25, 2014 at 07:06:27PM +0100, Achim Gratz wrote: Corinna Vinschen writes: I added the 8.1 GUID to setup on 2013-11-19 already. Did we have no new release since then? I don't think that version was ever released on cygwin.com. I'll release a new version ASAP. Done. A list of what changed is below. Hint: It's all Corinna. cgf revision 2.844 date: 2013/11/19 21:52:55; author: corinna; state: Exp; lines: +7 -2 * setup.exe.manifest: Add Windows 8.1 GUID. * setup64.exe.manifest: Ditto. revision 2.843 date: 2013/11/18 11:16:14; author: corinna; state: Exp; lines: +15 -2 * filemanip.cc (nt_fopen): Rename from fopen. Add permission parameter. Drop C binding. Move comment. * filemanip.h (nt_fopen): Declare. * geturl.cc (get_url_to_file): Call nt_fopen instead of fopen. * nio-file.cc (NetIO_File::NetIO_File): Ditto. * main.cc (dyn_AttachConsole): Remove. (dyn_GetLongPathName): Remove. (set_dynaddr): Remove. (set_cout): Just call AttachConsole directly. (WinMain): Drop call to set_dynaddr. revision 2.842 date: 2013/11/15 12:15:23; author: corinna; state: Exp; lines: +8 -2 * resource.h (IDC_SOURCE_SUBTEXT): Define. * res.rc: Define text below header as IDC_SOURCE_SUBTEXT to allow reconfiguration. revision 2.841 date: 2013/11/15 11:41:11; author: corinna; state: Exp; lines: +8 -2 * root.cc: Move inline definitions of GetDlgItemRect and SetDlgItemRect from here... * win32.h: ...to here, for potential usage in other dialogs. revision 2.840 date: 2013/11/15 10:42:56; author: corinna; state: Exp; lines: +8 -2 * res.rc: Fix size and position of rootdir textbox and button. Align size and position of localdir fields to rootdir fields for optical reasons. revision 2.839 date: 2013/11/15 10:35:47; author: corinna; state: Exp; lines: +6 -2 * resource.h (IDC_ROOTDIR_SUBTEXT): Fix typo. revision 2.838 date: 2013/11/15 10:34:59; author: corinna; state: Exp; lines: +8 -2 * resource.h (IDC_ROOTDIR_SUBTEXT): Define. * res.rc: Define text below header as IDC_ROOTDIR_SUBTEXT to allow reconfiguration. revision 2.837 date: 2013/11/15 10:22:15; author: corinna; state: Exp; lines: +26 -2 * mount.cc (read_mounts): Drop setting root_text. * res.rc: Set content of root dir dialog correctly right from the start. Remove unused items. * resource.h (IDC_ROOT_TEXT): Remove. (IDC_ROOT_BINARY): Ditto. (IDC_FILEMODES_LINK): Ditto. (IDC_MODE_GRP): Ditto. (IDC_MODE_TEXT): Ditto. (IDC_MODE_BIN): Ditto. * root.cc (Root): Set Install For group items to CP_STRETCH. Remove all text/binary items. (rb): Remove. (check_if_enable_next): Drop test for root_text. (load_dialog): Remove all code setting items differently to what's specified as default in the resources, in favor of setting this correctly in the resources. (save_dialog): Drop setting root_text. (RootPage::OnMessageCmd): Drop IDC_ROOT_TEXT/IDC_ROOT_BINARY handling. (RootPage::OnInit): Drop IDC_FILEMODES_LINK handling. (RootPage::OnNext): Drop text/binary state from debug output. * state.cc (root_text): Remove. revision 2.836 date: 2013/11/14 21:36:13; author: corinna; state: Exp; lines: +41 -2 * archive_tar.cc: Drop commented out static variable definitions. (archive_tar::next_file_name): Replace MAX_PATH with CYG_PATH_MAX. * archive_tar.h (tar_state::filename): Ditto. * cygpackage.cc (cygpackage::cygpackage): Ditto. * cygpackage.h (cygpackage::getfilenamebuffer): Ditto. * desktop.cc (start_menu): Add comment. Drop Windows 9x considerations. (desktop_icon): Ditto. (check_desktop): Ditto. (check_startmenu): Ditto. * diskfull.cc (diskfull): Drop Windows 9x considerations. Convert incoming path to wide char and call GetDiskFreeSpaceExW. * filemanip.cc (fopen): New function, overriding MSVCRT function. Explain why. (remove): Ditto. (rename): Ditto. (_access): Ditto. * install.cc (check_for_old_cygwin): Add comment. * localdir.cc (browse): Add comment. (LocalDirPage::OnNext): Don't rely on being able to change CWD. Call GetFileAttributesW instead and change conditional expressions accordingly. Explain why. Rename trySetCurDir to tryLocalDir to avoid confusion. Call do_from_local_dir rather than do_fromcwd. * mount.cc
Re: [PATCH] setup: add Windows 8.1 to manifest
On Tue, Feb 25, 2014 at 09:32:20PM +0100, Achim Gratz wrote: Corinna Vinschen writes: I'm not sure what you're doing. I'm making two builds from two Cygwin installations (one 32bit and one 64bit) with the native toolchain (not cross-compiled). I've had some disk space problems that prevented installation of the cross compilation toolchain(s) originally. That's now solved, but I'm still doing native builds. I'm building setup from the same source dir in two build dirs all the time (well, *when* I'm doing that, which was in November the last time). Maybe you should point out the actual problem you have? It complains that the architecture has changed between configure runs and that I should blow away configure.cache before re-configuration or distclean the whole thing. Sorry, can't get at the actual error messages from here. That may not be happening when you're doing a cross-compilation since the host architecture would not change in this case. In that case submit a patch. This obviously isn't impacting Corinna or me so expecting us to solve the problem for you is, well... cgf
Re: upset messages
On Sun, Feb 23, 2014 at 03:43:48PM -0500, Christopher Faylor wrote: On Sun, Feb 23, 2014 at 10:07:24AM -, cygwin-no-reply wrote: upset: *** package missing category tag upset: *** package missing category tag upset: *** package missing category tag upset: *** package missing category tag upset: *** package missing category tag upset: *** package missing category tag upset: *** package missing category tag upset: *** package missing category tag I don't understand why this is happening. One of the reason upset is complaining is because obsolete x86 curl-devel doesn't have an empty tarball associated with it but it doesn't look like it ever did. FWIW, upset assumed that there would always be a tarball in the same directory as a setup.hint. Can anyone explain what changed between 9:36 - 10:06 this morning to cause this to start happening? Actually, I guess it could have happened earlier than that since we apparently had a disk full condition on sourceware. cgf
Re: upset messages
On Sun, Feb 23, 2014 at 10:07:24AM -, cygwin-no-reply wrote: upset: *** package missing category tag upset: *** package missing category tag upset: *** package missing category tag upset: *** package missing category tag upset: *** package missing category tag upset: *** package missing category tag upset: *** package missing category tag upset: *** package missing category tag I don't understand why this is happening. One of the reason upset is complaining is because obsolete x86 curl-devel doesn't have an empty tarball associated with it but it doesn't look like it ever did. FWIW, upset assumed that there would always be a tarball in the same directory as a setup.hint. Can anyone explain what changed between 9:36 - 10:06 this morning to cause this to start happening? cgf
Re: [ITP] google-breakpad
On Thu, Feb 20, 2014 at 08:23:47PM -0600, Yaakov (Cygwin/X) wrote: On 2014-02-18 07:28, Jon TURNEY wrote: These packages contain the minidump analysis part of breakpad, a multi-platform crash reporting and analysis system using minidumps. It doesn't make much sense to package the libbreakpad_client crash handling library, as this conflicts with cygwin's error_start facility. It might make some sense to make MinGW cross-compiled packages of libbreakpad_client in the future. I can't find this in any major linux distribution, so votes are required. +1 +1 cgf
Re: Question about SSH key for upload
On Tue, Jan 28, 2014 at 01:47:41PM +1300, Chris LeBlanc wrote: Firstly thank you Christopher Faylor for activating my SSH key for the python-h5py package. That worked perfectly. I fetched these new packages on a local Cygwin install and they work nicely. Just one thing (I tried responding to the original SSH key mail thread but my mails were bounced as spam): I would also like to be the package maintainer for python3-h5py. I sent another SSH key for upload access email yesterday but it looks like it was missed, probably because it looked like a duplicate email since they both had the same SSH key. That's not how it works. You don't provide one ssh key per package. If that was the case, I'd still be here adding keys for Yaakov. What you are allowed to upload is controlled by how you are listed in cygwin-pkg-maint. I've added you to cygwin-pkg-maint. cgf
Re: SSH key for upload access
On Mon, Jan 27, 2014 at 01:50:58PM +1300, Chris LeBlanc wrote: Name: Chris LeBlanc Package: python-h5py BEGIN SSH2 PUBLIC KEY B3NzaC1yc2EBIwAAAQEA5EYaKpfUKmfn6xbQpv29T/8FgJDbHYD4g1DbcjzLce 1GgYy3QvdCQ9krbHqze5j34CGdETh2GpiYLEUpsJbIdEovUb/4HkZRVYrkWIh7PBakHQl3 szEd9i5BWgxXJnLNW90NP73nzGUdbPH76INbeIll1A3fRVGoyxsQvTAgHG2Gc68iIYPZuY gPAZgeis+yelxB+S3jRMfkLswu3iQjSCWzGZ2paBTmyawMXkMdsmVq58b4x1UEkR9Ztb9E g8agA0DsLVJbgLvdOApl97WkbxcupFNw6oTlM4LmOhynzXurxujcKKkGCVz6bkFi3/rA52 bGtpfe2EgeZwnUzqAkaw== END SSH2 PUBLIC KEY Activated (after adding adding python-h5py to cygwin-pkg-maint). cgf
Re: [ITA] tcl-sqlite3
On Tue, Jan 21, 2014 at 03:07:28PM +0100, Jan Nijtmans wrote: 2014/1/21 Corinna Vinschen: Please make sure to provide only subpackages for which the matching source package is available, too. Thank you, I didn't know that. My apologies! You didn't know that the source package has to exist? It's a free software project. I also added a '!email' file for you so that you can share in the fun of getting upset messages.
Re: [ITA] Git et al
On Fri, Jan 17, 2014 at 10:42:52AM -0800, Balaji Venkataraman wrote: On Wed, Jan 15, 2014 at 3:06 AM, Adam Dinwoodie wrote: There's a new build available at http://tastycake.net/~adam/cygwin/ which resolves that issue. If you want to give it a try and let me know how you get on, I'd be exceedingly grateful. I tried to add the path above to the list of mirrors in setup-x86.exe. Is that how you are expecting folks to get your build? It seemed to find setup.ini but just hung there for a while after which I gave up. Not sure if it's a firewall problem on my end (which I doubt - since I access other Cygwin mirrors routinely from behind the FW) or a server problem or PEBCAK. Thanks. No, that's not intended to be a setup.exe download. If you don't know what the above link was for then you are not the target audience for it. cgf
Re: SSH key for upload access
On Wed, Jan 15, 2014 at 03:58:16PM +0100, Gernot Hillier wrote: Name: Gernot Hillier Package: tftp BEGIN SSH2 PUBLIC KEY B3NzaC1kc3MAAACBALo+xRLiEqmpgiyzryUB6GKuwoin18BUKm5nMVnUo6kFUA9ygD V+JkYsoNXMdaMcL9pEoFsvWtNfW7s4j8LHtrtxP1oX1npNT1om7LnmO2muc73dlDzNRHtH apynRsIfgFZsNwgCFTFUKyB1maVY5S85d5Hzejop9TTdslIFRg2lFQDcoEKh5gGVeQ fvdyZ1rdWyB+KlBwAAAIAHlMtdx4szmElsxu8BOAOYjKdkugwqHqlyhgxS1Yq9NafeUOVn 2j7zlbqYP42ohiXy0TF9CVckRqR/KRRvloka25oVDcZVxTgI9LJIsdqQrYJC6T+s7D223c eyXbE9A3uTvGDCl8ZboxJ5HewS9PnKCyyRCWw7ar7j/fA3waU9agAAAIANaAYVrz505k62 rdhEf/vxygSHpE4RpZGZbipkzEjoQiZnEEecFdrnnF/nQUbHeJysT1kv2FGJy/i5xi4P8c FCePBzIhe/cUH0zLudR3ebDqdo/WdS3BaQUxrk2404x0CSREVr5NbdcExirg2OgyytU/IR HExUxnv4yoH4xkQLhQ== END SSH2 PUBLIC KEY Activated. cgf
Re: [ITP] python-h5py 2.2.0
On Wed, Jan 15, 2014 at 10:36:06AM +0100, Corinna Vinschen wrote: On Jan 15 07:25, Marco Atzeri wrote: On 15/01/2014 03:57, Chris LeBlanc wrote: It's been several weeks since I posted this ITP and there hasn't been a response. Version 2.2.1 of h5py is out, and I'm willing to package it for Cygwin but I'll need to know if this package will be accepted. Please let me know if I'm doing something incorrectly or if I should make any changes. I know there is a new package upload system, but it appears to be for accepted packages only. Please let me know if I can use this upload system for this proposed package. You can. Just have a read at https://sourceware.org/cygwin-apps/package-upload.html and send the public part of an ssh key as outlined. Actually, you can't use the upload system to upload packages that aren't accepted. This is only for packages which are listed in cygwin-pkg-maint. So, yes, the upload system is only intended for packages that are accepted. It isn't intended to be used as temporary staging for packages that might be accepted.
Re: RFC: usage of cygwin32-/cygwin64- cross-toolchains
On Fri, Jan 10, 2014 at 01:01:36AM -0600, Yaakov (Cygwin/X) wrote: On 2014-01-10 00:06, Christopher Faylor wrote: On Thu, Jan 09, 2014 at 11:32:44PM -0600, Yaakov (Cygwin/X) wrote: Now that we're long finished bootstrapping cygwin64, I was wondering to what degree (if any) are the cygwin32-* and cygwin64-* packages in either the Cygwin distro or the Fedora Cygwin repository are of actual use. If you are using any of these, please specify on which platform you are using them (i686/x86_64, Cygwin, F19, or if you want to move to F20) and to what extent (IOW to build Cygwin package A/B/C which require libraries X/Y/Z). This will help me best manage my time wrt keeping these updated. I use them in (essentially) Fedora 18 but I have vague plans to update to the latest Fedora sometime soon. And which libraries are you using? Sorry. I think the answer is pretty much all of them but the list is below. Since I do all of my builds on linux, I end up using most of your packages. However, I have methods for pulling in what I need from the release if there is a gap. So, I guess, the only things I really *need* are the compiler and binutils packages. Everything else is just nice to have for me. cgf cygwin32-freetype cygwin64-freetype cygwin32-gcccygwin64-gcc cygwin32-gcc-c++cygwin64-gcc-c++ cygwin32-gcc-gfortran cygwin64-gcc-gfortran cygwin32-gcc-gnat cygwin64-gcc-objc cygwin32-gcc-java cygwin64-gcc-objc++ cygwin32-gcc-objc cygwin64-gettext cygwin32-gcc-objc++ cygwin64-gettext-static cygwin32-gettextcygwin64-glib2 cygwin32-gettext-static cygwin64-gmp cygwin32-glib2 cygwin64-isl cygwin32-gmpcygwin64-libbfd cygwin32-islcygwin64-libedit cygwin32-libbfd cygwin64-libffi cygwin32-libeditcygwin64-libiconv cygwin32-libffi cygwin64-libiconv-static cygwin32-libiconv cygwin64-libltdl cygwin32-libiconv-staticcygwin64-libmpc cygwin32-libltdlcygwin64-libpng cygwin32-libmpc cygwin64-libtool cygwin32-libpng cygwin64-libxml2 cygwin32-libtoolcygwin64-minizip cygwin32-libxml2cygwin64-mpfr cygwin32-minizipcygwin64-ncurses cygwin32-mpfr cygwin64-nettle cygwin32-ncursescygwin64-openssl cygwin32-nettle cygwin64-orc cygwin32-opensslcygwin64-pcre cygwin32-orccygwin64-pixman cygwin32-pcre cygwin64-pkg-config cygwin32-pixman cygwin64-ppl cygwin32-pkg-config cygwin64-readline cygwin32-pplcygwin64-w32api-headers cygwin32-readline cygwin64-w32api-runtime cygwin32-w32api-headers cygwin64-zlib cygwin32-w32api-runtime cygwin64-zlib-static
Re: RFC: usage of cygwin32-/cygwin64- cross-toolchains
On Thu, Jan 09, 2014 at 11:32:44PM -0600, Yaakov (Cygwin/X) wrote: Now that we're long finished bootstrapping cygwin64, I was wondering to what degree (if any) are the cygwin32-* and cygwin64-* packages in either the Cygwin distro or the Fedora Cygwin repository are of actual use. If you are using any of these, please specify on which platform you are using them (i686/x86_64, Cygwin, F19, or if you want to move to F20) and to what extent (IOW to build Cygwin package A/B/C which require libraries X/Y/Z). This will help me best manage my time wrt keeping these updated. I use them in (essentially) Fedora 18 but I have vague plans to update to the latest Fedora sometime soon. cgf
Re: I cannot login with sftp
On Sun, Jan 05, 2014 at 09:29:47PM +0100, waterlan wrote: It would be nice if this issue was mentioned at the upload instruction page. Also some more information about how to create the rsa key. That saves some searching the web. The package-upload.html file is on its 66th revision. I don't plan on adding instructions in how to use ssh though. cgf
Re: SSH key for upload access
On Sat, Jan 04, 2014 at 11:07:01AM -0500, David Levine wrote: Name: David Levine Package: nmh BEGIN SSH2 PUBLIC KEY B3NzaC1yc2EDAQABAAABAQDVUAOcU70/qR4Q1taKO/8xt5dYlgrfYrgSgzwXcO JZ5sWlRq2HecgzB+UXLtc/Bcqz+yyMFaK8LQJ+6XdTXpirHQf+IfDvDDpcEB4xSfHyLW/W uUSn2RpCjfm85jlMbqgGjiCwcVeTJFJXz9pMIYSHe5oiLDW1GA9imKtACdbFlt9GRgaorw ZSB4tTGyNCyGX2HpzFKGkIHNCcnN37ZYVb0KieyN5F5Yi2gZYaHzk+yKLklgaeivwZcEYf yihldmZclXlqhcagkyCs/e0gihkdAPCQp9CWD5PmwkL6wlwG+vC4sATeBaeXhANdyc1uOn 28PKPi1rOj2euSeAU7BfYl END SSH2 PUBLIC KEY Activated.
Re: SSH key for upload access
On Fri, Jan 03, 2014 at 11:45:53AM +0100, marco atzeri wrote: Name: Marco Atzeri Package: lapack BEGIN SSH2 PUBLIC KEY B3NzaC1yc2EDAQABAAABAQDOnH9bOIalaKpmcNZ2oCDM7Wq4O1pCSVbNfPYwZt 9KDpnhBg6eQVXjQ8EmK2Dvg3m/pmcXdbf8K+jxNUwtFMp/Z1+ZB5c92Ak7VEB0XV9NTUtI hix7U2q2G+knaEh+2tPkAMyYY2Ha+MezTXLfowFcaUbMXZ7FVKcLcJjEOtuJgLRuZvjtxN rKNerLjQjJJHvpqY4MTJgAqrtn32UBLpVFiUPialuuC8wwuYxzE7VDhgRJvw4QwvI42Nwv WAiV+uIf+pysHcW8iLZ+ekzTiKNBakT2dxLYy9G7vRltsBn+X9CpDJ73vKGygNwirkDQ2N mSSEUiE1JyEHdISOaRpV2h END SSH2 PUBLIC KEY (Re)activated.
Re: SSH key for upload access
On Fri, Jan 03, 2014 at 07:30:24PM +0100, Christian Franke wrote: Name: Christian Franke Package: smartmontools BEGIN SSH2 PUBLIC KEY B3NzaC1yc2EDAQABAAABAQDt8ihOHe9qLnwOB25IWrLNJBulYOWf2+0Umg89RX vSJ54gAiNJ27qs0NeW0oMdZITTGEtUAZgSiVmh1UE0THHIQxhAe9RW6LtEfv8R8uF/dz3Q njwfNPu4cBLFCzUkz0qD/wSRbmgGL51uX/8DVfSNLeDGBwTddrdVxtMpbtkaQkdR7DPCrJ IN/K2YtRh+L3Whiu6FICnjCpD5sjET+Ky+q980tRfi+ZJY+UxmdwsgXCbwo+n7BzJ4EYqH VoOU2WSZngxK61KY546XJgwpvtzkQdfy97W5yCk5MlOjmS7M4DSTNpOIBgATDAuaZAKz9a oOfdmOmExUoLX8C90PXAAn END SSH2 PUBLIC KEY Activated.
Re: SSH key for upload access
On Thu, Jan 02, 2014 at 11:20:02AM +0100, Erwin Waterlander wrote: Name: Erwin Waterlander Package: dos2unix libunistring libunistring-devel libunistring-doc libunistring0 BEGIN SSH2 PUBLIC KEY B3NzaC1yc2EDAQABAAABAQC6uA/1Gt9J5Hin1j9oanLQ45YEH+Ge/7gJRtztCV 7jkHvK4XOj3exowfYOxz4Dp2q/mIZj2i23Yy95zJWwQNuQZ9InwgZVRHwzVuyly5cjXcI5 kSYleBtvh32UfP83BHuG3zKTpwMpzQX8kCEveYxE58jtkZFnXPmlhklUVZ19h/35DiyT4K chLsyLQ9bCBIfBR+fyg7S7Qp5YmuKlEBlWSCVDEHL9aN1TzD0krn53Bcfb4X1UwJDDmgJD 4D0V9oK94IltCoQPaBGBzEdXZ6e78ADLv2tiPJcS93s/ZYLqljVfMkfb+7Ol3Z+Z8cbtnq TRVpZdnTG4LBYHGj/xh5Fb END SSH2 PUBLIC KEY Please go back to https://sourceware.org/cygwin-apps/package-upload.html and read what is supposed to show up after the Package. Hint: it is not a list packages with wrapping onto a new line. cgf
Re: SSH key for upload access
On Thu, Jan 02, 2014 at 03:37:50PM +0100, marco atzeri wrote: Il 1/2/2014 12:50 AM, Christopher Faylor ha scritto: On Wed, Jan 01, 2014 at 04:41:21PM +0100, marco atzeri wrote: Il 11/30/2013 3:55 AM, Christopher Faylor ha scritto: On Fri, Nov 29, 2013 at 10:25:39PM +0100, marco atzeri wrote: Given the error, apparently you're not using the private key associated with the above public key. FWIW, the above key is not the same as the public key for your general login. cgf the public key was a DSA and the last one a RSA. Something was wrong with that RSA key so here a new fresh one BEGIN SSH2 PUBLIC KEY B3NzaC1yc2EDAQABAAABAQDOnH9bOIalaKpmcNZ2oCDM7Wq4O1pCSVbNfPYwZt 9KDpnhBg6eQVXjQ8EmK2Dvg3m/pmcXdbf8K+jxNUwtFMp/Z1+ZB5c92Ak7VEB0XV9NTUtI hix7U2q2G+knaEh+2tPkAMyYY2Ha+MezTXLfowFcaUbMXZ7FVKcLcJjEOtuJgLRuZvjtxN rKNerLjQjJJHvpqY4MTJgAqrtn32UBLpVFiUPialuuC8wwuYxzE7VDhgRJvw4QwvI42Nwv WAiV+uIf+pysHcW8iLZ+ekzTiKNBakT2dxLYy9G7vRltsBn+X9CpDJ73vKGygNwirkDQ2N mSSEUiE1JyEHdISOaRpV2h END SSH2 PUBLIC KEY already tested with the ssh login and it worked. In case it isn't obvious, the format of the email mentioned at https://sourceware.org/cygwin-apps/package-upload.html is for reading by a program. Using a program means that there won't be issues if I try to update files by hand. If you want to update your key submit a new request using that format. cgf
Re: SSH key for upload access
On Thu, Jan 02, 2014 at 10:16:25PM +0100, Erwin Waterlander wrote: Name: Erwin Waterlander Package: dos2unix BEGIN SSH2 PUBLIC KEY B3NzaC1yc2EDAQABAAABAQC6uA/1Gt9J5Hin1j9oanLQ45YEH+Ge/7gJRtztCV 7jkHvK4XOj3exowfYOxz4Dp2q/mIZj2i23Yy95zJWwQNuQZ9InwgZVRHwzVuyly5cjXcI5 kSYleBtvh32UfP83BHuG3zKTpwMpzQX8kCEveYxE58jtkZFnXPmlhklUVZ19h/35DiyT4K chLsyLQ9bCBIfBR+fyg7S7Qp5YmuKlEBlWSCVDEHL9aN1TzD0krn53Bcfb4X1UwJDDmgJD 4D0V9oK94IltCoQPaBGBzEdXZ6e78ADLv2tiPJcS93s/ZYLqljVfMkfb+7Ol3Z+Z8cbtnq TRVpZdnTG4LBYHGj/xh5Fb END SSH2 PUBLIC KEY Activated.
Re: SSH key for upload access
On Wed, Jan 01, 2014 at 04:41:21PM +0100, marco atzeri wrote: Il 11/30/2013 3:55 AM, Christopher Faylor ha scritto: On Fri, Nov 29, 2013 at 10:25:39PM +0100, marco atzeri wrote: Name: Marco Atzeri Package: lapack BEGIN SSH2 PUBLIC KEY B3NzaC1yc2EDAQABAAABAQDBdNLOzObcACE50UDaWncOKGYK8Ph2j7NGdMlgRH IjzLj6ibCAJK8rSJ+9u1UY59cjUL3LbdWnJzohRMnQ+cEe2mrG1uwjQXVC5C9V0A9EFKwV 6q/Q6z3+UO4K14jH+s8tYCei/M/92c2c9zmta2w4sf6S+D1BS6MWOA5wg5GGHXAtVaiU4Z PhjOgrTDxsGY8tQBWEtUVRKaXLRHO014ObE8HddC4dgyiSk89eW8Bj0I9mfW/jtOd2pcNF G0Z/CSWjRyLftQvYHAznppse8Q9rKQYkp7jLHcNYn8oQU5vGwRZzU3axdIUCZx26YJu6AT 5h3CjsRvMjvKtvNJ2QV5Zz END SSH2 PUBLIC KEY Activated. cgf while I succeed to connect with ssh matzeri(at)sourceware(dot)org on sftp, I catch: $ lftp -d sftp://cygwin:(at)cygwin(dot)com lftp cygwin(at)cygwin(dot)com:~ ls Running connect program (ssh -a -x -s -l cygwin cygwin.com sftp) --- sending a packet, length=5, type=1(INIT), id=0 --- Permission denied (publickey). Peer closed connection Disconnecting Interrupt Any idea ? Given the error, apparently you're not using the private key associated with the above public key. FWIW, the above key is not the same as the public key for your general login. cgf
Re: [RFU 64 bit] dos2unix 6.0.4-1
On Thu, Jan 02, 2014 at 12:29:31AM +0100, Erwin Waterlander wrote: New upstream release. wget -x -nH \ http://waterlan.home.xs4all.nl/cygwin64/dos2unix-6.0.4-1.tar.xz \ http://waterlan.home.xs4all.nl/cygwin64/dos2unix-6.0.4-1-src.tar.xz \ http://waterlan.home.xs4all.nl/cygwin64/setup.hint \ http://waterlan.home.xs4all.nl/cygwin64/dos2unix-debuginfo/dos2unix-debuginfo-6.0.4-1.tar.xz \ http://waterlan.home.xs4all.nl/cygwin64/dos2unix-debuginfo/setup.hint Changes: * New options -ul and -ub to convert UTF-16 files without BOM. * New Russian translation of the messages. * When a binary symbol is encountered the value is printed. Keep only the previous release. We have a new way of uploading packages. Please see: https://sourceware.org/cygwin-apps/package-upload.html
Re: SSH key for upload access
On Sat, Dec 14, 2013 at 06:47:35PM +0100, jdzstz wrote: Name: Jorge D?az Package: varnish BEGIN SSH2 PUBLIC KEY Comment: 2048-bit RSA, converted by Jorge@asus-jorge from OpenSSH B3NzaC1yc2EDAQABAAABAQDnehMN7HWKDaSbc1cAXJXcUryaSNukqBKWf4qwgo XlN/oLuGoe4MJ3BHNK6RCRU2WtmKi3R45xuWJtee+ELk6gIFXD5m2hc1YDnUPCvYHK9c4v avkHgbV8mu733T1IV4nNmQkKLQcfj0BpyY5VyXuEfEa5EG41tTWTxsiR7bwqyVijU8NlYu djRrGarff003clXNmlr/nCetyNPEFEsK4KQS+f4UJpMhxvGe9PxbWgx91QPoI7YdwdTwCE AOTB2eAlmpcHO2gJW0rSJoCByXOcjBdIWXCcAzAActeBzVcwD/VQrenIwl4i31gEWZLR+H bfpL66oXMR0zkbw4aMtRmB END SSH2 PUBLIC KEY Activated.
Re: SSH key for upload access
On Sat, Dec 14, 2013 at 03:23:58PM -0800, Dave Kilroy wrote: Name: Dave Kilroy Package: chere Activated.
Upload enhancement: Allow removal of files from the distro
I've modified upset to allow the removal of files from the cygwin distribution. If you want a file to disappear, upload an empty file with a leading dash as the filename. This will caused the corresponding file in the distribution to be moved to an archive directory. This archive directory is only available to people with normal logins to sourceware.org. Wildcards are allowed in the filename, so be careful. Slightly more details on file removal here: https://sourceware.org/cygwin-apps/package-upload.html I plan on writing a cron job which deletes old archived files but I haven't done that yet. This isn't a sophisticated backup mechanism so if you delete, recreate, and delete a file you won't be able to get the file you originally deleted. I don't expect this to be a common scenario. I'm still not entirely wild about this way of handling file removal so it's likely that something else could show up in the next ten years. But at least now people can remove files that they don't want. I've also modified upset so that files will not be moved out of the upload directories and setup.ini will not be updated if there are any errors detected. Hopefully this means that release that people grab should always be error-free. Contemplated upcoming change: If you create a !announce file the contents will eventually be sent to cygwin-announce. The announcements will be batched and only sent out when it seems like at least one of the cygwin mirrors has the release (I won't necessarily know for sure if the file is there but the chances will be pretty high that it will be). The announcements will have the name of the maintainer with a from and reply-to of cygwin at... you know. This change requires some coordination between upset and the mirror checker but it seems like it would be nice for announcements to go out after the mirrors have picked up an update. In theory, the announcement could even contain a list of mirrors which are likely to have the update. cgf
Re: Install Bash 4.2 for Cygwin
On Thu, Dec 05, 2013 at 10:20:16AM +0100, Javier Murillo M?rquez wrote: Hello!! Is possible install bash 4.2 on cygwin? Is there some patch or update for it? Thanks Wrong mailing list. Go to http://cygwin.com/lists.html#cygwin-apps to see why.
Re: two questions about new upload method
On Sat, Nov 30, 2013 at 12:48:14PM -0500, Andrew Schulman wrote: On 11/30/2013 3:47 AM, Andrew Schulman wrote: On Fri, Nov 29, 2013 at 10:06:50PM -0500, Christopher Faylor wrote: On Fri, Nov 29, 2013 at 01:13:30PM -0500, Christopher Faylor wrote: I added you as the owner for unison and unison2.45. Which didn't do anything. I'm investigating why now. It was because the !ready files disappeared after the previous run. I put one in unison/unison2.45 and the files were moved. Thanks. The packages are out now. I see unison2.45 but not the others. Hm, you're right. Not sure why, since I am listed as maintainer of unison2.27, unison2.32, unison2.40 at http://cygwin.com/cygwin-pkg-maint. And they're all listed in !packages in my upload directory. I just recreated !ready again. In my upload directory I see that x86_64/release/unison/unison2.45 has been cleared out, but the uploaded files for unison2.27, unison2.32, and unison2.40 are still waiting there. I just put a '!ready' file in the unison directory and everything was transferred. You need at least one !ready file per architecture so if you put a !ready at your top level it won't work as expected. From: https://sourceware.org/cygwin-apps/package-upload.html Note: !ready files need to be created at least once for each architecture that is uploaded, i.e., in each of the x86 and x86_64 directories or in the package directories themselves. upset will periodically scan the upload directories for packages that are ready, and, if there are no errors, move the packages into the real release area. New directories in the release area will be created as needed. If there are errors then setup.ini will not be updated and the release area will remain pristine. Note: The upload area is only for new files intended for the Cygwin release. There is no reason to put older files in the upload directories since they already exist in the main release. cgf
Re: upset messages
On Fri, Nov 29, 2013 at 11:10:16AM +0100, marco atzeri wrote: Il 11/29/2013 2:45 AM, Christopher Faylor ha scritto: /sourceware1/cygwin-staging/setup/upset: Error. Parsing failed. - duplicate packages lapack detected - x86_64/release/lapack/lapack vs. /var/ftp/pub/cygwin/x86_64/release/lapack Marco you created an additional lapack directory with duplicate files. I'd appreciate it if you would use the new upload mechanism since it will guard against this kind of thing. just noticed. I tried to solve a problem and I created a different one. So to solve both I just uploaded new packages bumping to -2 I actually fixed the problem by removing the directory. It sure looked like you had duplicated content there. I tried in the past the new method, but I had the impression was not active for me. Could you check ? AFAIK, you never sent the SSH key for upload details. I don't see anything in the archives. cgf
Re: two questions about new upload method
On Fri, Nov 29, 2013 at 12:27:17PM -0500, Andrew Schulman wrote: (1) Is there something I should sould be doing to tell upset which package versions are old and should be purged? There was a long thread about how to delete packages in cygwin-apps. http://cygwin.com/ml/cygwin-apps/2013-10/threads.html#00184 It also went into November. I uploaded lftp, and the new version was added to the archive, but the old one (4.4.7-1) is still there. Do I need to add curr: and prev: lines to setup.hint? Or will upset figure that out and remove the old versions at some point? (2) I uploaded the unison packages for x86_64 in subdirectories of x86_64/release/unison: x86_64/release/unison/unison2.27 x86_64/release/unison/unison2.32 x86_64/release/unison/unison2.40 x86_64/release/unison/unison2.45 because that's how they're organized in x86/release. Will upset pick them up when they're organized that way? I only ask because it's been about 18 hours and they haven't appeared in any of the mirrors yet, although upset seems to be running every hour. Guess I need to add a FAQ. Q) Why aren't my files being transferred to the release area? I've waited several days and don't see any movement. A) The package updater runs every 10 minutes so, if you don't see any movement in, e.g., 20 minutes, then your package is not going to be updated. The main reason that this could happen is if you uploaded a package that you are not actually responsible for. The updater only knows what you are responsible for based on http://cygwin.com/cygwin-pkg-maint so if you aren't listed as an owner there your packages won't be updated. I added you as the owner for unison and unison2.45. cgf
Re: SSH key for upload access
On Fri, Nov 29, 2013 at 10:25:39PM +0100, marco atzeri wrote: Name: Marco Atzeri Package: lapack BEGIN SSH2 PUBLIC KEY B3NzaC1yc2EDAQABAAABAQDBdNLOzObcACE50UDaWncOKGYK8Ph2j7NGdMlgRH IjzLj6ibCAJK8rSJ+9u1UY59cjUL3LbdWnJzohRMnQ+cEe2mrG1uwjQXVC5C9V0A9EFKwV 6q/Q6z3+UO4K14jH+s8tYCei/M/92c2c9zmta2w4sf6S+D1BS6MWOA5wg5GGHXAtVaiU4Z PhjOgrTDxsGY8tQBWEtUVRKaXLRHO014ObE8HddC4dgyiSk89eW8Bj0I9mfW/jtOd2pcNF G0Z/CSWjRyLftQvYHAznppse8Q9rKQYkp7jLHcNYn8oQU5vGwRZzU3axdIUCZx26YJu6AT 5h3CjsRvMjvKtvNJ2QV5Zz END SSH2 PUBLIC KEY Activated. cgf
Re: cygwin-pkg-maint update
On Fri, Nov 29, 2013 at 09:43:11PM +0100, marco atzeri wrote: I just noticed that gl2ps , libgl2ps1 and libgl2ps-devel are not reported as they were only recently added. But I see the same for the result of split /addition in the past like netcdf-cxx4, libnetcdf-cxx4, libnetcdf-cxx4-devel or the suitesparse expansion. So before touching anything : what is the right procedure to update cygwin-pkg-maint ? You can add your new packages to cygwin-pkg-maint since you have a login account on sourceware.orgi with cygwin group access. You'll need to use CVS: cvs -d :ext:sourceware.org:/cvs/cygwin co htdocs You don't add -devel or other subpackages packages like libgl2ps-devel. Just add the main package name. In case anyone noticed: unison is a special case since new version numbers are part of the package name. To answer the general question: Anyone without a cygwin group account on sourceware will have to send mail here to have one of us update cygwin-pkg-maint. Personally, I'd appreciate a patch but if you can't do that, at least use the same format as cygwin-pkg-maint in your request. cgf
Re: two questions about new upload method
On Fri, Nov 29, 2013 at 01:13:30PM -0500, Christopher Faylor wrote: I added you as the owner for unison and unison2.45. Which didn't do anything. I'm investigating why now. cgf
Re: two questions about new upload method
On Fri, Nov 29, 2013 at 10:06:50PM -0500, Christopher Faylor wrote: On Fri, Nov 29, 2013 at 01:13:30PM -0500, Christopher Faylor wrote: I added you as the owner for unison and unison2.45. Which didn't do anything. I'm investigating why now. It was because the !ready files disappeared after the previous run. I put one in unison/unison2.45 and the files were moved. cgf
upset messages
/sourceware1/cygwin-staging/setup/upset: Error. Parsing failed. - duplicate packages lapack detected - x86_64/release/lapack/lapack vs. /var/ftp/pub/cygwin/x86_64/release/lapack Marco you created an additional lapack directory with duplicate files. I'd appreciate it if you would use the new upload mechanism since it will guard against this kind of thing. cgf
Re: Cygport and auto-manifestize compatibility manifest
On Wed, Nov 20, 2013 at 04:01:01PM +0100, Corinna Vinschen wrote: On Nov 20 09:47, Charles Wilson wrote: On 11/20/2013 8:28 AM, Corinna Vinschen wrote: Apart from the fact that it would be nice if our linker would do this automatically and transparently, Or libtool, if you use it to link your exe? PTC...since $new-libtool is pretty high on my to-do list. It'd be better if there was an option to ld/gcc, of course -- but the details would be rather complicated. You wouldn't want to invoke a separate executable like windres b/c then your build recipe/makefile would have to change. Best if $LD_FLAGS could be used... maybe something hideously ugly like -w32-manifest-compat file [1] where file is not a full XML manifest, but rather contains a list of GUIDs [2], and ld/gcc autogenerates the manifest with just that stuff. That way, if you manually create a manifest (for other purposes), you could just /not/ use the new flag. The other way around. If your project does not link in a resource anyway, which means that your project is WIn32 aware, then ld should add the manifest resource by default. Everything else means that you have to tweak all project configury, which is only barely descibed by a can of worms... A simple windres call in cygport would be nice, but unfortunately windres does not yet have this capability to add a resource to an existing exe. I know, SHTDI... Yes, that's pretty much the problem. Even my ugly workaround is bad, because it only works on Windows. No more cross-building on Linux :-P Some more ugly hacks: Could cygwin itself create the manifests when it runs a program iff they don't exist? Or, alternately, setup.exe? Or rebase? cgf
Re: request - Dante v1.4.0
On Tue, Nov 19, 2013 at 08:38:09AM -0800, Bry8 Star wrote: Can Cygwin include : Dante v1.4.0 or other stable edition ? https://www.inet.no/dante/ It includes a SOCKS-v5 server/daemon, and also a SOCKS-v5 proxy. Sorry but you misunderstand what this mailing list is for. It isn't for package requests. I'm unsubscribing you from this mailing list. Please feel free to resubscribe if you would actually like to become a package maintainer.
Re: Subject: SSH key for upload access
On Fri, Nov 15, 2013 at 01:44:57PM +0100, Jan Nijtmans wrote: Name: Jan Nijtmans Package: sqlite3, libsqlite3-devel, libsqlite3_0 BEGIN SSH2 PUBLIC KEY Comment: 2048-bit RSA, converted by nijtmaj@NB1912 from OpenSSH B3NzaC1yc2EDAQABAAABAQCoMlr/9sPXdDP6KA5b8bdfTHi6pDLZBT4DB24lqn lQIG3CxDVLGSudt+sMlHGxsLpa5eQBsFBuenNZH+GD4503BD/AIv8UpSkC8xTgIYAryIWP fLLHtF57thmk6LYWZlMSh2O1Va5EdnhmJhi75ZUFavfEYb/QFlllXGwUad9KkQ2mZqwBNK JM9lZnq+xJynWCHAkMLTLFXOHisTQSgiRc08fX/i9XHRC71jrua5N0y3af8MbjA5q/Mj9u jgUgRgB6+dJWpAgAKFsVPGnkT2TvG5hEwJbl6lE22/6mux2ETAq8sHkQjc//gmulFC0Rhj bJQpu93Q3/o3z/FIPRAGxF END SSH2 PUBLIC KEY From https://sourceware.org/cygwin-apps/package-upload.html Name: Your Name Package: The name of one of the packages that you are responsible for It doesn't say comma separated list of packages. These things are actually read by a script so that above doesn't work. I'll edit the above message and feed it through the script. I'm mentioning this so that future maintainers don't think this is the proper way to request upload access.
Re: Subject: SSH key for upload access
On Fri, Nov 15, 2013 at 10:10:21AM -0500, Christopher Faylor wrote: On Fri, Nov 15, 2013 at 01:44:57PM +0100, Jan Nijtmans wrote: Name: Jan Nijtmans Package: sqlite3, libsqlite3-devel, libsqlite3_0 BEGIN SSH2 PUBLIC KEY Comment: 2048-bit RSA, converted by nijtmaj@NB1912 from OpenSSH B3NzaC1yc2EDAQABAAABAQCoMlr/9sPXdDP6KA5b8bdfTHi6pDLZBT4DB24lqn lQIG3CxDVLGSudt+sMlHGxsLpa5eQBsFBuenNZH+GD4503BD/AIv8UpSkC8xTgIYAryIWP fLLHtF57thmk6LYWZlMSh2O1Va5EdnhmJhi75ZUFavfEYb/QFlllXGwUad9KkQ2mZqwBNK JM9lZnq+xJynWCHAkMLTLFXOHisTQSgiRc08fX/i9XHRC71jrua5N0y3af8MbjA5q/Mj9u jgUgRgB6+dJWpAgAKFsVPGnkT2TvG5hEwJbl6lE22/6mux2ETAq8sHkQjc//gmulFC0Rhj bJQpu93Q3/o3z/FIPRAGxF END SSH2 PUBLIC KEY From https://sourceware.org/cygwin-apps/package-upload.html Name: Your Name Package: The name of one of the packages that you are responsible for It doesn't say comma separated list of packages. These things are actually read by a script so that above doesn't work. I'll edit the above message and feed it through the script. I'm mentioning this so that future maintainers don't think this is the proper way to request upload access. The web page also doesn't say Put a single space in front of Name and Package. cgf
Re: SSH key for upload access
On Thu, Nov 14, 2013 at 12:49:50PM +0400, Mikhail Usenko wrote: Name: Mikhail Usenko Package: cygcheck-dep BEGIN SSH2 PUBLIC KEY B3NzaC1yc2EDAQABAAACAQCrr04wqp/lhb5jAIR0n/+qlYuuVIZ+Jl5h+4eRVK 4X4mS3NJ1JyL2gG4FzW6UCCdJPkzuCYWc8iOH9Ft/VUY2dnyY2qODnaK0KC59BbqfEjIvW zuxD8sg7Y+FEvgVwL0/077b/OvNd/rNmycKIXo/raNIScLUDILbMwWjO2GZag+gLj8ccRc DnBWn3Gp+9yC2QsKvSNzPk7xXnMkgDEz1SwAIkbcQQ/YvaJsuSPw2mBCLd9DPdf1uOYEwT wJAPagE87WlhMgANKw2LHfqTbnnk4mLsdSjUNJOH6L8lYFTlMzvWnN3tGvAkltefYZ8EK7 QUazuNiA4/1XB03HKR5676+u54pd+W+lEw2ui1WRXLJsPt/8Dhn2MpJ7Sz1t5Whlu6nNdu Dxvye2AhC38clZcRJWlaBQpJhCI4ZWaUMVg2LhEaN9RozuRdgWspzSj1p14EZM5nNvSivZ j9lpH3tupg8x301AF+GOEJO918ba03nCcvgetwhPqsJ/lI6sJKqHFxQXBKRJ9al5Ud5ew7 J0uTQIzACd/UPUP0R+bCjvY3Wp6/ieZ+/IY4PzPnnWqu3JhpsDxCTOHV+yV+gDmH7HYAEE AAYfwhIkv+90r5cg/sHF0XBNqm3dCbnwcuV+NW9RQPDO0b2edkafJUzDH75QkTnSojp765 7p2meiCcsxdhVQ== END SSH2 PUBLIC KEY Activated. cgf
Re: [ITA] sqlite3
On Thu, Nov 14, 2013 at 10:47:51AM +0100, Corinna Vinschen wrote: Jan, please see https://sourceware.org/cygwin-apps/package-upload.html for how to request upload privileges and how to upload, once you got your GTG for the package, which AFAICS, Warren would be the right guy to do. Jan has an upload directory on cygwin.com now. Jan, if you can send the information at the above link now, you'll be GTG for uploading as soon as the package has been pronounced GTG by Warrent. cgf
Re: Deleting old versions of packages
On Tue, Oct 29, 2013 at 04:50:38PM -0400, Christopher Faylor wrote: On Tue, Oct 29, 2013 at 09:02:56PM +0100, Achim Gratz wrote: Leave everything as is at the upload side, but add two cleanup passes on the release directory; a first that deletes zero-sized files and a second that removes empty directories. That way a maintainer can upload a file that he wants to be deleted. Then upset will see the cleaned up release directory and setup.ini won't have to specify tzhe exact versions of files most of the time. I don't think I have to worry about empty directories. Those are easy to purge. I was trying to avoid the zero-length file scenario but maybe that's the best that can be done. The ordering would have to be right so that upset doesn't first reference a file and then delete it of course. In further consideration in the thinking room, two other ideas presented themselves: 1) Create files with a leading '-' character to flag deletion. 2) Create a !deleteme directory containing files or directories that should be deleted. (Although empty directories can be automatically detected and are not really an issue) I like either of these better than the zero-length file because it will be obvious from simple directory scanning when a file needs to be deleted. I'm thinking that the leading '-' is the easiest to implement since it is stateless. cgf
Re: [ITA] sqlite3
On Thu, Nov 14, 2013 at 02:27:51PM -0500, Christopher Faylor wrote: On Thu, Nov 14, 2013 at 10:47:51AM +0100, Corinna Vinschen wrote: Jan, please see https://sourceware.org/cygwin-apps/package-upload.html for how to request upload privileges and how to upload, once you got your GTG for the package, which AFAICS, Warren would be the right guy to do. Jan has an upload directory on cygwin.com now. Jan, if you can send the information at the above link now, you'll be GTG for uploading as soon as the package has been pronounced GTG by Warrent. i.e., Warren cgf
Re: Deleting old versions of packages
On Thu, Nov 14, 2013 at 09:32:25PM +0100, Achim Gratz wrote: Christopher Faylor writes: In further consideration in the thinking room, two other ideas presented themselves: 1) Create files with a leading '-' character to flag deletion. That should be workable and relatively painless on all sides. 2) Create a !deleteme directory containing files or directories that should be deleted. (Although empty directories can be automatically detected and are not really an issue) I like '-' prefixed files alongside the files to be uploaded better than yet another directory hierarchy to traverse. But if you think this is easier to implement, I can adapt. I like either of these better than the zero-length file because it will be obvious from simple directory scanning when a file needs to be deleted. I'm thinking that the leading '-' is the easiest to implement since it is stateless. It is still zero-sized though or do you envision to have these files some content? I don't see any need for content but it actually won't matter what people put in the files. cgf
Re: [ITA] sqlite3
On Wed, Nov 13, 2013 at 04:03:40PM +0100, Jan Nijtmans wrote: I would like to adopt sqlite3. I've packaged the latest release. I don't think the package is in need of adoption. Warren Young is still around and active, AFAICT. cgf
Re: Struggling to upload
On Mon, Nov 11, 2013 at 10:50:00PM +, David Stacey wrote: I am attempting to upload perl-Text-CSV_XS-1.02-1 for both x86 and x86_64 architectures. I have uploaded the files into my home directory, and created '~/x86/!ready' and '~/x86_64/!ready' files. I see that the two '!ready' files have disappeared, but the new package is still in my home directory and is not visible on ftp.cygwin.com. Please could you tell me what I have done wrong! The software responsible for moving packages into the cygwin release area only recognizes your packages as listed in: http://cygwin.com/cygwin-pkg-maint Unfortunately, the files you uploaded don't match the case of the package in that file (perl-Text-CSV_XS vs. perl-text-csv_xs). I've just made 'upset' do a case insensitive match so try creating !ready files again and see if they are then eventually moved. cgf
Re: [GOLDSTAR] Re: [PATCH] setup: allow running as non-admin
On Sun, Nov 10, 2013 at 01:28:02PM +0100, Corinna Vinschen wrote: On Nov 10 02:28, Christopher Faylor wrote: On Sat, Nov 09, 2013 at 06:30:50PM +0100, Corinna Vinschen wrote: What changed is the way how normal users can install for just them. No name tweak but an option instead. Given what you wrote, an installation as normal user right from the net was not possible before, so just the method to do it changed slightly. By documenting it somewhere, we should be all set, shouldn't we? So, in other words, an end user will no longer have to rename setup*.exe to foo.exe to bypass enforced elevation but will, instead, just have to use a command-line option. Sounds good to me. We can add words for that to the install.html web page and to the FAQ. Exactly what I had in mind. I have some changes to setup-net.xml in the loop. I'll add some more to the FAQ and upload that next week. Nevertheless, on second thought we *could* do more, if we want to, now that we have our permissions completely under our own control. Provided somebody has fun working on that stuff, what we could do, for instance: - Per the Microsoft UAC guidelines(*) the elevation prompt should not be shown at all if UAC is switched off. The idea is to show a dialog instead, telling the user this application requires admin privs, yada yada, but in fact our setup would run as normal user just fine if we let it. See the next point. - Right now setup simply exits if the elevation didn't work or was canceled. What about a dialog instead, which asks the user something along the lines of Elevation canceled or UAC turned off, and then Setup can run without admin privs with some restrictions, are you aware of them and do you want to do that? [Yes/No] - This could be even more elegant if setup checks if the installer path in the registry is in HKLM. If so, it could refuse to do its stuff without admin rights, because it knows that the original installation has been performed with admin rights. Chances are high then, that a normal user won't have enough permissions to update the installation. - Something we could have done all along (and which has been mentioned on the Cygwin ML): We could drop the All users/Just me choice if the user has no admin rights. After all, the All user stuff can't be written anyway without admin rights. All good SHTDI ideas. cgf
Re: [GOLDSTAR] Re: [PATCH] setup: allow running as non-admin
On Sat, Nov 09, 2013 at 06:30:50PM +0100, Corinna Vinschen wrote: What changed is the way how normal users can install for just them. No name tweak but an option instead. Given what you wrote, an installation as normal user right from the net was not possible before, so just the method to do it changed slightly. By documenting it somewhere, we should be all set, shouldn't we? So, in other words, an end user will no longer have to rename setup*.exe to foo.exe to bypass enforced elevation but will, instead, just have to use a command-line option. Sounds good to me. We can add words for that to the install.html web page and to the FAQ. cgf
Re: [GOLDSTAR] Re: [PATCH] setup: allow running as non-admin
On Sat, Nov 09, 2013 at 11:04:34AM +1100, Shaddy Baddah wrote: On Nov 08 02:23, Christopher Faylor wrote: Thanks again for doing this. Done. Don't mention it. I have to mention it because your type of contribution is so rare in this project. There are only a handful of people who contribute code so you're very much appreciated. I'm delighted to give back to the Cygwin community and thank you all for what I feel is one of the best, if not the best open source project and community. I'll stick around too and help if there is any issues with the patch. Did you see the comments in the list? Are they valid complaints? cgf
Re: [GOLDSTAR] Re: [PATCH] setup: allow running as non-admin
On Thu, Nov 07, 2013 at 02:15:21PM +0100, Corinna Vinschen wrote: Hi Shaddy, On Nov 7 11:39, Shaddy Baddah wrote: 2013-11-06 Shaddy Baddah lithium-cygwin at shaddybaddah dot name * LogFile.cc (LogFile::flushAll): New function to flush log all logging to files without exiting (as LogFile::exit does). * LogFile.h: Declare new method closeAll. * main.cc (NoAdminOption): Add new CLI options -B/--no-admin. This option allows the user to suppress privilege elevation (in tandem with asInvoker requestedExecutionLevel changes to exe manifests). (WinMain): check if setup run with Administrator privilege and if the NoAdminOption has not been specified, attempt to elevate privilege to an Administrator via WINAPI ShellExecuteEx(). * setup.exe.manifest: Add requestedExecutionLevel of asInvoker to allow suppression of privilege elevation. * setup64.exe.manifest: Modify requestedExecutionLevel from requireAdministrator to asInvoker to allow suppression of privilege elevation. Continuity of privilege elevation attempt on startup is implemented by main.cc changes to WinMain(). * win32.cc (NTSecurity::isRunAsAdmin): New function to allow main.cc to check if setup.exe has been run with privilege elevated to Administrator level. * win32.h: Declare new method isRunAsAdmin. Thanks a lot for this patch. I applied it with a few minor tweaks. First of all, this comment was a bit misleading now, given that the code doesn't run on pre-Vista anyway: +// Note, this is necessary to avoid an infinite loop. +// The understanding is that pre-Vista, the runas verb will not +// result in a privilege elevated process. Therefore we need to +// indicate to the forked process that it should be happy with +// whatever privileges it is run with. +std::string command_line_cs (command_line); +command_line_cs += -; +command_line_cs += NoAdminOption.shortOption(); +sei.lpParameters = command_line_cs.c_str (); I shortened the comment to a simple one-liner: // Avoid another isRunAsAdmin check in the child. I also added a small change for the sake of starting setup from the command line. While the log to the logfiles has been stopped, the log to stdout persist up to the call of theLog-exit. I added a bit of code to stop printing Ending cygwin install if the elevation was successful. In that case the stdout log now prints note: Hand installation over to elevated child process. Thanks again for this patch, it's highly appreciated and is worth a gold star, I think. Chris, do your worst ;) The new setup's are installed. Shaddy, do you want to respond to the Cygwin ML thread and tell them that you've fixed the problem? Thanks again for doing this. cgf
Re: cannot run setup64.exe without admin privileges (even if renamed foo.exe)
On Wed, Nov 06, 2013 at 02:43:22PM +0100, Corinna Vinschen wrote: Looks fine to me. When you're ready to go, please send the complete patch in cleartext (not compressed) with a ChangeLog entry. I will give it a try and apply soon, so we can finally get rid of this problem. And, I'll be standing by to generate a new version of setup.exe as soon as the patch goes in. Then we can just sit back and tell people to upgrade when they complain. Ah, WJVM. cgf
Re: [PATCH] setup: allow running as non-admin
On Thu, Nov 07, 2013 at 10:52:00AM +1100, Shaddy Baddah wrote: Hi, As discussed, please find the patch to allow setup to be run as a non-admin user include clear text. -- Regards, Shaddy Only a very minor comment: + +// Note, this is necessary to avoid an infinite loop. +// The understanding is that pre-Vista, the runas verb will not This indentation looks wrong. + // result in a privilege elevated process. Therefore we need to + // indicate to the forked process that it should be happy with + // whatever privileges it is run with. cgf
Re: [PATCH] setup: allow running as non-admin
On Thu, Nov 07, 2013 at 11:25:37AM +1100, Shaddy Baddah wrote: Hi Christopher, On Nov 07 11:23, Christopher Faylor wrote: This indentation looks wrong. Should I correct and republish? Yes, please. cgf
Re: [PATCH] setup: allow running as non-admin
On Thu, Nov 07, 2013 at 11:39:51AM +1100, Shaddy Baddah wrote: Hi, On Nov 07 11:23, Christopher Faylor wrote: Hi, As discussed, please find the patch to allow setup to be run as a non-admin user include clear text. Thanks. I'll let Corinna have the final say on this but I really appreciate your willingness to provide a patch. cgf
Re: [ITP] cygcheck-leaves - a script to list installed packages not required by any
On Mon, Nov 04, 2013 at 01:39:25PM +0100, Corinna Vinschen wrote: On Oct 31 12:34, Mikhail Usenko wrote: Thanks for the comment. I've forgotten to test the script on 32-bit Windows. Now it uses a bash-specific variable to determine the CPU type and should work OK. Also after some time of using I've completely rewritten it having added new functionality and renamed it to 'cygcheck-dep'. setup.hint: --- category: Utils requires: bash coreutils sed wget bzip2 sdesc: Show information on dependencies for installed Cygwin packages --- Neat. I toyed a bit with your script and I like it. This could come in handy to isolate installation problems. I uploaded the package. Please send an announcement along the lines of the existing announcements to the cygwin-announce list. This needs to be in cygwin-pkg-maint and we'll need information as per: https://sourceware.org/cygwin-apps/package-upload.html . Also, FWIW, this package didn't really go through the vetting process of getting the required number of votes. I don't object to it going in but I don't think we want to get into the habit of short circuiting published procedures without at least acknowledging that we are doing so for a reason.
Re: [ITP] cygcheck-leaves - a script to list installed packages not required by any
On Mon, Nov 04, 2013 at 06:54:03PM +0100, Corinna Vinschen wrote: On Nov 4 12:45, Christopher Faylor wrote: On Mon, Nov 04, 2013 at 01:39:25PM +0100, Corinna Vinschen wrote: On Oct 31 12:34, Mikhail Usenko wrote: Thanks for the comment. I've forgotten to test the script on 32-bit Windows. Now it uses a bash-specific variable to determine the CPU type and should work OK. Also after some time of using I've completely rewritten it having added new functionality and renamed it to 'cygcheck-dep'. setup.hint: --- category: Utils requires: bash coreutils sed wget bzip2 sdesc: Show information on dependencies for installed Cygwin packages --- Neat. I toyed a bit with your script and I like it. This could come in handy to isolate installation problems. I uploaded the package. Please send an announcement along the lines of the existing announcements to the cygwin-announce list. This needs to be in cygwin-pkg-maint Did so while uploading. Ah, I was looking for cygcheck-leaves. Nevermind. cgf
Re: SSH key for upload access
On Wed, Oct 30, 2013 at 07:46:40AM -0600, Eric Blake wrote: On 10/29/2013 09:40 PM, Christopher Faylor wrote: On Tue, Oct 29, 2013 at 03:20:08PM -0700, Peter A. Castro wrote: Name: Peter A. Castro Package: zsh SSHkey: ssh-rsa B3NzaC1yc2EDAQABAAAEAQDFdqRkJQbjhJeoggEzOym1belbKv1IIJn+gAzqufl7BwOYcvtZ9hrqZLIdD4QtZLMJbGDRYzEEeXJqCcOy3OJjJ3PUq4q0CuZwiVppNlytxLlim7/0Ex+6gPTHS02nae9aFlMqIx+VVLn10yPj4N/wp/oNKKocWGi7cac42VTmwn6UadhznvkWu0q/f7lJbw4VdpdQz4w/I03C2x5rmuWW9W34GNkhtFudRkUfSaj+WPp2oabsN0EgdUnhcHB8K57y3oXAXMmHDGaf1SVLmlewZVYrKngmW3U9E6yFE20K+Di6I6yAeBmcfyUa7XlRZMO6s4GkqJI7wPa0CzUDv7wkn+RRr7SpHfI6dbGasFdJqgplOwPwjg0F4UN7Pn57MzgHGa9RFIWp7hiieuwh21rmWVQCqi7cLvCDC+734m51XYi21KzZT9OWOZGQELkYOpE5PXmuaIPDWJUWompqqu6blgvRKs5VRjimy7dcjQIni25Hj0Ai/81HKoMAOtaTrbx2LCg6zHQ9vkGK42do3DC8W93QNfPeAOFI14uTx35NYJagAEltiCAZp0wRZMlxVzECpX0LEdKRhAzYpMtpH+nkLKrWHiGISJIlFXKVc3Jr1H8gNW7BBtA/rKzeAXJa0vetYuO9ErGpnFwxC7jQIKg+Im2Nut0zMwmiXzvwo1XM/1x5lCf9EUDxs42CkPIh8GgUA6gnrGk0SmGaByZfyT0IrTrXo9INM+tZzHOGQK2/3WQPPP/mbTj6GgHFPMT/MfnIrwA1/r2N3U2GAQN6k5/QbgRG9blQw1Ukd2X4TKJLITKTnYN1VsTgCrwcotS2fQ7y2yVdHmTBxcNdO7f3lGa18v0dvpZXx1HcF4wbSsx4AYVHKWUlyuvLMzamT85bxDlABu7KKZddJrSS660W3Ts7vwEutc9oWluStBRB06doIDlyk! SS3PdogX+bB/W/MkNEN9HY2iMTxc+YyoLnH8Oi4Ibvv+/j8N4MJkHCxWPA/m3FkHdweXmls2IPmaLcFtdL2b53smH/cTVMq3eyg3yOEus5232fKOZYx0gMlyu8EsuSCkbYMk4QHDnlH2cwCoFNb5sXcYpkbuOO7YUzLWnGorzFdEzr3xxYjWjYessXrjPdkHRQbPibu30dP2XTzoM91f60KjI/7Ys3alPquofDuF9PFYOEy9YOQeREHGfhpIafRYybyhz0YSW1M5lsowIpzv/AM/rtGfvd97nIiRCIAR+ZBPOKmaJWBLKV7nJcYs5V/euqauvIJ9KPldgTpAbh+mZdqorBxZTFwTqdBloPCjXI2powYyWzIvVMKN2eNPakqdgM+J0LzJZw/jm4O4LDPMps+L3faKmJRmxFf9bdl CygwinUploads Uploaded after modifying the software to treat a !\n as (apparently) something special. Anyone know if there is an RFC which specifies this? SMTP (RFC 2821) recommends that clients not send lines longer than 999 bytes; many mailers obey this by using !\n as the continuation sequence to break long lines into something that fits SMTP. Thanks much for the info. I'm somewhat surprised that the perl package that I'm using to read these messages didn't handle that automatically. cgf
Re: SSH key for upload access
On Wed, Oct 30, 2013 at 09:56:51AM -0400, Christopher Faylor wrote: On Wed, Oct 30, 2013 at 07:46:40AM -0600, Eric Blake wrote: On 10/29/2013 09:40 PM, Christopher Faylor wrote: On Tue, Oct 29, 2013 at 03:20:08PM -0700, Peter A. Castro wrote: Name: Peter A. Castro Package: zsh SSHkey: ssh-rsa B3NzaC1yc2EDAQABAAAEAQDFdqRkJQbjhJeoggEzOym1belbKv1IIJn+gAzqufl7BwOYcvtZ9hrqZLIdD4QtZLMJbGDRYzEEeXJqCcOy3OJjJ3PUq4q0CuZwiVppNlytxLlim7/0Ex+6gPTHS02nae9aFlMqIx+VVLn10yPj4N/wp/oNKKocWGi7cac42VTmwn6UadhznvkWu0q/f7lJbw4VdpdQz4w/I03C2x5rmuWW9W34GNkhtFudRkUfSaj+WPp2oabsN0EgdUnhcHB8K57y3oXAXMmHDGaf1SVLmlewZVYrKngmW3U9E6yFE20K+Di6I6yAeBmcfyUa7XlRZMO6s4GkqJI7wPa0CzUDv7wkn+RRr7SpHfI6dbGasFdJqgplOwPwjg0F4UN7Pn57MzgHGa9RFIWp7hiieuwh21rmWVQCqi7cLvCDC+734m51XYi21KzZT9OWOZGQELkYOpE5PXmuaIPDWJUWompqqu6blgvRKs5VRjimy7dcjQIni25Hj0Ai/81HKoMAOtaTrbx2LCg6zHQ9vkGK42do3DC8W93QNfPeAOFI14uTx35NYJagAEltiCAZp0wRZMlxVzECpX0LEdKRhAzYpMtpH+nkLKrWHiGISJIlFXKVc3Jr1H8gNW7BBtA/rKzeAXJa0vetYuO9ErGpnFwxC7jQIKg+Im2Nut0zMwmiXzvwo1XM/1x5lCf9EUDxs42CkPIh8GgUA6gnrGk0SmGaByZfyT0IrTrXo9INM+tZzHOGQK2/3WQPPP/mbTj6GgHFPMT/MfnIrwA1/r2N3U2GAQN6k5/QbgRG9blQw1Ukd2X4TKJLITKTnYN1VsTgCrwcotS2fQ7y2yVdHmTBxcNdO7f3lGa18v0dvpZXx1HcF4wbSsx4AYVHKWUlyuvLMzamT85bxDlABu7KKZddJrSS660W3Ts7vwEutc9oWluStBRB06doIDlyk! SS3PdogX+bB/W/MkNEN9HY2iMTxc+YyoLnH8Oi4Ibvv+/j8N4MJkHCxWPA/m3FkHdweXmls2IPmaLcFtdL2b53smH/cTVMq3eyg3yOEus5232fKOZYx0gMlyu8EsuSCkbYMk4QHDnlH2cwCoFNb5sXcYpkbuOO7YUzLWnGorzFdEzr3xxYjWjYessXrjPdkHRQbPibu30dP2XTzoM91f60KjI/7Ys3alPquofDuF9PFYOEy9YOQeREHGfhpIafRYybyhz0YSW1M5lsowIpzv/AM/rtGfvd97nIiRCIAR+ZBPOKmaJWBLKV7nJcYs5V/euqauvIJ9KPldgTpAbh+mZdqorBxZTFwTqdBloPCjXI2powYyWzIvVMKN2eNPakqdgM+J0LzJZw/jm4O4LDPMps+L3faKmJRmxFf9bdl CygwinUploads Uploaded after modifying the software to treat a !\n as (apparently) something special. Anyone know if there is an RFC which specifies this? SMTP (RFC 2821) recommends that clients not send lines longer than 999 bytes; many mailers obey this by using !\n as the continuation sequence to break long lines into something that fits SMTP. Thanks much for the info. I'm somewhat surprised that the perl package that I'm using to read these messages didn't handle that automatically. I guess I should be asking for ssh-keygen -e format. I'll change the web page to specify this but, in the future, please use something like: ssh-keygen -e -f ~/.ssh/id_rsa.pub and just fill out the Name/Package fields, followed by output from that command. cgf
Change to procedure for requesting upload access
On Wed, Oct 30, 2013 at 11:25:53AM -0400, Christopher Faylor wrote: On Wed, Oct 30, 2013 at 09:56:51AM -0400, Christopher Faylor wrote: I guess I should be asking for ssh-keygen -e format. I'll change the web page to specify this but, in the future, please use something like: ssh-keygen -e -f ~/.ssh/id_rsa.pub and just fill out the Name/Package fields, followed by output from that command. I've updated https://sourceware.org/cygwin-apps/package-upload.html with the new procedure. cgf
Re: [ITP] fish shell 2.1.0
Since this is converging on a release of fish, don't forget to provide upload information at some point: https://sourceware.org/cygwin-apps/package-upload.html
Re: Deleting old versions of packages
On Tue, Oct 29, 2013 at 09:02:56PM +0100, Achim Gratz wrote: Leave everything as is at the upload side, but add two cleanup passes on the release directory; a first that deletes zero-sized files and a second that removes empty directories. That way a maintainer can upload a file that he wants to be deleted. Then upset will see the cleaned up release directory and setup.ini won't have to specify tzhe exact versions of files most of the time. I don't think I have to worry about empty directories. Those are easy to purge. I was trying to avoid the zero-length file scenario but maybe that's the best that can be done. The ordering would have to be right so that upset doesn't first reference a file and then delete it of course. In another discussion someone suggested a web-based form for deletion but if I was going to use that, I might as well use that method for upload too. I don't think I'm ready to scrap sftp now that this is implemented.
Re: SSH key for upload access
On Tue, Oct 29, 2013 at 09:36:44PM +0100, Konrad Borowski wrote: Name: Konrad Borowski Package: fish SSHkey: ssh-rsa B3NzaC1yc2EDAQABAAABAQC+7ew29lRE9nanr9fgceGZ4trqUhil+e2NpxlHzdct+60nn/Juz94hCrVRZdZbpsIgFdfwiKnsQWQ4kmXA7YE8VpfZp0NFTOikyQsakKJmYKr2VyBwdCi6EW8In91b5FjJZfh3G10WpXyKmy3Qim48jibAI8AhWJXSAZOPf45MyDBHVKkbwQnoKtH5BvYIt0R1ayPP4TM2Zu3DpIsNE4IjDFYlF0j5obWk6gahYjn3iiCHsxvuSU5JiK6z8l1z/ejqjJtIkH4Si6TPjOMf0Ufxb33HkRMZy6WIO6i8tDZiC1kKKDXQ9JC/FtPRtyR0pu+ZURsXPym6IOzb3rPQCDXF glitchmr@pineapple This has been activated. You will be able to upload after your package is given the green light. cgf
Re: SSH key for upload access
On Tue, Oct 29, 2013 at 03:20:08PM -0700, Peter A. Castro wrote: Name: Peter A. Castro Package: zsh SSHkey: ssh-rsa B3NzaC1yc2EDAQABAAAEAQDFdqRkJQbjhJeoggEzOym1belbKv1IIJn+gAzqufl7BwOYcvtZ9hrqZLIdD4QtZLMJbGDRYzEEeXJqCcOy3OJjJ3PUq4q0CuZwiVppNlytxLlim7/0Ex+6gPTHS02nae9aFlMqIx+VVLn10yPj4N/wp/oNKKocWGi7cac42VTmwn6UadhznvkWu0q/f7lJbw4VdpdQz4w/I03C2x5rmuWW9W34GNkhtFudRkUfSaj+WPp2oabsN0EgdUnhcHB8K57y3oXAXMmHDGaf1SVLmlewZVYrKngmW3U9E6yFE20K+Di6I6yAeBmcfyUa7XlRZMO6s4GkqJI7wPa0CzUDv7wkn+RRr7SpHfI6dbGasFdJqgplOwPwjg0F4UN7Pn57MzgHGa9RFIWp7hiieuwh21rmWVQCqi7cLvCDC+734m51XYi21KzZT9OWOZGQELkYOpE5PXmuaIPDWJUWompqqu6blgvRKs5VRjimy7dcjQIni25Hj0Ai/81HKoMAOtaTrbx2LCg6zHQ9vkGK42do3DC8W93QNfPeAOFI14uTx35NYJagAEltiCAZp0wRZMlxVzECpX0LEdKRhAzYpMtpH+nkLKrWHiGISJIlFXKVc3Jr1H8gNW7BBtA/rKzeAXJa0vetYuO9ErGpnFwxC7jQIKg+Im2Nut0zMwmiXzvwo1XM/1x5lCf9EUDxs42CkPIh8GgUA6gnrGk0SmGaByZfyT0IrTrXo9INM+tZzHOGQK2/3WQPPP/mbTj6GgHFPMT/MfnIrwA1/r2N3U2GAQN6k5/QbgRG9blQw1Ukd2X4TKJLITKTnYN1VsTgCrwcotS2fQ7y2yVdHmTBxcNdO7f3lGa18v0dvpZXx1HcF4wbSsx4AYVHKWUlyuvLMzamT85bxDlABu7KKZddJrSS660W3Ts7vwEutc9oWluStBRB06doIDlyk! SS3PdogX+bB/W/MkNEN9HY2iMTxc+YyoLnH8Oi4Ibvv+/j8N4MJkHCxWPA/m3FkHdweXmls2IPmaLcFtdL2b53smH/cTVMq3eyg3yOEus5232fKOZYx0gMlyu8EsuSCkbYMk4QHDnlH2cwCoFNb5sXcYpkbuOO7YUzLWnGorzFdEzr3xxYjWjYessXrjPdkHRQbPibu30dP2XTzoM91f60KjI/7Ys3alPquofDuF9PFYOEy9YOQeREHGfhpIafRYybyhz0YSW1M5lsowIpzv/AM/rtGfvd97nIiRCIAR+ZBPOKmaJWBLKV7nJcYs5V/euqauvIJ9KPldgTpAbh+mZdqorBxZTFwTqdBloPCjXI2powYyWzIvVMKN2eNPakqdgM+J0LzJZw/jm4O4LDPMps+L3faKmJRmxFf9bdl CygwinUploads Uploaded after modifying the software to treat a !\n as (apparently) something special. Anyone know if there is an RFC which specifies this?
Deleting old versions of packages
On Tue, Oct 22, 2013 at 10:14:52PM -0400, Christopher Faylor wrote: On Tue, Oct 22, 2013 at 11:31:34PM +0100, David Stacey wrote: Thanks to CGF for the effort that has gone into the new upload process - I've just uploaded a new package called 'icoutils' and it was really quite painless. One thing I haven't grasped yet is the mechanism by which old versions are deleted. If I were to upload a new version of an existing package, how would I go about removing the oldest? Eventually old packages will be deleted (actually archived) automatically. I haven't yet added that functionality to upset though. Maybe this weekend if I have the time. The problem with this method is that it forces you to use a setup.hint file to delete packages. For instance, I just had a case where I wanted make-4.0-2 to be curr and make-3.82.90-1 to be prev. I really don't want to have to change setup.hint to enforce that because that's error prone. If that's exactly what people were trying to warn me about then I apologize for being dense. I don't like the clunkiness of creating anti-files in the sftp directory to force deletions but I can't think of any other way to do this short of actually making it look like the entire release directory is in the user's sftp area. cgf
Re: Deleting old versions of packages
On Mon, Oct 28, 2013 at 09:21:49PM +0100, Achim Gratz wrote: Christopher Faylor writes: I don't like the clunkiness of creating anti-files in the sftp directory to force deletions but I can't think of any other way to do this short of actually making it look like the entire release directory is in the user's sftp area. What we've got is what I'd call a transactional procedure for maintaining our packages. The positive part is implemented: if the transaction gets committed (!ready) then any files get transferred to the release directory. Removing files is difficult for two reasons: a) we don't easily know the current state of the release directory and b) setup.hint may allow multiple states depending on what is already in the release directory. Keeping the deletion part a manual operation is possible, but probably goes against your intentions and a !delete file is iffy. So my proposal would be that the current state of the release directory is mirrored with (zero-sized?) files in the sftp area. A maintainer could then just delete any of those placeholders and the corresponding file would be deleted from the release directory. Crucially, the upload and the deletion would not necessarily need to happen with the same transaction. So your proposal is basically to do I can't think of any way to do this short of... That's not a very inspired proposal given the fact that I already mentioned the idea and implied that I wasn't keen on doing it that way. cgf
Re: SSH key for upload access
On Sun, Oct 27, 2013 at 11:38:41AM -0400, Bob Heckel wrote: Name: Bob Heckel Package: w3m SSHkey: ssh-rsa B3NzaC1yc2EDAQABAAACAQC+K2qMn2tp95y16TEQDVte5AZHYWs6CeNy/64R1c+NRU12Zq+C6YCHk4prf6iLSDrc4S2GkuC0R4AebUPY/kbm8QEsHlms2EESIf5qBi+dXGilGkLW6LcHGG7D6PuYgFYwVtZ/3EXdTC0qnRXgbAbT3isuck+AYOIrTx2YlLIoy2QKjSeaXgMbopvIu1Fnn0PmVl4h7zW9jWVJlbwxxbMk3MTp/+s2exGsUZQKcXnKmt+AAatnoUs6MCxR363+lKnS9dqUpC+2MmYd/reTU3DE3yg2+oKFhkL+7WlyoSfMpprPYDa9z9W9mLEojv2Mr343H6LddvC1UTuxxNcfk0u0GzXTH6Mnb+IMtIeoWG78pXZX3Cbkq5tIRn6reTNIhclbL7XsijKfyYDskMc6XQ8SYhV4pYb3kSHaC15rRARf8EtWq5sO57b66y1mlqxI7Q3y5gIL9OVGiD4aVlW5eXMtzqrFR4rIY4DUU8EN1m9+BU6Z7ObaOiW9u+9yWMzrzqBPaX7mMEBJgtkcrdTe4lMDz0Ve9iEcpgPcQWC3AGiPJIOIa0lYZnPixWWvMUDXG1Gt3o6tF6VPqlBMkmOTVWjXU+y8mR1qyxQ402P1HVKiYks37JrAJWWtzKB2Qb50u/48Ukd34FtODb9Q1zKn+x34poZkAORsgITqAHhsNhvw/Q== cygupload Activated. Out of curiosity, do you have any idea why the SSHkey above showed up on three lines? It should be one line. cgf
