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

e 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/

at 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'

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

ub.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)

-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

xel 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

(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

of 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)

is 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

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

ll 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

> 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 https://peopl

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

ut 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

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

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

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

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

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

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.

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

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

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

pArmor 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 * Ad

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

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

202). - -- 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

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) unstable; urgency

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

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

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

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

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

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

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:

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

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

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:

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

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

to 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

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

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.

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

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

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

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

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

Bug#942315: tcpdump: Version in oldoldstable is higher than oldstable and stable

On Thu, Oct 17, 2019 at 10:02 AM Moritz Muehlenhoff wrote: > IMHO for stretch-security/buster-security we should rather rebase the old > 4.9.2ish packages to 4.9.3, given that it creates new system users etc. > it seems not really suitable for a security update. Ok, that is what I did. Review

Bug#942315: tcpdump: Version in oldoldstable is higher than oldstable and stable

On Wed, Oct 16, 2019 at 9:48 PM Salvatore Bonaccorso wrote: > Ideally given the issues are denial of service issues, this would have > been okay via a point release. But we discussed this coincidentally in > the team concluding we could as well release it via security. But we > were thinking of

Bug#942315: tcpdump: Version in oldoldstable is higher than oldstable and stable

Hi Guillem, On Mon, Oct 14, 2019 at 3:45 PM Guillem Jover wrote: > With the latest upload to oldoldstable-security, the versions in > oldstable and stable are now lower. This means that upgrades will > not take effect for this package, which will be left built against > libraries and packaging

Bug#941698: Bug#942171: tcpdump: FTBFS on ppc64el for test ikev2pI2

On Fri, Oct 11, 2019 at 2:06 PM Thierry fa...@linux.ibm.com wrote: > This is similar to bug #873377 which was supposed to be fixed in V 4.9.1-2 - > logs show that for v4.9.1-2 and -3 test was not run - then it was failing but > not reported as an error for the global count of success ! Sigh. I

Bug#940309: tmux: Random segfaults

Hi, On Sun, Sep 15, 2019 at 2:12 PM Kamil Jonca wrote: > At random moments tmux segfaults, destroying all sessions. > in dmesg we have: [...] Thanks for the report. Can you try with 3.0-rc4 from experimental?

Bug#939889: tmux: removal followed by reinstallation uses /etc/shells entry

On Fri, Sep 13, 2019 at 8:07 PM Sven Joachim wrote: > I think that would be correct. When filing the bug, I was worried that > leaving the entry in /etc/shells might fool an unsuspecting user to > chsh(1) to a non-existent program, but chsh does not actually let you do > this (unless you are

Bug#939889: tmux: removal followed by reinstallation uses /etc/shells entry

Hi Sven, On Mon, Sep 9, 2019 at 9:27 PM Sven Joachim wrote: > I guess the purpose is to preserve local configuration and give the > local admin to the ability to remove the /usr/bin/tmux entry from > /etc/shells. Yes, I don't remember the details but that is apparently the intent and it's

Bug#938962: user-mode-linux needs update for new linux

Hi, On Tue, Sep 3, 2019 at 3:21 PM Ritesh Raj Sarraf wrote: [...] > In file included from /usr/include/pcap.h:43, > from arch/um/drivers/pcap_user.c:7: > /usr/include/pcap/pcap.h:835:18: note: previous declaration of ‘pcap_open’ > was here > PCAP_API pcap_t *pcap_open(const

Bug#935112: Drop root privileges

Hi, On Mon, Aug 19, 2019 at 4:57 PM Laurent Bigonville wrote: > tcpdump is apparently able to drop its root privileges to run as an > unprivileged user. Yes, with the -Z option (e.g. `tcpdump -Z nobody'). > In RHEL they are passing "--with-user=tcpdump" to the configure. What this does is

Bug#933514: tmux: Screen garbling in ncurses apps

On Wed, Jul 31, 2019 at 8:17 PM Sven Joachim wrote: > Maybe the problems with screen updates have been triggered by > ncurses-base 6.1+20190713-1, see #933572? I could reproduce that one > with tmux 2.8-3, 2.9a-2 and 3.0~rc3-1. Do you mind if I merge this bug with #933572? Thanks.

Bug#933572: ncurses-base: Screen corruptions seen when running mutt in a tmux

Hi Sven, On Wed, Aug 7, 2019 at 6:26 PM Sven Joachim wrote: > So now all of this has happened in the meantime, and ncurses > 6.1+20190803-1 should be ready for upload. The problematic "rin" > feature has been removed from tmux* and from screen, but not from other > screen-derived terminfo

Bug#933514: tmux: Screen garbling in ncurses apps

This bug will be fixed by a future update to ncurses, which I assume is waiting for the current version to migrate to testing. Thanks.

Bug#933572: ncurses-base: Screen corruptions seen when running mutt in a tmux

Hi Sven, On Wed, Jul 31, 2019 at 7:57 PM Sven Joachim wrote: > So rin=\E[%p1%dT has been added in sid, apparently because of the > following change in the 20190630 patchlevel: > > , > | + add a check in tic for paired indn/rin > ` Would it be possible to temporarily revert this

Bug#933514: tmux: Screen garbling in ncurses apps

A patch for this is now available in the upstream bug tracker (https://github.com/tmux/tmux/issues/1861) and I have tested it successfully using the Mutt recipe from #933572.

Bug#933572: ncurses-base: Screen corruptions seen when running mutt in a tmux

Hi Sven, On Wed, Jul 31, 2019 at 7:57 PM Sven Joachim wrote: > So rin=\E[%p1%dT has been added in sid, apparently because of the > following change in the 20190630 patchlevel: > > , > | + add a check in tic for paired indn/rin > ` > > It looks like tmux does not quite cope with

Bug#933514: tmux: Screen garbling in ncurses apps

On Wed, Jul 31, 2019 at 5:42 AM T. Joseph Carter wrote: > The latest version of tmux has issues with screen updates under GNOME > Terminal with ncurses apps. This causes eg weechat's scrollback (pgup, > pgdn) to not draw correctly, causes specific issues with aptitude as > well. Thanks for the

Bug#932282: libnet-pcap-perl: FTBFS: error: redefinition of ‘struct pcap_rmtauth’

Hi Niko, On Wed, Jul 17, 2019 at 12:51 PM Niko Tyni wrote: > This package fails to build from source on current sid/amd64. > > Presumably this regressed with libpcap 1.9.0-2 so copying > the maintainer in case it's an oversight. Thank you for the report! Fedora uses the following patch to fix

Bug#928648: Sessions do not survive X restart under some conditions

Hi, On Wed, May 8, 2019 at 11:09 AM chrysn wrote: > In 2.9a-1 and 2.8-3, the following procedure resulted in tmux sessions > not surviving an X restart (which is my primary use case for tmux): [...] It looks to me like something is killing the tmux server, and I'm not sure there's anything that

  1   2   3   4   5   6   7   8   9   >