Re: Y2038 - best way forward in Debian?
* Eduard Bloch: > I vaguelly remember that glibc keeps collecting workarounds for replaced > APIs all the time, adjusting binary compatibility with manually > redirected symbols. Glibc folks might correct me, though. > > So, wouldn't a restart of the i386 architecture under a different name > give an excelent opportunity to get rid of many of such workarounds? Yes, that's what happens automatically once you start a new architecture for glibc, with a new ABI baseline. All the compat symbols before that baseline are automatically removed. But for one of the largest pieces with unwanted ABI exposure (the stdio implementation, also known as libio), we do not have a clean replacement. Part of the challenge is that even current gnulib pokes at stdio internals, so it's not just about maintaining compatibility with legacy binaries back when programmers didn't know you shouldn't do that (or simply had no way to influence development of the system libc).
Re: Y2038 - best way forward in Debian?
On Fri, Mar 06, 2020 at 07:46:26AM +0100, Eduard Bloch wrote: So, wouldn't a restart of the i386 architecture under a different name give an excelent opportunity to get rid of many of such workarounds? In theory, sure...but I don't see that there's any actual demand for a new/clean i386 architecture in 2038.
Bug#953250: ITP: libglib-testing -- test library providing test harnesses and mock classes
Package: wnpp Severity: wishlist Owner: Laurent Bigonville * Package name: libglib-testing Version : 0.1.0 Upstream Author : Philip Withnall * URL : https://gitlab.gnome.org/pwithnall/libglib-testing * License : LGPL 2.1 Programming Lang: C Description : test library providing test harnesses and mock classes libglib-testing is a test library providing test harnesses and mock classes which complement the classes provided by GLib. It is intended to be used by any project which uses GLib and which wants to write internal unit tests.
OpenLiteSpeed Build Script Violating Debian Upstream Guide
Hello, In Debian Upstream guide (https://wiki.debian.org/UpstreamGuide): You should never assume that Internet access is available during building. Debian guarantees that every binary package can be built from the available source packages for licensing and security reasons. Do not assume your VCS tools (e.g. Git) nor your VCS repository are available during the build. Debian's Policy requires that Debian packages follow the Filesystem Hierarchy Standard for file locations. Debian packages are not installed into /usr/local. Thus Debian config files are found in /etc and manual pages in /usr/share/man. If your program normally installs to a different location please be sure to provide a mechanism to change the locations without patching the source. Use of environment variables for this purpose is recommended. Avoid dependencies on unreleased versions (such as VCS snapshots) Avoid dependencies on the patches applied in specific distributions or your own patches If you need to patch a dependency please try to get your patch officially accepted by the dependency authors and document this process: When has this patch been sent to which email list or which issue tracker (with url) If your software depends on other libraries, then Debian also needs to make sure that your software compiles and works with the version of these libraries available in Debian. Debian may compile your software against a different version of some library than you do. Recently, I'm looking at build script (build.sh) from OpenLiteSpeed source tarball. Upstream said that invoking build.sh to build OLS is recommended way. But I found that the build script violate Debian Upstream Guide, if we package OLS by calling the build script from `debian/rules`: 1. The script builds OLS using specific version of CMake (3.14.5) and Go (1.6), though it did mention installing cmake as build dependency from apt. The script downloads both build tools and install them to `/usr/local` (which Debian packages never do). 2. OLS depend on Git snapshot version of some third-party libraries (`lsquic`, BoringSSL, and OLS third-party repo). Running `./configure` also clone BoringSSL Git repo and patch it with OLS upstream changes against specific commit in `master` branch, though I don't see the anything in configure script that do the clone (perhaps at `configure.in`?) 3. `chmod 777 /tmp/shm ./install.sh` (seriously dangerous!) 4. The build script installs OLS to `/usr/local`. If OLS will be packaged, should we use shipped `./build.sh` with flaws above? Bagas -- An old man doll... just what I always wanted! - Clara
Re: OpenLiteSpeed Build Script Violating Debian Upstream Guide
On Fri, Mar 06, 2020 at 08:38:43PM +0700, Bagas Sanjaya wrote: > If OLS will be packaged, should we use shipped `./build.sh` with flaws > above? No. And downloading stuff during the build process is strictly prohibited, not just discouraged. -- WBR, wRAR signature.asc Description: PGP signature
Re: OpenLiteSpeed Build Script Violating Debian Upstream Guide
On Fri, 2020-03-06 at 20:38 +0700, Bagas Sanjaya wrote: > 1. The script builds OLS using specific version of CMake (3.14.5) and > Go > (1.6), though it did mention installing cmake as build dependency > from > apt. The script downloads both build tools and install them to > `/usr/local` (which Debian packages never do). The CMake dependency should be easy enough to fix, as CMake 3.16 is available in Debian Sid. Kyle
Bug#953272: ITP: pyqt-builder -- PEP 517 compliant PyQt build system
Package: wnpp Severity: wishlist Owner: Dmitry Shachnev * Package name: pyqt-builder Version : 1.2.0 Upstream Author : Riverbank Computing Limited * URL : https://pypi.org/project/PyQt-builder/ * License : BSD (2-clause) Programming Lang: Python Description : PEP 517 compliant PyQt build system PyQt-builder is the PEP 517 compliant build system for PyQt and projects that extend PyQt. It extends the sip build system and uses Qt's ``qmake`` to perform the actual compilation and installation of extension modules. Projects that use PyQt-builder provide an appropriate ``pyproject.toml`` file and an optional ``project.py`` script. Any PEP 517 compliant frontend, for example ``sip-install`` or ``pip`` can then be used to build and install the project. This package is needed to replace the legacy build system of PyQt5. I will maintain it under the umbrella of Debian Python Modules Team. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#953274: ITP: ruby-ffi-libarchive: Ruby FFI binding to libarchive
Package: wnpp Owner: Lucas Kanashiro Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org * Package name : ruby-ffi-libarchive Version : 1.0.0 Upstream Author : John Bellone , Jamie Winsor , Frank Fischer * URL : https://github.com/chef/ffi-libarchive * License : Apache-2.0 Programming Lang: Ruby Description : Ruby FFI binding to libarchive This library provides Ruby FFI bindings to the well-known libarchive library (https://github.com/libarchive/libarchive). This package will be maintained under the umbrella of the Debian Ruby team. -- Lucas Kanashiro
Bug#953280: ITP: golang-github-jaguilar-vt100 -- An raw-mode vt100 screen reader
Package: wnpp Severity: wishlist Owner: Tong Sun * Package name: golang-github-jaguilar-vt100 Version : 0.0~git20150826.2703a27-1 Upstream Author : J jaguilar * URL : https://github.com/jaguilar/vt100 * License : Expat Programming Lang: Go Description : An raw-mode vt100 screen reader The golang-github-jaguilar-vt100 is a vt100 screen reader. Dependency of the github.com/google/go-containerregistry.
Re: Re: OpenLiteSpeed Build Script Violating Debian Upstream Guide
No. And downloading stuff during the build process is strictly prohibited, not just discouraged. Why did you say that? Why Debian prohibit downloading stuffs (including git clone repository) during build process? -- An old man doll... just what I always wanted! - Clara
Re: Re: OpenLiteSpeed Build Script Violating Debian Upstream Guide
On Sat, Mar 07, 2020 at 10:35:13AM +0700, Bagas Sanjaya wrote: > > No. > > And downloading stuff during the build process is strictly prohibited, not > > just discouraged. > > > Why did you say that? Why Debian prohibit downloading stuffs (including git > clone repository) during build process? Packages must be self-contained, using only their contents and the Debian repo during the build process. There are multiple technical and non-technical reasons for this requirement, including knowing that the package is DFSG-compliant and being able to always rebuild the package. -- WBR, wRAR signature.asc Description: PGP signature
