Bug#1104244: RFS: foomuuri/0.28-1 [ITA] -- multizone bidirectional nftables firewall

On Sun, Apr 27, 2025 at 08:33:34PM +0100, Jeremy Sowden wrote: > I'll pick this up. I'm a member of the Shorewall team and I have been > informed that the Foomuuri maintainer (formerly of the SW team) has put > the package up for adoption. Thanks, Jeremy! -r

Bug#1095421: O: rcs -- The GNU Revision Control System

-Thi became one. > > A quick glance at the archives of one of RCS mailing lists shows that > at least Paul is still active [1]. > > [1] https://lists.gnu.org/archive/html/bug-rcs/ That's great news. Thanks all. -- Romain Francoise https://people.debian.org/~rfrancoise/

Bug#1095421: Acknowledgement (O: rcs -- The GNU Revision Control System)

The Debian packaging can be found in the shared Debian group on Salsa: https://salsa.debian.org/debian/rcs -- Romain Francoise https://people.debian.org/~rfrancoise/

Bug#1095422: Acknowledgement (O: metastore -- Store and restore metadata from a filesystem)

The Debian packaging can be found in the shared Debian group on Salsa: https://salsa.debian.org/debian/metastore -- Romain Francoise https://people.debian.org/~rfrancoise/

Bug#1095472: O: foomuuri -- multizone bidirectional nftables firewall

Package: wnpp Severity: normal X-Debbugs-Cc: foomu...@packages.debian.org Control: affects -1 + src:foomuuri I intend to orphan the foomuuri package. It's a new-ish project, introduced in Debian in 2023, that is the spiritual successor to Shorewall. It's a Python script which can generate arbitrar

Bug#1095422: O: metastore -- Store and restore metadata from a filesystem

Package: wnpp Severity: normal X-Debbugs-Cc: metast...@packages.debian.org Control: affects -1 + src:metastore I intend to orphan the metastore package. I have not used it for some time, the last upstream release was in 2018 and the upstream author mentioned in a GitHub issue that he's no longer a

Bug#1095421: O: rcs -- The GNU Revision Control System

Package: wnpp Severity: normal X-Debbugs-Cc: r...@packages.debian.org Control: affects -1 + src:rcs I intend to orphan the rcs package. It is in good shape from the Debian perspective, however the software itself can now be considered legacy. Unfortunately the upstream maintainer passed away a few

Bug#1093667: tmux crashes when I use this .tmux.conf

On Tue, Jan 21, 2025 at 4:21 AM Richard Alhama wrote: > set-option -g default-command "reattach-to-user-namespace -l zsh" `reattach-to-user-namespace' is a macOS utility and it's not necessary in Debian, you need to comment out this line. -- Romain Francoise ht

Bug#1035401: release-notes | upgrading.rst: Mention tmux in preference to screen (!213)

g opinion on the MR; as far as I know, screen doesn't make any compatibility promises either, it was just stagnant for many years. -- Romain Francoise https://people.debian.org/~rfrancoise/

Bug#1078771: SEGV when running tcpdump -Z root

Good find. Thanks for the report, and the patch. -- Romain Francoise https://people.debian.org/~rfrancoise/

Bug#1076965: vim-ultisnips: autopkgtest fails with tmux from experimental

Source: vim-ultisnips Version: 3.2-2 Severity: minor Tags: patch tmux in experimental is a snapshot from upstream Git and reports its version as 'next-3.5' at the moment, which does not match a regexp used in one of the autopkgtests. Trivial patch is: diff --git a/test/vim_interface.py b/test/vi

Bug#1073981: tmux: entering copy mode is very slow with large history

My patch was accepted upstream; please test again with 3.4-7 when that reaches your machine. -- Romain Francoise https://people.debian.org/~rfrancoise/

Bug#1073981: tmux: entering copy mode is very slow with large history

Found it. Upstream PR: https://github.com/tmux/tmux/pull/4013 -- Romain Francoise https://people.debian.org/~rfrancoise/

Bug#1073981: tmux: entering copy mode is very slow with large history

emory grid, it allocates the same huge amount of memory and copies everything over. In 3.4 this involves way more memory. It's also much much slower than 3.3a at actually accepting the output from cat, which is unsurprising. I'll dig deeper. -- Romain Francoise https://people.debian.org/~rfrancoise/

Bug#1073981: tmux: entering copy mode is very slow with large history

0M lines of scrollback history in each window? Also, I'm curious. Is it better with an empty `status-right'? -- Romain Francoise https://people.debian.org/~rfrancoise/

