Bug#724568: ITP: hidapi -- Library for communicating for USB and Bluetooth HID devices
Package: wnpp Severity: wishlist Owner: Scott Talbert * Package name: hidapi Version : 0.7.0 Upstream Author : Alan Ott * URL : http://www.signal11.us/oss/hidapi/ * License : GPLv3 or BSD Programming Lang: C Description : Library for communicating for USB and Bluetooth HID devices HIDAPI is a multi-platform library which allows an application to interface with USB and Bluetooth HID-class devices on Windows, Linux, FreeBSD, and Mac OS X. On Linux, either the hidraw or the libusb back-end can be used. There are trade-offs and the functionality supported is slightly different. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130925031815.2085.88406.report...@debian-unstable.techie.net
wxWidgets GTK+ 3 build available
Hi, Since ~March, we have a GTK+ 3 build of wxWidgets in Unstable/Testing. Packages that use wxWidgets may switch over to this build if they desire, although we are not pushing to remove the wx GTK+ 2 package in Buster, so packages can continue to use the GTK+ 2 build for Buster. To switch a package over to the GTK+ 3 build, it could be as simple as changing the Build-Depends from libwxgtk3.0-dev to libwxgtk3.0-gtk3-dev, rebuilding, and testing. A couple of known issues: 1) If your package uses wxSpinCtrl and hard-codes the widget size, or does not have additional horizonal space, the size may have to be adjusted. This is due to the underlying GtkSpinButton having switched to a wider layout in GTK+ 3. 2) If your package uses wxGLCanvas, it won't work under Wayland. This is due to wxGLCanvas (currently) requiring X11 to function. This can be worked around by forcing the GDK backend to X11. Here's one example of how this has been done: [1] We have set up a tracker to track the progress of moving to the GTK+ 3 package here: [2] Here is a dd-list output for the packages that build-depend on wxWidgets: A. Maitland Bottoms freedv (U) Adrien Cunin filezilla Alastair McKinstry mathgl (U) Alec Leamas wxsvg (U) Alessio Treglia sooperlooper (U) Alexander Kojevnikov spek Alexander Wirt icinga2 (U) Andreas Bombe cubicsdr (U) limesuite (U) Andreas Metzler hugin (U) Andreas Rönnquist poedit (U) Andreas Tille ctsim (U) gentle (U) ginkgocadx (U) lamarc (U) sitplus (U) treeviewx (U) Andrej Shadura wxhexeditor Anthony F McInerney sandboxgamemaker Anton Gladky gnuplot (U) Axel Beckert gnudatalanguage (U) Barak A. Pearlmutter ucblogo Barry deFreese plee-the-bear (U) Bas Couwenberg spatialite-gui (U) thuban (U) Bas Wijnen openmsx-catapult Benjamin Drung audacity (U) Brandon Barnes dolphin-emu (U) Bruno "Fuddl" Kleinert scorched3d (U) Carlo Segre fityk (U) objcryst-fox Carsten Schoenert kicad (U) Charles Plessy treeviewx (U) Chow Loong Jin mediainfo Christoph Berg pgadmin3 (U) Christoph Feenders ebook2cwgui (U) Colin Tuckley trustedqsl (U) D Haley 3depict (U) Damyan Ivanov flamerobin Daniel Echeverry tintii Daniel Leidert openbabel (U) David Henningsson audacity (U) David Paleino codeblocks spatialite-gui (U) Debian Accessibility Team espeakedit Debian Astronomy Team gnudatalanguage munipack Debian Electronics Team kicad Debian Erlang Packagers erlang Debian Games Team scorched3d Debian Games Team 0ad darkradiant dolphin-emu freedink-dfarc jugglemaster megaglest openyahtzee pcsx2 plee-the-bear scummvm-tools springlobby Debian GIS Project saga spatialite-gui thuban Debian Hamradio Maintainers cubicsdr ebook2cwgui freedv limesuite trustedqsl Debian l10n developers poedit Debian Med Packaging Team ctsim gentle ginkgocadx lamarc mriconvert sitplus treeviewx Debian Multimedia Maintainers audacity wxsvg Debian Multimedia Maintainers sooperlooper Debian Nagios Maintainer Group icinga2 Debian PhotoTools Maintainers hugin Debian PostgreSQL Maintainers pgadmin3 Debian Science Maintainers 3depict bossa cba fityk mathgl Debian Science Team gnuplot plplot wxastrocapture Debichem Team openbabel qutemol Denis Briand pgadmin3 (U) Dimitrios Eftaxiopoulos mathgl (U) Dmitry Smirnov freespace2-launcher-wxlauncher Dr. Tobias Quathamer silverjuke Ferdinand Griffon cba (U) Filip Hroch munipack (U) Francesco Paolo Lovergine saga (U) thuban (U) Franck Joncourt fwknop-gui Free Ekanayaka audacity (U) Georges Khaznadar kicad (U) Gert Wollny ginkgocadx (U) Gianfranco Costamagna poedit (U) Gonéri Le Bouder plee-the-bear (U) Graham Inggs qutemol (U) Gudjon I. Gudjonsson gspiceui Gunter Königsmann wxmaxima Helmut Grohne jugglemaster (U) Jaime Robles trustedqsl (U) James Cowgill codelite dolphin-emu (U) Jan Wagner icinga2 (U) Jaromír Mikeš audacity (U) sooperlooper (U) Jerry Stueve trustedqsl (U) Johan Van de Wauw saga (U) Jose G. López pgn2web José Luis Blanco Claraco mrpt Julien Jorge plee-the-bear (U) Kamal Mostafa ebook2cwgui (U) trustedqsl (U) Kartik Mistry xchm Kevin M. Rosenberg ctsim (U) Laszlo Boszormenyi (GCS) delaboratory wxsqlite3 Ludovic Rousseau 0ad (U) Luis Rivas Vañó sitplus (U) Luke Faraone chipw Mark Vejvoda megaglest (U) Markus Frosch icinga2 (U) Markus Koschany megaglest (U) openyahtzee (U) springlobby (U) Michael Banck openbabel (U) qutemol (U) Michael Casadevall codeblocks (U) Miguel A. Colón Vélez pcsx2 (U) Miriam Rui
Does debhelper prune empty directories?
Hi, I'm working on a package where I have a directory tree listed in the 'install' file with a destination directory. This source directory tree has a few empty subdirectories in it. Somehow during the build process, these empty subdirectories are disappearing. Does debhelper prune empty subdirectories? If so, is there a way to avoid that? What's strange is that this only seems to be happening in the main package. I have a subpackage which does a similar operation, but it's empty directories seem to be preserved. Thanks, Scott
Re: Does debhelper prune empty directories?
On Fri, 19 Jul 2019, Scott Talbert wrote: Hi, I'm working on a package where I have a directory tree listed in the 'install' file with a destination directory. This source directory tree has a few empty subdirectories in it. Somehow during the build process, these empty subdirectories are disappearing. Does debhelper prune empty subdirectories? If so, is there a way to avoid that? What's strange is that this only seems to be happening in the main package. I have a subpackage which does a similar operation, but it's empty directories seem to be preserved. I have narrowed it down - it seems to be dh_python2 that is removing the empty directories. Perhaps I should take my question to debian-python. Scott
Re: Bug#1037927: ITP: fuse -- bazil.org/fuse - With macOS support and its own import path so replace directives aren't necessary
On Wed, 14 Jun 2023, Félix Sipma wrote: * Package name: fuse There's already a package named fuse in Debian: https://tracker.debian.org/pkg/fuse Regards, Scott
Re: Proper handling of Lintian warnings due to other packages
On Wed, 31 Jan 2024, Jonas Smedegaard wrote: Unfortunately it is not likely that the package will be catch up soon, because the Haskell team upgrade most Haskell libraries only as a whole. That issue is not tracked in debbugs, because those vocal in the Haskell team actively discourages the use of debbugs: https://lists.debian.org/debian-haskell/2024/01/msg00012.html Note: I don't discourage usage of debbugs. It's just that I'm unlikely to notice bugs immediately due to the way debbugs notifications work. Scott
Re: Proper handling of Lintian warnings due to other packages
On Wed, 31 Jan 2024, Jonas Smedegaard wrote: Quoting Scott Talbert (2024-01-31 16:49:59) On Wed, 31 Jan 2024, Jonas Smedegaard wrote: Unfortunately it is not likely that the package will be catch up soon, because the Haskell team upgrade most Haskell libraries only as a whole. That issue is not tracked in debbugs, because those vocal in the Haskell team actively discourages the use of debbugs: https://lists.debian.org/debian-haskell/2024/01/msg00012.html Note: I don't discourage usage of debbugs. It's just that I'm unlikely to notice bugs immediately due to the way debbugs notifications work. The net effect of a) silence in response to filing bugreports, b) responses when reporting issues to Haskell mailinglist, and even c) you [dissing] my explicit attempts at steering conversation to the bugtracker is discouragement of using the bugtracker. - Jonas [dissing]: Sorry, I cannot find any other way to describe what you did when you replied to the list when I posted https://lists.debian.org/debian-haskell/2024/01/msg3.html and wrote "Meh" when I posted https://lists.debian.org/debian-haskell/2024/01/msg00010.html With respect to "silence in response to filing bug reports": Debian is a volunteer project. There is no service level agreement for bug response time, or expectation even that a bug will ever get responded to. My "meh" was in response to you insisting that the conversation be moved to the bug tracker. I was explicitly stating that I was okay with discussing bugs on the mailing list and NOT insisting that they be moved to the bug tracker. The bug tracker is not user friendly for some users, so I personally am fine with receiving reports through other means and will not insist everyone use the BTS. Scott
Re: Debian Policy 4.6.0.0 released
On Tue, 17 Aug 2021, Sean Whitton wrote: Hello everyone, I just pushed version 4.6.0.0 of the Debian Policy Manual and related documents to sid. Below you will find the significant normative changes from the previously announced release of Policy (4.5.1). The formal upgrading checklist is short, but also included in this release is important work by Russ Allbery to improve how we use Policy's explicitly normative terms -- 'must', 'should', 'recommended', etc. These keywords are now used more consistently. We have also introduced a new category of statements which we are calling "Policy advice". The addition of this category should make it easier to incorporate descriptions of more of our best practices into Policy. Please see 1.1. There are also a number of miscellaneous corrections. Thank you to those who submitted bug reports and patches. =*=*=*= 9.1.1 No package is allowed to install files in ``/usr/lib64/``. Previously, this prohibition only applied to packages for 64-bit architectures. 12.1 Manual pages may be included in dependencies, not only in the packages containing the things they document. Hi, The upgrading checklist on [1] is for version 4.5.2. I could be wrong, but doesn't this usually match first parts of the policy version (4.6.0.0)? [1] https://www.debian.org/doc/debian-policy/upgrading-checklist.html#version-4-5-2 Thanks, Scott
Re: Using release-monitoring.org [was: uscan roadmap]
On Fri, 3 Dec 2021, Paul Wise wrote: I think this would be the best path forward - it would probably be not easy given that it changes entirely how the current system works, but it might be well worth the effort. Working together with another distribution would share the work for the distro. I'm sure if we are willing to join them they would accommodate us if there are any changes we would require (e.g. login via salsa instead of a fedora account). At minimum we would need a way to map from release-monitoring.org package names to Debian source package names. Assuming they use Fedora source package names, then the Repology service provides such a mapping and we could presumably could get a periodic export of that. release-monitoring.org has the ability to configure distribution-specific names for each package. Take for example pycurl, which has mappings for Fedora, Alpine, and Timesys: https://release-monitoring.org/project/7973/ It appears there are 314 packages that already have Debian mappings. Scott
Using a build profile on a buildd build
Hi, Is it possible to instruct the buildds to use a build profile when performing an official build (e.g., using nocheck to break a dependency loop)? If so, how? Thanks, Scott
Re: php8.1 ?
On Fri, 17 Jun 2022, admin4 wrote: Hello Debianers, it's a great distro. * stable * fast * secure * minimalism (UNIX K.I.S.S) + https://dwaves.de/2017/05/02/the-unix-philosophy-of-k-i-s-s-simple-and-beau tiful-software-that-just-works/ o constructive criticism is welcome what is (still) missing are Debian/Ubuntu official php8.1 packages. right now thanks to an maintainer @ https://packages.sury.org/php/ https://dwaves.de/2022/03/19/gnu-linux-debian-11-how-to-upgrade-php7-to-php 8-1-logo-problems-during-update-postinst-49-etc-apache2-envvars-clear_env- not-found/ it is still possible for Debian 11 to upgrade from php7.4 to php8.1 php8.1 is in unstable and testing (e.g., will be in Bullseye): https://tracker.debian.org/pkg/php8.1 Debian doesn't add packages in stable releases (e.g., 11). The only way to get php8.1 in an official repository would be via backports. It looks as if someone has already requested a backport of php8.1, so perhaps you want to follow this bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1012615 Scott
Re: questionable massive auto-removal: buggy deps nvidia-graphics-drivers-tesla-470
On Tue, 28 Jun 2022, julien.pu...@gmail.com wrote: Hi, sorry I didn't follow the conversation but it seems that all my Python packages are still not migrating to testing and I don't really understand how to fix it. The error I see consistently in my Python packages is: > Issues preventing migration: > Not built on buildd: arch all binaries uploaded by venthur, a new > source-only upload is needed to allow migration I've re-uploaded all packages a few days ago, but the error is still the same. Wild guess: were your new uploads _*source-only*_ ? I looked at a couple of them and they were (source all) so that does appear to be the problem. All uploads need to be source-only (since bullseye?). Scott
Proposed MBF: wxwidgets3.2 transition
Hi, wxWidgets 3.2 (a new API/ABI stable release) has been released a few months ago and is now packaged in unstable as wxwidgets3.2. Upstream has stopped supporting wxWidgets 3.0, so the Debian wx team would like to migrate all wx package users to wxwidgets3.2 for bullseye, with the plan to remove wxwidgets3.0 before release. For most packages, the transition should be as simple as changing Build-Depends from libwxgtk3.0-gtk3-dev to libwxgtk3.2-dev. Some packages may require small patches; I'm happy to help with those (and I have some already from working on this transition in Fedora already). The Release Team has set up a transition tracker for us to track progress [1]. I'm planning to file bugs for all packages that haven't yet migrated. dd-list is attached. Please let me know if you have any questions or comments. Thanks, Scott [1] https://release.debian.org/transitions/html/wxwidgets-3.2.htmlA. Maitland Bottoms freedv (U) Alastair McKinstry mathgl (U) Alec Leamas opencpn wxsvg (U) Alessio Treglia sooperlooper (U) Alexander Wirt icinga2 (U) Andreas Bombe cubicsdr (U) limesuite (U) Andreas Metzler hugin (U) Andreas Rönnquist poedit (U) Andreas Tille ctsim (U) gentle (U) lamarc (U) treeviewx (U) Andrej Shadura wxhexeditor Andrius Merkys openbabel (U) Aniol Marti aegisub Anton Gladky gnuplot (U) Axel Beckert gnudatalanguage (U) Barak A. Pearlmutter ucblogo Barry deFreese asc (U) plee-the-bear (U) Bartosz Fenski asc (U) Bas Couwenberg grass (U) spatialite-gui (U) Bas Wijnen openmsx-catapult Benjamin Drung audacity (U) Brandon Barnes dolphin-emu (U) Bruno Kleinert scorched3d (U) Carlo Segre fityk (U) objcryst-fox Carsten Schoenert kicad (U) Cesar Mauri eviacam Charles Plessy treeviewx (U) Chow Loong Jin mediainfo slic3r-prusa (U) Christoph Berg cubicsdr (U) limesuite (U) trustedqsl (U) Christoph Schmidt-Hieber stimfit D Haley 3depict (U) Damyan Ivanov flamerobin libalien-wxwidgets-perl (U) Daniel Echeverry tintii Daniel Leidert openbabel (U) David Hart 4pane David Henningsson audacity (U) David Paleino codeblocks spatialite-gui (U) David Prévot codeblocks (U) Debian 3-D Printing Packages <3dprinter-gene...@lists.alioth.debian.org> slic3r-prusa Debian Accessibility Team espeakedit Debian Astronomy Team gnudatalanguage munipack Debian Electronics Team kicad Debian Erlang Packagers erlang Debian Games Team 0ad asc darkradiant dolphin-emu megaglest openyahtzee pcsx2 plee-the-bear scorched3d scummvm-tools springlobby Debian GIS Project grass saga spatialite-gui Debian Hamradio Maintainers cubicsdr ebook2cwgui freedv limesuite trustedqsl Debian l10n developers poedit Debian Med Packaging Team ctsim gentle lamarc mriconvert treeviewx Debian Multimedia Maintainers audacity sooperlooper wxsvg Debian Nagios Maintainer Group icinga2 Debian Perl Group libalien-wxwidgets-perl Debian PhotoTools Maintainers hugin Debian QA Group codelite Debian Science Maintainers 3depict bossa cba fityk mathgl xylib Debian Science Team gnuplot plplot wxastrocapture Debichem Team openbabel qutemol Dennis Braun audacity (U) sooperlooper (U) Dimitrios Eftaxiopoulos mathgl (U) Dmitry Smirnov freespace2-launcher-wxlauncher Dominique Dumont libalien-wxwidgets-perl (U) Dr. Tobias Quathamer silverjuke Ferdinand Griffon cba (U) Filip Hroch munipack (U) Francesco Paolo Lovergine grass (U) saga (U) Free Ekanayaka audacity (U) Georges Khaznadar kicad (U) Gianfranco Costamagna poedit (U) Gonéri Le Bouder plee-the-bear (U) Graham Inggs qutemol (U) gregor herrmann libalien-wxwidgets-perl (U) Gunter Königsmann wxmaxima Gürkan Myczko gnudatalanguage (U) Gürkan Myczko drs4eb James Cowgill dolphin-emu (U) Jan Wagner icinga2 (U) JaromÃr MikeÅ¡ audacity (U) sooperlooper (U) Johan Van de Wauw saga (U) Jose G. López pgn2web Jose Luis Blanco Claraco mrpt Julien Jorge plee-the-bear (U) Jussi Pakkanen meson Kamal Mostafa ebook2cwgui (U) Kartik Mistry xchm Kevin M. Rosenberg ctsim (U) Laszlo Boszormenyi (GCS) wxsqlite3 Ludovic Rousseau 0ad (U) Mark Vejvoda megaglest (U) Markus Frosch icinga2 (U) Markus Koschany asc (U) megaglest (U) openyahtzee (U) springlobby (U) Martin Budaj therion Michael Banck openbabel (U) qutemol (U) Miguel A. Colón Vélez pcsx2 (U) Miriam Ruiz xmlcopyeditor Morten Kjeldgaard qutemol (U) NIIBE Yutaka golly Ole Streicher gnudatalanguage (U) plplot (U) Olly Betts libalien-wxwidgets-perl (U)
Re: Proposed MBF: wxwidgets3.2 transition
On Tue, 13 Sep 2022, Mattia Rizzolo wrote: On Mon, Sep 12, 2022 at 10:32:23PM -0400, Scott Talbert wrote: wxWidgets 3.2 (a new API/ABI stable release) has been released a few months ago and is now packaged in unstable as wxwidgets3.2. Upstream has stopped supporting wxWidgets 3.0, so the Debian wx team would like to migrate all wx package users to wxwidgets3.2 for bullseye, with the plan to remove wxwidgets3.0 before release. For most packages, the transition should be as simple as changing Build-Depends from libwxgtk3.0-gtk3-dev to libwxgtk3.2-dev. Some packages may require small patches; I'm happy to help with those (and I have some already from working on this transition in Fedora already). Question from somebody who doesn't know wxWidgets: if the update from one release to the other is so simple (at least, you make it sound very simple, and #1019416 has no blocking bugs, so I reckon everything works?) then why is this not packaged like pretty much any other library with an unversionde source package and an unversioned -dev binary package? Major wxWidgets releases are not API compatible, so there will be packages that will require changes (although there are not many backwards-incompatible API changes between 3.0 and 3.2). I would think of it more akin to GTK-2 vs GTK-3, although there are not as many API changes. Historically, there have been larger API changes between releases (e.g., 2.8 to 3.0). I suppose it would be technically possible to do it with a single -dev package, but that would lead to potentially extended breakages of unstable while the packages that require changes get updated. Scott
Re: Proposed MBF: wxwidgets3.2 transition
On Tue, 13 Sep 2022, Simon McVittie wrote:
For most libraries, the deciding factor would be: are library users
expected to find the library via a single pkg-config file that cannot
coexist with the other version (like libpng's libpng.pc and OpenSSL's
libssl.pc/libcrypto.pc/openssl.pc), or do they ship versioned pkg-config
files that can coexist (like GTK 2/3/4, Qt 4/5/6 and SDL 1/2)?
A more technology-neutral way to ask this question is: when the library
user names the library that they want, do they do so with a
major-version-qualified name, or with an unversioned name?
For libraries like GTK and SDL, the answer is that they normally use a
major-version-qualified name: Autotools PKG_CHECK_MODULES([GTK], [gtk+-3.0]),
Meson dependency('gtk4'), CMake find_package(SDL2 REQUIRED) or similar.
Because names are interfaces and interfaces are names, we package these
libraries with correspondingly versioned names: libgtk-3-dev, libgtk-4-dev,
libsdl2-dev and so on.
For libraries like libpng and OpenSSL, the answer is that they normally
use a non-versioned name: Autotools PKG_CHECK_MODULES([openssl]) or Meson
dependency('libpng') or similar. We package these libraries with unversioned
names: libssl-dev, libpng-dev and so on.
I think following that principle would make me lean towards a -dev package
without the major version, because library users seem to ask for it with
dependency('wxwidgets', modules: ['core']) or WX_CONFIG_CHECK([3.0])
or $(wx-config --cflags --libs core) or something like that - where the
3.0 is a minimum version, rather than a major version to select.
The answer is somewhere in between. wxWidgets major releases are designed
to coexist with each other. The library user can select a specific version,
by using the version-specific wx-config (e.g., wx-config-3.0 or
wx-config-3.2), or using the generic wx-config with
wx-config --version=x.y.
In any event, I don't plan to change the packaging design at this point
(it's been this way forever, AFAIK). Maybe when wx 3.4 comes out in ~10
years we can reconsider. :)
Scott
Re: Proposed MBF: wxwidgets3.2 transition
On Wed, 14 Sep 2022, gregor herrmann wrote: On Mon, 12 Sep 2022 22:32:23 -0400, Scott Talbert wrote: wxWidgets 3.2 (a new API/ABI stable release) has been released a few months ago and is now packaged in unstable as wxwidgets3.2. … For most packages, the transition should be as simple as changing Build-Depends from libwxgtk3.0-gtk3-dev to libwxgtk3.2-dev. … Debian Perl Group libalien-wxwidgets-perl libalien-wxwidgets-perl (.69+dfsg-4 uploaded to experimental. Next step: check what libwx-perl [0] says and do a binNMU or sourceful upload (it needs to switch from wxperl-gtk-3-0-5-uni-gcc-3-4 to wxperl-gtk-3-2-0-uni-gcc-3-4). Reviews of the packaging changes welcome. Thanks! Looks fine, other than a Build-Depends on wx-common isn't necessary - libwxgtk3.2-dev will pull that in. Scott
Re: Proposed MBF: wxwidgets3.2 transition
On Thu, 15 Sep 2022, Andreas Metzler wrote: On 2022-09-13 Scott Talbert wrote: Hi, wxWidgets 3.2 (a new API/ABI stable release) has been released a few months ago and is now packaged in unstable as wxwidgets3.2. Upstream has stopped supporting wxWidgets 3.0, so the Debian wx team would like to migrate all wx package users to wxwidgets3.2 for bullseye, with the plan to remove wxwidgets3.0 before release. For most packages, the transition should be as simple as changing Build-Depends from libwxgtk3.0-gtk3-dev to libwxgtk3.2-dev. Some packages may require small patches; I'm happy to help with those (and I have some already from working on this transition in Fedora already). [...] A successful build is no guarantee for a working packaging though. e.g. hugin errs out immediately when built with the newer wxWidgets. That is certainly true - and probably another good reason we don't use the single-dev-package approach. Do you want help with those errors? Scott
Re: Transition: pkg-config to pkgconf: next steps
On Thu, 20 Oct 2022, Andrej Shadura wrote: Hi, On Thu, 20 Oct 2022, at 12:34, Sebastiaan Couwenberg wrote: On 10/20/22 12:25, Andrej Shadura wrote: The version of pkgconf package providing the pkg-config binary package has been sitting in experimental for some time. I think I have tested the upgrade process quite extensively, but it would still be great if someone else could have a look. In any case, my plan is to upload it to unstable in about two weeks time. I will then commence another round of rebuilds; meanwhile I will be working on fixing issues I’ve already run into: I cannot reproduce the issue with icinga2, it built successfully on my system with pkg-config (>= 1.8.0) from experimental. Yes, this one in particular looks like an OOM error. I will do a separate run with more memory and disk just for those ABORTED builds. Also, it looks like there are some transient failures due to the perl rebuild that's ongoing. Specifically wxwidgets3.0 and wxpython4.0 are affected by that. Scott
Re: wxWidgets update & opencpn.
On Fri, 28 Oct 2022, Alec Leamas wrote: Hi Tobias! Thanks for takin time to reply! On 28/10/2022 11:00, Tobias Frost wrote: Hi Alec, On Fri, Oct 28, 2022 at 10:15:49AM +0200, Alec Leamas wrote: The core issue here is opencpn, wxsvg is a dependency. The problem with opencpn is that it has a plugin universe, and updating the current 5.6.2 version to wxWidgets 3.2 would break the plugin ABI. Hi Alec, Your plan to wait until 5.8 comes out is probably fine. However, just curious - if you switched opencpn to use wx 3.2 now, couldn't you just rebuild/binNMU the plugins? Or are you trying to avoid that extra effort? Regards, Scott
Does removal of global variables from a library break C ABI?
In one of the library packages I maintain (hidapi), upstream removed a couple of global variables (my .symbols file noticed this). See abipkgdiff below. Does this break ABI? My assessment is that it does NOT, but I would like to confirm. These variables were not declared in a header file, so I can't see how external user code would have referenced them. Thanks, Scott changes of 'libhidapi-hidraw.so.0.0.0'=== Functions changes summary: 0 Removed, 0 Changed, 0 Added function Variables changes summary: 0 Removed, 0 Changed, 0 Added variable Function symbols changes summary: 0 Removed, 1 Added function symbol not referenced by debug info Variable symbols changes summary: 2 Removed, 0 Added variable symbols not referenced by debug info 1 Added function symbol not referenced by debug info: [A] hid_get_device_info 2 Removed variable symbols not referenced by debug info: [D] device_string_names [D] last_global_error_str end of changes of 'libhidapi-hidraw.so.0.0.0'===
Re: Does removal of global variables from a library break C ABI?
On Wed, 18 Jan 2023, Peter Pentchev wrote: On Tue, Jan 17, 2023 at 08:03:18PM -0800, Russ Allbery wrote: Scott Talbert writes: In one of the library packages I maintain (hidapi), upstream removed a couple of global variables (my .symbols file noticed this). See abipkgdiff below. Does this break ABI? My assessment is that it does NOT, but I would like to confirm. These variables were not declared in a header file, so I can't see how external user code would have referenced them. It does technically, but if the variables were never declared in a header file, it's equivalent to hiding private functions that were previously exposed by mistake but never prototyped for users. Traditionally, we don't consider that an ABI break worth bumping the soname unless we have some reason to believe that software is using those symbols. JFTR (I'm pretty sure that both Scott and Russ know this), https://sources.debian.org/ can help one figure out whether some other Debian package uses them. Thanks Russ and Peter. I didn't find any usage of these symbols, but I did sadly find a lot of bundled copies of this library in the archive. :( Scott
Re: Testing migrations not updating or visible
On Wed, 1 Jul 2020, Hugh McMaster wrote: The package tracker is no longer displaying migration status or ‘excuses’ for packages. I expected xmlstarlet to have almost migrated, but it’s stuck on 3 days old. Other packages are not displaying any migration status, despite being uploaded recently. Looks like the problem is not with the PTS but with britney, which seems to not have run in a couple of days: https://release.debian.org/britney/update_excuses.html Scott
Re: Source only upload
On Tue, 14 Jul 2020, Michael Meskes wrote: I just fell into the trap (again) and uploaded a binary package instead of sources only. We don't want the binaries to be uploaded, that much I get, but could anyone please explain to me, why we still accept binary uploads and why no tool in the whole chain gives as much as a warning, let alone is configured to do the right thing? If I missed something, please point me into the right direction. You still need to produce binary packages unfortunately if you upload something to NEW or binary-NEW. Scott
Re: Help with contacting Ubuntu devs for updating critically broken packages
On Wed, 14 Oct 2020, Norbert Preining wrote: Hi all (please Cc) is there a way to update hopelessly broken packages in Ubuntu Focal LTS? (packages in question are onedrive and in particular calibre - I refrain from commenting on the reasons behind calibre) Ubuntu seems to pull at arbitrary intervals rather incomplete packages that end up in LTS releases, and upstream gets flooded with bug reports. Yes, Ubuntu has a Stable Release Update process[1], but this is probably better discussed on an Ubuntu mailing list, rather than Debian. Scott [1] https://wiki.ubuntu.com/StableReleaseUpdates
Bug#888554: ITP: wxpython4.0 -- Python interface to the wxWidgets Cross-platform C++ GUI toolkit, Phoenix version
Package: wnpp Severity: wishlist Owner: Scott Talbert * Package name: wxpython4.0 Version : 4.0.0 Upstream Author : Robin Dunn * URL : https://www.wxpython.org/ * License : wxWindows Library License Programming Lang: Python Description : Python interface to the wxWidgets Cross-platform C++ GUI toolkit, Phoenix version wxWidgets (formerly known as wxWindows) is a class library for C++ providing GUI components and other facilities on several popular platforms (and some unpopular ones as well). . This package provides a Python interface to the wxGTK library and the wxPython runtime support libraries. This is the "Phoenix" implementation which now supports Python 3.
Bug#890091: ITP: pytest-forked -- py.test plugin for running tests in isolated forked subprocesses
Package: wnpp Severity: wishlist Owner: Scott Talbert * Package name: pytest-forked Version : 0.2 Upstream Author : pytest-dev * URL : https://pypi.python.org/pypi/pytest-forked * License : MIT Programming Lang: Python Description : py.test plugin for running tests in isolated forked subprocesses The pytest-forked plugin extends py.test by adding an option to run tests in isolated forked subprocesses. This is useful if you have tests involving C or C++ libraries that might crash the process. To use the plugin, simply use the --forked argument when invoking py.test. Needed as a dependency of pytest-xdist. Plan to maintain as part of DPMT.
sbuild and dpkg-checkbuilddeps
Hi, It seems that something changed in the last month or so with sbuild such that when building a package, it now seems to run dpkg-checkbuilddeps _outside_ the chroot and will fail all the build deps aren't installed. Is there a way to avoid this behavior, other than by using --no-clean-source? Thanks, Scott
