Bug#811318: pyroman: Pyroman not started by systemd (included fix).
Package: pyroman Version: 0.5.0-1 Severity: normal Dear Maintainer, Upgrading from previous stable to jessie, I found that the pryoman command was not called on startup by systemd. The issue is easy to see with $ systemctl cat pyroman # /lib/systemd/system/pyroman.service # # Pyroman Firewall # [Unit] Description=Pyroman firewall DefaultDependencies=no After=systemd-modules-load.service network-pre.target Before=network.target Wants=network-pre.target [Service] Type=oneshot RemainAfterExit=yes StandardOutput=syslog EnvironmentFile=/etc/default/pyroman ExecStartPre=/bin/sh -c '[ "$PYROMAN_ENABLED" = "y" ]' ExecStart=/usr/sbin/pyroman --init [Install] WantedBy=multi-user.target.wants The last line WantedBy is not correct since it should be set to multi-user.target, and I don't think I edited it by any ways. I have to systemctl disable pyroman && systemctl enable pyroman to make it work again. Note: I think that this bug should be tagged as important since on a computer like the one that use pyroman, not having it started is a major failure !!!. Anyway, I let the maintainer change it if needed, because I guess that the initV script is fully working. 2nd Note: I don't know why the 02_*.py and 05_*.py were not installed nor notified during the install process. Perhaps because it was already installed ? Best regards, Caeies. -- System Information: Debian Release: 8.2 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i586) Kernel: Linux 3.16.0-4-586 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages pyroman depends on: ii iptables 1.4.21-2+b1 ii python2.7.9-1 pyroman recommends no packages. pyroman suggests no packages. -- Configuration Files: /etc/default/pyroman changed [not included] /etc/pyroman/02_icmp-essentials.py c04ce4a2af6794b2cdd524e3bb09fcab [Errno 2] No such file or directory: u'/etc/pyroman/02_icmp-essentials.py c04ce4a2af6794b2cdd524e3bb09fcab' /etc/pyroman/05_scan_block.py 7c711d1ba7cdf046194dd8e4a762120f [Errno 2] No such file or directory: u'/etc/pyroman/05_scan_block.py 7c711d1ba7cdf046194dd8e4a762120f' /etc/pyroman/10_interfaces.py changed [not included] /etc/pyroman/25_networks.py changed [not included] -- no debconf information
Bug#568519: [pkg-lighttpd] Bug#568519: lighttpd fails proxy connections when upgraded to 1.4.13-4etch12
Olaf van der Spek a écrit : > On Wed, Jun 9, 2010 at 1:26 PM, Benoit Hamet > wrote: >> Version: 1.4.13-4etch12 >> Severity: normal > > Both Etch and 1.4.13 are quite old. Isn't it time to upgrade? If I've got time to upgrade yes, but ... 1 ) This is production servers 2 ) there's a lot's of machine to upgrade 3 ) it (was) run(ning) very well ... ... So having a security update not breaking our whole servers could be great :/. Sorry for that. Regards, Benoît. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#568519: lighttpd fails proxy connections when upgraded to 1.4.13-4etch12
Version: 1.4.13-4etch12 Severity: normal We are using the same configuration than the one described in this bug report (https reverse proxy, with apache2 doing the ssl proxying). the 1.4.13-4etch11 was working fine, but 1.4.13-4etch12 is failing. No logs in lighttpd, a netstat show that apache2 proxy is trying to connect to the server, but it's timing out with the same message in apache2 logs. I guess that the problem comes from : - Fix denial of service through slow short requests leading to memory exhaustion due to bad memory handling (CVE-2010-0295). I have tried to do the reverse without ssl, and things looks working (but that's not an option in our case). So why ssl + this fix is not working ? Regards. Benoît. -- System Information: Debian Release: 4.0 APT prefers oldstable APT policy: (500, 'oldstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-6-amd64 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages lighttpd depends on: ii libattr1 2.4.32-1 Extended attribute shared library ii libbz2-1.01.0.3-6high-quality block-sorting file co ii libc6 2.3.6.ds1-13etch10 GNU C Library: Shared libraries ii libldap2 2.1.30-13.3OpenLDAP libraries ii libpcre3 6.7+7.4-4 Perl 5 Compatible Regular Expressi ii libssl0.9.8 0.9.8c-4etch9 SSL shared libraries ii lsb-base 3.1-23.2etch1 Linux Standard Base 3.1 init scrip ii mime-support 3.39-1 MIME files 'mime.types' & 'mailcap ii zlib1g1:1.2.3-13 compression library - runtime Versions of packages lighttpd recommends: ii php5-cgi 5.2.0+dfsg-8+etch16 server-side, HTML-embedded scripti -- 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#555325: version 1.3.4 completely unusable
Package: gq Version: 1.3.4-1 > > Same as the first reporter. Just update gq yesterday in sid. it's totaly > unusable. > I'm trying to connect via ssl, I never find how to successfully do it. > ldapsearch is working smoothly, not gq. > > I can provide some backtrace of gtk backtraces produced under gdb. > > I confirm that the dn is forget evry time. > The port for ssl is not usuable in the old gq in host field I put before > : > ldaps://10.42.42.1/ and remove the port entry and it was working. > > Now, triggers a lot's of assert. > > I have tried with a LANG=C thinking of a problem with utf8 ... but > doens't seems to work better. > > Some time I've got random data in the dn field, making me thinking of a > buffer not rightly initialized or something like that. I just do a test using valgrind ... invalid read of already free'd memory ... so invalid pointers are there. Backtrace is not really usable ... : (one sample on 11). This happens when opening the preference box, then the local machine one. ==367==by 0x439DFA: ??? (in /usr/bin/gq) ==367==by 0x452178: ??? (in /usr/bin/gq) ==367==by 0x723F8FC: g_object_newv (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x72401AA: g_object_new_valist (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x72403FB: g_object_new (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x43AA38: ??? (in /usr/bin/gq) ==367==by 0x453E00: ??? (in /usr/bin/gq) ==367==by 0x72393EC: g_closure_invoke (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x724CCDA: ??? (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x724E081: g_signal_emit_valist (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x724E552: g_signal_emit (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x52E7D54: ??? (in /usr/lib/libgtk-x11-2.0.so.0.1800.4) ==367==by 0x72393EC: g_closure_invoke (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x724C5EB: ??? (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x724E081: g_signal_emit_valist (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x724E552: g_signal_emit (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x52E6A1C: ??? (in /usr/lib/libgtk-x11-2.0.so.0.1800.4) ==367==by 0x53973B7: ??? (in /usr/lib/libgtk-x11-2.0.so.0.1800.4) ==367==by 0x72393EC: g_closure_invoke (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x724C9C8: ??? (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x724DF17: g_signal_emit_valist (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x724E552: g_signal_emit (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x54A05AD: ??? (in /usr/lib/libgtk-x11-2.0.so.0.1800.4) ==367==by 0x538F972: gtk_propagate_event (in /usr/lib/libgtk-x11-2.0.so.0.1800.4) ==367==by 0x5390A4A: gtk_main_do_event (in /usr/lib/libgtk-x11-2.0.so.0.1800.4) ==367==by 0x58BC35B: ??? (in /usr/lib/libgdk-x11-2.0.so.0.1800.4) ==367==by 0x76AF139: g_main_context_dispatch (in /lib/libglib-2.0.so.0.2200.3) ==367==by 0x76B2997: ??? (in /lib/libglib-2.0.so.0.2200.3) ==367==by 0x76B2E6C: g_main_loop_run (in /lib/libglib-2.0.so.0.2200.3) ==367==by 0x5390E46: gtk_main (in /usr/lib/libgtk-x11-2.0.so.0.1800.4) ==367==by 0x421747: ??? (in /usr/bin/gq) ==367==by 0x8574ABC: (below main) (libc-start.c:222) ==367== Address 0xd412c10 is 0 bytes inside a block of size 35 free'd ==367==at 0x4C21DBC: free (vg_replace_malloc.c:325) ==367==by 0x4380AC: ??? (in /usr/bin/gq) ==367==by 0x72393EC: g_closure_invoke (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x724CCDA: ??? (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x724E081: g_signal_emit_valist (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x724E552: g_signal_emit (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x723D5F8: ??? (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x723C7E4: ??? (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x723C94A: g_object_thaw_notify (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x531B9CE: ??? (in /usr/lib/libgtk-x11-2.0.so.0.1800.4) ==367==by 0x531CE4B: gtk_entry_set_text (in /usr/lib/libgtk-x11-2.0.so.0.1800.4) ==367==by 0x439866: ??? (in /usr/bin/gq) ==367==by 0x439DFA: ??? (in /usr/bin/gq) ==367==by 0x452178: ??? (in /usr/bin/gq) ==367==by 0x723F8FC: g_object_newv (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x72401AA: g_object_new_valist (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x72403FB: g_object_new (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x43AA38: ??? (in /usr/bin/gq) ==367==by 0x453E00: ??? (in /usr/bin/gq) ==367==by 0x72393EC: g_closure_invoke (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x724CCDA: ??? (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x724E081: g_signal_emit_valist (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==by 0x724E552: g_signal_emit (in /usr/lib/libgobject-2.0.so.0.2200.3) ==367==b
Bug#555325: version 1.3.4 completely unusable
Package: gq Version: 1.3.4-1 Severity: grave Hi all, Same as the first reporter. Just update gq yesterday in sid. it's totaly unusable. I'm trying to connect via ssl, I never find how to successfully do it. ldapsearch is working smoothly, not gq. I can provide some backtrace of gtk backtraces produced under gdb. I confirm that the dn is forget evry time. The port for ssl is not usuable in the old gq in host field I put before : ldaps://10.42.42.1/ and remove the port entry and it was working. Now, triggers a lot's of assert. I have tried with a LANG=C thinking of a problem with utf8 ... but doens't seems to work better. Some time I've got random data in the dn field, making me thinking of a buffer not rightly initialized or something like that. Got no time atm to track this bug deeply. I can help if somebody want to test things. Regards, Benoît. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.31-1-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gq depends on: ii libatk1.0-0 1.28.0-1 The ATK accessibility toolkit ii libc6 2.10.2-2 GNU C Library: Shared libraries ii libcairo2 1.8.8-2 The Cairo 2D vector graphics libra ii libfontconfig1 2.6.0-4 generic font configuration library ii libfreetype62.3.11-1 FreeType 2 font engine, shared lib ii libglade2-0 1:2.6.4-1library to load .glade files at ru ii libglib2.0-02.22.3-1 The GLib library of C routines ii libgnome-keyring0 2.28.1-2 GNOME keyring services library ii libgtk2.0-0 2.18.4-1 The GTK+ graphical user interface ii libldap-2.4-2 2.4.17-2.1 OpenLDAP libraries ii libpango1.0-0 1.26.1-1 Layout and rendering of internatio ii libssl0.9.8 0.9.8k-7 SSL shared libraries ii libxml2 2.7.6.dfsg-1 GNOME XML library gq recommends no packages. gq 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#510658: postgresql-8.3: Requested infos by Martin.
Package: postgresql-8.3 Version: 8.3.6-1 Followup-For: Bug #510658 Hi all, Same bug here, installed machine 2 weeks ago, but only using the posgresql data base today : Was a beta2 netinstall, choosing the package with database task. here's the output requested by Martin : $ ls -lR /etc/postgresql /var/lib/postgresql /var/log/postgresql /etc/postgresql: total 0 /var/lib/postgresql: total 0 /var/log/postgresql: total 0 $ pg_lsclusters Version Cluster Port Status OwnerData directory Log file So nothing was created. I try the /etc/init.d/posgresql start trick, but doesn't work. Try to reconfigure it without success. So will now purge it and reinstall. I can probably help a little bit on that one, since I have planned to do some other lenny install on amd64. Hope this help anyway. Regards, Caeies. -- System Information: Debian Release: 5.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages postgresql-8.3 depends on: ii libc6 2.7-18 GNU C Library: Shared libraries ii libcomerr21.41.3-1 common error description library ii libkrb53 1.6.dfsg.4~beta1-5 MIT Kerberos runtime libraries ii libldap-2.4-2 2.4.11-1 OpenLDAP libraries ii libpam0g 1.0.1-5Pluggable Authentication Modules l ii libpq58.3.6-1PostgreSQL C client library ii libssl0.9.8 0.9.8g-15 SSL shared libraries ii libxml2 2.6.32.dfsg-5 GNOME XML library ii locales 2.7-18 GNU C Library: National Language ( ii postgresql-client-8.3 8.3.6-1front-end programs for PostgreSQL ii postgresql-common 94lenny1 PostgreSQL database-cluster manage ii ssl-cert 1.0.23 simple debconf wrapper for OpenSSL ii tzdata2008h-2time zone and daylight-saving time postgresql-8.3 recommends no packages. Versions of packages postgresql-8.3 suggests: pn oidentd | ident-server (no description available) -- 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#500112: grub-pc: grub is failing to start at boot (go to rescue mode immediately) when using jfs.mod (prefix issue)
Hi again, >> This was already discussed and solved upstream some time ago. In >> short : >> when using grub-pc with the jfs file system, grub fails when starting >> and fallback in the rescue mode. This is due to a bug (AFAIK) in the >> jfs way of treating trailing / >> A possible workaround is to remove the ending / in the grub-install >> script, when building the command line of grub-mkpackage --prefix=...' > > I do remember talking about this with Robert, but in the context of a > cosmetical problem not about JFS and I haven't found anything yet on the > grub-devel archives. > >> IIRC the experimental package solve this problem (20080831). > > Yes it does, Robert commited this `workaround' on 2008-08-02 upstream. > So closing the report then, it'll go to unstable after lenny is > released. This doestn't seem that important for me to fix it for lenny. Hmm, perhaps it wasn't clear, but this render the booting on jfs partition unable to work ... in case of remote server, it could be problematic ... so I don't see why waiting for lenny release, since this will probably be reopened when servers will use lenny in production (ok, they're probably not using grub2 ?). Anyway, do whatever you want, I fixed my own grub-install, hope that nobody else will hit this one :). > > Feel free to bring that double slash problem with JFS up again upstream > on [EMAIL PROTECTED] if it's still a more general problem. for me it's working in new releases, so no needs to bring this up upstream. Regards, Benoît. PS: is it normal to only receive close notification and not the discussions on the bug ? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#500112: grub-pc: grub is failing to start at boot (go to rescue mode immediately) when using jfs.mod (prefix issue)
Package: grub-pc Version: 1.96+20080724-10 Severity: normal Hi all, This was already discussed and solved upstream some time ago. In short : when using grub-pc with the jfs file system, grub fails when starting and fallback in the rescue mode. This is due to a bug (AFAIK) in the jfs way of treating trailing / A possible workaround is to remove the ending / in the grub-install script, when building the command line of grub-mkpackage --prefix=...' IIRC the experimental package solve this problem (20080831). Regards, Benoit. -- Package-specific info: *** BEGIN /proc/mounts /dev/hda1 / jfs rw 0 0 *** END /proc/mounts *** BEGIN /boot/grub/device.map (hd0) /dev/hda *** END /boot/grub/device.map *** BEGIN /boot/grub/grub.cfg # # DO NOT EDIT THIS FILE # # It is automatically generated by /usr/sbin/update-grub using templates # from /etc/grub.d and settings from /etc/default/grub # ### BEGIN /etc/grub.d/00_header ### set default=0 set timeout=5 serial -s 57600 terminal serial ### END /etc/grub.d/00_header ### ### BEGIN /etc/grub.d/05_debian_theme ### set menu_color_normal=cyan/blue set menu_color_highlight=white/blue ### END /etc/grub.d/05_debian_theme ### ### BEGIN /etc/grub.d/10_hurd ### ### END /etc/grub.d/10_hurd ### ### BEGIN /etc/grub.d/10_linux ### set root=(hd0,1) menuentry "Debian GNU/Linux, linux 2.6.26-1-486" { linux /boot/vmlinuz-2.6.26-1-486 root=/dev/hda1 ro novga nofb console=ttyS0,57600n8,nomonitor acpi=off initrd /boot/initrd.img-2.6.26-1-486 } menuentry "Debian GNU/Linux, linux 2.6.26-1-486 (single-user mode)" { linux /boot/vmlinuz-2.6.26-1-486 root=/dev/hda1 ro single novga nofb console=ttyS0,57600n8,nomonitor acpi=off initrd /boot/initrd.img-2.6.26-1-486 } ### END /etc/grub.d/10_linux ### ### BEGIN /etc/grub.d/30_os-prober ### ### END /etc/grub.d/30_os-prober ### ### BEGIN /etc/grub.d/40_custom ### # This file is an example on how to add custom entries ### END /etc/grub.d/40_custom ### *** END /boot/grub/grub.cfg -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i586) Kernel: Linux 2.6.26-1-486 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 grub-pc depends on: ii debconf [debconf-2.0] 1.5.22 Debian configuration management sy ii grub-common 1.96+20080724-10 GRand Unified Bootloader, version ii libc6 2.7-13 GNU C Library: Shared libraries ii liblzo2-2 2.03-1 data compression library ii libncurses5 5.6+20080830-1 shared libraries for terminal hand grub-pc recommends no packages. Versions of packages grub-pc suggests: pn desktop-base (no description available) pn os-prober (no description available) -- debconf information: * grub-pc/chainload_from_menu.lst: true grub-pc/linux_cmdline: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#428791: if it was the only conflicts !
Hi, Sorry for reoppening this bug, but there's others conflicts that your message doesn't seems to fix, so ... with : icedax for cdda2ogg : dpkg : erreur de traitement de /var/cache/apt/archives/dvdrtools_0.3.1-2_amd64.deb (--unpack) : tentative de remplacement de « /usr/bin/cdda2ogg », qui appartient aussi au paquet icedax dpkg-deb: sous-processus paste tué par le signal (Relais brisé (pipe)) Des erreurs ont été rencontrées pendant l'exécution : /var/cache/apt/archives/dvdrtools_0.3.1-2_amd64.deb E: Sub-process /usr/bin/dpkg returned an error code (1) for genisoimage : dpkg : erreur de traitement de /var/cache/apt/archives/dvdrtools_0.3.1-2_amd64.deb (--unpack) : tentative de remplacement de « /usr/bin/devdump », qui appartient aussi au paquet genisoimage dpkg-deb: sous-processus paste tué par le signal (Relais brisé (pipe)) Des erreurs ont été rencontrées pendant l'exécution : /var/cache/apt/archives/dvdrtools_0.3.1-2_amd64.deb E: Sub-process /usr/bin/dpkg returned an error code (1) etc ... so please, make a clean package :). Regards, Caeies.
Bug#400630: confirmation of the bug on AMD64
Hi all, it seems that a reboot (due to a power failure) and this morning update solve the problem ... Don't know what was happening, perhaps some hidden dependancy ? Regards, Benoît.
Bug#400630: confirmation of the bug on AMD64
Hi all, I got the same problem here on debian AMD64. No Menu, no Strings, no tabs it's totaly unusable :... Any idea on what's wrong ? I try to add packages for french things etc ... but nothing better. Removing the .mozilla didn't help. Regards. Benoît.
Bug#373899: confirmation of the problem
Hi all, I got the same problem here. But there's not the only one (the UID / GID problem). The uri of the device is no more usb:/dev/usb/lp0 as It was in previous configuration, but usb://Samsung/ML-1610 for example ... The usb backend give this url when running without arguments ... I solve the problem by chown lp.lp the dev/usb/lp0 as a short time solution regarding rights issues ... Hope this help Regards, Benoît
Bug#365064: fluxbox: I confirm this problem on AMD64
Package: fluxbox Version: 0.9.14-1.2 Followup-For: Bug #365064 Hi all, Just for a confirmation of this bug. I was first thinking that it was my fault since it's occurs only some times. Typically I notice the problem after returning from Xscreensaver session, and lose the Double-Clic shade window behavior ... Now even if I restart the computer, it doesn't work at all (it was solving the problem before). Hope a quick solution, since it's very difficult to work without it ;) Regards, Benoît. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-2-amd64-k8 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages fluxbox depends on: ii libc62.3.6-10GNU C Library: Shared libraries ii libfontconfig1 2.3.2-5.1 generic font configuration library ii libgcc1 1:4.1.0-4 GCC support library ii libice6 1:1.0.0-3 X11 Inter-Client Exchange library ii libsm6 1:1.0.0-4 X11 Session Management library ii libstdc++6 4.1.0-4 The GNU Standard C++ Library v3 ii libx11-6 2:1.0.0-6 X11 client-side library ii libxext6 1:1.0.0-4 X11 miscellaneous extension librar ii libxft2 2.1.8.2-8 FreeType-based font drawing librar ii libxinerama1 1:1.0.1-4 X11 Xinerama extension library ii libxpm4 1:3.5.4.2-3 X11 pixmap library ii libxrandr2 2:1.1.0.2-4 X11 RandR extension library ii libxrender1 1:0.9.0.2-4 X Rendering Extension client libra ii menu 2.1.27 generates programs menu for all me fluxbox recommends no packages. -- no debconf information
Bug#349367: libpam-encfs: wrong behavior if a user don't have an encrypted home, directory + some remarks (patch included)
Hi Ruben, Ruben Porras wrote: >>Anyway, here's the steps to reproduce : > > [...] > >>So here is a possible security hole : if you want that somebody without >>an encrypted home dir, shouldn't login, then he can ... aïe. > > > No, that was not the intended behaviour, everybody should be able to > login. Ok, nice. > >>I wrote the patch attached to partialy correct this behavior : at least >>evrybody with or without an encrypted home dir will be able to log in. > > > I think this is fixed in the new version uploaded yesterday to unstable. > Can you check that? > Looks like I agree with you :). > > >>I take the time to correct some warnings (not all, but most of them) >> too. >> >>Ok, back to the default conf file : why the maintainer let it's user >>name in the file ??? (and not commented). > > > why not? Anyway, the example has now a generic "user" and commented. Just imagine a devil admin having a user with the same login as yourself and using libpam-encfs ... people will don't understand why they cannot login (due to the default behavior of encfs, which create the encryption if no .encfs5 is found (but that's another problem)). > > >>I suggest too, to put somewhere that the password for the encfs >>NEED to be the SAME as the unix login ... that's a serious weakness in >>my mind ... if somebody was able to crack the login password, it could >>read the encrypted data's ... So in the same time, I suggest to put a >>warning, to explain that you need to put the .encfs5 on another device >>like an USBkey + automount it for reading this file (a link from >>/home/.enc/encrypt/.encfs5 to /var/autofs/removable/uba/encfs5, could be >>a start for a better security) NOTE : this can't work with actual code. > > > This is not addressed in the last upload, neither the other fixes unless > upstream has fixed them (which did with a couple of them). So, if you > agree with me that the main issue is solved, we can downgrade this bug. Yes, no problem with that. Just to let you know, you will need to "fix" encfs to get this working (at least the encfs in testing) since a lstat is done and not a stat (I guess that's not a mistake, but I'm still trying to understand why using lstat instead of stat ...). So perhaps some discussions with the encfs maintainer will be necessary. Regards, and thanks for your quick answer. Benoît. signature.asc Description: OpenPGP digital signature
Bug#349367: libpam-encfs: wrong behavior if a user don't have an encrypted home, directory + some remarks (patch included)
Package: libpam-encfs Version: 0.1.2-4 Severity: important Tags: patch Hi all, First, I wan't to say that I hesitate to put it as grave, since I think this can be a kind of security hole. But since 1) that's not a default configuration 2) not so much people use it :) (I guess, or I'm a martian using encfs the way I use it :) 3) I perhaps doesn't understand how it should work ... 4) It depends on what you want as default behavior. I only put it as important. Anyway, here's the steps to reproduce : Create a "encrypt" user, I mean with a home directory using the encfs utilities. Create a "normal" user. Config pam as specified in the README.Debian : -- 8< -- /etc/pam.d/common-auth -- 8< -- authsufficient pam_encfs.so authrequiredpam_unix.so nullok_secure use_first_pass -- 8< -- use the default configuration file /etc/pam_encfs.conf (more about this file later) Login as the normal user : it's failing complaining about not able to read /home/.enc/encrypt/.encfs5 ... then the login is waiting for creating the new encrypted dir ... so you need to Ctrl+C to try a new time ... Login as the encrypt user : ok your logged ! In another console, try to loggin as the normal user : it works ! So here is a possible security hole : if you want that somebody without an encrypted home dir, shouldn't login, then he can ... aïe. I wrote the patch attached to partialy correct this behavior : at least evrybody with or without an encrypted home dir will be able to log in. I take the time to correct some warnings (not all, but most of them) too. Ok, back to the default conf file : why the maintainer let it's user name in the file ??? (and not commented). I suggest too, to put somewhere that the password for the encfs NEED to be the SAME as the unix login ... that's a serious weakness in my mind ... if somebody was able to crack the login password, it could read the encrypted data's ... So in the same time, I suggest to put a warning, to explain that you need to put the .encfs5 on another device like an USBkey + automount it for reading this file (a link from /home/.enc/encrypt/.encfs5 to /var/autofs/removable/uba/encfs5, could be a start for a better security) NOTE : this can't work with actual code. Hope this help, I'm ok to discuss issue. Regards, Benoît. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12dsdt Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=UTF-8) Versions of packages libpam-encfs depends on: ii encfs 1.2.4.1-2 encrypted virtual filesystem ii libc6 2.3.5-8GNU C Library: Shared libraries an ii libpam0g 0.79-3 Pluggable Authentication Modules l libpam-encfs recommends no packages. -- no debconf information --- libpam-encfs-0.1.2-orig/pam_encfs.c 2006-01-22 15:14:36.0 +0100 +++ libpam-encfs-0.1.2/pam_encfs.c 2006-01-22 15:46:45.0 +0100 @@ -69,6 +69,7 @@ #include #include #include +#include #include #include @@ -173,7 +174,7 @@ } -int checkmnt(char *targetpath) { +int checkmnt(const char *targetpath) { FILE *f = setmntent("/etc/mtab", "r"); struct mntent *m; @@ -193,7 +194,7 @@ char *str; do { str = strchr(line,','); -if (str > NULL) { +if (str != NULL) { *str = ' '; } } while (str != NULL); @@ -217,7 +218,7 @@ char line[BUFSIZE]; char username[USERNAME_MAX]; int parsed; - char *tmp; + const char *tmp; // Return 1 = error, 2 = silent error (ie already mounted) @@ -262,6 +263,9 @@ // Todo check if this dir exists and give better error msg } } + else + //If we are not the right user, just read next line + continue; if (strcmp("-",targetpath) == 0) { // We do not have targetpath, construct one. @@ -355,7 +359,10 @@ int inpipe[2],outpipe[2]; rval = pam_get_user(pamh, &user, NULL); - if ((rval != PAM_SUCCESS) || (!user)) { + if (rval != PAM_SUCCESS) + return rval; + + if (!user) { _pam_log ( LOG_ERR, "can't get username: %s", pam_strerror ( pamh, rval ) ); return PAM_AUTH_ERR; } @@ -363,7 +370,7 @@ rval = pam_get_item(pamh, PAM_AUTHTOK, (const void **)(void *)&passwd); if (rval != PAM_SUCCESS) { _pam_log(LOG_ERR, "Could not retrieve user's password"); -return PAM_AUTH_ERR; +return rval; } if (!passwd) { @@ -372,7 +379,9 @@ return rval; } rval = pam_get_item(pamh, PAM_AUTHTOK, (const void **)(void *)&passwd); -if (rval != PAM_SUCCESS || passwd == NULL) { +if (rval != PAM_SUCCESS) +return rval; +if(passwd == NULL) { _pam_log(LOG_ERR, "Could not retrieve user's password"); return PAM_AUTH_ERR; } @@ -552,7 +561,7 @@ int retval; pid_t pid; const char *targetpath; -
Bug#325387: libtool: some options available in documentation are not usable under AMD64
> > So something like "libtool --mode=link gcc -all-static ..." works > as it should. But "libtool --mode=link -all-static gcc ..." does > not and maybe it should. Ok, I guess that's it ... but I guess too that the line after gcc is passed "as is" so inverting the options is not a good idea. And still guessing and perhaps wrong, the default behavior of libtool was linking with gcc so a libtool -static was working like a charm, when new version need implicit specification of "--mode=link gcc" ... Thanks for the tips ... Ok for me if you want to close it... Regards. Benoît.
Bug#307299: twiki: Confirmation of the perl taint problem by other way
Re all, Benoit Hamet wrote: > But in the same time we are not able to save attachement for the same > reason : > =Save attachment error /usr/bin/ci -q -l -m"[Here a TextArea in HTML in > a form (asking for comment ???) > > " -t-none -w"testuser" %FILENAME% > [Wed Aug 31 15:11:57 2005] upload: Insecure dependency in exec > while running with -T switch at /usr/share/perl5/TWiki.pm line > 3447. > Content-type: text/html > > Software error: > > Insecure dependency in exec while running with -T switch at > /usr/share/perl5/TWiki.pm line 3447. > When there is no comment, I'm able to save files, but if I put a comment , I get the TextArea in the error message. So this is perhaps another bug, but (I don't have to check all the wiki code :) there is 2 differents call when there is or not comment ... > I will try to use the proposed solution and report if it works. Ok, the proposed solution for the diff is working ... regards, Benoît.
Bug#307299: twiki: Confirmation of the perl taint problem by other way
Package: twiki Version: 20040902-3 Followup-For: Bug #307299 Hi all, As mentionned, the diff is failling for every Topics with the following message : Software error: Insecure dependency in exec while running with -T switch at /usr/share/perl5/TWiki.pm line 3447. But in the same time we are not able to save attachement for the same reason : =Save attachment error /usr/bin/ci -q -l -m"[Here a TextArea in HTML in a form (asking for comment ???) " -t-none -w"testuser" %FILENAME% [Wed Aug 31 15:11:57 2005] upload: Insecure dependency in exec while running with -T switch at /usr/share/perl5/TWiki.pm line 3447. Content-type: text/html Software error: Insecure dependency in exec while running with -T switch at /usr/share/perl5/TWiki.pm line 3447. I will try to use the proposed solution and report if it works. Btw, I try to save with and without comment resulting in the same problem. Unfortunately, our Wiki is internal, and we have no way to let you checking. But If you have question I will do my best to answer. Note : The wiki only permits saving Topics ... so very limited. -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.4.27-2-686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages twiki depends on: ii apache-common 1.3.33-6 support files for all Apache webse ii debconf 1.4.30.13 Debian configuration management sy ii libalgorithm-diff-perl1.19.01-1 a perl library for finding Longest ii libdigest-sha1-perl 2.10-1 NIST SHA-1 message digest algorith ii libtext-diff-perl 0.35-2 Perform diffs on files and record ii perl [libmime-base64-perl]5.8.4-8Larry Wall's Practical Extraction ii perl-modules [libnet-perl]5.8.4-8Core Perl modules ii rcs 5.7-15 The GNU Revision Control System -- debconf information excluded -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#325383: Acknowledgement (libgnomevfs2-common: gnomevfs-ls report invalid file size for files > 4Gb)
Hum, sorry for the duplicate with Bug#325386, I get some problems with my mails and was thinking that the mail was not sent. Regards, Benoît. signature.asc Description: OpenPGP digital signature
Bug#325387: libtool: some options available in documentation are not usable under AMD64
Package: libtool Version: 1.5.6-6 Severity: normal Hi, I found that on AMD64 (I can't test it under other plateform) the -static and -all-static options are rejected by libtools as "unrecognized option `-static'" but libtool --help list them as valid ones ... so what happens ? regards, Benoit. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11-9-amd64-k8 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages libtool depends on: ii autotools-dev 20050803.1 Update infrastructure for config.{ ii cpp 4:4.0.1-3 The GNU C preprocessor (cpp) ii file 4.12-1 Determines file type using "magic" ii gcc [c-compiler] 4:4.0.1-3 The GNU C compiler ii gcc-3.3 [c-compiler] 1:3.3.6-9 The GNU C compiler ii gcc-3.4 [c-compiler] 3.4.4-7The GNU C compiler ii gcc-4.0 [c-compiler] 4.0.1-5The GNU C compiler ii libc6-dev [libc-dev] 2.3.5-4GNU C Library: Development Librari Versions of packages libtool recommends: ii libltdl3-dev 1.5.6-6A system independent dlopen wrappe -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#325386: libgnomevfs2-common: gnomevfs-ls report invalid file size for files > 4Gb
Package: libgnomevfs2-common Version: 2.8.4-4 Severity: minor a sample : ls -l /mnt/drive -rw-r--r-- 1 root root 5248663552 2005-07-29 12:01 sauvegarde.img -rw-r--r-- 1 root root 4133896192 2005-07-29 12:20 update.img gnomevfs-ls file://mnt/drive sauvegarde.img (Regular, application/octet-stream) size 953696256 mode 0644 update.img (Regular, application/octet-stream) size -161071104 mode 0644 (shortened for brievity) The main problem is that it seems that this is causing some apps to fail. For example gnomebaker is not able to see these files. I test gnomevfs-info and this one was working fine... regards, Benoît. -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.8-2-k7 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Versions of packages libgnomevfs2-common depends on: ii desktop-file-utils 0.10-1Utilities for .desktop files ii gconf2 2.8.1-6 GNOME configuration database syste ii gnome-mime-data2.4.2-1 base MIME and Application database ii libbonobo2-0 2.8.1-2 Bonobo CORBA interfaces library ii libbz2-1.0 1.0.2-7 high-quality block-sorting file co ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an ii libfam0c1022.7.0-6 client library to control the FAM ii libgconf2-42.8.1-6 GNOME configuration database syste ii libgcrypt111.2.0-11.1LGPL Crypto library - runtime libr ii libglib2.0-0 2.6.4-1 The GLib library of C routines ii libgnomevfs2-0 2.8.4-4 The GNOME virtual file-system libr ii libgnutls111.0.16-13.1 GNU TLS library - runtime library ii libgpg-error0 1.0-1 library for common error values an ii liborbit2 1:2.12.2-1libraries for ORBit2 - a CORBA ORB ii libpopt0 1.7-5 lib for parsing cmdline parameters ii libsmbclient 3.0.14a-3 shared library that allows applica ii libtasn1-2 0.2.10-3 Manage ASN.1 structures (runtime) ii libxml22.6.16-7 GNOME XML library ii shared-mime-info 0.16-3FreeDesktop.org shared MIME databa ii zlib1g 1:1.2.2-4.sarge.2 compression library - runtime -- no debconf information
Bug#325383: libgnomevfs2-common: gnomevfs-ls report invalid file size for files > 4Gb
Package: libgnomevfs2-common Version: 2.8.4-4 Severity: minor a sample : ls -l /mnt/drive -rw-r--r-- 1 root root 5248663552 2005-07-29 12:01 sauvegarde.img -rw-r--r-- 1 root root 4133896192 2005-07-29 12:20 update.img gnomevfs-ls file://mnt/drive sauvegarde.img (Regular, application/octet-stream) size 953696256 mode 0644 update.img (Regular, application/octet-stream) size -161071104 mode 0644 (shortened for brievity) The main problem is that it seems that this is causing some apps to fail. For example gnomebaker is not able to see these files. I test gnomevfs-info and this one was working fine... regards, Benoît. -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.8-2-k7 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Versions of packages libgnomevfs2-common depends on: ii desktop-file-utils 0.10-1Utilities for .desktop files ii gconf2 2.8.1-6 GNOME configuration database syste ii gnome-mime-data2.4.2-1 base MIME and Application database ii libbonobo2-0 2.8.1-2 Bonobo CORBA interfaces library ii libbz2-1.0 1.0.2-7 high-quality block-sorting file co ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an ii libfam0c1022.7.0-6 client library to control the FAM ii libgconf2-42.8.1-6 GNOME configuration database syste ii libgcrypt111.2.0-11.1LGPL Crypto library - runtime libr ii libglib2.0-0 2.6.4-1 The GLib library of C routines ii libgnomevfs2-0 2.8.4-4 The GNOME virtual file-system libr ii libgnutls111.0.16-13.1 GNU TLS library - runtime library ii libgpg-error0 1.0-1 library for common error values an ii liborbit2 1:2.12.2-1libraries for ORBit2 - a CORBA ORB ii libpopt0 1.7-5 lib for parsing cmdline parameters ii libsmbclient 3.0.14a-3 shared library that allows applica ii libtasn1-2 0.2.10-3 Manage ASN.1 structures (runtime) ii libxml22.6.16-7 GNOME XML library ii shared-mime-info 0.16-3FreeDesktop.org shared MIME databa ii zlib1g 1:1.2.2-4.sarge.2 compression library - runtime -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#315287: hotplug: reseting whole usb bus when plugging new device, leading to kill the usb root FS
>>>'rescan' the whole system in the case of a debian system beeing on an >>>usb root FS. >> >>This is a kernel issue. > > > Marco, could you espand on what the kernel issue is. > Is it the same bus rescan = bad issue that we were discussing last week? It seems that's related to the device/driver. I try the same experience with a 128Mb USB key USB2.0 certified, and it works well. I try with a Card Reader USB1.1 (don't have the references under the hand) and a 1Gb Flash Card and then the whole things is reseted, killing the root FS ... I read the previous bus rescan = bad issue in the bug tracker, and that's perhaps similar ... I will try tomorrow to test the system with the debian compiled 2.6.8 to see if I found the same problem ... Regards, Benoît. signature.asc Description: OpenPGP digital signature
Bug#315287: hotplug: reseting whole usb bus when plugging new device, leading to kill the usb root FS
Package: hotplug Version: 0.0.20040329-22 Severity: normal (This bug report is not done on the system on which it was occured) Hi all, So here my configuration / explanation : I run the 2.6.11 version of the debian kernel (at least the sources comes from the debian project). My root system is on an usb device (a card reader/CF). When I try to plug a usbnet cable, the hotplug detect the event, and rescan the whole bus (at least this is what I understand). But when the root FS was on /dev/sda1, just after the plug it is set on /dev/sdb1 ... Of course the kernel is very unhappy :/. I try to find a wa, but get no real idea ... I guess that the good way to do it should be to not 'rescan' the whole system in the case of a debian system beeing on an usb root FS. I should be able to help a minima at your request. Regards, Benoît. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.8-2-k7 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages hotplug depends on: ii bash 2.05b-26The GNU Bourne Again SHell ii debconf 1.4.30.13 Debian configuration management sy ii grep 2.5.1.ds1-4 GNU grep, egrep and fgrep ii module-init-tools3.2-pre1-2 tools for managing Linux kernel mo ii modutils 2.4.26-1.2 Linux module utilities ii procps 1:3.2.1-2 The /proc file system utilities ii sed 4.1.2-8 The GNU sed stream editor -- debconf information excluded -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#307447: doxygen: This problem still occurs for other tags
Package: doxygen Version: 1.4.2-2 Followup-For: Bug #307447 As you can see I test the 1.4.2-2 version even if in testing. I get some segfault when parsing php files. If a comment like : /** * @param : testing */ Then doxygen will segfault without any notice. I guess that the problem is the same than with \fn empty ... So if you can reopen it and solve it I will be happy :) Cheers Benoît. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.8-2-686-smp Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages doxygen depends on: ii libc6 2.3.2.ds1-21 GNU C Library: Shared libraries an ii libgcc1 1:3.4.3-12 GCC support library ii libpng12-0 1.2.8rel-1 PNG library - runtime ii libstdc++5 1:3.3.5-8The GNU Standard C++ Library v3 -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#305644: samba: remote password changes hang when trying to sync the unix password too (solution included)
Package: samba Version: 3.0.10-1 Severity: minor Hi all, I finaly found why my samba hangs when trying to update the password of the system. In fact the default passwd chat does'nt seem valid. You must add the output of the password program to be ok, and so avoiding a 'hang' when doing it remotely. So instead of passwd chat = *Enter\snew\sUNIX\spassword:* %n\n *Retype\snew\sUNIX\spassword:* %n\n * . use passwd chat = *Enter\snew\sUNIX\spassword:* %n\n *Retype\snew\sUNIX\spassword:* %n\n *passwd:\spassword\supdated\ssuccessfully* . take me some time too find the problem :/ regards, Benoît. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.8-2-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages samba depends on: ii debconf [debconf-2.0] 1.4.30.13Debian configuration management sy ii libacl1 2.2.23-1 Access control list shared library ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an ii libcomerr2 1.35-6 The Common Error Description libra ii libcupsys2-gnutls10 1.1.23-7 Common UNIX Printing System(tm) - ii libkrb531.3.6-2 MIT Kerberos runtime libraries ii libldap22.1.30-3 OpenLDAP libraries ii libpam-modules 0.76-22 Pluggable Authentication Modules f ii libpam-runtime 0.76-22 Runtime support for the PAM librar ii libpam0g0.76-22 Pluggable Authentication Modules l ii libpopt01.7-5lib for parsing cmdline parameters ii logrotate 3.7-2Log rotation utility ii netbase 4.21 Basic TCP/IP networking system ii samba-common3.0.10-1 Samba common files used by both th -- debconf information: samba/nmbd_from_inetd: * samba/run_mode: daemons samba/log_files_moved: samba/tdbsam: false * samba/generate_smbpasswd: true
Bug#305145: initrd-tools: Unable to automatically build initrd.img when using partition over RAID device
Package: initrd-tools Version: 0.1.78 Severity: important I get the following configuration : 2 SATA drives /dev/sd[ab]1 == /boot (but not a real RAID) /dev/sd[ab]2 == swap (not in RAID) /dev/sda3 == / (temporary install system due to big problems with the debian-installer :)) /dev/sdb3 == /tmp (temporary install) /dev/sd[ab]4 == One big partition for RAID translated into /dev/mdp0 or /dev/md/mdp0 (not using or using devfs) then in this configuration I get, /dev/mdp0p[1234] with /dev/mdp0p1 == future /, 2=/usr, 3=/var, 4=/home Under a chrooted environnement (the future tree is mounted) I try to use mkinitrd to build a RAID enabled initrd image. As you can see I don't use devfs and the name of the drive is not "really" choosen by me. mkinitrd fails to generate the image because it don't know how to handle this root device ... I try to look in mkinitrd script and see that most things are "harcoded" in it. But in the case of mdadm an array could be called /dev/home0 for example with /dev/home0p1 for first partition etc ... (man mdadm IIRC). So can I suggest to add something like MDBASE=/dev/md[p]$minor which could be settled in the mkinitrd.conf ? This will not solve my problem, but at least, should help me a little. I will try to build a patch in a near future. Regards, Benoît -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.8-2-686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages initrd-tools depends on: ii coreutils [fileutils] 5.2.1-2The GNU core utilities ii cpio 2.5-1.2GNU cpio -- a program to manage ar ii cramfsprogs 1.1-6 Tools for CramFs (Compressed ROM F ii dash 0.5.2-4The Debian Almquist Shell ii util-linux2.12-10Miscellaneous system utilities -- no debconf information
Bug#299502: (no subject)
Package: matwrap Subject: matwrap: stubs with dot in the name of one of their leading directories implies no function name (at least octave stubs) Version: 0.57-5 Severity: normal *** Please type your report below this line *** Hello, I'm used to put evry generated stuff (even .m) in a special directory typically, something like : ".build-architecture" But when calling matwrap with the .build-architecture/test/test.m for example, the generated test_octave.cpp will get an empty DEFUN_DLD(,,...) in this case. This is "easily" corrected by changing the order of the stripping process (first remove directory, then remove the . of extension filename) in matwrap_octave.pl line 362 and 363 should be switched to get the expected result. I don't test it for tesla and matlab, but looking at them, they seems to not get the same line (but I don't see the stripping of dirs in tesla and the process seems different for matlab). I can give a patch If you need it. Thanks for your attention. Regards. Benoit -- System Information: Debian Release: 3.1 Architecture: amd64 (x86_64) Kernel: Linux 2.6.8-10-amd64-k8 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages matwrap depends on: ii perl 5.8.4-6Larry Wall's Practical Extraction -- no debconf information signature.asc Description: OpenPGP digital signature
Bug#298041: i2c-2.4.27-2-k6: When installing i2c modules, headers are not set acccordingly !
Aurelien Jarno wrote: On Sat, Mar 05, 2005 at 11:19:40AM +0100, Benoit Hamet wrote: Hi Aurelien, Aurelien Jarno wrote: I have check on my system, the definition of i2c_adapter is the same in /usr/src/kernel-headers-2.4.27-2/linux/i2c.h and in /usr/src/modules/i2c/kernel/i2c.h. The ABI is the same, and a driver build with one or with the other header should work. The main funtions are the same I agree, but take a close look at the sizeof(struct adapter) and you will see that there _is_ a difference which conduct to a kind of buffer overflow :/ If you want I can c&p the 2 structures. Yes, it would be nice, because a diff between the two files listed above shows me that there is no difference concerning the structures. ]$ diff kernel-source-2.4.27/include/linux/i2c.h kernel-headers-2.4.27-2-k6/include/linux/i2c.h ]$ vi kernel-source-2.4.27/include/linux/i2c.h module/i2c/kernel/i2c.h In modules/i2c/kernel/i2c.h : line 246 you get : void *data; /* private data for the adapter */ /* some data fields that are used by all types */ /* these data fields are readonly to the public */ /* and can be set via the i2c_ioctl call */ /* data fields that are valid for all devices */ struct semaphore bus; struct semaphore list; unsigned int flags;/* flags specifying div. data */ when in kernel-source-2.4.27/include/linux/i2c.h you get : line 244 : void *data; /* private data for the adapter */ /* some data fields that are used by all types */ /* these data fields are readonly to the public */ /* and can be set via the i2c_ioctl call*/ /* data fields that are valid for all devices */ struct semaphore lock; unsigned int flags;/* flags specifying div. data*/ AND Then take a look at line 251 in module/i2c/kernel/i2c.h struct i2c_client *clients[I2C_CLIENT_MAX]; int timeout; when at line 248 you get in kernel-source-2.4.27/include/i2c.h struct i2c_client *clients[I2C_CLIENT_MAX]; int client_count; int timeout; Hope that you get it :] I think that perhaps if struct semaphore is the same size of int client_count, then perhaps the size are the same, but I would be really surprised if this was the case: Just in case : 904d5171ac343b10f4d0ac8c86d316b8 modules/i2c/kernel/i2c.h 7845d52b834f6309a4f040f7ef1f6968 kernel-headers-2.4.27-2-k6/include/linux/i2c.h Regards, Benoit signature.asc Description: OpenPGP digital signature
Bug#298041: i2c-2.4.27-2-k6: When installing i2c modules, headers are not set acccordingly !
Hi Aurelien, Aurelien Jarno wrote: Benoit Hamet a écrit : Package: i2c-2.4.27-2-k6 Version: 1:2.9.0-12 Severity: wishlist I lose one day figuring out why my drivers were segfaulting when registring in i2c system. I finally notice that the size of struct adapter is not the same between the headers chipped by the kernel-header and the one given by i2c-source (I guess that i2c-source is the source package for this version of the drivers). Which files are you speaking about? yes that's i2c.h I have check on my system, the definition of i2c_adapter is the same in /usr/src/kernel-headers-2.4.27-2/linux/i2c.h and in /usr/src/modules/i2c/kernel/i2c.h. The ABI is the same, and a driver build with one or with the other header should work. The main funtions are the same I agree, but take a close look at the sizeof(struct adapter) and you will see that there _is_ a difference which conduct to a kind of buffer overflow :/ If you want I can c&p the 2 structures. Regards, Benoit. signature.asc Description: OpenPGP digital signature
Bug#298041: i2c-2.4.27-2-k6: When installing i2c modules, headers are not set acccordingly !
Package: i2c-2.4.27-2-k6 Version: 1:2.9.0-12 Severity: wishlist I lose one day figuring out why my drivers were segfaulting when registring in i2c system. I finally notice that the size of struct adapter is not the same between the headers chipped by the kernel-header and the one given by i2c-source (I guess that i2c-source is the source package for this version of the drivers). So, I don't know what is the Debian policy about that problem, but I wish at least something like an advertisement when installing such a different driver from debian stock kernel ... I guess that I'm not the only one that can get this kind of problem ... If you need more info, I should be able to quickly answer. Regards. Benoit. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i586) Kernel: Linux 2.4.27-2-k6 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages i2c-2.4.27-2-k6 depends on: ii kernel-image-2.4.27-2-k6 2.4.27-8 Linux kernel image for version 2.4 -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#262063: Important to upgrade to rtfm 2.0.4
Heya, I will add that the new release solve the extract article bugs (which is very annoying). So If the new package could be made available quickly I will be thanksfull :) Cheers, Benoît.