Bug#1071977: tmux: /lib/x86_64-linux-gnu/libtinfo.so.6: version `NCURSES6_TINFO_6.4.current' 404

Downgrading this bug while we wait for more information for the submitter. -- Romain Francoise https://people.debian.org/~rfrancoise/

Bug#1072231: Switch wtmp writing to libwtmpdb

On Thu, May 30, 2024 at 9:00 PM Chris Hofstaedtler wrote: > > tmux updates utmp through libutempter. Will that be updated to use the > > new format? > > Unclear. OK, in any case tmux does not implement this format so the bug can either be reassigned to libutempter, or closed.

Bug#1072231: Switch wtmp writing to libwtmpdb

table. tmux updates utmp through libutempter. Will that be updated to use the new format? Thanks, -- Romain Francoise https://people.debian.org/~rfrancoise/

Bug#1071977: tmux: /lib/x86_64-linux-gnu/libtinfo.so.6: version `NCURSES6_TINFO_6.4.current' 404

.. Are you 100% sure that this tmux binary is the one shipped in the Debian package? Can you show the path and SHA256 of the binary? And run ldd on it? Thanks, -- Romain Francoise https://people.debian.org/~rfrancoise/

Bug#1070724: tmux: take flock on socket file/dir in /tmp/

7;s not something that I feel would be appropriate as a Debian-specific change, but I can discuss it with the upstream author. Not much chance of it happening though. Best, -- Romain Francoise https://people.debian.org/~rfrancoise/

Bug#1067057: tcpdump: Environment undocumented in the man page, yet the TZ variable has effect on the timezone

tcpdump has no special handling of TZ, it just calls strftime() which handles TZ as described in strftime(3). -- Romain Francoise https://people.debian.org/~rfrancoise/

Bug#1067056: libpcap0.8: man page gives incorrect syntax specification for 'proto ICMP'

roto 1' or 'ip proto \icmp' which are equivalent. 'proto \icmp' also works but generates support code for IPv6 as well which does not really make sense for ICMP and is likely not what you wanted. -- Romain Francoise https://people.debian.org/~rfrancoise/

Bug#1064363: Keep tmux 3.4 out of testing for now

Package: tmux Version: 3.4-1 Severity: serious tmux 3.4 has a few regressions that I would like to have fixed before the package is allowed to migrate to testing. -- Romain Francoise https://people.debian.org/~rfrancoise/

Bug#1064039: Unexpected string when using tmux with rxvt-unicode

tps://github.com/exg/rxvt-unicode/commit/417b540d6dba67d440e3617bc2cf6d7cea1ed968 I'll reassign this bug to rxvt-unicode. Thanks, -- Romain Francoise https://people.debian.org/~rfrancoise/

Bug#1063938: closed by Philip Chung (Re: Bug#1063938: tmux: Does not automatically set mode-keys to vi based on VISUAL or EDITOR environment)

