Re: Wine MinGW system libraries
Le mardi 7 septembre 2021, 00:44:31 UTC Paul Wise a écrit : > On Mon, Sep 6, 2021 at 9:54 PM Zebediah Figura wrote: > > The basic problem is that applications can and often do ship with PE > > builds of cross-platform libraries. These libraries can be ahead of > > Wine's system libraries, behind them, or even built with custom patches. > > Accordingly we really don't want to load "our" freetype in place of > > "their" freetype, or "theirs" in place of "ours". But because of the way > > the Win32 loader works, you can generally only have one DLL of a given > > name loaded in a process, and further attempts to dlopen() [as it were] > > "libfreetype-6.dll" will return the handle to the already loaded > > library, potentially breaking either Wine or the application. > > I don't know the details here, but my immediate thought when reading > this is that you need some kind of namespace. I then found that linker > namespaces are a thing, perhaps they would provide the solution for > you. It sounds like the OpenGL shim loader solution listed on the > glibc wiki might work for your use-case. Or perhaps the LD_AUDIT > feature would also work. > > https://www.sourceware.org/glibc/wiki/LinkerNamespaces I agree with pabs, implementing name space is a good solution and will allow to be distrib friendly. Moreover it will be best if marking a library as wine system one could be done post build. We will prefer to not modify upstream (like libpng) source. It is easier for us to apply small patch to upstream, or better in your case to add a post link linker script or even some compiler flag that will add some notes section to dll in order to mark it as use namespace system, or so on. The problem on windows side is well known as dll hell Renaming of the lib could be done post install. Moreover a crazy idea why not renaming system dll instead of libpng-2.0.0.dll as libpng-2.0.0.sll (note the version is manadaroty) Therefore we could use upstream source. Then add a small linker script that will rewrite the depends of libpng-2.0.0.sll to .sll file (aka binary sed s/.dll/.sll/g). then add a small wraper (shim) like said pab that load the .sll library, the best pratice will be a command tool that take the name of the sll and create magically the dll Therefore from distrib point of side we only changes the way we build the package, it could be automated, it is scalable and it does not need to patch package by package. Only to add some linker script magic Bastien
Bug#993862: ITP: avocado -- Framework for automated testing
Package: wnpp Severity: wishlist Owner: Avocado Debian package maintainers * Package name: avocado Version : 91.0 Upstream Author : Red Hat, Cleber Rosa * URL : https://github.com/avocado-framework/avocado * License : GPLv2+ Programming Lang: Python Description : Framework for automated testing Avocado is a next generation testing framework inspired by Autotest and modern development tools such as git. It is a set of tools and libraries to help with automated testing. One can call it a test framework with benefits. Native tests are written in Python and they follow the unittest pattern, but any executable can serve as a test. The main features are: * Multiple result formats (human-readable/xUnit/JSON/TAP) * Job Replay to reproduce a given job * Job Diff to compare several aspects of two given jobs * Plugin system for framework extension * Utility libraries to perform basic operations like process execution, system information obtain, package management, etc * Good documentation available: https://avocado-framework.readthedocs.io/en/latest Current packaging state can be found at https://github.com/avocado-framework/avocado/tree/master/contrib/packages/debian We plan to maintain it and need a sponsor for the upload.
Re: Wine MinGW system libraries
On 9/7/21 5:16 AM, Bastien Roucariès wrote: Le mardi 7 septembre 2021, 00:44:31 UTC Paul Wise a écrit : On Mon, Sep 6, 2021 at 9:54 PM Zebediah Figura wrote: The basic problem is that applications can and often do ship with PE builds of cross-platform libraries. These libraries can be ahead of Wine's system libraries, behind them, or even built with custom patches. Accordingly we really don't want to load "our" freetype in place of "their" freetype, or "theirs" in place of "ours". But because of the way the Win32 loader works, you can generally only have one DLL of a given name loaded in a process, and further attempts to dlopen() [as it were] "libfreetype-6.dll" will return the handle to the already loaded library, potentially breaking either Wine or the application. I don't know the details here, but my immediate thought when reading this is that you need some kind of namespace. I then found that linker namespaces are a thing, perhaps they would provide the solution for you. It sounds like the OpenGL shim loader solution listed on the glibc wiki might work for your use-case. Or perhaps the LD_AUDIT feature would also work. https://www.sourceware.org/glibc/wiki/LinkerNamespaces I agree with pabs, implementing name space is a good solution and will allow to be distrib friendly. Moreover it will be best if marking a library as wine system one could be done post build. We will prefer to not modify upstream (like libpng) source. It is easier for us to apply small patch to upstream, or better in your case to add a post link linker script or even some compiler flag that will add some notes section to dll in order to mark it as use namespace system, or so on. The problem on windows side is well known as dll hell Renaming of the lib could be done post install. Moreover a crazy idea why not renaming system dll instead of libpng-2.0.0.dll as libpng-2.0.0.sll (note the version is manadaroty) Therefore we could use upstream source. Then add a small linker script that will rewrite the depends of libpng-2.0.0.sll to .sll file (aka binary sed s/.dll/.sll/g). then add a small wraper (shim) like said pab that load the .sll library, the best pratice will be a command tool that take the name of the sll and create magically the dll Therefore from distrib point of side we only changes the way we build the package, it could be automated, it is scalable and it does not need to patch package by package. Only to add some linker script magic The problem isn't particularly about detecting what is and isn't a system library; I think we can come up with a reliable heuristic for that, without even needing linker namespaces or anything. The outstanding problem seems to be more about potentially breaking applications because they see two identically named DLLs loaded in the same process. Applications can and do trawl the internal loader state, although the Win32 loader also exposes some APIs so they don't even have to. It may also be that the aforementioned heuristic is too hacky to be accepted upstream into Wine.
Re: Debian Reunion Hamburg 2021
hi, On Wed, Sep 01, 2021 at 03:18:21PM +, Holger Levsen wrote: > I'm glad to finally be able to send out this invitation for the "Debian > Reunion > Hamburg 2021" taking place at the venue of the 2018 & 2019 MiniDebConfs! > > The event will run from Monday, Sep 27 2021 until Friday Oct 1 2021, with > Sunday, Sep 26 2021 as arrival day. IOW, Debian people meet again in Hamburg. > The exact format is less defined and structured than previous years, probably > we will just be hacking from Monday to Wednesday, have talks on Thursday and > a nice day trip on Friday. > > Please read https://wiki.debian.org/DebianEvents/de/2021/DebianReunionHamburg > if you intend to attend, especially > https://wiki.debian.org/DebianEvents/de/2021/DebianReunionHamburg#Dates_and_format_of_the_event > https://wiki.debian.org/DebianEvents/de/2021/DebianReunionHamburg#Covid_things > https://wiki.debian.org/DebianEvents/de/2021/DebianReunionHamburg#Call_for_papers > https://wiki.debian.org/DebianEvents/de/2021/DebianReunionHamburg#Registration > (registration is mandatory for this event!) > > Probably having some video coverage would be very nice to have, though due to > this very late announcement I'm not sure we'll really have talks and the need > for video. The event is in 3.5 weeks and will take place, either as a very > small hack meeting, or somewhat bigger. We certainly want videoing if we have > talks - and if you could help with this that would be very great! > > Last and definitly not least, financial sponsors for the event would be great. > If you can support the "Debian Reunion Hamburg 2021", please contact me > directly! > > > Now, late, after weeks of wondering if and how to do this event, I'm finally > and very much looking forward to it, to meet some Debian folks at least & for > some shared Debian hacking. Definitly not the 2021 event I had in mind after > the 2019 one, but something I feel I can responsibly do & enjoy. > > So, hoping to see some of you soon & most of you later! ;-) Sad but true, and > at least something for some people. We should all do more *local* events. And > more *online* events too, eg I think this is a great idea too: > https://wiki.debian.org/DebianEvents/internet/2021/MiniDebConfOnlineBookworm > > See you! there have been very few registrations so far, so I'm in contact with the venue discussing what to do. If you are still pondering whether to come or not, please register yourself, now!, even as 'maybe attending' so that we can better evaluate the situation. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ The corona crisis is peanuts compared to the global climate disaster. signature.asc Description: PGP signature
Bug#993864: ITP: taskserver -- taskwarrior synchronisation server
Package: wnpp Severity: wishlist Owner: Sergio de Almeida Cipriano Junior X-Debbugs-Cc: debian-devel@lists.debian.org, sergios...@protonmail.com * Package name: taskserver Version : 1.1.0 Upstream Author : Göteborg Bit Factory * URL : https://github.com/GothenburgBitFactory/taskserver * License : MIT Programming Lang: C++ Description : taskwarrior synchronisation server Taskserver is a daemon or service that will allow you to share tasks among different client applications, primarily Taskwarrior.
Re: Wine MinGW system libraries
I disagree. Le mar. 7 sept. 2021 à 17:48, Zebediah Figura a écrit : > On 9/7/21 5:16 AM, Bastien Roucariès wrote: > > Le mardi 7 septembre 2021, 00:44:31 UTC Paul Wise a écrit : > >> On Mon, Sep 6, 2021 at 9:54 PM Zebediah Figura wrote: > >>> The basic problem is that applications can and often do ship with PE > >>> builds of cross-platform libraries. These libraries can be ahead of > >>> Wine's system libraries, behind them, or even built with custom > patches. > >>> Accordingly we really don't want to load "our" freetype in place of > >>> "their" freetype, or "theirs" in place of "ours". But because of the > way > >>> the Win32 loader works, you can generally only have one DLL of a given > >>> name loaded in a process, and further attempts to dlopen() [as it were] > >>> "libfreetype-6.dll" will return the handle to the already loaded > >>> library, potentially breaking either Wine or the application. > >> > >> I don't know the details here, but my immediate thought when reading > >> this is that you need some kind of namespace. I then found that linker > >> namespaces are a thing, perhaps they would provide the solution for > >> you. It sounds like the OpenGL shim loader solution listed on the > >> glibc wiki might work for your use-case. Or perhaps the LD_AUDIT > >> feature would also work. > >> > >> https://www.sourceware.org/glibc/wiki/LinkerNamespaces > > I agree with pabs, implementing name space is a good solution > > and will allow to be distrib friendly. > > > > Moreover it will be best if marking a library as wine system one could > be done > > post build. We will prefer to not modify upstream (like libpng) source. > > > > It is easier for us to apply small patch to upstream, or better in your > case > > to add a post link linker script or even some compiler flag that will > add some > > notes section to dll in order to mark it as use namespace system, or so > on. > > > > The problem on windows side is well known as dll hell > > > > Renaming of the lib could be done post install. Moreover a crazy idea > why not > > renaming system dll instead of libpng-2.0.0.dll as libpng-2.0.0.sll > (note the > > version is manadaroty) Therefore we could use upstream source. Then add > a > > small linker script that will rewrite the depends of libpng-2.0.0.sll > to > > .sll file (aka binary sed s/.dll/.sll/g). > > > > then add a small wraper (shim) like said pab that load the .sll library, > the > > best pratice will be a command tool that take the name of the sll and > create > > magically the dll > > > > Therefore from distrib point of side we only changes the way we build the > > package, it could be automated, it is scalable and it does not need to > patch > > package by package. Only to add some linker script magic > > The problem isn't particularly about detecting what is and isn't a > system library; I think we can come up with a reliable heuristic for > that, without even needing linker namespaces or anything. > > The outstanding problem seems to be more about potentially breaking > applications because they see two identically named DLLs loaded in the > same process. Applications can and do trawl the internal loader state, > although the Win32 loader also exposes some APIs so they don't even have > to. > > It may also be that the aforementioned heuristic is too hacky to be > accepted upstream into Wine. > I do not propose to change the loader, i propose to change the link or post link stage of system library. You could rename the lib and change the dépend to new name after build. So you will have an unique name per system lib without changing the way you build these lib. It is équivalent to use a namespace resolved at late build time.
Re: Wine MinGW system libraries
Le mar. 7 sept. 2021 à 19:05, Bastien ROUCARIES a écrit : > I disagree. > > Le mar. 7 sept. 2021 à 17:48, Zebediah Figura a > écrit : > >> On 9/7/21 5:16 AM, Bastien Roucariès wrote: >> > Le mardi 7 septembre 2021, 00:44:31 UTC Paul Wise a écrit : >> >> On Mon, Sep 6, 2021 at 9:54 PM Zebediah Figura wrote: >> >>> The basic problem is that applications can and often do ship with PE >> >>> builds of cross-platform libraries. These libraries can be ahead of >> >>> Wine's system libraries, behind them, or even built with custom >> patches. >> >>> Accordingly we really don't want to load "our" freetype in place of >> >>> "their" freetype, or "theirs" in place of "ours". But because of the >> way >> >>> the Win32 loader works, you can generally only have one DLL of a given >> >>> name loaded in a process, and further attempts to dlopen() [as it >> were] >> >>> "libfreetype-6.dll" will return the handle to the already loaded >> >>> library, potentially breaking either Wine or the application. >> >> >> >> I don't know the details here, but my immediate thought when reading >> >> this is that you need some kind of namespace. I then found that linker >> >> namespaces are a thing, perhaps they would provide the solution for >> >> you. It sounds like the OpenGL shim loader solution listed on the >> >> glibc wiki might work for your use-case. Or perhaps the LD_AUDIT >> >> feature would also work. >> >> >> >> https://www.sourceware.org/glibc/wiki/LinkerNamespaces >> > I agree with pabs, implementing name space is a good solution >> > and will allow to be distrib friendly. >> > >> > Moreover it will be best if marking a library as wine system one could >> be done >> > post build. We will prefer to not modify upstream (like libpng) source. >> > >> > It is easier for us to apply small patch to upstream, or better in your >> case >> > to add a post link linker script or even some compiler flag that will >> add some >> > notes section to dll in order to mark it as use namespace system, or so >> on. >> > >> > The problem on windows side is well known as dll hell >> > >> > Renaming of the lib could be done post install. Moreover a crazy idea >> why not >> > renaming system dll instead of libpng-2.0.0.dll as libpng-2.0.0.sll >> (note the >> > version is manadaroty) Therefore we could use upstream source. Then >> add a >> > small linker script that will rewrite the depends of libpng-2.0.0.sll >> to >> > .sll file (aka binary sed s/.dll/.sll/g). >> > >> > then add a small wraper (shim) like said pab that load the .sll >> library, the >> > best pratice will be a command tool that take the name of the sll and >> create >> > magically the dll >> > >> > Therefore from distrib point of side we only changes the way we build >> the >> > package, it could be automated, it is scalable and it does not need to >> patch >> > package by package. Only to add some linker script magic >> >> The problem isn't particularly about detecting what is and isn't a >> system library; I think we can come up with a reliable heuristic for >> that, without even needing linker namespaces or anything. >> >> The outstanding problem seems to be more about potentially breaking >> applications because they see two identically named DLLs loaded in the >> same process. Applications can and do trawl the internal loader state, >> although the Win32 loader also exposes some APIs so they don't even have >> to. >> >> It may also be that the aforementioned heuristic is too hacky to be >> accepted upstream into Wine. >> > I do not propose to change the loader, i propose to change the link or > post link stage of system library. You could rename the lib and change the > dépend to new name after build. So you will have an unique name per system > lib without changing the way you build these lib. > > It is équivalent to use a namespace resolved at late build time. > And it is already coded :) https://pypi.org/project/machomachomangler/ > >
Bug#993881: ITP: obs-move-transition -- plugin for OBS Studio to improve switching scenes
Package: wnpp Severity: wishlist Owner: Joao Eriberto Mota Filho X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: obs-move-transition Version : 2.5.0 Upstream Author : Exeldro * URL : https://obsproject.com/forum/resources/move-transition.913/ * License : GPL-2 Programming Lang: C Description : plugin for OBS Studio to improve switching scenes This plugin moves sources to a new position during a scene transition, adding nice effects. If the 2 scenes contain a source with similar name (configured with settings) it will do the move the position and size between the 2 positions. . This filter can be added to a scene or a source to override the move transition for a source of the scene or the source global. . To use Move Transition, find for "Move" in "Scene Transitions" dock. This plugin is supported by OBS Studio 25 or above.
Re: Wine MinGW system libraries
On 9/7/21 12:05 PM, Bastien ROUCARIES wrote: I disagree. Le mar. 7 sept. 2021 à 17:48, Zebediah Figura a écrit : On 9/7/21 5:16 AM, Bastien Roucariès wrote: Le mardi 7 septembre 2021, 00:44:31 UTC Paul Wise a écrit : On Mon, Sep 6, 2021 at 9:54 PM Zebediah Figura wrote: The basic problem is that applications can and often do ship with PE builds of cross-platform libraries. These libraries can be ahead of Wine's system libraries, behind them, or even built with custom patches. Accordingly we really don't want to load "our" freetype in place of "their" freetype, or "theirs" in place of "ours". But because of the way the Win32 loader works, you can generally only have one DLL of a given name loaded in a process, and further attempts to dlopen() [as it were] "libfreetype-6.dll" will return the handle to the already loaded library, potentially breaking either Wine or the application. I don't know the details here, but my immediate thought when reading this is that you need some kind of namespace. I then found that linker namespaces are a thing, perhaps they would provide the solution for you. It sounds like the OpenGL shim loader solution listed on the glibc wiki might work for your use-case. Or perhaps the LD_AUDIT feature would also work. https://www.sourceware.org/glibc/wiki/LinkerNamespaces I agree with pabs, implementing name space is a good solution and will allow to be distrib friendly. Moreover it will be best if marking a library as wine system one could be done post build. We will prefer to not modify upstream (like libpng) source. It is easier for us to apply small patch to upstream, or better in your case to add a post link linker script or even some compiler flag that will add some notes section to dll in order to mark it as use namespace system, or so on. The problem on windows side is well known as dll hell Renaming of the lib could be done post install. Moreover a crazy idea why not renaming system dll instead of libpng-2.0.0.dll as libpng-2.0.0.sll (note the version is manadaroty) Therefore we could use upstream source. Then add a small linker script that will rewrite the depends of libpng-2.0.0.sll to .sll file (aka binary sed s/.dll/.sll/g). then add a small wraper (shim) like said pab that load the .sll library, the best pratice will be a command tool that take the name of the sll and create magically the dll Therefore from distrib point of side we only changes the way we build the package, it could be automated, it is scalable and it does not need to patch package by package. Only to add some linker script magic The problem isn't particularly about detecting what is and isn't a system library; I think we can come up with a reliable heuristic for that, without even needing linker namespaces or anything. The outstanding problem seems to be more about potentially breaking applications because they see two identically named DLLs loaded in the same process. Applications can and do trawl the internal loader state, although the Win32 loader also exposes some APIs so they don't even have to. It may also be that the aforementioned heuristic is too hacky to be accepted upstream into Wine. I do not propose to change the loader, i propose to change the link or post link stage of system library. You could rename the lib and change the dépend to new name after build. So you will have an unique name per system lib without changing the way you build these lib. It is équivalent to use a namespace resolved at late build time. Ah, so what you're proposing is that we do some sort of objcopy-like patching at runtime, e.g. when copying the dependency into the prefix. It probably won't be easy, but it might be more feasible than modifying the loader. I'll look into it...
Bug#993897: ITP: obs-ptz -- Plugin for OBS Studio to add a PTZ Camera control dock.
Package: wnpp Severity: wishlist Owner: Daniel Lenharo de Souza X-Debbugs-Cc: debian-devel@lists.debian.org, lenh...@debian.org * Package name: obs-ptz Version : 0.7.0 Upstream Author : Grant Likely * URL : https://github.com/glikely/obs-ptz * License : GPL2 Programming Lang: C++ Description : Plugin for OBS Studio to add a PTZ Camera control dock. This plugin adds a PTZ camera control panel to OBS that can control multiple cameras, and can automatically change selected camera based on the currently active preview or program scene. . The plugin supports the VISCA serial, VISCA-over-IP, and PELCO-P protocols, with plans to add support for other camera control protocols in the future. Features: Pan, Tilt, and Zoom controls Save and recall camera presets Control any number of cameras Auto select active camera based on active scene Supported protocols VISCA VISCA-over-IP Pelco-P
Re: Wine MinGW system libraries
On Tue, 2021-09-07 at 10:48 -0500, Zebediah Figura wrote: > The outstanding problem seems to be more about potentially breaking > applications because they see two identically named DLLs loaded in the > same process. Applications can and do trawl the internal loader state, > although the Win32 loader also exposes some APIs so they don't even have to. I might be wrong but I got the impression that runtime linker namespaces & LD_AUDIT are designed to solve this exact issue. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Wine MinGW system libraries
Le mar. 7 sept. 2021 à 23:01, Paul Wise a écrit : > > On Tue, 2021-09-07 at 10:48 -0500, Zebediah Figura wrote: > > > The outstanding problem seems to be more about potentially breaking > > applications because they see two identically named DLLs loaded in the > > same process. Applications can and do trawl the internal loader state, > > although the Win32 loader also exposes some APIs so they don't even have to. > > I might be wrong but I got the impression that runtime linker > namespaces & LD_AUDIT are designed to solve this exact issue. Yes but it does not work for PE because win native application do messy stuff with lib loader... see dll hell for instance. Spec was wrong for the beginning for PE. And wine does not use the ELF loader but a homemade PE in order to be bug to bug compatible with windows. In the long term implementing a LT_AUDIT in the wine loader will be worthless, but in the short term elfpatch like approach could work. Python use it. Bastien > > -- > bye, > pabs > > https://wiki.debian.org/PaulWise
Re: Wine MinGW system libraries
Le mar. 7 sept. 2021 à 21:16, Zebediah Figura a écrit : > > On 9/7/21 12:05 PM, Bastien ROUCARIES wrote: > > I disagree. > > > > Le mar. 7 sept. 2021 à 17:48, Zebediah Figura a > > écrit : > > > >> On 9/7/21 5:16 AM, Bastien Roucariès wrote: > >>> Le mardi 7 septembre 2021, 00:44:31 UTC Paul Wise a écrit : > On Mon, Sep 6, 2021 at 9:54 PM Zebediah Figura wrote: > > The basic problem is that applications can and often do ship with PE > > builds of cross-platform libraries. These libraries can be ahead of > > Wine's system libraries, behind them, or even built with custom > >> patches. > > Accordingly we really don't want to load "our" freetype in place of > > "their" freetype, or "theirs" in place of "ours". But because of the > >> way > > the Win32 loader works, you can generally only have one DLL of a given > > name loaded in a process, and further attempts to dlopen() [as it were] > > "libfreetype-6.dll" will return the handle to the already loaded > > library, potentially breaking either Wine or the application. > > I don't know the details here, but my immediate thought when reading > this is that you need some kind of namespace. I then found that linker > namespaces are a thing, perhaps they would provide the solution for > you. It sounds like the OpenGL shim loader solution listed on the > glibc wiki might work for your use-case. Or perhaps the LD_AUDIT > feature would also work. > > https://www.sourceware.org/glibc/wiki/LinkerNamespaces > >>> I agree with pabs, implementing name space is a good solution > >>> and will allow to be distrib friendly. > >>> > >>> Moreover it will be best if marking a library as wine system one could > >> be done > >>> post build. We will prefer to not modify upstream (like libpng) source. > >>> > >>> It is easier for us to apply small patch to upstream, or better in your > >> case > >>> to add a post link linker script or even some compiler flag that will > >> add some > >>> notes section to dll in order to mark it as use namespace system, or so > >> on. > >>> > >>> The problem on windows side is well known as dll hell > >>> > >>> Renaming of the lib could be done post install. Moreover a crazy idea > >> why not > >>> renaming system dll instead of libpng-2.0.0.dll as libpng-2.0.0.sll > >> (note the > >>> version is manadaroty) Therefore we could use upstream source. Then add > >> a > >>> small linker script that will rewrite the depends of libpng-2.0.0.sll > >> to > >>> .sll file (aka binary sed s/.dll/.sll/g). > >>> > >>> then add a small wraper (shim) like said pab that load the .sll library, > >> the > >>> best pratice will be a command tool that take the name of the sll and > >> create > >>> magically the dll > >>> > >>> Therefore from distrib point of side we only changes the way we build the > >>> package, it could be automated, it is scalable and it does not need to > >> patch > >>> package by package. Only to add some linker script magic > >> > >> The problem isn't particularly about detecting what is and isn't a > >> system library; I think we can come up with a reliable heuristic for > >> that, without even needing linker namespaces or anything. > >> > >> The outstanding problem seems to be more about potentially breaking > >> applications because they see two identically named DLLs loaded in the > >> same process. Applications can and do trawl the internal loader state, > >> although the Win32 loader also exposes some APIs so they don't even have > >> to. > >> > >> It may also be that the aforementioned heuristic is too hacky to be > >> accepted upstream into Wine. > >> > > I do not propose to change the loader, i propose to change the link or post > > link stage of system library. You could rename the lib and change the > > dépend to new name after build. So you will have an unique name per system > > lib without changing the way you build these lib. > > > > It is équivalent to use a namespace resolved at late build time. > > > > Ah, so what you're proposing is that we do some sort of objcopy-like > patching at runtime, e.g. when copying the dependency into the prefix. > > It probably won't be easy, but it might be more feasible than modifying > the loader. I'll look into it... Yes sort of obcopy patching under linux it is called patchelf... If it work, it could be latter done in memory like paul wise suggest implementing namespace and LT_AUDIT (but it is a long term goal) 1. capture library loading 2. do the patching at loading time (using the same code then patchelf for pe replacing file read/write by mmap operation) And voila bastien
Re: Require packages to build without any configured DNS
On Mon, 06 Sep 2021, Mattia Rizzolo wrote: > It must be noted that no actual network operation happen, so this > doesn't fall into the "no network activity" bucket. > > This is the bug that was filed against dnspython: > https://bugs.debian.org/989171 > > Do anybody on the list have any opinion on where is the bug, on > dnspython, or on the build environment? Do you know why dnspython doesn't just fall back to socket.getaddrinfo if it can't parse /etc/resolv.conf [or maybe why python applications using dnspython don't fall back to that if dnspython fails?] That seems like the right default unless you really, really need to talk to a full-fledged DNS server directly. -- Don Armstrong https://www.donarmstrong.com He quite enjoyed the time by himself in the mornings. The day was too early to have started going really wrong. -- Terry Pratchet _Only You Can Save Mankind_ p133
Bug#993906: ITP: sqlmodel -- SQL databases in Python, designed for simplicity, compatibility, and robustness
Package: wnpp Severity: wishlist Owner: Sandro Tosi X-Debbugs-Cc: debian-devel@lists.debian.org, mo...@debian.org * Package name: sqlmodel Version : 0.0.4 Upstream Author : Sebastián Ramírez * URL : https://github.com/tiangolo/sqlmodel * License : MIT Programming Lang: Python Description : SQL databases in Python, designed for simplicity, compatibility, and robustness SQLModel is a library for interacting with SQL databases from Python code, with Python objects. It is designed to be intuitive, easy to use, highly compatible, and robust. . SQLModel is based on Python type annotations, and powered by Pydantic and SQLAlchemy. . The key features are: . * Intuitive to write: Great editor support. Completion everywhere. Less time debugging. Designed to be easy to use and learn. Less time reading docs. * Easy to use: It has sensible defaults and does a lot of work underneath to simplify the code you write. * Compatible: It is designed to be compatible with FastAPI, Pydantic, and SQLAlchemy. * Extensible: You have all the power of SQLAlchemy and Pydantic underneath. * Short: Minimize code duplication. A single type annotation does a lot of work. No need to duplicate models in SQLAlchemy and Pydantic. SQLModel is designed to simplify interacting with SQL databases in FastAPI applications, it was created by the same author. . It combines SQLAlchemy and Pydantic and tries to simplify the code you write as much as possible, allowing you to reduce the code duplication to a minimum, but while getting the best developer experience possible. . SQLModel is, in fact, a thin layer on top of Pydantic and SQLAlchemy, carefully designed to be compatible with both.
Bug#993914: ITP: gpufetch -- Simple yet fancy GPU architecture fetching tool
Package: wnpp Severity: wishlist Owner: clay stan X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: gpufetch Version : 0.10 Upstream Author : Dr-Noob * URL : https://github.com/Dr-Noob/gpufetch License : MIT
Bug#993914: ITP: gpufetch -- Simple yet fancy GPU architecture fetching tool
X-Debbugs-Cc: debian-devel@lists.debian.org Hi, 在 2021-09-08星期三的 14:26 +0800，clay stan写道： > Package: wnpp > Severity: wishlist > Owner: clay stan > X-Debbugs-Cc: debian-devel@lists.debian.org > > * Package name : gpufetch > Version : 0.10 > Upstream Author : Dr-Noob > * URL : https://github.com/Dr-Noob/gpufetch > License : MIT The project homepage says that it needs cuda C compiler, which is non-free. How are you going to solve this problem? Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
