Re: ATTN Maintainer : sqlite3 update ?
Yes, will do. Op za 11 mrt 2023 om 07:40 schreef Marco Atzeri : > Hi Jan, > could you update the package to last version ? > > Regards > Marco > > > >
Re: Go or Rust Packages?
Op vr 4 feb. 2022 om 07:58 schreef Marco Atzeri: > As it is written in go, you need to go back to the oldest version > written in C and from them forward to the current version. There's also a "golang" frontend for gcc. Could that be used to bootstrap go? Regards, Jan Nijtmans
Re: autoconf
Op do 2 dec. 2021 om 11:41 schreef Corinna Vinschen via Cygwin-apps: > Nope, I didn't. Make that: > > On Dec 2 08:23, ASSI wrote: Indeed, sorry!. I stripped a little bit too much from the message ... Regards, Jan Nijtmans
Re: autoconf
Op do 2 dec. 2021 om 10:22 schreef Corinna Vinschen via Cygwin-apps:
> > Most distros still package 2.69 or even earlier and that includes some
> > substantial rolling release distros. As long as these guys don't use
> > the newer version it seems unlikely that we would actually need it, plus
> > I don't see us spending time and effort debugging things that aren't
> > even Cygwin specific.
My 2c : Cygwin should - at least - allow people to install autoconf-2.71
and - as long as the packages are prepared for it - things shouldn't break.
If I install autoconf-2.71 locally, and then compile Tcl 8.6.12, which
contained in tcl.cygport:
src_compile() {
cd ${S}/unix
cygautoreconf
...
$ cygport tcl.cygport compile
>>> Compiling tcl-8.6.12-1.x86_64
*** ERROR: autoconf2.5 is required to build this package
My solution was, simply to remove the "cygautoreconf" line from the
cygport file, then it works again.
Somewhere in cygport, a check is done for the autoconf version, please
change this check to allow autoconf 2.71 (as well as 2.59 and 2.69).
Then I can put back the "cygautoreconf" line in tcl.cygport.
Thanks!
Jan Nijtmans
Tcl/Tk 8.6.12
The following packages have been uploaded to the Cygwin distribution: * tcl-8.6.12-1 * tcl-devel-8.6.12-1 * tcl-tk-8.6.12-1 * tcl-tk-devel-8.6.12-1 * tcl-itcl-4.2.2-1 * tcl-itcl-devel-4.2.2-1 * tcl-itk-4.2.2-1 * tcl-itk-devel-4.2.2-1 * tcl-iwidgets-4.1.1-1 * mingw64-i686-tcl-8.6.12-1 * mingw64-i686-tk-8.6.12-1 * mingw64-x86_64-tcl-8.6.12-1 * mingw64-x86_64-tk-8.6.12-1 This is an update and rebuild of the Tcl/Tk stack to the latest upstream releases. Regards, Jan Nijtmans
[ITP] mingw64-i686-libtommath/mingw64-x86_64-libtommath
Hi all, I would like to upload new packages for libtommath for Windows 32 and 64. They will be needed when Tcl 8.7 approaches final state (that will still take considerable time ...), but at least it will allow me to do some testing earlier: libtommath 1.2 is final, so no need to wait for that. I'm already maintaining the cygwin (32-bit and 64-bit) port of libtommath, so doing the mingw-w64 parts as well is quite trivial. I already have working cygport files. Could someone please add those two package names to the cygwin-pkg-maint file, and add the necessary directores so I can do the upload ? Thanks! Jan Nijtmans
Re: Putting packages up for adoption
First, I would like three packages to be added to cygwin-pkg-maint:
- mingw64-i686-tcl-thread
- mingw64-x86_64-tcl-thread
- tcl-thread
This is meant for the Tcl-Tk "thread" extension.
Second, making my point, this time with proof.
Op di 24 mrt. 2020 om 20:27 schreef Jan Nijtmans:
> Op di 24 mrt. 2020 om 15:25 schreef Yaakov Selkowitz:
> > Fedora, and possibly other distros as well, set a default search path
> > for tcl that conforms with their desired filesystem layout -- having
> > all extensions under /usr/{lib,share}/tclX.Y instead of scattered
> > throughout /usr/{lib,share}.
>
> Thank you! It's 100% clear to me now. It's just about customising
> to Fedora's directory layout. They have the right to do that, I have
> the right to ignore it ;-).
In the mingw32-xxx-tcl packages, loading the "registry" and "dde"
sub-packages doesn't work. The reason is the wrong setting of the
$auto_path variable, which is caused by the fedora patches:
tclsh86
% info nameofexecutable
C:/builds/cygwin32/usr/i686-w64-mingw32/sys-root/mingw/bin/tclsh86.EXE
% package require registry
can't find package registry
% set auto_path
C:/builds/cygwin32/usr/i686-w64-mingw32/sys-root/mingw/lib/tcl8.6
% set auto_path C:/builds/cygwin32/usr/i686-w64-mingw32/sys-root/mingw/lib
C:/builds/cygwin32/usr/i686-w64-mingw32/sys-root/mingw/lib
% package require registry
1.3.2
% package require dde
1.4.0
%
Of course, I will fix this in the next version.
Regards,
Jan Nijtmans
Re: Putting packages up for adoption
Op di 24 mrt. 2020 om 15:25 schreef Yaakov Selkowitz:
> Fedora, and possibly other distros as well, set a default search path
> for tcl that conforms with their desired filesystem layout -- having
> all extensions under /usr/{lib,share}/tclX.Y instead of scattered
> throughout /usr/{lib,share}.
Thank you! It's 100% clear to me now. It's just about customising
to Fedora's directory layout. They have the right to do that, I have
the right to ignore it ;-).
Regards,
Jan Nijtmans
Regards,
Jan Nijtmans
Re: Putting packages up for adoption
Op di 24 mrt. 2020 om 14:51 schreef Yaakov Selkowitz: > > However, I created a "fedora" branch in (upstream) Tcl, in which > > I merged the two patches from fedora. Result: > > <https://travis-ci.org/github/tcltk/tcl/builds/666214831> > > The errors I see there are "Test file error: can't find package > tcltests", which sounds like an issue with the test environment and not > on those changes. The point is, Tcl has a specific order of paths where it searches its environment, like an $auto_path variable. The test-suite tests this algorithm, and - apparently - the outcome of the algorith changed. You can add additional paths, but you cannot change the order of existing paths that are searched. So, sorry, but I respectfully disagree. The test-suite adds a path where it can find the "tcltests" package, the fedora changes result in not finding that package any more. That's a bug in the path search algorithm, which is modified by the fedora patch. Regards, Jan Nijtmans
Re: Putting packages up for adoption
Op di 24 mrt. 2020 om 00:38 schreef Yaakov Selkowitz: > > Hm. It appears that they did: > > <https://src.fedoraproject.org/rpms/tcl/tree/master> > > I meant their mingw-tcl package. Indeed, you are right! However, I created a "fedora" branch in (upstream) Tcl, in which I merged the two patches from fedora. Result: <https://travis-ci.org/github/tcltk/tcl/builds/666214831> So, I wonder if they ran the Tcl test suite this gives not much thrust, since they changes assumptions made in the test-cases, assumptions that user-applications and other environments could depend on. Regards, Jan Nijtmans
Re: Putting packages up for adoption
Op ma 23 mrt. 2020 om 16:45 schreef Yaakov Selkowitz: > The bulk of the patchset is from Fedora, but they haven't updated > recently either. Hm. It appears that they did: <https://src.fedoraproject.org/rpms/tcl/tree/master> :-) Regards, Jan Nijtmans
Re: Putting packages up for adoption
Op zo 22 mrt. 2020 om 23:34 schreef Yaakov Selkowitz: > A word of caution wrt Tcl/Tk for Cygwin: upstream incorrectly treats > Cygwin as a Win32 platform, necessitating extensive patches to make it > comply with *NIX/X11 standards. These patches CANNOT be dropped > without breaking compatibility, since Win32 and X11 APIs do not > interact. Fortunately, Tcl/Tk moves rather slowly, so the existing > patches should serve you well for some time. Yes, I'm aware of that. Of course, I'll be very careful to guarantee 100% binary compatibility. Still, I have some questions. At first, I noted that the current Tcl version is 8.6.8, which is two patchlevels behind (released December 22, 2017, more than 3 years old, while 8.6.10 is released November 21, 2019, 4 months ago). Work to do! So, I tried starting with x86_64-w64-mingw32. Here are my remarks. - There are 7 patches included. Only one of them applies cleanly, the others are not really necessary (Please correct me if I'm wrong. Let's go through them. - tcl-8.5.6-mingw.patch This one is wrong. Changing tools for cross-compilations should be done by "configure ... --host=x86_64-w64-mingw32" - tcl-8.6.1-nativezlib.patch OK. Tcl provides its own zlib.dll, in case it's not available externally. In Cygwin it is available (as "mingw64-x86_64-zlib"), which is prefered. (I added "cygautoreconf", so this patch would be part of "configure") - tcl-8.6.3-autopath.patch Not necessary for building, Only needed when we want to run Tcl in a non-standard installed directory. - tcl-8.6.5-hidden.patch Wrong. This exports some internal symbols, which are not supposed to be exported at all. - tcl-8-6-5-paralle-make-fix.patch Already fixed upstream. Besides, it's for unix/Makefile.in, not for mingw. - tcl-mingw-w64-compatibility.patch Already fixed upstream: <https://core.tcl-lang.org/tcl/info/8fbf108ea77e5351> - tcl-nativetclsh.patch Only needed when running Tcl, not for building the libraries Further on, I noted the the resulting hints file contains: requires: tcl while I would expect: requires: mingw64-x86_64-zlib Here is my cygport file so far. Thanks for your feedback! Regards, Jan Nijtmans mingw64-x86_64-tcl.cygport Description: Binary data
Re: Putting packages up for adoption
Op vr 20 mrt. 2020 om 05:03 schreef Yaakov Selkowitz: > To that end, in the best interest of the community, please consider my > packages up for adoption. I don't expect that any one person will take > all of them; some are obsolete and due for removal anyway, some should > be picked up as soon as possible, and others might just end up > bitrotting if nobody is interested in them. However, in whatever there > is interest (or need), hopefully what is there now will serve as a > strong foundation to on which to continue to build. I'm willing to adopt the tcl-related packages: mingw64-i686-tcl Yaakov Selkowitz mingw64-i686-tk Yaakov Selkowitz mingw64-x86_64-tcl Yaakov Selkowitz mingw64-x86_64-tkYaakov Selkowitz tcl Yaakov Selkowitz tcl-itcl Yaakov Selkowitz tcl-itk Yaakov Selkowitz tcl-iwidgets Yaakov Selkowitz tcl-tix Yaakov Selkowitz tcl-tk Yaakov Selkowitz tcl-togl Yaakov Selkowitz And - since I'm already maintaining SQLite, I can do the mingw64 variants of SQLite too: mingw64-i686-sqlite3 Yaakov Selkowitz mingw64-x86_64-sqlite3 Yaakov Selkowitz In one month or so, Tcl 8.6.11 is expected, then I'll try to get the first builds going (assuming my contribution is accepted) Regards, Jan Nijtmans
Re: [ITP] libtommath
Op di 26 nov. 2019 om 20:22 schreef Marco Atzeri: > > Am 26.11.2019 um 13:21 schrieb Jan Nijtmans: > > Hi all, > > > > Libtommath (version 1.2.0) is a multiple-precision integer library which > > is available on various Linux platforms (e.g. Ubuntu, Fedora). Tcl 8.6 > > has its own libtommath fork built-in, but it's planned to change that > > for Tcl 8.7: Tcl 8.7 will depend on libtommath 1.2.0 (or later). That's > > why I would like this package to be available for Cygwin. > > > > your cygport has some problem at package action > > *** Warning: libtommath.hint is missing > > no idea why, but your cygport is a bit unusual in defining the > variables Yes, I saw this warning. Also don't known why. The resulting package works! And since libtommath doesn't have any dependencies ... I could use some advise how to do this better! Thanks! Jan Nijtmans
[ITP] libtommath
Hi all,
Libtommath (version 1.2.0) is a multiple-precision integer library which
is available on various Linux platforms (e.g. Ubuntu, Fedora). Tcl 8.6
has its own libtommath fork built-in, but it's planned to change that
for Tcl 8.7: Tcl 8.7 will depend on libtommath 1.2.0 (or later). That's
why I would like this package to be available for Cygwin.
I created a libtommath.cygport file, and managed to create x64 and i686
cygwin packages for it. If approved, can you please add those to
the cygwin-pkg-maint file and have these owned by me. Then I will
upload them.
The package files can be found (temporary) here:
<https://www.dropbox.com/sh/4y11za6dv5fwdh9/AAAm127uiszYkEIq9HTbxakKa?dl=0>
libtommath1
libtommath-doc
libtommath-devel
libtommath-debuginfo
Thanks!
Regards,
Jan Nijtmans
Re: [ITA] fossil
2015-05-28 17:42 GMT+02:00 jari: See fossil.README; It is being maintained. Latest package uploaded, Jari Great to hear that! Thanks! Regards, Jan Nijtmans
[ITA] fossil
I would like to adopt fossil. I've packaged the latest release. The
main reason I am offering this, is that I'm noting that fossil
is falling behind the upstream version (1.33, currently), and
I don't see any action taken on Corinna's request to convert
the build system to cygport:
2015-02-11 10:23 GMT+01:00 Jan Nijtmans jan.nijtm...@gmail.com:
2015-02-10 10:30 GMT+01:00 Corinna Vinschen:
Would you mind terribly to start converting your build systems to
cygport with this package?
...
I couldn't resist myself making a start with this. And got it working
So, that's what I did, and it is completed now, ready to be
reviewed by anyone interested. Since I'm already building
a win64 version and a Docker version for every fossil
release, additional Cygwin(32/64) builds are not that much
additional work any more.
If Jari intends to keep fossil maintenance and wants to
use my work as starting-point for a cygport build, that's
fine with me too. Fossil doesn't get the attention it
deserves, and distributing an older version in Cygwin
is just a pity. I'm glad to help with that in any way I can.
setup.hint
--
category: Devel
requires: cygwin libopenssl100 libsqlite3_0 zlib0
sdesc: DVCS with built-in wiki, http server and issue tracker
ldesc: A single binary distributed version control which utilizes
SQLite database back-end for storage metadata. The self contained
binary includes also issue tracker, wiki engine and built in web
server to serve everything; including the repositories. Fossil uses
plain HTTP, with proxy support, for all network communications.
Autosync feature helps to keep repositories and their distributed issue
trackers up to date without need for separate merging.
D=https://dl.dropboxusercontent.com/u/69449580
wget -x -nH --cut-dirs=3 \
${D}/fossil/x86_64/setup.hint \
${D}/fossil/x86_64/fossil-1.33-1.tar.xz \
${D}/fossil/x86_64/fossil-1.33-1-src.tar.xz \
${D}/fossil/x86_64/fossil-debuginfo/setup.hint \
${D}/fossil/x86_64/fossil-debuginfo/fossil-debuginfo-1.33-1.tar.xz
D=https://dl.dropboxusercontent.com/u/69449580
wget -x -nH --cut-dirs=3 \
${D}/fossil/i686/setup.hint \
${D}/fossil/i686/fossil-1.33-1.tar.xz \
${D}/fossil/i686/fossil-1.33-1-src.tar.xz \
${D}/fossil/i686/fossil-debuginfo/setup.hint \
${D}/fossil/i686/fossil-debuginfo/fossil-debuginfo-1.33-1.tar.xz
Regards,
Jan Nijtmans
cygwin64-sqlite3 obsolete?
In the 32-bit setup, a rather old (3.7.15) version of cygwin64-sqlite3 is present, my guess is that this package was set up for the Cygwin64 bootstrap. I have no plans to adopt this package for updating it to the current version (3.8.3), therefore I would like to request this package to be removed. Any objections? Regards, Jan Nijtmans
Re: [ITA] Git et al
2014-01-29 Achim Gratz strom...@nexgo.de: Does it use the system SQLite and if so, does it run the tests cleanly? I'm building that package locally against the installed libraries and I've been getting UNIQUE constraint errors from the test suite since the 3.8.x version of SQLite has landed. SQLite 3.7.17 is still available, and SQLite 3.8.3 (beta) is available as test package. Especially 3.7.17 is meant to be able to verify such kinds of possible regressions. Does this 3.7.17 work well with git? If so, this looks like a regression which should be reported to the SQLite developers. If there is anything I can do to help, let me know. Version 3.8.3 will come out soon. Regards, Jan Nijtmans
Re: [ITA] tcl-sqlite3
2014/1/21 Corinna Vinschen: Please make sure to provide only subpackages for which the matching source package is available, too. Thank you, I didn't know that. My apologies! Regards, Jan Nijtmans
Re: [ITA] tcl-sqlite3
2014/1/20 Yaakov (Cygwin/X) yselkow...@users.sourceforge.net: What is the source of the ICU and zlib patches, and why have you added them? ICU is a *huge* dependency for something as small as sqlite3. ICU is a dependency on sqlite3, but not for libsqlite3_0. So applications like Subversion don't get ICU as additional dependency. I don't think that the sqlite3 utility is used by many people. And the ones who do, expect that lower() and upper() work for all Unicode characters. On the SQLite mailing list I see messages regularly why SQLite doesn't have Unicode support. So-far, no-one complained about this added dependency. A solution might be a separate sqlite3-icu package, I'll consider that. The source for icu.c is in the SQLite source code (unfortunately not packed in the download). zlib.c is extracted from Fossil. I'm planning to contribute that upstream as separate SQLite extension. Your src.patch includes an incorrect hunk for sqlite3.h:SQLITE_VERSION_NUMBER. I also don't understand the reasoning for your tclsqlite3.c patches. It's on purpose: Subversion internally checks for sqlite3_libversion_number() = SQLITE_VERSION_NUMBER which means that Subversion compiled against SQLite 3.8.2 headers won't run on SQLite 3.8.1 any more. This is nonsense, and should be fixed upstream (in Subversion), but as long as that's not done this hack works. David Rothenberger might also patch Subversion for that, then I'm happy to undo this hack. libsqlite3.7.15.2.dll exports the following symbols: Sqlite3_Init Sqlite3_Unload TclTomMathInitializeStubs Tcl_InitStubs Tclsqlite3_Init Tclsqlite3_Unload memcmp tclIntPlatStubsPtr tclIntStubsPtr tclIntPlatPtr tclStubsPtr tclTomMathStubsStubsPtr Only the *_Init and *_Unload functions should be exported. That's what another patch is for. Finally win32-longpath is a better default VFS for Tcl as it gives less locking errors and handles paths 260 bytes better. As soon as the unix-cygwin VFS is enhanced to handle that better (still on my TODO list), this patch can be removed as well. But it's difficult to get Cygwin patches adapted in SQLite upstream, Warren can confirm that ;-) Also, you also clobbered the upstream README with a Cygwin-specific one; please don't do that. I'll undo that in my next version. Thanks! Huh? setup will remove the previous version before installing the newer one anyway. I didn't know that. Thanks! If it works, don't fix it. IMO we should let TEA do its thing. I'm willing to change that in my next version (assuming Corinna agrees on that) . SQLite 3.8.3 is going to be released in about 3 weeks anyway. That's not necessary, as it will have an external-source: sqlite3. Then why are libsqlite3-devel and libsqlite3_0 listed there as separate packages? Thanks for all feedback! Regards, Jan Nijtmans
Re: [ITA] tcl-sqlite3
2014/1/14 Yaakov (Cygwin/X): I don't see any links to a -src package, or better yet, a URL to the .cygport and patches (if any). That's because the -src package is the same as the sqlite3 src package. Apparently that was not clear enough from the mailed setup.hint file, it's already uploaded to cygwin.com: 2014/1/13 Jan Nijtmans jan.nijtm...@gmail.com: = tcl-sqlite3/setup.hint ... external-source: sqlite3 prev: 3.7.15.2-1 curr: 3.8.2-3 However, the one with the latest modifications can be found here now: https://dl.dropboxusercontent.com/u/69449580/Cygwin/sqlite3/sqlite3-3.8.2-3-src.tar.xz 2014/1/14 Warren Young war...@etr-usa.com: If it's hidden under /usr/lib/tcl or whatever, I don't see a problem with the fully-versioned library file. It's only for tcl-sqlite's use, and it's behind a layer of indirection, so it can call its file whatever it wants. It's not a problem, but partly-versioned (only the 3) library file has the advantage that no uninstall needs to be done after an upgrade to a higher version. The directory cannot accidentally keep old versions of files around, every upgrade will simply overwrite it with the new version. If the filename is agreed upon, still agreement is needed on the directory where those file should be installed. Using /usr/lib/tcl8.x/sqlite3 is not strange at all: TEA dictates that there should be a tclConfig.sh file in /usr/lib, but Debian moves that to /usr/lib/tcl8.x as well. It's already in the search path of Tcl, so it will work without the need to patch Tcl itself. Putting it in /usr/lib/tcl8.6/sqlite3, and create a link in /usr/lib/tcl8.5 as well, has the advantage that it is already ready for (my locally compiled) Tcl 8.6. Of course, it could be the other way around as well, but then I would like to to put a link in /usr/lib/tcl8.6 anyway. It just depends on what plans Cygwin has for Tcl 8.6 in the near future, I simply don't know. Summarised: TEA (without full-version): /usr/lib/sqlite3/tclsqlite3.dll /usr/lib/sqlite3/pkgIndex.tcl TM (Tcl module new style): /usr/lib/tcl8/8.5/sqlite3/tclsqlite3.dll /usr/lib/tcl8/8.5/sqlite3/sqlite3-3.8.2.tm (not a good idea, because tm-files are expected to contain the full version number) My suggestion (looks like Fedora's sqlite-tcl package): /usr/lib/tcl8.5/sqlite3 - ../tcl8.6/sqlite3 /usr/lib/tcl8.6/sqlite3/tclsqlite3.dll /usr/lib/tcl8.6/sqlite3/pkgIndex.tcl or /usr/lib/tcl8.6/sqlite3 - ../tcl8.5/sqlite3 /usr/lib/tcl8.5/sqlite3/tclsqlite3.dll /usr/lib/tcl8.5/sqlite3/pkgIndex.tcl Who has the authority to make such decision? And who can add the tcl-sqlite3 package to cygwin-pkg-maint? Thanks for all your cooperation! Regards, Jan Nijtmans
Re: [ITA] tcl-sqlite3
2014/1/14 Corinna Vinschen: I don't know much about sqlite, but your package content puzzles me: usr/lib/sqlite3.8.2/pkgIndex.tcl usr/lib/sqlite3.8.2/sqlite382.dll usr/share/man/mann/sqlite3.n.gz This looks only vaguely related to tcl. I see that the existing tcl-sqlite3-3.7.15.2-1.tar.bz2 in the 64 bit distro looks similar, but it's bound against sqlite-3.7.15.2, so it probably won't work with recent sqlite versions anyway. Well, I tested it, and the tcl-sqlite-3.7.15.2 package works fine together with the sqlite-3.8.2 package: All sqlite3 package are binary upwards compatible. I really don't quite grok the directory layout and the naming. Without patching, the TEA (Tcl Extension Architecture) is followed, of course I can patch it to whatever structure is required for Cygwin. Thanks! I took a look into the Fedora package, which is called sqlite-tcl. It provides /usr/lib/tcl8.5/sqlite3 /usr/lib/tcl8.5/sqlite3/libtclsqlite3.so /usr/lib/tcl8.5/sqlite3/pkgIndex.tcl That makes more sense to me: My tcl-sqlite3 build works with both Tcl 8.5 and 8.6 without re-compilation. Of course I could install copies in both /usr/lib/tcl8.5 and /usr/lib/tcl8.6, if that is desired, but both copies would just be identical. Regards, Jan Nijtmans
Re: [ITA] tcl-sqlite3
2014/1/14 Corinna Vinschen: That's not what I meant. What I meant is that Tcl extras are installed under /usr/lib/tcl, not directly under /usr/lib. I have no idea about the TEA, but it looks wrong to install Tcl stuff to /usr/lib. Perl stuff is under /usr/lib/perl, python stuff is under /usr/lib/python, ruby stuff is under /usr/lib/ruby... you get the idea. Agreed. Then it's most logical to install in /usr/lib/tcl. I'll do that. Also, even if sqlite3.8.2 and sqlite382.dll works, it's kind of puzzeling. Are you saying using sqlite3 and libtclsqlite3.so on Fedora is wrong, not following TEA? It's much easier to grok and doesn't wrongly imply it only works on a specificx sqlite 3.x.x version, IMHO. No, I'm not implying at all that Fedora (or Cygwin) is wrong at following TEA. TEA is designed to be able to install multiple versions of Tcl extensions next to each other, so if there are incompatible changes each Tcl application can choose which one it wants. Sqlite3 is very careful keeping upwards compatibility, so I would say Sqlite doesn't need that. And I don't intend to support multiple tcl-sqlite3 versions anyway. I have no problem at all patching the TEA build scripts for that, just as Fedora did. Thanks! Jan Nijtmans
Re: [ITA] tcl-sqlite3
2014/1/14 Corinna Vinschen: I don't know much about sqlite, but your package content puzzles me: usr/lib/sqlite3.8.2/pkgIndex.tcl usr/lib/sqlite3.8.2/sqlite382.dll usr/share/man/mann/sqlite3.n.gz After some experimenting, I'm proposing the following layout: usr/lib/tcl8.5/sqlite3- ../tcl8.6/sqlite3 (soft link) usr/lib/tcl8.6/sqlite3/pkgIndex.tcl usr/lib/tcl8.6/sqlite3/tclsqlite3.dll usr/share/man/mann/sqlite3.n.gz This way, both Tcl 8.5 and 8.6 can find the package without the need to duplicate anything. And the full version numbers are gone. Is that better? Warren and Yaakov, what are you saying as sqlite and tcl maintainers? I've copied the modified tar.xz files (setup.hint is unmodified) to my dropbox area: https://dl.dropboxusercontent.com/u/69449580/Cygwin/sqlite3/tcl-sqlite3/setup.hint https://dl.dropboxusercontent.com/u/69449580/Cygwin/sqlite3/tcl-sqlite3/tcl-sqlite3-3.8.2-3.tar.xz https://dl.dropboxusercontent.com/u/69449580/Cygwin64/sqlite3/tcl-sqlite3/setup.hint https://dl.dropboxusercontent.com/u/69449580/Cygwin64/sqlite3/tcl-sqlite3/tcl-sqlite3-3.8.2-3.tar.xz Thanks very much for your feedback! Regards, Jan Nijtmans
[ITA] tcl-sqlite3
Cygwin64 has an exisiting tcl-sqlite3 package (version 3.7.15.2-1) which doesn't exist in Cygwin32. This package is not in cygwin-pkg-maint, so I assume someone (other than Warren Young) uploaded it as part of the Cygwin64 bootstrap process. This package was very useful to me: The source code of the bindings is already included in the sqlite3 source package, all that needed to be added is a few lines to actually build it. I think it is useful to more people than only me: It is part of the batteries included Tcl 8.6 package, but it works fine with Tcl 8.5 as well without re-compilation (I tested it with both!) I'm thus offering to take over the following package: - tcl-sqlite3 Following http://cygwin.com/setup.html, I've copied the assorted setup.hint files below and uploaded the packages to my dropbox area: https://dl.dropboxusercontent.com/u/69449580/Cygwin/sqlite3/tcl-sqlite3/setup.hint https://dl.dropboxusercontent.com/u/69449580/Cygwin/sqlite3/tcl-sqlite3/tcl-sqlite3-3.8.2-3.tar.xz https://dl.dropboxusercontent.com/u/69449580/Cygwin64/sqlite3/tcl-sqlite3/setup.hint https://dl.dropboxusercontent.com/u/69449580/Cygwin64/sqlite3/tcl-sqlite3/tcl-sqlite3-3.8.2-3.tar.xz I'm not sure if a GTG is needed from another package maintainer, otherwise Warren Young would be the most logical choice. Anyway, whatever feedback from Warren (or anyone else) is appreciated! Jan Nijtmans = tcl-sqlite3/setup.hint category: Database Tcl requires: libsqlite3_0 tcl sdesc: Tcl bindings for SQLite ldesc: SQLite is a C library that implements an embeddable SQL database engine. Programs that link with the SQLite library can have SQL database access without running a separate RDBMS process. The distribution comes with a standalone command-line access program (sqlite3) that can be used to administer an SQLite database and which serves as an example of how to use the SQLite library. external-source: sqlite3 prev: 3.7.15.2-1 curr: 3.8.2-3
Subject: SSH key for upload access
Name: Jan Nijtmans Package: sqlite3, libsqlite3-devel, libsqlite3_0 BEGIN SSH2 PUBLIC KEY Comment: 2048-bit RSA, converted by nijtmaj@NB1912 from OpenSSH B3NzaC1yc2EDAQABAAABAQCoMlr/9sPXdDP6KA5b8bdfTHi6pDLZBT4DB24lqn lQIG3CxDVLGSudt+sMlHGxsLpa5eQBsFBuenNZH+GD4503BD/AIv8UpSkC8xTgIYAryIWP fLLHtF57thmk6LYWZlMSh2O1Va5EdnhmJhi75ZUFavfEYb/QFlllXGwUad9KkQ2mZqwBNK JM9lZnq+xJynWCHAkMLTLFXOHisTQSgiRc08fX/i9XHRC71jrua5N0y3af8MbjA5q/Mj9u jgUgRgB6+dJWpAgAKFsVPGnkT2TvG5hEwJbl6lE22/6mux2ETAq8sHkQjc//gmulFC0Rhj bJQpu93Q3/o3z/FIPRAGxF END SSH2 PUBLIC KEY
Re: Subject: SSH key for upload access
2013/11/15 Christopher Faylor: The web page also doesn't say Put a single space in front of Name and Package. And the web page neither says that Subject: should be put before the subject ;-( I'm sorry for being a bad copy/paster... Anyway, Thanks! Regards, Jan Nijtmans
[ITA] sqlite3
I would like to adopt sqlite3. I've packaged the latest release.
setup.hint
--
category: Database
requires: libreadline7 libgcc1
sdesc: Client program for accessing SQLite 3 databases, plus docs
ldesc: SQLite is a C library that implements an embeddable SQL database
engine. Programs that link with the SQLite library can have SQL
database access without running a separate RDBMS process. The
distribution comes with a standalone command-line access program
(sqlite3) that can be used to administer an SQLite database and which
serves as an example of how to use the SQLite library.
download:
--
D=http://dl.dropboxusercontent.com/u/69449580/Cygwin64
wget -x -nH --cut-dirs=3 \
${D}/sqlite3/setup.hint \
${D}/sqlite3/sqlite3-3.8.1-1.tar.xz \
${D}/sqlite3/sqlite3-3.8.1-1-src.tar.xz \
${D}/sqlite3/libsqlite3_0/setup.hint \
${D}/sqlite3/libsqlite3_0/libsqlite3_0-3.8.1-1.tar.xz \
${D}/sqlite3/libsqlite3-devel/setup.hint \
${D}/sqlite3/libsqlite3-devel/libsqlite3-devel-3.8.1-1.tar.xz \
${D}/sqlite3/sqlite3-debuginfo/setup.hint \
${D}/sqlite3/sqlite3-debuginfo/sqlite3-debuginfo-3.8.1-1.tar.xz
D=http://dl.dropboxusercontent.com/u/69449580/Cygwin
wget -x -nH --cut-dirs=3 \
${D}/sqlite3/setup.hint \
${D}/sqlite3/sqlite3-3.8.1-1.tar.xz \
${D}/sqlite3/sqlite3-3.8.1-1-src.tar.xz \
${D}/sqlite3/libsqlite3_0/setup.hint \
${D}/sqlite3/libsqlite3_0/libsqlite3_0-3.8.1-1.tar.xz \
${D}/sqlite3/libsqlite3-devel/setup.hint \
${D}/sqlite3/libsqlite3-devel/libsqlite3-devel-3.8.1-1.tar.xz \
${D}/sqlite3/sqlite3-debuginfo/setup.hint \
${D}/sqlite3/sqlite3-debuginfo/sqlite3-debuginfo-3.8.1-1.tar.xz
--
Jan Nijtmans jan.nijtm...@gmail.com
Re: [ITA] sqlite3
2013/11/13 Christopher Faylor: On Wed, Nov 13, 2013 at 04:03:40PM +0100, Jan Nijtmans wrote: I would like to adopt sqlite3. I've packaged the latest release. I don't think the package is in need of adoption. Warren Young is still around and active, AFAICT. cgf Yes, he is! I'm waiting for his endorsement mail, because actually he is the one who proposed this adoption to me. I will do my best to be a good package maintainer for sqlite, but I hope you can forgive any beginners mistakes I might make. With your help I think everything will be OK. Regards, Jan Nijtmans