bash -c tmux` or similar to force tmux to be launched from a shell, if that helps. -- Romain Francoise https://people.debian.org/~rfrancoise/

Bug#1063938: tmux: Does not automatically set mode-keys to vi based on VISUAL or EDITOR environment

; show -g mode-keys \; kill-server mode-keys emacs % export EDITOR=/usr/bin/vi % tmux -S /tmp/tmux-test -f /dev/null new -d \; show -g mode-keys \; kill-server mode-keys vi % -- Romain Francoise https://people.debian.org/~rfrancoise/

Bug#1063838: tmux: new upstream released: tmux 3.4

and has had Sixel enabled for a few months already. Thanks, -- Romain Francoise https://people.debian.org/~rfrancoise/

Bug#1063237: tmux: crash when pasting into dead pane

Fix merged upstream: https://github.com/tmux/tmux/commit/4bdb855020d266ea0a480a53e13c806fcaad9b45 And tmux 3.4 is also out, so it'll be part of that upload. Thanks, -- Romain Francoise https://people.debian.org/~rfrancoise/

Bug#1063237: tmux: crash when pasting into dead pane

u for reporting this issue. The fix is straightforward enough and I've submitted here: https://github.com/tmux/tmux/pull/3830 -- Romain Francoise https://people.debian.org/~rfrancoise/

Bug#1055257: tcpdump fails to change ownership of savefile if built with libcap-ng

p-ng? (For the record, the patch referenced above was introduced in 2019, it's not recent.) -- Romain Francoise https://people.debian.org/~rfrancoise/

Bug#1048011: rcs: Fails to build source after successful build

those changes but not all, and I don't think this is worth spending a lot of time on. It's been like this for many years and nobody ever cared. -- Romain Francoise https://people.debian.org/~rfrancoise/

Bug#1043196: tmux: Manpages are broken because of unnecessary utf8 characters

Hi, This doesn't seem to be specific to tmux and I don't want to carry a patch for ever escaping the hyphens. I'll just merge this report with the original one in groff-base for now. Thanks, -- Romain Francoise https://people.debian.org/~rfrancoise/

Bug#1035842: Namespaces: Operation not permitted. Fails to setgroups due to EPERM

On Wed, May 10, 2023 at 7:12 AM Tj wrote: > When working with user namespaces tcpdump fails. Upstream has several > open issues and at least one pull request for this since 2019. > > https://github.com/the-tcpdump-group/tcpdump/pull/812 Thank you. Yes, this patch seems sensible, I'll pick it up.

Bug#1041159: dh_installsystemd: doesn't handle units installed in /usr/lib/systemd (vs. /lib/systemd)

As per discussion with Niels, reopening to keep as a beacon to guide others to the links above.

Bug#1041159: dh_installsystemd: doesn't handle units installed in /usr/lib/systemd (vs. /lib/systemd)

ge this bug with the original one. Cheers, -- Romain Francoise https://people.debian.org/~rfrancoise/

Bug#1041159: dh_installsystemd: doesn't handle units installed in /usr/lib/systemd (vs. /lib/systemd)

Package: debhelper Version: 13.11.4 Severity: normal I'm working on packaging a new upstream project which installs a number of systemd units directly to /usr/lib/systemd/system and I noticed that dh_installsystemd doesn't add the required maintscript stanzas to enable these units. If I patch the

Bug#1038269: tmux: server exits unexpectedly with libtinfo6 from experimental

ownstream packages :-) As insurance against any backporting side effects, I'm uploading a Git snapshot to experimental as well. -- Romain Francoise https://people.debian.org/~rfrancoise/

Bug#1038269: tmux: server exits unexpectedly with libtinfo6 from experimental

ill take care of doing the backports later today and compare my work with the Arch Linux package. -- Romain Francoise https://people.debian.org/~rfrancoise/

Bug#1035661: libpcap0.8: Manpages pcap-tstamp(7) and pcap-savefile(5) not installed

d. Thanks for the suggestion. -- Romain Francoise https://people.debian.org/~rfrancoise/

Bug#1035663: ITP: foomuuri -- multizone bidirectional nftables firewall

Package: wnpp Severity: wishlist Owner: Romain Francoise X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: foomuuri Version : 0.18 Upstream Contact: "Kim B. Heino" * URL : https://github.com/FoobarOy/foomuuri * License : GPL-2.0 Progra

Bug#1032298: tcpdump: apparmor blocks writing to stdout/stderr in lxd container [PATCH]

/dev/pts/* it is a high price to pay in terms of weakening the sandbox for an uncommon use case. With access to /dev/pts, an attacker can access SSH sessions and other terminals. Is there any way this could be fixed on the LXD side, or made more restrictive? Regards, -- Romain Francoi

Bug#1034086: tcpdump: CVE-2023-1801

Consequently I'm going to mark this bug as fixed in 4.9.3-1, which was the first version to disable the SMB code in Debian (in 2019). -- Romain Francoise https://people.debian.org/~rfrancoise/

Bug#1034086: tcpdump: CVE-2023-1801

packet. Thanks. Just in case, I will mention that the SMB printer code is *not* enabled in Debian anymore. None of the supported distributions (oldstable, stable, testing/sid) are affected. -- Romain Francoise https://people.debian.org/~rfrancoise/

Bug#962695: iftop resolves all IPv6 addresse to the same hostname

On Fri, Feb 24, 2023 at 10:18 PM Markus Koschany wrote: > Sure, if it helps. Thank you.

Bug#962695: iftop resolves all IPv6 addresse to the same hostname

ng looks > correct. Yes, this is very annoying. It looks like this might have been fixed by this upstream commit: https://code.blinkace.com/pdw/iftop/-/commit/35af3cf65f17961d173b31fd3b00166ec095c226 If so, can we have it in a new upload targeted at bookworm? Thanks, -- Romain Francoise htt

Bug#1030733: shorewall: "shorewall6 start" gives bash error message: "[: 64: unexpected operator" if "ip addr show" has "metric" information

`ip' output is fraught with danger, ideally Shorewall would use the JSON version (but that requires a dependency on `jq' or similar)... -- Romain Francoise https://people.debian.org/~rfrancoise/

