Bug#1034501: ITP: luametatex -- New generation processing Engine for ConTeXt
Package: wnpp Severity: wishlist Owner: Hilmar Preusse X-Debbugs-Cc: debian-devel@lists.debian.org I'm not fully sure about the final name of the source package. The OpenSuSE people name it texlive-context-bin, maybe I'll use a similar naming. * Package name: luametatex Version : 2.10.07 Upstream Contact: Hans Hagen * URL : https://github.com/contextgarden/luametatex * License : GPL, MIT/X Programming Lang: C, CWeb, C++ Description : New generation processing Engine for ConTeXt This is a follow up on the LuaTeX project. The source is considered part of the ConTeXt distribution and managed by the ConTeXt development team and the ConTeXt user group. That way we can guarantee that the engine and this TeX macro package work together as expected. The idea is that users can easily compile the source themselves and that way have a guaranteed long term (minimal) TeX based installation. Because the management scripts are in Lua, only one binary is needed to serve the ConTeXt distribution. In the source code we try to stay close to the ancestors, LuaTeX, pdfTeX, eTeX and TeX, but in the meantime due to additions there is quite some diverge. There are new primitives and submechanisms, there is more control over the inner workings, font handling is mostly delegated to Lua and there is no built-in backend. The code base is all-inclusive and has no (nor will have) dependencies on external libraries. - The TeX engine in this package will be (probably) the default processing engine of ConTeXt. The upcoming 2023 release of Context will hence depend on it. - I'm a member of the Debian TeX Task force, I'll maintain the package as a member of the team. As I'm not a DD, I'd a sponsor for the initial upload. -- sigmentation fault signature.asc Description: PGP signature
Bug#1034507: ITP: torctl -- Redirect all traffic through tor network
Package: wnpp Severity: wishlist Owner: Danial Behzadi X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: torctl Version : 0.5.7 Upstream Contact: BlackArch * URL : https://github.com/BlackArch/torctl * License : GPL-3+ Programming Lang: Bash Description : Redirect all traffic through tor network Script to redirect all traffic through tor network including dns queries for anonymizing entire system.
build profile proposal: nogir
Hi, when adding new general build profiles, we're supposed to consult with debian-devel. Thus I propose the "nogir" profile. This profile is supposed to skip building "gir*" packages containing typelib files. Why? gobject-introspection is one of the few and high popcon components that poses resistant to cross compilation. gir packages are often added to existing source packages for e.g. libraries and their presence makes cross building fail. Often enough, these gir packages are not needed for a particular application, so skipping them would allow cross building the library. The profile also allows fixing cross build problems in packages shipping typelib files such that when we get a solution for typelib generation, those packages will not have other bugs. Precise scope There are two major ways to define this profile. 1. narrow and reproducible The profile inhibits generation of "gir*" packages. It does not affect other kinds of packages. As such, it cannot be applied to source packages that happen to not split out their typelib files to separate packages (libraries libcjs0 and libgjs0g as well as a few applications such as gnome-calculator or liferea). On the flip side, the profile is called "reproducible" and it can be mechanically validated for correctness using reproducible builds. 2. wide and unreproducible The profile inhibits the generation of typelib files and also disables packages that would become mostly empty as a result (such as gir* packages). This covers more use cases, but the profile no longer is reproducible. The first approach would cover 282 binary packages at present and the second approach would affect 21 additional packages. Given that the majority of those 21 packages are applications, I prefer the narrow approach. As such I propose the following addition: profile name:nogir content changes: N package set changes: Y description: Disable building packages containing mainly GObject introspection data If there are no objections to this, I'd like to get at least one reply from a pkg-gnome team member. Bear in mind that gnome packages may receive patches adding nogir profile support if this is accepted, so if you expect rejecting such patches, please speak up. Helmut
Re: build profile proposal: nogir
On Sun, 16 Apr 2023 at 13:22:57 +0200, Helmut Grohne wrote: > when adding new general build profiles, we're supposed to consult with > debian-devel. Thus I propose the "nogir" profile. This profile is > supposed to skip building "gir*" packages containing typelib files. Unfortunately, I don't think this profile as stated will be practically useful, so I object to its addition on behalf of the GNOME team. I would support its addition if it was practically useful, but in the current state of the archive, it is not. GObject-Introspection metadata for a library consists of two files: * a GIR XML text file like /usr/share/gir-1.0/Flatpak-1.0.gir, analogous to a C header, usually-but-not-always architecture-independent in the same way C headers are (see #905715, #1029957, etc.), and intended to be read by the toolchains of compiled languages like Rust and Vala to generate Rust/Vala/etc. bindings for the library at compile-time on developer systems; * a binary typelib file like /usr/lib/x86_64-linux-gnu/girepository-1.0/Flatpak-1.0.typelib, analogous to a C library, and intended to be read by dynamic language runtimes like gjs or dynamic language extensions like PyGI to generate JavaScript/Python/etc. bindings for the library in-memory on end-user systems The GObject-Introspection mini-policy currently says that GIR XML needs to be shipped in the architecture-independent -dev package, so for example a typical simple example is libflatpak-dev which contains: * /usr/include/flatpak/flatpak.h (and friends) * /usr/lib/x86_64-linux-gnu/pkgconfig/flatpak.pc * /usr/share/gir-1.0/Flatpak-1.0.gir * /usr/lib/x86_64-linux-gnu/libflatpak.so If your goal is to be able to compile the runtime and -dev parts of GLib-based libraries like libflatpak for a cross architecture to use them as build-dependencies, then a nogir profile is not going to be helpful, because to ship the -dev package, you still need the GIR XML. To generate /usr/share/gir-1.0/Flatpak-1.0.gir, we need to enable GObject-Introspection and run g-ir-scanner against the compiled libflatpak, which is exactly the part of the build that is non-cross-friendly: because of the way GObject-Introspection currently works, it needs to be able to execute a host-architecture binary linked to the just-compiled libflatpak (the "dump binary") which outputs a subset of the runtime type information known to the GObject type system. It can be via qemu/binfmt_misc - it doesn't need to be high-performance, or do anything beyond minor computation and relatively basic syscalls like stdio - but it does have to work. Generating /usr/lib/x86_64-linux-gnu/girepository-1.0/Flatpak-1.0.typelib and therefore gir1.2-flatpak-1.0 involves "compiling" that GIR XML into a more efficient binary format. As far as I understand it, this doesn't strictly need to execute host-architecture code. If the GIR XML had always been in a separate package, like gir1.2-flatpak-1.0-dev or something, then we could turn that off under nogir as well; but it isn't, and splitting it would be a backwards-incompatible change, as well as requiring *many* trips through the NEW queue. Please see #1030223 for more information. I do have some ideas about how this can potentially be addressed post-bookworm (see #1030223) but so far I haven't really got far with implementing that. I'm sorry that the number of things I've found myself responsible for prevents me from progressing any of them particularly quickly. smcv
Bug#1034531: ITP: obs-scene-as-transition -- plugin for OBS Studio to use a Scene as a Transition
Package: wnpp Severity: wishlist Owner: Joao Eriberto Mota Filho X-Debbugs-Cc: debian-devel@lists.debian.org, Andi Stone * Package name: obs-scene-as-transition Version : 1.1.0 Upstream Contact: Andi Stone * URL : https://obsproject.com/forum/resources/scene-as-transition.1704 * License : GPL-2 Programming Lang: C Description : plugin for OBS Studio to use a Scene as a Transition This plugin can be used to create all kinds of transitions. It is recommended to get the most out of this plugin that you use other powerful plugins such as obs-move-transition to create advanced movements. Is possible to make the transitions dynamic by passing information from other ways. An example would be putting a text source on the transition scene and having it updated with the name of the scene or game you are transitioning to. Some features: - Choose a scene to use as a transition. - Set the total transition duration. - Set a what point the scene changes (Time or Percentage). - Choose a filter to trigger on the transition scene when the transition starts.
Re: build profile proposal: nogir
Hi Simon, On Mon, Apr 17, 2023 at 04:17:10PM +0100, Simon McVittie wrote: > Unfortunately, I don't think this profile as stated will be practically > useful, so I object to its addition on behalf of the GNOME team. I would > support its addition if it was practically useful, but in the current > state of the archive, it is not. thank you for taking the time to explain your reasons in detail. > I do have some ideas about how this can potentially be addressed > post-bookworm (see #1030223) but so far I haven't really got far with > implementing that. I'm sorry that the number of things I've found myself > responsible for prevents me from progressing any of them particularly > quickly. I'm sorry for having missed #1030223. I propose that we close this thread and continue discussing the profile in #1030223 (where it is also proposed with different semantics) until we reach consensus and then present that here. Helmut
