On 10/16/24 18:18, Iustin Pop wrote:
> Gitea/Forgejo are common recommended solutions for "home hosting", but
> neither is packaged.
(jftr) I'm currently working with Forgejo upstream to get one last
feature implemented that we'll need at work to switch to it, and then
finish the packaging of it
close 935834
thanks
Hi,
I think Debian that it doesn't make sense if Debian has both forgejo and
gitea, and that forgejo is the better fit for Debian.
I'm working on getting forgejo packaged (#1058932), so I'll close this
bug in favour of it.
Regards,
Daniel
close 935834
thanks
Hi,
I think Debian that it doesn't make sense if Debian has both forgejo and
gitea, and that forgejo is the better fit for Debian.
I'm working on getting forgejo packaged (#1058932), so I'll close this
bug in favour of it.
Regards,
Daniel
retitle 1058932 ITP: forgejo -- a self-hosted lightweight software forge
owner 1058932 Daniel Baumann
thanks
Hi,
I'm working on this.. it will be not quite, but I expect all the
necessary things to be uploaded over the 2 months/until end of year.
Regards,
Daniel
retitle 1058932 ITP: forgejo -- a self-hosted lightweight software forge
owner 1058932 Daniel Baumann
thanks
Hi,
I'm working on this.. it will be not quite, but I expect all the
necessary things to be uploaded over the 2 months/until end of year.
Regards,
Daniel
Package: ftp.debian.org
Hi,
please remove src:libyang3, it has been renamed to src:libyang.
Regards,
Daniel
Hi,
On 10/7/24 09:27, Phong Tran Thanh wrote:
> How about the disable scrub and deep-scrub
neither scrubbing nor deep-scrubbing should be disabled, it is an
integral part of ensuring data consistency and data availability.
if you disable it, ceph will not know when/if data on the disks/ssds has
Package: gitlab-ci-multi-runner
Severity: wishlist
Hi,
please upgrade gitlab-runner to the current upstream version (17.4.0),
the one in the archive is rather old.
Regards,
Daniel
On 10/4/24 09:16, Bastian Blank wrote:
> What is the plan to get this fixed?
I'm working on getting all required build-depends in debian, but I can
also just remove the non-free bits until thats done.
Regards,
Daniel
On 10/4/24 09:16, Bastian Blank wrote:
> What is the plan to get this fixed?
I'm working on getting all required build-depends in debian, but I can
also just remove the non-free bits until thats done.
Regards,
Daniel
On 9/23/24 13:04, Lukas Märdian wrote:
> It's sad to see that fellow DDs do not seem to care
It's sad to see that in this and the other thread before, the same weak
arguments in favour of netplan are repeated by you without neither
adressing the valid points raised against it, nor providing an act
On 9/23/24 13:04, Lukas Märdian wrote:
> It's sad to see that fellow DDs do not seem to care
It's sad to see that in this and the other thread before, the same weak
arguments in favour of netplan are repeated by you without neither
adressing the valid points raised against it, nor providing an act
close 1082067
thanks
On 9/18/24 06:49, Helmut Grohne wrote:
> I suggest removing zmodemjs from Debian for the following reasons:
it's a build-depends of ttyd. unfortunately, the whole webpack stuff
broke hard/incompatible in debian at some point, so stuff doesn't work
anymore and neeeds to be upd
Package: git-subrepo
Severity: wishlist
Hi,
it would be nice if you could update git-subrepo to the current upstream
version (0.4.9).
Regards,
Daniel
On 9/13/24 09:16, Helmut Grohne wrote:
> Please also mail the RC bug about your plans. Ideally, you cross
> reference blocking bugs (where other components need to be updated) such
> that others can see how they can help. Also mailing the bug is
> considered an activity on the autoremover side and
On 9/5/24 10:43, Marc Haber wrote:
> I don't see a problem with keeping ifupdown{2,-ng,} if none of those
> packages is part of the default install and we remove it from the
> beginner- and intermediate-level docs.
right, me neither; but Lukas' argument was that introducing netplan is
"unifying do
sorry, one more..
On 9/4/24 18:00, Lukas Märdian wrote:
> But we ought to look at the bigger picture!
>From that point of view, it doesn't make sense to even consider netplan.
No distribution other than ubuntu is using it.
If Debian uses network-manager and systemd-networkd, there's hardly any
d
On 9/4/24 18:00, Lukas Märdian wrote:
>> Of course we could. But who would actually care?
>
> That's exactly the problem!
I don't think so. I still have the impression that netplan wants to fill
a whole where in reality there's none.
In my experience networking from a systems point of view has d
On 9/4/24 17:49, Lukas Märdian wrote:
> Netplan is for the average user who googles about "how to configure network
> on debian" and ends up with the "4 ways to configure the network"
> [4ways] or
> even more options in the Debian Reference [debref]:
so, to exaggerate on purpose, netplan is only t
Hi,
On 9/3/24 18:24, Lukas Märdian wrote:
> The nice thing about Netplan is that it [...] functions as a
> layer on top.
I don't understand what actual problem netplan is trying to solve.
On servers I want systemd-networkd directly anyway (for lacp, vlan and
bridges), and on end-user desktops I'
severity 1079467 important
thanks
Hi Christian,
On 8/23/24 17:08, Christian Haul wrote:
> after upgrading to kernel 6.10.6 boot fails on mdadm not finding devices as
> none are configured. Going back to 6.10.3 fixes the problem.
thank you for your report. I can't reproduce it on my neither of my
severity 1079467 important
thanks
Hi Christian,
On 8/23/24 17:08, Christian Haul wrote:
> after upgrading to kernel 6.10.6 boot fails on mdadm not finding devices as
> none are configured. Going back to 6.10.3 fixes the problem.
thank you for your report. I can't reproduce it on my neither of my
/e17ea4ffd19c1a2bcd5ccc0e430ff476832ea618
Building with fixed cmake (Closes: #1078446).
Signed-off-by: Daniel Baumann
(this message was generated automatically)
--
Greetings
https
Hi,
thanks - while you were writing this I've uploaded a temporary fix (or
attempt for it) by setting JAVA_JVM_LIBRARY manually on architectures
that don't have the hotspot jvm but just the zero jvm.
I've opened a bug with the link to your patch to cmake, hopefully the
cmake debian maintainer wil
Hi,
thanks - while you were writing this I've uploaded a temporary fix (or
attempt for it) by setting JAVA_JVM_LIBRARY manually on architectures
that don't have the hotspot jvm but just the zero jvm.
I've opened a bug with the link to your patch to cmake, hopefully the
cmake debian maintainer wil
Package: cmake
Severity: serious
Tags: patch
Hi,
a few days ago, openjdk-21 was made the new default-jdk in unstable.
With openjdk-21, some changes apply which jvm is used/available on which
architecture and cmake doesn't detect them yet. Therefore, ceph does
FTBFS and possibly a bunch of other
Package: cmake
Severity: serious
Tags: patch
Hi,
a few days ago, openjdk-21 was made the new default-jdk in unstable.
With openjdk-21, some changes apply which jvm is used/available on which
architecture and cmake doesn't detect them yet. Therefore, ceph does
FTBFS and possibly a bunch of other
/fc0568864989a1532f742ac6656bce1520a32cfd
Correcting execution order of dh_movetousr, thanks to Helmut Grohne
(Closes: #1073640).
Signed-off-by: Daniel Baumann
(this message was
/7d0bd445e66b92db610fa0a5fff3066d7dfa5e4f
Correcting execution order of dh_movetousr, thanks to Helmut Grohne
(Closes: #1073640).
Signed-off-by: Daniel Baumann
(this message was
On 8/7/24 08:21, Daniel Baumann wrote:
> I'm uploading a new upstream version implementing this during the
> evening today.
I'm currently sick, but I will do it on the weekend.
Regards,
Daniel
Package: ftp.debian.org
Hi,
pendulum has been a dependency of pgcli and iredis, but they removed
that for a less complicated way of displaying relative timestamps in
more recent versions. Please remove pendulum from Debian.
Regards,
Daniel
close 1076259 20221002-16
thanks
Hi,
thanks for spotting it, I've uploaded fixed versions for both.
Regards,
Daniel
close 1076259 20221002-16
thanks
Hi,
thanks for spotting it, I've uploaded fixed versions for both.
Regards,
Daniel
tag 1041092 + pending
thanks
fixed in git, thanks for spotting and reporting it.
Regards,
Daniel
tag 1073640 + pending
thanks
fixed, pushing and uploading asap..
Regards,
Daniel
/6647b96bca5ee2254590f3ce6be6cf2c2c460171
Cherry-picking patches from upstream to fix FTBFS with gcc-14 (Closes:
#1074874).
Signed-off-by: Daniel Baumann
(this message was generated
tag 1074874 + pending
thanks
I've cherry-picked the necessary upstream commits on top of 18.2.4, will
finish running tests before uploading later on..
Regards,
Daniel
tag 1074874 + pending
thanks
I've cherry-picked the necessary upstream commits on top of 18.2.4, will
finish running tests before uploading later on..
Regards,
Daniel
close 1069702
thanks
Hi,
thank you for your report, I've fordwarded it to upstream in April:
https://github.com/tqdm/tqdm/issues/1575
Given that there's no progress on it here, I don't think that it's of
value to keep the duplicate of this upstream bug in the Debian bug
tracker, hence I'm closin
Hi Florian,
On 7/20/24 15:04, Florian Ernst wrote:
> When you orphaned libmicrohttpd with the upload of 1.0.0-2[0] you
> apparently also depublished its git repo[1]
I deleted it after a while when it wasn't picked up, so unfortunately I
can't have it anymore, sorry. :(
Regards,
Daniel
Hi Florian,
On 7/20/24 15:04, Florian Ernst wrote:
> When you orphaned libmicrohttpd with the upload of 1.0.0-2[0] you
> apparently also depublished its git repo[1]
I deleted it after a while when it wasn't picked up, so unfortunately I
can't have it anymore, sorry. :(
Regards,
Daniel
Package: wnpp
* Package name : jinjax
* Upstream Author : Juan-Pablo Scaletti
* License : MIT
* Homepage : https://github.com/jpsca/jinjax
https://jinjax.scaletti.dev
Regards,
Daniel
Package: wnpp
* Package name : jinjax
* Upstream Author : Juan-Pablo Scaletti
* License : MIT
* Homepage : https://github.com/jpsca/jinjax
https://jinjax.scaletti.dev
Regards,
Daniel
On 6/12/24 13:33, Jakub Ružička wrote:
I did what I could with the upstream packaging, so now it's your turn with
debian/experimental, Daniel, if you have the time :)
thanks for all the work - I will have a time for everything this Friday
afternoon/evening and will report back.
Regards,
Dani
Hi,
what's the status of getting 1.6 uploaded? Do you need any help?
Regards,
Daniel
Package: rspamd
Hi,
rspamd 3.8.4 has been released back in February - it would be nice if
you could update the package in Debian.
Regards,
Daniel
On 5/2/24 10:30, David Lamparter wrote:
I've managed to get sbuild crosscompile to work for hppa and found the
problem (it's a missing "XREF_SETUP()" line, not that the error message
would give any hint to that...)
yay!
I'll put a -2 together later today.
nice, feel free to ping me when don
On 4/30/24 12:56, David Lamparter wrote:
Ok, for the time being I've instead decided to use this as a kick in my
ass to finally do the NM procedure to become a Debian Maintainer...
https://nm.debian.org/process/1284/
hehe, nice ;)
I have no idea what kind of timescale that works on, but I pro
Hi David,
On 4/30/24 18:21, David Lamparter wrote:
flipped libatomic to be linked unconditionally.
it's not harmful to do so on architectures that don't need it, but imho
its cleaner to only be linked on affected architectures (armel m68k
powerpc sh4).
https://github.com/FRRouting/frr/com
Hi David,
On 4/30/24 18:21, David Lamparter wrote:
flipped libatomic to be linked unconditionally.
it's not harmful to do so on architectures that don't need it, but imho
its cleaner to only be linked on affected architectures (armel m68k
powerpc sh4).
https://github.com/FRRouting/frr/com
Hi,
On 4/30/24 18:12, Jakub Ružička wrote:
Secondary reason for that was that there is no upgrade path from 5.x to
6.x so it's unwanted for knot-resolver 5 packages to auto-update to 6.
For that, the package probably needs a different name (like
knot-resolver6)
imho this should be handled i
On 4/29/24 19:50, Daniel Baumann wrote:
pushing to the repo requires me to be added to the salsa project.. would
you mind adding me?
in the meantime, I've pushed to here:
https://git.progress-linux.org/users/daniel.baumann/debian/todo/knot-resolver/log/
before I'll continue: what&
On 4/23/24 14:45, Jakub Ružička wrote:
Awesome, I've forwarded your words of praise to the hard-working Knot
Resolver team :)
(jftr: we switched in 2015 from cisco ncr to unbound, and in 2016 from
unbound to knot-resolver.. and are super happy ever since)
I'm actually quite interested in (t
On 4/29/24 18:31, David Lamparter wrote:
Did you run into issues that forced you up to 2.1.148? The "officially
listed" (= in configure.ac) requirement is 2.1.128, if we(upstream)
missed something I'd look into getting that listed minimum bumped up
too.
Rechecking the frr 10 announcement.. say
Hi David,
On 4/29/24 16:56, David Lamparter wrote:
I can't do uploads myself (not a DM/DD)
no problem - I'm happy to sponsor your uploads if you want me to ;)
FRR definitely requires libyang 2.1.128.
hm, frr 10 needs libyang2 2.1.148.
which, as you noted, is already uploaded so for now -
tag 1067077 +pending
thanks
Hi,
my initial attempt in 10.0-0.2 to link with libatomic didn't work, I've
fixed that locally but a build to confirming on an armel porterbox is
runnning before uploading 10.0-0.3 in some minutes..
Regards,
Daniel
tag 1067077 +pending
thanks
Hi,
my initial attempt in 10.0-0.2 to link with libatomic didn't work, I've
fixed that locally but a build to confirming on an armel porterbox is
runnning before uploading 10.0-0.3 in some minutes..
Regards,
Daniel
Package: qa.debian.org
Severity: wishlist
Hi,
I've switched off TLS1.2 on my git server (to see what would be
brocken), one of them is VCSWatch:
Error: fatal: unable to access
'https://git.progress-linux.org/users/daniel.baumann/debian/packages/aio-eapi/':
gnutls_handshake() failed: Error i
Package: qa.debian.org
Severity: wishlist
Hi,
I've switched off TLS1.2 on my git server (to see what would be
brocken), one of them is VCSWatch:
Error: fatal: unable to access
'https://git.progress-linux.org/users/daniel.baumann/debian/packages/aio-eapi/':
gnutls_handshake() failed: Error i
Hi,
On 4/23/24 13:58, Jakub Ružička wrote:
but we've agreed the time has come to get extra testing & feedback
through Debian experimental.
yay, thanks!
[ we use knot-resolver at work for the central resolvers for the
university, and we love it. kresd 6 offers some nice improvements for
us,
Hi,
any news or ETA on this? do you need help?
Regards,
Daniel
Package: nwipe
Hi,
it would be nice if you could upload the current nwipe release to Debian.
Regards,
Daniel
Hi Tobias,
On 4/14/24 13:55, Tobias Frost wrote:
As I have the package ready, I'd like to propose to maintain it as new
package
In January 2023 I've uploaded gnome-shell-extension-vertical-workspaces
(and 5 other extensions) as individual source packages as every other
gnome-shell extension
Hi Tobias,
On 4/14/24 13:55, Tobias Frost wrote:
As I have the package ready, I'd like to propose to maintain it as new
package
In January 2023 I've uploaded gnome-shell-extension-vertical-workspaces
(and 5 other extensions) as individual source packages as every other
gnome-shell extension
Hi Tobias,
On 4/14/24 10:14, Tobias Frost wrote:
* Package name: gnome-shell-extension-vertical-workspaces
this is already included in src:gnome-shell-extensions-extra.
Regards,
Daniel
Hi Tobias,
On 4/14/24 10:14, Tobias Frost wrote:
* Package name: gnome-shell-extension-vertical-workspaces
this is already included in src:gnome-shell-extensions-extra.
Regards,
Daniel
close 1062068
thanks
Hi Anubhav,
thank you for your report.
Unfortunately you're using a very old version of nvme-cli that can not
be expected to work with recent firmware files.
Please upgrade nvme-cli to a more recent version (at last the one in
stable).
Regards,
Daniel
close 1064390 4.3-1
thanks
Hi Graham,
thanks - I've just uploaded 4.3.
Regards,
Daniel
retitle 1042906 please package new upstream version 9.x
thanks
Hi Lee,
any updates since last year? Ansible is currently at 9.x and I'd really
like to be able to use a recent enough version of ansible via debian
packages. Is there anything I could help you with?
Regards,
Daniel
Package: inkscape-open-symbols
Severity: wishlist
Hi,
thank you for maintaining inkscape-open-symbols.
As inkscape-open-symbols 1.2 is incompatible with inkscape 1.3 in
experimental, it would be nice if you could upload a newer version of
inkscape-open-symbols to experimental too.
Regards,
ngelog
@@ -1,3 +1,11 @@
+libnvme (1.3-1+deb12u1) bookworm; urgency=medium
+
+ * Uploading to bookworm.
+ * Cherry-picking upstream commits to fix buffer overflow during scanning
+devices that do not support sub-4k reads (Closes: #1054631).
+
+ -- Daniel Baumann Sun, 14 Apr 2024 08:57:21 +0200
+
ngelog
@@ -1,3 +1,11 @@
+libnvme (1.3-1+deb12u1) bookworm; urgency=medium
+
+ * Uploading to bookworm.
+ * Cherry-picking upstream commits to fix buffer overflow during scanning
+devices that do not support sub-4k reads (Closes: #1054631).
+
+ -- Daniel Baumann Sun, 14 Apr 2024 08:57:21 +0200
+
Package: frr
Severity: wishlist
Hi David and Ondrej,
it would be nice if you could upload the newly released frr version. If
you need/want help, I'm happy to do so, just let me know.
Regards,
Daniel
close 1067450
thanks
Hi,
On 3/21/24 18:03, Daniel wrote:
Mar 21 17:59:09 zone-s ttyd[1039170]: [2024/03/21 17:59:09:4449] E:
lws_create_context: failed to load evlib_uv
Mar 21 17:59:09 zone-s ttyd[1039170]: [2024/03/21 17:59:09:4449] E:
libwebsockets context creation failed
Mar 21 17:59:09 zo
close 1067450
thanks
Hi,
On 3/21/24 18:03, Daniel wrote:
Mar 21 17:59:09 zone-s ttyd[1039170]: [2024/03/21 17:59:09:4449] E:
lws_create_context: failed to load evlib_uv
Mar 21 17:59:09 zone-s ttyd[1039170]: [2024/03/21 17:59:09:4449] E:
libwebsockets context creation failed
Mar 21 17:59:09 zo
Package: libyang2
Severity: wishlist
Hi Ondrej,
it would be nice if you could upload libyang2 >= 2.1.128 as the new frr
release requires that. If you need/want help, I'm happy to do so, just
let me know.
Regards,
Daniel
Package: knot-resolver
Severity: wishlist
Hi,
it would be nice if you could upload knot-resolver 6.x to experimental.
Regards,
Daniel
Package: frr
Version: 9.1-0.1
Severity: normal
Hi,
please find the diff of the NMU from 8.4.4-1.1 to 9.1-0.1 as patch attached.
I noticed that frr could do with some more packaging love, I'd be happy
to help out if you need/want any.
Regards,
Daniel
frr_9.1-0.1.patch.gz
Description: applica
On 3/8/24 15:28, Helmut Grohne wrote:
> $FILE needs to be used here.
thanks.
> I was about to NMU zutils. Can you move ahead soonish? Once zutils is
> uploaded, I can go ahead with gzip.
sure, will upload in ~3h from now.
Regards,
Daniel
Hi Helmut,
thanks for the patch and work on this, much appreciated.
Just to be sure - I think I've found a typo in the latest iteration of
the patch, could you please confirm?
https://git.progress-linux.org/users/daniel.baumann/debian/packages/zutils/commit/?id=a4f81b9df9543f588c0528614264694056
On 12/22/23 12:30, Helmut Grohne wrote:
I am happy with all of these changes moving to
unstable and trixie.
applied and uploaded both p-l-metapackages and bfh-metapackages to unstable.
Thanks for your patience.
thank you for all your work and help!
Regards,
Daniel
On 12/22/23 12:30, Helmut Grohne wrote:
I am happy with all of these changes moving to
unstable and trixie.
applied and uploaded both p-l-metapackages and bfh-metapackages to unstable.
Thanks for your patience.
thank you for all your work and help!
Regards,
Daniel
Hi Helmut
On 12/19/23 15:13, Helmut Grohne wrote:
Based on the work on molly-guard, I'm ataching an updated patch and it
really is a copy of the one on bfh-container #1055509, so see there for
the why its done the way its done.
great, thanks!
I'll test it tomorrow and upload.
Regards,
Daniel
Hi Helmut
On 12/19/23 15:13, Helmut Grohne wrote:
Based on the work on molly-guard, I'm ataching an updated patch and it
really is a copy of the one on bfh-container #1055509, so see there for
the why its done the way its done.
great, thanks!
I'll test it tomorrow and upload.
Regards,
Daniel
Hi,
On 12/11/23 15:52, grin wrote:
> Could you write at least a short note into README.Debian (or TODO) behind the
> reasons
> why ML is not compiled in?
I'm currently re-working the netdata packaging after the latest upstream
changes, which is quite some work.. this issue is definitely on the
t
Package: sentinelsat
Severity: wishlist
Hi Simon,
thank you for maintaining sentinelsat in Debian.
It would be nice if you could update it to the current upstream version
(1.2.1).
Regards,
Daniel
Package: icingaweb2-module-reporting
Severity: wishlist
Hi David,
thank you for maintaining icingaweb2-module-reporting in Debian.
It would be nice if you could update it to the current upstream version
(1.0.1).
Regards,
Daniel
Package: port-for
Severity: wishlist
Hi David,
thank you for maintaining port-for in Debian.
It would be nice if you could update it to the current upstream version
(0.7.2).
Regards,
Daniel
Package: icingaweb2-module-x509
Severity: wishlist
Hi David,
thank you for maintaining icingaweb2-module-x509 in Debian.
It would be nice if you could update it to the current upstream version
(1.3.2).
Regards,
Daniel
Package: icingaweb2-module-director
Severity: wishlist
Hi David,
thank you for maintaining icingaweb2-module-director in Debian.
It would be nice if you could update it to the current upstream version
(1.11.0).
Regards,
Daniel
Package: icingaweb2-module-cube
Severity: wishlist
Hi David,
thank you for maintaining icingaweb2-module-cube in Debian.
It would be nice if you could update it to the current upstream version
(1.3.2).
Regards,
Daniel
Package: icingaweb2-module-businessprocess
Severity: wishlist
Hi David,
thank you for maintaining icingaweb2-module-businessprocess in Debian.
It would be nice if you could update it to the current upstream version
(2.5.0).
Regards,
Daniel
Package: icingaweb2-module-graphite
Severity: wishlist
Hi David,
thank you for maintaining icingaweb2-module-graphite in Debian.
It would be nice if you could update it to the current upstream version
(1.2.4).
Regards,
Daniel
Package: geomet
Severity: wishlist
Hi Simon,
thank you for maintaining geomet in Debian.
It would be nice if you could update it to the current upstream version
(1.1.0).
Regards,
Daniel
Hi Olivier,
thanks you, that is much apperciated. I've been mostly away/VAC the last
two weeks, but I'll take care about this and the other patch later today.
Regards,
Daniel
On 11/15/23 19:52, Daniel Baumann wrote:
> for 18.2.0, there's only one trivial thing needed:
> https://git.progress-linux.org/packages/graograman-backports-extras/ceph/commit/?id=ed59c69244ec7b81ec08f7a2d1a1f0a90e765de0
or, for mainline inclusion, an alternative depends would be s
On 11/15/23 19:31, Gregory Farnum wrote:
> There are versioning and dependency issues
for 18.2.0, there's only one trivial thing needed:
https://git.progress-linux.org/packages/graograman-backports-extras/ceph/commit/?id=ed59c69244ec7b81ec08f7a2d1a1f0a90e765de0
then, the packages build fine/as-i
On 11/13/23 17:14, Luke Hall wrote:
> How is it that Proxmox were able to release Debian12 packages for Quincy
> quite some time ago?
because you can, as always, just (re-)build the package yourself.
> My understanding is that they change almost nothing in their packages
> and just roll them to f
On 11/9/23 07:35, Nizamudeen A wrote:
> On the Ceph GUI, we thought it could be interesting to show information
> regarding the community events, ceph release information
like others have already said, it's not the right place to put that
information for lots of reasons.
one more to add: putting
close 1041689 1.5-2
thanks
Hi Marc,
On 8/8/23 11:07, Marc Bres Gil wrote:
> I've downloaded it from sid repositories, installed manually and seems
> to work.
thank you for confirming and reporting it in the first place, I'm
closing the bug now.
Regards,
Daniel
1 - 100 of 3418 matches
Mail list logo