Bug#1030898: please enable rdma support

Thanks for the suggestion. So far I've resisted adding extra binary dependencies to libpcap and this seems like a very specialized use case.

Bug#1029403: shorewall: fails to start with "Couldn't load match `iface':No such file or directory"

On Thu, Jan 26, 2023 at 09:47:07PM +0200, Vincas Dargis wrote: > Wait a minute, why there's two bug reports? Yes, I believe the core > issue should be in xtables. Do you mind if I merge them? -- Romain Francoise https://people.debian.org/~rfrancoise/

Bug#986152: Offer of help

Now finally uploaded! (And it didn't go through NEW.) -- Romain Francoise https://people.debian.org/~rfrancoise/

Bug#1029403: shorewall: fails to start with "Couldn't load match `iface':No such file or directory"

Hi, Isn't this already tracked as #973990? There is something specific to your setup because I can assure you that Shorewall generally works in sid. Please provide more information. Thanks, -- Romain Francoise https://people.debian.org/~rfrancoise/

Bug#986152: Offer of help

next few days. Thanks, -- Romain Francoise https://people.debian.org/~rfrancoise/

Bug#986152: Offer of help

On Sat, Jan 21, 2023 at 10:47:12AM -0500, Roberto C. Sánchez wrote: > Whenever a source package produces a new binary package, whether that > package exists in the archive already or not, it will land in NEW. Ah, makes sense. Thanks. Experimental it is, then. :-)

Bug#986152: Offer of help

I noticed while testing that you removed the '--no-start' argument to dh_installinit calls in the unified package, and that's not right, as README.Debian documents. The situation is even a bit more complex: * shorewall.postinst and shorewall6.postinst source the config file in /etc/default an

Bug#986152: Offer of help

On Fri, Jan 20, 2023 at 05:18:19PM -0500, Roberto C. Sánchez wrote: > I think that the bug is actually assigned to the shorewall-doc binary > package, not the shorewall-doc source package. Assuming that the > shorewall source package will start to emit a shorewall-doc binary > package, I think that

Bug#986152: Offer of help

