Re: [ITA] ruby-sqlite3 1.6.3
On 26.05.2023 05:31, Daisuke Fujimura via Cygwin-apps wrote: Hello, Cygportfile: - https://cygwin.com/cgit/cygwin-packages/playground/tree/?h=ruby-sqlite3 Packages, logs: - https://github.com/cygwin/scallywag/actions/runs/5086092688 changed maintainer
[ITA] ruby-sqlite3 1.6.3
Hello, Cygportfile: - https://cygwin.com/cgit/cygwin-packages/playground/tree/?h=ruby-sqlite3 Packages, logs: - https://github.com/cygwin/scallywag/actions/runs/5086092688 ruby-sqlite3.cygport.diff Description: Binary data
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 > > > >
ATTN Maintainer : sqlite3 update ?
Hi Jan, could you update the package to last version ? Regards Marco
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: cygwin64-sqlite3 obsolete?
On Feb 5 09:13, Jan Nijtmans wrote: 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? If no other maintainer needs the package to cross build 64 bit packages against sqlite3 on 32 bit, I see no problem to remove them. So, here's the question; Is there any maintainer in need of a sqlite cross build package to build his packages? And then there is python. Jason, are you set up to build 64 bit packages yet? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp7lfn9Ftmmy.pgp Description: PGP signature
Re: cygwin64-sqlite3 obsolete?
On Wed, Feb 05, 2014 at 10:29:25AM +0100, Corinna Vinschen wrote: And then there is python. Jason, are you set up to build 64 bit packages yet? Yes. Jason
Re: [ITA] tcl-sqlite3
On Jan 20 10:37, Jan Nijtmans wrote: 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. [etc] Please, who uploaded the tcl-sqlite3-3.8.3-1 package? It is broken, because it's missing its source package. There's no matching sqlite3-3.8.3-1-src.tar.xz file. We're now constantly getting an upset message warning about this. For now, I moved the tcl-sqlite3-3.8.3-1.tar.xz packages out of the release areas. Please make sure to provide only subpackages for which the matching source package is available, too. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpbPfqzhtWPN.pgp Description: PGP signature
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
On Tue, Jan 21, 2014 at 03:07:28PM +0100, Jan Nijtmans wrote: 2014/1/21 Corinna Vinschen: Please make sure to provide only subpackages for which the matching source package is available, too. Thank you, I didn't know that. My apologies! You didn't know that the source package has to exist? It's a free software project. I also added a '!email' file for you so that you can share in the fun of getting upset messages.
Re: [ITA] 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
On 2014-01-15 03:12, Jan Nijtmans wrote: 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. 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 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. 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. Also, you also clobbered the upstream README with a Cygwin-specific one; please don't do that. 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. Huh? setup will remove the previous version before installing the newer one anyway. 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. No one's talking about patching Tcl. The OOTB default works as well, and doesn't pollute a directory which is currently used solely for the standard library. TEA (without full-version): TM (Tcl module new style): My suggestion (looks like Fedora's sqlite-tcl package): If it works, don't fix it. IMO we should let TEA do its thing. And who can add the tcl-sqlite3 package to cygwin-pkg-maint? That's not necessary, as it will have an external-source: sqlite3. Yaakov
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
Hi Jan, On Jan 13 11:57, Jan Nijtmans wrote: 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! 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. I really don't quite grok the directory layout and the naming. 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: - As a tcl package the shared lib should be under /usr/lib/tcl8.5 - The subdir and the shared lib shouldn't have the *exact* name of the sqlite version, otherwise they don't make sense anymore if sqlite gets updated to, say, 3.8.3. Warren and Yaakov, what are you saying as sqlite and tcl maintainers? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpvD6Ad0PNz5.pgp Description: PGP signature
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
On Jan 14 13:15, Jan Nijtmans wrote: 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. 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. 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. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpY1AoJorkSD.pgp Description: PGP signature
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
Re: [ITA] tcl-sqlite3
On Jan 14 16:50, Jan Nijtmans wrote: 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? That looks good to me, but I'm not a tcl expert. And, having said that, I'm wondering why Cygwin has two dirs: /usr/lib/tcl8.5 /usr/lib/tcl8 with the latter having two subdirs, 8.4 and 8.5. What's the deal here? Warren and Yaakov, what are you saying as sqlite and tcl maintainers? I'd still love to have some more feedback from Warren and Yaakov... Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpKxiVe_msE_.pgp Description: PGP signature
Re: [ITA] tcl-sqlite3
On 2014-01-14 03:55, Corinna Vinschen wrote: 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, Yes, that's the default TEA layout. but it's bound against sqlite-3.7.15.2, so it probably won't work with recent sqlite versions anyway. It should still work, it just won't have bindings for the newest features in sqlite-3.8.x. I really don't quite grok the directory layout and the naming. 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: - As a tcl package the shared lib should be under /usr/lib/tcl8.5 Not necessarily. Packages built with Tcl stubs are not linked to libtcl8.5 and should be compatible with any (at least newer) version of Tcl without having to be rebuilt. - The subdir and the shared lib shouldn't have the *exact* name of the sqlite version, otherwise they don't make sense anymore if sqlite gets updated to, say, 3.8.3. Tcl extensions are loaded via pkgIndex.tcl, so the module name itself is irrelevant. Yaakov
Re: [ITA] tcl-sqlite3
On 2014-01-14 10:45, Corinna Vinschen wrote: And, having said that, I'm wondering why Cygwin has two dirs: /usr/lib/tcl8.5 /usr/lib/tcl8 with the latter having two subdirs, 8.4 and 8.5. What's the deal here? There are two different ways of providing tcl extensions, packages and modules, the latter being new in 8.5 but AFAICS hasn't taken off. You can read more about them here: http://wiki.tcl.tk/37432 http://wiki.tcl.tk/12999 Yaakov
Re: [ITA] tcl-sqlite3
On 2014-01-14 09:50, Jan Nijtmans wrote: 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? /usr/lib/tcl8.x is for the Tcl standard library; I don't think that other packages -- particularly those that aren't actually dependent on a particular version of Tcl -- belong there. Yaakov
Re: [ITA] tcl-sqlite3
On Jan 14 13:30, Yaakov (Cygwin/X) wrote: On 2014-01-14 10:45, Corinna Vinschen wrote: And, having said that, I'm wondering why Cygwin has two dirs: /usr/lib/tcl8.5 /usr/lib/tcl8 with the latter having two subdirs, 8.4 and 8.5. What's the deal here? There are two different ways of providing tcl extensions, packages and modules, the latter being new in 8.5 but AFAICS hasn't taken off. You can read more about them here: http://wiki.tcl.tk/37432 http://wiki.tcl.tk/12999 Ok, thanks. Apart from that, would you mind to review the package and give a GTG (or not)? I'm just not feeling savvy enough, neither in tcl nor in sqlite. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpKyxdhSF7st.pgp Description: PGP signature
Re: [ITA] tcl-sqlite3
On 1/14/2014 05:44, Corinna Vinschen wrote: 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. Yaakov makes a good point: the whole idea of tcl-sqlite is that it wraps the SQLite 3 API exactly, so when new public APIs get exported by SQLite, new APIs appear in the Tcl wrapper. Therefore, a new version of tcl-sqlite really *could* depend on a specific version of SQLite, if the API changed.
Re: [ITA] tcl-sqlite3
On 1/13/2014 03:57, Jan Nijtmans wrote: I assume someone (other than Warren Young) uploaded it as part of the Cygwin64 bootstrap process. Yep, not me. Probably Yaakov. I'm not sure if a GTG is needed from another package maintainer, If you've written a new .cygport file, I think you should seek a GTG. A second pair of eyeballs can't hurt. otherwise Warren Young would be the most logical choice. Not really. I've never used tcl-sqlite, and I haven't used Tcl in at least a dozen years.
Re: [ITA] tcl-sqlite3
On Jan 14 13:34, Warren Young wrote: On 1/14/2014 05:44, Corinna Vinschen wrote: 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. Yaakov makes a good point: the whole idea of tcl-sqlite is that it wraps the SQLite 3 API exactly, so when new public APIs get exported by SQLite, new APIs appear in the Tcl wrapper. Therefore, a new version of tcl-sqlite really *could* depend on a specific version of SQLite, if the API changed. In how far does that affect the filename? We're adding new APIs to Cygwin all the time, but the DLL is still called cygwin1.dll. And that's how it works for any other DLL as well as long as it doesn't break backward compatibility, API-wise. It's your and Yaakov's call eventually, so I retract all my idle musings in terms of the file or directory names. Just let Jan know how you want to have it. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpHaFwmtIswH.pgp Description: PGP signature
Re: [ITA] tcl-sqlite3
On 2014-01-14 14:52, Corinna Vinschen wrote: In how far does that affect the filename? We're adding new APIs to Cygwin all the time, but the DLL is still called cygwin1.dll. And that's how it works for any other DLL as well as long as it doesn't break backward compatibility, API-wise. This is a loadable module, not a link library, and unlike other language interpreters which load extensions directly based on file name, Tcl package-type extensions are loaded based on a metadata file (pkgIndex.tcl). It is actually typical of Tcl extensions to be versioned in this way. Yaakov
Re: [ITA] tcl-sqlite3
On 2014-01-14 13:49, Corinna Vinschen wrote: Ok, thanks. Apart from that, would you mind to review the package and give a GTG (or not)? I'm just not feeling savvy enough, neither in tcl nor in sqlite. I don't see any links to a -src package, or better yet, a URL to the .cygport and patches (if any). Yaakov
[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
Re: [ITA] sqlite3
On 11/14/2013 12:27, Christopher Faylor wrote: Jan, if you can send the information at the above link now, you'll be GTG for uploading as soon as the package has been pronounced GTG by Warrent. Jan sent me a link to his proposed packages, which I looked at briefly, but they've disappeared. What I saw of the tarball contents looked good, but I didn't actually install and exercise packages here. Jan, will you please put the package tarballs you intend to upload on a public file server somewhere? You can send the link directly to me, or post it in reply to this thread. I'll want to test both 32- and 64-bit versions. Don't worry about the tclsqlite package at this point. There's no reason that should hold up the main packages.
Re: [ITA] sqlite3
On 11/15/2013 06:38, Warren Young wrote: On 11/14/2013 12:27, Christopher Faylor wrote: Jan, if you can send the information at the above link now, you'll be GTG for uploading as soon as the package has been pronounced GTG by Warrent. GTG. I tested by unpacking the 3 main packages (exe, lib, and -devel), examining the file list, running the exe, and running svn to make sure it loaded the DLL correctly. I had to rebase on 32-bit, but that's probably not surprising since I did a manual install. Jan, some nits to take care of in the next sqlite3.README file: - It still mentions lemon3.exe. - I wasn't the maintainer of all prior versions of Cygwin SQLite. I started with 3.5.8. I don't remember who the prior maintainer of the official Cygwin SQLite package was. From the port notes, I started from Yaakov's Cygwin Ports version, but it was someone else's package I was replacing in the official distro. - Typo: idential - identical Also, when you post your cygwin-announce message, be sure to describe the new VFS switching mechanism. One of the READMEs should describe this Cygwin-specific environment variable in some detail, too.
Re: [ITA] sqlite3
On Nov 13 16:05, Warren Young wrote: On 11/13/2013 08:18, Christopher Faylor wrote: 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. Jan has been the driving force behind fixing the problems that prevented a simple update from SQLite 3.7.x to 3.8 on Cygwin. (3.8 is a big upstream release, and they broke a lot of things on Cygwin, since it isn't a primary deployment platform for them.) The only reason I adopted this package in the first place is that the previous maintainer disappeared, and it was about to be removed from the distribution. I just stepped in to rescue it. I have never actually *used* SQLite on Cygwin, other than testing; Cygwin SQLite has never been my itch. I expect Jan to be a better SQLite package adoptive parent than I was. Via private email and on the SQLite list, I've been explaining the whys and wherefores of the current Cygwin SQLite package to Jan and others. I don't intend to disappear entirely from the SQLite world, but I think most of the knowledge transfer has already happened. Ok, thanks for clarifying, Warren. Jan, please see https://sourceware.org/cygwin-apps/package-upload.html for how to request upload privileges and how to upload, once you got your GTG for the package, which AFAICS, Warren would be the right guy to do. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpgBkl2aVEPx.pgp Description: PGP signature
Re: [ITA] sqlite3
On Thu, Nov 14, 2013 at 10:47:51AM +0100, Corinna Vinschen wrote: Jan, please see https://sourceware.org/cygwin-apps/package-upload.html for how to request upload privileges and how to upload, once you got your GTG for the package, which AFAICS, Warren would be the right guy to do. Jan has an upload directory on cygwin.com now. Jan, if you can send the information at the above link now, you'll be GTG for uploading as soon as the package has been pronounced GTG by Warrent. cgf
Re: [ITA] sqlite3
On Thu, Nov 14, 2013 at 02:27:51PM -0500, Christopher Faylor wrote: On Thu, Nov 14, 2013 at 10:47:51AM +0100, Corinna Vinschen wrote: Jan, please see https://sourceware.org/cygwin-apps/package-upload.html for how to request upload privileges and how to upload, once you got your GTG for the package, which AFAICS, Warren would be the right guy to do. Jan has an upload directory on cygwin.com now. Jan, if you can send the information at the above link now, you'll be GTG for uploading as soon as the package has been pronounced GTG by Warrent. i.e., Warren cgf
[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
On Wed, Nov 13, 2013 at 04:03:40PM +0100, Jan Nijtmans wrote: I would like to adopt sqlite3. I've packaged the latest release. I don't think the package is in need of adoption. Warren Young is still around and active, AFAICT. cgf
Re: [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
Re: [ITA] sqlite3
On 11/13/2013 08:18, Christopher Faylor wrote: 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. Jan has been the driving force behind fixing the problems that prevented a simple update from SQLite 3.7.x to 3.8 on Cygwin. (3.8 is a big upstream release, and they broke a lot of things on Cygwin, since it isn't a primary deployment platform for them.) The only reason I adopted this package in the first place is that the previous maintainer disappeared, and it was about to be removed from the distribution. I just stepped in to rescue it. I have never actually *used* SQLite on Cygwin, other than testing; Cygwin SQLite has never been my itch. I expect Jan to be a better SQLite package adoptive parent than I was. Via private email and on the SQLite list, I've been explaining the whys and wherefores of the current Cygwin SQLite package to Jan and others. I don't intend to disappear entirely from the SQLite world, but I think most of the knowledge transfer has already happened.
Re: sqlite3
On 8/22/2013 23:54, Michael DeByl wrote: Sorry to be a pain Well, here's your pain returned: This should be on the main Cygwin mailing list, not the -apps list. :) (This list is for discussing the *packaging* of the Cygwin apps you use, not for discussing the use of them.) But since I dislike chasing threads across lists, I'll reply here. SQLite header and source version mismatch 2013-05-20 00:56:22 118a3b35693b134d56ebd780123b7fd6f1497668 2013-04-12 11:52:43 cbea02d93865ce0e06789db95fd9168ebac970c7 Please post your cygcheck output per http://cygwin.com/problems.html to the main list. Also, what does 'type -a sqlite3' say? Feel free to start a new thread on the main list with the answers. it seems like one would expect it to work as packaged. Well, seeing as how this the the first such complaint I've received about SQLite3 3.7.17-3, which has been the current version for over 2 months now, I'd say it probably does work as packaged. Something is odd about your particular machine. The cygcheck output should help us figure out what that peculiarity is.
Re: sqlite3
Hi all Sorry to be a pain - but just used the installer to grab sqlite3 so I could use the command line tool, however when running it I get: SQLite header and source version mismatch 2013-05-20 00:56:22 118a3b35693b134d56ebd780123b7fd6f1497668 2013-04-12 11:52:43 cbea02d93865ce0e06789db95fd9168ebac970c7 Oh noes! On linux i'd know what to do, but I am a total cygwin noob, and it seems like one would expect it to work as packaged. Please let me know if there's anything I can do to help. --Michael
Re: [RFU 64-bit] sqlite3-3.7.17-3
On Jul 25 23:14, Warren Young wrote: Leave 3.7.16.2-1 as curr. 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/cygwin64/sqlite3/ (These are the same as the 32-bit packages, released over a month ago. I just forgot to do the 64-bit ones after I decided to promote the test packages to curr.) Uploaded. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
[RFU 64-bit] sqlite3-3.7.17-3
Leave 3.7.16.2-1 as curr. 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/cygwin64/sqlite3/ (These are the same as the 32-bit packages, released over a month ago. I just forgot to do the 64-bit ones after I decided to promote the test packages to curr.)
Re: [RFU] sqlite3-3.7.17-3
On Jun 13 16:54, Warren Young wrote: Would someone flip this package from test to curr for me, please? Leave 3.7.16.2-1 as prev. Done. Do you want to keep 3.7.13-1? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
Re: [RFU] sqlite3-3.7.17-3
On 6/14/2013 01:54, Corinna Vinschen wrote: On Jun 13 16:54, Warren Young wrote: Would someone flip this package from test to curr for me, please? Leave 3.7.16.2-1 as prev. Done. Thanks! Do you want to keep 3.7.13-1? I didn't know I could have more than one prev. Sure, let's keep it a while. Just in this past week, I got a complaint about one of the changes in .16.2 relative to .13, so it's conceivable some may want to step back two steps if .17 doesn't work out for everyone.
Re: [RFU] sqlite3-3.7.17-3
Would someone flip this package from test to curr for me, please? Leave 3.7.16.2-1 as prev.
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] sqlite3-3.7.17-3
On 6/11/2013 01:37, marco atzeri wrote: you should make it test adding the relevant prev/current/test entries as specified on http://cygwin.com/setup.html Is there a way to set this via the .cygport file? I tried searching its HTML manual, and didn't find one. The alternative is to manually adjust the generated .hint files on test releases on my end.
Re: [RFU] sqlite3-3.7.17-3
On 6/11/2013 10:10 AM, Warren Young wrote: On 6/11/2013 01:37, marco atzeri wrote: you should make it test adding the relevant prev/current/test entries as specified on http://cygwin.com/setup.html Is there a way to set this via the .cygport file? I tried searching its HTML manual, and didn't find one. The alternative is to manually adjust the generated .hint files on test releases on my end. David Rothenberger submitted a patch for cygport to this list on 6/2, to add that feature. Don't know if Yaakov incorporated it or not, but you could locally patch your cygport if you wanted. -- Chuck
[RFU] sqlite3-3.7.17-3
Leave 3.7.16.2-1 as curr, and make this test only for now. (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/
Re: [RFU 64bit] sqlite3-3.7.16.2-1
On Apr 18 09:17, Corinna Vinschen wrote: On Apr 17 15:00, Warren Young wrote: From within release/sqlite3: wget -e robots=off --cut-dirs=2 -np -nH -A'*3.7.16.2-1*' -A'*.hint' \ -r http://etr-usa.com/cygwin64/sqlite3/ Uploaded. Just a tiny hiccup: The sqlite3 package has libncurses10 in the requires line, but the 64bit release only provides libncursesw10. Just, FYI. Yaakov fixed that on cygwin.com. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
Re: [RFU 64bit] sqlite3-3.7.16.2-1
On 4/19/2013 03:32, Corinna Vinschen wrote: Just a tiny hiccup: The sqlite3 package has libncurses10 in the requires line, but the 64bit release only provides libncursesw10. Just, FYI. Yaakov fixed that on cygwin.com. I've fixed this by making use of Cygport's new setup.hint generation feature, specifically its ability to build the requires line automatically. I moved to this new feature for this package release, but I copied over the requirements from my hand-written hint files. I just removed the REQUIRES lines and verified that Cygport does the right thing here. The automatic dependency generation doesn't include ncurses explicitly, but it does include readline which depends on ncurses. I expect setup.exe will follow the dependency chain correctly.
Re: [RFU 64bit] sqlite3-3.7.16.2-1
On Apr 17 15:00, Warren Young wrote: From within release/sqlite3: wget -e robots=off --cut-dirs=2 -np -nH -A'*3.7.16.2-1*' -A'*.hint' \ -r http://etr-usa.com/cygwin64/sqlite3/ Uploaded. Thanks a lot, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
Re: [RFU 32bit] sqlite3-3.7.16.2-1
On Apr 16 11:30, Warren Young wrote: Leave 3.7.13-1 as prev, and remove 3.7.3. From within release/sqlite3: wget -e robots=off --cut-dirs=2 -np -nH -A'*3.7.16.2-1*' -A'*.hint' \ -r http://etr-usa.com/cygwin/sqlite3/ Uploaded. (I'm including the *hint files this time, Corinna. :) ) Good idea ;) Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
[RFU 64bit] sqlite3-3.7.16.2-1
From within release/sqlite3: wget -e robots=off --cut-dirs=2 -np -nH -A'*3.7.16.2-1*' -A'*.hint' \ -r http://etr-usa.com/cygwin64/sqlite3/
[RFU 32bit] sqlite3-3.7.16.2-1
Leave 3.7.13-1 as prev, and remove 3.7.3. From within release/sqlite3: wget -e robots=off --cut-dirs=2 -np -nH -A'*3.7.16.2-1*' -A'*.hint' \ -r http://etr-usa.com/cygwin/sqlite3/ (I'm including the *hint files this time, Corinna. :) )
Re: sqlite3-3.7.15-1 test packages
On 11/21/2012 12:01, Achim Gratz wrote: FWIW, I think Yaakov is more immediately concerned about the additional API: -DSQLITE_ENABLE_COLUMN_METADATA\ -DSQLITE_ENABLE_FTS3 -DSQLITE_ENABLE_FTS_PARENTHESIS\ -DSQLITE_ENABLE_FTS4 I've made some SQLite 3.7.15.1-1 packages, and put them up for testing: http://etr-usa.com/cygwin/sqlite3/libsqlite3-devel-3.7.15.1-1.tar.bz2 http://etr-usa.com/cygwin/sqlite3/libsqlite3_0-3.7.15.1-1.tar.bz2 http://etr-usa.com/cygwin/sqlite3/sqlite3-3.7.15.1-1-src.tar.bz2 http://etr-usa.com/cygwin/sqlite3/sqlite3-3.7.15.1-1.tar.bz2 These packages enable the requested build options. *Plus*, they attempt to work around at least one of the problems that lead us to try building SQLite in Unix mode on Cygwin in the first place. Instead of a wholesale Unix mode switch, we only do temporary directory selection in a Unix way instead of asking Windows for a temporary directory, which is often not user-writeable when the user is not an admin. This certainly tries to address Daniel Colascione's reported problem, and may address Achim Gratz' original problem, too. This required a fairly ugly hack to the SQLite code, so I'm not even going to consider posting an RFU message for these packages until I get some positive feedback from those affected.
Re: [RFU] sqlite3-3.7.13.1-1 (test to prev promotion)
On Aug 16 04:38, Warren Young wrote: Please remove the 3.7.12.1-1 packages. Also, run this from 'release' to replace the setup.hint files with versions without 'prev', 'curr' and 'test' directives: wget -e robots=off -X from-box --cut-dirs=1 -np -nH \ -A'setup.hint' -r http://etr-usa.com/cygwin/sqlite3/ I don't see any reason to build -2 packages. The existing ones are fine already. They just need to be promoted to curr. Done. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [RFU] sqlite3-3.7.13.1-1 (test to prev promotion)
Please remove the 3.7.12.1-1 packages. Also, run this from 'release' to replace the setup.hint files with versions without 'prev', 'curr' and 'test' directives: wget -e robots=off -X from-box --cut-dirs=1 -np -nH \ -A'setup.hint' -r http://etr-usa.com/cygwin/sqlite3/ I don't see any reason to build -2 packages. The existing ones are fine already. They just need to be promoted to curr.
Re: [RFU] sqlite3-3.7.13.1-1 (test to prev promotion)
On Aug 16 04:38, Warren Young wrote: Please remove the 3.7.12.1-1 packages. Also, run this from 'release' to replace the setup.hint files with versions without 'prev', 'curr' and 'test' directives: wget -e robots=off -X from-box --cut-dirs=1 -np -nH \ -A'setup.hint' -r http://etr-usa.com/cygwin/sqlite3/ I don't see any reason to build -2 packages. The existing ones are fine already. They just need to be promoted to curr. Hang on. I just replied on the Cygwin ML. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [RFU] sqlite3-3.7.13.1-1
On Aug 8 13:38, Warren Young wrote: On 8/8/2012 9:40 AM, Corinna Vinschen wrote: On Aug 6 20:06, Warren Young wrote: $ cd .../release $ wget -e robots=off -X from-box --cut-dirs=1 -np -nH -A'*3.7.13-1*' \ -r http://etr-usa.com/cygwin/sqlite3/ That should populate the release/sqlite3 sub-tree correctly. Not entirely. The new sqlite3-debuginfo package just lingers in the top-level sqlite3 directory. It's supposed to go into its own sqlite3-debuginfo subdir with its own setup.hint file, which has been generated by cygport (should be under dist/sqlite3/sqlite3-debuginfo). Okay, thanks for the clues. I've fixed this. It's automated on my end now, so it shouldn't happen again. Why don't you create custom setup.hint files with prev, curr and test entries, so that the new 3.7.13-1 is test for now? Done. New wget command, to slurp setup.hint files, too: wget -e robots=off -X from-box --cut-dirs=1 -np -nH \ -A'*3.7.13-1*,setup.hint' -r http://etr-usa.com/cygwin/sqlite3/ Uploaded. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [RFU] sqlite3-3.7.13.1-1
On Aug 6 20:06, Warren Young wrote: $ cd .../release $ wget -e robots=off -X from-box --cut-dirs=1 -np -nH -A'*3.7.13-1*' \ -r http://etr-usa.com/cygwin/sqlite3/ That should populate the release/sqlite3 sub-tree correctly. Not entirely. The new sqlite3-debuginfo package just lingers in the top-level sqlite3 directory. It's supposed to go into its own sqlite3-debuginfo subdir with its own setup.hint file, which has been generated by cygport (should be under dist/sqlite3/sqlite3-debuginfo). Please leave both 3.7.12-1 *and* 3.7.3-1 as prev, if that's possible. I don't want 3.7.3-1 dropped until I'm sure this version fixes the svn disk I/O error. (At that point, we can drop .12 as well.) If I can have only one, I'd prefer to keep 3.7.3-1. You can have only one, unfortunately. It's no problem to keep old versions around, but they won't be accessible via setup. Why don't you create custom setup.hint files with prev, curr and test entries, so that the new 3.7.13-1 is test for now? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [RFU] sqlite3-3.7.13.1-1
On 8/8/2012 9:40 AM, Corinna Vinschen wrote: On Aug 6 20:06, Warren Young wrote: $ cd .../release $ wget -e robots=off -X from-box --cut-dirs=1 -np -nH -A'*3.7.13-1*' \ -r http://etr-usa.com/cygwin/sqlite3/ That should populate the release/sqlite3 sub-tree correctly. Not entirely. The new sqlite3-debuginfo package just lingers in the top-level sqlite3 directory. It's supposed to go into its own sqlite3-debuginfo subdir with its own setup.hint file, which has been generated by cygport (should be under dist/sqlite3/sqlite3-debuginfo). Okay, thanks for the clues. I've fixed this. It's automated on my end now, so it shouldn't happen again. Why don't you create custom setup.hint files with prev, curr and test entries, so that the new 3.7.13-1 is test for now? Done. New wget command, to slurp setup.hint files, too: wget -e robots=off -X from-box --cut-dirs=1 -np -nH \ -A'*3.7.13-1*,setup.hint' -r http://etr-usa.com/cygwin/sqlite3/
[RFU] sqlite3-3.7.13.1-1
$ cd .../release $ wget -e robots=off -X from-box --cut-dirs=1 -np -nH -A'*3.7.13-1*' \ -r http://etr-usa.com/cygwin/sqlite3/ That should populate the release/sqlite3 sub-tree correctly. Please leave both 3.7.12-1 *and* 3.7.3-1 as prev, if that's possible. I don't want 3.7.3-1 dropped until I'm sure this version fixes the svn disk I/O error. (At that point, we can drop .12 as well.) If I can have only one, I'd prefer to keep 3.7.3-1.
Re: [RFU] sqlite3-3.7.12.1-1
On Jun 4 23:50, Warren Young wrote: wget -e robots=off --cut-dirs=2 -np -nH -A'*3.7.12.1-1*' -r \ http://etr-usa.com/cygwin/sqlite3/ Please leave 3.7.3-1 as prev. Done. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
[RFU] sqlite3-3.7.12.1-1
wget -e robots=off --cut-dirs=2 -np -nH -A'*3.7.12.1-1*' -r \ http://etr-usa.com/cygwin/sqlite3/ Please leave 3.7.3-1 as prev.
Re: sqlite3: please update [RFU]
On 11/30/2010 12:00 PM, Corinna Vinschen wrote: On Nov 4 15:07, Yaakov S wrote: On Sun, 2010-10-03 at 02:04 -0500, Yaakov (Cygwin/X) wrote: Cygwin's sqlite3 (3.6.21) is ten months old, and some current software already needs more recent versions. Could you please update sqlite3 to the latest upstream release (currently 3.7.2)? Ping? KDE 4.5 requires a newer sqlite3, and I'd like to avoid another colliding package in Ports. Warren? You still with us? Yes, sorry, I missed the original request. wget -e robots=off --cut-dirs=2 -np -nH -A'*3.6.21-3*' -r \ http://etr-usa.com/cygwin/sqlite3/ FWIW, sqlite3 is one of several packages I'm maintaining only because I know what it's supposed to do and so can verify correct operation, not because I actually use it under Cygwin. If someone with better motivation wants to maintain it, they're welcome to take over.
Re: sqlite3: please update [RFU]
On 12/1/2010 6:58 AM, Warren Young wrote: wget -e robots=off --cut-dirs=2 -np -nH -A'*3.6.21-3*' -r \ http://etr-usa.com/cygwin/sqlite3/ Grr... wget -e robots=off --cut-dirs=2 -np -nH -A'*3.7.3-1*' -r \ http://etr-usa.com/cygwin/sqlite3/
Re: sqlite3: please update [RFU]
On Dec 1 07:00, Warren Young wrote: On 12/1/2010 6:58 AM, Warren Young wrote: wget -e robots=off --cut-dirs=2 -np -nH -A'*3.6.21-3*' -r \ http://etr-usa.com/cygwin/sqlite3/ Grr... wget -e robots=off --cut-dirs=2 -np -nH -A'*3.7.3-1*' -r \ http://etr-usa.com/cygwin/sqlite3/ Thanks, uploaded. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: sqlite3: please update
On Nov 4 15:07, Yaakov S wrote: On Sun, 2010-10-03 at 02:04 -0500, Yaakov (Cygwin/X) wrote: Cygwin's sqlite3 (3.6.21) is ten months old, and some current software already needs more recent versions. Could you please update sqlite3 to the latest upstream release (currently 3.7.2)? Ping? KDE 4.5 requires a newer sqlite3, and I'd like to avoid another colliding package in Ports. Warren? You still with us? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Updated: sqlite3-3.6.21-3
The previous -2 release had a completely wrong source patch relative to the original sources, which caused it to be all but useless. Thus, everyone who got the -2 should upgrade.
Re: Updated: sqlite3-3.6.21-3
Sorry wrong list. I'm on a *roll* this week...
Re: [RFU] sqlite3-3.6.2-1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Warren Young on 9/9/2008 12:44 PM: Now there's a thread on the main Cygwin list about people needing a static version of libsqlite3 to link against Python. (Irony...) These packages include both versions. I hope they pass this time. Due to the spotty maintainership and rough change-over, this is a pretty big jump over the current stuff on the mirrors. Uploaded. Igor, can we get a gold star over here? - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjOVEAACgkQ84KuGfSFAYDJiQCeN2fN6CCLRdbrO9A9uagBhz3c OFcAoMUWq/BLMH2lVBVDkRyH6VJ4HKTa =QO1Q -END PGP SIGNATURE-
[RFU] sqlite3-3.6.2-1
A bit of history: Back in May, Max Bowsher gave up maintainership of a bunch of packages. I adopted a few of them, and released sqlite3-3.5.8-1. There was some concern about the fact that my package didn't ship with a DLL version of the library, only a static library. I got comments from Dr. Zell on how to fix it, but did nothing more about it, since I didn't think a DLL was really necessary. It's the sort of library best linked statically. Apparently I was perceived as dropping the ball, because Max's last packages are still on the mirrors. Now there's a thread on the main Cygwin list about people needing a static version of libsqlite3 to link against Python. (Irony...) These packages include both versions. I hope they pass this time. Due to the spotty maintainership and rough change-over, this is a pretty big jump over the current stuff on the mirrors. executables: http://etr-usa.com/cygwin/sqlite3/setup.hint http://etr-usa.com/cygwin/sqlite3/sqlite3-3.6.2-1.tar.bz2 shared library: http://etr-usa.com/cygwin/sqlite3/lib.hint http://etr-usa.com/cygwin/sqlite3/libsqlite3_0-3.6.2-1.tar.bz2 devel stuff: http://etr-usa.com/cygwin/sqlite3/devel.hint http://etr-usa.com/cygwin/sqlite3/libsqlite3-devel-3.6.2-1.tar.bz2 sources: http://etr-usa.com/cygwin/sqlite3/sqlite3-3.6.2-1-src.tar.bz2
Re: [RFU] sqlite3-3.5.8-1
Dr. Volker Zell wrote: usr/bin/lemon3.exe Isn't this the parser-generator needed only for the build itself? -- Lapo Luchini - http://lapo.it/ “Gentlemen do not read each others mail.” (Henry Lewis Stimson)
Re: [RFU] sqlite3-3.5.8-1
Lapo Luchini wrote: Dr. Volker Zell wrote: usr/bin/lemon3.exe Isn't this the parser-generator needed only for the build itself? It's possible that some SQLite users have come to rely on it, assuming it will be available. It's not entirely an internal use only tool; it has its own web page: http://www.hwaci.com/sw/lemon/ Options: 1. leave it in 2. remove it; if someone complains, revisit the question 3. make a separate package for it
Re: [RFU] sqlite3-3.5.8-1
Dr. Volker Zell wrote: When building and packaging with your .cygport file I do not get shared libs. It may not be possible. It's set to try to build shared libraries, but you get this during the build: libtool: link: warning: undefined symbols not allowed in i686-pc-cygwin shared libraries I seem to recall seeing a thread about this many moons ago that said there was no workaround to this short of changing the source code to avoid the need for undefined symbols. I don't see much incentive to do this, though, because SQLite is public domain, and relatively small. The intent of the library is to embed it deeply in your program for use as low-level infrastructure. It's not really meant to be upgraded separately from the program that uses it. Is it possible that your .src patch is missing ? No source patches are necessary. It builds perfectly OOTB.
Re: [RFU] sqlite3-3.5.8-1
Warren Young writes:
Dr. Volker Zell wrote:
When building and packaging with your .cygport file I do not get
shared
libs.
It may not be possible. It's set to try to build shared libraries,
but you get this during the build:
libtool: link: warning: undefined symbols not allowed in
i686-pc-cygwin shared libraries
I seem to recall seeing a thread about this many moons ago that said
there was no workaround to this short of changing the source code to
avoid the need for undefined symbols.
I don't see much incentive to do this, though, because SQLite is
public domain, and relatively small. The intent of the library is to
embed it deeply in your program for use as low-level infrastructure.
It's not really meant to be upgraded separately from the program that
uses it.
Is it possible that your .src patch is missing ?
No source patches are necessary. It builds perfectly OOTB.
Try the following:
-- cut here
diff -urN -x CYGWIN-PATCHES -x 'aclocal.m4*' -x autom4te.cache -x config.cache
-x config.log -x config.status -x config.h -x config.h.in -x ABOUT-NLS -x
Makefile.in.in -x Makevars.template -x '*SlackBuild*' -x '*.egg-info' -x
'*.class' -x '*.pyc' -x '*.mo' -x '*.gmo' -x at-3.1.8-31.install.orig -x
hdf5-1.6.7-1.src.patch.orig -x libmad-0.15.1b-1.sh.orig -x
libmcrypt-2.5.8-1.src.patch.orig -x postgresql-8.1.4-1.cygport.orig -x
rcs-5.7-4.src.patch.orig -x template-package.sh.orig -x '*.rej' -x '*.spec' -x
'*.temp' -x '*~' -x '*.stackdump' -x COPYING -x INSTALL -x compile -x
config-ml.in -x config.guess -x config.sub -x depcomp -x elisp-comp -x
install-sh -x libtool.m4 -x ltoptions.m4 -x ltsugar.m4 -x ltversion.m4 -x
'lt~obsolete.m4' -x ltmain.sh -x mdate-sh -x missing -x mkinstalldirs -x
py-compile -x symlink-tree -x texinfo.tex -x ylwrap -x config.rpath -x
configure -x omf.make -x xmldocs.make -x gnome-doc-utils.make -x
gnome-doc-utils.m4 -x intltool.m4 -x intltool-extract -x intltool-extract.in -x
intltool-merge -x intltool-merge.in -x intltool-update -x intltool-update.in
origsrc/sqlite-3.5.8/Makefile.in src/sqlite-3.5.8/Makefile.in
--- origsrc/sqlite-3.5.8/Makefile.in2008-04-14 02:49:45.0 +0200
+++ src/sqlite-3.5.8/Makefile.in2008-05-10 11:18:27.140625000 +0200
@@ -408,13 +408,13 @@
libsqlite3.la: $(LIBOBJ)
$(LTLINK) -o $@ $(LIBOBJ) $(TLIBS) \
- ${ALLOWRELEASE} -rpath $(libdir) -version-info 8:6:8
+ ${ALLOWRELEASE} -rpath $(libdir) -no-undefined -version-info
8:6:8
libtclsqlite3.la: tclsqlite.lo libsqlite3.la
$(LTLINK) -o $@ tclsqlite.lo \
- $(LIBOBJ) @TCL_STUB_LIB_SPEC@ $(TLIBS) \
+ $(LIBOBJ) @TCL_LIB_SPEC@ $(TLIBS) \
-rpath $(libdir)/sqlite \
- -version-info 8:6:8
+ -no-undefined -version-info 8:6:8
sqlite3$(TEXE):$(TOP)/src/shell.c libsqlite3.la sqlite3.h
$(LTLINK) $(READLINE_FLAGS) \
diff -urN -x CYGWIN-PATCHES -x 'aclocal.m4*' -x autom4te.cache -x config.cache
-x config.log -x config.status -x config.h -x config.h.in -x ABOUT-NLS -x
Makefile.in.in -x Makevars.template -x '*SlackBuild*' -x '*.egg-info' -x
'*.class' -x '*.pyc' -x '*.mo' -x '*.gmo' -x at-3.1.8-31.install.orig -x
hdf5-1.6.7-1.src.patch.orig -x libmad-0.15.1b-1.sh.orig -x
libmcrypt-2.5.8-1.src.patch.orig -x postgresql-8.1.4-1.cygport.orig -x
rcs-5.7-4.src.patch.orig -x template-package.sh.orig -x '*.rej' -x '*.spec' -x
'*.temp' -x '*~' -x '*.stackdump' -x COPYING -x INSTALL -x compile -x
config-ml.in -x config.guess -x config.sub -x depcomp -x elisp-comp -x
install-sh -x libtool.m4 -x ltoptions.m4 -x ltsugar.m4 -x ltversion.m4 -x
'lt~obsolete.m4' -x ltmain.sh -x mdate-sh -x missing -x mkinstalldirs -x
py-compile -x symlink-tree -x texinfo.tex -x ylwrap -x config.rpath -x
configure -x omf.make -x xmldocs.make -x gnome-doc-utils.make -x
gnome-doc-utils.m4 -x intltool.m4 -x intltool-extract -x intltool-extract.in -x
intltool-merge -x intltool-merge.in -x intltool-update -x intltool-update.in
origsrc/sqlite-3.5.8/tclinstaller.tcl src/sqlite-3.5.8/tclinstaller.tcl
--- origsrc/sqlite-3.5.8/tclinstaller.tcl 2008-03-14 19:01:53.0
+0100
+++ src/sqlite-3.5.8/tclinstaller.tcl 2008-05-10 11:20:41.43750 +0200
@@ -5,7 +5,7 @@
#tclsh tclinstaller.tcl 3.0
#
set VERSION [lindex $argv 0]
-set LIBFILE .libs/libtclsqlite3[info sharedlibextension]
+set LIBFILE .libs/cygtclsqlite3-0[info sharedlibextension]
if { ![info exists env(DESTDIR)] } { set env(DESTDIR) }
if { ![info exists env(TCLLIBDIR)] } { set env(TCLLIBDIR) [lindex $auto_path
0] }
set LIBDIR $env(DESTDIR)$env(TCLLIBDIR)
@@ -13,11 +13,12 @@
set LIBNAME [file tail $LIBFILE]
set LIB $LIBDIR/sqlite3/$LIBNAME
set LIB_INSTALL $LIBDIR_INSTALL/sqlite3/$LIBNAME
+set SQLLITELIB [lindex $auto_path 0]/sqlite3/$LIBNAME
file delete -force $LIBDIR
Re: [RFU] sqlite3-3.5.8-1
Warren Young writes: New maintainer, new upstream version, new packaging system. The problems that came up in the ITA thread of last week have been fixed. executables: http://etr-usa.com/cygwin/sqlite3/setup.hint http://etr-usa.com/cygwin/sqlite3/sqlite3-3.5.8-1.tar.bz2 shared library: http://etr-usa.com/cygwin/sqlite3/lib.hint http://etr-usa.com/cygwin/sqlite3/libsqlite3_0-3.5.8-1.tar.bz2 devel stuff: http://etr-usa.com/cygwin/sqlite3/devel.hint http://etr-usa.com/cygwin/sqlite3/libsqlite3-devel-3.5.8-1.tar.bz2 sources: http://etr-usa.com/cygwin/sqlite3/sqlite3-3.5.8-1-src.tar.bz2 When building and packaging with your .cygport file I do not get shared libs. Is it possible that your .src patch is missing ? Packaging sqlite3-3.5.8-1 Creating binary package(s) sqlite3-3.5.8-1.tar.bz2 usr/bin/lemon3.exe usr/bin/sqlite3.exe usr/share/ usr/share/doc/ usr/share/doc/Cygwin/ usr/share/doc/Cygwin/sqlite3-3.5.8.README usr/share/doc/sqlite3-3.5.8/ usr/share/doc/sqlite3-3.5.8/html/ usr/share/doc/sqlite3-3.5.8/html/lemon.html usr/share/doc/sqlite3-3.5.8/README usr/share/man/ usr/share/man/man1/ usr/share/man/man1/sqlite3.1.gz libsqlite3_0-3.5.8-1.tar.bz2 usr/lib/libsqlite3.a usr/lib/libsqlite3.la libsqlite3-devel-3.5.8-1.tar.bz2 usr/include/ usr/include/sqlite3.h usr/include/sqlite3ext.h usr/lib/pkgconfig/ usr/lib/pkgconfig/sqlite3.pc Ciao Volker
[RFU] sqlite3-3.5.8-1
New maintainer, new upstream version, new packaging system. The problems that came up in the ITA thread of last week have been fixed. executables: http://etr-usa.com/cygwin/sqlite3/setup.hint http://etr-usa.com/cygwin/sqlite3/sqlite3-3.5.8-1.tar.bz2 shared library: http://etr-usa.com/cygwin/sqlite3/lib.hint http://etr-usa.com/cygwin/sqlite3/libsqlite3_0-3.5.8-1.tar.bz2 devel stuff: http://etr-usa.com/cygwin/sqlite3/devel.hint http://etr-usa.com/cygwin/sqlite3/libsqlite3-devel-3.5.8-1.tar.bz2 sources: http://etr-usa.com/cygwin/sqlite3/sqlite3-3.5.8-1-src.tar.bz2
Re: [ITP] sqlite3
Max Bowsher wrote: Max Bowsher wrote: SQLite is a small C library that implements a self-contained, embeddable, zero-configuration SQL database engine. ... Updated to 3.3.17-1. The 3.3.14-0.1 packages were GTGed, so I'll upload in a few days if no one says differently. Uh, a few days became a few months owing to my forgetfulness, but new sqlite 3.5.1 is now uploaded. Max. signature.asc Description: OpenPGP digital signature
1.5.24 -2 cygwin python 2.5.1 problem, import sqlite3 fail
when i try to import sqlite3 in python, it results: ... File /usr/lib/python2.5/sqlite3/dbapi2.py from _sqlite3 import * ImportError: No module name _sqlite3 Actually, i can't find any modules named _sqlite3 in /usr/lib/python2.5/. How can i do? thanks find /usr/lib/python2.5/ -print | grep _sqlite3
Re: 1.5.24 -2 cygwin python 2.5.1 problem, import sqlite3 fail
On Sun, Nov 04, 2007 at 08:10:55PM +0800, Vincent Huang wrote: when i try to import sqlite3 in python, it results: ... File /usr/lib/python2.5/sqlite3/dbapi2.py from _sqlite3 import * ImportError: No module name _sqlite3 Actually, i can't find any modules named _sqlite3 in /usr/lib/python2.5/. How can i do? thanks find /usr/lib/python2.5/ -print | grep _sqlite3 This is not a bug reporing mailing list. Please use the main cygwin list.
Re: [ITP] sqlite3
Max Bowsher wrote: SQLite is a small C library that implements a self-contained, embeddable, zero-configuration SQL database engine. It will be a mandatory dependency of future Subversion releases. http://mps.sh.nu/~maxb/cygsqlite3/release/sqlite3/ # sqlite3 sdesc: Embeddable SQL database engine ldesc: SQLite is a small C library that implements a self-contained, embeddable, zero-configuration SQL database engine. category: Database Libs Devel requires: cygwin libsqlite3_0 # libsqlite3_0 sdesc: Embeddable SQL database engine ldesc: SQLite is a small C library that implements a self-contained, embeddable, zero-configuration SQL database engine. category: Database Libs requires: cygwin external-source: sqlite3 Debian: http://packages.debian.org/cgi-bin/search_packages.pl?searchon=sourcenamesversion=allexact=1keywords=sqlite3 Updated to 3.3.17-1. The 3.3.14-0.1 packages were GTGed, so I'll upload in a few days if no one says differently. Max. signature.asc Description: OpenPGP digital signature
Re: [ITP] sqlite3
Max Bowsher wrote: I have no idea, actually. I needed it for Subversion, and it configured and built fine, and that's pretty much all the thought I gave it, so far. Same I did for Monotone: no patch applied and it seems to work well enough. (thus it is using define OS_WIN and os_win.c) For future reference, a thread that talks about it (but is not the one I remember about.. can't find it at the moment): http://thread.gmane.org/gmane.comp.db.sqlite.general/1175 -- Lapo Luchini [EMAIL PROTECTED] (OpenPGP X.509) www.lapo.it (Jabber, ICQ, MSN)
Re: [ITP] sqlite3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Max Bowsher wrote: SQLite is a small C library that implements a self-contained, embeddable, zero-configuration SQL database engine. Are you using Mingw or Cygwin file locking? (by default CYGWIN includes Win32 in SQLite sources) I had tried packaging it some time ago, and had some problems in both cases, but finally gave up for lack of time and real need. Well, I guess I can answer myself reading the patch... I'll do that (and review the package) this evening or tomorrow, I hope. But then again I probably remember it wrong in the first place, since monotone uses SQLite3 internally and works nicely enough to be usable IMHO (no, unfortunately it can't use an external shared SQLite library at this time). - -- Lapo Luchini [EMAIL PROTECTED] (OpenPGP X.509) www.lapo.it (Jabber, ICQ, MSN) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIcBAEBAgAGBQJGHlZJAAoJEJLw0EUVBG945VcQAK6T6pOCK6+ruDREGUN0T+mU XiSWVumQnu+QyFVxwewjRDnXe0h2TK6qeqU134J4xbIwB3iY/SgYxVakPAywhRGb Cmetah/klgqAATox4aG8ygu47COPBXwTGYQ3AqxsdjGgz7CFAyNFF8gXKl3G+sZb HAjqEUbO0uO5nPTPuKXuBzBNKRMDzTj08xOB75VNo2RGx8sUMMY4vv3Uq9Uswnrf +twBBVZTh/iSpSkAs+1ntQ13OeJT6177XazRGZnYucHA2WLQ07p2HCItnm2F0Z2U xlGYc6Wo6Bo/7d52mXFjxS/qoYwT4pLBJjZnPxftezpaEEm8g67Hr7uzBPpafRaV +9c91w6sxKCAk2geu9gVmqPh0ZVXTDG010oNcTPeXmIJSItGCocI+0T8lLw5TYyr b5K21jhzyJo25s1ltHuw2x5wtii1qvpzSruUtlM4GYtTSCme9j1SHNhypHCwl9Rf JONWpJrNQVuNkRinFehYejXgBAVENYaH+i6O0WWVK5Yt30BGOeOjoAqd2KWmaLZs 2YDGSU5diimBJmDSoS2WRm+aegc+ozE/09kZtnvZaze2Y/6enE4U/N6pTD0gXsu4 SbANQT1xaiZ+E3yRsYMOeXVrD53pO9nQy9i/OL5DWOh5N1+qsLOHGTEi3hLB+RIv ZVmP4zAgqNV3IzD61L9P =RC/T -END PGP SIGNATURE-
Re: [ITP] sqlite3
Lapo Luchini wrote: Max Bowsher wrote: SQLite is a small C library that implements a self-contained, embeddable, zero-configuration SQL database engine. Are you using Mingw or Cygwin file locking? (by default CYGWIN includes Win32 in SQLite sources) I had tried packaging it some time ago, and had some problems in both cases, but finally gave up for lack of time and real need. I have no idea, actually. I needed it for Subversion, and it configured and built fine, and that's pretty much all the thought I gave it, so far. Max. signature.asc Description: OpenPGP digital signature
Re: [ITP] sqlite3
Max Bowsher writes: SQLite is a small C library that implements a self-contained, embeddable, zero-configuration SQL database engine. It will be a mandatory dependency of future Subversion releases. http://mps.sh.nu/~maxb/cygsqlite3/release/sqlite3/ # sqlite3 sdesc: Embeddable SQL database engine ldesc: SQLite is a small C library that implements a self-contained, embeddable, zero-configuration SQL database engine. category: Database Libs Devel requires: cygwin libsqlite3_0 # libsqlite3_0 sdesc: Embeddable SQL database engine ldesc: SQLite is a small C library that implements a self-contained, embeddable, zero-configuration SQL database engine. category: Database Libs requires: cygwin external-source: sqlite3 Debian: http://packages.debian.org/cgi-bin/search_packages.pl?searchon=sourcenamesversion=allexact=1keywords=sqlite3 Builds fine from source. Package names end with -0.1.tar.bz2 which should be -1.tar.bz2 I guess. According to the sqlite web site there is a newer version (3.3.15) available which fixes a bug. Otherwise GTG. Max. Ciao Volker
[ITP] sqlite3
SQLite is a small C library that implements a self-contained, embeddable, zero-configuration SQL database engine. It will be a mandatory dependency of future Subversion releases. http://mps.sh.nu/~maxb/cygsqlite3/release/sqlite3/ # sqlite3 sdesc: Embeddable SQL database engine ldesc: SQLite is a small C library that implements a self-contained, embeddable, zero-configuration SQL database engine. category: Database Libs Devel requires: cygwin libsqlite3_0 # libsqlite3_0 sdesc: Embeddable SQL database engine ldesc: SQLite is a small C library that implements a self-contained, embeddable, zero-configuration SQL database engine. category: Database Libs requires: cygwin external-source: sqlite3 Debian: http://packages.debian.org/cgi-bin/search_packages.pl?searchon=sourcenamesversion=allexact=1keywords=sqlite3 Max. signature.asc Description: OpenPGP digital signature
pysqlite / sqlite3 - ITP delayed
Hi folks,
this is meant as a quick progress update for those who might
be interested.
I would like to ITP pysqlite, which depends on sqlite.
While pysqlite is fine, I'm having trouble with sqlite.
While it basically works fine for supporting pysqlite,
I'd like to solve these issues before giving it away:
1.) I found at least 3 mutually binary-incompatible versions
of sqlite: 2.8.16, 3.0.[78], and 3.2.1. I would be happy to
go for the newest for now (3.2.1), but it might be nice
to be able to support different versions (as debian does).
2.) The installation of the tcl-bindings doesn't work for
me (yet). This is part of the upstream package, so I want
to have a closer look. Maybe I'll have to produce a non-
tcl package first (I don't need them anyway ;-), but that
wouldn't be nice.
3.) Building the documentation doesn't work for me (yet).
The package comes with extensive documentation. The debian
package installs it as HTML. The source however is in *tcl*.
Fascinating!
All in all, It'll take me another fortnight (next weekend
is blocked already). I'll keep you updated.
Cheers,
Jan.
P.S.: Here's my draft of the ITP.
Following positive response from Lapo and Gerrit (thanks),
and because I have the package anyway, here comes my first-ever
ITP. I need pysqlite, and pysqlite depends on sqlite.
For emphasis: Debian Sarge (frozen testing) contains
pysqlite 1.0.1 and sqlite3 3.2.1 (and sqlite 2.8.x, as well).
Both have been packaged for cygwin before but never uploaded,
I believe. For sqlite in particular I'm building on the experience
of Jari Aalto, Yaakov Selkowitz, Gerrit P. Haase, and Reini Urban.
Please note my questions below.
pysqlite:
http://www.rechen-gilde.de/cygwin/release/pysqlite/setup.hint
http://www.rechen-gilde.de/cygwin/release/pysqlite/pysqlite-1.1.6-1.tar.bz2
http://www.rechen-gilde.de/cygwin/release/pysqlite/pysqlite-1.1.6-1-src.tar.bz2
sdesc: An extension module for the SQLite embedded relational database
ldesc: This is version 1.1.6 which is compatible with sqlite 3.0.7.
category: Database Devel
requires: cygwin sqlite3 python
sqlite3:
http://www.rechen-gilde.de/~miracle/cygwin/release/sqlite3/setup.hint
http://www.rechen-gilde.de/~miracle/cygwin/release/sqlite3/sqlite-3.2.1-1.tar.bz2
http://www.rechen-gilde.de/~miracle/cygwin/release/sqlite3/sqlite-3.2.1-1-src.tar.bz2
category: Database
requires: cygwin libncurses8 libreadline6
sdesc: An embeddable SQL database engine (3.0 branch)
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
(sqlite) that can be used to administer an SQLite database and which
serves as an example of how to use the SQLite library.
Open issues for pysqlite ...
- Are my customizations to the generic-build-script too much?
As I've listed in the README:
- Renaming source directory pysqlite to pysqlite-1.1.6.
- Some rules, e.g. conf, are empty.
- Rules build and install call the original python setup.py.
- The rule install specifies the install prefix.
- The python setup.py is called in ${srcdir}, not ${objdir}.
- The upstream source would build separate versions for each version
of the cygwin and python packages (cross-product, e.g.
lib.cygwin-1.5.16-i686-2.4). I've no clue whether this can be
a problem, so I'll try and just make one binary package for now.
As soon as that breaks, well ...
Cheers,
Jan.
