Heimdal Bugs re update-alternatives
Hello,
Can I please have some thoughts on #1070031?
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070031
Is it appropriate to use update-alternatives for kadmin that is supplied
with {Heimdal,MIT} Kerberos?
I am thinking they do very different things but maybe not. i.e. one
updates files for Heimdal KDC, the other updates files for MIT KDC.
But we don't what these packages to conflict either. What is the best
solution?
Also what can I do about #1095296?
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1095296
Seems that Heimdal tools are implemented as symlinks that point to
"/usr/bin/heimtools" and then use the program name to decide what to
do. Argh.
Please CC responses to me, thanks
--
Brian May @ Linux Penguins
Bug#1095553: ITP: hvcc -- heavy dataflow audio programming language transpiler
Package: wnpp Severity: wishlist Owner: IOhannes m zmoelnig X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: hvcc Version : 0.13.2 Upstream Contact: https://github.com/Wasted-Audio/hvcc/issues * URL : https://wasted-audio.github.io/hvcc * License : GPL3+ Programming Lang: Python Description : heavy dataflow audio programming language transpiler Heavy is a framework for easily generating audio plugins for use in interactive sound and music applications such games, instruments or installations. It aims to reduce the dependency on low-level programming from a creative standpoint and bridge the gap from idea to production-ready implementation. Heavy makes use of modern software principles to generate highly optimised C/C++ code specifically targeting a wide variety of popular hardware architectures and software frameworks. It can also automatically build plugin binaries for these platforms. Currently Heavy supports compiling Pure Data (.pd) patch files. I intend to maintain this under the multimedia-team umbrella.
Bug#1095041: ITP sphinxcontrib-googleanalytics -- Google Analytics extension for Sphinx
Package: wnpp Followup-For: Bug #1095041 Owner: Hilmar Preuße X-Debbugs-Cc: debian-devel@lists.debian.org In the meantime I've packaged the extension myself and intend to upload. The package is on salsa in the Python Team Space. Hilmar signature.asc Description: PGP signature
Bug#1095637: ITP: ruby-dry-logger -- dependency-free logging solution suitable for Ruby application
Package: wnpp Severity: wishlist Owner: Abhijith PA X-Debbugs-Cc: debian-devel@lists.debian.org, debian-r...@lists.debian.org * Package name: ruby-dry-logger Version : 1.0.4 * URL : https://github.com/dry-rb/dry-logger * License : Expat Programming Lang: Ruby Description : dependency-free logging solution suitable for Ruby application ruby-dry-logger provides a standalone, dependency-free logging solution suitable for any Ruby application. Some features are structured logging by default, logging to multiple destinations via pluggable logging backends, fine-grained log formatting using formatters. This is a dependency of camping 3.2.6. It will be maintained it under the Debian Ruby Team.
Re: Using GitHub directly from inside Emacs
On Sun, Feb 09, 2025 at 10:19:04AM -0800, Otto Kekäläinen wrote: > Hi! Hi, > I don't use Emacs myself, but I learned last weekend at FOSDEM that > some Emacs users love using the Emacs extension Magit [1] with the > Forge [2] feature to list and review GitHub Pull Requests directly > from Emacs without opening a browser. > > Just curious to know if any Emacs users here (Monty?) have tried Magit > for interacting with https://github.com/MariaDB/server/pulls? > > There are currently 240 open PRs and 157 have zero reviews [3] from > people with GitHub permissions to give reviews. To get more > contributors, we need to have more people participating in > reviewing/approving incoming contributions. Nah. The "Nah" expressed stronger: "NO". There is only need for awareness that '"Somebody else should do it!" is a dangerous strategy' > Also some parts of the contributions process are not very optimal, and > the process is likely to become smoother only if enough of current core > developers at least occasionally "eat their own cooking" and experience > (at least parts) of the contribution process. +1 for the "What you do not wish to be done to yourself, do not do to another." > - Otto Groeten Geert Stappers > [1] https://magit.vc/ A Git Porcelain inside Emacs > [2] https://magit.vc/manual/forge.html Forge allows you to work with Git forges, currently Github and Gitlab, from the comfort of Magit and Emacs. > [3] https://github.com/MariaDB/server/pulls?q=is%3Apr+is%3Aopen+review%3Anone -- Silence is hard to parse
Re: RFC on proposal for adequate(1) overrides
[bumping this for more attention. I've received two responses (both positive), neither from folks that claim to be from any kind of qa team] On Sat Feb 1, 2025 at 10:28 PM CET, Serafeim (Serafi) Zanikolas wrote: > hi, > > I'd like to extend adequate(1) to allow maintainers to suppress the reporting > of > Debian policy violations, much like lintian has overrides. if you care about > binary package qa testing, please review: > > https://salsa.debian.org/debian/adequate/-/wikis/proposals/overrides > > if you don't like the salsa ui, you may instead: > > git clone https://salsa.debian.org/debian/adequate.wiki.git > $PAGER adequate.wiki/proposals/overrides.md > > thanks, > serafi > > ps. fwiw, I've previously reached out to d-ci@ and d-lint-maint@ signature.asc Description: PGP signature
Re: Using GitHub directly from inside Emacs
Hi! Sorry, my email client auto-completed as the "developers" mailing list the one I usually write to, and not the one this was intended to be submitted at... Anyway, I am sure there are some Emacs users here too and if you never heard about Magit+Forge then maybe this was useful info. > [1] https://magit.vc/ A Git Porcelain inside Emacs > [2] https://magit.vc/manual/forge.html Forge allows you to work with Git forges, currently Github and Gitlab, from the comfort of Magit and Emacs.
Bug#1095568: ITP: python-aiowatttime -- asyncio-based library for interacting with WattTime
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-aiowatttime Version : 2024.06.0 Upstream Contact: Aaron Bach * URL : https://github.com/bachya/aiowatttime * License : Expat Programming Lang: Python Description : asyncio-based library for interacting with WattTime This package is an asynchronous Python 3 library designed for seamless interaction with WattTime's emissions data API. Leveraging Python's asyncio framework, it enables efficient, non-blocking access to real-time, forecasted, and historical emissions information. This functionality is particularly beneficial for developers aiming to integrate environmental data into applications focused on energy management, sustainability analytics, or ecological research. . Key Features: * Asynchronous Design: Utilizes Python's asyncio for non-blocking operations, ensuring efficient data retrieval. * Comprehensive Emissions Data Access: Provides methods to obtain real-time, forecasted, and historical emissions data, facilitating a wide range of analytical applications. * Grid Region Identification: Includes functionality to determine the grid region based on geographical coordinates, enhancing the precision of regional emissions analysis. * Robust Retry Mechanism: Incorporates configurable retry logic to handle token expiration and transient network issues, improving reliability in data fetching. I will maintain this package in the Homeassistant team.
Re: Do we need a conflict of interest policy?
Hi Ted, I disagree with your application of some points to the Debian Project. I agree with others. (Why is this in -devel and not -project?) At 2025-02-08T23:09:55-0500, Theodore Ts'o wrote: > So for example, if you serve on the board of a church, or a non-profit > orgaization like Usenix, or the Rocky Enterrise Software Foundation > (RESF), if there is a motion where you might benefit depending on how > the decision comes out, the CoI policy will mandate that you abstain > from voting on the motion. This is where the "refrain from > participating from a decision" language might come from. When I served on the SPI board, I had a personal rule (one that I did not expect or demand of others), that I would abstain from voting on my own motions. This worked out fine. I don't recall a motion of mine ever stalling out in a tie due to my habit, nor one that would have tied if only I had voted. I thought the practice to be a worthwhile shield against even the notion of self-dealing. People can of course levy such charges on no grounds whatsoever, but it seemed a helpful bulwark and was easily done. Tied or near-tied votes can inflame the passions within boards and memberships alike. I wanted to stay away from that, and I recall SPI board meetings as invariably highly collegial. > Howeer, it is quite common that someone with that potental conflict of > interest is often a subject matter expert. For example, if you are a > primary owner of a general contracting company, then you will know a > lot about building construction; so if the vote is about which company > should be hired, the board would *want* to hear your insights. So > typically the conflict of interest would be disclosed, the expert > would give their opinions, insights, and other expertise to the board > --- and then the expert might abstain from voting on the actual motion > if they were a board member. Seems like sound practice to me. > The problem is that in Debian, we rarely vote when we make decisions. > This does happen, of course, such as when the Technical Committee > votes on something that might be a very close call. In that case, it > would make sense for a TC member who might have conflict of interest > to step aside. It's odd to me that you didn't mention the GR process (except by reference to DPL elections). I think it is significant because of how distinguishable it is. I may be on the stern and searching side of disclosures and conflict-of-interest recusals, but I would not expect a Debian developer to lose their franchise in the GR process for _any_ reason short of expulsion. That's because it _is_ the franchise. Our constitution commits us to a democratic form of government. You and I are both U.S. people, so we know well, though others may not-- the United States has a sorry history of stripping its citizens and residents of the franchise (or never extending it to them in the first place). Frequently this practice occurs on a racialist basis, to prevent African-Americans from exercising their voting rights. Because overt racialism was unfashionable for a while, numerous proxies for black skin arose, like felon status. The ACLU has a useful primer.[1] I think Debian has striven to avoid that sorry example, and largely succeeded. (More precisely, I don't think our constitution's primary drafter, Ian Jackson, nor its charter ratifiers, had any desire to emulate the more wretched codicils of the U.S. Constitution's own letter, which was racialist not through carelessness or latent biases but explicit design. Beyond the standard reference--the _Federalist Papers_--Thomas Jefferson's _Notes on the State of Virginia_ (1785) is instructive in this respect.) > However, many decisions take place via discussion / debates on public > mailing list --- so what does refrain from participating in a decision > mean in that context? That the people who might have the most > expertise must not participate in the debate? That > seems counterproductive. So there, probably the best you could do > is to make sure people should be asked to disclose conflicts of > interest up front, although in many cases, it might be obvious (for > example if the e-mail address has canonical.com). Yes, I think they should disclose--both their potential/actual CoI and their expertise. If they behave more professionally and compose more factual, better-reasoned, and more completely supported and documented cases for action (or inaction) because they feel the weight of their employment affiliation upon them more acutely in that context--how is that bad? I'm trying to imagine the internal narrative of a person disincentivized as you posit. "Jeez, if I weigh in on this I'm going to have to produce really high-quality output. Yeesh. You know what? Screw it. These guys can muddle through without my insight." It's noteworthy to me that the richer a person's compensation package in our field, the more prone they are to resentment.
Using GitHub directly from inside Emacs
Hi! I don't use Emacs myself, but I learned last weekend at FOSDEM that some Emacs users love using the Emacs extension Magit [1] with the Forge [2] feature to list and review GitHub Pull Requests directly from Emacs without opening a browser. Just curious to know if any Emacs users here (Monty?) have tried Magit for interacting with https://github.com/MariaDB/server/pulls? There are currently 240 open PRs and 157 have zero reviews [3] from people with GitHub permissions to give reviews. To get more contributors, we need to have more people participating in reviewing/approving incoming contributions. Also some parts of the contributions process are not very optimal, and the process is likely to become smoother only if enough of current core developers at least occasionally "eat their own cooking" and experience (at least parts) of the contribution process. - Otto [1] https://magit.vc/ [2] https://magit.vc/manual/forge.html [3] https://github.com/MariaDB/server/pulls?q=is%3Apr+is%3Aopen+review%3Anone