On Fri, Jan 20, 2023 at 11:59:44AM +, Jeremy Sowden wrote: > The Developer's Reference, § 5.6.1, expresses the preference that when > new binary packages are added to a source package, it should be > uploaded to experimental, so I've updated the version and distribution > in the change-log entr

Bug#986152: Offer of help

Hi Jeremy, On Thu, Jan 19, 2023 at 7:01 PM Jeremy Sowden wrote: > I've pushed all the work to my repo on Salsa: > > https://salsa.debian.org/azazel/shorewall > > Do you want to review it before I push to the shorewall-team repo? It all looks pretty good to me! In fact, it's a radical improveme

Bug#986152: Offer of help

Hi, Replying to the latest messages in the thread in one go... On Sun, Jan 08, 2023 at 02:35:17PM +, Jeremy Sowden wrote: > I've created a Shorewall team on tracker.d.o and added you both to it. Thanks! On Mon, Jan 09, 2023 at 08:51:54AM -0500, Roberto C. Sánchez wrote: > For a bit of histo

Bug#986152: Offer of help

On Tue, Jan 3, 2023 at 11:54 PM Jeremy Sowden wrote: > I've imported my fork of Roberto's SF repo to Salsa: > > https://salsa.debian.org/azazel/shorewall > > I haven't touched it in 18 months, so I'll give it a polish when I have > some time, and perhaps we can use it as a starting point. Thank

Bug#986152: Offer of help

Hi, [Cc'ing Roberto directly to make sure he's aware of this discussion.] I'm also a Shorewall[6] user and while the state of the package isn't really alarming right now, I need it to be properly maintained going forward. We could set up a pkg-shorewall team on Salsa and co-maintain the packages

Bug#964985: libpcap0.8: build with rpcap support (--enable-remote)

Hi, On Thu, Dec 29, 2022 at 11:42 AM Peter Vanpoucke wrote: > Could this get picked up? I've used a port for Linux separately before, > but that one will no longer be maintained: > . I will look into it. Thanks.

Bug#1023315: tmux: manage /etc/shells using dpkg triggers

Hi, On Wed, Nov 2, 2022 at 10:51 AM Helmut Grohne wrote: > tmux manages its entry in /etc/shells using add-shell/remove-shell. > Consider managing this entry declaratively instead. Since version 5.3-1, > debianutils recognizes /usr/share/debianutils/shells.d/tmux and will add > those shells to /e

Bug#1016475: tmux sessions do not persist through logout

Hi, There’s nothing tmux can do right now about systemd killing user sessions without lingering enabled; just run `sudo loginctl enable-linger $USER`. Thanks.

Bug#1011426: bullseye-pu: package tcpdump/4.99.0-2+deb11u1

Hi Adam, On Sat, May 28, 2022 at 8:51 PM Adam D. Barratt wrote: > Please go ahead, thanks. Uploaded. Thanks!

Bug#1011426: bullseye-pu: package tcpdump/4.99.0-2+deb11u1

