Hi,
On 2/11/25 12:41, Vincent Lefevre wrote:
I'm also wondering about the current status of this bug. After
more than one year, there haven't been any comments.
Sorry for not being of great help on this, but just for information, it
has been also one year since
I'm holding it's upgrade:
##
I don't really use redmine anymore, so I can't speak to that issue or
any other issue in the redmine debian package, I'm sorry.
On 2025-02-11 14:47:31, Soren Stoutner wrote:
> Antoine,
>
> I wrote a previous email to this bug report, but I realized I didn’t include
>
Control: severity -1 normal
On 2025-02-09 15:37:06, Antoine Beaupré wrote:
> On 2025-02-09 15:35:38, Antoine Beaupré wrote:
>
> [...]
>
>> I'm a bit at a loss here, not sure where to go next.
>
> Oh, and also, there's this upstream bug:
>
> https://github.
On 2025-02-09 15:35:38, Antoine Beaupré wrote:
[...]
> I'm a bit at a loss here, not sure where to go next.
Oh, and also, there's this upstream bug:
https://github.com/xorpaul/g10k/issues/230
Not sure it's related, but i'll ping there.
--
Work expands so as to fill
Control: notfound -1 0.9.7-1+b3
Downgrading to the bookworm version in sid seems to workaround the
issue.
Also, triggering a backtrace with SIGQUIT (C-\) shows the hang is
somewhere in the standard library.
Here it is on -help, for example:
^\SIGQUIT: quit
PC=0x477203 m=0 sigcode=128
goroutine
Package: golang-1.23-src
Version: 1.23.5-1
Severity: serious
I'm trying to rebuild g10k in sid, and it fails:
golang-1.23-go : Depends: golang-1.23-src (>= 1.23.6-1) but it is not
installable
golang-src : Depends: golang-1.23-src but it is not installable
The g10k build-dep is simply `golang-
On 2025-01-19 10:14:06, David Prévot wrote:
> This package hasn’t seen an upstream release (nor commit) for more than
> eight years, and has no dependencies in Debian. Given how PHP has
> changed in the mean time, I doubt it’s even still working. Let’s not
> release Trixie with a useless and abando
Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: php-console-ta...@packages.debian.org
Control: affects -1 + src:php-console-table
User: ftp.debian@packages.debian.org
Usertags: remove
As explained in #1093487, php-console-table is probably dead and
should be removed from Debian.
Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian...@lists.debian.org
* Package name: mediamtx
Version : 1.11.3
Upstream Contact: https://github.com/aler9
* URL : https://github.com/bluenviron/mediamtx
* License : MIT
Programming Lang: Golang
Description
On 2025-02-06 22:12:28, Antoine Beaupré wrote:
> I'm in the process of switching to Xapian now. This brings a whole lot
> of other issues (it uses more disk space and there's a bug in the
> xapian-haystack library that crashes indexing, see #), but so far, we've
> com
Package: python3-xapian-haystack
Version: 2.1.1-1+deb12u1
Severity: important
Tags: patch upstream
We're suffering from a bug described in hyperkitty:
https://gitlab.com/mailman/hyperkitty/-/issues/408
... but i suspect it's also present in other xapian-haystack
consumers.
This affects at least
Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian...@lists.debian.org
* Package name: scc
Version : 3.4.0
Upstream Contact: https://github.com/boyter
* URL : https://github.com/boyter/scc
* License : MIT
Programming Lang: go
Description : fast accura
On Sun, 2 Feb 2025 13:50:56 + Simon McVittie wrote:
> This would likely require someone with an interest in 0ad to take over
> some or all of the responsibility for mozjs115, (…)
To avoid confusion: you’re not saying that mozjs requires new
maintenance (this is still the domain of the GNOME t
Source: 0ad
Severity: wishlist
With 0 A.D. alpha 27, upstream worked on improving the ability to use
system-provided mozjs instead of the embedded copy.
Since this build of the game relies on mozjs 115, already available in
Debian testing (Trixie) and Sid, I suggest excluding the shipped copy of
Control: reassign -1 openstack-clients
On 2025-01-24 12:44:22, Thomas Goirand wrote:
> On 1/24/25 10:52, Riccardo Coccioli wrote:
>> Hi,
>>
>> But this bug is also not related to Cumin in any way. Cumin doesn't have
>> a dependency on python-eventlet nor python3-trio, which are clearly
>> the c
On 2025-01-15 10:04:54, Antoine Beaupré wrote:
[...]
> This thread on the upstream mailman mailing list mentions people don't
> have this kind of problem with gunicorn:
>
> https://lists.mailman3.org/archives/list/mailman-us...@mailman3.org/thread/QCTB7Y6W7I7GDRCIJKFNEVQB7DS
Control: reassign -1 openstack-clients
On 2025-01-22 15:30:43, Antoine Beaupré wrote:
> Control: reassign -1 python3-keystoneauth1
> Control: affects -1 cumin
>
> I've struggled to get a backtrace from cumin because it catches all
> exceptions in its main() function. But by r
On 2025-01-16 16:10:51, Antoine Beaupré wrote:
> I started looking into this, published my work in:
>
> https://salsa.debian.org/go-team/packages/rdap
>
> Right now the build is failing with:
>
> src/github.com/openrdap/rdap/cli.go:26:2: cannot find package
> "github.
On 2025-01-22 21:40:41, Paride Legovini wrote:
> Control: tags -1 + moreinfo
>
> On Fri, 26 Oct 2018 Antoine Beaupre wrote:
>> It looks like the way autopkgtest calls qemu is suboptimal:
>>
>> gnupg2-2.1.1816$ autopkgtest . -- qemu
>> /var/lib/libvirt/image
Control: reassign -1 python3-keystoneauth1
Control: affects -1 cumin
I've struggled to get a backtrace from cumin because it catches all
exceptions in its main() function. But by removing that handler, I could
see a backtrace..
Mysteriously, the entry point in cumin is actually:
-> from keystone
Some updates from the shotman issue tracker:
this could be related to fractional scaling. According to them:
> Someone on #sway on IRC mentioned that imv doesn't support fractional
> scale. So any image that you open will be blurry.
So they filed: https://todo.sr.ht/~exec64/imv/70
... but then
Package: gpg-sq
Version: 0.11.2-7
Severity: normal
When a recipient is not "trusted" by gpg, this works:
echo foo | gpg --armor -e -r RECIPIENT
But this doesn't:
echo foo | gpg-sq --armor -e -r RECIPIENT
I think it's because of the way the terminal is handled. Here's what
it looks like
Package: gpg-sq
Version: 0.11.2-7
Severity: normal
Enthusiastic about sequoia's gpg layer, whoohoo!
My first try wasn't as exciting though:
anarcat@angela:~/s/t/account-keyring> gpg-sq --locate-keys u...@torproject.org
gpg: error: Error parsing option auto-key-locate in
/home/anarcat/.gnupg/g
Le Tue, 21 Jan 2025 17:53:48 +0400,
Ilyas Gasanov a écrit :
> In this case, can I ask you to create a Request For Adoption (RFA) on
> WNPP channel, so that other potential maintainers would be able to
> take note of this?
Mono is already listed on https://wiki.debian.org/LowThresholdAdoption
Thanks for your interest for Mono in Debian, that clearly goes far
beyond my own ;)
For a bit of context, Mono was facing removal from Debian after several
years being unmaintained. I took over its maintenance because I rely on
the Mono runtime binary and libraries for some other project of mine
(
For what it's worth, I have now tested gimp, and i find it renders the
image full screen *better* than gwenview. (It did take a couple of
minutes to turn off *everything* in gimp to get the right view though.)
Considering the G in GTK stands for "Gimp", this might not be a GTK
issue after all, alt
Just tested with loupe (rust, glib) and the results are similar to eog:
slight blurriness.
It's more evident when you use a highly detailed image like this:
https://paste.anarc.at/publish/2025-01-20-Ie2Gs5QhtTBWLYdIf9XuPD-6jrIzTSvElDNmahN-Fj0/DSCF8443.jpg
Here's the image, in fullscreen, with gw
I should also note that not all viewers are similarly blurry.
For example, eog is noticeably *less* blurry than geeqie (in fact, now
I'm starting to doubt it's blurry at all). Comparing the screenshot vs
gwenview, however, it does seem a little less sharp. Same with imv,
which seems to have the sa
Package: sway
Version: 1.10-2
Severity: important
So this is going to sound insane, but it looks to me as all images
loaded under Sway by GTK-derived image viewers are blurry.
At first, I thought this was an issue with screenshotting tools. I was
redoing the screenshot for undertime, and found th
As the maintainer of a build-dependency of smuxi (src:mono), I plan to
soon remove a binary package it relies on,
cf. https://bugs.debian.org/1093237
Unless its build recipe is updated to rely on another package (I
suggested one in the linked bug report), that would probably lead to
the removal of
I started looking into this, published my work in:
https://salsa.debian.org/go-team/packages/rdap
Right now the build is failing with:
src/github.com/openrdap/rdap/cli.go:26:2: cannot find package
"github.com/alecthomas/kingpin/v2" in any of:
/usr/lib/go-1.23/src/github.com/alecthomas/k
Source: smuxi
Severity: wishlist
As of Trixie/Sid, smuxi build-depends explicitly on mono-runtime-boehm.
This is a package built from mono:src, not available on all
architectures, and that I plan to drop in favour of mono-runtime-sgen
(that is already available, and the default garbage collector f
I know this is not the most satisfying solution, especially as some of
you worked on finding ways to improve the reproducibility of the
mono-source package, but my plan is simply to drop it.
It does not have a popcon entry (I guess it means it has never been
installed on a system with popcon repor
On 2025-01-16 10:20:56, Michael Tremer wrote:
> Good morning everyone,
>
> I ran the machine now with a total of 16 GiB - no other modifications have
> been made.
>
> Since then, the Apache process consumed the entirety of memory (minus the
> other basic system services) and was killed by the OOM
Le Wed, 15 Jan 2025 23:17:39 +,
James Addison a écrit :
> I've updated the Reproducible Builds documentation recently to add a
> relevant section[2] about file permissions; in short, there's a tar
> '--mode' option that I think may be helpful here.
Thank you, I’m going to take some time soon
Package: cumin
Version: 4.2.0-1
Severity: grave
cumin is currently completely broken in trixie:
anarcat@angela:~> cumin '*' 'uptime'
Caught AttributeError exception: type object 'GreenSocket' has no attribute
'sendmsg'
anarcat@angela:~[99]>
Not sure what's going on here, it might be related to
On 2025-01-15 16:13:44, Michael Tremer wrote:
[...]
> Apache is absolutely the biggest user of the memory and I considered that
> amount illegitimate.
For the record, I absolutely agree.
>> But yeah, your numbers might show there's actually an underlying issue
>> with mailman-web itself. Our t
On 2025-01-15 15:56:27, Michael Tremer wrote:
[...]
>>> I would be happy to hear if running mailman3 in Gunicorn resolves the
>>> problem, but maybe it is just a coincidence that the problem doesn’t appear
>>> there?
>>
>> It could be! If you could show us OOM dmesg logs, they should show whic
On 2025-01-15 15:18:21, Michael Tremer wrote:
> I am running mailman3-web in Apache with mod_wsgi and I also have the same
> memory usage problem. Therefore I thought it was a mailman3 problem rather
> than in the application that is hosting it.
Have you pinned down exactly *what* process is eat
Package: g10k
Version: 0.9.9-1+b4
Severity: serious
g10k somehow hangs after doing whatever it is it's doing. Here it is
hanging after printing the usage:
anarcat@angela:~> time g10k -help (main)
Usage of g10k:
-branch string
which git branch of the Puppet envi
Package: wnpp
Severity: wishlist
Owner: Antoine Beaupre
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.torproject.org
* Package name: llm-ollama
Version : 0.8.1
Upstream Contact: https://github.com/taketwo
* URL : https://github.com/taketwo/llm
Control: forwarded -1 https://github.com/equeim/tremotesf2/issues/585
Control: tags -1 -moreinfo
On 2025-01-13 16:47:08, Chen Shengqi wrote:
> On Mon, 13 Jan 2025 11:31:13 -0500, Antoine Beaupré
> wrote:
>
>>> ...and many of them have already been fixed by upstream.
>&
severity 1092582 wishlist
thanks
Le Thu, 09 Jan 2025 11:59:49 +0200,
Amr Ibrahim a écrit :
> Please consider migrating to Mono from the WINE project:
> https://gitlab.winehq.org/mono/mono
This is something I plan to do at some point, but not before the
current packaging is in a better state.
A
On 2025-01-02 19:17:38, Johannes Schauer Marin Rodrigues wrote:
> Hi,
>
> Quoting Antoine Beaupré (2025-01-01 03:52:54)
>> > Essentially, we do not pass a path to zstd anymore but we let sbuild open
>> > the path and then pass the filedescriptor to what we opened to
On Thu, 2 Jan 2025 20:48:42 +0100 Niels Thykier
wrote:
> I've prepared an NMU for mono (versioned as 6.12.0.199+dfsg-2.1) and
> uploaded it to DELAYED/5. Please feel free to tell me if I
> should delay it longer.
Thank you for that update, I am going to replicate it on the Salsa
repository when I
Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-r...@lists.debian.org
* Package name: wpaperd
Version : 1.1.1
Upstream Contact: https://github.com/danyspin97
* URL : https://github.com/danyspin97/wpaperd
* License : GPL-3
Programming Lang: Rust
Descrip
On 2023-12-06 08:32:49, Martin wrote:
> Hi Antoine,
>
> I'm started here:
>
> https://salsa.debian.org/python-team/packages/pass-secret-service
>
> So far, it doesn't work for me.
> Maybe I'm missing sth. about D-Bus activation?
>
> Any help apprec
Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-gol...@lists.debian.org
* Package name: wallutils
Version : 5.12.9
Upstream Contact: https://github.com/xyproto
* URL : https://github.com/xyproto/wallutils
* License : BSD-3
Programming Lang: Golang
Desc
On 2024-12-30 06:46:27, Johannes Schauer Marin Rodrigues wrote:
[...]
> Essentially, we do not pass a path to zstd anymore but we let sbuild open the
> path and then pass the filedescriptor to what we opened to zstd via its
> standard input.
Ah yes, that would work of course!
Probably harmless
On 2024-12-25 08:13:37, Johannes Schauer Marin Rodrigues wrote:
> commits without any rationale behind them are the best
Ugh, wtf.
Uh. So it looks like this is a feature of zstd that it won't follow
symlinks when reading compressed files!!
So i guess this is not a bug in sbuild after all, but s
On 2024-12-23 07:49:57, Johannes Schauer Marin Rodrigues wrote:
[...]
> If this variable were to be re-used then somebody who intends to build for
> bookworm-backports would have a chroot for just bookworm, without backports
> extracted. That is wrong.
Is it really? I mean if you don't have a bo
Package: plattenalbum
Version: 2.2.1-1+b1
Severity: serious
Out of the box, this package completely fails to run:
anarcat@angela:~$ plattenalbum
Traceback (most recent call last):
File "/usr/bin/plattenalbum", line 24, in
from mpd import MPDClient, CommandError, ConnectionError
ModuleNotF
On 2024-12-22 22:57:37, Johannes Schauer Marin Rodrigues wrote:
> Hi,
>
> Quoting Antoine Beaupré (2024-12-22 22:39:51)
>> > In your mind, what should sbuild add to support this?
>> >
>> > I can only think of one logical implementation and that is to add yet
On 2024-12-22 22:59:22, Johannes Schauer Marin Rodrigues wrote:
> Quoting Antoine Beaupré (2024-12-22 22:39:12)
>> On 2024-12-22 22:21:22, Johannes Schauer Marin Rodrigues wrote:
>> > Hi,
>> >
>> > Quoting Antoine Beaupre (2024-12-22 21:34:14)
>> >>
On 2024-12-22 22:25:02, Johannes Schauer Marin Rodrigues wrote:
> Hi,
>
> Quoting Antoine Beaupre (2024-12-04 16:00:51)
>> I'm building an UNRELEASED package and then sbuild complains with this:
>>
>> E: Chroot for distribution UNRELEASED, architecture amd64 not
On 2024-12-22 22:21:22, Johannes Schauer Marin Rodrigues wrote:
> Hi,
>
> Quoting Antoine Beaupre (2024-12-22 21:34:14)
>> I'm getting this if I use symlinks for tarballs in unshare mode:
>>
>> Warning :
>> /home/anarcat/.cache/sbuild/UNREL
Package: sbuild
Version: 0.88.1
Severity: normal
I'm getting this if I use symlinks for tarballs in unshare mode:
Warning :
/home/anarcat/.cache/sbuild/UNRELEASED-amd64.tar.zst is a symbolic link,
ignoring
I'm not sure why this is happening, but it's quite inconvenient as I
On 2024-12-22 18:17:39, Simon Josefsson wrote:
> Antoine Beaupré writes:
>
>> On 2024-12-21 10:25:36, Simon Josefsson wrote:
>>> Hi. It seems golang-goptlib changed namespace between upstream
>>> releases, and snowflake has to adapt. However, it is possible to
m that?
Thanks for checking. I've been running 6.12.5-1 successfully for the
past few days. Thanks!
Antoine
On 2024-12-21 10:25:36, Simon Josefsson wrote:
> Hi. It seems golang-goptlib changed namespace between upstream
> releases, and snowflake has to adapt. However, it is possible to solve
> this with a hack in golang-goptlib, so I did that.
thank you so much!
btw, you might want to look into:
htt
Le Fri, 20 Dec 2024 09:54:27 -0500,
Jeremy Bícha a écrit :
> It is somewhat unusual for multiple versions of an app to be available
> in a single Debian release. Why do you want to do it in this case?
I do have a use case for that: running non-free games (no source
available) using the Debian-pr
Source: foot
Severity: wishlist
It seems like foot-terminfo was removed as a binary package in
1.15.1-2, as requested in #1041685.
But as pointed out in that bug report, some capabilities did *not*
make it to the global terminfo database, and are, according to
upstream, "very unlikely to ever get
On Fri, 13 Dec 2024 15:18:50 +0100 Jan Binder
wrote:
> Thanks for looking into this, disabling the camera works as a stopgap
measure
Thanks for the replies and pointers to the fix.
I'll stay on 6.11 until the next 6.12 image is made available.
Antoine
Package: pipewire
Version: 1.2.7-1
Severity: normal
Hi!
I've been a happy user of Pipewire since bullseye (!). Recently,
however, I noticed something strange: I'm listening to music (whatever
music player, say Youtube in Firefox, or Audacious installed from a
debian package, but I also reproduced
So I looked at packaging anthropic as well. All dependencies are
packaged in Debian (which is good) except jiter (which is less
good). It's a tiny module that would be trivial to package, except that
it says they shouldn't be using it, so i filed that as a bug upstream:
https://github.com/anthropi
Package: wnpp
Severity: wishlist
Owner: Antoine Beaupre
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.torproject.org
* Package name: llm-claude-3
Version : 0.10
Upstream Contact: Simon Willison <https://github.com/simonw>
* URL : https://gith
> I think the upload landed directly into the archive instread to
> delayed/10:
> https://tracker.debian.org/news/1592940/accepted-needrestart-38-01-source-into-experimental/
Yes, I screwed up dput. My only excuse is that it landed in
experimental, at least, and that I had exchanges with the maint
On 2024-12-09 14:55:20, anar...@debian.org wrote:
> Control: tags 1087882 + patch
> Control: tags 1087882 + pending
>
> Dear maintainer,
>
> I've prepared an NMU for needrestart (versioned as 3.8-0.1) and
> uploaded it to DELAYED/10. Please feel free to tell me if I
> should delay it longer.
Ugh.
Package: dput-ng
Version: 1.40
Followup-For: Bug #1065203
Is there an upload planned to fix this? scp is still broken in sid...
-- System Information:
Debian Release: trixie/sid
APT prefers testing-debug
APT policy: (500, 'testing-debug'), (500, 'testing')
Architecture: amd64 (x86_64)
Kerne
Package: unattended-upgrades
Version: 2.11+nmu1
Severity: important
I have apt-listbugs hooked into apt here, and running:
unattended-upgrade -v --dry-run
Results in an infinite loop. It's hard to tell where exactly it's
happening because I can't actually catch the beginning in my
scrollback
Package: src:linux
Version: 6.12.3-1
Severity: critical
Justification: breaks the whole system
X-Debbugs-Cc: anto...@cellerier.net
Dear Maintainer,
linux-image-6.12.3-amd64 fails to boot. The following kernel messages
are likely the relevant bits - appologies if I'm getting them wrong,
I'm unfami
Package: sbuild
Version: 0.87.1
Severity: normal
I'm building an UNRELEASED package and then sbuild complains with
this:
E: Chroot for distribution UNRELEASED, architecture amd64 not found
which, fair enough, there's no such tarball in my .cache/sbuild:
$ find ~/.cache/sbuild/
/home/anarcat/.ca
Control: tags -1 + wontfix
I'd like to keep nomacs in unstable. I think there's still hope for the
package. Many of the RC bugs would be fixed simply with an update to the
latest upstream, see #1076763.
It's something I've personally been working on, but got distracted by an
upstream issue:
http
On 2021-12-11 13:31:56, Pierre-Elliott Bécue wrote:
> Hi all,
>
> Jonas Meurer wrote on 09/12/2021 at 22:09:05+0100:
>
>> [[PGP Signed Part:No public key for 5262E7FF491049FE created at
>> 2021-12-09T22:09:05+0100 using RSA]]
>> Hey Moritz, hey Amir and Kunal,
>>
>> Moritz Muehlenhoff wrote:
>>>
Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-pyt...@lists.debian.org
* Package name: keyring-pass
Version : 0.9.3
Upstream Contact: https://github.com/nazarewk
* URL : https://github.com/nazarewk/keyring_pass
* License : MIT
Programming Lang: Python
On 2024-11-26 06:01:15, Helmut Grohne wrote:
> Since the suggestion bug was neither closed nor tagged in a month, silent
> consent to proceed with removal is assumed.
I'm not the primary maintainer of Monkeysphere, but I was one of the
participants in the community and I wanted to reassuring you t
The initial packaging is ready on Salsa:
https://salsa.debian.org/games-team/julius
I already found someone willing to sponsor the upload (big thanks to
them), and the packaging process was greatly sped up by previous
attempts that were already published on Salsa:
- https://salsa.debian.org/games-
Le Sun, 24 Nov 2024 17:06:31 +0100,
Sébastien Noel a écrit :
> If you are motivated enough to properly upload this engine to Debian
> maybe you can use my work at https://salsa.debian.org/twolife/julius
Thank you for sharing your work, this will definitely help me in
getting started!
I am shar
I started a discussion with the upstream through GitHub:
https://github.com/bvschaik/julius/issues/739
pgpfmBqA_lksx.pgp
Description: Signature digitale OpenPGP
I started a discussion with the upstream through GitHub:
https://github.com/deathkiller/jazz2-native/issues/87
pgpFsBy5upqXv.pgp
Description: Signature digitale OpenPGP
I started a discussion with upstream through GitHub:
https://github.com/diasurgical/devilutionX/discussions/7556
pgpJXSRTx2gIV.pgp
Description: Signature digitale OpenPGP
Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-devel-ga...@lists.debian.org
* Package name: jazz2-resurrection
Version : 2.9.1
Upstream Contact: None yet
* URL : https://deat.tk/jazz2/
* License : GPL3
Programming Lang: C++
Description : Native en
Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-devel-ga...@lists.debian.org
* Package name: devilutionx
Version : 1.5.3
Upstream Contact: None yet
* URL : https://github.com/diasurgical/devilutionX
* License : Sustainable Use License (non-free)
Programm
If the name of the package should not be "julius", I guess for avoiding
a collision with RFP #506606, I suggest we use something else than the
main developer nickname to distinguish this package.
Since this is an engine for the video game named "Caesar III", I would
suggest "julius-caesar3" or "ju
I submitted the patches through Salsa:
https://salsa.debian.org/games-team/0ad/-/merge_requests/6
It builds and then runs nicely on my up-to-date Debian unstable.
I sneaked in a fix to ensure DEB_BUILD_OPTIONS=parallel=${n} is
honoured, as I needed it to ensure the package could be built on a
low-
Package: needrestart
Version: 3.7-3.1
Severity: important
SInce the update to 3.7-3.1, needrestart always triggers a restart of
all running LXC containers. Not a restart of lxc.service itself, but a
restart of each and every container using "lxc-stop --reboot --name foo".
Reverting back to 3.7-3,
Source: prometheus
Severity: wishlist
It would be great to have promtool shipped in a separate binary
package. We use it to test alerting rules in our CI, and I would like
to run those tests locally, but that means installing the `prometheus`
package which sets up the whole server and everything.
On 2024-04-06 23:17:14, Antoine Beaupré wrote:
> Upstream actually fixed this issue, possibly:
>
> https://github.com/dajva/rg.el/commit/8e2347d0a11aa64fd721702b176b1dbc7889f78e
>
> So, woot, i guess we get this fix when upstream makes a new release (or
> we import that patch)
Package: 0ad
Version: 0.0.26-7
Severity: grave
Tags: upstream
Justification: renders package unusable
Since the 1.23.0 → 1.24.0 OpenAL upgrade in unstable, 0 A.D. crashes on launch.
This is a problem affecting the upstream too:
https://wildfiregames.com/forum/topic/125203-crash-on-start-due-to-sou
Note that this issue is tracked internally at:
https://gitlab.torproject.org/tpo/tpa/team/-/issues/41883
Package: needrestart
Version: 3.7-3.1
Severity: wishlist
Hi Patrick!
So a major security issue came out in needrestart, as you undoubetly
know! :)
We've been maintaining a couple patches over needrestart 3.7 at
torproject.org (mainly for prometheus monitoring) and we need to
reroll them on top o
Package: prometheus-pgbackrest-exporter
Severity: wishlist
Upstream ships this .service file:
https://github.com/woblerr/pgbackrest_exporter/blob/master/pgbackrest_exporter.service.template
let's ship (and enable?) it in the debian package as well! :)
-- System Information:
Debian Release: 12.
On 2024-11-08 22:06:01, Kyle Robbertze wrote:
> Hi,
>
> Liquidsoap already build-deps on libssl-ocaml-dev and the configure output
> does report that it is building with SSL support (at least the last
> buildable-version, I'm still working on getting a working version back into
> sid).
Maybe it
Control: retitle -1 fails to stream to icecast HTTPS server
Actually, I should clarify it fails to connect to a HTTPS server, a
problem, it turns out, is actually extremely common in various icecast
implementations.
Connecting in plain text (over a tunnel) works.
Package: liquidsoap
Version: 2.1.3-2
Severity: wishlist
I have tried to make liquidsoap stream to a HTTPS icecast server, and
it seems to fail even if docs seem to indicate this should work:
output.icecast(%mp3, host="radio.anarc.at", port=443, password="hackme",
mount="liq.ogg", radio, transpo
Package: butt
Version: 0.1.37-2
Severity: important
I have tried "butt" to try to stream audio to an icecast server, and
I'm somehow failing. It seems to incorrectly be talking to the server,
as the server reports this:
[2024-11-08 14:53:15] INFO connection/_handle_source_request Source logging
On 2024-11-06 20:47:56, Pierre-Elliott Bécue wrote:
> Antoine Beaupré wrote on 05/11/2024 at 23:16:31+0100:
>
>> Hey folks,
>>
>> So with the help of this issue and a few other things found here and
>> there, I wrote my own upgrade docs, which should be available
Package: wnpp
Severity: wishlist
* Package name: ruby-sdl2
Version : 0.3.6
Upstream Contact: Ippei Obayashi
* URL : https://github.com/ohai/ruby-sdl2
* License : LGPL v3
Programming Lang: Ruby
Description : SDL2 bindings for Ruby
Ruby/SDL2 is an extens
Hey folks,
So with the help of this issue and a few other things found here and
there, I wrote my own upgrade docs, which should be available for folks
here:
https://gitlab.torproject.org/tpo/tpa/team/-/wikis/service/lists#mailman-2-migration
a.
--
La seule excuse de Dieu, c'est qu'il n'existe
Package: mailman3
Version: 3.3.8-2~deb12u2
Severity: important
Tags: upstream
Mailman 3, out of the box, doesn't do any sort of DMARC
mitigation. This implies that it's impossible to deliver mail to
standards-conforming providers (e.g. Google, but also others) by
default, as the From: header will
1 - 100 of 1865 matches
Mail list logo
