Bug#1063688: mypy fails with a combination of argparse and glob
Package: mypy
Version: 1.0.1-1
Severity: normal
X-Debbugs-Cc: dalg...@gmail.com
Dear Maintainer,
$ cat u.py
import argparse
import glob
parser = argparse.ArgumentParser()
parser.add_argument('-g', type=glob.glob)
$ mypy u.py
u.py:5: error: Argument "type" to "add_argument" of "_ActionsContainer" has
incompatible type "Callable[[AnyStr, DefaultNamedArg(Optional[Union[str, bytes,
PathLike[str], PathLike[bytes]]], 'root_dir'), DefaultNamedArg(Optional[int],
'dir_fd'), DefaultNamedArg(bool, 'recursive'), DefaultNamedArg(bool,
'include_hidden')], List[AnyStr]]"; expected "Union[Callable[[str],
List[AnyStr]], FileType]" [arg-type]
Found 1 error in 1 file (checked 1 source file)
Add the following directive to whatever line contains "type=glob.glob" is a
work around:
# type: ignore[arg-type]
-- System Information:
Debian Release: 12.4
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0-17-amd64 (SMP w/6 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages mypy depends on:
ii python3 3.11.2-1+b1
ii python3-mypy 1.0.1-1
Versions of packages mypy recommends:
ii python3-typeshed 0.0~git20221107.4f381af-1
Versions of packages mypy suggests:
pn mypy-doc
-- no debconf information
Bug#1059546: pylint generates false positive 'import-error' with local editable modules.
Easily replicable setup environment attached. A.tar.gz Description: application/gzip B.tar.gz Description: application/gzip
Bug#1059546: pylint generates false positive 'import-error' with local editable modules.
Sorry. I now realize that changing my local PROMPT to be the default '$ ', I dropped an important bit of information. The file, `t.py` is NOT in the same directory as `pyproject.toml`. That is, while t.py was $HOME for the test, the pyproject.toml file and associated source was in some $RANDOM directory. Just like, if I have two python projects, A and B, living in completely different source directories, and A depends on B. If B is installed in normal mode, pylint against A works fine. However, if B is installed with 'pip -e', then pylint against A cannot find B. mrc
Bug#1059546: pylint generates false positive 'import-error' with local editable modules.
Package: pylint
Version: 2.16.2-2
Severity: important
Tags: upstream
X-Debbugs-Cc: dalg...@gmail.com
Dear Maintainer,
This *might* be https://github.com/pylint-dev/pylint/issues/8829 . However, I
am new to this bits of the Python eco-system, so not confident in my
assessment.
When trying to run pylint against a module that imports an _editable_ module
install, a false positive 'import-error' is given.
To reproduce, I used the following toy module:
$ find -type f -exec printf '\n%s\n' {} \; -exec cat {} \;
./pyproject.toml
[project]
name = 'ttt'
version = '0'
./ttt/__init__.py
./ttt/pylintbug.py
"""Docstring."""
def bug_func():
"""Bug."""
print('I am the bug_func')
And this module for testing:
$ cat t.py
"""Docstring."""
from ttt import pylintbug
pylintbug.bug_func()
With the module not installed, nothing works, as expected:
# nothing installed
$ pip list --user ; date
Wed Dec 27 07:31:09 PM PST 2023
$ python --version
Python 3.11.2
$ python t.py
Traceback (most recent call last):
File "/home/nexus/t.py", line 3, in
from ttt import pylintbug
ModuleNotFoundError: No module named 'ttt'
$ pylint --rcfile /dev/null t.py
* Module t
t.py:3:0: E0401: Unable to import 'ttt' (import-error)
--
Your code has been rated at 0.00/10 (previous run: 0.00/10, +0.00)
Install the module:
$ pip install --break-system-packages .
Defaulting to user installation because normal site-packages is not writeable
Processing /home/nexus/src/ttt
Installing build dependencies ... done
Getting requirements to build wheel ... done
Preparing metadata (pyproject.toml) ... done
Building wheels for collected packages: ttt
Building wheel for ttt (pyproject.toml) ... done
Created wheel for ttt: filename=ttt-0-py3-none-any.whl size=1225
sha256=051948400d275bad5c31d656ef0394f8a43232d00754ab826bbe18dcd67d1c60
Stored in directory:
/tmp/pip-ephem-wheel-cache-upb4wjrt/wheels/c3/93/be/4d7b95f07076bb565c6c69548aef2e2868a95b899b724660dd
Successfully built ttt
Installing collected packages: ttt
Successfully installed ttt-0
And everything works as expected:
$ pip list --user ; date
Package Version
--- ---
ttt 0
Wed Dec 27 07:32:56 PM PST 2023
$ python t.py
I am the bug_func
$ pylint --rcfile /dev/null t.py
Your code has been rated at 10.00/10 (previous run: 0.00/10, +10.00)
Now, install the module and reinstall in _editable_ mode (-e):
$ pip uninstall --break-system-packages -y ttt
Found existing installation: ttt 0
Uninstalling ttt-0:
Successfully uninstalled ttt-0
$ pip install --break-system-packages -e .
Defaulting to user installation because normal site-packages is not writeable
Obtaining file:///home/nexus/src/ttt
Installing build dependencies ... done
Checking if build backend supports build_editable ... done
Getting requirements to build editable ... done
Preparing editable metadata (pyproject.toml) ... done
Building wheels for collected packages: ttt
Building editable for ttt (pyproject.toml) ... done
Created wheel for ttt: filename=ttt-0-0.editable-py3-none-any.whl size=2313
sha256=20eacec25143d7c0f57fed066c7c57dbed566853edc944919e1029a65349822b
Stored in directory:
/tmp/pip-ephem-wheel-cache-2sxotfjx/wheels/c3/93/be/4d7b95f07076bb565c6c69548aef2e2868a95b899b724660dd
Successfully built ttt
Installing collected packages: ttt
Successfully installed ttt-0
Now, executing the 't.py' script works, but pylint fails with the false
positive:
$ pip list --user ; date
Package Version Editable project location
--- --- -
ttt 0 /home/nexus/src/ttt
Wed Dec 27 07:35:24 PM PST 2023
$ python t.py
I am the bug_func
$ pylint --rcfile /dev/null t.py
* Module t
t.py:3:0: E0401: Unable to import 'ttt' (import-error)
Your code has been rated at 0.00/10 (previous run: 10.00/10, -10.00)
Reinstalling the module in regular mode and it works again:
$ pip list --user ; date
Package Version
--- ---
ttt 0
Wed Dec 27 07:38:27 PM PST 2023
$ python t.py
I am the bug_func
$ pylint --rcfile /dev/null t.py
Your code has been rated at 10.00/10 (previous run: 10.00/10, +0.00)
-- System Information:
Debian Release: 12.4
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0-16-amd64 (SMP w/6 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages pylint depends on:
ii python33.11.2-1+b1
ii python3-astroid2.14.2-1
ii python3-dill
Bug#1032522:
I missed this report while researching, so I ended up filing this one: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1058574 It looks like it was an upstream issue where certain code in python.el was brought into emacs 28.2, but didn't make it to 29.
Bug#1058574: Acknowledgement (emacs-el: emacs reliably hangs when editing python source with certain docstrings)
Of course, as soon as I file the bug, THEN I find a likely duplicate: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032522
Bug#1058574: emacs-el: emacs reliably hangs when editing python source with certain docstrings
Package: emacs-el Version: 1:28.2+1-15 Severity: important Tags: upstream X-Debbugs-Cc: dalg...@gmail.com Dear Maintainer, When editing the following file, emacs will reliably hang: $ cat bug.py def foo(self): """Foo.""" """ pass def baz(self): """Ba'r.""" pass The problem seems triggered by the single-quote in the second docstring. Upon research, this is likely a problem specific to the version of progmodes/python.el shipped with emacs 28.2. Although the above specific test case did not seem to match other reports I saw. I'm not comfortable enough mixing and matching something like emacs-el from backports (which is 29.1) with stable emacs 28.2 (not enough experience with emacs). Some reference threads: https://lists.gnu.org/archive/html/bug-gnu-emacs/2023-01/msg01686.html https://www.reddit.com/r/emacs/comments/z0oye9/emacs_freezes_when_opening_a_python_file https://emacs.stackexchange.com/questions/74167/python-mode-hangs-on-class-member-comment -- System Information: Debian Release: 12.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-15-amd64 (SMP w/6 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages emacs-el depends on: ii emacs-common 1:28.2+1-15 emacs-el recommends no packages. emacs-el suggests no packages. -- no debconf information
Bug#707824: less: crashes with multiple group regex
Package: less Version: 456-1 Severity: important Dear Maintainer, env -i TERM=$TERM less /usr/share/dict/words Then do this search: (a|b)(c|d) less crashes: *** glibc detected *** less: double free or corruption (fasttop): 0x0887edc8 *** === Backtrace: = /lib/i386-linux-gnu/i686/cmov/libc.so.6(+0x70f01)[0xb7626f01] /lib/i386-linux-gnu/i686/cmov/libc.so.6(+0x72768)[0xb7628768] /lib/i386-linux-gnu/i686/cmov/libc.so.6(cfree+0x6d)[0xb762b81d] less[0x805a701] === Memory map: 08048000-08069000 r-xp 08:31 1044485/bin/less 08069000-0806a000 r--p 0002 08:31 1044485/bin/less 0806a000-0806d000 rw-p 00021000 08:31 1044485/bin/less 0806d000-08071000 rw-p 00:00 0 08879000-0889a000 rw-p 00:00 0 [heap] b740-b7421000 rw-p 00:00 0 b7421000-b750 ---p 00:00 0 b7598000-b75b4000 r-xp 08:31 1085361 /lib/i386-linux-gnu/libgcc_s.so.1 b75b4000-b75b5000 rw-p 0001b000 08:31 1085361 /lib/i386-linux-gnu/libgcc_s.so.1 b75b5000-b75b6000 rw-p 00:00 0 b75b6000-b7712000 r-xp 08:31 1085420 /lib/i386-linux-gnu/i686/cmov/libc-2.13.so b7712000-b7713000 ---p 0015c000 08:31 1085420 /lib/i386-linux-gnu/i686/cmov/libc-2.13.so b7713000-b7715000 r--p 0015c000 08:31 1085420 /lib/i386-linux-gnu/i686/cmov/libc-2.13.so b7715000-b7716000 rw-p 0015e000 08:31 1085420 /lib/i386-linux-gnu/i686/cmov/libc-2.13.so b7716000-b7719000 rw-p 00:00 0 b7719000-b7736000 r-xp 08:31 1085458 /lib/i386-linux-gnu/libtinfo.so.5.9 b7736000-b7738000 r--p 0001c000 08:31 1085458 /lib/i386-linux-gnu/libtinfo.so.5.9 b7738000-b7739000 rw-p 0001e000 08:31 1085458 /lib/i386-linux-gnu/libtinfo.so.5.9 b7739000-b773a000 rw-p 00:00 0 b774f000-b775 rw-p 00:00 0 b775-b7751000 r-xp 00:00 0 [vdso] b7751000-b776d000 r-xp 08:31 1085704/lib/i386-linux-gnu/ld-2.13.so b776d000-b776e000 r--p 0001b000 08:31 1085704/lib/i386-linux-gnu/ld-2.13.so b776e000-b776f000 rw-p 0001c000 08:31 1085704/lib/i386-linux-gnu/ld-2.13.so bff2b000-bff4c000 rw-p 00:00 0 [stack] Aborted If I download and extract 444-4 and run it (using the same installed libraries from testing), it succeeds. Trying with 458-1 also has the same problem. -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-686-pae (SMP w/2 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 less depends on: ii debianutils 4.3.4 ii libc62.13-38 ii libtinfo55.9-10 less recommends no packages. less suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#566539: linux-image-2.6.32-trunk-486: Minor formatting issue on info screen during update
I do not have whiptail installed (saw no sense in having both dialog and whiptail installed). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#566539: linux-image-2.6.32-trunk-486: Minor formatting issue on info screen during update
ii debconf 1.5.28 Debian configuration management system ii debconf-i18n 1.5.28 full internationalization support for debcon Configured to use dialog ii dialog 1.1-20080819-1 Displays user-friendly dialog boxes from she mrc -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#566539: linux-image-2.6.32-trunk-486: Minor formatting issue on info screen during update
Package: linux-2.6 Version: 2.6.32-5 Severity: minor During the upgrade process, apt-get causes a message to display that starts with this text: │ Required firmware files may be missing│ │ │ │ This system is currently running Linux 2.6.30-2-686 and you are │ │ installing Linux 2.6.32-trunk-486. In the new version some of the│ │ drivers used on this system may require additional firmware files:│ While scrolling down, I noticed the following: │ radeon/RV630_me.bin, radeon/RV630_pfp.bin, radeon/RV610_me.bin, │ │ radeon/RV610_pfp.bin, radeon/R600_me.bin, radeon/R600_pfp.bin\nr8169: │ │ rtl8168d-2.fw, rtl8168d-1.fw │ I don't think that \n is supposed to be there. -- Package-specific info: ** Kernel log: boot messages should be attached ** Model information not available ** PCI devices: 00:00.0 Host bridge [0600]: VIA Technologies, Inc. VT82C693A/694x [Apollo PRO133x] [1106:0691] (rev c4) Subsystem: ASUSTeK Computer Inc. Device [1043:8038] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort+ SERR- PERR+ INTx- Latency: 0 Region 0: Memory at fc00 (32-bit, prefetchable) [size=32M] Capabilities: access denied Kernel driver in use: agpgart-via 00:01.0 PCI bridge [0604]: VIA Technologies, Inc. VT82C598/694x [Apollo MVP3/Pro133x AGP] [1106:8598] (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort+ SERR- PERR- INTx- Latency: 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: d000-dfff Memory behind bridge: de80-dfdf Prefetchable memory behind bridge: e000-fbff Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- BridgeCtl: Parity- SERR- NoISA- VGA+ MAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: access denied 00:04.0 ISA bridge [0601]: VIA Technologies, Inc. VT82C686 [Apollo Super South] [1106:0686] (rev 40) Subsystem: ASUSTeK Computer Inc. Device [1043:8038] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 Capabilities: access denied Kernel driver in use: parport_pc 00:04.1 IDE interface [0101]: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE [1106:0571] (rev 06) (prog-if 8a [Master SecP PriP]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 32 Region 0: [virtual] Memory at 01f0 (32-bit, non-prefetchable) [size=8] Region 1: [virtual] Memory at 03f0 (type 3, non-prefetchable) [size=1] Region 2: [virtual] Memory at 0170 (32-bit, non-prefetchable) [size=8] Region 3: [virtual] Memory at 0370 (type 3, non-prefetchable) [size=1] Region 4: I/O ports at b800 [size=16] Capabilities: access denied Kernel driver in use: VIA_IDE 00:04.2 USB Controller [0c03]: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller [1106:3038] (rev 16) (prog-if 00 [UHCI]) Subsystem: First International Computer, Inc. VA-502 Mainboard [0925:1234] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 32, Cache Line Size: 32 bytes Interrupt: pin D routed to IRQ 10 Region 4: I/O ports at b400 [size=32] Capabilities: access denied Kernel driver in use: uhci_hcd 00:04.3 USB Controller [0c03]: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller [1106:3038] (rev 16) (prog-if 00 [UHCI]) Subsystem: First International Computer, Inc. VA-502 Mainboard [0925:1234] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 32, Cache Line Size: 32 bytes Interrupt: pin D routed to IRQ 10 Region 4: I/O ports at b000 [size=32]
Bug#563453:
I too was hit by this change in bash 4.1, however, it is not a bug in bash but rather a bug in the script. Compare bash against ksh or zsh, for instance, and you'll see that 4.1 is now in step with those shells. I have not located the relevant specs, but given that this was an explicit and documented change, I suspect it's a compliance fix in bash, rather than just an arbitrary change. In the bash NEWS files we see: j. The [[ and (( commands are now subject to the setting of `set -e' and the ERR trap. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#564160: python-beautifulsoup: Consider permanently downgrading to 3.0.8
Package: python-beautifulsoup Version: 3.1.0.1-2 Severity: normal Per the author's discussion at http://www.crummy.com/software/BeautifulSoup/3.1-problems.html, it might be seriously worth considering not even distributing the 3.1.0 series at this point in time. It seems pretty significantly broken at this time, and may end up being the cause of more problems than solving. It might be less overall effort to not upgrade than it would be to have every user of the package pin it to an earlier version. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.30-2-686 (SMP w/2 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 python-beautifulsoup depends on: ii python2.5.4-5An interactive high-level object-o ii python-support1.0.6 automated rebuilding support for P python-beautifulsoup recommends no packages. python-beautifulsoup suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541296: migrationtools: migrate_services.pl generates invalid entry for tcp/udp echo
On Wed, Aug 12, 2009 at 10:18:30PM -0700, Mike Castle wrote: Severity: grave Justification: causes non-serious data loss Incorrect: No data was actually *lost*, right? I think it's correct. After all the definition is: 'causes non-serious data loss', causes the loss of data on the system that is unimportant, or restorable without resorting to backup media Granted, I ran migrationtools once, two years ago. And now, trying to upgrade slapd caused there to be no ldap server running, because the data is invalid. As a result, I ended up with an ldap server with no data in it. Seemed lost to me. Sure, it was there in /var/backups. But it did involve a restore process that seems to imply the final clause there. If this option: 'renders package unusable', renders the package unusable, or mostly so, on all or nearly all possible systems on which it could be installed (i.e., not a hardware-specific bug); or renders package uninstallable or unremovable without special effort read something: 'renders OTHER package unusable' I probably would have chosen that as an option. At any rate, making it impossible to log into a system as a normal user does seem a grave error. The fix for bug#307618 actually introduced another issue. Any system that used migrationtools to load services will be unable to upgrade to slapd 2.4.17-1 (actually, anything newer than 2.4.15). Reference bug#541292 for details. But essentially, `cn=echo+ipServiceProtocol=tcp+ipServiceProtocol=udp' is an illegal value. At first glance, it seems that replacing the + with _ allows the file to load, but I'm not sure if that's sufficient for everything to work properly. I don't know if this dn: is used or just needs to be unique. In principle they are unique, but I suspect that most users of migrationtools won't actually use that data. I will simply disable that patch for now, and leave it to the user to decide if they want to a) use only some of the scripts og b) force-load with the result that tcp and udp entries are merged. A force load that results in the same string will never work in the long run. Better to give them the ability to have a valid string. Maybe instead of `+' use `_and_' ? mrc -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541292: slapd: Upgrade to 2.4.17-1 fails if migrationtools have been used.
Package: slapd Version: 2.4.17-1 Severity: important This bug is about 2.4.17-1, which I no longer have installed. I had to downgrade back to 2.4.11-1 for the time being. When I originally migrated to LDAP some time ago, I made use of migrationtools to move /etc files into LDAP. Specifically, I ran /usr/share/migrationtools/migrate_all_online.sh. This has survived numerous slapd upgrades until I tried to do 2.4.17-1 which failed with: Installing new version of config file /etc/default/slapd ... Backing up /etc/ldap/slapd.conf in /var/backups/slapd-2.4.11-1... done. Moving old database directories to /var/backups: - directory dc=mrc,dc=home... done. Loading from /var/backups/slapd-2.4.11-1: - directory dc=mrc,dc=home... failed. Loading the database from the LDIF dump failed with the following error while running slapadd: str2entry: entry -1 has invalid DN cn=echo+ipServiceProtocol=tcp+ipServiceProtocol=udp,ou=Services,dc=mrc,dc=home slapadd: could not parse entry (line=1673) dpkg: error processing slapd (--configure): subprocess installed post-installation script returned error exit status 1 The stanza in the ldif file reads: dn: cn=echo+ipServiceProtocol=tcp+ipServiceProtocol=udp,ou=Services,dc=mrc,dc= home objectClass: ipService objectClass: top ipServicePort: 7 ipServiceProtocol: udp ipServiceProtocol: tcp cn: echo structuralObjectClass: ipService entryUUID: 0a564566-b013-102b-82f8-250058e72771 creatorsName: cn=admin,dc=mrc,dc=home createTimestamp: 20070616050609Z entryCSN: 20070616050609.00Z#79#000#00 modifiersName: cn=admin,dc=mrc,dc=home modifyTimestamp: 20070616050609Z In building several openldap versions by hand and running slapadd with a custom config file, it appears that this was introduced with 2.4.15. I don't know LDAP well enough to know if this was a regression or a tightening down to be more inline with specs. If the latter, then migrationtools should probably be fixed. This may be related to ITS#5959 (though that's just a guess). I'm not sure how to proceed, but I imagine I will change the cn= to be `echo'. At the very least, by now having this bug filed, hopefully this particular error condition will now show up on searches. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.26-2-686 (SMP w/2 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 slapd depends on: ii adduser 3.110 add and remove users and groups ii coreutils 7.4-2 The GNU core utilities ii debconf [debconf-2.0] 1.5.27 Debian configuration management sy ii libc6 2.9-23 GNU C Library: Shared libraries ii libdb4.2 4.2.52+dfsg-5 Berkeley v4.2 Database Libraries [ ii libgnutls26 2.6.6-1the GNU TLS library - runtime libr hi libldap-2.4-2 2.4.11-1 OpenLDAP libraries ii libltdl3 1.5.26-4 A system independent dlopen wrappe ii libperl5.10 5.10.0-24 Shared Perl library ii libsasl2-22.1.23.dfsg1-1 Cyrus SASL - authentication abstra ii libslp1 1.2.1-7.6 OpenSLP libraries ii libwrap0 7.6.q-18 Wietse Venema's TCP wrappers libra ii perl [libmime-base64-perl 5.10.0-24 Larry Wall's Practical Extraction ii psmisc22.8-1 utilities that use the proc file s ii unixodbc 2.2.11-16+b1 ODBC tools libraries Versions of packages slapd recommends: ii libsasl2-modules 2.1.23.dfsg1-1 Cyrus SASL - pluggable authenticat Versions of packages slapd suggests: hi ldap-utils2.4.11-1 OpenLDAP utilities -- debconf information: slapd/password_mismatch: slapd/tlsciphersuite: * slapd/invalid_config: true * shared/organization: dc=mrc,dc=home slapd/upgrade_slapcat_failure: slapd/slurpd_obsolete: * slapd/backend: HDB slapd/dump_database: when needed * slapd/allow_ldap_v2: false * slapd/no_configuration: false slapd/move_old_database: true slapd/suffix_change: false slapd/dump_database_destdir: /var/backups/slapd-VERSION * slapd/purge_database: true * slapd/domain: mrc.home -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541296: migrationtools: migrate_services.pl generates invalid entry for tcp/udp echo
Package: migrationtools Version: 47-6 Severity: grave Justification: causes non-serious data loss The fix for bug#307618 actually introduced another issue. Any system that used migrationtools to load services will be unable to upgrade to slapd 2.4.17-1 (actually, anything newer than 2.4.15). Reference bug#541292 for details. But essentially, `cn=echo+ipServiceProtocol=tcp+ipServiceProtocol=udp' is an illegal value. At first glance, it seems that replacing the + with _ allows the file to load, but I'm not sure if that's sufficient for everything to work properly. I don't know if this dn: is used or just needs to be unique. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.26-2-686 (SMP w/2 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 migrationtools depends on: hi ldap-utils [openldap-utils] 2.4.11-1 OpenLDAP utilities ii perl 5.10.0-24 Larry Wall's Practical Extraction migrationtools recommends no packages. Versions of packages migrationtools suggests: hi slapd 2.4.11-1 OpenLDAP server (slapd) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541292: migrationtools
So, it turns out that the problem is from a Debian specific fix to migrationtools. Reference bug#307618 . It turns out that there is already another service entry for `cn=echo', that's why this one is mangled into `cn=echo+ipServiceProtocol=tcp+ipServiceProtocol=udp'. I've filed a new bug against migrationtools to hopefully prevent further injury: bug#541296. But in the meantime, what can we do about existing installations? Since this error was introduced by a Debian specific fix, should there be a Debian specific work around in the upgrade scripts to try to detect this issue? Either explicitly say something like ``Hey, this is broken and won't work. See this wiki entry for details,'' or try to fix it during the upgrade? Or at least a mention in a README.Debian file? According to popcon, it appears that migrationtools is installed on about 1/8th of the number of machines that slapd is installed on (I'm guessing that there are few installation with migrationtools without slapd). Since nothing seems to explicitly depend on migrationtools, and there is not much reason to install it unless it's going to be used, then it seems that, maybe, about 12% of the slapd users will be affected by this problem in the future. That's a pretty good chunk of users. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#509650: alsa-utils: typo in alsaconf startup screen
Package: alsa-utils Version: 1.0.16-2 Severity: minor s/suopported/supported/ -- System Information: Debian Release: 5.0 APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages alsa-utils depends on: ii dialog1.1-20080316-1 Displays user-friendly dialog boxe ii libasound21.0.16-2 ALSA library ii libc6 2.7-16 GNU C Library: Shared libraries ii libncurses5 5.6+20080830-2 shared libraries for terminal hand ii linux-sound-base 1.0.17.dfsg-4 base package for ALSA and OSS soun ii lsb-base 3.2-20 Linux Standard Base 3.2 init scrip ii module-init-tools 3.4-1 tools for managing Linux kernel mo ii pciutils 1:3.0.0-6 Linux PCI Utilities ii python2.5.2-3An interactive high-level object-o ii whiptail 0.52.2-11.3Displays user-friendly dialog boxe Versions of packages alsa-utils recommends: ii alsa-base 1.0.17.dfsg-4 ALSA driver configuration files alsa-utils suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#507225: libldap-2.4-2: /etc/ldap/ldap.conf went missing during install
Package: libldap-2.4-2 Version: 2.4.11-1 Severity: grave Justification: renders package unusable After installation, it was noticed that /etc/ldap/ldap.conf was missing. dpkg -L libldap-2.4-2 did not display the file, however, dpkg -c on the original .deb does show it present. dpkg -i fixed it. This was a fresh install done via a slightly older business card install. I first installed just a base system, even deselecting the desktop task. I have a set of personal .debs that I use for specifying dependencies during installation that I prefer to use. It was noticed that autofs-ldap's /etc/ldap/schema/autofs.schema was successfully installed. I was just reviewing /var/log/dpkg.log and noticed that the initial installation installed both libldap-2.4-2 AND libldap2. Later, when I purge unwanted packages via dselect, apparently libldap2 was removed, which appears to have caused /etc/ldap/ldap.conf to disappear. This seems like a problematic configuration to allow. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libldap-2.4-2 depends on: ii libc62.7-16 GNU C Library: Shared libraries ii libgnutls26 2.4.2-3 the GNU TLS library - runtime libr ii libsasl2-2 2.1.22.dfsg1-23 Cyrus SASL - authentication abstra libldap-2.4-2 recommends no packages. libldap-2.4-2 suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#412989: please add users and groups referenced by default udev configuration
I'm new to Debian, and newer still to setting up LDAP at home. I was disheartened, when researching this problem, to find out that this is still a bug after 1.5 years. Right now there are five user/group references in udev that don't exist as part of the main system. They are, and come from: group rdma from package libibverbs group nvram from UNKNOWN group fuse from fuse-utils group kvm from kvm user tss group tss from trousers (I couldn't figure out what package adds nvram, and wonder if it is actually still necessary.) So, hows this for a suggestion: We remove those references from 91-permissions.rules and create five new packages, named something like: udev-$GROUP It would Depend on udev and only contain one file of real interest: /etc/udev/rules.d/91-permissions-$GROUP.rules Each of the the packages that actually adds the group could Recommend udev-$GROUP That way, if someone is trying to run a system without udev, they could still do so, and wouldn't need to install the supplemental packages. If Debian packaging supports a (if udev installed, Depend on udev-$GROUP) that would be even better, but I don't think it does. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#473010: Also happens with x-window-manage
When looking for temporary ways around this bug, I tried x-window-manage and got the same error: fvwm2[29972]: segfault at 0004 eip 0808517e esp bf8a1800 error 4 x-window-manage[30152]: segfault at 0004 eip 0808517e esp bfaba1f0 error 4 So I suspect a shared library issue. I've ended up using something like: fvwm | twm as a work around until this is fixed. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
