Re: PostgreSQL, getting it up
On 3/22/2013 12:39 PM, d. henman wrote: Marco, thanks for the direction. ($ cygrunsrv.exe -S cygserver ) I might have tried $ cygrunsrv -s server (without the cyg prefix) According to: /usr/share/doc/Cygwin/postgresql.README " cygrunsrv is not required anymore, pg_ctl has now the service functions included. cygserver must run as service, CYGWIN must contain server." I will look on the documentation; I have not reviewed it for 9.x series as busy fighting other serious issues That phrase "cygrunsrv is not required anymore" threw me off. So the above is wrong in that it is needed to start cygserver. And the environment variable CYGWIN needs to contain the text, "server" in it. I'll try that. Regards Marco
64bit: cygstdc++-6.dll
latest libstdc++6-4.8-20130319-1 has at least a missing entry point from previous dll cmake fails with "_ZTVN10_cxxabiv117_class_type_infoE could not be located" regards Marco
setup64.ini: wrong current version ?
from setup64.ini @ cygwin sdesc: "The UNIX emulation engine" category: Base requires: base-cygwin version: 1.7.18-9 install: 64bit/release/cygwin/cygwin-1.7.18-9.tar.bz2 source: 64bit/release/cygwin/cygwin-1.7.18-9-src.tar.bz2 [prev] version: 1.7.18-10 install: 64bit/release/cygwin/cygwin-1.7.18-10.tar.bz2 source: 64bit/release/cygwin/cygwin-1.7.18-10-src.tar.bz2 regards Marco
Re: patch for build mc-4.8.7 cygwin 64 bit
On 3/22/2013 9:46 PM, adam kisiel wrote:
--- origsrc/mc-4.8.7/src/filemanager/mountlist.c2012-12-27
09:13:20.0 +0100
+++ src/mc-4.8.7/src/filemanager/mountlist.c2013-03-22
thanks, but last stable is 4.8.1.7
just built for 32 bit with
--- origsrc/mc-4.8.1.7/src/filemanager/mountlist.c 2012-12-28
09:47:48.0 +0100
+++ src/mc-4.8.1.7/src/filemanager/mountlist.c 2013-03-22
23:33:24.430506900 +0100
@@ -227,8 +227,7 @@
#ifdef MOUNTED_GETMNTENT1
#define ME_DUMMY(Fs_name, Fs_type, Fs_ent) \
(ME_DUMMY_0 (Fs_name, Fs_type)\
- || (strcmp (Fs_type, "none") == 0\
- && !hasmntopt (Fs_ent, "bind")))
+ || (strcmp (Fs_type, "none") == 0 ))
#else
#define ME_DUMMY(Fs_name, Fs_type) \
(ME_DUMMY_0 (Fs_name, Fs_type) || strcmp (Fs_type, "none") == 0)
@@ -240,7 +239,7 @@
/* All cygwin mount points include `:' or start with `//'; so it
requires a native Windows call to determine remote disks. */
static int
-me_remote (char const *fs_name, char const *fs_type _GL_UNUSED)
+me_remote (char const *fs_name, char const *fs_type )
{
if (fs_name[0] && fs_name[1] == ':')
{
I will build for 64bit in short term
build on testing distro all depend in
ftp://cygwin.com/pub/cygwin/64bit
I use two days no errors.
binary and source package is
on my side
http://code.google.com/p/cyg64distro/downloads/list
building in cygport
only:
install coreutils-8.15-2
nocoreutils-8.21-1 !! is broken "configure error"
thanks,
I was just trying to understand what broke my system
sorry for my english. "google translate"
big thanks to:
Corinna, Yaakov
and all the cygwin team
cygwin 64-bit is faster
Regards
Marco
64bit: coreutils-8.21-1 broken
Corinna, as reported by Adam deep inside his mc post coreutils-8.21-1 produce a "configure error" on automake/configure scripts. I noticed with fftw that some lines output were swallowed coreutils-8.15-2 has not such problem Regards
Re: coreutils-8.15-2 src cygwin 64bit
On 3/23/2013 12:27 PM, adam kisiel wrote: ftp://cygwin.com/pub/cygwin/64bit/release/coreutils/coreutils-8.15-2-src.tar.bz2 [cut] cygwin 64 bit do not need this. CC=gcc-4 please correct. I am sure that Corinna knows what to do http://cygwin.com/who.html Regards Marco
Re: patch for build mc-4.8.7 cygwin 64 bit
On 3/23/2013 8:48 AM, marco atzeri wrote: On 3/22/2013 9:46 PM, adam kisiel wrote: I will build for 64bit in short term 4.8.1.7 uploaded Regards Marco
Re: 64bit: cygstdc++-6.dll
On 3/25/2013 9:52 AM, Corinna Vinschen wrote: On Mar 24 03:33, Yaakov (Cygwin/X) wrote: On 2013-03-23 04:50, Corinna Vinschen wrote: On Mar 22 19:11, marco atzeri wrote: latest libstdc++6-4.8-20130319-1 has at least a missing entry point from previous dll cmake fails with "_ZTVN10_cxxabiv117_class_type_infoE could not be located" However, a quick glance into the symbols exported by libstdc++.a shows that the above symbol exists, but with additional leading underscores: _ZTVN10__cxxabiv117__class_type_infoE ^ ^ It's hard to see, but the error message actually does have double underscores. I don't quite understand. From what Marco pasted above, it doesn't. I copied manually from the windows error message, so Yaakov highlighted that I have missed the double underscores as "hard to see". The x86_64 ABI does not prepends underscores in front of symbols, so there has evidently gone something wrong. I checked my the Linux cross toolchain and it is also using the symbols with additional leading underscores. Off the top of my head I don't see where this discrepancy is caused. The PE underscore only applies to the very beginning of a symbol, not to every component of a C++ symbol name. Those double underscores are straight from libstdc++ code, as they are internal symbols. In any case, the error is a result of adding one of Dave Korn's patches: http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/gcc;a=blob;f=4.7-libstdc-dllimport.patch;hb=refs/heads/4.8#l29 I have omitted that patch in the new 4.8.0-1. Hopefully Dave can explain the purpose and necessity of that patch, since it would seem that using (at least that hunk of) it would require rebuilding most C++ packages in 64bit/release; if it's really necessary, then we will want to do that sooner rather than later. That I don't quite understand either. If this is only about missing exported symbols and not about the name, how are the already built C++ packages affected? They could be built, so they didn't use this symbols, apparently. I'm slightly confused now... Corinna
setup64.ini update
Corinna, for what I see the setup64.ini is manually updated, but there is a mismatch between the build and the location install: 64bit/release from GEN-sware: cd /sourceware/ftp/pub/cygwin || exit 1 [cut]/bin/genini --recursive --output=64bit/setup64.ini 64bit/release cd 64bit || exit 1 bzip2 -9c setup64.ini > setup64.bz2 chmod 664 setup64.ini setup64.bz2 It should be built in the 64bit directory with cd /sourceware/ftp/pub/cygwin/64bit [cut]/bin/genini --recursive --output=setup64.ini release otherwise the only way for setup64 to work is to copy back the setup64.exe and setup64.ini from pub/cygwin/64bit to pub/cygwin Marco
Re: setup64.ini update
On 3/25/2013 10:57 AM, Corinna Vinschen wrote: On Mar 25 10:38, marco atzeri wrote: setup64.exe is tweaked to read the setup64.ini files from the 64bit subdir. The paths in the setup64.ini files must be relative to the parent "cygwin" dir, otherwise the paths are wrong. What problem exactly do you see? Corinna my fault, I misunderstood the base directory it is not the "pub/cygwin/64bit" where setup64.exe is, but "pub/cygwin" as the 32bit install Regards Marco
Re: patch for build mc-4.8.7 cygwin 64 bit
On 3/25/2013 4:10 PM, Eric Blake wrote: On 03/22/2013 02:46 PM, adam kisiel wrote: --- origsrc/mc-4.8.7/src/filemanager/mountlist.c2012-12-27 09:13:20.0 +0100 +++ src/mc-4.8.7/src/filemanager/mountlist.c2013-03-22 19:59:40.866980200 +0100 @@ -225,11 +225,17 @@ we grant an exception to any with "bind" in its list of mount options. I.e., those are *not* dummy entries. */ #ifdef MOUNTED_GETMNTENT1 +#ifdef HAVE_HASMNTOPT #define ME_DUMMY(Fs_name, Fs_type, Fs_ent) \ (ME_DUMMY_0 (Fs_name, Fs_type)\ || (strcmp (Fs_type, "none") == 0\ && !hasmntopt (Fs_ent, "bind"))) Actually, for any package afflicted by this gnulib bug (coreutils and findutils have also both hit it), I've been applying this upstream gnulib patch: http://git.sv.gnu.org/cgit/gnulib.git/commit/lib/mountlist.c?id=62bb7a8b Eric, it seems already on mc trunk, that uses an unusual sync with gnulib https://www.midnight-commander.org/changeset?reponame=&new=a85fc3367e4e821e7585f52b3a04715f9d6c1b1a%40src%2Ffilemanager%2Fmountlist.c&old=bbf1f4e8577e4608bfb832366c3c7a6ecea653d6%40src%2Ffilemanager%2Fmountlist.c Question, how do you manage : me_remote (char const *fs_name, char const *fs_type _GL_UNUSED) as _GL_UNUSED is always giving problem and I need to change with me_remote (char const *fs_name, char const *fs_type ) to allow build ? Regards Marco
Re: [64bit RFU] xmlstarlet-1.4.2-1
On 4/1/2013 2:43 PM, David Stacey wrote:
BASEURL=http://dl.dropbox.com/sh/7y1yn4whbyho9a7
wget --no-host-directories --force-directories --cut-dirs=5 \
${BASEURL}/ZMxLdGuAOB/64bit/release/xmlstarlet/setup.hint \
${BASEURL}/-0L7Ciq1OA/64bit/release/xmlstarlet/xmlstarlet-1.4.2-1-src.tar.bz2
\
${BASEURL}/YUKx1I2ao8/64bit/release/xmlstarlet/xmlstarlet-1.4.2-1.tar.bz2 \
${BASEURL}/RmYWLRBzf0/64bit/release/xmlstarlet/xmlstarlet-debuginfo/setup.hint
\
${BASEURL}/OXEiqObJog/64bit/release/xmlstarlet/xmlstarlet-debuginfo/xmlstarlet-debuginfo-1.4.2-1.tar.bz2
This is my first 64-bit package, so I'd appreciate it if someone could
take a quick look at it. However it appears to work fine, and all the
built-in tests give the expected results.
Dave.
uploaded
64bit: segfault on program exit
I am building and testing openmpi-1.7.0rc9 on CYGWIN_NT-6.1 1.7.18(0.263/5/3) 2013-03-28 22:07 x86_64 Cygwin every looks fine except when all the processes on several cores end and should return to lunching program, something go wrong (of course on 32bit everyhing is OK) Attached stackdump. $ mpirun -np 4 ./hello_c.exe Hello, world, I am 1 of 4, (Open MPI v1.7rc9, package: Open MPI marco@MARCOATZERI Distribution, ident: 1.7rc9, Mar 28, 2013, 96) Hello, world, I am 3 of 4, (Open MPI v1.7rc9, package: Open MPI marco@MARCOATZERI Distribution, ident: 1.7rc9, Mar 28, 2013, 96) Hello, world, I am 2 of 4, (Open MPI v1.7rc9, package: Open MPI marco@MARCOATZERI Distribution, ident: 1.7rc9, Mar 28, 2013, 96) Hello, world, I am 0 of 4, (Open MPI v1.7rc9, package: Open MPI marco@MARCOATZERI Distribution, ident: 1.7rc9, Mar 28, 2013, 96) [MARCOATZERI:05260] *** Process received signal *** [MARCOATZERI:05260] Signal: Segmentation fault (11) [MARCOATZERI:05260] Signal code: (23) [MARCOATZERI:05260] Failing at address: 0x488f23380 [MARCOATZERI:05260] *** End of error message *** Segmentation fault debugging with gdb is not very useful as (gdb) run -np 4 ./hello_c.exe Starting program: /usr/bin/orterun.exe -np 4 ./hello_c.exe [New Thread 1964.0x23a8] [New Thread 1964.0x1554] [New Thread 1964.0x27dc] [New Thread 1964.0x1388] [New Thread 1964.0x5a4] [New Thread 1964.0x15bc] [New Thread 1964.0x23e4] [New Thread 1964.0x2244] [New Thread 1964.0x163c] [New Thread 1964.0x16f8] [New Thread 1964.0x2718] [New Thread 1964.0x2018] [New Thread 1964.0x19c4] Hello, world, I am 0 of 4, (Open MPI v1.7rc9, package: Open MPI marco@MARCOATZERI Distribution, ident: 1.7rc9, Mar 28, 2013, 96) Hello, world, I am 2 of 4, (Open MPI v1.7rc9, package: Open MPI marco@MARCOATZERI Distribution, ident: 1.7rc9, Mar 28, 2013, 96) Hello, world, I am 3 of 4, (Open MPI v1.7rc9, package: Open MPI marco@MARCOATZERI Distribution, ident: 1.7rc9, Mar 28, 2013, 96) Hello, world, I am 1 of 4, (Open MPI v1.7rc9, package: Open MPI marco@MARCOATZERI Distribution, ident: 1.7rc9, Mar 28, 2013, 96) and gdb freezes. Marco Exception: STATUS_ACCESS_VIOLATION at rip=00488F23380 rax= rbx=0004 rcx=00018022C984 rdx= rsi=000600012270 rdi=000488F6C060 r8 =0001801C9DA0 r9 =000488F7E000 r10=000588F6C05F r11=000488F23367 r12= r13=0001 r14= r15=0006 rbp=0022A630 rsp=0022A610 program=E:\cygwin64\bin\orterun.exe, pid 5260, thread main cs=0033 ds=002B es=002B fs=0053 gs=002B ss=002B Stack trace: FrameFunctionArgs 022A630 00488F23380 (004CCD4, 0060008C820, 00600082970, 022CCF0) 00600012500 00488F1C48C (000, 022AB10, 00180134344, 000) 022A900 0010040234B (022AB10, 000, 000, 022AB80) 022AAC0 001004010F3 (022AB10, 000, 030, 3000100FF00) 022AB80 001800478A7 (000, 000, 000, 000) 000 0018004576B (000, 000, 000, 000) 000 0018004592F (000, 000, 000, 000) 000 00100407CB1 (000, 000, 000, 000) 000 00100401010 (000, 000, 000, 000) 000 0007710652D (000, 000, 000, 00077189300) 000 0007733C521 (000, 000, 000, 00077189300) End of stack trace
Re: [64bit RFU] libgii 1.0.2-3, libggi 2.2.2-3, libggimisc 2.2.2-3 and libggiwmh 0.3.2-3
On 4/2/2013 10:20 PM, Peter Rosin wrote:
gii=1.0.2-3
ggi=2.2.2-3
misc=2.2.2-3
wmh=0.3.2-3
echo "
libgii1/libgii1-${gii}-src.tar.bz2
libgii1/libgii1-${gii}.tar.bz2
libgii1/setup.hint
libgii1/libgii1-devel/libgii1-devel-${gii}.tar.bz2
libgii1/libgii1-devel/setup.hint
libgii1/libgii1-input-x/libgii1-input-x-${gii}.tar.bz2
libgii1/libgii1-input-x/setup.hint
libgii1/libgii1-debuginfo/libgii1-debuginfo-${gii}.tar.bz2
libgii1/libgii1-debuginfo/setup.hint
libggi2/libggi2-${ggi}-src.tar.bz2
libggi2/libggi2-${ggi}.tar.bz2
libggi2/setup.hint
libggi2/libggi2-devel/libggi2-devel-${ggi}.tar.bz2
libggi2/libggi2-devel/setup.hint
libggi2/libggi2-display-aa/libggi2-display-aa-${ggi}.tar.bz2
libggi2/libggi2-display-aa/setup.hint
libggi2/libggi2-display-file/libggi2-display-file-${ggi}.tar.bz2
libggi2/libggi2-display-file/setup.hint
libggi2/libggi2-display-terminfo/libggi2-display-terminfo-${ggi}.tar.bz2
libggi2/libggi2-display-terminfo/setup.hint
libggi2/libggi2-display-x/libggi2-display-x-${ggi}.tar.bz2
libggi2/libggi2-display-x/setup.hint
libggi2/libggi2-samples/libggi2-samples-${ggi}.tar.bz2
libggi2/libggi2-samples/setup.hint
libggi2/libggi2-debuginfo/libggi2-debuginfo-${ggi}.tar.bz2
libggi2/libggi2-debuginfo/setup.hint
libggimisc2/libggimisc2-${misc}-src.tar.bz2
libggimisc2/libggimisc2-${misc}.tar.bz2
libggimisc2/setup.hint
libggimisc2/libggimisc2-devel/libggimisc2-devel-${misc}.tar.bz2
libggimisc2/libggimisc2-devel/setup.hint
libggimisc2/libggimisc2-samples/libggimisc2-samples-${misc}.tar.bz2
libggimisc2/libggimisc2-samples/setup.hint
libggimisc2/libggimisc2-debuginfo/libggimisc2-debuginfo-${misc}.tar.bz2
libggimisc2/libggimisc2-debuginfo/setup.hint
libggiwmh0/libggiwmh0-${wmh}-src.tar.bz2
libggiwmh0/libggiwmh0-${wmh}.tar.bz2
libggiwmh0/setup.hint
libggiwmh0/libggiwmh0-devel/libggiwmh0-devel-${wmh}.tar.bz2
libggiwmh0/libggiwmh0-devel/setup.hint
libggiwmh0/libggiwmh0-display-x/libggiwmh0-display-x-${wmh}.tar.bz2
libggiwmh0/libggiwmh0-display-x/setup.hint
libggiwmh0/libggiwmh0-samples/libggiwmh0-samples-${wmh}.tar.bz2
libggiwmh0/libggiwmh0-samples/setup.hint
libggiwmh0/libggiwmh0-debuginfo/libggiwmh0-debuginfo-${wmh}.tar.bz2
libggiwmh0/libggiwmh0-debuginfo/setup.hint
" | \
wget --no-verbose --force-directories --no-host-directories --cut-dirs=2 \
--basehttp://www.lysator.liu.se/~peda/cygwin/64bit --input-file=-
done.
I put all in a libggi main directory like 32bit one
Regards
Marco
Re: [64bit RFU] libgii 1.0.2-3, libggi 2.2.2-3, libggimisc 2.2.2-3 and libggiwmh 0.3.2-3
On 4/3/2013 9:10 AM, Peter Rosin wrote: On 2013-04-02 22:50, marco atzeri wrote: On 4/2/2013 10:20 PM, Peter Rosin wrote: gii=1.0.2-3 ggi=2.2.2-3 misc=2.2.2-3 wmh=0.3.2-3 done. I put all in a libggi main directory like 32bit one Thanks, but the packages do not show up in setup (the files are there, but setup64.ini is incomplete). Did you remember to run GEN-sware? Or is some extra tweak needed when an extra directory level is added? Cheers, Peter forgot. I just run it now Marco
Re: [64bit RFU] yasm-1.2.0-1
On 4/3/2013 11:35 AM, David Stacey wrote:
BASEURL=http://dl.dropbox.com/sh/7y1yn4whbyho9a7
wget --no-host-directories --force-directories --cut-dirs=5 \
${BASEURL}/a5VUX01nIC/64bit/release/yasm/setup.hint \
${BASEURL}/1Dgzi6G73k/64bit/release/yasm/yasm-1.2.0-1-src.tar.bz2 \
${BASEURL}/OUqYxaIg4g/64bit/release/yasm/yasm-1.2.0-1.tar.bz2 \
${BASEURL}/QSBMHWgylC/64bit/release/yasm/yasm-devel/setup.hint \
${BASEURL}/fUyAhZItiq/64bit/release/yasm/yasm-devel/yasm-devel-1.2.0-1.tar.bz2
\
${BASEURL}/FOziI2vuE1/64bit/release/yasm/yasm-debuginfo/setup.hint \
${BASEURL}/g6fefVrrJR/64bit/release/yasm/yasm-debuginfo/yasm-debuginfo-1.2.0-1.tar.bz2
This is the yasm assembler, rebuilt for 64-bit.
All built-in tests pass.
Cheers,
Dave.
uploaded
Marco
Re: 64bit: segfault on program exit
On 4/2/2013 10:59 AM, Corinna Vinschen wrote: Hi Marco, On Apr 1 17:11, marco atzeri wrote: I am building and testing openmpi-1.7.0rc9 on CYGWIN_NT-6.1 1.7.18(0.263/5/3) 2013-03-28 22:07 x86_64 Cygwin every looks fine except when all the processes on several cores end and should return to lunching program, something go wrong (of course on 32bit everyhing is OK) Attached stackdump. Not all 64 bit issues are Cygwin's fault. It's not clear in your case, but it is pretty clear that this happens in a DLL other than the Cygwin DLL. Look at the stack trace: Stack trace: FrameFunctionArgs 022A630 00488F23380 (004CCD4, 0060008C820, 00600082970, 022CCF0) 00600012500 00488F1C48C (000, 022AB10, 00180134344, 000) 022A900 0010040234B (022AB10, 000, 000, 022AB80) 022AAC0 001004010F3 (022AB10, 000, 030, 3000100FF00) 022AB80 001800478A7 (000, 000, 000, 000) 000 0018004576B (000, 000, 000, 000) 000 0018004592F (000, 000, 000, 000) 000 00100407CB1 (000, 000, 000, 000) 000 00100401010 (000, 000, 000, 000) 000 0007710652D (000, 000, 000, 00077189300) 000 0007733C521 (000, 000, 000, 00077189300) End of stack trace The function addresses starting with 0x4 are distro DLLs. So the crash occurs in a DLL at address 0x4:88F23380. The easiest way to find out which DLL is the culprit, is this: Call `rebase -i /bin/*.dll' and see which DLL covers the 0x4:88Fx addresses. it is one of the openmpi dll. The next addresses on the stack are applicaton addresses (0x1:0xxx) The Cygwin DLL itself only shows up in the 6th frame (0x1:8xxx). This is apparently the DLL entry point which ultimately calls the application's main function. unfortunately GDB freezes before hitting breakpoints in code portion where the segfault is supposed to be. So something is fishy and GDB seems unable to catch it Did you see my mail describing the memory layout on the cygwin-developers list? This is a bit helpful I hope: http://cygwin.com/ml/cygwin-developers/2013-02/msg00027.html Corinna Thanks Marco
Re: [64bit RFU] doxygen-1.8.3.1-2
On 4/4/2013 9:46 PM, David Stacey wrote:
BASEURL=http://dl.dropbox.com/sh/7y1yn4whbyho9a7
wget --no-host-directories --force-directories --cut-dirs=5 \
${BASEURL}/GaHtPI0wwe/64bit/release/doxygen/doxygen-1.8.3.1-2-src.tar.bz2 \
${BASEURL}/dnd_KE3crB/64bit/release/doxygen/doxygen-1.8.3.1-2.tar.bz2 \
${BASEURL}/07f8FokqQW/64bit/release/doxygen/setup.hint
This is a very minimalistic build of doxygen 1.8.3.1, compiled for
64-bit. Please note the following:
* There is no TeX support in Cygwin64 at the moment, so you will need to
specify 'GENERATE_LATEX = NO' in your doxygen configuration file. For
the same reason, there is no PDF version of the manual in this build.
* There is no Qt4 support in Cygwin64 at the moment, so this build is
provided without the doxywizard sub-package.
* Compiling with --ggdb produces a compilation error (too many sections)
which I will investigate if I get time. The upshot of this is that there
is no debuginfo package for this build.
* This build replaces doxygen-1.8.3.1-1, which was built for win32-g++
and would not compile under Cygwin64 as it relied on a TeX installation.
I will re-build doxygen when 64-bit versions of Qt4 / texlive-collection
become available.
Cheers,
Dave.
uploaded
Marco
Re: 64bit: segfault on program exit
On 4/3/2013 4:22 PM, Corinna Vinschen wrote: On Apr 3 15:30, marco atzeri wrote: On 4/2/2013 10:59 AM, Corinna Vinschen wrote: The crash occurs in a forked process, I guess. Since you're building the stuff yourself, maybe you can try some serious `printf' based debugging? very curious, this test if (n == -1) does not work as "n" is ssize_t = long while if (n + 1) is fine Corinna Marco
Re: 64bit: segfault on program exit
On 4/6/2013 11:10 PM, Corinna Vinschen wrote: On Apr 6 21:44, marco atzeri wrote: On 4/3/2013 4:22 PM, Corinna Vinschen wrote: On Apr 3 15:30, marco atzeri wrote: On 4/2/2013 10:59 AM, Corinna Vinschen wrote: The crash occurs in a forked process, I guess. Since you're building the stuff yourself, maybe you can try some serious `printf' based debugging? very curious, this test if (n == -1) does not work as "n" is ssize_t = long I don't understand what you mean. I tried this: #include #include $ cat > x.c < ignore. debugging when sleeping is not effective :-( Marco
Re: [64bit RFU] emacs-24.3-3
On 4/6/2013 11:27 PM, Corinna Vinschen wrote: Unfortunately I can't upload. The 64bit/release/emacs dir has only write permissions for Andy Koppe. The same goes for yasm and libggi, which are 755 for Marco Atzeri only. This is weird, the release parent dir has 2775 permissions and the subdirs should have the same permissions. Andy, Marco, can you please chmod -R g+w the aforementioned directories ASAP? Thank you. Done Marco
Re: 64bit: segfault : recv return type ?
On 4/7/2013 9:06 AM, marco atzeri wrote:
On 4/6/2013 11:10 PM, Corinna Vinschen wrote:
What is the original code doing?
Corinna
I think the problem in on recv definition.
my code is (with all added printf) :
static void
evsig_cb(evutil_socket_t fd, short what, void *arg)
{
static char signals[1024];
ev_ssize_t n;
int i;
int ncaught[NSIG];
struct event_base *base;
base = arg;
memset(&ncaught, 0, sizeof(ncaught));
while (1) {
n = recv(fd, signals, sizeof(signals), 0);
printf("recv %li \n",n);
fflush(stdout);
if (n == -1) {
printf("n==-1 %li \n",n);
fflush(stdout);
int err = evutil_socket_geterror(fd);
printf("err %i \n",err);
fflush(stdout);
if (! EVUTIL_ERR_RW_RETRIABLE(err))
event_sock_err(1, fd, "%s: recv",
__func__);
printf("func %s \n",__func__);
fflush(stdout);
break;
} else if (n==0) {
/* XXX warn? */
break;
} else {
printf("before for n %li \n",n);
fflush(stdout);
for (i = 0; i < n; ++i) {
ev_uint8_t sig = signals[i];
if (sig < NSIG)
ncaught[sig]++;
}
}
}
-
and the relevant output is
recv 2
before for n 2
recv 4294967295
before for n 4294967295
[MARCOATZERI:03904] *** Process received signal ***
[MARCOATZERI:03904] Signal: Segmentation fault (11)
-
so recv is returning 2^32-1 instead of the expected -1
on winsup/cygwin/net.cc is defined as function returning int
---
/* exported as recv: standards? */
extern "C" int
cygwin_recv (int fd, void *buf, size_t len, int flags)
{
int res;
fhandler_socket *fh = get (fd);
myfault efault;
if (efault.faulted (EFAULT) || !fh)
res = -1;
---
while on sys/socket.h
ssize_t recv (int, void *__buff, size_t __len, int __flags);
on POSIX
http://pubs.opengroup.org/onlinepubs/009695399/functions/recv.html
(and also
newlib/libc/sys/linux/net/recv.c return ssize_t)
while:
sizeof(int) = 4
sizeof(ssize_t) = 8
Regards
Marco
Re: [RFU] task-2.2.0-1
On 4/8/2013 12:13 AM, Federico Hernandez wrote: Please upload. --- wget -x -nH --cut-dirs=3 \ http://taskwarrior.org/download/cygwin17/task/setup.hint \ http://taskwarrior.org/download/cygwin17/task/task-2.2.0-1.tar.bz2 \ http://taskwarrior.org/download/cygwin17/task/task-2.2.0-1-src.tar.bz2 done PS: The version(s) prior to 2.1.2 can be deleted. done Regards Marco
Re: 64bit: segfault : recv return type ?
On 4/8/2013 12:04 PM, Corinna Vinschen wrote: You're oh so right. Thanks for tracking this down. I'll fix that asap. Should be fixed in CVS. I'll create a new 64 bit Cygwin DLL later today. Corinna it works fine, thanks Marco
Re: 64 bit: "noarch" packages and going beta
On 4/10/2013 3:16 PM, Corinna Vinschen wrote: Greetings venerable maintainers, - Those of you testing the 64 bit Cygwin: How do you judge the stability of the 64 bit Cygwin DLL? Is it still rather pre-beta, or are we in a stage where we can offically open up the test distro to a wider audience? 64bit looks solid enough, the recv mismatch was the only real problem I had in porting packages. Wider audience is needed to test more corner cases Thanks for your input, Corinna Regards Marco
Re: [RFU 32 + 64bit] fltk
On 4/14/2013 11:09 PM, A.R. Burgers wrote: LS, packages for fltk-1.3 are available here for upload: 64 bit: wget -nH -r -L -R 'index.html*' --cut-dirs=3 http://members.quicknet.nl/ar.burgers/cygwin/64bit/fltk/ does not work in this way. Next time : wget -nH -np -r --cut-dirs=2 http://members.quicknet.nl/ar.burgers/cygwin/64bit/fltk/ find 64bit -name "index.html*" |xargs rm 32 bit: wget -nH -r -L -R 'index.html*' --cut-dirs=3 http://members.quicknet.nl/ar.burgers/cygwin/fltk/ wget -nH -np -r --cut-dirs=2 http://members.quicknet.nl/ar.burgers/cygwin/fltk/ find fltk -name "index.html*" |xargs rm for 32 bit please leave 1.3.1.9285 as previous should I remove 1.1.8r5648-1 and 1.1.10 ? kind regards, Teun Regards Marco
Re: [RFU 32 + 64bit] fltk
On 4/15/2013 10:01 AM, marco atzeri wrote: On 4/14/2013 11:09 PM, A.R. Burgers wrote: LS, for 32 bit please leave 1.3.1.9285 as previous should I remove 1.1.8r5648-1 and 1.1.10 ? as they are needed for libfltk1.1 , it is better to not remove. Regards Marco
Re: [RFU 32 + 64bit] fltk-1.3.1.9857-2
On 4/15/2013 8:40 PM, a.rburg...@quicknet.nl wrote: corrina wrote: Marco uploaded the packages, but there was a small problem. The "required:" lines of libfltk-devel/setup.hint and libfltk1.3/setup.hint were broken up in multiple lines. I fixed that on cygwin.com, but maybe you should check locally. Did cygport add the line breaks for some reason? I switched from manual setup.hints to cygport autobuilded setup.hint. I had embedded newlines in the values of the _REQUIRES variables, which apparently is not allowed. new packages for fltk-1.3 fixing this are available here for upload: do we need to upload a new version just for setup.hint ? I guess Corinna already solved it. 64 bit: wget -nH -r -L -R 'index.html*' --cut-dirs=3 http://members.quicknet.nl/ar.burgers/cygwin/64bit/fltk/ 32 bit: wget -nH -r -L -R 'index.html*' --cut-dirs=2 http://members.quicknet.nl/ar.burgers/cygwin/fltk/ Marco had an issue with the wget command. In reality it is sourceware.org that does not like it in this way I suspect it is due to the : -R 'index.html*' as index.html is the first file downloaded and than immediately rejected, nothing else if further downloaded. I think there was an error in the cut-dirs level in one of the wget commands. I double checked, the wgets work fine for me, I hope they work for you too. different system , different result. kind regards, Teun Regards Marco
Re: [HEADSUP] Please try to build your packages for 64 bit
On 4/19/2013 12:45 PM, Corinna Vinschen wrote: Hi maintainers, Right now, we have a couple of missing dependencies in the 64 bit distro. If one of the packages is yours, it would be nice if you could try to build it. Here's the list of missing deps as of today: for ImageMagick still missing: libautotrace3 libfpx1 libgs9 libpango1.0_0 librsvg2_2 Corinna Regards Marco
Re: libqhull-devel
On 4/20/2013 8:42 PM, Achim Gratz wrote: Hi Marco, the includes are in /usr/include/libqhull on Cygwin, but all software using it I've found so far expects to find them in /usr/include/qhull instead. I've simply dropped a link on my system, but could you explain why you've chosen libqhull? Hi Achim, upstream decision not mine on latest versions; for that reason on octave the qhull check is like this: OCTAVE_CHECK_LIB(qhull, QHull, [Qhull library not found -- this will result in loss of functionality of some geometry functions.], [libqhull/libqhull.h qhull/libqhull.h libqhull.h qhull/qhull.h qhull.h], [qh_qhull], [], [], [warn_qhull= as you can see they changed the include 3 times from qhull/qhull.h -> qhull/libqhull.h -> libqhull/libqhull.h Regards Achim. Bye Marco
Re: [HEADSUP] Please try to build your packages for 64 bit
On 4/20/2013 8:29 PM, Corinna Vinschen wrote: Hi Marco, On Apr 20 10:43, marco atzeri wrote: On 4/19/2013 12:45 PM, Corinna Vinschen wrote: Hi maintainers, Right now, we have a couple of missing dependencies in the 64 bit distro. If one of the packages is yours, it would be nice if you could try to build it. Here's the list of missing deps as of today: for ImageMagick still missing: libautotrace3 libfpx1 libgs9 libpango1.0_0 librsvg2_2 did you try to build anything of them yourself? no. I had no much time on last weeks Thx, Corinna
Re: [RFU 64bit] gmp / mpfr / mpc / ppl / isl / cloog-ppl / cloog
On 4/21/2013 8:12 PM, Achim Gratz wrote:
After some false starts trying to get things play well together, I've
done extensive changes to the packaging so it becomes more coherent, to
me anyway. I hope this makes the maintenance a bit easier in the long
run, but if anybody has any questions about this, please ask.
Therefore I would like to ask that the existing directories simply be
removed before these are uploaded:
gmp mpfr libmpc ppl isl cloog-{ppl,isl}
For Cygwin32 we'll have to do the obsolescence dance some day, but I
hope for 64bit it is OK to ask everyone to just delete the obsoleted
packages by hand this time. If not, let me know and I'll need to figure
it out for 64bit as well.
Also, in nettle/libnettle-devel/setup.hint, the dependency on
libgmp-devel needs to be changed to gmp-devel so that setup.exe doesn't
try to pull in a non-existent package.
Please unpack the tar file (45MiB) from the 64bit directory to populate
the release directories.
# The first line sets up shell variable wget, to be used by all later lines
# simply paste into the shell from here (assumes you are in .../release).
--8<---cut here---start->8---
wget="wget -rxnH --cut-dirs=1 http://cygwin.stromeko.net/64bit";
$wget/64bit_packages.tar.xz
--8<---cut here---end--->8---
Regards,
Achim.
Yaakov,
most of these dir have file with no write permission for group,
so I can not update the setup.hint files.
-bash-4.1$ ls -l gmp
total 4392
-rw-r--r--. 1 yselkowitz cygwin 2225839 Mar 7 13:17 gmp-5.1.1-1-src.tar.bz2
-rw-r--r--. 1 matzericygwin 2228732 Apr 21 19:25 gmp-5.1.1-2-src.tar.bz2
-rw-r--r--. 1 matzericygwin1924 Apr 21 19:25 gmp-5.1.1-2.tar.bz2
drwxrwsr-x. 2 yselkowitz cygwin4096 Apr 21 19:25 gmp-debuginfo
drwxr-sr-x. 2 matzericygwin4096 Apr 21 19:25 gmp-devel
drwxr-sr-x. 2 matzericygwin4096 Apr 21 19:25 gmp-doc
drwxrwsr-x. 2 yselkowitz cygwin4096 Apr 21 19:25 libgmp10
drwxrwsr-x. 2 yselkowitz cygwin4096 Mar 13 03:01 libgmp-devel
drwxrwsr-x. 2 yselkowitz cygwin4096 Apr 21 19:25 libgmpxx4
-rw-r--r--. 1 root root 103 Mar 13 07:34 md5.sum
-rw-r--r--. 1 yselkowitz cygwin 417 Mar 7 13:17 setup.hint
there is also a mismatch gmp-devel and libgmp-devel, how we solve ?
Similar for the some of the other packages
I aborted the upload, and cleaned as much as possible
Achim's files are on
/sourceware/snapshot-tmp/cygwin/release/release/
-bash-4.1$ ls
cloog cloog-ppl gmp isl mpc mpfr ppl
Regards
Marco
Re: [HEADSUP] Please try to build your packages for 64 bit
On 4/23/2013 10:37 AM, Corinna Vinschen wrote: I still think it would make sense to name the packages according to their architecture in future: foo-1.0-1.i686.tar.bz2 bar-2.3-4.x86_64.tar.bz baz-5.0-8.noarch.tar.bz2 no objection We should also find a simply mechanism to share the noarch packages between the i686 and x86_64 release area, either by adding a noarch dir or by automatic copying or linking the files (or parent dirs) between the i686 and x86_64 release areas. this will require syncronization between the two versions and it is unlikely to happen anytime soon Corinna Marco
64bit: invalid ltdl library
any idea ? configure:21346: checking for lt_dladvise_preload in -lltdl configure:21371: gcc -std=gnu99 -std=gnu99 -o conftest.exe -fopenmp -ggdb -O2 -pipe -fdebug-prefix-map=/pub/devel/imagemagick/ImageMagick-6.7.6.3-3/build=/usr/src/debug/ImageMagick-6.7.6.3-3 -fdebug-prefix-map=/pub/devel/imagemagick/ImageMagick-6.7.6.3-3/src/ImageMagick-6.7.6-3=/usr/src/debug/ImageMagick-6.7.6.3-3 -Wallconftest.c -lltdl>&5 configure:21371: $? = 0 configure:21380: result: yes configure:21427: error: invalid ltdl library directory: `/usr/lib' $ ls -l /usr/lib/*ltd* -rw-r--r-- 1 marco None 199770 Mar 31 07:14 /usr/lib/libltdl.a -rwxr-xr-x 1 marco None 41902 Mar 31 07:14 /usr/lib/libltdl.dll.a $ file /usr/lib/libltdl.dll.a /usr/lib/libltdl.dll.a: current ar archive Regards Marco
Re: 64bit: invalid ltdl library
On 4/26/2013 12:16 AM, Peter Rosin wrote: On 2013-04-25 23:35, Peter Rosin wrote: On 2013-04-25 22:07, marco atzeri wrote: any idea ? configure:21346: checking for lt_dladvise_preload in -lltdl configure:21371: gcc -std=gnu99 -std=gnu99 -o conftest.exe -fopenmp -ggdb -O2 -pipe -fdebug-prefix-map=/pub/devel/imagemagick/ImageMagick-6.7.6.3-3/build=/usr/src/debug/ImageMagick-6.7.6.3-3 -fdebug-prefix-map=/pub/devel/imagemagick/ImageMagick-6.7.6.3-3/src/ImageMagick-6.7.6-3=/usr/src/debug/ImageMagick-6.7.6.3-3 -Wallconftest.c -lltdl>&5 configure:21371: $? = 0 configure:21380: result: yes configure:21427: error: invalid ltdl library directory: `/usr/lib' $ ls -l /usr/lib/*ltd* -rw-r--r-- 1 marco None 199770 Mar 31 07:14 /usr/lib/libltdl.a -rwxr-xr-x 1 marco None 41902 Mar 31 07:14 /usr/lib/libltdl.dll.a $ file /usr/lib/libltdl.dll.a /usr/lib/libltdl.dll.a: current ar archive Regards Marco My guess is that cygport has been a bit too aggressive w/o the libtool maintainer (or whoever build the 64-bit libtool package) noticing and s/build/built/ that /usr/lib/libltdl.la has been inadvertently stripped out of the libtool package. You can probably workaround that by copying the libltdl.la file from a 32-bit install. They are probably exactly equal. it seems to work Cheers, Peter
[64 bit] intltool ?
Yaakov, could you port intltool to 64 bit ? I need it to configure ccrypt-1.10-1 Regards Marco
[64bit] autoconf test for GetConsoleScreenBufferInfo
the attached test extracted by configure of hdf5 is failing on 32 bit as expected with /tmp/cc5L84Vo.o: In function `main': /cygdrive/e/cygwin64/tmp/conftest.c:140: undefined reference to `_GetConsoleScreenBufferInfo' collect2: ld returned 1 exit status but it is passing on 64 bit ls -sh conftest.exe 64K conftest.exe so I guess there is some weird include pulling w32api as the definition is only on the w32api $ grep -rH GetConsoleScreenBufferInfo /usr/include/* /usr/include/w32api/wincon.h: WINBASEAPI WINBOOL WINAPI GetConsoleScreenBufferInfo(HANDLE hConsoleOutput,PCONSOLE_SCREEN_BUFFER_INFO lpConsoleScreenBufferInfo); /usr/include/w32api/wincon.h:WINBASEAPI WINBOOL WINAPI GetConsoleScreenBufferInfoEx( To test just ". config_test.txt" Regards Marco gcc -o conftest.exe -std=c99 -pedantic -Wall -Wextra -Wundef -Wshadow -Wpointer-arith -Wbad-function-cast -Wcast-qual -Wcast-align -Wwrite-strings -Wconversion -Waggregate-return -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wnested-externs -Winline -Wno-long-long -Wfloat-equal -Wmissing-format-attribute -Wmissing-noreturn -Wpacked -Wdisabled-optimization -Wformat=2 -Wendif-labels -Wdeclaration-after-statement -Wold-style-definition -Winvalid-pch -Wvariadic-macros -Wnonnull -Winit-self -Wmissing-include-dirs -Wswitch-default -Wswitch-enum -Wunused-macros -Wunsafe-loop-optimizations -Wc++-compat -Wstrict-overflow -Wlogical-op -Wlarger-than=2048 -Wvla -Wsync-nand -Wframe-larger-than=16384 -Wpacked-bitfield-compat -Wstrict-aliasing -Wstrict-overflow=5 -Wjump-misses-init -Wunsuffixed-float-constants -O3 -fomit-frame-pointer -finline-functions -ggdb -O2 -pipe conftest.c -lpthread -lz -lm /* confdefs.h */ #define PACKAGE_NAME "HDF5" #define PACKAGE_TARNAME "hdf5" #define PACKAGE_VERSION "1.8.10" #define PACKAGE_STRING "HDF5 1.8.10" #define PACKAGE_BUGREPORT "h...@hdfgroup.org" #define PACKAGE_URL "" #define PACKAGE "hdf5" #define VERSION "1.8.10" #define CXX_HAVE_OFFSETOF 1 #define CYGWIN_ULLONG_TO_LDOUBLE_ROUND_PROBLEM 1 #define STDC_HEADERS 1 #define HAVE_SYS_TYPES_H 1 #define HAVE_SYS_STAT_H 1 #define HAVE_STDLIB_H 1 #define HAVE_STRING_H 1 #define HAVE_MEMORY_H 1 #define HAVE_STRINGS_H 1 #define HAVE_INTTYPES_H 1 #define HAVE_STDINT_H 1 #define HAVE_UNISTD_H 1 #define HAVE_DLFCN_H 1 #define LT_OBJDIR ".libs/" #define HAVE_LIBM 1 #define STDC_HEADERS 1 #define TIME_WITH_SYS_TIME 1 #define HAVE_DIFFTIME 1 #define HAVE_GETTIMEOFDAY 1 #define HAVE_CLOCK_GETTIME 1 #define HAVE_SYS_RESOURCE_H 1 #define HAVE_SYS_TIME_H 1 #define HAVE_UNISTD_H 1 #define HAVE_SYS_IOCTL_H 1 #define HAVE_SYS_STAT_H 1 #define HAVE_SYS_SOCKET_H 1 #define HAVE_SYS_TYPES_H 1 #define HAVE_STDDEF_H 1 #define HAVE_SETJMP_H 1 #define HAVE_FEATURES_H 1 #define HAVE_STDINT_H 1 #define HAVE_IO_H 1 #define HAVE_SYS_TIMEB_H 1 #define HAVE_FSEEKO 1 #define HAVE_FTELLO 1 #define SIZEOF_CHAR 1 #define SIZEOF_SHORT 2 #define SIZEOF_INT 4 #define SIZEOF_UNSIGNED 4 #define SIZEOF_LONG 4 #define SIZEOF_LONG_LONG 8 #define SIZEOF___INT64 0 #define SIZEOF_FLOAT 4 #define SIZEOF_DOUBLE 8 #define SIZEOF_LONG_DOUBLE 12 #include #include #define SIZEOF_INT8_T 1 #define SIZEOF_UINT8_T 1 #define SIZEOF_INT_LEAST8_T 1 #define SIZEOF_UINT_LEAST8_T 1 #define SIZEOF_INT_FAST8_T 1 #define SIZEOF_UINT_FAST8_T 1 #define SIZEOF_INT16_T 2 #define SIZEOF_UINT16_T 2 #define SIZEOF_INT_LEAST16_T 2 #define SIZEOF_UINT_LEAST16_T 2 #define SIZEOF_INT_FAST16_T 4 #define SIZEOF_UINT_FAST16_T 4 #define SIZEOF_INT32_T 4 #define SIZEOF_UINT32_T 4 #define SIZEOF_INT_LEAST32_T 4 #define SIZEOF_UINT_LEAST32_T 4 #define SIZEOF_INT_FAST32_T 4 #define SIZEOF_UINT_FAST32_T 4 #define SIZEOF_INT64_T 8 #define SIZEOF_UINT64_T 8 #define SIZEOF_INT_LEAST64_T 8 #define SIZEOF_UINT_LEAST64_T 8 #define SIZEOF_INT_FAST64_T 8 #define SIZEOF_UINT_FAST64_T 8 #define SIZEOF_SIZE_T 4 #define SIZEOF_SSIZE_T 4 #define SIZEOF_PTRDIFF_T 4 #include /*for off_t definition*/ #define SIZEOF_OFF_T 8 #define SIZEOF_OFF64_T 0 #define DEV_T_IS_SCALAR 1 #define HAVE_ZLIB_H 1 #define HAVE_LIBZ 1 #define HAVE_FILTER_DEFLATE 1 #define HAVE_PTHREAD_H 1 #define HAVE_LIBPTHREAD 1 #define HAVE_DECL_TZNAME 0 #define HAVE_STRUCT_TIMEZONE 1 #define GETTIMEOFDAY_GIVES_TZ 1 #define HAVE_STAT_ST_BLOCKS 1 /* end confdefs.h. */ /* Define GetConsoleScreenBufferInfo to an innocuous variant, in case declares GetConsoleScreenBufferInfo. For example, HP-UX 11i declares gettimeofday. */ #define GetConsoleScreenBufferInfo innocuous_GetConsoleScreenBufferInfo /* System header to define __stub macros and hopefully few prototypes, which can conflict with char GetConsoleScreenBufferInfo (); below. Prefer to if __STDC__ is defined, since exists even on freestanding compilers. */ #ifdef __STDC__ # include #else # include #endif #undef GetConsoleScreenBufferInfo /* Override any GCC internal prototype to avoid an error. Use char because int might match the return type of a GCC builtin and
Re: [64bit] autoconf test for GetConsoleScreenBufferInfo
Il 5/14/2013 9:05 PM, Corinna Vinschen ha scritto: On May 14 20:30, marco atzeri wrote: I fear you might not like my answer: The problem here is NOT that the linking works, the problem is that, if the configure test is used to find out if we're running on Windows or not, it's simply not feasible anymore when taking x86_64 Cygwin into account. This has to be solved differently, for instance by not performing this test if configure already knows the target is Cygwin. not a big problem in this case I can split the check and add a conditional tests from AC_CHECK_FUNCS([_getvideoconfig gettextinfo GetConsoleScreenBufferInfo]) to AC_CHECK_FUNCS([_getvideoconfig gettextinfo ]) case $host_os in CYGWIN*) ;; *) AC_CHECK_FUNCS([GetConsoleScreenBufferInfo]) ;; esac the problem is to identify such issue on other softwares. Corinna Thanks Marco
sourceware.org temp upload dir
any reason why /sourceware/snapshot-tmp/cygwin/release has been removed ? -bash-4.1$ cd /sourceware/snapshot-tmp/cygwin -bash-4.1$ ls -l total 2184 drwxrwsr-x. 4 cgf cgf 4096 May 14 2012 cvs-mirror -rw-rw-r--. 1 cgf cygwin 774 Mar 19 14:52 Makefile drwxrwxr-x. 2 root cygwin4096 Jun 10 2009 RCS -rwxr-xr-x. 1 cgf cygwin 2220573 Apr 29 2012 setup.exe -bash-4.1$ Regards Marco
Re: sourceware.org temp upload dir
Il 5/22/2013 6:52 PM, Corinna Vinschen ha scritto: On May 22 12:38, Christopher Faylor wrote: On Wed, May 22, 2013 at 06:05:29PM +0200, marco atzeri wrote: any reason why /sourceware/snapshot-tmp/cygwin/release has been removed ? Are you asking because you use the get-cygwin-package script or because you were using it for your own personal uploads? If it is the former then that's a problem, I guess (I didn't think anyone was using the script since it wasn't foolproof). It is is the latter then you shouldn't have been using that area to begin with. It wasn't created for general use. Uhm... am I the only one here who thought this is *the* general upload directory for Cygwin packages? Since that's apparently not right, what *is* the general upload directory for Cygwin packages? Corinna I had the same impression. I was using it for temporary storage during upload phase before moving to release areas (32 and 64 ) Marco
Re: Global 32/64 bit collision issues
Il 5/23/2013 10:44 AM, Corinna Vinschen ha scritto: Hi guys, But what about cygserver? Without cygserver there's no XSI IPC. Even if we don't change the service names on a general basis, shouldn't cygserver at least be available in parallel, using different service names? my experience with postgreSQL says that the two services are not interchangeable. 32 bit program fails with 64 cygserver Corinna Marco
[64 bit] relocation truncated to fit: R_X86_64_PC32
trying to build octave I hit: libtool: link: g++ -shared -nostdlib /usr/lib/gcc/x86_64-pc-cygwin/4.8.0/crtbegin.o .libs/liboctinterp.la.lnkscript -L/pub/devel/octave/octave-3.6.4-1/build/libcruft/.libs -L/usr/local/lib ../liboctave/.libs/liboctave.dll.a /pub/devel/octave/octave-3.6.4-1/build/libcruft/.libs/libcruft.dll.a -lcholmod -lumfpack -lamd -lcamd -lcolamd -lccolamd -lcxsparse -larpack -lqrupdate -lfftw3 -lfftw3f -lreadline -lncurses -lpcre ../libcruft/.libs/libcruft.dll.a -llapack -lblas -lgfortran -lquadmath -lhdf5 -lz -lX11 -L/usr/lib/gcc/x86_64-pc-cygwin/4.8.0 -L/usr/lib/gcc/x86_64-pc-cygwin/4.8.0/../../.. /../x86_64-pc-cygwin/lib/../lib -L/usr/lib/gcc/x86_64-pc-cygwin/4.8.0/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-pc-cygwin/4.8.0/../../../../x86_64-pc-cygwin/lib -L/usr/lib/gcc/x86_64-pc-cygwin/4.8.0/../../.. -lstdc++ -lgcc_s -lgcc -lcygwin -ladvapi32 -lshell32 -luser32 -lkernel32 -lgcc_s -lgcc /usr/lib/gcc/x86_64-pc-cygwin/4.8.0/crtend.o -O2 -O2 -O2 -Wl,-no-undefined -o .libs/cygoctinterp-1.dll -Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker .libs/liboctinterp.dll.a mv DLD-FUNCTIONS/PKG_ADD-t DLD-FUNCTIONS/PKG_ADD .libs/liboctinterp_la-ov-int16.o:ov-int16.cc:(.rdata+0x24): relocation truncated to fit: R_X86_64_PC32 against `.text$_ZNK19octave_int16_scalar3mapEN17octave_base_value14unary_mapper_tE' looking at gcc "3.17.16 Intel 386 and AMD x86-64 Options" `-mcmodel=small' Generate code for the small code model: the program and its symbols must be linked in the lower 2 GB of the address space. Pointers are 64 bits. Programs can be statically or dynamically linked. This is the default code model. `-mcmodel=kernel' Generate code for the kernel code model. The kernel runs in the negative 2 GB of the address space. This model has to be used for Linux kernel code. `-mcmodel=medium' Generate code for the medium model: the program is linked in the lower 2 GB of the address space. Small symbols are also placed there. Symbols with sizes larger than `-mlarge-data-threshold' are put into large data or BSS sections and can be located above 2GB. Programs can be statically or dynamically linked. `-mcmodel=large' Generate code for the large model. This model makes no assumptions about addresses and sizes of sections. - should I force the `-mcmodel=large' ? Regards Marco
Re: [RFU] lftp
Il 5/28/2013 12:21 PM, Corinna Vinschen ha scritto: Yaakov, I'm wondering if it isn't time to do two things: - Create a new cygport version which does not create the toplevel files anymore. +1. It is annoying to have 2 times the same files - Create a short documentation how to create the new cygport files. Corinna Marco
Re: [64bit RFU] serf-1.2.0-1
Il 5/29/2013 7:03 AM, David Rothenberger ha scritto: wget -x -nH --cut-dirs=2 \ http://home.comcast.net/~david.rothenberger/cygwin64/serf/libserf1_0/libserf1_0-1.2.0-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin64/serf/libserf1_0/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin64/serf/libserf1-devel/libserf1-devel-1.2.0-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin64/serf/libserf1-devel/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin64/serf/serf-1.2.0-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin64/serf/serf-1.2.0-1-src.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin64/serf/serf-debuginfo/serf-debuginfo-1.2.0-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin64/serf/serf-debuginfo/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin64/serf/setup.hint uploaded
Re: [64bit RFU] cyrus-sasl-2.1.26-1
Il 5/29/2013 6:56 AM, David Rothenberger ha scritto: wget -x -nH --cut-dirs=2 \ http://home.comcast.net/~david.rothenberger/cygwin64/cyrus-sasl/cyrus-sasl-2.1.26-1-src.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin64/cyrus-sasl/cyrus-sasl-2.1.26-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin64/cyrus-sasl/cyrus-sasl-debuginfo/cyrus-sasl-debuginfo-2.1.26-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin64/cyrus-sasl/cyrus-sasl-debuginfo/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin64/cyrus-sasl/libsasl2-devel/libsasl2-devel-2.1.26-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin64/cyrus-sasl/libsasl2-devel/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin64/cyrus-sasl/libsasl2_3/libsasl2_3-2.1.26-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin64/cyrus-sasl/libsasl2_3/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin64/cyrus-sasl/libsasl2_3-sql/libsasl2_3-sql-2.1.26-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin64/cyrus-sasl/libsasl2_3-sql/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin64/cyrus-sasl/setup.hint uploaded
Re: [RFU] serf-1.2.0-1
Il 5/29/2013 7:00 AM, David Rothenberger ha scritto: Please remove 1.1.0-1. 0.7.1-2 must remain for use with subversion-1.6. Thanks! wget -x -nH --cut-dirs=2 \ http://home.comcast.net/~david.rothenberger/cygwin/serf/libserf1_0/libserf1_0-1.2.0-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/serf/libserf1_0/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/serf/libserf1-devel/libserf1-devel-1.2.0-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/serf/libserf1-devel/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/serf/serf-1.2.0-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/serf/serf-1.2.0-1-src.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/serf/serf-debuginfo/serf-debuginfo-1.2.0-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/serf/serf-debuginfo/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/serf/setup.hint done and done
Re: [RFU] cyrus-sasl-2.1.26-1
Il 5/29/2013 6:43 AM, David Rothenberger ha scritto: 2.1.25-1 had an upstream ABI change without an SONAME bump. So, 2.1.26-1 includes the SONAME bump and an libsasl2_3 subpackage that wasn't there in 2.1.25. Because of this ABI change, I ask that you remove 2.1.25-1 and leave 2.1.23-1 as the previous version. Thanks! wget -x -nH --cut-dirs=2 \ http://home.comcast.net/~david.rothenberger/cygwin/cyrus-sasl/cyrus-sasl-2.1.26-1-src.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/cyrus-sasl/cyrus-sasl-2.1.26-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/cyrus-sasl/cyrus-sasl-debuginfo/cyrus-sasl-debuginfo-2.1.26-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/cyrus-sasl/cyrus-sasl-debuginfo/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/cyrus-sasl/libsasl2-devel/libsasl2-devel-2.1.26-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/cyrus-sasl/libsasl2-devel/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/cyrus-sasl/libsasl2_3/libsasl2_3-2.1.26-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/cyrus-sasl/libsasl2_3/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/cyrus-sasl/libsasl2_3-ldap/libsasl2_3-ldap-2.1.26-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/cyrus-sasl/libsasl2_3-ldap/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/cyrus-sasl/libsasl2_3-sql/libsasl2_3-sql-2.1.26-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/cyrus-sasl/libsasl2_3-sql/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/cyrus-sasl/setup.hint done and done
Re: [64 bit] relocation truncated to fit: R_X86_64_PC32
Il 5/27/2013 11:34 AM, Corinna Vinschen ha scritto: On May 26 08:40, marco atzeri wrote: trying to build octave I hit: You can try. The general idea was that this isn't necessary. -mcmodel=medium is default and despite the text you're quoting, the idea was that the base address of the result shouldn't matter on PE/COFF. Unfortunately the linker is making a fuss about that yet and maybe there's still another problem as well. So you have two choices: - Try -mcmodel=large, but there's a good chance it crashes (harfbuzz apparently does). it crashed, but it could be another reason as also the second option failed with 1.7.18-6 - Link with -Wl,--image-base-address -Wl,0x1000 and rebase the DLLs afterwards to some arbitrary address between 0x4: and 0x6:. This should work as expected. this worked. (-Wl,--image-base -Wl,0x1000") with latest 1.7.18-8 not with 1.7.18-6 Corinna Marco
Re: [64 bit] relocation truncated to fit: R_X86_64_PC32
Il 5/29/2013 12:28 PM, Corinna Vinschen ha scritto: Hi Marco, On May 29 12:14, marco atzeri wrote: Il 5/27/2013 11:34 AM, Corinna Vinschen ha scritto: On May 26 08:40, marco atzeri wrote: trying to build octave I hit: You can try. The general idea was that this isn't necessary. -mcmodel=medium is default and despite the text you're quoting, the idea was that the base address of the result shouldn't matter on PE/COFF. Unfortunately the linker is making a fuss about that yet and maybe there's still another problem as well. So you have two choices: - Try -mcmodel=large, but there's a good chance it crashes (harfbuzz apparently does). it crashed, but it could be another reason as also the second option failed with 1.7.18-6 - Link with -Wl,--image-base-address -Wl,0x1000 and rebase the DLLs afterwards to some arbitrary address between 0x4: and 0x6:. This should work as expected. this worked. (-Wl,--image-base -Wl,0x1000") with latest 1.7.18-8 not with 1.7.18-6 Sorry to say that, but this is not overly helpful. For one thing, you mean 1.7.19, not 18, right? How exactly did it work with 1.7.19-8? Only after using --image-base 0x1000 or also after the rebase? 1.7.19. no need to rebase for "make check" What exactly did not work with 1.7.19-6? Building or running? running. it was segfaulting almost on start. Rebase made no difference; same for CFLAGS="-fwrapv" Did you only try with --image-base 0x1000 or also with rebase? To what address did you rebase? If building worked but running didn't, what has gone wrong? Was it a fork problem, perhaps? Any hints from the stackdump? GDB? Did you check for a collision with another DLL? Also, what about 1.7.19-7? The difference between -6, -7, and -8 is exactly one patch per version. It might be interesting to learn about the patch which, apparently, fixed the problem. I missed the 1.7.19-7 during my tests, do you need I test it ? Corinna Marco
Re: [RFU] texlive-20120628-2, etc.
Il 5/29/2013 12:20 AM, Ken Brown ha scritto: On 5/28/2013 5:14 PM, marco atzeri wrote: any chance for a 64bit version of texlive ? I'm working on it. At the moment I can build everything except luatex.exe and xetex.exe. If I can't solve that within the next day or so, I'll go ahead and upload what I have. Ken no urgency. I built and uploaded the package without building the documentation Regards Marco
[64bit] openldap ?
Volker any chance ? it is the only package missing for building a complete postgresql Regards Marco
Re: [64bit] openldap ?
Il 5/29/2013 2:00 PM, Dr. Volker Zell ha scritto: marco atzeri writes: > Volker any chance ? Actually I'm working on it, but right now ldapsearch SEGFAULTS :-( during the test suite. CFLAGS="-fwrapv" helped on slang testsuite, may be it helps also here (dark magic) > it is the only package missing for building a complete > postgresql I know... > Regards > Marco Ciao Volker Ciao Marco
Re: [RFU] libaprutil1-1.5.2-1
Il 5/29/2013 6:39 PM, David Rothenberger ha scritto: David Rothenberger wrote: Please leave 1.4.1-1 as previous and remove 1.3.12-1 and 1.3.9-3. Thanks! wget -x -nH --cut-dirs=2 \ http://home.comcast.net/~david.rothenberger/cygwin/libaprutil1/aprutil1/aprutil1-1.5.2-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/libaprutil1/aprutil1/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/libaprutil1/libaprutil1-1.5.2-1-src.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/libaprutil1/libaprutil1-1.5.2-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/libaprutil1/libaprutil1-devel/libaprutil1-devel-1.5.2-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/libaprutil1/libaprutil1-devel/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/libaprutil1/setup.hint I think this RFU has been overlooked. Could someone please upload it? Thanks. done and done
Re: [64 bit] relocation truncated to fit: R_X86_64_PC32
Il 5/29/2013 2:33 PM, Corinna Vinschen ha scritto: On May 29 12:48, marco atzeri wrote: Il 5/29/2013 12:28 PM, Corinna Vinschen ha scritto: Also, what about 1.7.19-7? The difference between -6, -7, and -8 is exactly one patch per version. It might be interesting to learn about the patch which, apparently, fixed the problem. I missed the 1.7.19-7 during my tests, do you need I test it ? It would be nice. Thanks, Corinna 1.7.19-7 is fine. 1.7.19-6 segfaults. Attached stackdump Stack trace: FrameFunctionArgs 006 0018006F9BB (010, 0229430, 003D8E10BA0, 007) 006 00180070E6A (03F8550, 006, 0E8, 000) 0229420 0018011A168 (000, 03F0230, 00180135D04, 03F1320) 0C1 0018011723E (000, 00600039530, 000, 000) 11284C0 0018011770B (045CC70, 00600221010, 001800434ED, 006) 11284C0 001801178DC (000, 00600221010, 02297F8, 006002AA500) 11284C0 00180117B9F (0459850, 000, 00600221D90, 000) 11284C0 00180146CA6 (0060001, 00600221D90, 041, 003D8E10BA0) 11284C0 001800C0523 (006002AB770, CE330C0, 006002AB770, 006002B1810) 11284C0 00180113350 (CE330C0, 006002AB770, 006002B1810, 0229B98) 11284C0 00077492664 (006002118C8, 054DFBD, 006001D7A48, 0060024D050) 11284C0 006002118C8 (054DFBD, 006001D7A48, 0060024D050, 006002118A8) 11284C0 0060024D020 (006001D7A48, 0060024D050, 006002118A8, 006002118C8) 11284C0 006002118C8 (0060024D050, 006002118A8, 006002118C8, 00600222310) 11284C0 054DFBD (00010086CA1, 006002118C8, 006002399B0, 1128460) 11284C0 000100867AA (001800C0523, 006002AB3F0, 001, 001) End of stack trace (more stack frames may be present)
Re: [RFU] subversion-1.7.9-2
Il 5/29/2013 8:57 PM, David Rothenberger ha scritto: Please upload subversion-1.7.9-2 as the new current release. Please delete 1.7.9-1 and leave 1.6.17-1 as prev. done and done
Re: [ITP] docbook2X
Il 5/30/2013 9:21 AM, Yaakov (Cygwin/X) ha scritto: docbook2X converts DocBook documents into the man page format and the GNU Texinfo format. It is used during 'make info' in the git package, among others. The upstream commands are ordinarily docbook2man and docbook2texi, but those names collide with the more commonly used docbook-utils. Various distros rename these commands in different ways; I chose the name used by git; other aliases may be added in the future if needed. Packages: ftp://ftp.cygwinports.org/pub/cygwinports/uploads/docbook2X/ Package sources: http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/docbook2X Yaakov builds and packages fine (of course) GTG Marco
Re: [64bit RFU] texlive-20130529-1, etc.
Il 6/1/2013 12:57 PM, Ken Brown ha scritto:
This is expected to be the TeX Live 2013 release. The build contains
everything except xindy and biber. Building biber (or getting the biber
developer to do it for me) is a separate project that may take a while.
D=http://sanibeltranquility.com/cygwin/64bit/release/TeX
TL=texlive
TC=texlive-collection
wget -x -nH --cut-dirs=3 \
${D}/${TC}-basic/${TC}-basic-20130529-1.tar.bz2\
${D}/${TC}-basic/${TC}-basic-20130529-1-src.tar.bz2\
[cut]
Ken,
Is the system a bit slow ?
at 4 K/s it will take long time ...
Regards
Marco
Re: [64bit RFU] texlive-20130529-1, etc.
Il 6/1/2013 3:57 PM, Ken Brown ha scritto:
On 6/1/2013 9:14 AM, marco atzeri wrote:
Il 6/1/2013 12:57 PM, Ken Brown ha scritto:
This is expected to be the TeX Live 2013 release. The build contains
everything except xindy and biber. Building biber (or getting the
biber developer to do it for me) is a separate project that may take a
while.
D=http://sanibeltranquility.com/cygwin/64bit/release/TeX
TL=texlive
TC=texlive-collection
wget -x -nH --cut-dirs=3 \
${D}/${TC}-basic/${TC}-basic-20130529-1.tar.bz2\
${D}/${TC}-basic/${TC}-basic-20130529-1-src.tar.bz2\
[cut]
Ken,
Is the system a bit slow ?
at 4 K/s it will take long time ...
It seems to be slow right now, but normally it's fine. I tested the
wget command a couple of hours ago, and it didn't take long to complete.
I would suggest waiting a little while and trying again.
Ken
it tooks just "202 files, 3.3G in 1h 37m 13s"
you have just doubled the 64bit relese size ;-)
-bash-4.1$ du -hs release
6.9Grelease
-bash-4.1$ du -hs release/TeX/
3.3Grelease/TeX/
Regards
Marco
Re: [RFU] libogg-1.3.1-1
Il 6/1/2013 7:57 PM, David Rothenberger ha scritto: Please delete 1.2.1-1 and leave 1.3.0-1 as the previous version. Thanks! wget -x -nH --cut-dirs=2 \ http://home.comcast.net/~david.rothenberger/cygwin/libogg/libogg0/libogg0-1.3.1-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/libogg/libogg0/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/libogg/libogg-1.3.1-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/libogg/libogg-1.3.1-1-src.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/libogg/libogg-debuginfo/libogg-debuginfo-1.3.1-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/libogg/libogg-debuginfo/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/libogg/libogg-devel/libogg-devel-1.3.1-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/libogg/libogg-devel/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/libogg/setup.hint done and done
Re: [64bit RFU] libogg-1.3.1-1
Il 6/1/2013 7:58 PM, David Rothenberger ha scritto: wget -x -nH --cut-dirs=2 \ http://home.comcast.net/~david.rothenberger/cygwin64/libogg/libogg0/libogg0-1.3.1-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin64/libogg/libogg0/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin64/libogg/libogg-1.3.1-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin64/libogg/libogg-1.3.1-1-src.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin64/libogg/libogg-debuginfo/libogg-debuginfo-1.3.1-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin64/libogg/libogg-debuginfo/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin64/libogg/libogg-devel/libogg-devel-1.3.1-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin64/libogg/libogg-devel/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin64/libogg/setup.hint done
Re: [64bit RFU] libtheora-1.1.1-2
Il 6/1/2013 11:39 PM, David Rothenberger ha scritto: wget -x -nH --cut-dirs=2 \ http://home.comcast.net/~david.rothenberger/cygwin64/libtheora/libtheora0/libtheora0-1.1.1-2.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin64/libtheora/libtheora0/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin64/libtheora/libtheora-1.1.1-2.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin64/libtheora/libtheora-1.1.1-2-src.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin64/libtheora/libtheora-debuginfo/libtheora-debuginfo-1.1.1-2.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin64/libtheora/libtheora-debuginfo/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin64/libtheora/libtheoradec1/libtheoradec1-1.1.1-2.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin64/libtheora/libtheoradec1/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin64/libtheora/libtheora-devel/libtheora-devel-1.1.1-2.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin64/libtheora/libtheora-devel/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin64/libtheora/libtheoraenc1/libtheoraenc1-1.1.1-2.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin64/libtheora/libtheoraenc1/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin64/libtheora/setup.hint done
Re: [RFU] subversion-1.7.10-1
Il 6/2/2013 1:04 AM, David Rothenberger ha scritto: Please upload subversion-1.7.10-1 as the new current release. Please delete 1.7.9-1 and leave 1.6.17-1 as prev. uploaded and removed 1.7.9-2
Re: [64bit RFU]: speex-1.2rc1-1
Il 6/2/2013 1:59 AM, David Rothenberger ha scritto: wget -x -nH --cut-dirs=2 \ http://home.comcast.net/~david.rothenberger/cygwin64/speex/libspeex1/libspeex1-1.2rc1-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin64/speex/libspeex1/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin64/speex/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin64/speex/speex-1.2rc1-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin64/speex/speex-1.2rc1-1-src.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin64/speex/speex-debuginfo/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin64/speex/speex-debuginfo/speex-debuginfo-1.2rc1-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin64/speex/speex-devel/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin64/speex/speex-devel/speex-devel-1.2rc1-1.tar.bz2 done
Re: [RFU] flac-1.3.0-1
Il 6/2/2013 8:04 AM, David Rothenberger ha scritto: Please leave 1.2.1-1 as previous and delete 1.2.0-1. uploaded do you mean leave 1.2.1-2 and delete 1.2.1-1 ? Marco
Re: [64bit RFU] flac-1.3.0-1
Il 6/2/2013 8:09 AM, David Rothenberger ha scritto: wget -x -nH --cut-dirs=2 \ http://home.comcast.net/~david.rothenberger/cygwin64/flac/flac-1.3.0-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin64/flac/flac-1.3.0-1-src.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin64/flac/flac-debuginfo/flac-debuginfo-1.3.0-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin64/flac/flac-debuginfo/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin64/flac/flac-devel/flac-devel-1.3.0-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin64/flac/flac-devel/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin64/flac/flac-docs/flac-docs-1.3.0-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin64/flac/flac-docs/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin64/flac/libFLAC++6/libFLAC++6-1.3.0-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin64/flac/libFLAC++6/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin64/flac/libFLAC8/libFLAC8-1.3.0-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin64/flac/libFLAC8/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin64/flac/setup.hint done
Re: [64bit RFU] libao-1.1.0-1
Il 6/2/2013 8:25 AM, David Rothenberger ha scritto: wget -x -nH --cut-dirs=2 \ http://home.comcast.net/~david.rothenberger/cygwin64/libao/libao-1.1.0-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin64/libao/libao-1.1.0-1-src.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin64/libao/libao4/libao4-1.1.0-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin64/libao/libao4/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin64/libao/libao-debuginfo/libao-debuginfo-1.1.0-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin64/libao/libao-debuginfo/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin64/libao/libao-devel/libao-devel-1.1.0-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin64/libao/libao-devel/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin64/libao/setup.hint done
Re: [64bit RFU] texlive-20130529-1, etc.
Il 6/2/2013 2:46 PM, Ken Brown ha scritto:
On 6/1/2013 12:59 PM, marco atzeri wrote:
it tooks just "202 files, 3.3G in 1h 37m 13s"
It turns out that 202 wasn't enough. For some reason, one of the setup.hint
files didn't get uploaded. In addition, I accidentally omitted some of the
setup.hint files in my RFU, as well as the debuginfo files. The following
should fix it:
D=http://sanibeltranquility.com/cygwin/64bit/release/TeX
TL=texlive
TC=texlive-collection
wget -x -nH --cut-dirs=3 \
${D}/${TC}-games/setup.hint\
${D}/${TL}/setup.hint\
${D}/${TL}/texlive-debuginfo/texlive-debuginfo-20130529-1.tar.bz2\
${D}/${TL}/texlive-debuginfo/setup.hint\
${D}/${TL}/libkpathsea6/setup.hint\
${D}/${TL}/libkpathsea-devel/setup.hint\
${D}/${TL}/libptexenc1/setup.hint\
${D}/${TL}/libptexenc-devel/setup.hint\
${D}/asymptote/setup.hint\
${D}/asymptote/asymptote-debuginfo/asymptote-debuginfo-2.23-1.tar.bz2\
${D}/asymptote/asymptote-debuginfo/setup.hint
Thanks.
Ken
done
Re: [64bit RFU] libvorbis-1.3.3-1
Il 6/2/2013 5:56 PM, David Rothenberger ha scritto: wget -x -nH --cut-dirs=2 \ http://home.comcast.net/~david.rothenberger/cygwin64/libvorbis/libvorbis0/libvorbis0-1.3.3-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin64/libvorbis/libvorbis0/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin64/libvorbis/libvorbis-1.3.3-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin64/libvorbis/libvorbis-1.3.3-1-src.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin64/libvorbis/libvorbis-debuginfo/libvorbis-debuginfo-1.3.3-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin64/libvorbis/libvorbis-debuginfo/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin64/libvorbis/libvorbis-devel/libvorbis-devel-1.3.3-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin64/libvorbis/libvorbis-devel/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin64/libvorbis/libvorbisenc2/libvorbisenc2-1.3.3-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin64/libvorbis/libvorbisenc2/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin64/libvorbis/libvorbisfile3/libvorbisfile3-1.3.3-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin64/libvorbis/libvorbisfile3/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin64/libvorbis/setup.hint uploaded
Re: [64bit RFU] emacs-auctex-11.87-1
Il 6/2/2013 7:51 PM, Ken Brown ha scritto:
D=http://sanibeltranquility.com/cygwin/64bit/release/TeX
wget -x -nH --cut-dirs=3 \
${D}/emacs-auctex/emacs-auctex-11.87-1-src.tar.bz2 \
${D}/emacs-auctex/emacs-auctex-11.87-1.tar.bz2 \
${D}/emacs-auctex/setup.hint
Thanks.
Ken
uploaded
Re: [RFU] serf-1.2.1-1
Il 6/4/2013 4:27 AM, David Rothenberger ha scritto:
Please remove 1.2.0-1. 0.7.1-2 must remain for use with
subversion-1.6.
Thanks!
D=http://home.comcast.net/~david.rothenberger/cygwin
wget -x -nH --cut-dirs=2 \
{$D}/serf/libserf1_0/libserf1_0-1.2.1-1.tar.bz2 \
{$D}/serf/libserf1_0/setup.hint \
{$D}/serf/libserf1-devel/libserf1-devel-1.2.1-1.tar.bz2 \
{$D}/serf/libserf1-devel/setup.hint \
{$D}/serf/serf-1.2.1-1.tar.bz2 \
{$D}/serf/serf-1.2.1-1-src.tar.bz2 \
{$D}/serf/serf-debuginfo/serf-debuginfo-1.2.1-1.tar.bz2 \
{$D}/serf/serf-debuginfo/setup.hint \
{$D}/serf/setup.hint
s/{$D}/${D}/
uploaded and removed 1.2.0-1
Re: [64bit RFU] serf-1.2.1-1
Il 6/4/2013 4:35 AM, David Rothenberger ha scritto:
D=http://home.comcast.net/~david.rothenberger/cygwin64
wget -x -nH --cut-dirs=2 \
${D}/serf/libserf1_0/libserf1_0-1.2.1-1.tar.bz2 \
${D}/serf/libserf1_0/setup.hint \
${D}/serf/libserf1-devel/libserf1-devel-1.2.1-1.tar.bz2 \
${D}/serf/libserf1-devel/setup.hint \
${D}/serf/serf-1.2.1-1.tar.bz2 \
${D}/serf/serf-1.2.1-1-src.tar.bz2 \
${D}/serf/serf-debuginfo/serf-debuginfo-1.2.1-1.tar.bz2 \
${D}/serf/serf-debuginfo/setup.hint \
${D}/serf/setup.hint
uploaded
Re: [RFU] Perl-Text-CSV_XS-0.98-1
Il 6/7/2013 10:15 PM, David Stacey ha scritto: # 32-bit: # 64-bit: In both cases, please keep 0.97-1 as previous. Many thanks in advance, Dave. uploaded
Re: [64bit RFU] doxygen-1.8.4-2
Il 6/8/2013 12:28 AM, David Stacey ha scritto: Please remove 1.8.4-1 and leave 1.8.3.1-2 as previous. uploaded and removed 1.8.4-1 Many thanks in advance for uploading, Dave. Regards Marco
Re: [64bit] Uploads for 05 June
Il 6/5/2013 9:00 AM, Yaakov (Cygwin/X) ha scritto: I just uploaded the following packages (plus their subpackages) for the 64bit distribution: * gstreamer0.10-0.10.36-2 * gstreamer0.10-plugins-base-0.10.36-2 * gstreamer1.0-1.0.7-1 * gstreamer1.0-plugins-base-1.0.7-1 Following http://www.cygwin.com/setup.html Video is not "yet" a valid category warning: package girepository-Gst0.10 uses an invalid category 'Video' warning: package girepository-Gst1.0 uses an invalid category 'Video' warning: package girepository-GstCheck0.10 uses an invalid category 'Video' warning: package girepository-GstCheck1.0 uses an invalid category 'Video' warning: package girepository-GstInterfaces0.10 uses an invalid category 'Video' warning: package girepository-GstInterfaces1.0 uses an invalid category 'Video' warning: package gstreamer0.10 uses an invalid category 'Video' warning: package gstreamer0.10-plugins-aalib uses an invalid category 'Video' warning: package gstreamer0.10-plugins-base uses an invalid category 'Video' warning: package gstreamer0.10-plugins-cairo uses an invalid category 'Video' warning: package gstreamer0.10-plugins-esd uses an invalid category 'Video' warning: package gstreamer0.10-plugins-flac uses an invalid category 'Video' warning: package gstreamer0.10-plugins-gconf uses an invalid category 'Video' warning: package gstreamer0.10-plugins-gdk_pixbuf uses an invalid category 'Video' warning: package gstreamer0.10-plugins-gio uses an invalid category 'Video' warning: package gstreamer0.10-plugins-good uses an invalid category 'Video' warning: package gstreamer0.10-plugins-jpeg uses an invalid category 'Video' warning: package gstreamer0.10-plugins-libcaca uses an invalid category 'Video' warning: package gstreamer0.10-plugins-libdv uses an invalid category 'Video' warning: package gstreamer0.10-plugins-libpng uses an invalid category 'Video' warning: package gstreamer0.10-plugins-ogg uses an invalid category 'Video' warning: package gstreamer0.10-plugins-pango uses an invalid category 'Video' warning: package gstreamer0.10-plugins-pulse uses an invalid category 'Video' warning: package gstreamer0.10-plugins-shout2 uses an invalid category 'Video' warning: package gstreamer0.10-plugins-soup uses an invalid category 'Video' warning: package gstreamer0.10-plugins-speex uses an invalid category 'Video' warning: package gstreamer0.10-plugins-taglib uses an invalid category 'Video' warning: package gstreamer0.10-plugins-theora uses an invalid category 'Video' warning: package gstreamer0.10-plugins-vorbis uses an invalid category 'Video' warning: package gstreamer0.10-plugins-wavpack uses an invalid category 'Video' warning: package gstreamer0.10-plugins-ximage uses an invalid category 'Video' warning: package gstreamer0.10-plugins-ximagesrc uses an invalid category 'Video' warning: package gstreamer1.0 uses an invalid category 'Video' warning: package gstreamer1.0-plugins-aalib uses an invalid category 'Video' warning: package gstreamer1.0-plugins-base uses an invalid category 'Video' warning: package gstreamer1.0-plugins-flac uses an invalid category 'Video' warning: package gstreamer1.0-plugins-gdk_pixbuf uses an invalid category 'Video' warning: package gstreamer1.0-plugins-good uses an invalid category 'Video' warning: package gstreamer1.0-plugins-jpeg uses an invalid category 'Video' warning: package gstreamer1.0-plugins-libcaca uses an invalid category 'Video' warning: package gstreamer1.0-plugins-libdv uses an invalid category 'Video' warning: package gstreamer1.0-plugins-libpng uses an invalid category 'Video' warning: package gstreamer1.0-plugins-ogg uses an invalid category 'Video' warning: package gstreamer1.0-plugins-pango uses an invalid category 'Video' warning: package gstreamer1.0-plugins-pulse uses an invalid category 'Video' warning: package gstreamer1.0-plugins-shout2 uses an invalid category 'Video' warning: package gstreamer1.0-plugins-soup uses an invalid category 'Video' warning: package gstreamer1.0-plugins-speex uses an invalid category 'Video' warning: package gstreamer1.0-plugins-taglib uses an invalid category 'Video' warning: package gstreamer1.0-plugins-theora uses an invalid category 'Video' warning: package gstreamer1.0-plugins-vorbis uses an invalid category 'Video' warning: package gstreamer1.0-plugins-vpx uses an invalid category 'Video' warning: package gstreamer1.0-plugins-wavpack uses an invalid category 'Video' warning: package gstreamer1.0-plugins-ximage uses an invalid category 'Video' warning: package gstreamer1.0-plugins-ximagesrc uses an invalid category 'Video' warning: package libdv uses an invalid category 'Video' warning: package libdv-devel uses an invalid category 'Video' warning: package libdv4 uses an invalid category 'Video' warning: package libgstinterfaces0.10-devel uses an invalid category 'Video' warning: package libgstinterfaces0.10_0 uses an invalid category 'Video' warning: package libgstinterfaces1.0
Re: [64bit RFU] rdiff-backup 1.2.8-5
Il 6/9/2013 6:28 PM, David Rothenberger ha scritto:
D=http://home.comcast.net/~david.rothenberger/cygwin
s/cygwin/cygwin64\//
wget -x -nH --cut-dirs=2 \
${D}rdiff-backup/rdiff-backup-1.2.8-5.tar.bz2 \
${D}rdiff-backup/rdiff-backup-1.2.8-5-src.tar.bz2 \
${D}rdiff-backup/rdiff-backup-debuginfo/rdiff-backup-debuginfo-1.2.8-5.tar.bz2 \
${D}rdiff-backup/rdiff-backup-debuginfo/setup.hint \
${D}rdiff-backup/setup.hint
uploaded
Re: [64bit RFU] keepassx-0.4.3-1
Il 6/10/2013 7:43 PM, David Stacey ha scritto:
BASEURL=http://dl.dropbox.com/sh/7y1yn4whbyho9a7
wget --no-check-certificate --no-host-directories --force-directories
--cut-dirs=6 \
${BASEURL}/gMetoiuG3_/64bit/release/KDE/keepassx/keepassx-0.4.3-1-src.tar.bz2
\
${BASEURL}/faOgOyuoYS/64bit/release/KDE/keepassx/keepassx-0.4.3-1.tar.bz2 \
${BASEURL}/xaqPOGFz3J/64bit/release/KDE/keepassx/setup.hint \
${BASEURL}/U82Dz9jF1S/64bit/release/KDE/keepassx/keepassx-debuginfo/keepassx-debuginfo-0.4.3-1.tar.bz2
\
${BASEURL}/J4n6_izWKV/64bit/release/KDE/keepassx/keepassx-debuginfo/setup.hint
uploaded
Re: [RFU] sqlite3-3.7.17-3
Il 6/10/2013 9:55 PM, Warren Young ha scritto: Leave 3.7.16.2-1 as curr, and make this test only for now. you should make it test adding the relevant prev/current/test entries as specified on http://cygwin.com/setup.html (I am hoping to be able to promote it to curr later, but it changes too much to risk that without more testing. The only reason I'm RFU'ing it is because there seems to be some resistance to installing test versions from raw tarballs.) From within release/sqlite3: wget -e robots=off --cut-dirs=2 -np -nH -A'*3.7.17-3*' -A'*.hint' \ -r http://etr-usa.com/cygwin/sqlite3/ uploaded and put as test. Regards Marco
Re: [RFU] perl-Text-CSV_XS-1.00-1
Il 6/14/2013 8:49 PM, David Stacey ha scritto: # 32-bit: # 64-bit: In both cases, please remove 0.97-1 and leave 0.98-1 as previous. Many thanks in advance, Dave. uploaded Regards MArco
Re: [RFU] perl-Text-CSV-1.32-1
Il 6/14/2013 8:49 PM, David Stacey ha scritto: These /ought/ to be architecture independent, but just in case: # 32-bit: # 64-bit: In both cases, please leave 1.21-1 as previous. Many thanks in advance, Dave. uploaded
Re: [RFU] libaprutil1-1.5.2-2
Il 6/16/2013 12:51 AM, David Rothenberger ha scritto:
Please leave 1.4.1-1 as previous and remove 1.5.2-1.
Thanks!
D=http://home.comcast.net/~david.rothenberger/cygwin
wget -x -nH --cut-dirs=2 \
${D}/libaprutil1/aprutil1/aprutil1-1.5.2-2.tar.bz2 \
${D}/libaprutil1/aprutil1/setup.hint \
${D}/libaprutil1/libaprutil1-1.5.2-2-src.tar.bz2 \
${D}/libaprutil1/libaprutil1-1.5.2-2.tar.bz2 \
${D}/libaprutil1/libaprutil1-devel/libaprutil1-devel-1.5.2-2.tar.bz2 \
${D}/libaprutil1/libaprutil1-devel/setup.hint \
${D}/libaprutil1/setup.hint
uploaded and 1.5.2-1 removed
Marco
Re: [RFU] cyrus-sasl-2.1.26-2
Il 6/16/2013 12:55 AM, David Rothenberger ha scritto: Please leave 2.1.23-1 as the previous version and remove 2.1.25-1. uploaded. there is no 2.1.25-1 but 2.1.26-1 I removed that Regards Marco
Re: Preparation for gcc 4.7.3-1
Il 6/17/2013 7:32 AM, Christopher Faylor ha scritto: On Sun, Jun 16, 2013 at 11:49:44AM -0500, Yaakov (Cygwin/X) wrote: On 2013-06-16 09:56, Christopher Faylor wrote: I thought that Dave Korn was back and supporting gcc. Did that change? http://cygwin.com/ml/cygwin-apps/2013-06/msg00079.html So, the answer is: No. cgf I presume Yaakov means that Dave is again MIA and we need Kai to take over to finally deliver a gcc-4.7.x Dave, still with us ? Regards Marco
Re: [64bit] Wrong permissions on emacs-auctex directory
Il 6/21/2013 4:26 PM, Ken Brown ha scritto: Marco, I'm trying to update emacs-auctex, but you're the owner of /sourceware/ftp/pub/cygwin/64bit/release/TeX/emacs-auctex, and the cygwin group doesn't have write permission on the directory or its files. Could you fix this? Thanks. Ken changed
Re: Fixing packages which rely on obsolete packages
Il 6/22/2013 11:13 PM, Christopher Faylor ha scritto: On Sat, Jun 22, 2013 at 04:49:21PM -0400, Christopher Faylor wrote: Here's a similar list for 64-bit packages. Apparently genini's error checking leaves something to be desired. Obviously some of these are not obsolete. upset: *** warning - package gnupg requires non-existent package minires removed upset: *** warning - package libGraphicsMagick3 requires non-existent package libpng14 correct to libpng15 upset: *** warning - package libMagickCore5 requires non-existent package libpng14 correct to libpng15 upset: *** warning - package libplot-devel requires non-existent package libpng12-devel correct to libpng-devel upset: *** warning - package libplot2 requires non-existent package libpng12 correct to libpng15 upset: *** warning - package libplotter-devel requires non-existent package libpng12-devel correct to libpng-devel upset: *** warning - package libplotter-devel requires non-existent package libstdc++6-devel correct to libstdc++6 upset: *** warning - package libplotter2 requires non-existent package libpng12 correct to libpng15 upset: *** warning - package libslang2 requires non-existent package libpcre0 correct to libpcr1 upset: *** warning - package libslang2 requires non-existent package libpng14 corrected to libpng15 I haven't touched any 64-bit setup.hint's. cgf Regards Marco
Re: [RFU] screen
Il 6/28/2013 8:15 PM, Andrew Schulman ha scritto: Please upload just this setup.hint, which has changed to make the new release of screen current instead of test. Thanks, Andrew. # 32 bits wget -x -nH --cut-dirs=2 \ http://home.comcast.net/~andrex2/cygwin32/screen/setup.hint uploaded
Re: [RFU] cyrus-sasl-2.1.26-4
Il 6/29/2013 6:49 AM, David Rothenberger ha scritto: Please leave 2.1.23-1 as the previous version and remove 2.1.26-2. done
Re: [64bit RFU] cyrus-sasl-2.1.26-4
Il 6/29/2013 6:49 AM, David Rothenberger ha scritto: Please remove 2.1.26-1 and leave 2.1.26-3 as previous. Thanks! done. Ken, I was able to move at side your old upload dir but not to change permission or remove it. drwxrwsr-x. 2 matzeri cygwin4096 Jun 29 06:30 libsasl2_3-ldap drwxr-sr-x. 2 kbrown cygwin4096 Jun 26 03:23 libsasl2_3-ldap-bk could you take care ? $ ls -l libsasl2_3-ldap total 32 -rw-rw-r--. 1 matzeri cygwin 9183 Jun 29 06:30 libsasl2_3-ldap-2.1.26-3.tar.bz2 -rw-rw-r--. 1 matzeri cygwin 9188 Jun 29 06:30 libsasl2_3-ldap-2.1.26-4.tar.bz2 -rw-r--r--. 1 matzeri cygwin 112 Jun 29 06:30 md5.sum -rw-rw-r--. 1 matzeri cygwin 232 Jun 29 06:30 setup.hint $ ls -l libsasl2_3-ldap-bk/ total 20 -rw-rw-r--. 1 kbrown cygwin 9183 Jun 24 00:53 libsasl2_3-ldap-2.1.26-3.tar.bz2 -rw-r--r--. 1 root cygwin 112 Jun 29 06:23 md5.sum -rw-rw-r--. 1 kbrown cygwin 232 Jun 29 06:17 setup.hint May I suggest "umask 002" ? Regards Marco
Re: Preparation for gcc 4.7.3-1
Il 6/29/2013 1:03 PM, JonY ha scritto: On 6/20/2013 13:46, Christopher Faylor wrote: On Thu, Jun 20, 2013 at 06:18:23AM +0800, JonY wrote: On 6/19/2013 07:39, Yaakov (Cygwin/X) wrote: On 2013-06-18 17:32, JonY wrote: On 6/19/2013 06:17, Yaakov (Cygwin/X) wrote: As for the logistics, how about you put this in a temporary location (not under release) that I can access, and then I can deal with all the necessary transitioning. Where do I put the files at? /sourceware/cygwin-gcc/ sounds OK? You can put them in your HOME (or a subdirectory thereof). I put the upload at /sourceware1/home/jyong/gcc-new, but cgf says I shouldn't be using the home directory. It seems to be world readable though. I told you to use your home directory on irc. We had a discussion about this in this mailing list a few weeks ago. You should not be creating directories outside of your home directory. Isn't that in the home directory? I would say yes $ find /home/jyong/gcc-new/dist /home/jyong/gcc-new/dist /home/jyong/gcc-new/dist/gcc /home/jyong/gcc-new/dist/gcc/libquadmath0 /home/jyong/gcc-new/dist/gcc/libquadmath0/setup.hint /home/jyong/gcc-new/dist/gcc/libquadmath0/libquadmath0-4.7.3-1.tar.bz2 [cut] /home/jyong/gcc-new/dist/gcc/libgcj-common/setup.hint /home/jyong/gcc-new/dist/gcc/libgcj-common/libgcj-common-4.7.3-1.tar.bz2 /home/jyong/gcc-new/dist/gcc/gcc-4.7.3-1.tar.bz2 /home/jyong/gcc-new/dist/gcc/gcc-debuginfo /home/jyong/gcc-new/dist/gcc/gcc-debuginfo/setup.hint /home/jyong/gcc-new/dist/gcc/gcc-debuginfo/gcc-debuginfo-4.7.3-1.tar.bz2
Re: Preparation for gcc 4.7.3-1
Il 6/29/2013 1:30 PM, JonY ha scritto: On 6/29/2013 19:10, marco atzeri wrote: Isn't that in the home directory? I would say yes I see, FileZilla client probably likes to use pwd or realpath $PWD to find the working dir. I prefer a simple scp -r CUnit matzeri(at)sourceware.org:CUnit to upload on my home dir all the content of a dir Regards Marco
Re: [RFU] screen
Il 7/4/2013 3:17 AM, Andrew Schulman ha scritto: Please upload, for 32 and 64 bits. Please remove 4.1.0-20130513-1, leaving 4.0.3-7 as previous. Thanks, Andrew. done. what about 4.0.3-5 ? # 32 bits # 64 bits done
Re: [RFU] screen
Il 7/4/2013 6:09 AM, Andrew Schulman ha scritto: what about 4.0.3-5 ? Please remove that version. Thanks, Andrew. done
Re: [64bit RFU] scons-2.3.0-1
Il 7/5/2013 5:29 PM, David Rothenberger ha scritto:
D=http://home.comcast.net/~david.rothenberger/cygwin64
wget -x -nH --cut-dirs=2 \
${D}/scons/scons-2.3.0-1-src.tar.bz2 \
${D}/scons/scons-2.3.0-1.tar.bz2 \
${D}/scons/setup.hint
done
Re: [RFU] socat
Il 6/23/2013 5:23 PM, Andrew Schulman ha scritto: Please upload, for 32- and 64-bit. Both of the versions here are security updates, so please remove all previous versions in the archive. Thanks, Andrew. # 32-bit wget -x -nH --cut-dirs=3 \ http://home.comcast.net/~andrex2/cygwin32/socat/setup.hint \ http://home.comcast.net/~andrex2/cygwin32/socat/socat-1.7.2.2-1.tar.bz2 \ http://home.comcast.net/~andrex2/cygwin32/socat/socat-1.7.2.2-1.tar.bz2 \ http://home.comcast.net/~andrex2/cygwin32/socat/socat-2.0.0-b6-1.tar.bz2 \ http://home.comcast.net/~andrex2/cygwin32/socat/socat-2.0.0-b6-1.tar.bz2 \ # 64-bit wget -x -nH --cut-dirs=3 \ http://home.comcast.net/~andrex2/cygwin64/socat/setup.hint \ http://home.comcast.net/~andrex2/cygwin64/socat/socat-1.7.2.2-1.tar.bz2 \ http://home.comcast.net/~andrex2/cygwin64/socat/socat-1.7.2.2-1.tar.bz2 \ http://home.comcast.net/~andrex2/cygwin64/socat/socat-2.0.0-b6-1.tar.bz2 \ http://home.comcast.net/~andrex2/cygwin64/socat/socat-2.0.0-b6-1.tar.bz2 \ it seems someone already uploaded both, and forgot to mention it Bye Marco
Re: svn-load: missing dependency
Il 7/7/2013 8:24 AM, Yaakov (Cygwin/X) ha scritto: It was just brought to my attention[1] that Jari's svn-load package is (and always has been) missing a crucial dependency, pysvn (not to be confused with subversion-python). I have python-pysvn and python3-pysvn in Ports; should I move these to the distro, or remove svn-load? Yaakov [1] http://stackoverflow.com/questions/17508663 +1 to add.
Re: [ITP] poco-1.4.6p1-1
Il 7/6/2013 9:17 PM, David Stacey ha scritto:
Download links are as follows:
# 32-bit:
BASEURL=https://dl.dropboxusercontent.com/u/119453582/Cygwin/32bit/release
wget --no-check-certificate --no-host-directories --force-directories
--cut-dirs=5 \
${BASEURL}/poco/libpoco-1.4.6/libpoco-1.4.6-1.4.6p1-1.tar.bz2 \
${BASEURL}/poco/libpoco-1.4.6/setup.hint \
${BASEURL}/poco/libpoco-devel/libpoco-devel-1.4.6p1-1.tar.bz2 \
${BASEURL}/poco/libpoco-devel/setup.hint \
${BASEURL}/poco/libpoco-doc/libpoco-doc-1.4.6p1-1.tar.bz2 \
${BASEURL}/poco/libpoco-doc/setup.hint \
${BASEURL}/poco/poco-1.4.6p1-1-src.tar.bz2 \
${BASEURL}/poco/poco-debuginfo/poco-debuginfo-1.4.6p1-1.tar.bz2 \
${BASEURL}/poco/poco-debuginfo/setup.hint \
${BASEURL}/poco/setup.hint
it builds and passes almost all the tests.
I am not sure that the version number on "poco/libpoco-1.4.6"
directory name is needed
GTG for me
# 64-bit:
not tested, but I assume is fine ;-)
Many thanks in advance for looking at this package,
Dave.
[1] http://pocoproject.org/
[2] http://pkgs.org/search/?keyword=poco
Regards
Marco
[64bit] R-2.15.3-1
uploaded also the first 64bit Release Versions 2.15.3-1 of R libRmath libRmath-devel for cygwin are now available in the Cygwin distribution: CHANGES New upstream bugfix release https://mailman.stat.ethz.ch/pipermail/r-announce/2013/000560.html last of 2.x.y series DESCRIPTION R is a language and environment for statistical computing and graphics. R provides a wide variety of statistical (linear and nonlinear modelling, classical statistical tests, time-series analysis, classification, clustering, ...) and graphical techniques, and is highly extensible. The S language is often the vehicle of choice for research in statistical methodology, and R provides an Open Source route to participation in that activity. HOMEPAGE http://www.r-project.org/ Marco Atzeri
[ITP] metis-5.1.0-1
Already in debian, it improves some performance of SuiteSparse, so next cygwin package of Suitesparse will include metis as dependecy http://glaros.dtc.umn.edu/gkhome/views/metis Description: - METIS - Serial Graph Partitioning and Fill-reducing Matrix Ordering METIS stable version: 5.1.0, METIS is a set of serial programs for partitioning graphs, partitioning finite element meshes, and producing fill reducing orderings for sparse matrices. The algorithms implemented in METIS are based on the multilevel recursive-bisection, multilevel k-way, and multi-constraint partitioning schemes developed in our lab. -- Version 5.x has license Apache Version 2. http://glaros.dtc.umn.edu/gkhome/metis/metis/changes to download (remove the index.html's) : wget -r -np -nH --cut-dirs=1 \ http://matzeri.altervista.org/32bit/metis/index.html find metis -name index.html -o -name md5.sum | xargs rm File list libmetis-devel/libmetis-devel-5.1.0-1.tar.bz2 libmetis-devel/setup.hint libmetis0/libmetis0-5.1.0-1.tar.bz2 libmetis0/setup.hint metis-5.1.0-1-src.tar.bz2 metis-5.1.0-1.tar.bz2 metis-debuginfo/metis-debuginfo-5.1.0-1.tar.bz2 metis-debuginfo/setup.hint setup.hint Regards MArco
Re: remaining missing packages in 64-bit release
Il 7/14/2013 7:40 AM, Yaakov (Cygwin/X) ha scritto: On 2013-07-13 21:38, Christopher Faylor wrote: On Sat, Jul 13, 2013 at 09:44:40PM -0400, Andrew Schulman wrote: There are of course other packages that could be called missing because they haven't been ported to x86_64 yet, and other packages that depend on them can't be released until they are. Ah, good point. I'll check tomorrow and make a more comprehensive list. Attached. Yaakov please add an additional filter @ SuiteSparse category: _obsolete I replaced it with the singles packages: requires: amd btf camd ccolamd cholmod colamd cxsparse klu ldl rbio spqr suitesparseconfig umfpack
Re: [ITP] poco-1.4.6p1-1
Il 7/14/2013 7:36 PM, David Stacey ha scritto: # 32-bit: GTG # 64-bit: not tested. I assume is fine Thank you to Marco, Ken and Corinna, who all took the time to comment on my first poco package. This is attempt #2, which (hopefully) adopts the naming convention that Corinna suggested [1]. it looks fine to me Essentially, the code and patches are the same as I submitted previously. There is one extra patch (to stop one of the 'make' scripts resetting the library name) and a few tweaks to the 'poco.cygport' file (to produce the package names you see above). Poco is quite a bit more complex than the other packages I maintain, so if there are further changes you'd like me to make then let me know. Many thanks in advance for looking at this package, Dave. [1] - http://www.cygwin.com/ml/cygwin-apps/2013-07/msg00128.html Regards Marco
Re: SuiteSparse: upset messages
Il 7/15/2013 11:49 PM, Yaakov (Cygwin/X) ha scritto: On 2013-07-15 16:43, upset lived up to its name and complained: upset: *** /sourceware/ftp/pub/cygwin/x86/setup.ini: warning - package libSuiteSparse-devel refers to nonexistent external-source: SuiteSparse Marco, The problem was that libSuiteSparse-devel-3.7.1-1 was left without a source package of the same version. I moved that out of the way for now; let me know if you need it restored. Yaakov I forgot to remove it, thanks Marco
