Bug#1071505: Resolve kconfig@x32 build failure
Package: kconfig
Version: 5.115.0
In
https://buildd.debian.org/status/fetch.php?pkg=kconfig=x32=5.115.0-2=1714911041=0
we find:
15: * Start testing of KStandardShortcutWatcherTest *
15: Config: Using QtTest library 5.15.10, Qt 5.15.10
(x86_64-little_endian-ilp32 shared (dynamic) release build; by GCC 13.2.0),
debian unknown
15: PASS : KStandardShortcutWatcherTest::initTestCase()
15: QWARN : KStandardShortcutWatcherTest::testSignal()
QDBusMarshaller::appendVariantInternal: Found unknown D-BUS type ''
15: FAIL! : KStandardShortcutWatcherTest::testSignal() Compared values are not
the same
15:Actual (((signalSpy.count(: 0
15:Expected (1): 1
15:Loc: [/<>/autotests/kstandardshortcutwatchertest.cpp(52)]
I can reproduce this in a local unchrooted build I have just set up with
debotstrap. The testsuite problem goes away when I add en_US.UTF-8 to
/etc/locale.gen. Indeed, kconfig seems to hard-depend on the
availability of en_US.UTF-8:
autotests/kstandardshortcuttest.cpp:setenv("LC_ALL", "en_US.utf-8", 1);
autotests/kconfigtest.cpp:setenv("LC_ALL", "en_US.utf-8", 1);
(it might also be possible to replace that with C.UTF-8, haven't tried)
Bug#1071479: git package is uninstallable on x32
On Monday 2024-05-20 04:36, Jonathan Nieder wrote: >> root@f3:/tmp# apt-get install git >[...] >> git : Depends: git-man (< 1:2.42.0-.) but 1:2.43.0-1 is to be installed > >This means the latest version hasn't built on x32 in the last several >months. https://buildd.debian.org/status/package.php?p=git says the >build deps are not installable; do you know why? git build-depends on: - libsvn-perl:x32 libsvn-perl depends on missing: - perlapi-5.36.0:x32 subversion build-depends on: - libkf5wallet-dev:x32 libkf5wallet-dev depends on: - libkf5wallet5:x32 (= 5.101.0-1) libkf5wallet5 depends on missing: - libkf5wallet-data:x32 (= 5.101.0-1) [follow some more BD chains] https://buildd.debian.org/status/package.php?p=kconfig=sid#problem-6 $ make check ... E: Build killed with signal TERM after 150 minutes of inactivity Oh well. Guess I don't get git because of some far-away KDE problem.
Bug#1071479: git package is uninstallable on x32
Package: git Version: 1:2.42.0-1 On Debian/x32 of the day, it is impossible to install the git package: root@f3:/tmp# apt-get install git Reading package lists... Done Building dependency tree... Done Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: git : Depends: git-man (< 1:2.42.0-.) but 1:2.43.0-1 is to be installed Recommends: ssh-client E: Unable to correct problems, you have held broken packages. root@f3:/tmp# apt-mark showheld root@f3:/tmp# -- sources.list (1 entry) -- deb https://deb.debian.org/debian-ports sid main None of http://ftp.gwdg.de/pub/linux/debian/debian/pool/main/g/git/ http://ftp.de.debian.org/debian-ports/pool/main/g/git/ http://ftp.de.debian.org/debian-ports/pool-x32/main/g/git/ carry git-man-2.42 anymore. Since I really don't care about manual pages for chroots, can we perhaps drop the git -> git-man hard requirement?
Bug#907396: kopano-server: Tools all fail with: MAPI error 80040111 (MAPI_E_LOGON_FAILED)
On Saturday 2018-09-01 12:32, Carsten Schoenert wrote: >severity -1 serious >affects -1 icu > >Hello Teun, > >On Mon, Aug 27, 2018 at 04:42:31PM +0200, Teun Kloosterman wrote: >> Trying to get Kopano to run, but all tools fail with: >> root$ kopano-cli --create-store >> [error ] virtual HRESULT M4LMAPISession::OpenMsgStore(ULONG_PTR, ULONG, >> const ENTRYID*, LPCIID, ULONG, IMsgStore**): msp>Logon failed: logon failed >> (80040111)MAPI error 80040111 (MAPI_E_LOGON_FAILED) >> >> On the forum they state that: [SOLVED] in kopanocore-8.6.80.1420-1.x86_64 >> built from sources >> https://forum.kopano.io/topic/1522/solved-db-backend-kopano-cli-mapi-error-80040111-mapi_e_logon_failed/9 > >unfortunately I can confirm the behaviour you see. But what ARE you doing? The report is just way too fucking confusing, making jumps between LFS and then Fedora and then back... damn. >Understanding the link you providing correctly we would need libicu61 >which kopano needs to be linked against. Debian currently is only >providing version 60.2 in unstable and testing. I opened up a whishlist >bug for packaging a recent version into Debian [1]. >OTOH also the configure script in 8.6.5 and .7 isn't detecting this >requirement, this is an upstream issue which should be added to the >autotools setup for kopano-core. There is no requirement on a particular ICU version! It is even buildable with the very old ICU 4.2 from RHEL6.
Bug#849338: ITP: hxtools -- Collection of tools and scripts
On Sunday 2016-12-25 23:59, Guus Sliepen wrote: >> * tailhex(1) - hex dumper with tail-following support > >od -x | tail? Do we really need a tool for this? tail is not the same as tail -f, and /usr/bin/od (and /usr/bin/hexdump) end execution when they reach the end of a regular file, such that piping into tail (with or without -f) would be useless. >> * xcp(1) - proof-of-concept cp(1) with alternate copying mechanisms > >I'm quite sure cp from coreutils is using an optimal algorithm >it should be fixed there instead of having another tool that >does not implement everything cp does, and may not even be faster. Feel free to write the patch. There is a 12% time improvement to gain with splice(2), at least there is here when testing on a 2GB file.
Bug#830575: nspawn lacks a dependency on dbus
On Monday 2016-07-11 14:18, Michael Biebl wrote: >Am 09.07.2016 um 18:33 schrieb Jan Engelhardt: >> Package: systemd-container >> Version: 230-5 >> >> nspawn fails to start the selected program. It appears to need dbus, and >> Debian >> is missing a Requires:. System has version "stretch main" listed in apt >> sources.list. > >systemd has a Recommends: dbus, so I assume you have >Recommends-installed-by-default disabled? I have whatever default Debian gave me, and I would not be surprised if that was indeed disabled - it has been disabled in the distribution for as long as I can remember. And I am not even contesting that default. As for the systemd package, it would therefore appear that the Recommends should be turned into Requires.
Bug#830575: nspawn lacks a dependency on dbus
Package: systemd-container Version: 230-5 nspawn fails to start the selected program. It appears to need dbus, and Debian is missing a Requires:. System has version "stretch main" listed in apt sources.list. root@zfrei97:/var/lib/docker/btrfs/subvolumes# btrfs sub snap 1e7fd030e8111cb3d82d0fbc36b0c1ec28cb9ff036b506dc4958884e1b6b1599 /t Create a snapshot of '1e7fd030e8111cb3d82d0fbc36b0c1ec28cb9ff036b506dc4958884e1b6b1599' in '//t' root@zfrei97:/var/lib/docker/btrfs/subvolumes# cd /t root@zfrei97:/t# touch it root@zfrei97:/t# systemd-nspawn -D /t -M t /bin/bash Spawning container t on /t. Press ^] three times within 1s to kill container. Failed to open system bus: No such file or directory Failed to create directory /t/sys/fs/selinux: Read-only file system Failed to create directory /t/sys/fs/selinux: Read-only file system root@zfrei97:/t# echo $? 1 root@zfrei97:/t# machinectl Failed to create bus connection: No such file or directory root@zfrei97:/t# systemctl start systemd-machined Failed to start systemd-machined.service: Unit dbus.socket not found. root@zfrei97:/etc# apt-get install dbus Reading package lists... Done Building dependency tree Reading state information... Done The following additional packages will be installed: libcap-ng0 libdbus-1-3 Suggested packages: dbus-user-session | dbus-x11 The following NEW packages will be installed: dbus libcap-ng0 libdbus-1-3 0 upgraded, 3 newly installed, 0 to remove and 0 not upgraded. Need to get 406 kB of archives. After this operation, 1,030 kB of additional disk space will be used. Do you want to continue? [Y/n] Get:1 http://ftp.de.debian.org/debian stretch/main amd64 libcap-ng0 amd64 0.7.7-3 [13.6 kB] Get:2 http://ftp.de.debian.org/debian stretch/main amd64 libdbus-1-3 amd64 1.10.8-1 [188 kB] Get:3 http://ftp.de.debian.org/debian stretch/main amd64 dbus amd64 1.10.8-1 [204 kB] Fetched 406 kB in 0s (2,377 kB/s) Selecting previously unselected package libcap-ng0:amd64. (Reading database ... 23795 files and directories currently installed.) Preparing to unpack .../libcap-ng0_0.7.7-3_amd64.deb ... Unpacking libcap-ng0:amd64 (0.7.7-3) ... Selecting previously unselected package libdbus-1-3:amd64. Preparing to unpack .../libdbus-1-3_1.10.8-1_amd64.deb ... Unpacking libdbus-1-3:amd64 (1.10.8-1) ... Selecting previously unselected package dbus. Preparing to unpack .../dbus_1.10.8-1_amd64.deb ... Unpacking dbus (1.10.8-1) ... Processing triggers for libc-bin (2.22-13) ... Processing triggers for man-db (2.7.5-1) ... Processing triggers for systemd (230-5) ... Setting up libcap-ng0:amd64 (0.7.7-3) ... Setting up libdbus-1-3:amd64 (1.10.8-1) ... Setting up dbus (1.10.8-1) ... Processing triggers for libc-bin (2.22-13) ... Processing triggers for systemd (230-5) ... root@zfrei97:/etc# machinectl MACHINE CLASS SERVICE 0 machines listed. root@zfrei97:/etc# cd root@zfrei97:~# systemd-nspawn -D /t -M t /bin/bash Spawning container t on /t. Press ^] three times within 1s to kill container. Failed to create directory /t/sys/fs/selinux: Read-only file system Failed to create directory /t/sys/fs/selinux: Read-only file system root@t:/#
Bug#783178: gdlib-config --libs reports wrong library list
Package: libgd2-xpm-dev Version: 2.0.36~rc1~dfsg-6.1 Running `gdlib-config --libs` outputs: -lXpm -lX11 -ljpeg -lfontconfig -lfreetype -lpng12 -lz -lm On Debian, this list is lacking -lgd itself, which means third-party software that uses this command to link to GD fails to link. On openSUSE, their gd 2.0.36-rc1 package yields -lgd (and no -lXpm, -lX11, etc.). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#752993: automake: configure does not parse variables to make foo.Po files
On Sat, 28 Jun 2014 18:38:16 +1000, Craig Small wrote in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752993 : $ cat Makefile.am AUTOMAKE_OPTIONS = subdir-objects bin_PROGRAMS = foo foo_SOURCES = foo.c lib/bar.c lib/bar.h $(top_srcdir)/lib/nothere.c The way I interpret the automake manual is that $() in SOURCES is not supported, nor possible. Variables could be changed at make time (by passing arguments to make, for example), which provide an instance where an ambiguity arises, and automake wants to avoid that :-) Second, the value of top_srcdir cannot be known beforehand, because it is first set by configure. The sensible way is to statically resolve $(top_srcdir) with the real (relative) path of the source file, that is, foo_SOURCES = foo.c lib/bar.c lib/bar.h lib/nothere.c Depending on where your particular Makefile.am is located, it may even be ../lib/nothere.c or ../../lib/nothere.c, and so on. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#690548: iptables: invalid size 40 (kernel) != (user) 48 on yeelong because kernel is 64 bits, iptables 32 bits
On IRC I have heard that MIPS has multiple ABIs; as far as modern Linux is concerned, I think you may be running into: o32, n32, n64. Your kernel is probably n64 (and its compat companion is n32), but your iptables is o32. Can you check with the file(1) utility and/or readelf(1)? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#690548: iptables: invalid size 40 (kernel) != (user) 48 on yeelong because kernel is 64 bits, iptables 32 bits
[ 26.096000] x_tables: ip_tables: limit.0 match: invalid size 40 (kernel) != (user) 48 The problem seems to be that the linux kernel is 64 bits [...] Iptables as packaged is a 32 bits mipsel executable, and seems to have some data structures that include 32 bits pointers or something that don't work when shared with the 64 bit kernel. IIRC this also occured to the ARM guys. The kernel parts support zero or one compat format, and one native format, which depends on the compiler options used. i386 kernel: native=i386 compat=NONE amd64 kernel: native=amd64 compat=i386 sparc64 kernel: native=sparc64 compat=sparcv9 armv7-eabi kernel: native=armv7-eabi compat=NONE (Turning off CONFIG_COMPAT in the kernel .config means compat is never included.) This meant that one cannot use a ARM OABI iptables binary. [And there was no reason to continue using OABI anyway, so that was simple.] It will also mean that you will not be able to use a x32-type iptables binary on amd64. (Hint, hint, ljlane) I suppose you may have a similar case with your mips environment that you have a non-standard userspace. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#691306: Bug #691306: iptables add 4 rules instead just one in kernel INPUT chain
On Thursday 2012-10-25 17:20, Laurence J. Lane wrote: I'm uncertain of the issue with duplicate addresses for localhost. I'll ask upstream if iptables should filter out duplicates. dunno. I have no preference in this regard. `wget` would also seem to simply iterate over all entries. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#641517: iptables: ip6tables don't work
On Wednesday 2012-10-17 14:40, Filip Valder wrote: Hi. Sorry for my misknowledge but I think that it could be an implicit rule. Why should a user care of this IPv6 ARP? On the other side there are surely thousands reasons for NOT doing it... IPv6 Neighbor Discovery is used to ask the local Ethernet segment for the hardware address belonging to a certain IPv6 address, because without said HW addr (a.k.a. MAC address), packets cannot be unicasted to the desired destination. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#641517: iptables: ip6tables don't work
On Wednesday 2012-10-17 14:51, Filip Valder wrote: I do understand and that's what I mean. It's necessary for the basic functionality so why should it be explicitly set by a user? Users have different requirements. Not all possible IPv6 scenarios use NDISC. The kernel gives you tools, how you use them is your choice. (If you do not like the raw way of the kernel, there are plenty of frontends to pick from.) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#641517: iptables: ip6tables don't work
On Wednesday 2012-10-10 08:21, Filip Valder wrote: Hi. The 2 lines above the line you mention preserve SYN/SYN-ACK + ESTABLISHED states for tcp/22 connection. First matching rule wins, so where is the problem? As I said, you need ICMPv6. Without it, you won't even get SSH packets. Basic networking. Like ARP in IPv4. (tcpdump ssh v-foo) 10:47:33.268038 Out 8a:0c:9c:aa:b9:7f ethertype IPv6 (0x86dd), length 88: 2001:db8:151:ffa::1 ff02::1:ff00:80: ICMP6, neighbor solicitation, who has 2001:db8:151:ffa::80, length 32 10:47:33.268410 In 08:00:27:0e:c4:07 ethertype IPv6 (0x86dd), length 88: 2001:db8:151:ffa::80 2001:db8:151:ffa::1: ICMP6, neighbor advertisement, tgt is 2001:db8:151:ffa::80, length 32 10:47:33.268433 Out 8a:0c:9c:aa:b9:7f ethertype IPv6 (0x86dd), length 96: 2001:db8:151:ffa::1.55849 2001:db8:151:ffa::80.22: Flags [S], seq 2298159748, win 14400, options [mss 1440,sackOK,TS val 359464204 ecr 0,nop,wscale 7], length 0 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#641517: iptables: ip6tables don't work
The SSH traffic (as an example) is dropped, no other rules (snipped) match even if they shall match. *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] -A INPUT -i lo -j ACCEPT -A INPUT -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -i eth0 -p tcp -m tcp --dport 22 -j ACCEPT # The following line drops everything, after disabling -A INPUT -i eth0 -j DROP COMMIT Precisely, you are dropping everything else, including vital ICMPv6. This is not a bug. Your ruleset is too restrictive. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#653022: [Bug 653022] the bug's still here
I believe the bug is still here: # iptables -m ACCOUNT -h iptables v1.4.12.2: Couldn't load match `ACCOUNT':No such file or directory iptaccount only provides a target, not a match. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#653206: libpam-mount: login not possible with version 2.13.1 - ends in segfault
On Sunday 2012-02-19 10:48, Michael Domann wrote: volume user=mdomann fstype=crypto_LUKS path=/dev/sdb2 mountpoint=/home/mdomann/media fskeypath=/home/mdomann/.gnupg/media fskeyhash=none fskeycipher=none options=fsck,nodev,nosuid / Now fixed in commits fa2422d pam_mount: understand crypt_LUKS and crypto_LUKS in xml file 73b6833 pam_mount: fix crash when an unknown digest/cipher was specified -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#641353: Bug #641353: libpam-mount: sudo increases root login count, but decreases user login count
The reason seems to be, that sudo causes /var/run/pam_mount/root to be increased by one, but afterwards, decreases /var/run/pam_mount/$USER by one. Which in turn, when reached zero, causes the volumes to be unmounted. Does it also happen with su(8)? If not, then consider this a sudo bug; potential duplicate of #645480. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#653206: libpam-mount: login not possible with version 2.13.1 - ends in segfault
On Wednesday 2012-02-15 19:12, Michael Domann wrote: Dec 25 08:09:54 sysiphus login[3411]: (mount.c:267): Mount info: globalconf, user=mdomannvolume fstype=crypto_LUKS server=(null) path=/dev/sda3 mountpoint=/home cipher=(null) fskeypath=(null) fskeycipher=(null) fskeyhash=(null) options=fsck / fstab=0 ssh=0 Dec 25 08:09:56 sysiphus login[3411]: (mount.c:586): ehd_keydec_run: Unknown digest What were the luksFormat commands/parameters you used to create this volume? If you do not remember, using luksDump can provide an approximation. root@sysiphus:/home/mdomann# cryptsetup luksDump /dev/sdb2 LUKS header information for /dev/sdb2 Version: 1 Payload offset: 2056 Key Slot 0: ENABLED Key Slot 1: ENABLED Key Slot 2: ENABLED Key Slot 3: ENABLED Dec 25 08:09:56 sysiphus login[3411]: (pam_mount.c:602): going to readconfig /home/mdomann/.pam_mount.conf.xml Dec 25 08:09:56 sysiphus login[3411]: (mount.c:586): ehd_keydec_run: Unknown digest Dec 25 08:10:00 sysiphus login[3411]: (mount.c:695): error sending password to mount Dec 25 08:10:00 sysiphus kernel: login[3411]: segfault at 0 ip 7fc0cdd7c359 sp 7fff13cfb3b0 error 4 in libc-2.13.so[7fc0cdd05000+17a000] The sda3 volume seems ok. What is in /home/mdomann/.pam_mount.conf.xml? The error happens after that is being parsed. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#653206: libpam-mount: login not possible with version 2.13.1 - ends in segfault
Dec 25 08:09:54 sysiphus login[3411]: (mount.c:267): Mount info: globalconf, user=mdomann volume fstype=crypto_LUKS server=(null) path=/dev/sda3 mountpoint=/home cipher=(null) fskeypath=(null) fskeycipher=(null) fskeyhash=(null) options=fsck / fstab=0 ssh=0 Dec 25 08:09:56 sysiphus login[3411]: (mount.c:586): ehd_keydec_run: Unknown digest What were the luksFormat commands/parameters you used to create this volume? If you do not remember, using luksDump can provide an approximation. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#579021: gdb fails with Cannot find new threads: generic error when linking with libdbi
Package: gdb Version: 7.3-1+b1 Followup-For: Bug #579021 -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.1.0-1-amd64 (SMP w/3 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gdb depends on: ii gdbserver 7.3-1+b1 ii libc6 2.13-21 ii libexpat1 2.0.1-7.2 ii libncurses5 5.9-4 ii libpython2.7 2.7.2-5 ii libreadline6 6.2-7 ii zlib1g1:1.2.3.4.dfsg-3 gdb recommends no packages. Versions of packages gdb suggests: pn gdb-doc none -- no debconf information Trying to run gdb on the sudo sources also yields this error. root@vjng-debian:/home/jengelh/sudo-1.8.3p1/src# gdb sudo GNU gdb (GDB) 7.3-debian Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /home/jengelh/sudo-1.8.3p1/src/sudo...done. (gdb) b policy_check Breakpoint 1 at 0x40b0c4: file ./sudo.c, line 1123. (gdb) r -Hu jengelh id Starting program: /home/jengelh/sudo-1.8.3p1/src/sudo -Hu jengelh id Breakpoint 1, policy_check (plugin=0x615e20, argc=1, argv=0x7fffe640, env_add=0x61b9a0, command_info=0x7fffe4e0, argv_out=0x7fffe4d8, user_env_out=0x7fffe4d0) at ./sudo.c:1123 1123return plugin-u.policy-check_policy(argc, argv, env_add, command_info, (gdb) s [Thread debugging using libthread_db enabled] Cannot find new threads: generic error sudo itself is not linked to libpthread, nor is any of its modules. The whole sudo thing does not even seem to make use of pthreads. Generic error messages should be killed; it should at least print what it searched for (even if it's a random number).. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#579021: gdb fails with Cannot find new threads: generic error when linking with libdbi
On Thursday 2011-11-24 02:46, Jan Engelhardt wrote: root@vjng-debian:/home/jengelh/sudo-1.8.3p1/src# gdb sudo GNU gdb (GDB) 7.3-debian Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /home/jengelh/sudo-1.8.3p1/src/sudo...done. (gdb) b policy_check Breakpoint 1 at 0x40b0c4: file ./sudo.c, line 1123. (gdb) r -Hu jengelh id Starting program: /home/jengelh/sudo-1.8.3p1/src/sudo -Hu jengelh id Breakpoint 1, policy_check (plugin=0x615e20, argc=1, argv=0x7fffe640, env_add=0x61b9a0, command_info=0x7fffe4e0, argv_out=0x7fffe4d8, user_env_out=0x7fffe4d0) at ./sudo.c:1123 1123return plugin-u.policy-check_policy(argc, argv, env_add, command_info, (gdb) s [Thread debugging using libthread_db enabled] Cannot find new threads: generic error sudo itself is not linked to libpthread, nor is any of its modules. The whole sudo thing does not even seem to make use of pthreads. And with LD_PRELOAD=/lib/x86_64-linux-gnu/libpthread.so.0 gdb sudo this suddenly starts to work. (Why is it that I only need this kludge on Debian? openSUSE also ships gdb 7.3) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#648066: pam_mount and sudo problem
On Tuesday 2011-11-22 10:42, Hanno Böck wrote: Hi, There seems to be a problem with pam_mound and latest sudo: https://bugs.gentoo.org/show_bug.cgi?id=390459 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=648698 Can you have a look? .oO( Why do I always have to investigate sudo bugs. ) root@vjng-debian:/home/jengelh# /usr/local/sudo-1.8.2/bin/sudo id [998] pam_mount: library loaded [dlopened] [998] sudo: calling pam_open_session [998] pam_mount: pam_sm_open_session uid=0(root) gid=0(root) groups=0(root) [997] sudo: calling pam_close_session root@vjng-debian:/home/jengelh# /usr/local/sudo-1.8.3/bin/sudo id [1000] pam_mount: library loaded [1001] sudo: calling pam_open_session [1001] pam_mount: pam_sm_open_session uid=0(root) gid=0(root) groups=0(root) [1000] sudo: calling pam_close_session [1000] pam_mount: pam_sm_close_session: opener pid was 0 [1000] pam_mount: library unloaded [dlclosed] One does not simply walk into Mordor^W^W^W distribute your PAM functions calls across different processes by the moon phase. Therefore, pam_mount has no state in one process, and it is only reasonable that pam_mount.so screams out loud about Config.user == NULL. And why in all world does sudo use fork(2) anyway? su(8) can completely do without such and so does not even run into the problem of asymmetric calling of the stack. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#622693: libpam-mount: This version of mount.crypt does not support mtab-less systems yet
On Tuesday 2011-11-01 00:50, Roger Leigh wrote: Just a heads up: util-linux 2.20.1 is the current stable release, and should make its way into Debian soon. I've packaged it here: http://people.debian.org/~rleigh/util-linux/ and the maintainer will hopefully upload it soon, Nothing happened. As I just installed a D7 for other pam_mount^W sudo bug hunting, I noticed 2.20 still isn't offered in testing. the basis. Once that's done, it should be possible to upload a libmount- using version of libpam-mount. Is this possible? I scrapped the last state of libmount code. It was just too ugly and did not look great. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638305: iptables: missing space char in the log
iptables -t mangle -A OUTPUT -s 192.168.0.0/16 -o pp+ -j LOG --log-prefix tabl=mangle --log-uid I get log records like this: Aug 18 14:44:27 NoX-gw kernel: [22682.960012] tabl=mangleIN= OUT=ppx_TTK SRC=192.168.66.1 DST=172.16.11.21 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=445 DPT=51949 WINDOW=5840 RES=0x00 ACK SYN URGP=0 UID=0 GID=0 where log-prefix value and next field is not delimited by space. This has always been like this, and is actually intended if you consider that people may want a space there (but, say, a colon). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#627085: libpam-mount: multiple logins of the same UID result in multiple mounts, not all mounts are cleanly umounted
http://bugs.debian.org/627085 This is a duplicate of bug #586009. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#634769: iptables: regression : state: option --state cannot be inverted.
Package: iptables Version: 1.4.11.1-3 Severity: important there is regression since 1.4.10-1 a command as : iptables -t filter -A OUTPUT -o $WAN_INTERFACE -s $WAN_IP -d $WAN_NETWORK -p all -m state ! --state INVALID -j ACCEPT Ideally, one just uses -m conntrack --ctstate which has rendered -m state obsolete. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#622693: libpam-mount: This version of mount.crypt does not support mtab-less systems yet
On Friday 2011-07-22 21:46, Roger Leigh wrote: Looking at the current git, I have a couple of questions: 1) Is libmount now required? It looks this way looking at the configure script. Yes. 2) If so, how about non-Linux platforms which don't support libmount? Because it's Linux-specific, it means it's not possible to build on kFreeBSD (where it did previously build OK). Should be easy to port. 3) Is [mount = 2.20] strictly required, or is 2.19 OK? Given that 2.19.1 is current, depending on an unreleased version makes it hard to test! If it's possible to use 2.19 safely, that would be great. A post-2.19 git snapshot is required, which is why there has been no pam_mount release tarball for libmount so far. The more I ponder about libmount integration however, I am not satisfied, as I most likely had to add more code than take away - did not check the stats, but it felt like so. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#622693: libpam-mount: This version of mount.crypt does not support mtab-less systems yet
On Sunday 2011-07-10 21:57, Roger Leigh wrote: On Fri, Apr 15, 2011 at 06:46:51PM +0200, Jan Engelhardt wrote: The error has been changed to a warning in 2c6e6148709fc3accc8c5b442ce021d45f6f3ac5 (-2.10). The underlying issue remains the same - calling umount won't call umount.crypt because there is no mention of crypt in /etc/mtab, so in other words, the crypto and loop devices remain active even after logout. To fully work with such mtab-less (or mtab=ro) systems, the new utab branch from git would be needed. Dear Jan, It's great to see that it's fixed in git. Is this code stable enough for use at this point? Are you planning making a new release in the near future? If I could get some people to toy around with it that would of course be preferable, because it is actually new code. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#632084: DNAT/REDIRECT generating wrong port number for ctorigdstport
Crosslinks: http://marc.info/?l=netfilter-develm=130999299016674w=2 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#615121: #615121: iptables --localtz option of -m time not working
I have marked this as +fixed-upstream, as the --localtz option has been officially deprecated for this very problem; preferably, everything is specified in UTC now. More documentation in iptables-1.4.11's manpage. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#623112: iptables: file in wrong place
Collected this into my patch queue. Should be in upstream soon enough. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#610232: libpam-mount: umount.crypt doesn't umount, says is not mounted (according to cmtab)
This should be addressed now with 30e737615eec0a998936da55c1febd32f4fcfd3a, included in 2.10. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#622693: libpam-mount: This version of mount.crypt does not support mtab-less systems yet
The error has been changed to a warning in 2c6e6148709fc3accc8c5b442ce021d45f6f3ac5 (-2.10). The underlying issue remains the same - calling umount won't call umount.crypt because there is no mention of crypt in /etc/mtab, so in other words, the crypto and loop devices remain active even after logout. To fully work with such mtab-less (or mtab=ro) systems, the new utab branch from git would be needed. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#621033: Update description of package
Package: libhx-dev Version: 3.9.1-1 Originally sent to maintainer on: Mon, 17 Jan 2011 00:41:01. Status: Bounced. Resending to submit@BDO. I recently updated the project's description with the release of version 3.9 (except with the tarball which was generated somewhat earlier). Instead of the item list, it now sports two paragraphs that better fit in line with what most other packages have, and is a bit more futureproof (a feature list would have to be almost constantly updated). Please update the DEB package's description you are maintaining using the first two paragraphs of http://libhx.sf.net/, or if some policy dictates shorter descriptions, just the first paragraph (which incidentally hits the ceiling of 255 chars on SF :-). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#620818: mount.cifs appends trailing slash to share name in kernel
Package: cifs-utils Version: 4.9 Bug #586009 has essentially not been solved. Fixing mtab won't help when you run systems with /etc/mtab as a symlink to /proc/self/mounts. # strace -fe mount -s 65536 -v mount -t cifs //localhost/homes /mnt -o user=root [pid 2734] mount(//localhost/homes/, ., cifs, 0, ip=::1,unc=localhost\\homes,,ver=1,user=root,pass=abc) = 0 # tail -n1 /proc/self/mounts //localhost/homes/ /mnt cifs rw,relatime,unc=\\localhost\homes,username=root,uid=0,noforceuid,gid=0,noforcegid,addr=:::::::0001,posixpaths,serverino,acl,rsize=16384,wsize=57344,actimeo=1 0 0 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#620818: [Pkg-samba-maint] Bug#620818: mount.cifs appends trailing slash to share name in kernel
On Monday 2011-04-04 14:47, Luk Claes wrote: On 04/04/2011 01:55 PM, Jan Engelhardt wrote: Package: cifs-utils Version: 4.9 That's not a version in Debian, I guess you mean 2:4.9-1? Can you give the output from 'apt-cache policy cifs-utils' so we can confirm? I don't actually run Debian, though I monitor DBTS for bugs against upstream packages, such as pam_mount, that I maintain. I suspect that, since the bug is reproducible on openSUSE too, that it is a general issue. Appending new findings to the Debian issue stream seems like the best way to record the persistence of problems. Bug #586009 has essentially not been solved. Fixing mtab won't help when you run systems with /etc/mtab as a symlink to /proc/self/mounts. Any reason why you open a new bug in that case? DBTS tends to.. reject mail some time in the future after a bug has been closed. # strace -fe mount -s 65536 -v mount -t cifs //localhost/homes /mnt -o user=root [pid 2734] mount(//localhost/homes/, ., cifs, 0, ip=::1,unc=localhost\\homes,,ver=1,user=root,pass=abc) = 0 # tail -n1 /proc/self/mounts //localhost/homes/ /mnt cifs rw,relatime,unc=\\localhost\homes,username=root,uid=0,noforceuid,gid=0,noforcegid,addr=:::::::0001,posixpaths,serverino,acl,rsize=16384,wsize=57344,actimeo=1 0 0 This is an observation, though I don't see any mention of what problem it causes for you especially as you are being root when doing the mount. The problem occurs when one tries to compare whether something has been mounted already. In pam_mount.conf.xml, someone may specify //localhost/homes to be mounted. This then gets mounted on login, however, on second login, it may be erroneously tried to be mounted again, because //localhost/homes/ (procfs) != //localhost/homes (config). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#580882: 580882: mount.crypt: New option to show fsck output
Where does the motd or the message about new mails go to? Nowhere, since showing /etc/motd is exclusive to /bin/login. New mail statement is part of the shell, so will only be produced when you run an interactive on, on a tty. So not executed for xdm either. Well, it was a rhetorical question. I plan to decouple PAM from mounting anyway, so it would not be an issue anymore. So if you have a patch, I will merge it. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#615121: #615121: iptables --localtz option of -m time not working
On Thursday 2011-03-31 07:53, Damyan Ivanov wrote: Not sure if it matters, but the hardware clock is using UTC (i.e. /etc/default/rcS contains UTC=yes). When the xt_time kernel module is loaded, it prints the current timezone the kernel is operating with - and this is what xt_time will be using when doing localtz comparisons. Thanks for the reply. Indeed, there is this message in dmesg: xt_time: kernel timezone is - I too use UTC, but I don't get . /etc/sysconfig# head -n10 clock; hwclock; date; rmmod xt_time; modprobe xt_time; dmesg | tail -n1; ## Path:System/Environment/Clock ## Description: Information about your timezone and time ## Type:string(-u,--utc,--localtime) ## ServiceRestart: boot.clock ## Command: /sbin/refresh_initrd # # Set to -u if your system clock is set to UTC, and to --localtime # if your clock runs that way. # HWCLOCK=-u Thu Mar 31 12:16:01 2011 -0.767810 seconds Thu Mar 31 12:16:03 CEST 2011 [383639.470885] xt_time: kernel timezone is +0100 # cat /etc/SuSE-release openSUSE 11.4 (x86_64) I think there is no bug here currently - the Linux system was written such that each user could have his own TZ setting applied to shells, desktop, etc. (Which requires that the kernel always keeps an UTC clock somewhere.) On boot, once the kernel UTC clock has been initialized from the RTC + $(DST result of date command), the KTZ is independent, much like just another user's environment variable. I have set the hardware clock to use the local timezone and it changed to xt_time: kernel timezone is +0300 It seems to fix the problem, but I wonder what would happen at the next DST change. I guess it would require to shut down the firewall, The particular box I have shown output from still reads +0100 while 4 days ago, DST began and thus would have become +0200. Since the KTZ is set by distro scripts once at boot, one can't blame ntpd for not updating the KTZ. After all, ntpd only needs to concern itself with adjusting the UTC clock, since timezones is not a system property, but per-user. Given these findings, the localtz option is obviously heavily dependent on KTZ, and maybe should be ripped out of the xt_time module to avoid surprises. reload xt_time and restart the firewall so that it picks up the correct timezone (If the kernel changes its at all. I have never used UTC=no before). Still a suboptimal solution? Reloading xt_time won't change anything. Someone or something would need to set the KTZ, and once it does so, xt_time will pick it up automatically. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#615121: #615121: iptables --localtz option of -m time not working
Not sure if it matters, but the hardware clock is using UTC (i.e. /etc/default/rcS contains UTC=yes). When the xt_time kernel module is loaded, it prints the current timezone the kernel is operating with - and this is what xt_time will be using when doing localtz comparisons. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#614781: libpam-mount: could not chown ... : Operation not
Why is there no disk for '%(USER)-server'? Because the desktop environments usually do not show a disk icon for each and every mount, but only for mounts backed by a local hardware device. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#619581: Debian's screenrc screws up backscrolling
Package: screen Version: 4.0.3 To reproduce: 1. Start an xterm 2. Use some command to generate a few screenfuls of output (say, ls -l on some larger directory like /usr/lib) 3. Start screen (4. Execute uname -a, for example) 5. Execute some command that outputs 1-2 screenfuls 6. Hit Shift-PgUp, and observe that there is NO way with S-PgUp to get at the output previous to the currently visible lines. (In example: the uname output). Culprit is this line in /etc/screenrc: # The vt100 description does not mention dl. *sigh* termcapinfo vt100 dl=5\E[M Commenting it out fixes the problem. Which brings me to the point - why _was_ this added, anyway? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#611990: iptables segmentation faults on empty source address
tag 611990 +fixed-upstream thanks http://dev.medozas.de/gitweb.cgi?p=iptables;a=commitdiff;h=4b110b426df7bf486a3e7884c56ebb3487023601 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#429579: 429579: iptables -L trailing blanks enough to cause wrapping
On Saturday 2010-12-18 02:05, jidanni wrote: JE == Jan Engelhardt writes: $ iptables -L was wrapping on to extra blank lines on my extra wide screen JE Out of curiosity, how wide is your screen? 111 chars. OK, it's not wrapping anymore currently in 1.4.10-1. All there are are a few trailing blanks, as can be seen with iptables -L|sed 's/$/$/' I have sent in a patch now to correct this. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#610111: iptables-save dumps resolved uids/gids for owner matches
merge 515752 610111 thanks DUPLICATE of 515752. The problem was fixed in 1.4.3 already. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#603379: 603379: pam_mount not honoring options from user config file
pam_mount volume fstype=fuse path=encfs#/home/%(USER)/.crypt mountpoint=/home/%(USER)/Documents/private options=nosuid,nodev,allow_root / /pam_mount The mount works, but the allow_root option is not honored. Mounting manually with encfs accepts the option and user_allow_other is enabled in fuse.conf, so this is not an issue related to fuse. Enable debug level=2 / and see how encfs gets called. Are you sure you have allow_root in mntoptions allowed=... in /etc/security/pam_mount.conf.xml? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#603379: 603379: pam_mount not honoring options from user config file
On Tuesday 2010-12-21 19:23, Jan Engelhardt wrote: pam_mount volume fstype=fuse path=encfs#/home/%(USER)/.crypt mountpoint=/home/%(USER)/Documents/private options=nosuid,nodev,allow_root / /pam_mount The mount works, but the allow_root option is not honored. Mounting manually with encfs accepts the option and user_allow_other is enabled in fuse.conf, so this is not an issue related to fuse. Enable debug level=2 / and see how encfs gets called. Are you sure you have allow_root in mntoptions allowed=... in /etc/security/pam_mount.conf.xml? This is fixed by commit 2b1c9a7, to show up in pam_mount v2.8. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#600857: no SNAT stickness in iptables
The SNAT target supposedly already worked like SAME, thus SAME was removed. The completely-random SNAT was moved to require the --random option. Kernel commit cb76c6a597350534d211ba79d92da1f9771f8226. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#529954: 529954: add ip6tables TPROXY support
ip6tables seems not to support TPROXY: Fixed for Linux 2.6.37 and iptables-1.4.11. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#429579: 429579: iptables -L trailing blanks enough to cause wrapping
$ iptables -L was wrapping on to extra blank lines on my extra wide screen Out of curiosity, how wide is your screen? iptables: No chain/target/match by that name say what name, without requiring we do The xtables1 setsockopt protocol does not have room to convey more than an errno code; this will be rectified with the xtables2 netlink interface. Also, on the man page TARPIT section, Standard iptables does not come with TARPIT. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#580882: 580882: mount.crypt: New option to show fsck output
How exactly are we supposed to print any fsck progress to a graphical context, anyway? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#496769: removing entries fails always with Operation failed: such conntrack doesn't exist
That should be fixed in 0.9.15 (possibly earlier). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#583715: mount.crypt doesn't handle ctrl-c correctly
Seems my knowledge of pmt is already enrusted. :p -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#594393: CVE-2010-2947
Please check whether stable is affected. As the commit log says: Affects all versions prior to, and including, 3.5. So yes, stable is affected (unless somebody was already quick to fix it there). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#580882: mount.crypt: New option to show fsck output
On Tuesday 2010-07-27 18:10, Jörg Sommer wrote: Hi Jan, What I was saying is that you cannot make the output of something visible that isn't being run in the first place. Why not? Bind stdout and stderr of the process to the current and be silent, while the subprocess is running. I don't see where the problem is. It's like: Try to make a patch and see ;-) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#582820: Dependencies not honored
Package: xtables-addons Version: 1.26 In IRC I received a report from a Debian user who fell victim to the lack of proper dependencies. The system, if I understood him right, started out with xtables-addons-1.26 and iptables-1.4.3. The libxt_*.so files in xtables-addons are linked against libxtables.so.4, the latter of which is only provided starting from iptables 1.4.6. In rpm-based systems, xtables-addons(.rpm) would have a (automatically detected during build) Requires: libxtables.so.4, and since only iptables 1.4.6 provides this, the package manager du jour would have either 1. suggested to upgrade to iptables 1.4.6 2. not install xtables-addons However in .deb I don't see anything that would enforce this. Manually adding iptables = 1.4.6 to xtables-addons.dsc does not look right either - it's easy to forget updating this, etc. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#528366: [bts#528366] Re: /sbin/mount.crypt: mount.crypt does not send keyfile option to cryptsetup
This is now implemented and will be there for v2.2. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#573392: [pkg-cryptsetup-devel] Bug#573392: (no subject)
I posted this now at http://code.google.com/p/cryptsetup/issues/detail?id=58 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#573392: [pkg-cryptsetup-devel] Bug#573392: (no subject)
On Tuesday 2010-03-16 13:37, Jonas Meurer wrote: hey jan, did you give cryptsetup 1.1.0 a try yet? its library api has many improvements compared to cryptsetup 1.0.6. Great, I'll try that. Thanks. it should be safe to upgrade to cryptsetup packages from debian/unstable within debian/lenny, as long as you don't ignore the instructions from NEWS.Debian. Oh I'm not from Debian, I just remember that BTS is the cryptsetup anchorpoint ;) Jan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#573392: (no subject)
Package: cryptsetup Version: 1.0.7 Severity: important I was trying to change pam_mount to use libcryptsetup instead of forking out to /sbin/cryptsetup, but then I noticed I cannot pass in the binary key material via the library api. (There is no keyfile on disk, it's only in memory.) struct crypt_options: - passphrase: zero terminated/no length parameter provided *shrug* - passphrase_fd: pipe() to myself is prone to deadlock - writing key material to a file: prone to missing cleanup and collisions Any way to get it done for a non-interactive program? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#566338: Add upstream URL to .dsc
Package: libaio Version: 0.3.107 It would be nice to know where libaio is from, given that internet searches only turn up binary packages. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#538433: (no subject)
So, is this being completely ignored? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#527733: (no subject)
Hi René, you need to explicitly use x86_64 if you want to reproduce this, not i386. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#554628: (no subject)
notabug. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#528366: (no subject)
melissa:~# cat /etc/cryptmount/cmtab You are probably confusing cryptmount with pam_mount's mount.crypt. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#528366: very complicated the whole setting with mount.crypt
I can't find documentation regarding the options that I can put inside /etc/fstab when I specify an entry as 'crypt' You may find these in `man mount.crypt`. I can't find documentation about how's /etc/crypttab interacting with other programs, i.e. who uses what. /etc/crypttab is a mechanism specific to somewhere between distro and cryptsetup. It is invoked by some /etc/init.d script to mount static crypto volumes on boot. It should be documented in crypttab(5), too. Even worse, mount.crypt documentation says that key-files can only be used with ' normal crypto volumes ' and not with LUKS volumes. Why? The fsk_hash/fsk_cipher/keyfile options to mount.crypt dictate that mount.crypt shall read and decrypt the keyfile with your given password, and send the decrypted key (securely) to cryptsetup for use as a key. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#536415: cryptsetup: opening LUKS partitions takes several seconds
On Monday 2009-08-17 18:31, Marcus Better wrote: cryptsetup: opening LUKS partitions takes several seconds This is probably due to PBKDF2 itself and should also manifest with crypto mappings created after the systems is up. Oh. Can the this be tuned somehow? AFAIK only by not using LUKS and using standard dmcrypt instead. What could explain the difference between my two nearly identical laptops (Thinkpad R60 and T61), where the slower one takes noticeably less time to unlock the partitions? Different partition sizes, settings, etc. Perhaps SMP is disabled on one (I don't you know - you did not tell me). My crystal orb is getting gray again also you would need to unlock the very same fs with both machines, not two different fs with two different machines. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541805: Remove conflicting warning message
Package: cryptsetup
Version: 1.0.5
Version: 1.0.7
Users of libpam-mount regularly get confused when PAM is set
to no-debug-output (which is the default), but cryptsetup
spews this line. Commands that ran successful should not
print to stderr, because that would indicate a warning, and
command successful definitely is not a warning.
The patch is against tr...@83.parent 5f0a4d71a9e0614b9b3a9cf36397f53ed8c7f014 ()
commit ab22843236163656aa602afe0bde9cbc7c405959
Author: Jan Engelhardt jeng...@medozas.de
Date: Sun Aug 16 14:22:57 2009 +0200
cryptsetup: remove conflicting status message
Users of libpam-mount regularly get confused when PAM is set to
no-debug-output (which is the default), but cryptsetup spews this
line. Commands that ran successful should not print to stderr,
because that would indicate a warning, and command successful
definitely is not a warning.
---
src/cryptsetup.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/src/cryptsetup.c b/src/cryptsetup.c
index 075a12a..5ce722f 100644
--- a/src/cryptsetup.c
+++ b/src/cryptsetup.c
@@ -125,10 +125,8 @@ static void show_status(int errcode)
{
char error[256];
- if(!errcode) {
-fprintf(stderr, _(Command successful.\n));
+ if(!errcode)
return;
- }
crypt_get_error(error, sizeof(error));
if (!opt_verbose) {
--
# Created with git-export-patch
Bug#540532: Fix uscan for package libhx
Package: libhx Version: 2.9 http://dehs.alioth.debian.org/report.php?package=libhx URL changed to Sourceforge. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#528990: [BTS] Re: ipset modules?
On Saturday 2009-08-08 20:28, Christoph Anton Mitterer wrote: On Sat, 2009-08-08 at 20:05 +0200, Jan Engelhardt wrote: Well, shameless ad included, Submitter may try xtables-addons which ships ipset3, including kernel modules. Hm interesting,... didn't know that it includes this. Perhaps the two maintainers should think whether the packages could/should be joined? Josef (ipset author) wants to continue supporting Linux 2.4, a scenario the Xt-a build environment cannot provide. So I'll let him release his tarballs, import a copy into Xt-a for convenience, and everbody moves along as usual :] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#538433: Obsolete ifconfig and related tools
ifconfig has tons of problems and its use should be discouraged in favor of iproute2. we're working on that :) The patch serves as means to identify remaining programs requiring checking and its inclusion, I would say, not be help up by any related work. It helps to flag up programs that still require attention, but first and foremost it is meant to inform users. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#538433: Obsolete ifconfig and related tools
Oh, sorry I missed the patch at first. But it is not a good idea to inject text on standard output, since these tools are usually used inside scripts.. If need be, the printing to stdout can be changed to stderr. Not that grepping in ifconfig output was reliable in the first place (due to localization, you name it)... -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#538433: Obsolete ifconfig and related tools
Package: net-tools
Version: 1.60
ifconfig has tons of problems and its use should be discouraged in favor
of iproute2.---
arp.c |7 +++
ifconfig.c | 20
ipmaddr.c |3 +++
iptunnel.c |3 +++
netstat.c | 39 +++
route.c| 12 ++--
6 files changed, 82 insertions(+), 2 deletions(-)
Index: net-tools-1.60/arp.c
===
--- net-tools-1.60.orig/arp.c
+++ net-tools-1.60/arp.c
@@ -514,6 +514,10 @@ static void arp_disp(char *name, char *i
printf(_(on %s\n), dev);
}
+static void obsolescence_warning(void)
+{
+ printf(_(arp is obsolete: please use `ip neigh` instead.\n));
+}
/* Display the contents of the ARP cache in the kernel. */
static int arp_show(char *name)
@@ -601,6 +605,7 @@ static int arp_show(char *name)
}
}
(void) fclose(fp);
+obsolescence_warning();
return (0);
}
@@ -662,6 +667,8 @@ int main(int argc, char **argv)
textdomain(net-tools);
#endif
+obsolescence_warning();
+
/* Initialize variables... */
if ((hw = get_hwtype(DFLT_HW)) == NULL) {
fprintf(stderr, _(%s: hardware type not supported!\n), DFLT_HW);
Index: net-tools-1.60/ifconfig.c
===
--- net-tools-1.60.orig/ifconfig.c
+++ net-tools-1.60/ifconfig.c
@@ -225,6 +225,19 @@ static int set_netmask(int skfd, struct
return 0;
}
+/*
+ * This is called twice on purpose. Once at the start of the program,
+ * so that users piping it into |less will see it on the first page
+ * (if there is lots of output), and once again at the end of the program,
+ * for users that do not pipe it into anything, seeing the last page
+ * (also with lots of output).
+ */
+static void obsolescence_warning(void)
+{
+ printf(ifconfig is obsolete: please use `ip addr` or `ip link`.
+ For statistics, use `ip -s link`.\n);
+}
+
int main(int argc, char **argv)
{
struct sockaddr sa, sa_netmask;
@@ -253,6 +266,8 @@ int main(int argc, char **argv)
textdomain(net-tools);
#endif
+obsolescence_warning();
+
/* Find any options. */
argc--;
argv++;
@@ -295,6 +310,8 @@ int main(int argc, char **argv)
if (argc == 0) {
int err = if_print((char *) NULL);
(void) close(skfd);
+ if (err == 0)
+ obsolescence_warning();
exit(err 0);
}
/* No. Fetch the interface name. */
@@ -987,6 +1004,9 @@ int main(int argc, char **argv)
spp++;
}
+if (goterr == 0)
+ obsolescence_warning();
+
return (goterr);
}
Index: net-tools-1.60/ipmaddr.c
===
--- net-tools-1.60.orig/ipmaddr.c
+++ net-tools-1.60/ipmaddr.c
@@ -396,6 +396,9 @@ int main(int argc, char **argv)
textdomain(net-tools);
#endif
+ printf(_(Note: multicast address configuration should
+ be done through `ip maddr` instead.\n));
+
basename = strrchr(argv[0], '/');
if (basename == NULL)
basename = argv[0];
Index: net-tools-1.60/iptunnel.c
===
--- net-tools-1.60.orig/iptunnel.c
+++ net-tools-1.60/iptunnel.c
@@ -587,6 +587,9 @@ int main(int argc, char **argv)
textdomain(net-tools);
#endif
+ printf(_(Note: tunnel configuration should
+ be done through `ip tunnel` instead.\n));
+
basename = strrchr(argv[0], '/');
if (basename == NULL)
basename = argv[0];
Index: net-tools-1.60/netstat.c
===
--- net-tools-1.60.orig/netstat.c
+++ net-tools-1.60/netstat.c
@@ -1989,6 +1989,34 @@ static void usage(void)
exit(E_USAGE);
}
+static void netstat_obsolescence_warning(void)
+{
+ printf(_(netstat is obsolete: please use `ss` instead.\n));
+}
+
+static void route_obsolescence_warning(void)
+{
+ printf(_(`netstat -r` is obsolete:
+ please use `ip route` instead.\n));
+}
+
+static void stat_obsolescence_warning(void)
+{
+ printf(_(`netstat -i` is obsolete:
+ please use `ip -s link` instead.\n));
+}
+
+static void groups_obsolescence_warning(void)
+{
+ printf(_(`netstat -g` is obsolete:
+ please use `ip maddr` instead.\n));
+}
+
+static void masq_obsolescence_warning(void)
+{
+ printf(_(`netstat -M` is obsolete:
+ please use `conntrack -L` instead.\n));
+}
int main
(int argc, char *argv[]) {
@@ -2152,6 +2180,7 @@ int main
+ flag_ax25 + flag_netrom + flag_igmp + flag_x25;
if (flag_mas) {
+ masq_obsolescence_warning();
#if HAVE_FW_MASQUERADE HAVE_AFINET
#if MORE_THAN_ONE_MASQ_AF
if (!afname[0])
@@ -2168,6 +2197,7 @@ int main
ENOSUPP(netstat.c, FW_MASQUERADE);
i = -1;
#endif
+ masq_obsolescence_warning();
return (i);
}
@@ -2180,6 +2210,8 @@ int main
if (flag_rou) {
int options = 0;
+ route_obsolescence_warning();
+
if (!afname[0])
strcpy(afname, DFLT_AF);
@@ -2198,9 +2230,11 @@ int main
break;
Bug#536585: Compress fluid-soundfont source package
Package: fluid-soundfont Version: 3.1-1 The fluid source package is a pretty large one, and is usually shipped in SFARK format upstream. Since SFARK is a cumbersome closed-source whacky thing, and standard compressors like lzma do not operate well on such audio files, I have tried running FLAC on the soundfont files, with success - the .src.rpm is just 77MB instead of 128MB. I thought that maybe Debian could make use of this technique too. The file is at http://jftp.medozas.de/SRPMS-11.1/fluid-soundfont-3.1-jen0.src.rpm (I still think that eawpats sounds better ;-) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#536246: Unable to set debian iptables time rule (fwd)
-- Forwarded message -- Date: Tue, 7 Jul 2009 20:09:51 From: Jan Engelhardt To: Sanjoy Ghosh Subject: Re: Unable to set debian iptables time rule On Tuesday 2009-07-07 19:50, Sanjoy Ghosh wrote: Hi, In early days I also tried to install your IPtables time patch but unable. I also install debian-501-i386-netinst.iso(lenny).And my IPtables version 1.4.2 which is installed during debian install. Though this version have time option but i am unable to do this.Here is the rule : iptables -A INPUT -i eth1 -s xxx.xxx.xxx.xxx -m mac --mac-source xx:xx:xx:xx:xx:xx -m time --timestart 09:00 --timestop 20:00 --days Mon,Tue,Wed,Thu,Fri -j ACCEPT .When apply this rule got some error message(iptables v1.4.2: Unknown arg `(null)' Try `iptables -h' or 'iptables --help' for more information). Please help me. Upgrade to 1.4.4 - it will print a better error message than (null). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#536246: Unable to set debian iptables time rule (fwd)
Package: iptables Version: 1.4.2 Tags: fixed-upstream owner, please reset Submitter to original poster (see Reply-To) -- Forwarded message -- Date: Wed, 8 Jul 2009 16:28:08 From: Sanjoy Ghosh sanjo...@gmail.com Subject: Re: Unable to set debian iptables time rule Hi, My Os was debian lenny and please tell me the procedure how to install time patch for iptables 1.4.2.Because when I Installed debian lenny iptables also installed which iptables version 1.4.2.In previous mail I send you a Bug when I set a time rule in my OS. Help me for further step. Thanks Sanjoy On Wed, Jul 8, 2009 at 2:12 PM, Jan Engelhardt wrote: On Wednesday 2009-07-08 04:51, Sanjoy Ghosh wrote: Thanks For mail me.And i will try to update and again try but problem was previous state.Please help me. Without a proper error message that is impossible. File a bug with debian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#509234: libpam-mount: pam_mount no longer waits for password
On Wednesday 2009-07-01 01:04, Frédéric Brière wrote: On Fri, Feb 13, 2009 at 04:44:46PM -0500, Frédéric Brière wrote: What remains as a bug is the presence of a superfluous Password: prompt with enable_interactive, which is displayed even if pam_mount has successfully retrieved the PAM password. One thing I noticed today: this is per mount, not per session. IOW, I now have two volume entries, and the prompt is displayed twice. As previously said, this is from cryptsetup. All I can, and now will, do is to discard stdout output from these programs. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#509234: libpam-mount: pam_mount no longer waits for password
On Wednesday 2009-07-01 01:04, Frédéric Brière wrote: On Fri, Feb 13, 2009 at 04:44:46PM -0500, Frédéric Brière wrote: What remains as a bug is the presence of a superfluous Password: prompt with enable_interactive, which is displayed even if pam_mount has successfully retrieved the PAM password. One thing I noticed today: this is per mount, not per session. IOW, I now have two volume entries, and the prompt is displayed twice. Fix now in pam_mout 1.27. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#531677: (no subject)
tag 531677 +fixed-upstream thanks Upstream in 1.4.4. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#528457: (no subject)
Collected upstream in 1.4.4. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#532878: (no subject)
lsof support was ripped out for v0.45 and replaced by ofl. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#524862: (no subject)
tag $this +debian-specific FTR, iptables-apply is not installed by upstream at `make install` time. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#528427: (no subject)
Patch queued. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#472655: (no subject)
See bug #473533 for resolution. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#504989: (no subject)
Troex Nevelin wrote: That is OK as I don't have xt_connlimit.ko module in this kernel, so there is no bug, right? But you do have ipt_connlimit, in, most likely, net/ipv4/netfilter/ipt_connlimit.ko. Both ipt_connlimit and xt_connlimit use same ID (“connlimit.0”), which is why this 'bug' did happen (Invalid argument). I could have easily chosen a different ID for xt_connlimit (“connlimit.1”), but I did not do that back then. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#516003: (no subject)
(This takes into account the mail you sent by private email.) Feb 19 20:21:52 MYHOSTNAME login[4568]: pam_mount(mount.c:64): umount messages: Feb 19 20:21:52 MYHOSTNAME login[4568]: pam_mount(mount.c:67): Command failed: Device busy Well that comes from umount(8). If your disk is still used, there is no way we can unmount it. So it's not really a pam_mount issue... The function ehd_dmcrypt_ops.unload() fails because on top of my LUKS partition (/dev/mapper/_dev_loop0) a loop device is set up (/dev/loop1): Then you have to make sure this loop device - which has an inode on the crypto image - is closed. But why is a loop device attached to my LUKS partition? Because you specified so. Feb 19 20:21:47 MYHOSTNAME login[4568]: pam_mount(mount.c:172): Mount info: globalconf, user=MYUSERNAME volume fstype=auto server=(null) path=/my/encrypted.img mountpoint=/mnt cipher=(null) fskeypath=/my/encrypted.key fskeycipher=aes-256-cbc fskeyhash=sha512 options=fsk_cipher=aes-256-cbc,fsk_hash=sha512,keyfile=/my/encrypted.key,fsck,noexec,nodev,nosuid,relatime,cipher=aes-cbc-essiv:sha256,keybits=256,hash=sha512 / fstab=0 This yields a mount command of Feb 19 20:21:47 MYHOSTNAME login[4568]: command: [mount] [-p0] [-o] [fsk_cipher=aes-256-cbc,fsk_hash=sha512,keyfile=/my/encrypted.key,fsck,noexec,nodev,nosuid,relatime,cipher=aes-cbc-essiv:sha256,keybits=256,hash=sha512] [-t] [auto] [/my/encrypted.img] [/mnt] And that one does not even work for me on openSUSE/util-linux 2.14.1: 16:15 yaguchi:../pmt/src # mount -p0 -o fsk_cipher=aes-256-cbc,fsk_hash=sha1,keyfile=/home/jengelh/Coding/pmt/src/x.key,fsck,noexec,nodev,nosuid,relatime,cipher=aes-cbc-essiv:sha256,keybits=256,hash=sha512 -t auto /home/jengelh/Coding/pmt/src/x.cont /mnt mount: you must specify the filesystem type So it may happen that your Debian mount(8) is either old or does nasty things wrt. loop. Certainly, what it does seems coherent though: /dev/loop0: [0901]:14450726 (/my/encrypted.img) /dev/loop1: [000d]:30967 (/dev/mapper/_dev_loop0) (a) mount creates a loop device /dev/loop0 from encrypted.img (b) mount.crypt gets /dev/loop0 as first parameter... (c) umount does not call crypt or so.. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#516003: (no subject)
On Sunday 2009-03-01 18:19, Wearenotalone wrote: Thanks for your feedback :) But why is a loop device attached to my LUKS partition? Because you specified so. I already noticed that i made some bad configuration mistakes ;) But i don't know for sure, where exactly i made this error. Is my assumption correct, that this problem is caused by the keybits option (or by me, because i specified the keybits option)? What suggestions do you have in order to fix this problem? Just ignore the keybits option? For your specific problem, omit the loop option in the options= in volume. I do not think this has anything to do with the keybits option. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#516003: (no subject)
On Sunday 2009-03-01 19:09, Wearenotalone wrote: For your specific problem, omit the loop option in the options= in volume. I do not think this has anything to do with the keybits option. I never explicitly used the loop option[...] Yes, but mount(8) decided to setup one before calling crypt_LUKS: mount.crypt_LUKS(mtcrypt.c:155): loop mount option ignored Hm. It seems to have been keysize after all (I could reproduce it): # mount -v x.cont /mnt -o fsk_cipher=aes-256-cbc,fsk_hash=sha512,keyfile=/my/encrypted.key,fsck,noexec,nodev,nosuid,relatime,cipher=aes-cbc-essiv:sha256,keybits=256,hash=sha512 mount: going to use the loop device /dev/loop0 Without keyfile, mount(8) will not set up the loop device. But the bug here is actually that you did not specify fstype=crypt in pam_mount.conf.xml. One has to explicitly state the fstype to mount(8) for any pseudo filesystem if it uses options that conflict with mount itself. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#509234: libpam-mount: pam_mount no longer waits for password
I can't really think of anything. It by default uses the PAM password and if that does not work, will ask for one. (Without having to specify any extra options.) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#350052: (no subject)
The proper way to remove active NAT mappings is to use `conntrack -F` (package: conntrack-tools). It is not required to unload iptables. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#509131: (no subject)
ping(8) is a setuid application so that it can create the SOCK_RAW/IPPRORO_RAW sockets. As such, the socket is very likely to belong to root rather than the user who originall invoked ping. I would not be surprised if -m owner --uid-owner foo did not match, and --uid-owner root always does. Also, if the kernel generates an ICMP reply in response to a received echo, there will not be any owner available. tag INVALID. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#150467: (no subject)
tag fixed-upstream This was fixed in v1.2.7. Please close. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#512047: (no subject)
I cannot reproduce this with any of iptables 1.4.1.1 iptables 1.4.2 iptables 1.4.3-rc1 Hence tagging as fixed-upstream. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#513516: (no subject)
The kernel wants '\0' for algo, only pattern may be a non-'\0'-terminated string of up to 128 chars. Turns out iptables calculates the -patlen incorrectly. Will submit fix upstream, thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#513465: (no subject)
That's probably just a friendly reminder that telnet is insecure and you should not be using it ;-) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#510924: iproute: tc fails on action ipt
On Saturday 2009-01-17 20:44, jamal wrote:
As an example of something that would work and i could use as a base,
see attached against git tree - compile tested.
It's a lot of code at once.
I think it is nicer to proceed in single steps (and commits),
as that shows what other problems we must bump over.
Here, this is what I think should be the first patch (see below).
This already turns up some further issues that need to be
resolved first, among:
- the XTABLES_LIBDIR define must be changeable at ./configure time
- it would make sense to rename most of the iptables functions
to have a prefix (i'll prepare that)
- making most of the functions inside m_ipt.c static so they do
not cause a dynamic linker overlap (e.g. xtables_register_target
which is as of yet still replicated)
What do you think?
# iproute git
diff --git a/tc/Makefile b/tc/Makefile
index bd9b833..7a1611d 100644
--- a/tc/Makefile
+++ b/tc/Makefile
@@ -4,6 +4,8 @@ TCOBJ= tc.o tc_qdisc.o tc_class.o tc_filter.o tc_util.o \
include ../Config
+CFLAGS += -DXTABLES_LIBDIR=\/usr/libexec/xtables\
+
TCMODULES :=
TCMODULES += q_fifo.o
TCMODULES += q_sfq.o
diff --git a/tc/m_ipt.c b/tc/m_ipt.c
index f5b7b3c..ea83b58 100644
--- a/tc/m_ipt.c
+++ b/tc/m_ipt.c
@@ -1,5 +1,5 @@
/*
- * m_ipt.c iptables based targets
+ * m_ipt.c Xtables based targets
* utilities mostly ripped from iptables duh, its the linux way
*
* This program is free software; you can distribute it and/or
@@ -15,7 +15,6 @@
#include netinet/in.h
#include arpa/inet.h
#include linux/if.h
-#include iptables.h
#include linux/netfilter.h
#include linux/netfilter_ipv4/ip_tables.h
#include utils.h
@@ -34,6 +33,7 @@
#include unistd.h
#include fcntl.h
#include sys/wait.h
+#include xtables.h
static const char *pname = tc-ipt;
static const char *tname = mangle;
@@ -52,7 +52,7 @@ static struct option original_opts[] = {
{0, 0, 0, 0}
};
-static struct iptables_target *t_list = NULL;
+static struct xtables_target *t_list = NULL;
static struct option *opts = original_opts;
static unsigned int global_option_offset = 0;
#define OPTION_OFFSET 256
@@ -60,7 +60,7 @@ static unsigned int global_option_offset = 0;
char *lib_dir;
void
-register_target(struct iptables_target *me)
+register_target(struct xtables_target *me)
{
/* fprintf(stderr, \nDummy register_target %s \n, me-name);
*/
@@ -70,7 +70,7 @@ register_target(struct iptables_target *me)
}
void
-xtables_register_target(struct iptables_target *me)
+xtables_register_target(struct xtables_target *me)
{
me-next = t_list;
t_list = me;
@@ -84,24 +84,6 @@ exit_tryhelp(int status)
exit(status);
}
-void
-exit_error(enum exittype status, char *msg, ...)
-{
- va_list args;
-
- va_start(args, msg);
- fprintf(stderr, %s v%s: , pname, pversion);
- vfprintf(stderr, msg, args);
- va_end(args);
- fprintf(stderr, \n);
- if (status == PARAMETER_PROBLEM)
- exit_tryhelp(status);
- if (status == VERSION_PROBLEM)
- fprintf(stderr,
- Perhaps iptables or your kernel needs to be
upgraded.\n);
- exit(status);
-}
-
/* stolen from iptables 1.2.11
They should really have them as a library so i can link to them
Email them next time i remember
@@ -206,10 +188,10 @@ fw_calloc(size_t count, size_t size)
return p;
}
-static struct iptables_target *
+static struct xtables_target *
find_t(char *name)
{
- struct iptables_target *m;
+ struct xtables_target *m;
for (m = t_list; m; m = m-next) {
if (strcmp(m-name, name) == 0)
return m;
@@ -218,13 +200,13 @@ find_t(char *name)
return NULL;
}
-static struct iptables_target *
+static struct xtables_target *
get_target_name(const char *name)
{
void *handle;
char *error;
char *new_name, *lname;
- struct iptables_target *m;
+ struct xtables_target *m;
char path[strlen(lib_dir) + sizeof (/libipt_.so) + strlen(name)];
new_name = malloc(strlen(name) + 1);
@@ -284,7 +266,7 @@ get_target_name(const char *name)
m = dlsym(handle, new_name);
if ((error = dlerror()) != NULL) {
- m = (struct iptables_target *) dlsym(handle, lname);
+ m = dlsym(handle, lname);
if ((error = dlerror()) != NULL) {
m = find_t(new_name);
if (NULL == m) {
@@ -352,10 +334,8 @@ static void set_revision(char *name, u_int8_t revision)
* we may need to check for version mismatch
*/
int
-build_st(struct iptables_target *target, struct ipt_entry_target *t)
+build_st(struct xtables_target *target, struct ipt_entry_target *t)
{
- unsigned int nfcache = 0;
-
if (target) {
size_t size;
@@ -367,7 +347,7 @@ build_st(struct iptables_target *target, struct
ipt_entry_target *t)
Bug#510924: iproute: tc fails on action ipt
On Wednesday 2009-01-21 19:39, jamal wrote: I agree. And I have a patch which resolves the current issue with some preliminary testing from Yawhen Kasarzhewski y...@pisem.net I still need to proof-read it and probably break it into three separate patches before submission. I am afraid I cant get rid of iptables as is from ipt - it is needed for older kernels. Well that is bad. But it is not really my problem. m_ipt has so horribly abused iptables it is quite unfixable IMHO. So Instead I compile something else once i detect there is xtables in the system, I compile with xtables support. If that works, ok. But I doubt it would get accepted upstream. See attached. In the next iteration I will like to remove everything tagged with XXX: TC_CONFIG_XIPT_H by making sure everything i need IPT - XT. (not IPXT) Here, this is what I think should be the first patch (see below). This already turns up some further issues that need to be resolved first, among: - the XTABLES_LIBDIR define must be changeable at ./configure time - it would make sense to rename most of the iptables functions to have a prefix (i'll prepare that) - making most of the functions inside m_ipt.c static so they do not cause a dynamic linker overlap (e.g. xtables_register_target which is as of yet still replicated) What do you think? Does it compile? Mostly. I cannot get iproute2 compiled because it cannot find the definitions for struct tcmsg, but I think I got rid of all the iptables-related compile errors. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#510924: iproute: tc fails on action ipt
On Wednesday 2009-01-21 20:11, jamal wrote: But it is not really my problem. It is ethically my problem, unfortunately. I wrote it and there are users out there. Heh. Does it compile? Mostly. I cannot get iproute2 compiled because it cannot find the definitions for struct tcmsg, but I think I got rid of all the iptables-related compile errors. If you are on debian - you should be able to install iproute-dev package and be fine I think. I just dload the tree. No, this is iproute2 which is missing some stuff. Specifically, doing this squashes away another compile error: diff --git a/tc/tc_util.h b/tc/tc_util.h index d84b09a..216d6cd 100644 --- a/tc/tc_util.h +++ b/tc/tc_util.h @@ -2,9 +2,11 @@ #define _TC_UTIL_H_ 1 #define MAX_MSG 16384 +#include linux/types.h #include linux/pkt_sched.h #include linux/pkt_cls.h #include linux/gen_stats.h +#include linux/rtnetlink.h #include tc_core.h /* This is the deprecated multiqueue interface */ In any case, I am afraid that still doesnt fix the backward/forward compat challenge. First things first. If you can get it to run with current libxtables.so, perhaps with some more changes as needed, you can call that an achievement and later fix the old m_ipt. #include xtables.h #include xtables/internal.h -- /home/hadi/iptables-src/iptables-1.4.2/.libs//libxtables.so: undefined reference to `program_version' /home/hadi/iptables-src/iptables-1.4.2/.libs//libxtables.so: undefined reference to `afinfo' /home/hadi/iptables-src/iptables-1.4.2/.libs//libxtables.so: undefined reference to `exit_error' /home/hadi/iptables-src/iptables-1.4.2/.libs//libxtables.so: undefined reference to `program_name' collect2: ld returned 1 exit status You tried a link. I only compiled it (partially, due to the errors). However, program_version, afinfo and program_name are supposed to be provided by the program itself (iptables, ip6tables, not libxtables) in this case m_ipt.c. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#510924: Debian Bug#510924: iproute: tc fails on action ipt - iptables extensions/libs
On Saturday 2009-01-17 15:27, jamal wrote: Jan/Patrick, Trying to fix YABFC on ipt: Looking at iptables 1.4.2, I see that some of the libipt_*.so are missing compared to iptables 1.4.1 (about 50%). Example: libipt_TTL.so is created in both versions but libipt_TOS.so is no longer there. Is this a phase to eventually replace libipt_* with libxt_* or is it a bug? $ l *TTL* *TOS* -rw-r--r-- 1 jengelh users 3276 Dec 25 00:09 libipt_TTL.c -rw-r--r-- 1 jengelh users 592 Jan 9 03:12 libipt_TTL.man -rw-r--r-- 1 jengelh users 11680 Jan 8 13:36 libipt_TTL.oo -rwxr-xr-x 1 jengelh users 14050 Jan 8 13:36 libipt_TTL.so -rw-r--r-- 1 jengelh users 7795 Dec 25 00:09 libxt_TOS.c -rw-r--r-- 1 jengelh users 1152 Jan 9 03:12 libxt_TOS.man -rw-r--r-- 1 jengelh users 19280 Jan 8 13:36 libxt_TOS.oo -rwxr-xr-x 1 jengelh users 21578 Jan 8 13:36 libxt_TOS.so -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
