Bug#1103985: ITP: cadquery -- Python module for building parametric 3D CAD models
Package: wnpp X-Debbugs-Cc: debian-devel@lists.debian.org, Debian Science Maintainers Owner: Roland Mas Severity: wishlist * Package name: cadquery Version : 2.5.2 Upstream Contact: David Cowden * URL : https://github.com/CadQuery/cadquery * License : BSD-3-Clause/Apache-2.0 Programming Lang: Python Description : Python module for building parametric 3D CAD models CadQuery is an intuitive, easy-to-use Python module for building parametric 3D CAD models. Using CadQuery, you can write short, simple scripts that produce high quality CAD models. It is easy to make many different objects using a single script that can be customized. . CadQuery is often compared to OpenSCAD. Like OpenSCAD, CadQuery is an open-source, script based, parametric model generator.
Proposed MBF: CMake 4.0 compatibility
Hi, CMake has deprecated backwards compatibility for versions older than 3.5 since July 2023, and the CMake 4.0 release finally drops support, causing all packages still relying (or declaring to rely) on older behavior to FTBFS. Trixie will ship with CMake 3.31, so this issue is only relevant for the Forky release cycle. However, I plan to file forky tagged bugs early, so that maintainers are aware and can forward the bug to upstream as needed. I have rebuilt the ~3000 packages which build-depend on CMake with debusine (thanks to Freexian for this helpful service and Stefano Rivera for his debusine-rebuilds tool) and discovered 936 affected packages; the dd-list is attached. If you want to fix your package, there are two options: 1) Add -DCMAKE_POLICY_VERSION_MINIMUM=3.5 to dh_auto_configure, which will override any CMakeLists.txt settings. This is the minimally invasive procedure, no patching required. See also [1]. 2) Patch CMakeLists.txt and use the "..." range syntax to add a supported maximum version, e.g., cmake_minimum_required(VERSION 3.2...3.31). This is the recommended way to submit bugfixes to upstream. In both cases, you should verify that CMake still behaves how the package expects it. If your package builds reproducibly, you can easily check that the binary packages remain unchanged. Alternatively, you can look for policy warnings in the current build logs, which will point you towards potential problems. Cheers Timo [1] https://cmake.org/cmake/help/latest/variable/CMAKE_POLICY_VERSION_MINIMUM.html -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ A. Maitland Bottoms airspyhf (U) airspyone-host codec2 gqrx-sdr hackrf inspectrum (U) libad9361-iio libm2k (U) libosmosdr libsigmf soapyuhd (U) uhd Aaron Boxer libgrokj2k Adam Borowski birdtray critnib ipmctl pmdk qjoypad rapidcheck rpma zst Adrian Knoth qstopmotion (U) Aigars Mahinovs dlt-daemon Alan M Varghese (NyxTrail) hyprpaper Alastair McKinstry exodusii (U) fpzip (U) xdmf xygrib (U) Alberto Garcia libwpe (U) Alberto Luaces Fernández openscenegraph Alejandro Garrido Mota anomaly (U) clog (U) vramsteg Alessio Treglia eq10q (U) jack-keyboard (U) libinstpatch (U) libsoxr (U) Alex Myczko ansilove cadabra2 crow-translate (U) drs4eb far2l gnudatalanguage (U) hdrmerge (U) libansilove rclone-browser rtl-433 (U) seergdb shotcut (U) vdt (U) welle.io (U) Alexander GQ Gerasiov croaring libdivide rapidjson Alexander Wirt icinga2 (U) Alexandre Detiste gargoyle-free (U) Alexandre Marie ufo-core (U) Alexandre Mestiashvili bustools (U) libpam-abl Alexandre Quessy supercollider (U) Alexandre Rossi transmission (U) Alexandre Viau libevdevplus libuinputplus ydotool Alf Gaida juffed (U) qt5-style-kvantum (U) Amin Bandali restinio Ana Custura chkservice smtpping Andrea Capriotti libvdestack (U) vdens (U) vdeplug-agno (U) vdeplug-pcap (U) vdeplug-slirp (U) vdeplug-vdesl (U) vdeplug-vlan (U) Andrea Pappacoda glm (U) Andreas Beckmann khronos-opencl-clhpp (U) oclgrind (U) opencl-clang-14 (U) Andreas Bombe cubicsdr (U) limesuite (U) muparserx soapyairspy (U) soapyaudio (U) soapybladerf (U) soapyhackrf (U) soapyosmo (U) soapyredpitaya (U) soapyremote (U) soapyrtlsdr (U) soapysdr (U) soapyuhd (U) Andreas Henriksson mfgtools (U) Andreas Metzler libpano13 (U) luminance-hdr (U) pfstools (U) Andreas Misje dhcpoptinj Andreas Rönnquist allegro4.4 (U) allegro5 (U) Andreas Tille assembly-stats (U) ball (U) bamtools (U) beads (U) bifrost (U) bppphyview (U) bppsuite (U) civetweb (U) diamond-aligner (U) dicomscope (U) discosnp (U) edflib (U) flexbar (U) hhsuite (U) hinge (U) iitii (U) kallisto (U) libatomicbitvector (U) libbpp-core (U) libbpp-phyl (U) libbpp-phyl-omics (U) libbpp-popgen (U) libbpp-qt (U) libbpp-raa (U) libbpp-seq (U) libbpp-seq-omics (U) libdivsufsort (U) libedlib (U) liblemon (U) libsdsl (U) libshrinkwrap (U) libstreamvbyte (U) maffilter (U) mapsembler2 (U) minc-tools (U) minia (U) node-shiny-server (U) orthanc-dicomweb (U) orthanc-imagej (U) physamp (U) plast (U) prime-phylo (U) pvrg-jpeg (U) relion (U) savvy (U) seqan2 (U) sibelia (U) terraphast (U) tvc (U) Andrej Shadura nfstrace openvr (U) Andrew Lee (李健秋) kdeplasma-applets-xrdesktop libqt5xdg (U) lxqt-branding-debian (U) lxqt-build-tools-qt5 (U
Package statistics by downloads
I'm interested in package popularity. I'm aware of popcon (https://popcon.debian.org/), but I'm more interested in actual downloads. Do the debian mirrors track unique downloads (e.g. by hashed IP address), and if no, why not? I can understand the privacy argument, but arguably package downloads aren't particularly revealing? And data could be aggregated daily, thus limiting exposure. Boyuan Yang pointed out in the debian-www list that the "repository mirrors" often use third-party CDNs. I assume it uses DNS response load-balancing. There's potential for the request log to be biased geographically, but it might add interesting data. Another bias would be people using a VPN, but they'd only be counted once per exit node (so you'd have some IPs using an extreme number of packages). Parsing the request logs could be fairly trivial: 1. reduce to unique pairs every 24h: (ip, package) 2. sum by package
Re: Package statistics by downloads
On 2025-04-23 10:08, Erik Schulz wrote: I'm interested in package popularity. I'm aware of popcon (https://popcon.debian.org/), but I'm more interested in actual downloads. What would this be useful for? You only described technical details, not why we would want to do this. Kind regards Philipp Kern
Re: Associating .texi files to the media type text/prs.texi?
* Simon Josefsson , 2025-04-23 10:45: https://www.iana.org/assignments/media-types/application/texinfo The "Published specification" link is: https://www.gnu.org/software/texinfo/manual/texinfo/texinfo.html#Info-Format-Specification This points to the chapter about the Info format, which is very different than Texinfo. I recommend removing the anchor from that URL. -- Jakub Wilk
Bug#1103977: ITP: python-django-hashids -- Model ID hashing for Django
Package: wnpp Severity: wishlist Owner: Colin Watson X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-django-hashids Version : 0.7.0 Upstream Contact: Shen Li * URL : https://github.com/ericls/django-hashids * License : Expat Programming Lang: Python Description : hashids as a Django model field This package provides a Django model field that presents a hash of the internal primary key, without storing the hash in the database. It supports lookups, filtering, and sorting by the hashid string. This is a test dependency of python-django-pgbulk, which I've also ITPed (#1103880), so I'm just chasing the dependency chain. I'll maintain it within the Debian Python Team. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: Associating .texi files to the media type text/prs.texi?
Jakub Wilk writes: > * Simon Josefsson , 2025-04-23 10:45: >>https://www.iana.org/assignments/media-types/application/texinfo > > The "Published specification" link is: > https://www.gnu.org/software/texinfo/manual/texinfo/texinfo.html#Info-Format-Specification > > This points to the chapter about the Info format, which is very > different than Texinfo. I recommend removing the anchor from that URL. Oops, thank you! I've asked IANA to implement your suggestion. /Simon signature.asc Description: PGP signature
Re: Dropping awk?
Hi, Quoting Josh Triplett (2025-04-20 19:05:13) > On Sun, Apr 20, 2025 at 12:48:08PM +0200, Simon Josefsson wrote: > > Josh Triplett writes: > > > > > And the extra symlinks in `/etc/alternatives` don't take much size; I > > > agree you don't need update-alternatives, but then, you also don't > > > strictly need the entire dpkg and apt packages, if you're already > > > omitting their files under /var/lib. > > > > Right -- has anyone considered if Debian should have official containers > > without apt and dpkg? I think that for many use-cases for containers, > > apt and dpkg will not be used and just take up space. Guix packs > > (containers) doesn't get Guix installed unless you specify that as a > > package you want to have installed (which is usually not necessary), so > > something like this should be possible. > > The tricky part of that would be that you then couldn't use that > container image as a base and install any further packages. Offering a > "stock" container image without dpkg and apt would mean that the > container image has to *already* have everything installed that people > using the container need. (By contrast, if someone is installing their > own container they could then finalize it by removing dpkg and apt and other > things not needed at runtime.) Not quite. You can use dpkg --root to let dpkg work on another directory than your current rootfs [1]. You can use DPkg::Options to pass such options to apt. You can use dpkg --force-script-chrootless and then maintainer scripts will use tools from outside the chroot to work on the chroot. mmdebstrap makes use of this functionality. [1] small wrinkle, dpkg will read its configuration from outside the chroot, so this does not work well if you want to set up a system with a different configuration, see #808203 > I think it's a good idea to support this case, but I would ideally want to > support it in tools that people use to build containers. For instance, > suppose we had an mmdebstrap option to purge dpkg and apt and associated > paraphernalia, after installing everything needed. You don't purge dpkg. You just tell mmdebstrap to create a chroot without dpkg. You can use mmdebstrap to create, for example, a chroot which contains all of build-essential but not dpkg. mmdebstrap can do this by running apt and dpkg from the outside, passing the chroot directory using the respective options and let it populate the chroot with the packages you choose. That package set can include dpkg and apt but it doesn't have to. Don't purge dpkg and apt from your chroot. Do not install it at all in the first place. :) Thanks! cheers, josch signature.asc Description: signature
Re: Associating .texi files to the media type text/prs.texi?
Simon Josefsson writes: > Charles Plessy writes: > >> And the situation could be easily reverted by somebody declaring >> `text/texinfo` to the IANA. > > I did so now. There was a bunch of discussion back and forth with IANA and eventually application/texinfo was registered: https://www.iana.org/assignments/media-types/media-types.xhtml#application https://www.iana.org/assignments/media-types/application/texinfo There were some charset concerns about text/texinfo (that I never managed to understand myself, so I can't confirm if they weren't just imaginary), and some people thought application/x-texinfo was more wide-spread than text/x-texinfo. I didn't understand from your first e-mail what your thinking around GNU Texinfo format for the mime.types registry is? As far as I can tell there is a proper application/x-texinfo entry already? I tried reading about the text/prs.texi format on https://www.iana.org/assignments/media-types/text/prs.texi but the links aren't working. Is there any software that supports that format in Debian? My preference would be to have a application/texinfo associated with *.texi and *.texinfo. If there is some preference mechanism in place, I would prefer that application/texinfo is before text/prs.texi. Of course, I see no reason to remove support for application/x-texinfo, it should from now on just be an alias for application/texinfo. /Simon signature.asc Description: PGP signature
