Bug#948701: ITP: libsqlitecpp -- smart and easy to use C++ SQLite3 wrapper
Package: wnpp Severity: wishlist Owner: Eduard Bloch * Package name: libsqlitecpp Version : 2.5.0+git20200112-1 Upstream Author : Sébastien Rombauts * URL : https://srombauts.github.io/SQLiteCpp/ * License : MIT Programming Lang: C++ Description : smart and easy to use C++ SQLite3 wrapper NOTE: this is a simple wrapper for sqlite which allows for cleaner C++ application code. Packaging as plain static library due to overhead/complexity/benefit trade-off. No plans for team maintenance yet (if you want to join the company, drop me a note!). Temp. WIP sample at https://github.com/Code7R/SQLiteCpp/tree/debian/sid Description: smart and easy to use C++ SQLite3 wrapper SQLiteC++ offers an encapsulation around the native C APIs of SQLite, with a few intuitive and well documented C++ classes. . The goals of SQLiteC++ are: - to offer the best of the existing simple C++ SQLite wrappers - to be elegantly written with good C++ design, STL, exceptions and RAII idiom - to keep dependencies to a minimum (STL and SQLite3) - to be portable - to be light and fast - to be thread-safe only as much as SQLite “Multi-thread” mode (see below) - to have a good unit test coverage - to use API names sticking with those of the SQLite library - to be well documented with Doxygen tags, and with some good examples - to be well maintained Best regards, Eduard.
[Resent, wrong email]: Working around the firefox nodejs dependency on riscv64 et al
(Apologies, for some reason Thunderbird used my GMail account for sending the mail. Please ignore the first message and respond here). Hi! I was browsing the debian-devel mailing list archives some weeks ago and ran into this thread [1] where the removal of the firefox-esr package on armel was discussed because newer Firefox versions have a build-dependency on nodejs which isn't available on armel. This could actually be fixed by patching the Debian source package such that the Javascript code is compiled in the binary-indep target of debian/rules so that the compiled Javascript files are put into the arch:all package and the Firefox packages firefox and firefox-esr can be built on armel, powerpc and sparc64 again. I know from a contact at Oracle that they are doing this to be able to build Firefox on Solaris/SPARC, they just keep the Javascript files in the repository out of which they are building the Firefox package for SPARC [2]. If we manage to split out the Javascript files into an arch:all package, we would be able to build Firefox on armel, powerpc, riscv64 and sparc64 as all these targets have full Rust support but don't support NodeJS. In the future, this will affect MIPS as well [3]. I think even ppc64 support is going to be removed from NodeJS in the near future. I have already opened a bug report for that against src:firefox [4]. Would anyone be interested to work with me on this issue? PS: Please keep me CC'ed, I'm not on the list. Thanks, Adrian > [1] https://lists.debian.org/debian-devel/2019/10/msg00391.html > [2] > https://github.com/oracle/solaris-userland/commit/05a1b957d036297a70a1f42a453f94f8cb789324 > [3] https://github.com/nodejs/node/issues/26179 > [4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=920902 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Working around the firefox nodejs dependency on riscv64 et al
Hi! I was browsing the debian-devel mailing list archives some weeks ago and ran into this thread [1] where the removal of the firefox-esr package on armel was discussed because newer Firefox versions have a build-dependency on nodejs which isn't available on armel. This could actually be fixed by patching the Debian source package such that the Javascript code is compiled in the binary-indep target of debian/rules so that the compiled Javascript files are put into the arch:all package and the Firefox packages firefox and firefox-esr can be built on armel, powerpc and sparc64 again. I know from a contact at Oracle that they are doing this to be able to build Firefox on Solaris/SPARC, they just keep the Javascript files in the repository out of which they are building the Firefox package for SPARC [2]. If we manage to split out the Javascript files into an arch:all package, we would be able to build Firefox on armel, powerpc, riscv64 and sparc64 as all these targets have full Rust support but don't support NodeJS. In the future, this will affect MIPS as well [3]. I think even ppc64 support is going to be removed from NodeJS in the near future. I have already opened a bug report for that against src:firefox [4]. Would anyone be interested to work with me on this issue? PS: Please keep me CC'ed, I'm not on the list. Thanks, Adrian > [1] https://lists.debian.org/debian-devel/2019/10/msg00391.html > [2] > https://github.com/oracle/solaris-userland/commit/05a1b957d036297a70a1f42a453f94f8cb789324 > [3] https://github.com/nodejs/node/issues/26179 > [4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=920902 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#948762: ITP: dark-gtk-themes -- dark GTK2/GTK3/Metacity theme
Package: wnpp Severity: wishlist Owner: Adam Borowski * Package name: dark-gtk-themes Upstream Author : Ximin Luo based on work by OriginalSeed * URL : https://github.com/infinity0/dark-themes * License : GPL2+ Description : dark GTK2/GTK3/Metacity theme This is Ximin Luo's pair of palette swap versions of DarkCold and DarkMint themes we already have in archive. The new themes are: * DarkFire * DarkBlood Obviously, both are firmly on the reddish side. The carmine shades in DarkBlood fit the color of a certain swirl...
