Re: Suggestions about i386 support
Hi The (2024.06.10_12:22:14_+) > How to get access to the right parts of the waste stream to be able to > pull out some working 64-bit hardware is another question, and one where > I don't have an answer that wouldn't involve spending money (which would > presumably make the proposed alternative insufficiently comparable, > since presumably you wouldn't have to spend money to keep the existing > 32-bit machine in service). If Andrey does, I'd be interested to learn > it. The point here is that the Debian project is not intending to support new hardware on the i386 architecture. The architecture is being kept around primarily to support running old i386 binaries. We didn't bring 64bit time_t to the architecture, because of this goal. There isn't a team working on a modern 32 bit x86 port. We're just trying to keep the old one going for as long as we can. You're welcome to try to form such a team, of course :) The cost of supporting a port of Debian is far more than the cost of the machines needed to build it. Never mind the cost of 1 user's machine. Stefano -- Stefano Rivera http://tumbleweed.org.za/
Re: Reviving schroot as used by sbuild
Hi Helmut (2024.06.25_16:55:45_+) > lxd/incus also was on my list, Personally, I have been using LXD (and now Incus, as it made it into Debian, yay) for my experimentation and local package builds, for a number of years now. They have native support for btrfs snapshots, locally built images, and make it relatively simple to block network access for my builds. The autopkgtest-virt backed is a bit klunky, but I don't miss schroot at all. > but my understanding is that they do not work without their system > services at all Correct. LXC containers are essentially VMs without their own kernel. They run their own systemd. This does mean that I build packages in a fatter system than necessary. But that has yet to be an issue for me. > and being able to operate containers (i.e. being incus-admin or the > like) roughly becomes equivalent to being full root on the system > defeating the purpose of the exercise. You don't have to be incus-admin to use Incus. Users get their own incus project (see the incus-user.service). But I've never played with this much, on a single-user system, incus-admin is just much simpler (if less secure). Of course incus still has to be root itself to add network interfaces to bridges. It's nice to be able to control networking for the containers, but it would be even nicer for sbuild to not need setup that requires root. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#564605: ITP: python-pysilc -- Python bindings for SILC
Package: wnpp Severity: wishlist Owner: Stefano Rivera * Package name: python-pysilc Version : 0.4 Upstream Author : Alastair Tse * URL : http://www.liquidx.net/pysilc/ * License : BSD Programming Lang: C Description : Python bindings for SILC PySilc is a near-complete set of Python bindings for creating SILC clients using the silc-toolkit. It allows developers to write simple bots and clients for connecting to SILC servers. -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#564609: ITP: python-pyfiglet -- A Python port of the FIGlet specification
Package: wnpp Severity: wishlist Owner: Stefano Rivera * Package name: python-pyfiglet Version : 0.4 Upstream Author : Christopher Jones * URL : http://sourceforge.net/projects/pyfiglet/ * License : GPLv2 Programming Lang: Python Description : A Python port of the FIGlet specification FIGLet is a program that creates large characters out of ordinary screen characters. It takes ASCII text and renders it in ASCII art fonts. It can be used on the command line or as an Object Oriented driver library in your own programs. -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#564608: ITP: python-aalib -- A set of bindings for AAlib, an ASCII art library
Package: wnpp Severity: wishlist Owner: Stefano Rivera * Package name: python-aalib Version : 0.1 Upstream Author : Jakub Wilk * URL : http://jwilk.net/software/python-aalib.html * License : GPLv2 Programming Lang: Python Description : A set of bindings for AAlib, an ASCII art library AAlib is a portable ascii art graphics library. Internally, it works like a graphics display, but the output is rendered into gorgeous platform independent ascii graphics. These are Python bindings for AAlib. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#565885: ITP: ibid -- Multi-protocol general purpose chat bot
Package: wnpp Severity: wishlist Owner: Stefano Rivera * Package name: ibid Version : 0+bzr849 Upstream Author : The Ibid Developers * URL : http://ibid.omnia.za.net/ * License : GPL (mostly MIT/X as well) Programming Lang: Python Description : Multi-protocol general purpose chat bot Ibid is a multi-protocol general purpose chat bot written in Python. It uses a natural language interface, and can connect to multiple sources, including IRC, Jabber and SILC servers, as well as allowing interaction using SMTP, HTTP and various RPC protocols. It aims to be agnostic with regard to how it is used, and to make plugins and extensions as easy as possible to write. -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#566798: ITP: python-objgraph -- Ad-hoc tools for drawing Python object reference graphs with graphviz
Package: wnpp Severity: wishlist Owner: Stefano Rivera * Package name: python-objgraph Version : 1.2 Upstream Author : Marius Gedminas * URL : http://mg.pov.lt/objgraph/ * License : MIT/X Programming Lang: Python Description : Ad-hoc tools for drawing Python object reference graphs with graphviz objgraph contains a set of utility functions for exploring Python objects in memory. It can be used for counting and statistics, finding root references responsible for large object trees and export the object reference graphs in graphviz format. -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#567552: ITP: python-html2text -- A Python Script which converts HTML to Markdown
Package: wnpp Severity: wishlist Owner: Stefano Rivera * Package name: python-html2text Version : 2.37 Upstream Author : Aaron Swartz * URL : http://www.aaronsw.com/2002/html2text/ * License : GPL3 Programming Lang: Python Description : A Python Script which converts HTML to Markdown html2text is a Python script that converts a page of HTML into clean, easy-to-read plain ASCII text. Better yet, that ASCII also happens to be valid Markdown (a text-to-HTML format). -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#572135: ITP: libstemmer -- Snowball stemming algorithms for use in Information Retrieval
Package: wnpp Severity: wishlist Owner: Stefano Rivera * Package name: libstemmer Version : 0+svn526 Upstream Author : Dr Martin Porter and Richard Boulton * URL : http://snowball.tartarus.org/ * License : BSD Programming Lang: C Description : Snowball stemming algorithms for use in Information Retrieval Snowball provides access to efficient algorithms for calculating a "stemmed" form of a word. This is a form with most of the common morphological endings removed; hopefully representing a common linguistic base form. This is most useful in building search engines and information retrieval software; for example, a search with stemming enabled should be able to find a document containing "cycling" given the query "cycles". Snowball provides algorithms for several (mainly European) languages. It also provides access to the classic Porter stemming algorithm for English: although this has been superseded by an improved algorithm, the original algorithm may be of interest to information retrieval researchers wishing to reproduce results of earlier experiments. -- 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/20100301191937.6647.38370.report...@bach
Bug#574276: ITP: re2 -- efficient, principled regular expression library
Package: wnpp Severity: wishlist Owner: Stefano Rivera * Package name: re2 Version : 0+hg10+dfsg Upstream Author : Google Inc. * URL : http://code.google.com/p/re2/ * License : BSD Programming Lang: C++ Description : efficient, principled regular expression library RE2 is a fast, safe, thread-friendly alternative to backtracking regular expression engines like those used in PCRE, Perl, and Python. It is a C++ library. RE2 uses automata theory to guarantee that regular expression searches run in time linear in the size of the input. RE2 implements memory limits, so that searches can be constrained to a fixed amount of memory. RE2 is engineered to use a small fixed C++ stack footprint no matter what inputs or regular expressions it must process; thus RE2 is useful in multithreaded environments where thread stacks cannot grow arbitrarily large. On large inputs, RE2 is often much faster than backtracking engines; its use of automata theory lets it apply optimizations that the others cannot. It hasn't released a version yet, but is reported to have been widely used within Google for a while. We presume it has stabilised a bit. -- 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/20100317100641.13486.30844.report...@bach
Bug#589394: ITP: munkres -- munkres algorithm for the Assignment Problem
Package: wnpp Severity: wishlist Owner: Stefano Rivera * Package name: munkres Version : 1.0.5.4 Upstream Author : Brian Clapper * URL : http://bmc.github.com/munkres/ * License : BSD Programming Lang: Python Description : munkres algorithm for the Assignment Problem The Munkres module provides an implementation of the Munkres algorithm (also called the Hungarian algorithm or the Kuhn-Munkres algorithm), useful for solving the Assignment Problem. I intend to package this under the Debian Python Modules Team. SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 465 6908 C: +27 72 419 8559 UCT: x3127 signature.asc Description: Digital signature
Bug#589396: ITP: beets -- music tagger and library organizer
Package: wnpp Severity: wishlist Owner: Stefano Rivera * Package name: beets Version : 1.0b2-1 Upstream Author : Adrian Sampson * URL : http://beets.radbox.org/ * License : MIT Programming Lang: Python Description : music tagger and library organizer Beets is a media library management system for obsessive-compulsive music geeks. The purpose of beets is to get your music collection right once and for all. It catalogs your collection, automatically improving its metadata as it goes using the MusicBrainz database. It then provides a set of tools for manipulating and accessing your music. Beets also includes a music player that implements the MPD protocol, so you can play music in your beets library using any MPD client. I intend to package this under the Debian Python Apps Team. SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 465 6908 C: +27 72 419 8559 UCT: x3127 signature.asc Description: Digital signature
Bug#589545: ITP: xdot -- interactive viewer for Graphviz dot files
Package: wnpp Severity: wishlist Owner: Stefano Rivera * Package name: xdot Version : 0.4 Upstream Author : Jose Fonseca * URL : http://code.google.com/p/jrfonseca/wiki/XDot * License : LGPL-3+ Programming Lang: Python Description : interactive viewer for Graphviz dot files xdot is an interactive viewer for graphs written in Graphviz's dot language. It uses internally the graphviz's xdot output format as an intermediate format, and PyGTK and Cairo for rendering. xdot can be used either as a standalone application from command line, or as a library embedded in your python application. Features: * Since it doesn't use bitmaps it is fast and has a small memory footprint. * Arbitrary zoom. * Keyboard/mouse navigation. * Supports events on the nodes with URLs. * Animated jumping between nodes. * Highlights node/edge under mouse. I intend to package this under the Debian Python Applications Team. SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 465 6908 C: +27 72 419 8559 UCT: x3127 signature.asc Description: Digital signature
Re: List of FTBFS in Ubuntu
Hi Russ (2010.12.03_19:25:06_+0200) > >opensaml2 (U) > I'm not sure what to make of these. The build failure says that it thinks > it got a log4cpp that's older than version 1.0, but the version in Ubuntu > is the same as the version in Debian. gcc argument order: g++ -o conftest -pthread -g -O2 -Wall -O2 -DNDEBUG -pthread -g -O2 -g -Wall -O2 -O2 -DNDEBUG-L/usr/lib -llog4cpp -lnsl -Wl,-Bsymbolic-functions conftest.cpp -lz >&5 /tmp/ccnWkLI6.o: In function `main': /tmp/buildd/opensaml2-2.3/conftest.cpp:35: undefined reference to `log4cpp::Category::getInstance(std::basic_string, std::allocator > const&)' /tmp/buildd/opensaml2-2.3/conftest.cpp:36: undefined reference to `log4cpp::eol(log4cpp::CategoryStream&)' /tmp/buildd/opensaml2-2.3/conftest.cpp:36: undefined reference to `log4cpp::CategoryStream::operator<<(log4cpp::CategoryStream& (*)(log4cpp::CategoryStream&))' /tmp/buildd/opensaml2-2.3/conftest.cpp:35: undefined reference to `log4cpp::CategoryStream::~CategoryStream()' /tmp/buildd/opensaml2-2.3/conftest.cpp:35: undefined reference to `log4cpp::CategoryStream::~CategoryStream()' collect2: ld returned 1 exit status This will work: g++ -o conftest -pthread -g -O2 -Wall -O2 -DNDEBUG -pthread -g -O2 -g -Wall -O2 -O2 -DNDEBUG conftest.cpp -L/usr/lib -llog4cpp -lnsl -Wl,-Bsymbolic-functions -lz Looks like autoconf's fault. SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 465 6908 C: +27 72 419 8559 UCT: x3127 -- 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/20101203221332.gk11...@bach.rivera.co.za
Re: RFA: all my packages
Hi Decklin (2011.02.11_00:11:05_+0200) > python-beautifulsoup and mpd need attention for proposed-updates; I > missed getting them into Squeeze. rxvt-unicode is a total clusterfuck. I'm happy to take beautfulsoup (and share it with DPMT) What were you considering for proposed-updates? 3.2? That would probably cause regressions for anyone who has worked around the pain that 3.1 brought. I can't see this easily getting into proposed-updates, but I'm happy to investigate... Reuben: I'm willing to co-maintain the netcats too. SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 465 6908 C: +27 72 419 8559 UCT: x3127 -- 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/20110211080058.gj1...@bach.rivera.co.za
Re: new scripts and patches for devscripts
Hi James (2011.03.10_21:34:51_+0200) > I completely agree that rewriting the tools isn't a useful effort. I > was more concerned that there had been significant development done on > scripts that were intended to be proposed to devscripts and yet were > intentionally being written in a language that I had previously > expressed to Benjamin wasn't used in devscripts. I've done development on them while they were in u-d-t, because they had issues that needed fixing, or new features I/other people wanted, and I don't care *that* much which package they live in. Yes, some of the scripts have always intended to be proposed for devscripts, but that was no reason not to work on them. Especially when getting them into devscripts was going to run into this language barrier... I've even rewritten some u-d-t Perl scripts in Python, so they could take advantage of Python libraries we'd already implemented, rather than have to implement the same things in multiple languages. (Also, my Perl is pretty poor, I'm much more productive in Python). > Last we spoke, he wasn't comfortable with Perl, so while they may > support their scripts within devscripts, how much does it really buy > for the devscripts package as a whole? It's a fair point. My perl isn't great, and I can't suddenly see myself suddenly getting deeply involved in devscripts. Of course the future is hard to predict, but I'm not planning on sharpening my perl skills. SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 465 6908 C: +27 72 419 8559 UCT: x3127 -- 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/20110310205005.gr24...@bach.rivera.co.za
Re: SV: MATE 1.8 has now fully arrived in Debian
Hi Matthias (2014.06.26_08:38:09_+0200) > Of these, roughly 20% have switched to systemd. And they apparently did not > and do not have any problem with it, otherwise we'd hear about it. Here and > other places. Quite loudly. Not necessarily. My laptop won't boot with systemd, although other machines I have will. I haven't filed a bug, because I haven't had the time to sit down and learn how to debug systemd booting, and I wouldn't want to file an bug until I know what's going on... SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 461 1230 C: +27 72 419 8559 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140701061541.gc3...@bach.rivera.co.za
Bug#668606: ITP: python-flexmock -- Mock/Stub/Spy library for Python
Package: wnpp Severity: wishlist Owner: Stefano Rivera * Package name: python-flexmock Version : 0.9.3 Upstream Author : Herman Sheremetyev * URL : http://has207.github.com/flexmock/ * License : BSD-2-clause Programming Lang: Python Description : Mock/Stub/Spy library for Python flexmock is a testing library for Python that makes it easy to create mocks, stubs and fakes. The API is inspired by a Ruby library of the same name, but Python flexmock is not a clone of the Ruby version. It omits a number of redundancies in the Ruby flexmock API, alters some defaults, and introduces a number of Python-only features. flexmock's design focuses on simplicity and intuitiveness. This means that the API is as lean as possible, though a few convenient short-hand methods are provided to aid brevity and readability. flexmock declarations are structured to read more like English sentences than API calls, and it is possible to chain them together in any order to achieve high degree of expressiveness in a single line of code. -- 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/20120413121508.ga3...@purcell.lan
Bug#711220: ITP: foodcritic -- Lint tool for Chef cookbooks
Package: wnpp Severity: wishlist Owner: Stefano Rivera * Package name: foodcritic Version : 2.1.0 Upstream Author : Andrew Crump * URL : http://acrmp.github.io/foodcritic/ * License : Expat Programming Lang: Ruby Description : Lint tool for Chef cookbooks Foodcritic has two goals: To make it easier to flag problems in your Chef cookbooks that will cause Chef to blow up when you attempt to converge. This is about faster feedback. If you automate checks for common problems you can save a lot of time. To encourage discussion within the Chef community on the more subjective stuff - what does a good cookbook look like? Opscode have avoided being overly prescriptive which by and large I think is a good thing. Having a set of rules to base discussion on helps drive out what we as a community think is good style. I intend to package this within pkg-ruby-extras -- 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/20130605160212.ga2...@purcell.lan
Bug#649477: ITP: unidecode -- ASCII transliterations of Unicode text (Python module)
Package: wnpp Severity: wishlist Owner: Stefano Rivera * Package name: unidecode Version : 0.04.9 Upstream Author : Tomaz Solc * URL : http://pypi.python.org/pypi/Unidecode * License : GPL-2+ Programming Lang: Python Description : ASCII transliterations of Unicode text (Python module) It often happens that you have text data in Unicode, but you need to represent it in ASCII for display. One could represent non-roman Unicode characters as "???" or "\\15BA\\15A0\\1610", but neither is useful to the user reading the text. Unidecode tries to represent it in ASCII characters (i.e., the universally displayable characters between 0x00 and 0x7F), where the compromises taken when mapping between two character sets are chosen to be near what a human with a US keyboard would choose. This module generally produces better results than simply stripping accents from characters (which can be done in Python with built-in functions). It is based on hand-tuned character mappings that for example also contain ASCII approximations for symbols and non-Latin alphabets. unidecode is a Python port of the Text::Unidecode Perl module. This will be packaged under the Debian Python Modules Team. -- 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/2021092425.ga26...@dvorak.kardiogramm.lan
Re: Ownership issue when repacking source in get-orig-source target
Hi Andreas (2012.01.13_23:07:52_+0200) > I wonder whether we should rather implement a fool proof solution which > can be simply used in get-orig-source targets (and as well in uscan). I started hacking on something like this in December, but quickly got bored. Here's what I did: http://anonscm.debian.org/gitweb/?p=users/stefanor/repack-source.git Interested? I was also trying to solve the timestamp problem, so that +dfsg / +ds repacks could be done reproduceably. It's in python3, which is no good for devscripts, but porting it back to 2.7 wouldn't be that hard. SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 465 6908 C: +27 72 419 8559 UCT: x3127 -- 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/20120114084129.ge27...@bach.rivera.co.za
Re: dpkg-source again broken wrt to 3.0 (quilt)???
Hi Norbert (2012.01.18_15:18:27_+0200) > Since we are at quilt 3.0 bashing: Maybe you can give me a rational > why I *ALWAYS* have to type in > export QUILT_PATCHES=debian/patches > before working with debian source packages? Because you haven't set up a .quiltrc? The maint-guide has a really nice example you can steal. SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 465 6908 C: +27 72 419 8559 UCT: x3127 -- 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/20120118132425.gb14...@bach.rivera.co.za
Re: Teams in changelog trailers
Hi Simon (2012.02.19_17:03:17_+0200) > It seems to me that the changelog is not the place for that information. > Its purpose is to document the changes made to the packaging, which is > totally orthogonal to whether it has been uploaded and by whom. Uploading is a fairly important change in the packaging, and it's useful to know who made the decision to upload. In the case of sponsored uploads, that is the contributor that requested the upload, not necessarily the person who made all the changes. > The chain of trust that lead to the changes being accepted into the > archive are only useful for internal purposes, AFAICT, and thus should > not be into the package. That's the GPG signature. It's not part of the changelog. I often end up with: [Maintainer] * foo [Contributor] * Team Upload * bar -- Contributor <...> ... which works well for me. SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 465 6908 C: +27 72 419 8559 UCT: x3127 -- 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/20120219151408.go14...@bach.rivera.co.za
Re: Mandatory -dbg packages
Hi Tzafrir (2012.10.29_16:29:06_+0200) > While clearing your throat, mind telling us how this works in Ubuntu > with PPAs? What happens if you installed a package from a PPA and you > want to generate a backtrace of a program that happens to use that > package? > > 1. You'll get debug information for the package. > 2. You won't get debug information for the package. > 3. You may accidentally get debug information for a diffent version of >the package. 2. It'll tell you that there aren't any debug symbols available. (IIRC) The -dbgsym packages are only generated in primary archive builds. SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 461 1230 C: +27 72 419 8559 -- 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/20121029145730.gd1...@bach.rivera.co.za
Re: Mandatory -dbg packages
Hi Andrej (2012.10.29_17:18:41_+0200) > >The -dbgsym packages are only generated in primary archive builds. > > I'm sorry to disappoint you about the Ubuntu PPAs but look into my > PPA - https://launchpad.net/~andrej-rep/+archive/ppa/+packages - to see > all those dbg packages. And users were used them to give me feedback to > bugs with full backtrace. I was talking about ddebs, the -dbgsym package generated by https://launchpad.net/pkg-create-dbgsym Not -dbg packages, manually generated in the package build. See also http://wiki.debian.org/AutomaticDebugPackages SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 461 1230 C: +27 72 419 8559 -- 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/20121031094731.gf1...@bach.rivera.co.za
Re: Retrieving source package from repository without touching sources.list?
Hi Paul (2013.01.15_12:42:54_+0200) > > It's called pull-debian-source > Sounds like something that should be moved into devscripts. It uses Launchpad to authenticate packages without having to fetch and read Packages and InRelease itself, so it probably couldn't go into devscripts as-is. SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 461 1230 C: +27 72 419 8559 -- 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/20130115104907.gh1...@bach.rivera.co.za
Bug#700084: ITP: python-cffi -- Foreign Function Interface for Python calling C code
Package: wnpp Severity: wishlist Owner: Stefano Rivera * Package name: python-cffi Version : 0.5 Upstream Author : Armin Rigo * URL : http://pypi.python.org/pypi/cffi/ * License : Expat Programming Lang: Python, C Description : Foreign Function Interface for Python calling C code Foreign Function Interface for Python calling C code. The aim of this project is to provide a convenient and reliable way of calling C code from Python. It keeps Python logic in Python, and minimises the C required. It is able to work at either the C API or ABI level, unlike most other approaches, that only support the ABI level. -- 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/20130208131846.ga23...@purcell.lan
Re: Bug#733029: dpkg-buildpackage: disable signing by default (-us -uc should be the default)
Hi Jonathan (2014.01.02_19:22:33_+0200) > > * having to support remote signing > > It would be fair enough to stderr "not supported, please use the older > tool in devscripts" and error 1 if such an argument was provided. That > would be pragmatic if (as I suspect) -r is rarely used. Aww. I'm a frequent user of -r. I have better places to build big packages than on my lap, and I prefer to keep my GPG key in as few places as possible. But of course, this could be replaced by a new remote signing wrapper. And, if popular enough, end up in devscripts... SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 461 1230 C: +27 72 419 8559 -- 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/20140104175405.ga7...@bach.rivera.co.za
Bug#735469: ITP: chef-zero -- in-memory Chef server (for testing and solo purposes)
Package: wnpp Severity: wishlist Owner: Stefano Rivera * Package name: chef-zero Version : 2.0.1 Upstream Author : Opscode, Inc. * URL : https://github.com/opscode/chef-zero * License : Apache-2.0 Programming Lang: Ruby Description : in-memory Chef server (for testing and solo purposes) Chef is a systems integration framework and configuration management library written in Ruby. Chef-zero is a self-contained, easy-setup, fast-start in-memory Chef server for testing and solo setup purposes. chef-zero is a dependency of chef 11. Package is prepared in pkg-ruby-extras git. -- 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/20140115154449.ga22...@purcell.lan
Re: Building/testing on s390x
Hi Xavier (2014.04.13_16:44:50_+0200) > As far as I can see, neither zandonai nor zani can be accessed by DD, DDs can't access buildds, only a few admins can. > and zelenka does not have any way to build (yet ?), or did I miss > something ? zelenka looks fine to me. Did you read the MOTD? https://dsa.debian.org/doc/schroot/ SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 461 1230 C: +27 72 419 8559 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140413145215.ga3...@bach.rivera.co.za
Re: Behaviour of dpkg-source with "3.0 (quilt)" and VCS and automatic patches
Hi Scott (2011.05.31_12:58:05_+0200) > This fits my mental model of being a distribution developer. It > cleanly separates upstream code from packaging except when I choose to > entangle them by applying the patches. > > I know others view it differently. I'm not trying to say they are > wrong, just that source format v3 is not a good fit with my mental > model. This is why I generally avoid it in packages I maintain. That's my model too, and I find v3 works well, combined with merge-mode VCS (i.e. containing only /debian). Of course, this only applies to one's own packages, not QA work. If your patches are simple enough to not be too conflicted by new upstream releases, there's really no need to do complex VCS dancing. I appreciate that this may not be the case for more complex packages. SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 465 6908 C: +27 72 419 8559 UCT: x3127 -- 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/20110531124344.gl14...@bach.rivera.co.za
Re: Uploading to multiple distros
Hi Ian (2011.06.02_14:54:37_+0200) > I wasn't aware of syncpackage. The manpage is quite discouraging. It's discouraging for a reason, the Ubuntu archive admins would prefer that we sync packages through them if possible (which results in ~1 days wait). An API method for syncing (+ a button on launchpad) is supposed to be available really soon now™. > Hrm. So syncpackage generates a .changes for uploading to ubuntu from > the .dsc (which presumably came out of the Debian build). That does > mean though that the Ubuntu target suite is not visible in the > changelog of the ultimate Ubuntu package. And if the package is not > accepted into the Debian archive for any reason, the changelog is very > misleading because it looks like a sync from Debian. Yes. It tries to do the same thing as the archive admins' sync script. And obviously it can easily mislead people, which is why it should be used with care, and has a big warning in the manpage. > One way to enable simultaneous uploads would be to arrange for > dpkg-genchanges to filter out suites for "other" distros when > generating the .changes file. Then you would have the same files > being uploaded but two different .changes files. Excepting the changelog bit, that's effectively what syncpackage does. It doesn't modify anything except the .changes file, if possible. SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 465 6908 C: +27 72 419 8559 UCT: x3127 -- 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/20110602131914.go14...@bach.rivera.co.za
Re: Behaviour of dpkg-source with "3.0 (quilt)" and VCS and automatic patches
Hi Scott (2011.06.02_16:30:13_+0200) > Keeping local_options in a VCS is a bit of a workaround for this ... > I'd really like to have a way to just control this globally on my system. +1 to that. Esp for team-maintained packages where people have different preferences, and QA work. SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 465 6908 C: +27 72 419 8559 UCT: x3127 -- 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/20110602145032.gp14...@bach.rivera.co.za
Re: Looking for seconds to add the Amazon EC2 public certificate in ca-certificates.
Hi Miguel (2011.08.23_22:34:47_+0200) > AFAIK, this certificate is only used to encrypt your AMIs and transfer them > securely to Amazon. In this way only you and Amazon know about the content > of your AMI, Amazon needs this in order to launch your AMIs in their cloud. That's what I've heard (although non-definitively) from someone who used to maintain ec2-ami-tools for Amazon. And as Russ asked: > Hm, then it's not actually a CA, is it? Correct. It's just some public key material for encryption. SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 465 6908 C: +27 72 419 8559 UCT: x3127 -- 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/20110824114028.gk1...@bach.rivera.co.za
Bug#918513: ITP: soupsieve -- A modern CSS selector implementation for BeautifulSoup
Package: wnpp Severity: wishlist Owner: Stefano Rivera * Package name: soupsieve Version : 1.6.2 Upstream Author : Isaac Muse * URL : https://github.com/facelessuser/soupsieve * License : MIT/Expat Programming Lang: Python Description : A modern CSS selector implementation for BeautifulSoup Soup Sieve is a CSS selector library designed to be used with Beautiful Soup 4 (python-bs4 in Debian). It aims to provide selecting, matching, and filtering using modern CSS selectors. Soup Sieve currently provides selectors from the CSS level 1 specifications up through the latest CSS level 4 drafts (though some are not yet implemented). Soup Sieve was written with the intent to replace Beautiful Soup's builtin select feature, and as of Beautiful Soup version 4.7.0, it now is 🎊. Soup Sieve can also be imported in order to use its API directly for more controlled, specialized parsing.
Re: Behavior change for Python packages built with CMake
Hi Simon (2023.07.27_13:24:53_+) > Is "deb_system" and not "deb" the canonical thing to use here? The GNOME > team has been using "DEB_PYTHON_INSTALL_LAYOUT = deb" to work around > the corresponding issue with Meson-built packages. Historically it's always been deb. > > The patched sysconfig and distutils.sysconfig modules in Debian > > have a (somewhat poorly documented) override for package > > builds: set the DEB_PYTHON_INSTALL_LAYOUT environment variable to > > "deb_system". This is used internally by pybuild > > Would it make sense for debhelper to set this, either unconditionally > or in a sufficiently new compat level, and either unconditionally or > for the cmake and meson build systems? That would be OK. I think the right thing to do is to patch build-systems that are aware of prefixes to understand Debian's python schemes. Either in Debian or upstream, as appropriate. We want to preserve the property that things install to /usr/local by default, and to /usr only by explicit request. That's what I've pursued, so far. Maybe the right thing to do is to change the sysconfig.get_path API (#1041778) to select a scheme for you. But I'm hesitant about that approach. It would probably fix a number of these build systems in one stroke, but it's a little more magic. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
pybuild now supports meson
FYI: The latest upload of dh-python to unstable (6.20230802) includes a meson plugin, so pybuild can easily build a package multiple times for all supported Python modules. It should detect meson from the presence of a meson.build file. And it'll re-execute dh's meson driver for the build step for each Python version. Hopefully that helps... (and doesn't cause unexpected FTBFSs) Stefano CCed teams of maintainers of packages matching: grep-dctrl -F Build-Depends,Build-Depends-Arch,Build-Depends-Indep \ -s Package,Build-Depends,Build-Depends-Arch,Build-Depends-Indep \ -e '(\s|^)meson(\s|$)' | \ grep-dctrl -F Build-Depends,Build-Depends-Arch,Build-Depends-Indep \ -s Package \ -e '(\s|^)python3(-all)?(-dev)?(\s|$)' Debian GNOME Maintainers gedit gi-docgen gnome-music gtk-doc libgom libpeas rhythmbox totem Debian Input Method Team keyman Debian Python Team gtg meson-python Eberhard Beilharz keyman (U) Emilio Pozuelo Monfort gtk-doc (U) libpeas (U) rhythmbox (U) FingerForce Team libfprint Francois Mazen gtg (U) Iain Lane gnome-music (U) gtk-doc (U) libpeas (U) Jeremy Bicha gtk-doc (U) libgom (U) Jeremy Bicha gedit (U) gnome-music (U) rhythmbox (U) totem (U) Jeremy Bícha libpeas (U) Jordi Mallach rhythmbox (U) Keyman team keyman (U) Laurent Bigonville gedit (U) gnome-music (U) libgom (U) libpeas (U) rhythmbox (U) totem (U) Maintainers of GStreamer packages gst-python1.0 Marco Trevisan libfprint (U) Michael Biebl gtk-doc (U) libgom (U) libpeas (U) rhythmbox (U) totem (U) Sebastian Dröge gst-python1.0 (U) pitivi Simon McVittie gi-docgen (U) meson-python (U) xdg-desktop-portal (U) Sjoerd Simons libpeas (U) Tim Lunn gnome-music (U) gtk-doc (U) Ulises Vitulli libfprint (U) Utopia Maintenance Team xdg-desktop-portal -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Potential MBF: packages failing to build twice in a row
Hi Sven (2023.08.05_19:01:19_+) > It might be worth to consider changing your workflow a bit and work with > a git repository. It does not have to be a clone of the repository (if > any) where the package is maintained, you can start with a fresh import, > e.g. with "gbp import-dsc". > > Then before building the package for the first time, commit or at least > stash your changes, and you can go easily back to a clean state with > "git reset --hard; git clean -fdqx". I find myself in the same position as Wookey, here. I will work with the git tree (if it exists) most of the time when I'm touching a package I've never touched before. Unless the repository is unreasonably big, or broken. However, when it fails to build, it's inside my build environment, not a git tree. It's nice to be able to troubleshoot the build in there, rather than have to spin up a new build (and install build-deps etc.). So I find myself having to fix the clean target to continue to work on the package. This is annoying, it would be nice if packages cleaned correctly. Personally, I have my sbuild configured to build a source package after the build, so that I can be sure that I don't regress my own packages' clean target. It would be nice if this was a default feature in sbuild, for most packages this is a very quick process. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Preparing for Python 3.12
Hi Matthias (2023.12.03_14:03:44_+) > We probably will see some Python related build failures while binNMUing > around 600 packages to add 3.12 as a supported version. If you see builds > failing because of a missing 3.12 extension, please just wait a few days > until all the binNMUs are done. > > For the progress, see (ignoring the 'unknown' status) > https://release.debian.org/transitions/html/python3.12-add.html This is a great time for new Python Team contributors to get involved in helping to support Python 3.12. This is a time when upstream Python knowledge can be more helpful than Debian packaging experience. Look go down the list of packages and investigate the ones with a red line. Either they have failed to build (top of the list) or they haven't been built against 3.12 yet (bottom of the list). As we investigate these, we'll file FTBFS bugs against them (which usually show up on buildd.debian.org, below the builds). Usually the process is: 1. Read the bug to see the investigation so far. 2. Check the upstream bugtracker for related bugs. 3. See if there is a new upstream release or commit that promises to support Python 3.12 (or whatever the issue is). 4. Report back on the bug 5. Prepare an upload. We're mostly coordinating in #debian-python on IRC. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Run Debian packaging tasks remotely with debusine.debian.net
Hi Martin (2024.03.09_11:43:54_+) > thank you for this project, it looks very interesting. Would you also > support running ratt there? For some packages ratt often fails on my local > machines due to RAM constraints. We are building out the pieces that will lead to being able to reimplement ratt within Debusine. Running ratt as a single debusine job wouldn't make as much sense as running a single build for each changed reverse dependency. We just landed support for sbuild's --extra-package= argument [0], which is the building block needed for ratt-style builds. I intend to script something to schedule all the builds for a new reverse dependency, soon. I have reverse-dependencies I want to test. [0]: https://salsa.debian.org/freexian-team/debusine/-/issues/320 Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Validating tarballs against git repositories
Hi Guillem (2024.03.30_04:41:37_+) > > 1. Move towards allowing, and then favoring, git-tags over source tarballs > > I assume you mean git archives out of git tags? Otherwise how do you > go from git-tag to a source package in your mind? There are some issues with transforming upstream's git-centric world into tarballs for Debian source packages, that are worth bearing in mind. The upstream git repository has some extra metadata available that upstream build tools start depending on. Things like: versions, tracked files, and ignored files. This came up in the Python world, where setuptools-scm has become more popular over the years. This is a plugin for setuptools that extracts some metadata from the git repository: 1. Determine the current version. Historically, specified in setup.py. 2. Determine the data files that should be shipped in the installed package. Historically, these were specified in a MANIFEST.in file, but developers got lazy and delegated this problem to git. Currently we set the version for packages that depend on 1 by an environment variable that setuptools-scm will consume. For packages that get file lists from git, it's a little more complex. setuptools writes a foo.eggi-info/SOURCES.txt into source artifacts that it produces (sdists). When this file is present, it's used as a list of files. https://setuptools.pypa.io/en/latest/deprecated/python_eggs.html#sources-txt-source-files-manifest So... for Python packages using setuptools-scm, we're pushed towards depending on upstream-created source tarballs (sdists), rather than upstream git archives, because we don't have the ".git" directory in our source packages. I can imagine that other ecosystems would run into similar problems and solve them by inventing similar protocols, if they solve them at all. Upstreams would probably prefer that we used git repositories *directly* as source artifacts, but that comes with a whole other can of worms... Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Validating tarballs against git repositories
Hi Thomas (2024.04.02_22:33:47_+) > Anyways, on the 400+ packages that I maintain within the OpenStack team, I > did come across some upstream using setuptools-scm. To my experience, using > the: > > git archive --prefix=$(DEBPKGNAME)-$(VERSION)/ $(GIT_TAG) \ > | xz >../$(DEBPKGNAME)_$(VERSION).orig.tar.xz > > workflow out of an upstream always work, including for those that are using > setuptools-scm. Then you haven't come across any that are using this mechanism to install data, yet. You're only seeing the version determination. You will, at some point run into this problem. It's getting more popular. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: About Package Maintenance (was: Question to all candidates: What are your technical goals)
Hi Marc (2024.04.08_16:48:13_+) > I have also noticed that the young people we manage to recruit are > usually not interested too much in the boring gruntwork of maintaining > important core packages (like adduser and sudo) but instead want to do > "new" things. But, otoh, what would Debian be without sudo? Somebody > needs to do that work as well. To some degree, this is self-fulfilling. Most core packages have a maintainer. Drive-by contributions in a bug or MR are likely to go ignored for years. Newbies aren't going to get pulled into these packages, easily. Where core packages are up for adoption, they're probably pretty complex and maybe not the best candidate for a new contributor. The best stuff has probably already been adopted. All of this leads to the position we are in, where new contributors best road into the project is into teams. And the best way to get some experience is packaging something new in a team. I see one of the goals of promoting team maintenance as increasing the pipeline of new contributors into the maintenance of core infrastructure. Rather than having to wait for the current maintainers to slowly fade away and salvage the result after years of problems. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: finally end single-person maintainership
Hi Philip (2024.05.21_10:05:59_+) > Attempts at top-down imposition of new methods on Debian strike me as > being unlikely to induce joy in anyone involved. Yeah, that doesn't fly in community projects like Debian at all. However, there is a gap between getting a DEP approved and getting the rest of the project to fully embrace it. That's something that takes some leadership in the project. DPLs are in a great position to help drive these changes forward. > I suspect that there's a decent chunk of developers who generally just > follow the status quo of every package they work on, without fuss. Yeah, probably most. > I rather like dgit for reducing the extent I have to think about this > sort of thing, but I note that at least one person in this thread seems > vexed by it, so we cannot even agree on the merits of that, apparently. On the other hand, dgit is only useful if you have a certain view of the world, that hasn't aligned with how I've done Debian packaging. I mean, an entirely git-centric view where you let go of trying to maintain your patch stack. So, I've only very briefly played with it. I imagine many in the project have similarly little experience using it. The tricky thing with tools like this is that you need to invest a lot of time using the tool to really get a feel for what it's good / bad at. You probably need to use it to maintain a complex package, for a while. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: t64 suffix
Hi Mathieu (2024.05.23_18:14:20_+) > What is expected from Debian packager now ? > > 1. Remove the t64 suffix upon next version upload ? You can remove it at the next SONAME transition (ABI bump) > 2. Keep the package-name-doesnt-match-sonames lintian warning (for now) ? That should only occur on architectures that weren't impacted by the t64 migration. I imagine t64 could be explicitly ignored in lintian (and someone has probably filed a bug about that). Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: MBF: Building packages in the (not so distant) future
Hi Scott (2024.05.26_17:43:54_+) > The clamav issue looks like a false positive. The distro-info data > will get updated between now and then. Same goes for distro-info, itself. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Making Debian available
Hi Andrey (2021.01.17_13:16:04_+) > On Sun, Jan 17, 2021 at 11:33:28AM +0100, Marc Haber wrote: > > My workaround is to plug in a network cable for installation. But > > alas, I have up to now been able to avoid hardware without built-in > > Ethernet. I guess that many USB Ethernet interfaces will work out of > > the box without non-free, right? > I think people on Reddit usually recommend USB-tethering the cell phone. This is a useful trick to know, and has served me well for many years. But, assuming this is the best option we can provide for a user, it should be more than a trick - the installer should probably suggest it. Something along the lines of: Unable to find an Internet connection. You may have a network interface that requires non-free firmware to operate. If you have a mobile phone connected to WiFi try plugging it in with a USB cable and enabling "USB tethering" to share its internet connection. You can use this to get Debian installed and then install the non-free firmware package your network interface requires. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#994279: ITP: pyreflink -- Python Library wrapping platform-specific reflink implementations
Package: wnpp Severity: wishlist Owner: Stefano Rivera X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: pyreflink Version : 0.2.1 Upstream Author : Ruben De Smet * URL : https://gitlab.com/rubdos/pyreflink * License : Expat Programming Lang: Python (CFFI C extensions) Description : Python Library wrapping platform-specific reflink implementations Python wrapper around the ``reflink`` system calls. . Features: . * Btrfs, XFS, OCFS2 ``reflink`` support. Btrfs is tested the most. * Apple macOS APFS ``clonefile`` support. Little testing, be careful. It might eat data. * A convenience method that checks support for reflinks within a specific directory. I intend to maintain this under the Debian Python Team, as a dependency of the beets testsuite.
Re: Search content (.h files) of all (-dev) packages?
Hi Alexander (2021.11.12_10:58:19_+) > The result is a bit astonishing. I have not checked for false positives yet. > But the initial search gave 650 affected source packages. I expected perhaps > 15 packages, which I fix then. However, that is 2.5% of the actual amount, 40 > times more than envisioned. Any idea how to tackle that? Usually: Mass rebuild them all, against the new doxygen, and then do a mass-bug-filing against the ones that FTBFS, describing the issue and how to fix it. I usually spin up a cloud instance for something like this, if it's a lot of packages. You can also ask Lucas for help doing mass builds, I think? https://wiki.debian.org/MassRebuilds SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
New pybuild plugin for PEP-517 pyproject.toml projects
The Python world has developed new standards for building and
distributing modules. The previous approach of running setup.py has been
replaced by a build API described in PEP517 (and some associated
documents).
An increasing number of projects now use this approach to building -
there is no setup.py in the source package but instead a pyproject.toml
file that lists the build tools and build dependencies that are to be
used. In some cases, a vestigial setup.py is kept for compatibility, but
the upstream expects the package to be built without it.
With the upload of dh-python 5.20211213, we now have an *experimental*
plugin that should be able to build all pyproject.toml packages. The
plugin has been designed to feel as similar to the previous distutils
(setup.py) plugin as possible. To select this plugin:
- Remove any patches creating a workaround setup.py for the project
- Build-depend on `dh-python-pep517` as well as any build tools
specified by upstream in pyproject.toml (in build-system.requires)
such as python3-setuptools, flit, or python3-poetry-core
- debdiff or diffoscope the resulting deb to check that it isn't
missing anything / including things it shouldn't
You'll notice that the binary package contains a .dist-info directory,
rather than .egg-info. This is expected, and fulfils the same purpose
with a better-defined structure. Your package should include this
.dist-info directory if it provides a public Python module. As we expect
.dist-info to become more common, we have improved .dist-info parsing in
this dh-python upload. If you had to previously explicitly specify
binary package dependencies, you may find that you don't need to any
more. dh_python3 --depends-section=SECTION now supports dist-info extra
sections, too.
Since this is a new plugin and somewhat experimental, an explicit opt-in
is required. It is anticipated that this plugin will eventually replace
the distutils plugin in situations where both pyproject.toml and
setup.py exist as well as the specialized flit plugin that was included
in bullseye. This plugin has so far been tested against packages using
setuptools, scons, flit and poetry-core as build backends, and against
packages that are pure python and ones containing C extensions; however,
further testing and bug reports are most welcome ("reportbug dh-python";
discussion in #debian-python on irc.oftc.net).
For the curious, the plugin sequence is as follows
- build step: invokes the upstream build backend (using the
python3-build module) and unpacks the wheel created by the build
(using the python3-installer module) into the pybuild {build_dir}.
Scripts and entry points should be available after this stage.
- test step: runs just like the distutils plugin
- install step: copies the files into debian/tmp or debian/package
as requested by debhelper
Thanks to the many contributions that went into this work, in
particular Stuart Prescott, Stefano Rivera, and Scott Kitterman.
regards,
Debian Python People
Further reading:
PEP517 and related:
https://www.python.org/dev/peps/pep-0517/
https://www.python.org/dev/peps/pep-0518/
https://www.python.org/dev/peps/pep-0621/
pybuild documentation:
https://salsa.debian.org/python-team/tools/dh-python/-/blob/master/pybuild.rst
pybuild plugin:
https://salsa.debian.org/python-team/tools/dh-python/-/blob/master/dhpython/build/plugin_pep517.py
Re: Cloud team plans for cloud-hosted mirrors
Hi Ross (2022.01.26_05:47:49_+) > Our first choice would be a subzone of debian.org. But we are not in DSA, and > haven't been able to get help with this request. So in the interest of making > progress, a new domain is the simplest alternative. FWIW, DSA has the ability to host domains in DSA's DNS and delegate git zone access to non-DSA DDs. This is how debconf.org DNS is handled. So, there is a path to bring external domains under the DSA umbrella, later. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#1005257: ITP: hatchling -- Python package build backend used by Hatch
Package: wnpp Severity: wishlist Owner: Stefano Rivera X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: hatchling Version : 0.11.2 Upstream Author : Ofek Lev * URL : https://ofek.dev/hatch/ * License : Expat Programming Lang: Python Description : Python package build backend used by Hatch This is the extensible, standards compliant build backend used by Hatch. It may be required to build a Python module from source. I intend to package it under the Debian Python Team.
Bug#1009986: ITP: hatch-vcs -- Hatch plugin for versioning from VCS
Package: wnpp Severity: wishlist Owner: Stefano Rivera X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: hatch-vcs Version : 0.2.0 Upstream Author : Ofek Lev * URL : https://pypi.org/project/hatch-vcs/ * License : Expat Programming Lang: Python Description : Hatch plugin for versioning from VCS This provides a plugin for Hatch that uses your preferred version control system (like Git) to determine project versions. It may be required to build a Python module from source. It's the hatch-equivalent of setuptools-scm (which it uses). I'll package it under the Debian Python Team.
Re: Bug#1014908: ITP: gender-guesser -- Guess the gender from first name
Hi Enrico (2022.07.16_08:17:11_+) > I think the right way to get the statistics you're looking for would be > to ask speakers to state their own identity on pentabarf, so that > statistics are based on self-determination, rather than external > overrides of it. If you're asking about DebConf 22, we have that information: count | gender ---+-- 21 | Decline to State 56 | Male 2 | Non-Binary 9 | Female (4 rows) I guess we should expose this in our conference statistics. We care about it. If you want similar data for DebConfs since 16, we can get that, too. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Bug#1014908: ITP: gender-guesser -- Guess the gender from first name
Hi Holger (2022.07.16_09:42:56_+) > but why? how is gender relevant for participating in DebConf as > a whole? (i can see how it could be relevant for some events, but > not for the whole conference.) It's not. It's for statistics, as we say when we collect it. I think it's our business, as a community, and as conference organisers, to try to increase the diversity at our events. To me, that means increasing speaker diversity, primarily. Attendee diversity won't change unless the speaker diversity changes. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Bug#1014908: ITP: gender-guesser -- Guess the gender from first name
Hi debian-devel (2022.07.16_09:12:16_+) > I guess we should expose this in our conference statistics. We care > about it. And in the future, we will: https://salsa.debian.org/debconf-team/public/websites/wafer-debconf/-/merge_requests/150 SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Bug#1014908: ITP: gender-guesser -- Guess the gender from first name
Hi Philip (2022.07.19_20:51:36_+) > > In other words, if you don't pick a culture, the _global_ dataset (ie, the > > default one) must not assume either. It takes a lot of work to prepare > > such a database, that's why this package is good to have. > > What exactly is it supposed to be good for? Seems perfect for statistics from large data sets. The data in those kind of things is always messy as hell. Full of mistakes and misalignment to whatever lines you are trying to draw through it. But, on aggregate, it does give you results, if you can control for the problems. A lot of research is done like this, "data science" they call it. > From what I can tell, at best it produces harmless nonsense, and at > worst it will cause people to be misidentified in ways that will vary > between mildly humourous to significantly hurtful. On an individual level, but on a large scale, you'd expect things to average out. Unless it has a systemic bias towards any particular output. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Epoch for node-markdown-it
Hi Holger (2022.08.20_00:04:13_+) > On Fri, Aug 19, 2022 at 06:00:44PM +0100, Simon McVittie wrote: > > Epochs cause problems, [...] > > which are? (I agree they are ugly and should often be avoided, but I don't > see any unsolved problems with them, which is why I'm asking.) The standard one is that people use them to revert an upload. But, epochs aren't used in the upstream tarball filename, so you then easily get a conflict between the old and the new one. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Sentry for Debian services?
Hi Bastian (2019.12.25_23:08:40_+) > I don't think we already have a Sentry instance for Debian services > running? Are there other services in need for a Sentry instance? If it were available, I'd probably use it for the DebConf websites. There are bugs, and I don't see them all in the logs. Some personal data there, (conference registration), of course. So maybe people would prefer we didn't send this off to 3rd party services... > I looked at the install documentation[1] and it tells me that I don't > want to run Sentry myself. Any takers? I've run it in the past, when it was just a Django app, with a couple of service dependencies. That was easy. These days it looks like more of a beast :( > Another option may be using the hosted solution, which they give away > gratis to open source projects, which we might be.[2] Had good experience with their hosted solution. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#968644: ITP: python-authlib -- Python library for OAuth and OpenID Connect servers
Package: wnpp Severity: wishlist Owner: Stefano Rivera X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-authlib Version : 0.14.3 Upstream Author : Hsiaoming Yang * URL : https://authlib.org/ * License : BSD-3 Programming Lang: Python Description : Python library for OAuth and OpenID Connect servers The ultimate Python library in building OAuth and OpenID Connect servers. It is designed from low level specifications implementations to high level frameworks integrations, to meet the needs of everyone. There are several Python libraries supporting bits of OAuth/OpenID, etc. This is one of the most complete I've seen, and seems well maintained (if somewhat new). Matrix Synapse uses it for OIDC. Intend to package it under the Debian Python Modules Team.
Bug#832140: ITP: ruby-cucumber-wire -- Wire protocol for Cucumber (a ruby acceptance testing framework)
Package: wnpp Severity: wishlist Owner: Stefano Rivera * Package name: ruby-cucumber-wire Version : 0.0.1 Upstream Author : Matt Wynne * URL : http://cucumber.io * License : Expat Programming Lang: Ruby Description : Wire protocol for Cucumber (a ruby acceptance testing framework) cucumber supports a wire protocol for running tests in separate processes. Not necessarily even ruby processes. This ruby library implements the wire protocol. Previously this was part of the cucumber package, but upstream has broken it out into its own library. I have no particular interest in long term maintenance, I just need it for a selfish cucumber version bump. It will live under the pkg-ruby-extras umbrella, with the other cucumber packages.
Bug#843992: ITP: ruby-knife-acl -- Knife plugin to manupulate Chef server access control lists
Package: wnpp Severity: wishlist Owner: Stefano Rivera * Package name: ruby-knife-acl Version : 1.0.3 Upstream Author : Seth Falcon , Jeremiah Snapp * URL : https://github.com/chef/knife-acl * License : Apache-2.0 Programming Lang: Ruby Description : Knife plugin to manupulate Chef server access control lists
Bug#845107: ITP: hdmi2usb-mode-switch -- Configuration and firmware tool for HDMI2USB devices
Package: wnpp Severity: wishlist Owner: Stefano Rivera * Package name: hdmi2usb-mode-switch Version : 0.0.0+git20161016-1 Upstream Author : Tim 'mithro' Ansell * URL : https://github.com/timvideos/HDMI2USB-mode-switch * License : Apache-2.0 Programming Lang: Python 3 Description : Configuration and firmware tool for HDMI2USB devices This is the tool for flashing and configuring the HDMI2USB devices. It can load a runtime firmware, and write firmware to the device's flash. https://hdmi2usb.tv/ is an open hardware and software project for capturing HDMI video with an FPGA board. This package supports the Digilent Atlys and Numato Opsis boards.
Bug#846185: ITP: ixo-usb-jtag -- Firmware for USB JTAG programmers
Package: wnpp Severity: wishlist Owner: Stefano Rivera * Package name: ixo-usb-jtag Version : 0.0.0+git20160908 Upstream Author : Tim 'mithro' Ansell * URL : https://github.com/mithro/ixo-usb-jtag * License : GPL-2+ Programming Lang: C Description : Firmware for USB JTAG programmers This firmware allows a USB-capable microcontroller to act like an Altera USB-Blaster JTAG pod. Which in turn may allow you to use tools you'd normally use with the Altera USB-Blaster, including UrJTAG and openocd. Supported hardware: The Cypress FX2 EZ-USB family, or an FTDI FT245 in combination with a CPLD. Builds are included for the hdmi2usb project's boards (Digilet Atlys and Numato Opsis).
Bug#895638: ITP: ruby-iso8601 -- Ruby parser to work with ISO 8601 dateTimes and durations
Package: wnpp Severity: wishlist Owner: Stefano Rivera * Package name: ruby-iso8601 Version : 0.10.1 Upstream Author : Arnau Siches * URL : https://github.com/arnau/ISO8601 * License : Expat Programming Lang: Ruby Description : Ruby parser to work with ISO 8601 dateTimes and durations ISO8601 is a simple implementation in Ruby of the ISO 8601 (Data elements and interchange formats - Information interchange - Representation of dates and times) standard.
Bug#895641: ITP: ruby-tomlrb -- A racc based toml parser
Package: wnpp Severity: wishlist Owner: Stefano Rivera * Package name: ruby-tomlrb Version : 1.2.6 Upstream Author : Francois Bernier * URL : https://github.com/fbernier/tomlrb * License : Expat Programming Lang: Ruby Description : A racc based toml parser A Racc based TOML Ruby parser supporting the 0.4.0 version of the spec. This is a dependency of the Chef stack. I intend to package it within the ruby team.
Bug#804350: ITP: vizzini -- Kernel driver for Exar XR21V1414 USB UART
Package: wnpp Severity: wishlist Owner: Stefano Rivera * Package name: vizzini Version : 1.0.0 Upstream Author : Exar Corporation, Inc. * URL : https://github.com/mithro/exar-uart-driver * License : GPL-2+ Programming Lang: C Description : Kernel driver for Exar XR21V1414 USB UART The debconf-video team is using a board with this UART on it for HDMI capture.
Re: Prepare your Sprints for DebCamp16!
Hi debconf-announce (2016.06.15_23:55:42_+0200) > DebCamp16 is taking place in Cape Town, South Africa between Thursday, 23 July > and Friday, 1 July 2016. 23 June to 1 July, obviously :) No amount of review of a proposed e-mail ever actually gets the dates right. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272 signature.asc Description: PGP signature
Alternative signature mechanisms for upstream source verification
Picking up a thread that started on debian-pyt...@lists.debian.org: https://lists.debian.org/msgid-search/14198883.O9o76ZdvQC@galatea Upstreams that care about supply chain security have been building mechanisms to authenticate their releases, beyond PGP signatures. For example, Python started providing sigstore signatures a couple of years ago, and is now talking about the idea of dropping PGP signatures. https://discuss.python.org/t/pre-pep-discussion-stop-providing-gpg-signatures-for-cpython-artifacts/65058 We currently support including PGP signatures in source packages, and verifying them in uscan. Should we expand this to include some of these new mechanisms? Things brought up in the debian-python thread include: 1. sigstore https://docs.sigstore.dev/ 2. ssh signatures 3. signify https://man.openbsd.org/signify.1 There is a general trend towards getting upstream sources from Git rather than tarballs in Debian, but we're a long way from moving across completely, or even finding consensus to do so. These signature mechanisms can generally be applied to git commits as well as tarballs. I see supporting them in Debian requiring: 1. Decisions on which schemes to support. I'd assume we support all that are available in Debian and have some significant use. Some, like sigstore, can be used in multiple modes, we'd have to make some selections. 2. Support in uscan to verify at download/checkout time. 2.1: Syntax in watch files to locate signature files. 2.2: Path in source packages / watch files to declare trusted signers. 2.3: Syntax in watch files for signature verification in git mode. 3. Support in dpkg-source to include detached signatures in source packages. 3.1: Declare expected formats and filename extensions. 4. Support in the archive? (Is anything necessary?) Is this something people are interested in pursuing? For sigstore, we probably need to package the Python / go client in Debian. We have rekor-cli for low-level verification, but not tools for verifying bundles like the ones Python provides. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Alternative signature mechanisms for upstream source verification
Hi Guillem (2024.10.05_01:32:45_+) > > 1. sigstore https://docs.sigstore.dev/ > > Although I've heard of this before, I never really checked what is > the actual design behind it, and its implications. I'm new to all this too, but I can answer some of those questions from my own reading: > I'm not sure how reliant on centralization this is, or on the apparent > specific OIDC providers currently in use The signing process is reliant on centralization. The signature scheme trusts the central server and OIDC provider to identify the signer. It signs that assertion and stores it in a CT log. > about offline operations Verification is possible offline, the bundle includes CT proof. The downside of verifying offline is that you can miss revocation. > and whether that is a first class use, or if that implies limitations, > etc. There are definitely limitations. The set of trusted parties is much larger than when verifying an OpenPGP signature. Instead of relying on the signer maintaining perfect security of their OpenPGP keys, we are relying on the security of their OIDC server & sigstore. Signatures are publicly auditable, so fraudulent signatures are theoretically detectable by the identity owner. There are revocation mechanisms. A system like this has a chance of being widely adopted in software ecosystems in a way that I don't think OpenPGP has any more. > Even though in the Python upstream thread it's mentioned that many > upstreams are moving into using it, it's not clear to me either what > are the long-term prospects of this either. Yep. Hard to say. We can sit on the fence until it becomes obvious. This is how we often do things :) In the meantime, packages like Python may drop OpenPGP in favor of it. That may be a small loss. We weren't even verifying Python's OpenPGP signatures until yesterday. > I've not checked either what is the format of the certificates and > signatures for this, how detectable they are, their size, etc. The bundle format (capable of offline use) is a JSON document with a mediaType key. It's detectable. > From Python upstream and your comment below, I take the only > implementations are either Python or Golang, which seems problematic as > something to have to pull into say a build-essential chroots by default. > (Not to mention that these are not even yet in Debian. :) We can take a slower approach and not include support in build-essential chroots for these newer schemes. Re-evaluate later, if one of them really blows up in popularity. And of course, we should probably just start with uscan, and talk about adding support to dpkg later, when we can see significant use. > > 2. ssh signatures > > AFAIK these are used via ssh-keygen. The signatures are pretty easy to > detect, as they are surrounded by «-BEGIN SSH SIGNATURE-» and > «-END SSH SIGNATURE-» and are ASCII encoded. The certificates > and signatures can be few lines or many lines, but should be > relatively small, probably similar to at most an OpenPGP one. I think > depending on the format the certificates can also be easily detectable. > > I'm not sure I'd be comfortable with having to depend (even weakly) on > openssh-client to be able to work with these. At least the implementation > is portable C so it should be available everywhere, so in theory such > (weak?) dependency would be possible everywhere. I'm not sure how you'd > automatically verify signatures if you need to specify the namespace, > the allowed signers and the signer identity, I guess you'd probably > need to store this alongside as well. And the ssh-keygen CLI seems > rather brittle. :/ > > Is this really being used widely, or much at all? I know it's used in some git tag signing. See: #1023140 Those aren't relevant to dpkg, at all (without git source packages). > > I see supporting them in Debian requiring: > > 1. Decisions on which schemes to support. I'd assume we support all that > >are available in Debian and have some significant use. > > I think that just like some compression formats that might be deemed > not worth the effort, to me this could look similar. > > I also think even then, we could decide that we do not want full > support for all of these, but perhaps still partial support might be > good enough for now. Say shipping the signatures and certs somewhere > that requires no integration infra work, for example, or only > supporting them in say uscan. Yes, I think starting with uscan is the obvious way, but I would want to do so in a way that leaves the way open to support in dpkg later. Ideally without any source package API changes, later. Stefano
Re: [RFH] Running Python tests that require the source to be installed
Hi John (2024.10.26_08:45:15_+) > > tox tests in Debian package builds are a little different because we use > > --system-site-packages virtualenvs, but they can be a good way to deal > > with this. > > Can you name any package using this mechanism so I can have a look? wheel uses tox tests, in about the most straightforward way possible (declare build-depends on tox). Sometimes you'll need to patch tox.ini to add things to allowlist_externals, because we're using --system-site-packages. You'll also need to Build-Depend on everything that tox wants to install into the virtualenv. Some more examples: $ reverse-depends -b tox Reverse-Build-Depends = * anosql * ceph * custodia * diskcache * django-auth-ldap * duplicity * enlighten * flask-jwt-simple * git-imerge * gitsome * gnome-keysign * gubbins * mitmproxy * pytest-datadir * pytest-mypy-plugins * python-django-solo * python-json-log-formatter * python-kdcproxy * python-magic * python-mrcfile * python-nox * python-pkginfo * python-prettylog * python-pyforge * python-pyvmomi * python-versioneer * python-w3lib * pytrainer * rdflib-sqlalchemy * reprotest * sagemath * sagenb-export * sshtunnel * tox-current-env * wheel Reverse-Build-Depends-Indep === * awscli * python-bottle * python-scrapy > > I'm not really experienced with tox, so it would be great to have some > guidance in the form of sample code. > > Adrian > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer > `. `' Physicist > `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 > -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: [RFH] Running Python tests that require the source to be installed
Hi John (2024.10.24_10:44:45_+) > I am maintaining the package src:kiwi [1] which hasn't been updated in > Debian for some time since upstream has added tests that only work when > the package source is installed into the test environment, i.e. available > through PYTHONPATH. If it actually needs the .dist-info to be on path (fully installed), you can try runnig the tests under tox. That's probably what the upstream does. tox tests in Debian package builds are a little different because we use --system-site-packages virtualenvs, but they can be a good way to deal with this. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Python 3.13 addition as a supported Python version started
Hi PICCA (2024.11.13_10:04:26_+) > I am a bit worrying for the scientific stack , will we have enough > time to work with our upstream in order to fix all these FTBFS. In the > scientific stack, things are going slowly The reality here is that Python has a 6-month release cycle, these days. If upstreams can't stay on top of new Python releases, we are stuck with doing the porting work or dropping them from Debian. We can't fix them all in 6 months. There are still a lot of open 3.11 and 3.12 bugs, for example. If we don't have the latest stable version of Python in our stable release, I think a large number of our users will be very disappointed. It would certainly cement the view that Debian ships ancient software. I don't think the users who would be upset would have any motivation to help improve the situation (working on old scientific packages). If we have to drop large numbers of scientific packages in our stable releases, I imagine a small number of users would be disappointed, and hopefully able to see how they can help avoid this situation in the future. Sorry, but I see that as the less bad outcome. I'm not saying I want it, but I think it's the approach we have to take, in the face of unmaintained software. The alternative would be to carry multiple Python releases in a Debian stable release, which is something we haven't wanted to do. We try to start the detection process as early as possible. I have been doing archive wide rebuilds (as much as I could, on arm64) since 3.13 rc2. I announced it, and our planned migration to 3.13 in trixie, in: https://lists.debian.org/msgid-search/20240920072725.mkhi575oydnr6...@satie.tumbleweed.org.za I'm hoping to have even better tooling for this kind of rebuild in the future. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Python 3.13 addition as a supported Python version started
Hi debian-python (2024.11.13_15:01:31_+) > Hi PICCA (2024.11.13_10:04:26_+) > > I am a bit worrying for the scientific stack , will we have enough > > time to work with our upstream in order to fix all these FTBFS. In the > > scientific stack, things are going slowly > > The reality here is that Python has a 6-month release cycle, these days. I mean 12-month, of course. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Building with many cores without OOM
Hi Guillem (2024.12.04_13:03:29_+) > > Are there other layers that could reasonably be used to implement a more > > general form of parallelism limiting based on system RAM? Ideally, we'd > > consolidate these implementations into fewer places. > > I think adding this in dpkg-buildpackage itself would make most sense > to me, where it is already deciding what amount of parallelism to use > when specifying «auto» for example. > > Given that this would be and outside-in interface, I think this would > imply declaring these parameters say as debian/control fields for example, > or some other file to be parsed from the source tree. I don't think this can be entirely outside-in, the package needs to say how much ram it needs per-core, to be able to calculate the appropriate degree of parallelism. So, we have to declare a value that then gets calculated against the proposed parallelism. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Simpler git workflow for packaging with upstreamless repositories
Hi Kari (2024.11.18_15:40:55_+) > - Only store debian/ in the repository and use origtargz for the rest. I used to feel strongly this way, too. However, A big advantage of storing the upstream sources in git is that you can use git to manage the quilt patch queue. I used to be pretty good at editing patches to get them to apply after upstream changed the code, but its painful and slow work. gbp-pq rebase is *infinitely* better. You need to be comfortable in git rebasing. But if you use git, you are probably already a git rebase ninja. You can use those same skills in Debian patch queue maintenance. I'd suggest giving gbp-pq a good try before writing off the gbp stack. Maintaining a complex patch stack is *much* easier with it. I look after packages in both layouts, and I am sold on storing upstream sources in git. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: General Resolution: Interpretation of DFSG on Artificial Intelligence (AI) Models
Hi Mo (2025.05.05_15:15:01_+) "The minimum discussion period is 2 weeks. The maximum discussion period is 3 weeks." This is surprising to me. Does that mean we must start to vote when we reach the maximum discussion period? I just thought I can go back and reply to the detailed issues in the threads after getting through the time trap of paper submission deadline. Read section A.2 of the constitution: you can withdraw your ballot option, and the GR won't happen. Others may pick it up and carry it through to a GR, though. This doesn't stop you from calling a GR later. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
