Re: Is there room for improvement in our collaboration model?
On 15.04.22 15:53, M. Zhou wrote: On Fri, 2022-04-15 at 14:24 +0200, Luca Boccassi wrote: I think this will also improve newcomer's contributing experience. This proposal is also filed at https://salsa.debian.org/debian/grow-your-ideas/-/issues/34 What about doing something even simpler - rather than having additional generic/core tags/teams/groups, for packages where one wants to say "please help yourself/ourselves", simply set the Maintainer field to debian-devel@lists.debian.org, have the Salsa repository in the debian/ namespace, and that's it? From thereon, anyone can do team-uploads by pushing to salsa and uploading directly, no need for acks/delays/permissions/requests. A simpler solution sounds good to me, except that change would be somewhat "permanent" in stating the original maintainer's preference. I forgot to mention in my original post that the tags can optionally expire. So, things like, `tag all my packages as "feel free to nmu" within the next two weeks` would be trackable. The only extra request from my side would be for salsa-maintained packages to havet the NMU not bypassing the version management. Steffen
Bug#1009757: ITP: libtie-cache-lru-perl -- Perl module that implements Least-Recently Used cache
Package: wnpp Severity: wishlist Owner: Paul Gevers X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: libtie-cache-lru-perl Version : 20150301 Upstream Author : Michael G Schwern * URL : https://metacpan.org/release/Tie-Cache-LRU * License : GPL-1+ or Artistic Programming Lang: Perl Description : Perl module for Least-Recently Used cache This is an implementation of a least-recently used (LRU) cache keeping the cache in RAM. A LRU cache is similar to the kind of cache used by a web browser. New items are placed into the top of the cache. When the cache grows past its size limit, it throws away items off the bottom. The trick is that whenever an item is -accessed-, it is pulled back to the top. The end result of all this is that items which are frequently accessed tend to stay in the cache. Debian already has libtie-cache-perl, which is a different implementation of the same idea (they were even developed in competition), but this package is a dependency of the Logitech Mediaserver that I'm working on, which also needs libtie-cache-lru-expires-perl (to be ITPd). I intent to maintain this package under the Perl Team umbrella.
Bug#1009758: ITP: flask-restx -- Flask-RESTX is an extension for Flask that adds support for quickly building REST APIs
Package: wnpp Severity: wishlist Owner: Jan Mojzis X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: flask-restx Version : 0.5.1 Upstream Author : python-restx Authors * URL : https://github.com/python-restx/flask-restx * License : BSD-3-Clause Programming Lang: Python Description : Flask-RESTX is an extension for Flask that adds support for quickly building REST APIs Flask-RESTX is an extension for Flask that adds support for quickly building REST APIs. Flask-RESTX encourages best practices with minimal setup. If you are familiar with Flask, Flask-RESTX should be easy to pick up. It provides a coherent collection of decorators and tools to describe your API and expose its documentation properly using Swagger. I would like to maintain the package using https://salsa.debian.org/ Currently is the Debian package maintained here https://salsa.debian.org/janmojzis/python-flask-restx I need sponsor for the first upload (I'm DM).
Re: Is there room for improvement in our collaboration model?
On Sat, Apr 16, 2022 at 8:32 AM Steffen Möller wrote: > The only extra request from my side would be for salsa-maintained > packages to havet the NMU not bypassing the version management. I agree with the idea, except that it's common to want to NMU something that you don't have Salsa commit privileges for. Thanks, Jeremy Bicha
Bug#1009761: ITP: mutt-wizard -- system to automatically configure
Package: wnpp Severity: wishlist Owner: Josenilson Ferreira da Silva X-Debbugs-Cc: debian-devel@lists.debian.org, nilsonfsi...@hotmail.com * Package name: mutt-wizard Version : 3.2.1 Upstream Author : Luke Smith * URL : https://github.com/LukeSmithxyz/mutt-wizard * License : GPL-3.0 Programming Lang: shell Description : system to automatically configure Determines the IMAP and SMTP servers and ports of email servers. Creating dotfiles for neomutt, isync, and msmtp appropriate for email addresses . It encrypts and stores passwords locally for easy remote access, accessible only by your GPG key. . Handles up to nine separate email accounts automatically, creating links to switch between accounts or between mailboxes. Provides sensible defaults and an attractive appearance for the neomutt email client. . In case the mutt-wizard doesn't know your server's IMAP/SMTP information by default, it will let you know for them and put them in all the right places.
Results for Debian Project Leader 2022 Election
Greetings,
This message is an automated, unofficial publication of vote results.
Official results shall follow, sent in by the vote taker, namely
Debian Project Secretary
This email is just a convenience for the impatient.
I remain, gentle folks,
Your humble servant,
Devotee (on behalf of Debian Project Secretary)
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Starting results calculation at Sun Apr 17 00:00:19 2022
Option 1 "Felix Lechner"
Option 2 "Jonathan Carter"
Option 3 "Hideki Yamane"
Option 4 "None of the above"
In the following table, tally[row x][col y] represents the votes that
option x received over option y.
Option
1 2 3 4
=== === === ===
Option 1 5284 151
Option 2294 266 327
Option 322969 290
Option 41882253
Looking at row 2, column 1, Jonathan Carter
received 294 votes over Felix Lechner
Looking at row 1, column 2, Felix Lechner
received 52 votes over Jonathan Carter.
Option 1 Reached quorum: 151 > 45.8421203698084
Option 2 Reached quorum: 327 > 45.8421203698084
Option 3 Reached quorum: 290 > 45.8421203698084
Dropping Option 1 because of Majority.
(0.8031914893617021276595744680851063829787) 0.803 (151/188) < 1
Option 2 passes Majority. 14.864 (327/22) >= 1
Option 3 passes Majority. 5.472 (290/53) >= 1
Option 2 defeats Option 3 by ( 266 - 69) = 197 votes.
Option 2 defeats Option 4 by ( 327 - 22) = 305 votes.
Option 3 defeats Option 4 by ( 290 - 53) = 237 votes.
The Schwartz Set contains:
Option 2 "Jonathan Carter"
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
The winners are:
Option 2 "Jonathan Carter"
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
The total numbers of votes tallied = 354
--
The voters have spoken, the bastards... --unknown
DEbian VOTe EnginE
digraph Results {
ranksep=0.25;
"Felix Lechner\n0.80" [ style="filled" , color="pink", shape=octagon,
fontname="Helvetica", fontsize=10 ];
"None of the above" -> "Felix Lechner\n0.80" [ label="37" ];
"Jonathan Carter\n14.86" [ style="filled" , color="powderblue", shape=egg,
fontcolor="NavyBlue", fontname="Helvetica", fontsize=10 ];
"Jonathan Carter\n14.86" -> "Hideki Yamane\n5.47" [ label="197" ];
"Jonathan Carter\n14.86" -> "None of the above" [ label="305" ];
"Hideki Yamane\n5.47" [ style="filled" , fontname="Helvetica", fontsize=10 ];
"Hideki Yamane\n5.47" -> "None of the above" [ label="237" ];
"None of the above" [ style="filled" , shape=diamond, fontcolor="Red",
fontname="Helvetica", fontsize=10 ];
}
pgpwHyyLlpCHV.pgp
Description: PGP signature
Re: Wine MinGW system libraries
Hello all, Since this conversation several months ago I've been working with the Wine maintainer on implementing a solution upstream that is compatible with our requirements and the pretty much universal desire by packagers to avoid system library imports. I believe I've found a solution that will work for now for everyone, although it has raised some questions about standardization of MinGW packages—see the "Open Questions" section of this mail for more details. == Summary of upstream progress == Currently Wine bundles the source of several libraries. At the same time, as was discussed we've implemented a system upstream by which external shared libraries can be linked to and loaded (while keeping them in a separate "namespace" so that they don't conflict with identically named application DLLs.) There are still some concerns on the Wine side that this will break applications in subtle ways, but unfortunately there has been almost no testing of this feature yet. The libraries which we import are as follows: * libFAudio * libgsm * libjpeg * jxrlib * liblcms2 * libmpg123 * libpng * libtiff * libvkd3d * libxml2 * libxslt * zlib This list is probably going to remain stable. Despite what was discussed earlier I do *not* forsee us importing libOSMesa (it turns out that it actually makes more sense on the Win32 "kernel" side). An import of libfreetype or libgnutls is also unlikely at this point (we've found it more worthwhile to write thunks for both). We currently do *not* support external static linking. The basic reason for this is that Wine builds against its own CRT rather than MinGW's, and we cannot safely statically link to a module built with a different CRT. == Technical details == In order to use system shared libraries, Wine needs to know where to find them at runtime. This is done with a configure argument: configure --with-system-dllpath=/first/directory/:/second/directory/ Note that this may need to include the location of libgcc_s and other dependencies, which is in a different location on Debian. Separately, for each argument, we need to know the compiler and linker flags used to find the library. This also can be done with configure arguments, much like for native libraries: configure GSM_PE_CFLAGS="-Iwhatever" GSM_PE_LIBS="-Lwhatever -lgsm" If MinGW pkg-config is present, and --with-system-dllpath is specified, Wine will automatically use it to detect the compiler and linker flags for all of the above packages supporting pkg-config, which in particular excludes libgsm and jxrlib. Thus in practice it should not be necessary to hand-code most CFLAGS and LIBS variables. == Open Question(s) == Currently it's necessary to use a configure argument to specify where to find the runtime path. This is fine for distributions, which is where most people are going to be getting Wine anyway. It's a bit unfortunate for anyone self-compiling Wine, though, and it'd be nice if there was some way to avoid it. Unfortunately, there are two things standing in our way. The first problem is that the location of runtime DLLs varies wildly between distributions, and there's no common independent way to detect it. We could potentially hardcode a few "guesses" at the runtime path into Wine's configure script, but that brings us to the second problem: there's no way to verify the presence of runtime DLLs. We *are* the loader and lower-level APIs and would have to bootstrap ourselves first, and this is pretty much infeasible. Verifying by name doesn't really work either, since the name isn't really predictable. Hence "standardize the location of runtime DLLs across distributions" isn't really a feasible solution either (or at least not a complete one), as nice as it would be—we have no way to know whether a distribution is post-standardization or not. Rather, I think the best solution is to have some tool which, if present or successful, lists one or more directories where libraries can be found. I'm not sure what the most sensible thing here is: * pkg-config would be an obvious tool to extend, but would presumably require modifying .pc files for all relevant packages upstream. The location also seems to be consistent across all packages within each distribution I was able to test, so there probably isn't much point in making it package-specific. [For the packages we care about, cmake and libtool both put things in /bin by default, and zlib apparently has no built-in cross-compilation support.] * Introducing an analogue of ld.so.conf seems like a good idea. It would allow for per-package extra directories, and is relatively easy to parse, although ideally it would be even easier than that (i.e. if someone else could deal with the "include" part, that would be great). ἔρρωσθε, Zeb Figura
