setitimer failure
hello. I really have to know if the setitimer() primitive works well using cywgin dll I am currently using NT5.0 (2000) I call setitimer(ITIMER_VIRTUAL, interval, NULL) and it returns -1 with bad argument as errno . I do not understand why, because my arguments seemes to be ok to me ! Any help very appreciated. gilles
Re: [nasm packaging review] was Re: Pending packages status
On Mon, 30 Dec 2002, Dean Scarff wrote: Done, the new binary package nasm-0.98.35-2 has everything except the pdf (due to ghostscript problems as I mentioned elsewhere). Updated files are here: http://proud-x.com/~p00ya/cygwin-apps/nasm/setup.hint http://proud-x.com/~p00ya/cygwin-apps/nasm/nasm-0.98.35-2.tar.bz2 http://proud-x.com/~p00ya/cygwin-apps/nasm/nasm-0.98.35-2-src.tar.bz2 Ok, I've just reviewed the package. Do you mind moving the contents of /usr/doc/nasm to /usr/doc/nasm-0.98.35 ? Btw, please, do not update the cygwin specific part of the package version number when releasing an updated version in the process of reviewing.
Re: [nasm packaging review] was Re: Pending packages status
Pavel Tsekov wrote: On Mon, 30 Dec 2002, Dean Scarff wrote: Done, the new binary package nasm-0.98.35-2 has everything except the pdf (due to ghostscript problems as I mentioned elsewhere). Updated files are here: http://proud-x.com/~p00ya/cygwin-apps/nasm/setup.hint http://proud-x.com/~p00ya/cygwin-apps/nasm/nasm-0.98.35-2.tar.bz2 http://proud-x.com/~p00ya/cygwin-apps/nasm/nasm-0.98.35-2-src.tar.bz2 Ok, I've just reviewed the package. Do you mind moving the contents of /usr/doc/nasm to /usr/doc/nasm-0.98.35 ? Btw, please, do not update the cygwin specific part of the package version number when releasing an updated version in the process of reviewing. Didn't the last discussion on this agree on *DO* update the Cygwin-specific release number during reviewing? Max.
Re: [nasm packaging review] was Re: Pending packages status
Pavel Tsekov wrote: On Mon, 30 Dec 2002, Max Bowsher wrote: Btw, please, do not update the cygwin specific part of the package version number when releasing an updated version in the process of reviewing. Didn't the last discussion on this agree on *DO* update the Cygwin-specific release number during reviewing? Please, consult the last discussion about that. My memory is incorrect. Sorry. I do think that a version number should uniquely identify a version, though. A possibility that was not considered last time this was discussed is to start the reviewing at -0.1, going -0.2, -0.3, etc., and then bump to -1 on release. Feel free to ignore me if you don't want to reopen this discussion. Max.
Re: UPX updated to 1.24
Pavel Tsekov wrote: http://www.lapo.it/tmp/upx-1.24-1-src.tar.bz2 http://www.lapo.it/tmp/upx-1.24-1.tar.bz2 I've removed the 1.20-1 packages. Lapo, there was no announcement for this package. Whops.. forgot to send it before holidays =( Sent right now. -- Lapo 'Raist' Luchini [EMAIL PROTECTED] (PGP X.509 keys available) http://www.lapo.it (ICQ UIN: 529796)
xinetd and chkconfig - ok to upload ?
On Tue, 24 Dec 2002, Pavel Tsekov wrote: 1. xinetd version: 2.3.9-1 status : reviewed; ready for upload (?!) 2. chkconfig version: 1.2.24h-1 status : reviewed; ready for upload Does anyone have any objections if I upload this packages ? I've doubts only about xinetd. Sergey answered Charles's question and there was no response from Charles, so it should be ok, right ?
Re: [nasm packaging review] was Re: Pending packages status
On Mon, 30 Dec 2002, Max Bowsher wrote: I do think that a version number should uniquely identify a version, though. A possibility that was not considered last time this was discussed is to start the reviewing at -0.1, going -0.2, -0.3, etc., and then bump to -1 on release. Feel free to ignore me if you don't want to reopen this discussion. Hello, Max Just to let you know that I do not want to ignore your opinion, nor do I want to ignore any other peoples' opinion. I just do not have strong opinion on this topic. So, as far as I'm concerned I'm trying to follow the instructions at http://cygwin.com/setup.html. If as a result of a discussion on this list this instructions do change, I'll follow the new instructions whatever they are.
Re: ifhp package
Pavel Tsekov said: Then why not just wait until all the pieces are ready ? OK, I'll do that. I'll post again when everything is ready.
Re: xinetd and chkconfig - ok to upload ?
Short version: as far as MY concerns go, these two packages are ok for upload. On Tue, 24 Dec 2002, Pavel Tsekov wrote: 1. xinetd version: 2.3.9-1 status : reviewed; ready for upload (?!) 2. chkconfig version: 1.2.24h-1 status : reviewed; ready for upload Does anyone have any objections if I upload this packages ? I've doubts only about xinetd. Sergey answered Charles's question and there was no response from Charles, so it should be ok, right ? Yes, I guess so. There were two separate subthreads -- one on xinetd and one on chkconfig, but Sergey answered some but not all of the questions all in one reply. However, the questions he left unaddressed were not showstoppers. Concerning xinetd, http://cygwin.com/ml/cygwin-apps/2002-12/msg00114.html addressed most of the issues. Sergey explained that a preremove script couldn't do this: (*) rm -f /etc/xinetd.d/* (*) rmdir /etc/xinetd.d (*) rm -f /etc/xinetd.conf but he never said why it couldn't at least do this (since I had suggested all six operations): rm -f /usr/bin/xinetd-config chkconfig --del xinetd 21 /dev/null rm -f /etc/rc.d/init.d/xinetd As it turns out, ONLY the first action in the second group (rm -f /usr/bin/xinetd-config) can actually be done from a preremove script, since xinetd-config will be automatically and unconditionally replaced by the postinstall script if this is an upgrade, and not an actual removal. However, the other two actions in the second group -- creating init.d/xinetd and making the rc.N/symlinks -- are only done when the user explicitly runs /usr/bin/xinetd-config. Thus, on upgrade, if the preremove script removes those, the user will have to re-run xinetd-config to recreate that file and symlinks. Blech. I don't think there is a clean way to do this (and ssh doesn't clean up /usr/bin/sshd-*-config either) unless we have a set of scripts like /etc/postinstall/ /etc/postupgrade/ /etc/preupgrade/ /etc/preremove/ and setup knows about upgrades vs. removals, and calls the correct scripts. But that's a MESS -- and would probably break a lot of existing packages that depend on the current behavior for proper operation on upgrade/install/remove. I'd rather leave a few droppings around after an real uninstall and let upgrades remain simple. There was also an issue with sunrpc: Sergey said: Me too. I'd like to build rpc-aware xinetd with sunrpc package. I'm not sure if that means he wants to WAIT for the sunrpc package to be accepted into cygwin, then rebuild his xinetd package so that it uses the rpc stuff, or if he wants to go forward with xinetd AS-IS and add rpc stuff later on as an update. I suspect the latter. So, as far as MY concerns go, these two packages are ok for upload. --Chuck
exim 4.12-1
A new exim release is ready for upload http://home.attbi.com/~phumblet/setup.hint http://home.attbi.com/~phumblet/exim-4.12-1.tar.bz2 http://home.attbi.com/~phumblet/exim-4.12-1-src.tar.bz2 The new setup.hint appears below. No change except for the version number. Thanks Pierre # Exim-4.12-1 setup.hint sdesc: A Mail Transfer Agent. ldesc: Mail Transfer Agent with sendmail like command line arguments and a single configuration file. Features: flexible retry algorithms, header envelope rewriting, multiple deliveries down single connection or multiple deliveries in parallel, regular expressions in configuration parameters, file lookups, supports sender and/or receiver verification, selective relaying, virtual domains and built-in mail filtering. See www.exim.org. This port is compiled with tls/ssl support. category: Mail requires: cygwin gdbm openssl
Re: xinetd and chkconfig - ok to upload ?
From: Charles Wilson [EMAIL PROTECTED] I don't think there is a clean way to do this (and ssh doesn't clean up /usr/bin/sshd-*-config either) unless we have a set of scripts like /etc/postinstall/ /etc/postupgrade/ /etc/preupgrade/ /etc/preremove/ and setup knows about upgrades vs. removals, and calls the correct scripts. But that's a MESS -- and would probably break a lot of existing packages that depend on the current behavior for proper Yep! You got my point. We can't do a clean package uninstall without distinguishing between uninstall/upgrade actions. Moreover, I can't do /usr/sbin/chkconfig --del xinetd in xinetd's preremove script because chkconfig may be removed already by setup on simultaneous upgrade of both xinetd and chkconfig pachages! BTW, shouldn't setup remove/install the packages one by one? Currently if several packages are upgraded at the same time setup removes _all_ the packages to be upgared first and installs all the upgrade packages after that. Sergey said: Me too. I'd like to build rpc-aware xinetd with sunrpc package. I'm not sure if that means he wants to WAIT for the sunrpc package to be accepted into cygwin, then rebuild his xinetd package so that it uses the rpc stuff, or if he wants to go forward with xinetd AS-IS and add rpc stuff later on as an update. I suspect the latter. You're right, I'm going to add RPC support to the next version of xinetd, I'd like to have XXX-1 version of xinetd to be uploaded as is. Sergey Okhapkin Somerset, NJ
Re: xinetd and chkconfig - ok to upload ?
On Tue, 2002-12-31 at 09:50, Sergey Okhapkin wrote: BTW, shouldn't setup remove/install the packages one by one? Currently if several packages are upgraded at the same time setup removes _all_ the packages to be upgared first and installs all the upgrade packages after that. Because of file moves: If file A is in package bar, and moves to package foo, then on upgrade, bar must be removed (removing the old A) before package foo is installed. The current behaviour is a stop gap before full file by file inspection. The primary guarantee of the current behaviour is that it always does the *right thing* when moving files between packages. Rob -- --- GPG key available at: http://users.bigpond.net.au/robertc/keys.txt. --- signature.asc Description: This is a digitally signed message part
Re: [nasm packaging review] was Re: Pending packages status
On Mon, Dec 30, 2002 at 01:18:05PM +0800, Dean Scarff wrote: Done, the new binary package nasm-0.98.35-2 has everything except the pdf (due to ghostscript problems as I mentioned elsewhere). What problems exactly are you having with Ghostscript? I'll assume that you're referring to the Cygwin version of Ghostscript. -- Dario Alcocer -- Sr. Software Developer, Helix Digital Inc. [EMAIL PROTECTED] -- http://www.helixdigital.com
Re: [nasm packaging review] was Re: Pending packages status
- Original Message - From: Pavel Tsekov [EMAIL PROTECTED] Date: Mon, 30 Dec 2002 11:11:59 +0100 (CET) On Mon, 30 Dec 2002, Dean Scarff wrote: Done, the new binary package nasm-0.98.35-2 has everything except the pdf (due to ghostscript problems as I mentioned elsewhere). Updated files are here: http://proud-x.com/~p00ya/cygwin-apps/nasm/setup.hint http://proud-x.com/~p00ya/cygwin-apps/nasm/nasm-0.98.35-2.tar.bz2 http://proud-x.com/~p00ya/cygwin-apps/nasm/nasm-0.98.35-2-src.tar.bz2 Ok, I've just reviewed the package. Do you mind moving the contents of /usr/doc/nasm to /usr/doc/nasm-0.98.35 ? Btw, please, do not update the cygwin specific part of the package version number when releasing an updated version in the process of reviewing. My mistake, both the above points are fixed now. The new binary package looks like: usr/ usr/man/ usr/man/man1/ usr/man/man1/nasm.1 usr/man/man1/ndisasm.1 usr/info/ usr/info/nasm.info usr/info/nasm.info-1 usr/info/nasm.info-10 usr/info/nasm.info-11 usr/info/nasm.info-12 usr/info/nasm.info-13 usr/info/nasm.info-14 usr/info/nasm.info-2 usr/info/nasm.info-3 usr/info/nasm.info-4 usr/info/nasm.info-5 usr/info/nasm.info-6 usr/info/nasm.info-7 usr/info/nasm.info-8 usr/info/nasm.info-9 usr/bin/ usr/bin/rdf2com.exe usr/bin/nasm.exe usr/bin/ndisasm.exe usr/bin/rdfdump.exe usr/bin/ldrdf.exe usr/bin/rdx.exe usr/bin/rdflib.exe usr/bin/rdf2bin.exe usr/bin/rdf2ihx.exe usr/doc/ usr/doc/nasm-0.98.35/ usr/doc/nasm-0.98.35/html/ usr/doc/nasm-0.98.35/html/nasmdo10.html usr/doc/nasm-0.98.35/html/nasmdoc0.html usr/doc/nasm-0.98.35/html/nasmdoc1.html usr/doc/nasm-0.98.35/html/nasmdoc2.html usr/doc/nasm-0.98.35/html/nasmdoc3.html usr/doc/nasm-0.98.35/html/nasmdoc4.html usr/doc/nasm-0.98.35/html/nasmdoc5.html usr/doc/nasm-0.98.35/html/nasmdoc6.html usr/doc/nasm-0.98.35/html/nasmdoc7.html usr/doc/nasm-0.98.35/html/nasmdoc8.html usr/doc/nasm-0.98.35/html/nasmdoc9.html usr/doc/nasm-0.98.35/html/nasmdoca.html usr/doc/nasm-0.98.35/html/nasmdocb.html usr/doc/nasm-0.98.35/html/nasmdoci.html usr/doc/nasm-0.98.35/nasmdoc.ps usr/doc/nasm-0.98.35/nasmdoc.txt usr/doc/nasm-0.98.35/AUTHORS usr/doc/nasm-0.98.35/CHANGES usr/doc/nasm-0.98.35/INSTALL usr/doc/nasm-0.98.35/COPYING usr/doc/nasm-0.98.35/README usr/doc/nasm-0.98.35/TODO usr/doc/nasm-0.98.35/ChangeLog usr/doc/Cygwin/ usr/doc/Cygwin/nasm-0.98.35.README Updated files are at: http://proud-x.com/~p00ya/cygwin-apps/nasm/setup.hint http://proud-x.com/~p00ya/cygwin-apps/nasm/nasm-0.98.35-1.tar.bz2 http://proud-x.com/~p00ya/cygwin-apps/nasm/nasm-0.98.35-1-src.tar.bz2 Cheers, Dean Scarff -- ___ Get your free email from http://mymail.operamail.com Powered by Outblaze
Re: [nasm packaging review] was Re: Pending packages status
From: Dario Alcocer alcocer at helixdigital dot com Date: Mon, 30 Dec 2002 18:35:28 -0800 What problems exactly are you having with Ghostscript? I'll assume that you're referring to the Cygwin version of Ghostscript. They may not be a problem with ghostscript at all, contrary to what I said before. It may actually be a problem with the .ps that was generated. I have no experience with either format, but here's the error message from ps2pdf: $ ps2pdf -dOptimize=true nasmdoc.ps nasmdoc.pdf Error: /undefined in setpagesize Operand stack: Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval- - 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- fa lse 1 %stopped_push 1 3 %oparray_pop 1 3 %oparray_pop .runexec 2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push -- nostringval-- --nostringval-- --nostringval-- Dictionary stack: --dict:1085/1123(ro)(G)-- --dict:0/20(G)-- --dict:111/200(L)-- Current allocation mode is local Current file position is 52386 GNU Ghostscript 7.05: Unrecoverable error, exit code 1 The .ps was generated from a perl script that exited without error. The build works on debian with perl 5.8.0 and GNU Ghostscript 7.05. I'm using those same versions of each on cywin. I'm sorry for assuming this was a problem with ghostscript if it isn't. If you or anyone knows the source of this problem, I'd be happy to know. Otherwise, I'm quite happy to leave the pdf out - it would double the size of the binary package, and its not a format that is particularly useful (imho) in cygwin when there's html as well. Cheers, Dean Scarff -- ___ Get your free email from http://mymail.operamail.com Powered by Outblaze
Re: [nasm packaging review] was Re: Pending packages status
On Tue, Dec 31, 2002 at 11:25:25AM +0800, Dean Scarff wrote: The .ps was generated from a perl script that exited without error. The build works on debian with perl 5.8.0 and GNU Ghostscript 7.05. I'm using those same versions of each on cywin. Compare the Postscript file that was produced on your Debian system with the one produced on Cygwin. If both Postscript files are exactly the same, then I'd say that there's a problem with Ghostscript. -- Dario Alcocer -- Sr. Software Developer, Helix Digital Inc. [EMAIL PROTECTED] -- http://www.helixdigital.com
