Hi Ian,
I can't remember what I did when I updated the patch, but a simple
text merging sounds more probable than performing all the tests again.
Please note that I no longer work for the company where we maintained
a dpkg-based Linux distro and kept on sending bugreports or patches to
## ####### ## ##
## ## ## ### ## ## ## ## ## ##
## ## ## ## ## ## ## ## ##
## ## ## ## #### ## ## ## ##
## ## ## ## ## ## ## ## ##
An obvious temporary workaround is __not__ using an __8-bit__ locale...
This is a quite serious typo that inverts the sense of the sentence...
By the way, I don't agree that this is a good workaround, as it leads to
different system setup, filenames or text file contents being encoded in
Ping! ...
It was 2 years ago that I posted this bugreport, including:
- detailed description of what to do for the bug to occur,
- detailed explanation where and why the source is buggy,
- patch to fix the problem.
Just a note I haven't mentioned before: this patch has already survived 2
Hi,
I send these two patches updated to the newest dpkg (namely 1.13.22).
Is there any chance that they'll be reviewed and probably committed by
someone around there?
--
Egmont
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=281057
diff -Naur dpkg-1.13.22.orig/src/processarc.c
Package: dpkg
Version: 1.13.22
Severity: wishlist
Currently if the argument of dpkg -S ends with a slash, no match is found.
E.g.
dpkg -S /usr/include - lots of packages found
dpkg -S /usr/include/ - no output
Since the TAB completion feature of most shells (including the default bash)
puts a
A fix for VTE is available at
https://bugzilla.gnome.org/show_bug.cgi?id=729533 -- it used to handle
bracketed paste mode differently than other terminals.
I might create a patch for MC too (after all, it should work with current
VTE), but after a first glimpse it doesn't look trivial.
egmont
Package: vte3
Version: 1:0.36.0-2
VTE 0.36 changed the control sequences generated for Home and End.
They used to be \eOH and \eOF, now they are the xterm-compatible \e[H
and \e[F. (Due to an unfortunate bug, they are \e[1~ and \e[4~ for
the keypad, this is already fixed in git. Forget these
Mainstream vte-0.36.2 release fixes the bug.
On Tue, May 6, 2014 at 3:50 PM, Egmont Koblinger egm...@gmail.com wrote:
A fix for VTE is available at
https://bugzilla.gnome.org/show_bug.cgi?id=729533 -- it used to handle
bracketed paste mode differently than other terminals.
I might create
The mainstream bugreport is
https://bugzilla.gnome.org/show_bug.cgi?id=677329
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Upstreamed:
https://bugzilla.gnome.org/show_bug.cgi?id=732127
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
You can use a space instead of '=', i.e.:
gnome-terminal --working-directory ~/Storage
It'll work as you'd expect.
It's a feature of the *shell* that it looks up the home directory if
the '~' is the first character of a word. If you use '=' as separator
then '~' is not the first character and
See also: http://lists.gnu.org/archive/html/bug-bash/2007-12/msg3.html
On Thu, Jun 26, 2014 at 11:45 AM, Egmont Koblinger egm...@gmail.com wrote:
You can use a space instead of '=', i.e.:
gnome-terminal --working-directory ~/Storage
It'll work as you'd expect.
It's a feature
I've reported this upstream:
https://bugzilla.gnome.org/show_bug.cgi?id=731137
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
I've reported this upstream:
https://bugzilla.gnome.org/show_bug.cgi?id=731137
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Please see
https://bugzilla.gnome.org/show_bug.cgi?id=730128
for official upstream response.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Unfortunately this is not yet fixed upstream. I've forwarded upstream at
https://bugzilla.gnome.org/show_bug.cgi?id=731155
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Hi Nicolas,
What is this application you're running?
Could you please run it under script and attach the resulted typescript file?
thx,
egmont
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Hi Tollef,
I've filed the bug upstream here:
https://bugzilla.gnome.org/show_bug.cgi?id=731230
I'll be happy to work on fixing this. If you have a reproducible test
case that'd help a lot!
thanks,
egmont
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of
I suspect it's the same as the recently-fixed
https://bugzilla.gnome.org/show_bug.cgi?id=730389
https://git.gnome.org/browse/gnome-terminal/commit/?id=f65261a
Could you maybe try to backport that patch to your gnome-terminal?
--
To UNSUBSCRIBE, email to
Transparency was indeed removed from official gnome-terminal.
A patch to bring it back is available at
https://code.launchpad.net/~larsu/gnome-terminal/update-restore-transparency-patch
(This an improved version over the original patch from
Fixed upstream, will appear in vte-0.38 (gnome-terminal-3.14).
On Tue, Jun 3, 2014 at 12:57 PM, Egmont Koblinger egm...@gmail.com wrote:
Unfortunately this is not yet fixed upstream. I've forwarded upstream at
https://bugzilla.gnome.org/show_bug.cgi?id=731155
--
To UNSUBSCRIBE, email
Mainstream bugreport is at http://www.midnight-commander.org/ticket/1539
mc-4.8.13 will hopefully fix this.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
This is probably the same as
https://bugzilla.gnome.org/show_bug.cgi?id=730763. Could you please verify
if you experience the same symptoms as there (e.g. focus out repaints the
screen; the timestamp printed by a date reveals that it's executed as
soon as you hit Enter, even though the display is
I'd argue that this is a bug in your Gnome theme. The close button
shouldn't change its size on hover. If it does, weird things are bound to
happen, and I'm not sure if gnome-terminal could (and really don't think it
should) try to do anything to prevent this.
Zerothly, there is no need for a patch; gnome-terminal supports
transparency just fine.
It's not the same. With the given patch, you get a translucent
background, but all other colors remain opaque. With a WM/compositing
approach even the foreground colors, non-default background colors,
and
Fyi: The transparency patch indeed did appear in Ubuntu Vivid.
On Sun, Nov 2, 2014 at 12:48 PM, Egmont Koblinger egm...@gmail.com wrote:
Zerothly, there is no need for a patch; gnome-terminal supports
transparency just fine.
It's not the same. With the given patch, you get a translucent
Hi Jérémy,
Thanks for the report, I forwarded it upstream:
https://bugzilla.gnome.org/show_bug.cgi?id=740929
Could you please verify that this only occurs to you if you close the
tab/window by its X button or a shortcut key, and not when you ask the
shell to exit (with Ctrl+D or the exit command
Upstream fix is at
https://git.gnome.org/browse/vte/commit/?h=vte-0-38id=d9d83d4
On Sun, Nov 30, 2014 at 6:46 PM, Egmont Koblinger egm...@gmail.com wrote:
Hi Jérémy,
Thanks for the report, I forwarded it upstream:
https://bugzilla.gnome.org/show_bug.cgi?id=740929
Could you please verify
The first upstream fix was incorrect. The correct fix is these two commits
on top of each other:
https://git.gnome.org/browse/vte/commit/?h=vte-0-38id=d9d83d4
https://git.gnome.org/browse/vte/commit/?h=vte-0-38id=b033047
FYI: New upstream tarball is released with the fix.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
vte-0.39.1 (to be released as stable in Gnome-3.16) changes this to
xterm-256color.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
This is caused by https://bugzilla.gnome.org/show_bug.cgi?id=677329 ,
a bug in either Gtk+ or X (unfortunately we don't know).
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
I wonder if it's the same as
https://bugzilla.gnome.org/show_bug.cgi?id=735101 ... probably it is.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Hi,
I've been an active contributor/developer of gnome-terminal in the
last 1.5 years.
I firmly disagree with Christoph's comment Apparently upstream
intentionally breaks things or simply doesn't care.
We do care, and we worked hard recently to make gnome-terminal work
reasonably close to
Forwarded upstream: https://bugzilla.gnome.org/show_bug.cgi?id=746665
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Upstream: https://bugzilla.gnome.org/show_bug.cgi?id=748520
cheers,
e.
In Preferences, you can specify whether a new terminal should be opened in
a tab or a window. This setting is used if you click on the Open Terminal
menu entry.
As you've realized, the two actions still have their separate shortcuts.
It's only the menu entry that offers only one or the other,
Sounds the same as https://bugzilla.gnome.org/show_bug.cgi?id=735101 -
follow this link to find the fix to the Gtk+ patch (
https://git.gnome.org/browse/gtk+/commit/?id=561ff51a) which should ideally
be backported indeed.
e.
Duplicate of bug 765877?
e.
Hi,
As per Andreas's off-bugtracker request, let me send a skeleton patch.
It compiles but sure doesn't run correctly; but at least shows which
are the bits that need to be addressed by someone familiar with
synaptic and C++. Please make sure to review every line of the patch
and address all the
Thanks, I filed it upstream: https://bugzilla.gnome.org/show_bug.cgi?id=754497
> If you have time it would be awsome to test the latest git.
Thanks for your work!
Unfortunately I don't think I'll have time to test it. If it "seems
to" work (starts up the command properly) there's hardly anything that
can go wrong. I recommend that you apply your patch and let the
community
Actually, instead of 0.98 you should really consider the gtk3 bazaar branch.
At this moment, it contains 2 known regressions compared to the gtk2
bazaar branch (which already has maybe two dozens of bugfixes since
0.98), and the underlying VTE library (responsible for the terminal
emulation
Package: cowsay-off
Version: 3.03+dfsg1-15
Package description says:
This package contains cows witch some may consider to be offensive.
Should be s/witch/which/
Upstream investigation and fix:
https://github.com/FreeRDP/Remmina/issues/835
https://bugzilla.gnome.org/show_bug.cgi?id=765382
Package: wnpp
Severity: wishlist
Version: 1.0.0 (as tagged in git) or newer from the 'stable' branch
(see https://github.com/gnunn1/terminix/issues/25)
URL: https://github.com/gnunn1/terminix
License: MPL
Terminix is a tiling terminal emulator.
It is more or less similar to Terminator (which is
> all terminals in Debian I'd call good currently use libvte9
This is quite subjective.
You might judge a terminal emulator by the "chrome" (the UI, menus, config
dialog, etc.) and then it's entirely up to your taste which one you prefer.
Or you might judge it by the actual terminal behavior.
Even though triggered by a recent change in mc, this is not a bug in mc,
rather a bug in the (ancient, unmaintained, Gtk2-based) libvte9 (vte-0.28).
See the upstream mc bug, as well as the other mc bug linked from there for
explanation.
Fix for libvte9 is at
Hi,
By the way, see https://bugs.launchpad.net/ubuntu/+source/bash/+bug/1566437
comment 7.
I'm wondering, does this workaround really belong to mc? Shouldn't rather
the shell prompt (PS1) emit all kinds of escape sequences that reset plenty
of terminal settings (that faulty apps might leave in a
Hi guys,
Just one click away from the linked bug 820303, namely in
https://bugzilla.gnome.org/show_bug.cgi?id=765382 it was clearly concluded
-- and confirmed even by a Remmina developer -- that it was a bug in
Remmina, accidentally triggered by a (not buggy) change in VTE.
Again, repeating: It
Marek: "Is this bug already in upstream?"-- you've missed my previous
comment here that begins with "Upstream investigation and fix". Please
those links.
Yup, mainstream VTE and Remmina developers have together investigated this
issue, located the bug in Remmina, and came up with a patch.
Probably relevant: https://bugzilla.gnome.org/show_bug.cgi?id=769898
6 at 11:04 AM, Egmont Koblinger <egm...@gmail.com> wrote:
> Probably relevant: https://bugzilla.gnome.org/show_bug.cgi?id=769898
>
There was no upstream bugreport up until now, however, I've talked to vte's
main developer when I saw the roxterm bug and he had no clue about it
either (neither did I). Mind you, neither of us actually started to deeply
investigate the story.
I've created an upstream bug now:
Hi,
I belive this is the same as the upstream bug at
https://bugzilla.gnome.org/show_bug.cgi?id=725342, which in turn boiled
down to the Gtk+ focus-out issue:
https://bugzilla.gnome.org/show_bug.cgi?id=677329.
If so, it's fixed in gtk+ 3.18.9.
cheers,
e.
Hi,
Terminator 1.90 (based on gtk3) has been released. In the mean time, the
gtk2 version will no longer be maintained.
Please see the official announcement at
https://gnometerminator.blogspot.com/2016/11/because-theyre-like-buses-which-is.html
.
cheers,
egmont
Hi,
FYI: Approximate memory usage (RSS) for me right after starting up the apps
is:
gnome-terminal, xfce4-terminal, mate-terminal: 35 MB
terminator: 55 MB
terminix: 60 MB
I'm on Ubuntu Yakkety, some of these apps are from Zesty beta or manually
compiled, all of them using Gtk+-3 and
Hi,
I think this is fixed in the brand new 1.90 version; could you please
confirm it?
cheers,
egmont
Oh, wait...
The fact that these file descriptors remain open _even after you close the
corresponding terminal_ is still present (in Terminator-1.90) and is an
actual valid issue.
Hang on, I'll investigate.
e.
I've reported this issue upstream:
https://bugs.launchpad.net/terminator/+bug/1645500
e.
FYI:
VTE (Debian package name: libvte-2.91-0) no longer ships gnome-pty-helper
as of version 0.42.
VTE, and in turn gnome-terminal, no longer does utmp/wtmp logging at all.
See https://git.gnome.org/browse/vte/commit/?id=299c700 and
https://bugzilla.gnome.org/show_bug.cgi?id=747046 for further
Hi,
Terminator-0.98 uses the gtk2-based vte for terminal emulation, which does
have a bug that sounds like the one you're describing.
Please ask the maintainers to upgrade to Terminator-1.90 (see Debian bug
807668) which uses the much newer gtk3-based vte, in which we've fixed the
scrollback
Pretty much the same: https://sourceforge.net/p/roxterm/bugs/127/
Hi,
Terminator-0.98 uses the gtk2-based vte for terminal emulation, which does
have a bug around the so-called "bracketed paste mode" which causes the
behavior you see.
Please ask the maintainers to upgrade to Terminator-1.90 (see Debian bug
807668) which uses the much newer gtk3-based vte, in
Hi,
Terminator-0.98 uses the gtk2-based vte for terminal emulation, which does
have a bug that sounds like the one you're describing (and yes it was
related to coloring).
Please ask the maintainers to upgrade to Terminator-1.90 (see Debian bug
807668) which uses the much newer gtk3-based vte, in
Hi,
It is by design that Terminator (more precisely, the vte widget that does
the actual terminal emulation) stores the scrollback data in unlinked
temporary files.
Terminator-0.98 uses the gtk2-based vte for terminal emulation, which uses
too many of them, up to 12 per vte (that is, per
Hi,
I've just read it more carefully that you're not only worried about the
number of files, but also about the overall disk usage and the entire
design as well.
Along with the encryption, compression was also implemented, so the overall
occupied size is now (with the gtk3-based vte-0.40 or
The correct setting for TERM is xterm (or rather xterm-256color). This
variable is supposed to refer to a terminal behavior description, not to
the name of the executable that is a terminal emulator.
Terminator uses the VTE widget for actual terminal emulation, which in turn
tries to emulate
Hi,
I can confirm the transparency problem. It works on Ubuntu's default Unity
7, though.
Also, transparency works under both Mutter and Unity 7 with some other
emulators based on the same VTE, namely gnome-terminal with Ubuntu's
transparency patch, Terminix, and xfce4-terminal.
Forwarded
This is two separate bugreports.
Transparency: What desktop / window manager are you using? VTE has reworked
transparency and it requires a compositing WM.
/usr/bin/who not reporting ttys: VTE, as per
https://bugzilla.gnome.org/show_bug.cgi?id=747046, no longer does utmp/wtmp
logging.
e.
I've halved all the size numbers in the config, and it still appears
perfectly for me (now the overall window is a "regular" window, smaller
than the screen in both dimensions).
Just for the record: What is your desktop environment / window manager?
thx,
egmont
Hi,
I cannot reproduce this issue on Ubuntu 16.10 with Terminator-1.90 using
your config. I get a terminator window occupying the entire screen, with
2x2 terminals in an equal split.
Your config seems to contain hardcoded pixel values like 3200, 1672,
1600... The exact behavior might easily
Hi,
Right click menu's "Show Menubar" by design only influences the
current window (similarly to some other options there, such as
selecting a Profile or toggling Read-Only).
What you're looking for is the global menu's Edit -> Preferences ->
"Show menubar by default in new terminals".
cheers,
Hi,
This is a truly interesting bug.
If you highlight and copy-paste only the printed "1" or "2" digits, you'll
notice that "1" carries the combining strikethrough with it. This is one
possible way of making sure that VTE's belief about where that combining
accent is is correct. The problem
Hi,
I cannot reproduce the issue -- in fact, I came across it on the
bugs.debian.org website which is encoded in UTF-8 so it cannot represent
the non-UTF-8 you're talking about. I'm copy-pasting the command but it's
perfectly valid UTF-8 and no lockup happens. It would be great if you could
The missing translations were committed into mainstream gnome-terminal git
after the 3.26.0 release, and hence will appear in 3.26.1.
See also
https://bugs.launchpad.net/ubuntu/+source/fonts-liberation/+bug/299158.
Hi guys,
Quickly glazing through the thread, a couple of remarks:
- screen/tmux indeed needs that TERM inside them is something
screen-related. Forget xterm or xterm-256color, go with screen,
screen-256color or screen.xterm-256color or alike. This is properly
documented in their docs/faqs and
Hi,
Terminal emulators don't send anything special on Ctrl-(Shift-)Enter, they
can only send the same newline they do on Enter.
MC has a hack called X11 support: Whenever it receives a newline from the
terminal emulator, it queries the X server whether any modifier is pressed
at that time.
This has just been implemented in upstream git, will be available in
vte-0.52.
Hi guys,
> We don't do c++ in d-i.
Unfortunately this sounds really problematic. As of version 0.42 vte
has been using (more and more) C++. This is not like Ubuntu's PCRE2
hack which is a matter of a few hours of work reverting and merging a
few commits. It's reasonably impossible to revert to
Package: guake
Version: 3.0.0.b2-1
The brand new package for Guake's GTK+3 version depends on certain
development packages, such as libglib2.0-dev, libgtk-3-dev and
libvte-2.91-dev. Presumably they pull in dozens of other packages as
dependencies, if not hundreds (complete X11 development suite).
Package: libvte-2.91-common
Version: 0.50.2-4
The contents of /usr/share/vte/termcap-2.91/xterm have been unchanged
at least since 0.28 (gtk2), about 6 years ago.
xterm's terminfo description has changed significantly since then.
VTE's behavior has changed a lot (got much closer to xterm).
I
Hi Sven & Alastair,
Thanks a lot for this bugreport and the quick fix!
I've asked Slang's author to release version 2.3.2 in the near future
to officially fix this issue, and he agreed to do so at the end of
this month. See [1].
If that indeed happens, upgrading to 2.3.2 would be a cleaner,
Upstream gnome-terminal bugreport at: https://gitlab.gnome.org/
GNOME/gnome-terminal/issues/29 ... although chances are it's a bug in some
other component, not gnome-terminal or vte. I'd appreciate if you could
join our investigation there.
thanks,
egmont
Hi,
FYI: slang-2.3.2 is out now.
cheers,
e.
On Wed, Feb 21, 2018 at 3:17 PM, Egmont Koblinger <egm...@gmail.com> wrote:
> Hi Sven & Alastair,
>
> Thanks a lot for this bugreport and the quick fix!
>
> I've asked Slang's author to release version 2.3.2 in the near f
Hi,
Just for the record, the test file is the same as in bug 912329, correct?
In which direction do you move the other window? (I tried multiple
possibilities.) I couldn't reproduce the bug on Ubuntu Cosmic, fvwm, and
vte 0.54.2's test app.
If you feel like, could you help trying out vte 0.54.2
Hi,
Sorry, I missed that you actually attached a screenshot.
I can see double lines there, on the outer frame of the first picture.
Could you please elaborate what is the problem you're seeing?
Thanks,
egmont
On Tue, Oct 30, 2018 at 1:57 PM Egmont Koblinger wrote:
> Hi,
>
> Could y
Hi,
Could you please post a screenshot?
I get double lines in the outer rectangle of the first picture.
The font should be irrelevant. These characters are drawn manually by VTE,
not taken by the font. Just to be sure, I've checked with your font too. I
get double lines, each 2px wide, with a
Note, mostly for myself: This reminds me of
https://bugzilla.gnome.org/show_bug.cgi?id=721761#c47 .
Could you please post a screenshot of the entire contents of your screen,
or perhaps even a screencast? Details like the location of the
previous/next character of whatever kind (e.g. manually
Hi,
Thanks for the screencast, I'll try to see if I can reproduce the bug based
on that. (I noticed the glitch at the right side of the test file, at the X
pattern too.)
> It is better to move the window slowly
Yes, that's what I did, pixel by pixel.
> handled by VTE like the box ones?
Yes,
Hi,
Sorry, I missed this bit:
> I've just tried on another machine, which uses nouveau instead of
> the nvidia driver, and I cannot reproduce the issue.
Does that machine have the very same packages (e.g. both are an up-to-date
sid), same cairo version, same configs (I know this one's
Package: libvte-2.91-0
Version: 0.54.0-1
Severity: grave
Open gnome-terminal, and use its Terminal -> Set Character Encoding
menu to switch to another encoding. Switch back, then again to
something different.
gnome-terminal crashes.
Mainstream vte 0.54.1 fixes this issue. Could you please
Hi,
At the end of your prompt you emit \e[37m, that is, change to the 7th
palette color (typically light gray), rather than the default color of
your emulator. That is, the status at the beginning of executing your
command, the status used for the letter "A" is not the default status,
not the one
A minor correction: The said changes appeared in vte 0.52
(gnome-terminal 3.28). Version 0.54 didn't change anything around
colors.
Hello,
I also tried and couldn't reproduce the problem.
It's probably a race condition as gnome-terminal asks to be of size
999x999, and the window manager rejects it and forces a smaller one.
How do you exactly set the size from vim? Do you put these lines in vimrc,
or you type these commands
Hi,
I can also reproduce the problem under Wayland + gnome-shell (but not on
X11). On Wayland the window is not forced to fit in the screen, on X11 it
is (with gnome-shell).
(I incorrectly thought I was testing with Wayland previously while I was
actually on X11. I should've tried both, anyways,
Hi,
> it seems some people continued ROXTerm development on Github:
I'd like to emphasize that it's not just "some people" who continue roxterm
(maybe an unofficial fork or so). It's _the original author_ who moved it
to a different location and is working on the project again.
cheers,
egmont
... and he's also the maintainer of the Debian package, haha, I missed this
bit :)
Tony, do you feel like reviving maintenance of the Debian package, or
perhaps finding a new maintainer for it?
Thanks,
egmont
1 - 100 of 149 matches
Mail list logo