* Minor AppArmor profile updates (debian/usr.bin.tcpdump): ++ Grant access to *.cap (closes: #989433). ++ Account for numerical suffix in filenames added by -W (closes: #1010688). + + -- Romain Francoise Sun, 22 May 2022 18:22:50 +0200 + tcpdump (4.99.0-2) unstable; urgency=medium

Bug#1010688: apparmor profile prevents -C -W

Duh, thanks for the report. Not sure how this was never found despite the profile being included since 2017 and Debian having AppArmor enabled by default since Debian 10 (for new installs). I'll fix this in unstable but it may not qualify for a stable upload. I'll ask.

Bug#996684: lintian: emits bogus embedded-library error for libtinfo6 package

On Sun, Oct 17, 2021 at 12:46:24PM +0200, Sven Joachim wrote: > I am getting the following error in libtinfo6 (as well as in libtinfo5 > and lib{32,64}tinfo6), which according to the FTP masters leads to > autorejection unless overridden: > > , > | $ lintian /var/cache/apt/archives/libtinfo6_6.

Bug#994112: bullseye-pu: package tmux/3.1c-1+deb11u1

#992202). - -- Romain Francoise Sat, 11 Sep 2021 23:24:41 +0200 + -- Romain Francoise Sat, 18 Sep 2021 15:02:56 +0200 tmux (3.1c-1) unstable; urgency=medium

Bug#992949: tmix FTCBFS: AC_RUN_IFELSE

Actually the simple fix in upstream commit b1a8c0fe02 fixes the cross-build since the package now builds successfully for arm64 on amd64 in the CI job autoconfigured by Salsa templates, so I'll go with that. Thanks.

Bug#994112: bullseye-pu: package tmux/3.1c-1+deb11u1

am to fix race condition +which results in the config not being loaded if several clients are +interacting with the server while it's initializing (upstream GitHub +issue #2438, closes: #992202). + + -- Romain Francoise Sat, 11 Sep 2021 23:24:41 +0200 + tmux (3.1c-1) unstabl

Bug#940562: Some context

The Debian package used to modify upstream's Makefiles to install rcsfreeze along with the rest of the RCS binaries. Sometime in 2012 I dropped this patch with the following commit message: * Stop shipping the rcsfreeze script as upstream doesn't support it. I don't remember if ttn (RCS upstrea

Bug#992949: tmix FTCBFS: AC_RUN_IFELSE

See also these PRs for previous attempts at fixing this: https://github.com/tmux/tmux/pull/2651 https://github.com/tmux/tmux/pull/2755 Removing the patch tag as I'm not going to apply this until it goes through upstream first.

Bug#797780: Still happening in current tmux?

Does this still happen with current versions of tmux? Thanks.

Bug#990554: tcpdump: leftover legacy configuration /etc/apparmor.d/local/usr.sbin.tcpdump

Hi intrigeri, Thanks for following up, appreciate your help. On Fri, Sep 3, 2021 at 10:12 AM intrigeri wrote: > Meanwhile, I'm afraid the only way to deal with such leftovers > is via maintainer scripts, taking care of not deleting contents > added by the user :/ Ok. Unfortunately the cat is so

Bug#992949: tmix FTCBFS: AC_RUN_IFELSE

Hi, Thanks for the report. Can you submit the patch upstream through the GitHub issue tracker? It'll be more efficient than having to push a patch on your behalf.

Bug#992234: uninstallable; incompatible with tmux 3.2

Package: tmuxinator Version: 2.0.2-1 Severity: serious tmux 3.2a is now in sid, which makes tmuxinator uninstallable because it is apparently incompatible and has the following Depends field: Depends: ruby | ruby-interpreter, ruby-erubis, ruby-thor, ruby-xdg, tmux (<< 3.2) Please update the pac

Bug#992202: tmux doesn't read tmux.conf upon login

Looks like this is upstream issue #2438: https://github.com/tmux/tmux/issues/2438 It was fixed on master in the 3.1b timeframe, but unfortunately the backport was missed and the fix is not included in 3.1c. I can probably get the fix included in a stable update. Alternatively, tmux 3.2a will be

Bug#992202: tmux doesn't read tmux.conf upon login

Hi, On Sun, Aug 15, 2021 at 7:54 PM Allan Wind wrote: > I just upgraded to bullseye and on subsequent login tmux doesn't > appear to read tmux.conf. This worked fine in buster. Can you check your display manager logs (or equivalent) for an error message that would indicate what's happening? >

Bug#990554: tcpdump: leftover legacy configuration /etc/apparmor.d/local/usr.sbin.tcpdump

user pkg-apparmor-t...@lists.alioth.debian.org usertags #990554 + help-needed thanks On Fri, Jul 2, 2021 at 1:57 AM Christoph Anton Mitterer wrote: > So is it tcpdump's responsibility to clean this up (manually) or should > debhelper > do it (somehow ^^) automatically, i.e. also migrate the e

Bug#990215: tmux: Missleading error message if socket path has wrong permissions

Hi, On Wed, Jun 23, 2021 at 8:57 AM Uwe Kleine-König wrote: > To improve this, the following patch helps: [...] Thanks for the bug report and the patch. Can you contribute this directly upstream? It's always a bit awkward for me to try and get someone else's patch merged...

Bug#989433: tcpdump: -Z doesn't seem to work properly

Right, this is indeed about apparmor. The apparmor profile for tcpdump grants rw access to *.pcap. You're using a capture file named "ax0.cap", which doesn't match. I couldn't reproduce because I was testing the same scenario with the correct extension. I guess the simple fix would be to also gran

Bug#989433: tcpdump: -Z doesn't seem to work properly

Hi, On Thu, Jun 3, 2021 at 7:30 PM Dennis Boone wrote: > The following session was executed as root: > > ozymandias 179 # tcpdump -r /tmp/ax0.cap -Z root > tcpdump: /tmp/ax0.cap: Permission denied > ozymandias 180 # tcpdump -r /tmp/ax0.cap -Z tcpdump > tcpdump: /tm

Bug#962921: Please fix spam for bullseye

Hi Tiago, apticron is scheduled for automatic removal on 04/12 and the fixed package will not migrate because you included an arch-all binary in your upload. Please upload a source-only version. Thanks.

Bug#651783: libpcap0.8: libpcap should be linked with libnl

Hi Steev, While the libnl landscape indeed seems to have simplified since the last time I took a look at it, I don't think we are in a good place right now. The last upload of libnl3 was in 2018. The packaging Git repository has disappeared. Upstream-wise, there's a 3.5.0 release on GitHub (picked

Bug#976094: buster-pu: package grub2/2.02+dfsg1-20+deb10u3

On Mon, Jan 11, 2021 at 03:57:10PM +0100, Cyril Brulebois wrote: > If I'm getting this right, the udeb part shouldn't be much of an issue, > but the change regarding the fresh install vs. grub-install /could/ have > side effects. As documented, the installer /should/ be doing the right > thing alre

Bug#979338: Upgrading severity

severity 979338 serious quit Upgrading severity as this is blocking migration of tcpdump 4.99 to testing.

Bug#979338: Acknowledgement (python3-scapy: hardcodes tcpdump location to /usr/sbin/tcpdump)

By the way, it looks like this will block migration of tcpdump 4.99.0 to testing and the freeze is coming up fast, let me know if I can help in any way.

Bug#979338: python3-scapy: hardcodes tcpdump location to /usr/sbin/tcpdump

Package: python3-scapy Version: 2.4.4-3 Severity: normal In tcpdump 4.99.0-1, the location of the tcpdump binary was changed from /usr/sbin/tcpdump to /usr/bin/tcpdump. This causes autopkgtest to fail for scapy, as the path is hardcoded to the old location via this patch: https://salsa.debian.o

Bug#979229: libpcap0.8-dev: missing dependency on libdbus-1-dev causes build failures

Hi Luca, On Mon, Jan 4, 2021 at 2:36 PM Luca Boccassi wrote: > libpcap0.8-dev sets "Libs.private: -ldbus-1" in its pkg-config file, > but it does not have a dependency on libdbus-1-dev, causing a build > failure in reverse dependencies that use pkg-config --static (or macro > variations thereof).

Bug#973917: buster-pu: package tcpdump/4.9.3-1~deb10u2

Hi Adam, On Thu, Nov 19, 2020 at 9:31 PM Adam D. Barratt wrote: > Please go ahead. Thanks, uploaded.

Bug#973917: buster-pu: package tcpdump/4.9.3-1~deb10u2

fix +untrusted input issue in the PPP printer (CVE-2020-8037, closes: #973877). + + -- Romain Francoise Sat, 07 Nov 2020 13:36:24 +0100 + tcpdump (4.9.3-1~deb10u1) buster-security; urgency=high * New upstream release, with fixes for 24 different CVEs (closes: #941698). diff -Nru tcpdump

Bug#973877: tcpdump: CVE-2020-8037

Hi, On Fri, Nov 6, 2020 at 1:48 PM Salvatore Bonaccorso wrote: > The following vulnerability was published for tcpdump. > > CVE-2020-8037[0]: > | The ppp decapsulator in tcpdump 4.9.3 can be convinced to allocate a > | large amount of memory. Thanks for the bug report. I am aware of this CVE and

Bug#970437: libpcap0.8: typo in manpage of pcap-filter

tags 970437 upstream fixed-upstream thanks Hi, On Wed, Sep 16, 2020 at 1:33 PM Sven Dreyer wrote: > the manpage of pcap-filter contains a typo: > > > mpls [label_num] >True if the packet is an MPLS packet. If [label_num] is > specified, only true is the packet has the specified l

Bug#964985: libpcap0.8: build with rpcap support (--enable-remote)

Hi, On Mon, Jul 13, 2020 at 11:03 PM Lukas Tribus wrote: > since libpcap 1.9, rpcap (remote-pcap) is supported [1] and can > be enabled at build by specifying --enable-remote or in cmake > -DENABLE_REMOTE=YES [2]. > > Please consider enabling this for libpcap 1.9. Thank you for the suggestion. H

Bug#959698: tmux: "incompatible server protocol change" does not seem acceptable

Hi, On Mon, May 4, 2020 at 10:15 AM Julien Cristau wrote: > I don't think that's acceptable. Running upgrades inside screen or > tmux is a best practice, so IMO it needs to work, and people need to be > able to re-attach to existing sessions across the upgrade. The tmux authors make no promise

Bug#958639: libpcap0.8: libpcap should be linked with libdbus

Hi, On Thu, Apr 23, 2020 at 11:00 PM Francois-Xavier Le Bail wrote: > It will permit to add some interfaces to capture on, like: > > - dbus-system (D-Bus system bus) > - dbus-session (D-Bus session bus) Ok. dbus is now priority standard (and has apparently been since 2015 because of libpam-syste

Bug#954378: tcpdump: Support pcapng captures wiht snaplen 524288

I just uploaded the backport, it may take a few days before it appears in the archive.

Bug#954378: tcpdump: Support pcapng captures wiht snaplen 524288

Hi, Thanks for the report. Wireshark has its own implementation of the PcapNg format, so it's not unexpected that it behaves differently than tcpdump. The fix is a bit too intrusive for a stable update, especially for a minor bug like this. I will simply do a buster backport of libpcap 1.9.1-2 fr

Bug#954181: Please stop disabling Bluetooth monitor support in libpcap

Hi Guy, On Tue, Mar 17, 2020 at 10:15 PM Guy Harris wrote: > Please remove this, so that people can use the bluetooth-monitor device on > Debian - and on its derivatives, once it trickles down to all the > derivatives. I built the current master-branch versions of libpcap and > tcpdump on Ubu

Bug#953141: tmux: Please add Suggests: ncurses-term to allow us using TERM=tmux or tmux-256color

Hi, On Thu, Mar 5, 2020 at 7:45 AM Ryo IGARASHI wrote: > ncurses-term package contains termcap entry of tmux and tmux-256color. > Using these entry, I can use e.g. italic which is not available using > TERM=screen. > However, this fact is not indicated anywhere on tmux package > description. It w

Bug#943648: tmux: FTBFS twice in a row: deletes cmd-parse.c which cannot be regenerated due to lack of yacc

Hi, On Sun, Oct 27, 2019 at 3:21 PM Andreas Beckmann wrote: > The first build succeeds, but the subsequent distclean removes > cmd-parse.c which cannot be regenerated due to yacc (bison) not being > available. Thanks for the report. Indeed this file is now generated and shipped in the upstream t

  1   2   3   4   5   6   7   8   9   >