Bug#1068561: ITS: argtable2
Go ahead. I'm swamped beyond words. You can take formal ownership, if you like. Shachar On 07/04/2024 12:46, Andreas Tille wrote: Source: argtable2 Version: 13-1.1 Severity: important X-Debbugs-Cc: Shachar Shemesh , Debian Med Packaging Team , 1066...@bugs.debian.org, m...@qa.debian.org Hi, on behalf of the Debian Med team I intend to salvage[1] this package since the following criteria from Wiki[2] are met There is no visible activity regarding the package for six months A previous NMU was not acknowledged, and a bug justifying another NMU is pending for one month The last upload was an NMU and there was no maintainer upload within one year Bugs exist for more than one major missing upstream version (bug #1066377) I have prepared the package I intend to upload inside the Debian Med team space https://salsa.debian.org/med-team/argtable2 The rationale to move this package into Debian Med team is that it affects a tree of dependencies in this team which maintains clustalo that depends from libargtable2-dev. Kind regards Andreas. [1] https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging [2] https://wiki.debian.org/PackageSalvaging -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (50, 'buildd-unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.3.0-2-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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
Bug#1003771: Not (properly?) wrapping the stat call
Are you sure this is a problem?
Fakeroot cannot wrap the open syscall. As a result, it has no way
of knowing whether a file was created before or after fakeroot was
run. To compensate for that, it treats all unknown files as owned
by root.
Fakeroot-ng does wrap the open syscall, and thus does not do
that. A file will only be shown as owned by root if it was created
through fakeroot-ng. This is the intended behavior, as it more
closely matches that or running as real root.
Please verify that this is still a bug.
On 15/01/2022 17:16, Christoph Biedl
wrote:
Package: fakeroot-ng
Version: 0.18-4.1
Severity: normal
Dear maintainer,
while working on #1001961 in fakeroot, I noticed the stat() call is not
properly wrapped by fakeoot-ng, and appearently never did - I checked
back to Debian 8 ("jessie").
Reproducer: Build the program below and run under either fakeroot or
fakeroot-ng.
Expected output (observed with fakeroot):
I: UID is 0, '.' is owned by 0
I: Pass
Received output:
I: UID is 0, '.' is owned by 1000
E: UID mismatch
While I haven't checked it, this should also break the python-apt
autopkgtest if it were run using fakeroot-ng instead of fakeroot.
See the bug# mentioned above for an explanation.
To me, it seems prudent to add this to have feature parity.
Regards,
Christoph
-- System Information:
Debian Release: bookworm/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.89 (SMP w/8 CPU threads)
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)
Versions of packages fakeroot-ng depends on:
ii libc6 2.33-2
ii libgcc-s1 11.2.0-14
ii libstdc++6 11.2.0-14
fakeroot-ng recommends no packages.
fakeroot-ng suggests no packages.
-- no debconf information
-
#include
#include
#include
#include
#include
int main (int argc, char **argv) {
struct stat statbuf;
if (stat (".", )) {
perror("Cannot stat '.'");
exit(1);
}
uid_t uid = getuid();
printf("I: UID is %u, '.' is owned by %u\n", uid, statbuf.st_uid);
if (uid == statbuf.st_uid) {
if (uid) {
printf("W: UID is not zero - not running under fakeroot?\n");
} else {
printf("I: Pass\n");
}
} else {
printf("E: UID mismatch\n");
}
}
-
Bug#991729: With glibc 2.34, it seems more is broken
On 05/08/2021 22:47, Daniel Schepler wrote: On Mon, Aug 2, 2021 at 10:45 PM Shachar Shemesh wrote: Can you run fakeroot-ng with "-l" and attach the generated log file? Here's the log from the run where make fails. The expected happened: 3331985: Unknown syscall 435(NONE) 3331985: Unknown syscall 435(RETURN) Syscall 435 is "clone3", and was added to the kernel about a year ago. I don't know when glibc started using it instead of one of the other clone clones, but as fakeroot-ng doesn't handle it, it unsurprisingly broke. I'll have a look at adding "clone3" to the list of supported system calls, but I'm also considering having fakeroot-ng repot any system call above the system calls it was aware of when it was written as unimplemented. This should avoid such breakages in the future.
Bug#991729: With glibc 2.34, it seems more is broken
On 03/08/2021 1:07, Daniel Schepler wrote: Since I did a test upgrade of a container (non-Debian) to glibc 2.34, it seems I no longer need anything as esoteric as python asyncio.subprocess to trigger a similar error: Can you run fakeroot-ng with "-l" and attach the generated log file?
Bug#898486: (no subject)
As the maintainer and author of fakeroot-ng, I have to say I this bug would have made much more sense to me had it been sent 41 days earlier. If you think namespaces provide a better solution to the problem fakeroot addresses, I believe a better solution is for you to write "fakeroot-ns" and introduce it to Debian. It is the open source way of solving such difference of opinion. It would sure make me happy to see another alternative implementation. Judging from Clint Adam's reaction to fakeroot-ng, I'm guessing his reaction will be no different. Alternatively, you can also run "update-alternatives --config fakeroot" and default it to running fakeroot-ng. This you can do with no change to Debian at all. This isn't a bug on my package, so it's not my judgement call to make, but I'd vote to close with no action taken.
Bug#950706: rsyncrypto: diff for NMU version 1.14-1.2
Thank you, and sorry for leaving slack for you to pick up :-( By all means, allow the NMU to move forward. On 16/05/2020 18:42, Adrian Bunk wrote: Control: tags 950706 + pending Dear maintainer, I've prepared an NMU for rsyncrypto (versioned as 1.14-1.2) and uploaded it to DELAYED/15. Please feel free to tell me if I should cancel it. cu Adrian
Bug#755074: cryptsetup: Cryptsetup prompting for password twice in parallel, preventing from entering password
Package: cryptsetup Version: 2:1.6.4-4 Severity: important Dear Maintainer, I have a LUKS disk (not necessary for the boot of the system). The disk was installed on wheezy. On Wheezy, it would ask for the password for the disk during boot. When I upgraded the system to Jessie, I noticed that the first time I input the password, it would always fail. I noticed that two password prompts would show on screen, one interrupted by the other. After I would put in the password prompt, the decryption would fail, and it would ask again, this time only once. At that point, I could put in the password and the disk would mount correctly. I think that the password prompt runs from two different scripts, perhaps to accomodate both initrd and normal startup. I suspect that the switch to systemd causes the two scripts to run in parallel, causing the trouble I'm experiencing. Shachar -- Package-specific info: -- /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-3.14-1-amd64 root=/dev/mapper/ssd-root ro quiet -- /etc/crypttab # target name source device key file options sdb1_crypt UUID=f9971ca4-10c8-43ae-8ffd-f27faaa765a1 none luks -- /etc/fstab # /etc/fstab: static file system information. # # Use 'blkid' to print the universally unique identifier for a # device; this may be used with UUID= as a more robust way to name devices # that works even if disks are added and removed. See fstab(5). # # file system mount point type options dump pass /dev/mapper/ssd-root/ ext4 noatime,nodiratime,discard,errors=remount-ro0 1 /dev/mapper/ssd-home/home ext4 nodiratime,discard 0 2 /dev/mapper/crypt-swap noneswapdefaults 0 2 /dev/mapper/crypt-data /srv/crypt ext4 noatime,nodiratime 0 2 /dev/mapper/plain-virtual /srv/virtualext4 noatime,nodiratime 0 2 /dev/mapper/plain-cache /var/cache ext4defaults 0 2 /dev/mapper/plain-storage /srv/storageext4defaults 0 2 /dev/sr0/media/cdrom0 udf,iso9660 user,noauto 0 0 -- lsmod Module Size Used by cfg80211 412187 0 rfkill 18867 1 cfg80211 raid6_pq 95238 0 xor21040 0 ufs73486 0 qnx4 13036 0 hfsplus93258 0 hfs49749 0 minix 31387 0 vfat 17135 0 msdos 17046 0 fat53794 2 vfat,msdos libcrc32c 12426 0 pci_stub 12429 1 vboxpci18981 0 vboxnetadp 25443 0 vboxnetflt 23324 0 vboxdrv 261792 3 vboxnetadp,vboxnetflt,vboxpci binfmt_misc16949 1 sha256_ssse3 21596 2 sha256_generic 16804 1 sha256_ssse3 dm_crypt 22595 1 snd_hda_codec_hdmi 40955 1 snd_hda_codec_realtek50301 1 snd_hda_codec_generic59065 1 snd_hda_codec_realtek iTCO_wdt 12831 0 iTCO_vendor_support12649 1 iTCO_wdt hid_generic12393 0 usbhid 44439 0 hid94034 2 hid_generic,usbhid x86_pkg_temp_thermal12951 0 intel_powerclamp 17159 0 usblp 17274 0 evdev 17445 8 snd_hda_intel 43768 3 intel_rapl 17356 0 snd_hda_codec 100159 4 snd_hda_codec_realtek,snd_hda_codec_hdmi,snd_hda_codec_generic,snd_hda_intel snd_hwdep 13148 1 snd_hda_codec coretemp 12854 0 snd_pcm84566 3 snd_hda_codec_hdmi,snd_hda_codec,snd_hda_intel kvm_intel 134712 0 snd_seq48834 0 snd_seq_device 13132 1 snd_seq kvm 388171 1 kvm_intel snd_timer 26614 2 snd_pcm,snd_seq psmouse90422 0 pcspkr 12595 0 serio_raw 12849 0 snd61094 16 snd_hda_codec_realtek,snd_hwdep,snd_timer,snd_hda_codec_hdmi,snd_pcm,snd_seq,snd_hda_codec_generic,snd_hda_codec,snd_hda_intel,snd_seq_device lpc_ich20768 0 mfd_core 12601 1 lpc_ich shpchp 31121 0 i2c_i801 16965 0 tpm_infineon 16844 0 tpm_tis17134 0 battery13101 0 tpm27415 2 tpm_tis,tpm_infineon i915 718092 4 soundcore 13026 1 snd video 17804 1 i915
Bug#710072: reportbug-ng ignores LC_MESSAGES
Package: reportbug-ng Version: 1.27 Severity: normal I have my locale set the following way: LANG is he_IL.UTF-8 LC_MESSAGES is en_US.UTF-8 According to the specs, this is supposed to provide a Hebrew locale with programs using their English translation. reportbug-ng, however, shows up translated to Hebrew. How to reproduce: Set LANG to one language (for which reportbug-ng has a translation) and LC_MESSAGES to another. -- System Information: Debian Release: 7.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.8-1-amd64 (SMP w/4 CPU cores) Locale: LANG=he_IL.UTF-8, LC_CTYPE=he_IL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages reportbug-ng depends on: ii python2.7.3-4 ii python-apt0.8.8.2 ii python-debianbts 1.11 ii python-qt44.9.3-4 ii python-support1.0.15 ii xdg-utils 1.1.0~rc1+git20111210-6 ii xterm 278-4 reportbug-ng recommends no packages. reportbug-ng 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#706265: iagno: Iagno hangs and/or take 100% CPU
Package: iagno Version: 1:3.4.2-3 Severity: important Dear Maintainer, When playing Iagno in computer level 3, if the human plays well enough, the program misbehaves. This is never most apparent than when iagno has only one move it can play. At that point it might sit there, with 100% CPU (one thread) for several *minutes*, crunching all of the possible ways the game can continue after it places it's one and only possible move. During that time, no indication is displayed that the game is working, the window does not respond, and clicking on the board does not appear to do anything (though the click is registered, and is considered your move once iagno does you the curtesy of actually playing). This is especially a shame, because the iagno version that came with squeeze, not only did not exhibit this bug, but actually played quite well at level 3 (much better than this version). -- System Information: Debian Release: 7.0 APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (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 iagno depends on: ii dconf-gsettings-backend [gsettings-backend] 0.12.1-3 ii gnome-games-data 1:3.4.2-3 ii libatk1.0-0 2.4.0-2 ii libc62.13-38 ii libcairo21.12.2-3 ii libcanberra-gtk3-0 0.28-6 ii libgdk-pixbuf2.0-0 2.26.1-1 ii libglib2.0-0 2.33.12+really2.32.4-5 ii libgtk-3-0 3.4.2-6 ii libpango1.0-01.30.0-1 ii librsvg2-2 2.36.1-1 Versions of packages iagno recommends: ii gnome-games-extra-data 3.2.0-4 iagno 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#614601: ITP: libsafewrite -- Simple functions for performing safe atomic replacement of files
Package: wnpp Severity: wishlist Owner: Shachar Shemesh shac...@debian.org * Package name: libsafewrite Version : 1.00 Upstream Author : Shachar Shemesh shac...@lingnu.com * URL : http://www.lingnu.com/opensource/safewrite.html * License : MIT Programming Lang: C Description : Simple functions for performing safe atomic file updates Safewrite is a library for simple, almost drop-in replacement to the usual open and close calls. Using safewrite, however, guarantees that the files be updated in an atomic way - anyone trying to read the file is guaranteed to get a complete version, either the old or the new, but never a partially updated file. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#614601: ITP: libsafewrite -- Simple functions for performing safe atomic replacement of files
On 22/02/11 19:54, Ben Hutchings wrote: Judging by what you consider 'small bugs' in https://github.com/Shachar/safewrite/commit/efafcd4260375a41257709c7eb5a8d6065366849 why should anyone trust their important data to this library? Feel free not to use it/file bugs against it. Giving feedback over the upstream trustworthiness is not the purpose of ITP bugs, and I have been warned by the list masters that discussing a specific package's upstream bugs on Debian-devel is off topic. I quickly reviewed the code and found: Did you read the accompanying manual pages first? safe_open() might not return correct error codes, since the library and system calls in its cleanup code may overwrite the original error code. Thank you for your input. I'll fix it. It uses a fixed extension for the temporary file name, and unlinks whatever was there before; this could be a security flaw. The matter has been discussed before. If you have a specific scenario where this will cause a security flaw, please feel free to file a bug or contact me directly. Pending that happening, my analysis is that there is no security flaw in that case. It doesn't check for failure of fstat() (this is unlikely but possible, e.g. when using a network filesystem). Interesting point. I'll have to think about it. Copying setuid and setgid bits to an empty file is pointless, since they are cleared by write() (this is a good thing!). Frankly, I was not aware of this. I could not find it documented in the man pages. In any case, this is no regression from the non-safe_open case, as these would get cleared on write either way. If this is a Linux only feature, I'm actually inclined to leave the code in (which is why I needed the manual pages). safe_close() doesn't actually close the file or free the 'context' if fsync() fails. This is inconsistent with close(). But consistent with what the man page says about it. The alternative is to not allow the user to retry saving the file's content, which I don't see as preferable. Thank you for your feedback. Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#530820: News about a new version of SI1452
The new standard is at the first draft stage. More info, including XKB implementation of the interim state, at http://www.lingnu.com/en/howto/78-si1452.html I'll try to update that link as things progress. Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#599287: Examples of corrupt pixmaps
This is from the the application's icon bar, the flags indicator for the keyboard language. Since the switch to using xorg.conf, the corruption is MUCH more likely to happen on dual monitor environments. -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com attachment: il_corrupt.pngattachment: il_ok.pngattachment: us_corrupt.pngattachment: us_ok.png
Bug#599261: kate: Error in implementation of Unicode BiDi algorithm - rule W5 not implemented
Package: kate Version: 4:4.4.5-1 Severity: normal Tags: l10n This bug is probably not in kate, but in its underlying infrastructure. I'm just not sure where. Unicode support for bidirectional languages is supposed to be implemented using the Unicode BiDi algorithm (UBA), detailed in http://www.unicode.org/reports/tr9/. Rule W5 (http://www.unicode.org/reports/tr9/#W5) states: W5. A sequence of European terminators adjacent to European numbers changes to all European numbers. It appears that kate (maybe QT?) do not implement this rule. When typing a sequence of Hebrew or Arabic letters, followed by a European Terminator (such as the hash symbol - #), followed by a number, the ET should receive the level of the number. logical order (upper case means RTL characters) HELLO #12 UBA dictated visual order: #12 OLLEH Actual order performed by kate: 12# OLLEH -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=he_IL.UTF-8, LC_CTYPE=he_IL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages kate depends on: ii kdebase-runtime 4:4.4.5-1runtime components from the offici ii libc6 2.11.2-6 Embedded GNU C Library: Shared lib ii libkde3support4 4:4.4.5-1the KDE 3 Support Library for the ii libkdecore5 4:4.4.5-1the KDE Platform Core Library ii libkdeui5 4:4.4.5-1the KDE Platform User Interface Li ii libkfile4 4:4.4.5-1the File Selection Dialog Library ii libkio5 4:4.4.5-1the Network-enabled File Managemen ii libknewstuff2-4 4:4.4.5-1the Get Hot New Stuff v2 Library ii libknewstuff3-4 4:4.4.5-1the Get Hot New Stuff v3 Library ii libkparts4 4:4.4.5-1the Framework for the KDE Platform ii libktexteditor4 4:4.4.5-1the KTextEditor interfaces for the ii libplasma3 4:4.4.5-1the Plasma Library for the KDE Pla ii libqt4-dbus 4:4.6.3-1+b1 Qt 4 D-Bus module ii libqt4-qt3support 4:4.6.3-1+b1 Qt 3 compatibility library for Qt ii libqt4-xml 4:4.6.3-1+b1 Qt 4 XML module ii libqtcore4 4:4.6.3-1+b1 Qt 4 core module ii libqtgui4 4:4.6.3-1+b1 Qt 4 GUI module ii libstdc++6 4.4.4-8 The GNU Standard C++ Library v3 kate recommends no packages. Versions of packages kate suggests: ii aspell0.60.6-4 GNU Aspell spell-checker ii hspell1.1-1 Hebrew spell checker and morpholog ii khelpcenter4 4:4.4.5-1 help center ii konsole 4:4.4.5-1 X terminal emulator -- 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#599261: Demo of desired behavior
The Unicode site has a page where you can watch the desired result of the UBA. It has a ASCII hack mode, where upper case letters can be used to simulate RTL ones (it's more elaborate than that - details at the page). A demo of correct rendering can be seen at http://unicode.org/cldr/utility/bidi.jsp?a=HI+%2312p=Autohack=on -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#588218: libc-bin: ldconfig unconditionally create auxilary cache file at fixed path
Package: libc-bin Version: 2.10.2-6 Severity: normal Tags: upstream I am using ldconfig to generate a cache for an image designed for an embedded system. That system runs a totally different platform, but up until Squeeze, ldconfig worked just fine, using the -r flag. Starting with Squeeze, ldconfig insists on generating an auxilary cache file. It attempts to generate this file even if the -i or -C options are used. Looking at the source, there does not appear to be any way to tell it to not create the auxilary cache file, or even to change the path for that file. I believe that, when given -i or -C, that the auxilary cache file should not be created at all. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-bpo.5-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash -- 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#576244: privbind: 1-byte buffer overflow
Christian Jaeger wrote: Whether this has security implications or not, I don't know. It has, literally, been years since I touched the code. As far as I can tell, an attacker trying to exploit this is running in the same privilege level as the potential gain from an exploitable buffer overrun (i.e. - no security implications as there is no privilege escalation). This is in addition to the fact that off by ones on the heap are hard to exploit. However, with these bugs, it is easier to fix than to explain why a fix is not necessary. I'm going to push a fix through, but pending more info from you or someone else, I will be marking it as neither security nor high priority. Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com
Bug#481759: Can be closed
I cannot reproduce this bug on an up to date Lenny machine. It seems somewhere, somehow, someone solved it. Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com
Bug#563232: libargtable2-0 does not contain libargtable2.so
Andrew Michael Wesie wrote: ~# ldd /opt/dell/srvadmin/rac5/bin/racadm libargtable2.so = /usr/lib/libargtable2.so (0xb7f4d000) Judging from the path in which this executable is installed (/opt), this is not a Debian program. Libargtable (the upstream), up until around the point Debian started to ship it, would not include SO versioning, resulting in applications linking with it being linked with the so rather than the explicit version. It would seem that your program links with such an old version (upstream released a properly versioned version on December 23, 2005 - over four years ago). I would direct your bug to the application. In the mean while, there are two easy work arounds. Either: 1. Install libargtable2-dev or 2. Create a symbolic link from /usr/lib/libargtable2.so.0 to /usr/lib/libargtable2.so Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com
Bug#544471: cap_sys_nice on executable leads to ERROR: ld.so: object 'libfakeroot-sysv.so' from LD_PRELOAD cannot be preloaded: ignored
Clint Adams wrote: On Tue, Sep 01, 2009 at 12:24:23AM -0400, Yaroslav Halchenko wrote: do you mean that executables with any capabilities (or even just cap_sys_nice) set are considered insecure and LD_PRELOAD is explicitly disallowed so LD_PRELOAD of fakeroot library fails? Yes, it is the same as with setuid/setgid programs. The point is that otherwise you could make a preload library to exploit any capability by subverting one of the functions used by a privileged binary. I'm not sure how fakeroot-ng interacts with capabilities, but perhaps it is more suitable for your use case. For SUID, fakeroot means that the program runs with privileges but without fakeroot's wrapping. Fakeroot-ng means that program runs without the (real) privileges, but with fakeroot-ng's wrapping. I'm not sure about capabilities, but it's definitely worth giving it a try. Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com
Bug#544471: cap_sys_nice on executable leads to ERROR: ld.so: object 'libfakeroot-sysv.so' from LD_PRELOAD cannot be preloaded: ignored
Yaroslav Halchenko wrote: hm... it seems to be doing find: $ fakeroot python --version ERROR: ld.so: object 'libfakeroot-sysv.so' from LD_PRELOAD cannot be preloaded: ignored. Python 2.5.4 $ fakeroot-ng python --version Python 2.5.4 cool -- thanks for the hint... seems to remain working fine within dpkg-buildpackage ;) I just wonder now what to do with the bug -- apparently it is a feature ;) but may be error message could be made more informative/relevant? This is not a bug. It's a design limitation. I'm not even sure fakeroot has the option of detecting when this limitation is about to trigger (at least, not in a sane way). Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com
Bug#533868: manpages-dev: Number of parameters of sys_clone
Package: manpages-dev Version: 3.21-1 Severity: normal In the clone(2) man page, sys_clone is described (the kernel level system call). The description there has inconsistent argument count. The first paragraph claims that sys_clone only has the flags and child stack arguments (making a total of two). The third paragraph says that kernel 2.5.49 added two more arguments, making a total of five. Either an argument is missing from the description, or someone made an algebric error. Shachar -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.30 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages manpages-dev depends on: ii manpages 3.21-1 Manual pages about using a GNU/Lin manpages-dev recommends no packages. Versions of packages manpages-dev suggests: ii man-db [man-browser] 2.5.5-2on-line manual pager -- 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#532994: fakeroot-ng should use /dev/shm for shared memory files
Package: fakeroot-ng Version: 0.15-1 Severity: wishlist fakeroot-ng uses mmap based shared memory to communicate between the debugger and the processes that think they are root. By default, the files for the communication are created under /tmp. It makes much more sense to create them under /dev/shm, like shm_open would do. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.30 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages fakeroot-ng depends on: ii libc6 2.9-13 GNU C Library: Shared libraries ii libgcc1 1:4.4.0-5 GCC support library ii libstdc++64.4.0-5The GNU Standard C++ Library v3 fakeroot-ng recommends no packages. fakeroot-ng 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#530820: The standard is scheduled to be rethought
I'm a permanent guest at the Standards Israeli Institute's sub-committee for Hebrew in computerized systems. Very recently, someone asked to reopen the Hebrew keyboard standard to address precisely these types of deficiencies. The standard is up for rediscussion sometime this year. Hopefully, the new standard will address all missing characters, as well as resolve the horrid location in which diacritics are currently placed. Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com
Bug#530181: closed by Shachar Shemesh shac...@shemesh.biz (Irrelevant script files)
severity 530181 wishlist thanks Raphael Geissert wrote: The w32 in the name of the script you mentioned stand for win32. This script is the mingw equivalent of the regtest script. You will also note that while regtest is marked as an executable, regtestw32 is not, which means it is, technically, not a script at all. It is a script, it has the shebang. You and I are in extreme disagreement on what an executable is. To me, having the executable permission is a requirement. I will concede that the Linux kernel sides with me, but the Windows kernel sides with you, so you can definitely say that more people agree with you than with me. Since the Mingw environment is not one for which there is a Debian port, I am closing this bug as irrelevant. Then why are those files shipped at all? That is a valid, if entirely different, question. I hardly think that the fact I decided to ship the entirety of upstream's test suite, even the parts that are not relevant to Debian, warrant a bug. I believe the Debian archive can sustain an extra 3900 bytes (uncompressed). I am not closing this bug yet so we do not enter an editing war, but lacking further input I will. Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com
Bug#506208: sshpass: fails when ssh asks for host key confirmation
Version 1.03 of upstream solved this problem, but the problem was deemed too minor to justify trying to push the version into Lenny. I'll upload a new version to Sid the moment Lenny is out the door. Shachar -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502585: sshpass taking 100% CPU while the ssh session is running
Package: sshpass Version: 1.01-1 Severity: grave Justification: renders package unusable When connecting using sshpass, sshpass takes 100% CPU during the connection, until ssh exists. This makes package usage impractical for any serious use. Problem originally reported on the source forge bug tracking system by an anonymous contributer. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/2 CPU cores) Locale: LANG=he_IL, LC_CTYPE=he_IL (charmap=ISO-8859-8) Shell: /bin/sh linked to /bin/bash Versions of packages sshpass depends on: ii libc6 2.7-14 GNU C Library: Shared libraries Versions of packages sshpass recommends: ii openssh-client [ssh-client] 1:5.1p1-3 secure shell client, an rlogin/rsh sshpass suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#478584: g++-4.3: Happens without the -include option too
Package: g++-4.3 Version: 4.3.1-9 Followup-For: Bug #478584 Just wanted to add that this happens even if the precompiled header is not forced on the compiler. I have a setting where the precompiled header is included from inside the file (#include stdafx.h - it's a cross platform project). I managed to get automake to place stdafx.h.gch in the include search path, and gcc correctly uses it. However, despite the fact that the include is specifically stated inside the file, the dependency files do not contain it. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/2 CPU cores) Locale: LANG=he_IL, LC_CTYPE=he_IL (charmap=ISO-8859-8) Shell: /bin/sh linked to /bin/bash Versions of packages g++-4.3 depends on: ii gcc-4.3 4.3.1-9The GNU C compiler ii gcc-4.3-base 4.3.1-9The GNU Compiler Collection (base ii libc6 2.7-13 GNU C Library: Shared libraries ii libgmp3c2 2:4.2.2+dfsg-3 Multiprecision arithmetic library ii libmpfr1ldbl 2.3.1.dfsg.1-2 multiple precision floating-point ii libstdc++6-4.3-dev4.3.1-9The GNU Standard C++ Library v3 (d g++-4.3 recommends no packages. Versions of packages g++-4.3 suggests: pn g++-4.3-multilib none (no description available) pn gcc-4.3-doc none (no description available) pn libstdc++6-4.3-dbgnone (no description available) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#470512: What's up with this?
Is this bug still open? -- Shachar Or | שחר אור http://ox.freeallweb.org/
Bug#495421: fakeroot-ng: does not appear to work any more
Jasen Betts wrote: Upstream checks this situation and gives a more verbose error message. I will try to add support for an alternative environment variable as well, so that you don't move the TMPDIR for all of the applications fakeroot-ng runs, only it itself. perhaps /dev/shm would be a good alternative location for the file? I'll introduce it into the Debian package as a first step, as there you can be fairly sure what and where things are. As a more general rule, I'm not sure how to make this thing in a platform independent way. Shachar -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495421: fakeroot-ng: does not appear to work any more
Jasen Betts wrote: It just stopped working! (it was working last month) even harmless binaries refuse to run. [EMAIL PROTECTED]:/tmp$ fakeroot -l log /bin/true Killed [EMAIL PROTECTED]:/tmp$ cat log handle_memory_allocation: 4458 process failed to mmap memory: Operation not permitted Needless to say, it works for me :-) Is your temporary folder (/tmp or TMPDIR) mounted with the -noexec flag? If so, what you see is the expected behavior. Set TMPDIR environment variable to point to somewhere that isn't mounted with -noexec and try again. Upstream checks this situation and gives a more verbose error message. I will try to add support for an alternative environment variable as well, so that you don't move the TMPDIR for all of the applications fakeroot-ng runs, only it itself. Shachar -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495174: fakeroot-ng: debian/rules clean does not clean, resulting in FTBS twice problems
Package: fakeroot-ng Version: 0.12-1 Severity: serious Tags: patch Justification: Policy 4.9 The debian/rules file for the package spread out the commands under several of the rules, including the 'clean' rule. For some reason, the empty lines are actually empty, instead of containing a TAB character. The result is that the rules are terminated early. As a result, running debian/rules clean does not call the upstream make distclean, which results in binary files still lying around, which results in a second dpkg-buildpackage failing with unrepresentable changes to the source. To fix, we merely need to add a TAB character to the begining of each such empty line. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.25-2-686 (SMP w/2 CPU cores) Locale: LANG=he_IL, LC_CTYPE=he_IL (charmap=ISO-8859-8) Shell: /bin/sh linked to /bin/bash Versions of packages fakeroot-ng depends on: ii libc6 2.7-13 GNU C Library: Shared libraries ii libgcc1 1:4.3.1-2 GCC support library ii libstdc++64.3.1-2The GNU Standard C++ Library v3 fakeroot-ng recommends no packages. fakeroot-ng suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495176: lintian: false positive: incorrect handling of continuation lines in scripts
Package: lintian Version: 1.24.2.1 Severity: normal If you check out fakeroot-ng version 0.12-1 (I worked around this bug in 0.12-2), lintian complains about command with path in maintainer script, line 37 of postinst. If you look at the actual script, however, line 36 and onwards look like this: update-alternatives --install /usr/bin/fakeroot fakeroot \ /usr/bin/fakeroot-ng 5 \ --slave /usr/share/man/man1/fakeroot.1.gz \ fakeroot.1.gz /usr/share/man/man1/fakeroot-ng.1.gz While line 37 indeed starts with what looks like a command, and it indeed has a path, but it is, in fact, an argument passed to update-alternatives. In order to solve this, lintian needs to do a more complete parsing of the lines before passing them on to the rules. I would suggest concatanating all the lines that are continuation lines into one string, and only then passing them on to the rules. This will have the side effect that the rules will attribute any problem in the above example to line 36, regardless of the line the problem actually happened on, but that, I think, is an acceptable price to pay (and not much different than other warnings). -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.25-2-686 (SMP w/2 CPU cores) Locale: LANG=he_IL, LC_CTYPE=he_IL (charmap=ISO-8859-8) Shell: /bin/sh linked to /bin/bash Versions of packages lintian depends on: ii binutils2.18.1~cvs20080103-7 The GNU assembler, linker and bina ii diffstat1.45-2 produces graph of changes introduc ii dpkg-dev1.14.20 Debian package development tools ii file4.25-1 Determines file type using magic ii gettext 0.17-3 GNU Internationalization utilities ii intltool-debian 0.35.0+20060710.1Help i18n of RFC822 compliant conf ii libparse-debianchan 1.1.1-2 parse Debian changelogs and output ii libtimedate-perl1.1600-9 Time and date functions for Perl ii liburi-perl 1.35.dfsg.1-1Manipulates and accesses URI strin ii man-db 2.5.2-2 on-line manual pager ii perl [libdigest-sha 5.10.0-11.1 Larry Wall's Practical Extraction lintian recommends no packages. Versions of packages lintian suggests: pn binutils-multiarchnone (no description available) pn libtext-template-perl none (no description available) ii man-db2.5.2-2on-line manual pager -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#493061: Patch
The following patch seems to solve this problem.
Index: file.cpp
===
--- file.cpp (revision 216)
+++ file.cpp (working copy)
@@ -1110,6 +1110,14 @@
if( ptlib_success( pid, sc_num ) ) {
ptlib_stat stat;
+// We are tight on context memory - first set up the args for the continuation syscall,
+// only then handle the current call return
+ptlib_save_state( pid, state-saved_state );
+ptlib_set_argument( pid, 1, state-context_state[2] );
+ptlib_set_argument( pid, 2, state-context_state[3] );
+ptlib_set_argument( pid, 3, state-context_state[0]==10 ? AT_REMOVEDIR : 0 );
+
+// Will the file be actually deleted?
ptlib_get_mem( pid, state-memory, stat, sizeof(stat) );
if( stat.nlink==1 || state-context_state[0]==10 ) {
@@ -1123,11 +1131,7 @@
state-context_state[2]=0;
}
-// Perform the actual unlink operation
-ptlib_save_state( pid, state-saved_state );
-ptlib_set_argument( pid, 1, state-context_state[2] );
-ptlib_set_argument( pid, 2, state-context_state[3] );
-ptlib_set_argument( pid, 3, state-context_state[0]==10 ? AT_REMOVEDIR : 0 );
+// Complete the continuation call
ptlib_generate_syscall( pid, state-orig_sc, state-shared_memory );
state-state=pid_state::REDIRECT1;
state-context_state[0]=1;
Bug#493061: OMG!!
Now how did THAT happen? Ok, I have it happening here. I think it should be a higher priority bug for fakeroot-ng, as I think we need to get this fix into Lenny or fakeroot-ng is not going to be as useful as it should. Shachar -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#433905: Another occurance
Hi, I can report the exact same bug on an AMD64 machine with two SCSI disks. Delayroot solved it there as well. I originally installed Etch, which booted up just fine, and when I upgraded to Lenny the problem appeared. lspci's output: 00:00.0 Host bridge: Intel Corporation 82945G/GZ/P/PL Memory Controller Hub (rev 02) 00:02.0 VGA compatible controller: Intel Corporation 82945G/GZ Integrated Graphics Controller (rev 02) 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 01) 00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 01) 00:1c.2 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 3 (rev 01) 00:1c.3 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 4 (rev 01) 00:1c.4 PCI bridge: Intel Corporation 82801GR/GH/GHM (ICH7 Family) PCI Express Port 5 (rev 01) 00:1c.5 PCI bridge: Intel Corporation 82801GR/GH/GHM (ICH7 Family) PCI Express Port 6 (rev 01) 00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 (rev 01) 00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 (rev 01) 00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 (rev 01) 00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 (rev 01) 00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 01) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev e1) 00:1f.0 ISA bridge: Intel Corporation 82801GB/GR (ICH7 Family) LPC Interface Bridge (rev 01) 00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller (rev 01) 00:1f.2 IDE interface: Intel Corporation 82801GB/GR/GH (ICH7 Family) SATA IDE Controller (rev 01) 00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 01) 01:00.0 Ethernet controller: Intel Corporation 82573V Gigabit Ethernet Controller (Copper) (rev 03) 06:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) 06:02.0 SCSI storage controller: Adaptec ASC-29320A U320 (rev 10) 06:05.0 FireWire (IEEE 1394): Texas Instruments TSB43AB23 IEEE-1394a-2000 Controller (PHY/Link) Hope this helps. Shachar -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#491862: virtualbox-ose-guest-source: Bad redirection in guest in mounted shared folder
Package: virtualbox-ose-guest-source Version: 1.6.2-dfsg-1~bpo40+1 Severity: normal *** Please type your report below this line *** Look at this weird thing that is happening to me... debian:/mnt# mount.vboxsf shared shared/ debian:/mnt# grep shared /proc/mounts none /mnt/shared vboxsf rw,nodev 0 0 debian:/mnt# touch shared/list debian:/mnt# echo first shared/list debian:/mnt# cat shared/list first debian:/mnt# echo second shared/list debian:/mnt# cat shared/list second debian:/mnt# This report is from the guest. The host is etch with the vbox from bpo, same version as the guest additions, i suppose. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-6-k7 Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Versions of packages virtualbox-ose-guest-source depends on: ii bzip2 1.0.3-6 high-quality block-sorting file co ii debhelper 5.0.42 helper programs for debian/rules ii dpatch 2.0.21 patch maintenance system for Debia ii kbuild 1:0.1.3svn1610-1~bpo40+1 framework for writing simple makef ii module-assistan 0.10.8 tool to make module package creati virtualbox-ose-guest-source recommends no packages. -- no debconf information -- Shachar Or | שחר אור http://ox.freeallweb.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#489654: More info, please
First, is there a document anywhere that explains what features of bash are not available in bourne shell? I should note that manually setting the interpreter on that script to /bin/dash does not cause it to break. Does that mean I should close this as not a bug? Is there a list of language features available in dash and not in bourne shell? Shachar -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#490593: aptitude search ~O also broken from this?
Hello! When I go aptitude -F'%p %v#' search '~Obackports ~i' I see that it lists not only packages that I have installed from backports, but it lists all the packages that I have installed which have a backports version. So is this caused by the same bug? Cheers! -- Shachar Or | שחר אור http://ox.freeallweb.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#490593: Ideas about the -F escapes
Good day! I suggest changing the way %t acts; it should print all the archives from which the package is included, such as 'stable,etch-backports'. A new escape will print the archive(s) which have the currently installed version. And another possible new escape could print the archive which has the candidate version. Another method would be having the search action pick not only one package, but multiple... but i'm going to places in the code which I don't know so I leave it up to you, or whoever wishes to patch this. Chau! -- Shachar Or | שחר אור http://ox.freeallweb.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#490650: aptitude: etch-backports/+M, dependency, something not quite right
Package: aptitude Version: 0.4.4-4 Severity: normal *** Please type your report below this line *** Cheers! When I type 'aptitude install fuse-utils/etch-backports libfuse2/etch-backports+M' I expect aptitude to install both packages from etch-backports and mark the libfuse2 package as being automatically installed. What happens is that the libfuse2 package doesn't get selected for installation, or perhaps it get deselected because nothing depends on it. Thing is, fuse-utils does depend on it. So I assume this has to do with the fact the aptitude by default chooses to not mark dependencies when they are from etch-backports. I would expect this command, where I explicitly specify the origins of the packages, to have higher priority than the default apt configuration. Peace! -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-6-amd64 Locale: LANG=he_IL.UTF-8, LC_CTYPE=he_IL.UTF-8 (charmap=UTF-8) Versions of packages aptitude depends on: ii apt [libapt-pkg-libc6. 0.6.46.4-0.1 Advanced front-end for dpkg ii libc6 2.3.6.ds1-13etch5 GNU C Library: Shared libraries ii libgcc11:4.1.1-21GCC support library ii libncursesw5 5.5-5 Shared libraries for terminal hand ii libsigc++-2.0-0c2a 2.0.17-2 type-safe Signal Framework for C++ ii libstdc++6 4.1.1-21 The GNU Standard C++ Library v3 Versions of packages aptitude recommends: ii aptitude-doc-en [aptitude-doc 0.4.4-4English manual for aptitude, a ter ii libparse-debianchangelog-perl 1.0-1 parse Debian changelogs and output -- no debconf information -- Shachar Or | שחר אור http://ox.freeallweb.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#490650: Workaround; intalling all bpo manually and then marking them M
Hey! I'm thinking of a possible workaround for this; I'll install all the etch-backports packages as manually installed and after installation mark the appropriate ones M. Sounds like it should work so I'll go ahead and modify the mkpkglist.sh script to give me the needed changes. Cheers! -- Shachar Or | שחר אור http://ox.freeallweb.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#490574: hal: Mounting NTFS-3G
Package: hal Version: 0.5.11-2 Severity: wishlist Hello! My wish is to make it relatively simple and easy for administrators to set up HAL to use NTFS-3G so that desktop users could mount their removable NTFS storage devices read and write. I would like this to be included in lenny and I expect that if this is done correctly and soon enough, the release team will authorize this. As I understand it, the way to do this is via tinkering with HAL's .fdi files; changing some defaults there; I haven't investigated just what exactly needs be done. My suggestion is to make a debconf question in the hal package which will ask which driver I would like HAL to use for mounting ntfs filesystems. This debconf question will let me choose between the kernel driver (the current default), the user-space driver (ntfsmount from ntfsprogs package) and the NTFS-3G driv er. Which selections are available will depend on which packages are installed and the debconf question sho uld let me know of these options, so that I'll know which packages I can install for this purpose. I would really like this to be included in lenny so I'll be posting about this in various mailing lists asking for help and I'll appreciate the Debian hal team's quick response. Peace! -- Shachar Or | שחר אור http://ox.freeallweb.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#490593: aptitude: -F %t seems to act strange
Package: aptitude Version: 0.4.4-4 Severity: normal *** Please type your report below this line *** Hello! I have the etch version of base-files while i have bpo in my sources.list. When i type 'aptitude -F %t search base-files' I get 'etch-backports'. I am thinking that I should be getting 'stable,etch-backports' because these are the origins for this package or 'stable' because that is the origin of the version I have installed or because that has the highest priority. Isn't this wierd? Peace! -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-6-amd64 Locale: LANG=he_IL.UTF-8, LC_CTYPE=he_IL.UTF-8 (charmap=UTF-8) Versions of packages aptitude depends on: ii apt [libapt-pkg-libc6. 0.6.46.4-0.1 Advanced front-end for dpkg ii libc6 2.3.6.ds1-13etch5 GNU C Library: Shared libraries ii libgcc11:4.1.1-21GCC support library ii libncursesw5 5.5-5 Shared libraries for terminal hand ii libsigc++-2.0-0c2a 2.0.17-2 type-safe Signal Framework for C++ ii libstdc++6 4.1.1-21 The GNU Standard C++ Library v3 Versions of packages aptitude recommends: ii aptitude-doc-en [aptitude-doc 0.4.4-4English manual for aptitude, a ter ii libparse-debianchangelog-perl 1.0-1 parse Debian changelogs and output -- no debconf information -- Shachar Or | שחר אור http://ox.freeallweb.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#490593: Fwd: Re: aptitude -F %t anomaly
-- Forwarded Message -- Subject: Re: aptitude -F [EMAIL PROTECTED] anomaly Date: Sunday 13 July 2008 03:40 From: Daniel Burrows [EMAIL PROTECTED] To: [EMAIL PROTECTED] On Sun, Jul 13, 2008 at 03:04:44AM +0300, Shachar Or [EMAIL PROTECTED] was heard to say: If 'candidate' means 'the version that'll be installed by an aptitude upgrade' then this isn't the case because I run aptitude upgrade and this package stays at it's current version. Yeah, from the code it looks like search picks a version semi-randomly (the first one in the apt cache file). Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] --- -- Shachar Or | שחר אור http://ox.freeallweb.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#490205: please add ttf-liberation to the desktop task
On Thursday 10 July 2008 22:07, Joey Hess wrote: Fabian Greffrath wrote: please add the ttf-liberation font package to the desktop task. I believe that nearly everybody out there installing a desktop system would like to have the free variants of the three infamous MS fonts installed by default. ttf-liberation is already a dependency of openoffice.org, which is already in the desktop task. So there's no need to add it to the task directly. As long as package that use it depend on it. I do wonder why no web browsers currently depend on it.. Is this policy or reason? Sounds strange... -- Shachar Or | שחר אור http://ox.freeallweb.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#490205: please add ttf-liberation to the desktop task
On Friday 11 July 2008 15:22, Joey Hess wrote: Shachar Or wrote: On Thursday 10 July 2008 22:07, Joey Hess wrote: Fabian Greffrath wrote: please add the ttf-liberation font package to the desktop task. I believe that nearly everybody out there installing a desktop system would like to have the free variants of the three infamous MS fonts installed by default. ttf-liberation is already a dependency of openoffice.org, which is already in the desktop task. So there's no need to add it to the task directly. As long as package that use it depend on it. I do wonder why no web browsers currently depend on it.. Is this policy or reason? Sounds strange... What's strange about it? I don't want to have to manually track every dependency that every package in a task needs to work well. If it is appropriate that some package will be part of a task, it seems right to make it part of the task and not via another package's dependency upon it. Because if that other package stops being dependant upon it or is excluded from the task, package 'foo' should still be part of the task. -- Shachar Or | שחר אור http://ox.freeallweb.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#455110: What to do about this bug
Any objections to reassigning this to dpkg and marking it a duplicate of bug #*454628 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=454628*? I think marking 454628 as blocking this one incorrectly describes the relationship, as if 454628 is resolved, this one will be resolved as well. ** Shachar -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#481759: Unreproducible (was: konsole: Backspace behavior breaks aptitude, screen)
Alexander E. Patrakov wrote: tag 481759 unreproducible thanks The testcase with aptitude works for me on amd64. Could you please run the stty command, so that we can compare our output? Mine is: speed 38400 baud; line = 0; -brkint -imaxbel iutf8 My stty is the same and, what's your $TERM? That may be where the trouble lies. I set my bashrc so that if it's xterm, to set it to xterm-color. When I set it to xterm, the problem goes away. This bug does exist, but may be filed against the wrong package. Also, with the latest version of aptitude this problem does not happen. It does happen when working with aptitude from Etch, or when working with screen. What are your konsole settings, in particular, Settings - Keyboard? (or, better, attach $HOME/.kde/share/config/konsolerc) Attached Shachar [$Version] update_info=konsole.upd:kde2.2/r1,konsole.upd:kde3.0/r1 [Desktop Entry] ActiveSession=0 AllowResize=false AutoResizeTabs=false BlinkingCursor=false CtrlDrag=true CutToBeginningOfLine=false DefaultSession=shell.desktop DynamicTabHide=false EnableBidi=true EncodingName=iso 8859-8-i Fullscreen=false Height 800=660 LineSpacing=0 MatchTabWinTitle=false SilenceSeconds=10 TabColor=0,0,0 TabViewMode=0 TerminalSizeHint=true WarnQuit=true Width 1280=1281 XonXoff=false bellmode=0 class=konsole-mainwindow#1 defaultfont=Monospace,10,-1,2,50,0,0,0,0,0 has frame=true history=1000 historyenabled=true keytab=default schema=WhiteOnBlack.schema scrollbar=2 tabbar=2 wordseps=:@-./_~ [TipOfDay] RunOnStart=false TipLastShown=2007,12,9,11,37,5
Bug#479659: RFH: wine -- Windows API implementation
Is this bug still open? Is help still needed? I don't have a huge amount of time, but Wine releases are just once a month, so I doubt that'll be a major problem. I am a Debian developer (http://qa.debian.org/[EMAIL PROTECTED]), where I co-maintain the packages in Debian Hebrew. I also maintain on my own libargtable, rsyncrypto, fakeroot-ng, sshpass and privbind (for all but the first I am also upstream). I am a (currently inactive) Wine hacker, and I subscribe to Ove's point of view vis what is right packaging wise. If you still need help, let me know. Shachar -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#481759: konsole: Backspace behavior breaks aptitude, screen
Package: konsole Version: 4:3.5.9.dfsg.1-2+b1 Severity: important When running aptitude or screen from a shell started inside a konsole terminal, the backspace misbehaves. This is true even if aptitude is used from Sid, Etch or Sarge. When the same versions of aptitude is used from the virtual console or from gnome-terminal, everything is ok. Reproduction steps: Open konsole from the shell, start aptitude press / to start a search type something try to delete it by pressing backspace - nothing happens. Press ctrl-H - the last character is deleted as if backspace was pressed Open konsole from the shell, start screen in that shell, type 12345, and then left arrow twice Press backspace - you would expect the 3 to be deleted. Instead, the 4 is deleted. Press ctrl-H - the three is deleted. This problem actually happens with gnome-terminal as well, but not with the virtual console. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.22-3-686 (SMP w/2 CPU cores) Locale: LANG=he_IL, LC_CTYPE=he_IL (charmap=ISO-8859-8) Shell: /bin/sh linked to /bin/bash Versions of packages konsole depends on: ii kdelibs4c2a 4:3.5.9.dfsg.1-4 core libraries and binaries for al ii libc6 2.7-10 GNU C Library: Shared libraries ii libgcc1 1:4.3.0-3GCC support library ii libqt3-mt 3:3.3.8b-5 Qt GUI Library (Threaded runtime v ii libstdc++6 4.3.0-3 The GNU Standard C++ Library v3 ii libx11-62:1.0.3-7X11 client-side library ii libxrender1 1:0.9.4-1X Rendering Extension client libra konsole recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#466184: icedove: Erronously detecting RSS source as updated
Package: icedove Version: 2.0.0.9-3 Severity: important When icedove is set to update via RSS from Israeli forum site Tapuz (http://tapuz.co.il), each time it tries to update it detects some of the messages in the forum as new, and adds an extra line for them. I have gone over the XML, and while I'm no RSS expert, I saw no server side reason for this behavior that I could detect. A sample URL that exhibits this behavior: http://www.tapuz.co.il/forums/main/rss.asp?forum=284 To reproduce the problem: - Subscribe to the above URL - Click Get Mail - You should get 10 new messages - mark them all read - Click Get Mail again - You should see about 5 of the message duplicate themselves - Click Get Mail again - The other 5 will now duplicate themselves This problem does not happen with the version of icedove that came with Etch. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.22-3-686 (SMP w/2 CPU cores) Locale: LANG=he_IL, LC_CTYPE=he_IL (charmap=ISO-8859-8) Shell: /bin/sh linked to /bin/bash Versions of packages icedove depends on: ii debianutils2.28.2Miscellaneous utilities specific t ii fontconfig 2.5.0-2 generic font configuration library ii libatk1.0-01.20.0-1 The ATK accessibility toolkit ii libc6 2.7-6 GNU C Library: Shared libraries ii libcairo2 1.4.14-1 The Cairo 2D vector graphics libra ii libfontconfig1 2.5.0-2 generic font configuration library ii libfreetype6 2.3.5-1+b1FreeType 2 font engine, shared lib ii libgcc11:4.3-20080116-1 GCC support library ii libglib2.0-0 2.14.5-2 The GLib library of C routines ii libgtk2.0-02.12.5-2 The GTK+ graphical user interface ii libhunspell-1.1-0 1.1.9-1 spell checker and morphological an ii libjpeg62 6b-14 The Independent JPEG Group's JPEG ii libnspr4-0d4.7.0~1.9b1-2 NetScape Portable Runtime Library ii libnss3-1d 3.12.0~1.9b1-2Network Security Service libraries ii libpango1.0-0 1.18.4-1 Layout and rendering of internatio ii libstdc++6 4.3-20080116-1The GNU Standard C++ Library v3 ii libx11-6 2:1.0.3-7 X11 client-side library ii libxft22.1.12-2 FreeType-based font drawing librar ii libxinerama1 1:1.0.2-1 X11 Xinerama extension library ii libxrender11:0.9.4-1 X Rendering Extension client libra ii libxt6 1:1.0.5-3 X11 toolkit intrinsics library ii psmisc 22.6-1Utilities that use the proc filesy ii zlib1g 1:1.2.3.3.dfsg-11 compression library - runtime icedove recommends no packages. -- debconf information: icedove/browser: Debian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#465042: fakeroot-ng: Support for more arches.
Well, I am working on a X86_64 port, but I really don't have access to other platforms even if I had the time. Why don't you get the porting teams interested in the project? Shachar -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#463697: fakeroot-ng failed to change permissions during dpkg-buildpackage with icedove-2.0.0.9-4
Yes, I have already encountered this problem myself. It appears that in Sid, someone changed chown to use the fchownat function. I'm (wearing my upstream cap) working on a solution. Thanks for the report Shachar -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#330670: Can close this bug
I finally got around to looking at implementing this idea. My assertion that you can take the code, verbatim, from strace was a tad optimistic (strace is a horrid mess of #ifdefs). My hope that it can be integrated into the existing fakeroot code is also, I think, a little off. Instead I opened a clean reimplementation of my idea. It does no LD_PRELOAD at all, and works purely externally to the debugged process. The project is available at http://sf.net/projects/fakerootng. Assuming we do not intend to merge the projects, I think we can just close this bug down (or turn it into an RFP for fakeroot-ng and reassign it to WNPP). Shachar -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#457927: xkb-data: wrong mapping for shift+backslash in il keyboard
Package: xkb-data
Version: 0.9-4
Severity: important
Tags: l10n patch
The standard Israeli keyboard dictates that shift+\ produce a pipe ('|')
symbol (just like the US mapping). In the il mapping, however, shift+\
produces \, which renders the shift useless for that key.
the problem does not seem to affect the il-lyx variant.
-- System Information:
Debian Release: 4.0
APT prefers stable
APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-5-686
Locale: LANG=he_IL, LC_CTYPE=he_IL (charmap=ISO-8859-8)
-- no debconf information
--- il 2007-12-27 12:08:57.0 +0200
+++ il.fixed 2007-12-27 12:09:08.0 +0200
@@ -76,7 +76,7 @@
key AD11 { [ bracketright, braceright, 0x10005bf ]}; // Rafe
key AD12 { [ bracketleft, braceleft, 0x10005bd ]}; // Meteg
-key BKSL { [ backslash,backslash, 0x10005bb ]}; // Qubuts
+key BKSL { [ backslash, bar, 0x10005bb ]}; // Qubuts
};
Bug#451899: argtable2 - FTBFS: No rule to make target `distclean'. Stop.
Bastian Blank wrote: make[1]: *** No rule to make target `distclean'. Stop. In a nutshell: Oops! I tried to outsmart the lintian suggestion vis -$(MAKE) distclean. I guess the joke's on me. Shachar -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#441083: sshpass breaks shopt -s checkwinsize
Dwayne Litzenberger wrote: It's more to do with the fact that when run through sshpass, the ssh process is connected to a different TTY than the one used by sshpass and the parent process. If passing SIGWINCH along to ssh is all it will take to make things work, I will gladly do it. If it takes starting to figure out what goes wrong and why, I somewhat doubt I'll invest the time (though, if you write a patch, I'll incorporate the fix into upstream, of course). Oh, it uses a different tty? I think there might be an ioctl that sshpass needs to handle, then. So now you know how the magic is done. I've tagged this bug upstream. I also found the docs I should have read before (tty_ioctl(4), in case you were wondering). I'll see what I can do about this bug. Shachar -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#441083: sshpass breaks shopt -s checkwinsize
Tags: patch
Dwayne Litzenberger wrote:
Oh, it uses a different tty? I think there might be an ioctl that sshpass
needs to handle, then.
Does the following patch solve the problem?
Shachar
Index: main.c
===
--- main.c (revision 28)
+++ main.c (working copy)
@@ -147,10 +147,17 @@
int handleoutput( int fd );
+/* Global variables so that this information be shared with the signal handler */
+static int ourtty; // Our own tty
+static int masterpt;
+
+void window_resize_handler(int signum);
+
int runprogram( int argc, char *argv[] )
{
+struct winsize ttysize; // The size of our tty
// Create a pseudo terminal for our process
-int masterpt=getpt();
+masterpt=getpt();
if( masterpt==-1 ) {
perror(Failed to get a pseudo terminal);
@@ -169,6 +176,13 @@
return 1;
}
+ourtty=open(/dev/tty, 0);
+if( ourtty!=-1 ioctl( ourtty, TIOCGWINSZ, ttysize )==0 ) {
+signal(SIGWINCH, window_resize_handler);
+
+ioctl( masterpt, TIOCSWINSZ, ttysize );
+}
+
int childpid=fork();
if( childpid==0 ) {
// Child
@@ -333,3 +347,11 @@
write( dstfd, \n, 1 );
}
+
+void window_resize_handler(int signum)
+{
+struct winsize ttysize; // The size of our tty
+
+if( ioctl( ourtty, TIOCGWINSZ, ttysize )==0 )
+ioctl( masterpt, TIOCSWINSZ, ttysize );
+}
Bug#441083: sshpass breaks shopt -s checkwinsize
Dwayne Litzenberger wrote: Package: sshpass Version: 1.00-2 Severity: normal When using sshpass in an xterm, the remote shell can't tell when I've resized an xterm. Truth be told, sshpass was mainly designed for non-interactive tasks. Can you please elaborate on the use scenario that led to this problem being relevant? Shachar -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#441083: sshpass breaks shopt -s checkwinsize
Dwayne Litzenberger wrote: IT consulting. Some customers are using password authentication on their machines, and the scenario doesn't warrant setting up public key authentication (users need to be able to deny me access by merely changing their root password). As a side note, I don't see the great problem with them editing the authorized keys file instead. Programs like vim and less aren't responding properly to changing the size of my xterm, which is a pain if I'm watching a log or something like that. The implications of the bug are clear. This is about use scenario. Storing a password in plain text truly is less secure than using private keys (especially with ssh-add), and so I am a bit reluctant to make the use of sshpass as a replacement to public key authentication too easy. My uneducated Well, you knew about SIGWINCH, which I didn't :-) guess is that sshpass isn't passing on SIGWINCH to the ssh process. It's more to do with the fact that when run through sshpass, the ssh process is connected to a different TTY than the one used by sshpass and the parent process. If passing SIGWINCH along to ssh is all it will take to make things work, I will gladly do it. If it takes starting to figure out what goes wrong and why, I somewhat doubt I'll invest the time (though, if you write a patch, I'll incorporate the fix into upstream, of course). - Dwayne Shachar -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#433597: linux-image-2.6.18-4-amd64: Panic with CR2: 0000000000100108 on SATA with software raid-1
Package: linux-image-2.6.18-4-amd64 Version: 2.6.18.dfsg.1-12etch2 Severity: critical Tags: patch Justification: breaks the whole system The problem only happened to me once, and before my last upgrade (with version 2.6.18.dfsg.1-12), but the changelog does not seem to indicate that this problem was solved, so I'm opening the bug report anyways. The machine is running two SATA disks with Raid-1 and LVM. This seems to be relevant to some of the internet discussions I found, though not all of them. I was connected to the machine over SSH (a remote machine) when I got the following messages: Message from [EMAIL PROTECTED] at Tue Jul 17 22:10:04 2007 ... fiasco kernel: Oops: 0002 [1] SMP Message from [EMAIL PROTECTED] at Tue Jul 17 22:10:04 2007 ... fiasco kernel: CR2: 00100108 After that, no user space program would interact with me, but pings still worked. The machine was rebooted by the hosting company, and now seem to be functioning again. Searching the internet I found two discussions that may be relevant. One is http://lists.openwall.net/linux-kernel/2006/11/04/69, which includes a patch, and the other is http://lkml.org/lkml/2006/1/4/196. Since the machine has been up for almost a year before this problem happened, and from the version numbers and frequencies mentioned by Linus, I believe that the first link contains the solution to this problem. Thanks, Shachar -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-amd64 Locale: LANG=en_US.UTF-8, LC_CTYPE=he_IL (charmap=ISO-8859-8) Versions of packages linux-image-2.6.18-4-amd64 depends on: ii coreutil 5.97-5.3The GNU core utilities ii debconf 1.5.11 Debian configuration management sy ii e2fsprog 1.39+1.40-WIP-2006.11.14+dfsg-2 ext2 file system utilities and lib ii initramf 0.85g tools for generating an initramfs ii module-i 3.3-pre4-2 tools for managing Linux kernel mo linux-image-2.6.18-4-amd64 recommends no packages. -- debconf information: linux-image-2.6.18-4-amd64/postinst/kimage-is-a-directory: linux-image-2.6.18-4-amd64/postinst/bootloader-test-error-2.6.18-4-amd64: linux-image-2.6.18-4-amd64/preinst/lilo-initrd-2.6.18-4-amd64: true linux-image-2.6.18-4-amd64/preinst/initrd-2.6.18-4-amd64: linux-image-2.6.18-4-amd64/preinst/failed-to-move-modules-2.6.18-4-amd64: linux-image-2.6.18-4-amd64/postinst/old-initrd-link-2.6.18-4-amd64: true linux-image-2.6.18-4-amd64/preinst/lilo-has-ramdisk: linux-image-2.6.18-4-amd64/postinst/old-dir-initrd-link-2.6.18-4-amd64: true linux-image-2.6.18-4-amd64/prerm/removing-running-kernel-2.6.18-4-amd64: true * linux-image-2.6.18-4-amd64/preinst/already-running-this-2.6.18-4-amd64: linux-image-2.6.18-4-amd64/preinst/abort-install-2.6.18-4-amd64: shared/kernel-image/really-run-bootloader: true linux-image-2.6.18-4-amd64/preinst/abort-overwrite-2.6.18-4-amd64: linux-image-2.6.18-4-amd64/postinst/depmod-error-initrd-2.6.18-4-amd64: false linux-image-2.6.18-4-amd64/postinst/create-kimage-link-2.6.18-4-amd64: true linux-image-2.6.18-4-amd64/postinst/depmod-error-2.6.18-4-amd64: false linux-image-2.6.18-4-amd64/postinst/bootloader-error-2.6.18-4-amd64: linux-image-2.6.18-4-amd64/postinst/old-system-map-link-2.6.18-4-amd64: true linux-image-2.6.18-4-amd64/preinst/bootloader-initrd-2.6.18-4-amd64: true linux-image-2.6.18-4-amd64/preinst/overwriting-modules-2.6.18-4-amd64: true linux-image-2.6.18-4-amd64/preinst/elilo-initrd-2.6.18-4-amd64: true linux-image-2.6.18-4-amd64/prerm/would-invalidate-boot-loader-2.6.18-4-amd64: true -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#427909: apt: should honor 3?? (301, 302 - moved) HTTP return codes
Package: apt Version: 0.6.46.4-0.1 Severity: wishlist I maintain an apt repository (a Debian mirror, actually) that has a considerable amount of users. Recently, due to serious space problems, we had to move the repository to a new server, and due to reasons beyond the scope of this report, this new server has a new address. What I wanted to do was to make sure that the old server return 301 permenantly moved HTTP error code on requests. An http client should honor these requests. In fact, this works well enough for wget and mozilla to use the old URLs without noticing anything changed. Apt, however, does not honor 301, and lists it as error. It is still better for me than the alternative, as it means that the user at least has a hint why things failed. Here's how I think APT should handle these cases: On most of the 300 return codes - get the package from the alternative location. On 301 - Update /etc/apt/sources.list with the new location, leaving the old one commented out with an explanation why it made the change along with a timestamp. This behaviour, as far as I can tell, is backed up by the definition of the 300 codes in the HTTP protocol. -- Package-specific info: -- (no /etc/apt/preferences present) -- -- (/etc/apt/sources.list present, but not submitted) -- -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-686 Locale: LANG=en_US, LC_CTYPE=he_IL (charmap=ISO-8859-8) Versions of packages apt depends on: ii debian-archive-keyring 2007.02.19 GnuPG archive keys of the Debian a ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries ii libgcc1 1:4.1.1-21 GCC support library ii libstdc++6 4.1.1-21 The GNU Standard C++ Library v3 apt recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#427605: ITP: privbind -- Allow unprivileged apps to bind to a privileged port
Russell Coker wrote: On Tuesday 05 June 2007 16:52, Shachar Shemesh [EMAIL PROTECTED] wrote: Package: wnpp Severity: wishlist Owner: Shachar Shemesh [EMAIL PROTECTED] What benefits does this offer over authbind which has been in Debian for ages? It uses a (I think) much more secure mode of operation. In particular: - No SUID executables - User who launches the daemon must be root - Privileges go down, never up And, as a result: - No global configuration necessary (though one will probably be added later if necessary). Shachar -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#427605: ITP: privbind -- Allow unprivileged apps to bind to a privileged port
Russell Coker wrote: On Wednesday 06 June 2007 20:05, Shachar Shemesh [EMAIL PROTECTED] wrote: What benefits does this offer over authbind which has been in Debian for ages? Before I begin answering your questions, the bug report has a link to technical explanation of how privbind is implemented. Have you read it? It uses a (I think) much more secure mode of operation. In particular: - No SUID executables - User who launches the daemon must be root Having a daemon instead of a SUID executable does not inherently make it more secure (there has been no shortage of exploits for bugs in daemons in the past). s/daemon/program that needs low port binding/ privbind does not allow regular users to bind to low ports. Privbind allows root to run program that bind to low port as non-root. The usual system is that a process with UID != 0 can not bind to ports below 1024. Breaking this involves increasing the privileges of some programs. Please read the privbind man page. It does not do what you think it does. And, as a result: - No global configuration necessary (though one will probably be added later if necessary). How can there be no global configuration needed? Please read the privbind man page. It does not do what you think it does. The sysadmin needs to decide which users are granted the privilege to bind to low ports and which ports those users may bind to. Please read the privbind man page. It does not do what you think it does. Shachar -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#427605: ITP: privbind -- Allow unprivileged apps to bind to a privileged port
Package: wnpp Severity: wishlist Owner: Shachar Shemesh [EMAIL PROTECTED] * Package name: privbind Version : 0.2 Upstream Author : Shachar Shemesh [EMAIL PROTECTED] * URL : http://sourceforge.net/projects/privbind * License : GPL Programming Lang: C Description : Allow unprivileged apps to bind to a privileged port This program allows running another program as a non-root user, except the other program will be able to bind to privileged (1024) ports. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-686 Locale: LANG=en_US, LC_CTYPE=he_IL (charmap=ISO-8859-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#427605: ITP: privbind -- Allow unprivileged apps to bind to a privileged port
martin f krafft wrote: How? Could you include a short note on how it does this magic in the description please? I'll do (arguably) better. I'll link to a not so short description at http://privbind.svn.sourceforge.net/viewvc/privbind/trunk/README?view=markup In a nutshell, privbind uses a 100% user space approach that does not rely on SUID executables or on global configs (unlike authbind). Instead, a root process runs privbind, which drops privileges and runs the actual program. Privbind does leave a root process behind, and wraps the program run with a LD_PRELOAD library that intercepts the bind call, and forwards its file descriptor through an open UNIX domain socket to the root process, which carries out the actual bind. Shachar -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#411238: coreutils: cp, ls, possibly others man pages doesn't follow man underline/bold policy
Package: coreutils Version: 5.97-5.3 Severity: minor The following commands use the wrong syntax in their SYNOPSIS section. They soecify specific options that should be typed as shown, and thus should be displayed bold according to the man conventions, as underlined. Command list: install, ln, mv, od, ptx, stty, chcon, runcon, chgrp, chmod, chown, cp, date, du, env Possible problems: fmt For details, see man(1) -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages coreutils depends on: ii libacl1 2.2.42-1 Access control list shared library ii libc6 2.3.6.ds1-10 GNU C Library: Shared libraries ii libselinux1 1.32-3 SELinux shared libraries coreutils recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#411238: Suggested patch for solution
Attached --- /dev/null 2007-02-16 11:08:58.152123001 +0200 +++ debian/patches/99_man_convention 2007-02-17 14:33:24.0 +0200 @@ -0,0 +1,242 @@ +diff -ru ../../tmp/coreutils-5.97/build-tree/coreutils-5.97/man/chcon.1 coreutils-5.97/man/chcon.1 +--- ../../tmp/coreutils-5.97/build-tree/coreutils-5.97/man/chcon.1 2007-02-17 14:27:27.0 +0200 coreutils-5.97/man/chcon.1 2007-02-17 14:13:57.0 +0200 +@@ -6,7 +6,7 @@ + [\fIOPTION\fR]...\fI CONTEXT FILE\fR... + .br + .B chcon +-[\fIOPTION\fR]...\fI --reference=RFILE FILE\fR... ++[\fIOPTION\fR]... \fB--reference=\fIRFILE FILE\fR... + .SH DESCRIPTION + .PP + . Add any additional description here +diff -ru ../../tmp/coreutils-5.97/build-tree/coreutils-5.97/man/chgrp.1 coreutils-5.97/man/chgrp.1 +--- ../../tmp/coreutils-5.97/build-tree/coreutils-5.97/man/chgrp.1 2007-02-17 14:29:52.0 +0200 coreutils-5.97/man/chgrp.1 2007-02-17 14:15:50.0 +0200 +@@ -7,7 +7,7 @@ + [\fIOPTION\fR]... \fIGROUP FILE\fR... + .br + .B chgrp +-[\fIOPTION\fR]... \fI--reference=RFILE FILE\fR... ++[\fIOPTION\fR]... \fB--reference=\fIRFILE FILE\fR... + .SH DESCRIPTION + .\ Add any additional description here + .PP +diff -ru ../../tmp/coreutils-5.97/build-tree/coreutils-5.97/man/chmod.1 coreutils-5.97/man/chmod.1 +--- ../../tmp/coreutils-5.97/build-tree/coreutils-5.97/man/chmod.1 2007-02-17 14:29:52.0 +0200 coreutils-5.97/man/chmod.1 2007-02-17 14:16:36.0 +0200 +@@ -4,13 +4,13 @@ + chmod \- change file access permissions + .SH SYNOPSIS + .B chmod +-[\fIOPTION\fR]... \fIMODE\fR[\fI,MODE\fR]... \fIFILE\fR... ++[\fIOPTION\fR]... \fIMODE\fR[\fB,\fIMODE\fR]... \fIFILE\fR... + .br + .B chmod + [\fIOPTION\fR]... \fIOCTAL-MODE FILE\fR... + .br + .B chmod +-[\fIOPTION\fR]... \fI--reference=RFILE FILE\fR... ++[\fIOPTION\fR]... \fB--reference=\fIRFILE FILE\fR... + .SH DESCRIPTION + This manual page + documents the GNU version of +diff -ru ../../tmp/coreutils-5.97/build-tree/coreutils-5.97/man/chown.1 coreutils-5.97/man/chown.1 +--- ../../tmp/coreutils-5.97/build-tree/coreutils-5.97/man/chown.1 2007-02-17 14:29:52.0 +0200 coreutils-5.97/man/chown.1 2007-02-17 14:17:29.0 +0200 +@@ -4,10 +4,10 @@ + chown \- change file owner and group + .SH SYNOPSIS + .B chown +-[\fIOPTION\fR]... [\fIOWNER\fR][\fI:\fR[\fIGROUP\fR]] \fIFILE\fR... ++[\fIOPTION\fR]... [\fIOWNER\fR][\fB:\fR[\fIGROUP\fR]] \fIFILE\fR... + .br + .B chown +-[\fIOPTION\fR]... \fI--reference=RFILE FILE\fR... ++[\fIOPTION\fR]... \fB--reference=\fIRFILE FILE\fR... + .SH DESCRIPTION + This manual page + documents the GNU version of +diff -ru ../../tmp/coreutils-5.97/build-tree/coreutils-5.97/man/cp.1 coreutils-5.97/man/cp.1 +--- ../../tmp/coreutils-5.97/build-tree/coreutils-5.97/man/cp.1 2007-02-17 14:27:28.0 +0200 coreutils-5.97/man/cp.1 2007-02-17 13:54:38.0 +0200 +@@ -10,7 +10,7 @@ + [\fIOPTION\fR]... \fISOURCE\fR... \fIDIRECTORY\fR + .br + .B cp +-[\fIOPTION\fR]... \fI-t DIRECTORY SOURCE\fR... ++[\fIOPTION\fR]... \fB-t\fR \fIDIRECTORY SOURCE\fR... + .SH DESCRIPTION + .\ Add any additional description here + .PP +diff -ru ../../tmp/coreutils-5.97/build-tree/coreutils-5.97/man/date.1 coreutils-5.97/man/date.1 +--- ../../tmp/coreutils-5.97/build-tree/coreutils-5.97/man/date.1 2007-02-17 14:29:52.0 +0200 coreutils-5.97/man/date.1 2007-02-17 14:19:16.0 +0200 +@@ -4,10 +4,10 @@ + date \- print or set the system date and time + .SH SYNOPSIS + .B date +-[\fIOPTION\fR]... [\fI+FORMAT\fR] ++[\fIOPTION\fR]... [\fB+\fIFORMAT\fR] + .br + .B date +-[\fI-u|--utc|--universal\fR] [\fIMMDDhhmm\fR[[\fICC\fR]\fIYY\fR][\fI.ss\fR]] ++[\fB-u\fR|\fB--utc\fR|\fB--universal\fR] [\fIMMDDhhmm\fR[[\fICC\fR]\fIYY\fR][\fB.\fIss\fR]] + .SH DESCRIPTION + .\ Add any additional description here + .PP +diff -ru ../../tmp/coreutils-5.97/build-tree/coreutils-5.97/man/du.1 coreutils-5.97/man/du.1 +--- ../../tmp/coreutils-5.97/build-tree/coreutils-5.97/man/du.1 2007-02-17 14:29:53.0 +0200 coreutils-5.97/man/du.1 2007-02-17 14:20:17.0 +0200 +@@ -7,7 +7,7 @@ + [\fIOPTION\fR]... [\fIFILE\fR]... + .br + .B du +-[\fIOPTION\fR]... \fI--files0-from=F\fR ++[\fIOPTION\fR]... \fB\-\-files0\-from=\fIF\fR + .SH DESCRIPTION + .\ Add any additional description here + .PP +diff -ru ../../tmp/coreutils-5.97/build-tree/coreutils-5.97/man/env.1 coreutils-5.97/man/env.1 +--- ../../tmp/coreutils-5.97/build-tree/coreutils-5.97/man/env.1 2007-02-17 14:29:53.0 +0200 coreutils-5.97/man/env.1 2007-02-17 14:21:28.0 +0200 +@@ -4,7 +4,7 @@ + env \- run a program in a modified environment + .SH SYNOPSIS + .B env +-[\fIOPTION\fR]... [\fI-\fR] [\fINAME=VALUE\fR]... [\fICOMMAND \fR[\fIARG\fR]...] ++[\fIOPTION\fR]... [\fB\-\fR] [\fINAME\fB=\fIVALUE\fR]... [\fICOMMAND \fR[\fIARG\fR]...] + .SH DESCRIPTION + .\ Add any additional description here + .PP +Only in coreutils-5.97/man: .fmt.1.swp +diff -ru
Bug#398898: lintian: zero-byte-file-in-doc-directory bogus complain on files in examples
Package: lintian Version: 1.23.25 Severity: normal Rsyncrypto is a package that performs rsync friendly encryption. The package comes bundled with a tests directory, that gets installed into /usr/share/doc/rsyncrypto/examples/tests. This directory contains known plain texts, cipher texts and keys so that regression testing and comparisons can be run. Some of the files in said directory are records of when the internal decision function decided to perform an IV reset. For some of the regression testing files (reg1 and reg2), this file is empty. When running version 0.18-1 (the version that introduced the tests direcotry under examples) through lintian, I get the complaint: O: rsyncrypto: zero-byte-file-in-doc-directory usr/share/doc/rsyncrypto/examples/tests/reg1.rot O: rsyncrypto: zero-byte-file-in-doc-directory usr/share/doc/rsyncrypto/examples/tests/reg2.rot (as you can see, I did an override). I believe that the override is unnecessary, and the files under /usr/share/doc/*/examples should not be checked for non-emptyness. -- 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.17-2-686 Locale: LANG=en_US, LC_CTYPE=he_IL (charmap=ISO-8859-8) Versions of packages lintian depends on: ii binutils 2.17-3The GNU assembler, linker and bina ii diffstat 1.43-2produces graph of changes introduc ii dpkg-dev 1.13.22 package building tools for Debian ii file 4.17-4Determines file type using magic ii gettext0.14.6-1 GNU Internationalization utilities ii intltool-debian0.35.0+20060710.1 Help i18n of RFC822 compliant conf ii libparse-debianchangel 1.0-1 parse Debian changelogs and output ii man-db 2.4.3-3 The on-line manual pager ii perl [libdigest-md5-pe 5.8.8-6.1 Larry Wall's Practical Extraction lintian recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#397295: ITP: bitefusion -- Simple 15 level snake game
Package: wnpp Severity: wishlist Owner: Shachar Shemesh [EMAIL PROTECTED] * Package name: bitefusion Version : 1.0.1 Upstream Author : JC3¸rgen Jacobsen [EMAIL PROTECTED] and Morten Hustveit [EMAIL PROTECTED] * URL : http://www.junoplay.com/ * License : GPL Programming Lang: C Description : Simple 15 level snake game A snake game with 15 levels. Great if you need to shut off your brain for a few minutes and occupy your hands in the meantime. Guaranteed no adrenaline rush! -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-2-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Bug#380711: ITP: thunderbird-bidiui -- BiDirectional extension (Hebrew and Arabic, support) for thunderbird
Package: wnpp Severity: wishlist Owner: Shachar Shemesh [EMAIL PROTECTED] * Package name: thunderbird-bidiui Version : x.y.z Upstream Author : Name [EMAIL PROTECTED] * URL : http://www.example.org/ * License : (GPL, LGPL, BSD, MIT/X, etc.) Programming Lang: (C, C++, C#, Perl, Python, etc.) Description : BiDirectional extension (Hebrew and Arabic support) for thunderbird The Thunderbird BiDi extension is located at http://bidiui.mozdev.org/index.html. It enables controlling the paragraph direction when writing emails containing text with bidirectional languages (such as Hebew or Arabic). -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-2-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#378654: Missing upstream copyright holder name in /usr/share/doc/busybox/copyright
Package: busybox Version: 1:1.1.3-2 Severity: serious Tags: patch Justification: Policy 12.5 The Debian policy requires the copyright file to hold the upstream copyright information. I know that it is an agregate of many packages, each with its own author, thus making copyright asertion difficult. I know that the upstream author of the actual agregate package is also the Debian package maintainer. A suggested fix is in the attached patch -- 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.15-1-686 Locale: LANG=en_US, LC_CTYPE=he_IL (charmap=ISO-8859-8) Versions of packages busybox depends on: ii libc6 2.3.6-15 GNU C Library: Shared libraries busybox recommends no packages. -- no debconf information --- debian/copyright.orig 2006-07-18 06:26:25.0 +0300 +++ debian/copyright2006-07-18 06:29:38.0 +0300 @@ -3,6 +3,11 @@ It was downloaded from ftp://ftp.busybox.net/busybox +Busybox is an agregate of multiple packages. These packages are copyrighted +by their respective authors. + +Busybox itself is Copyright (C) 1999-2005 by Erik Andersen + Copyright: This package is free software; you can redistribute it and/or modify
Bug#358617: linux-image-2.6.15-1-686: Seems like we have a duplicate
Package: linux-image-2.6.15-1-686 Version: 2.6.15-8 Followup-For: Bug #358617 It seems that this bug is a duplicate of #347468 -- 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.15-1-686 Locale: LANG=en_US, LC_CTYPE=he_IL (charmap=ISO-8859-8) Versions of packages linux-image-2.6.15-1-686 depends on: ii initramfs-tools [linux-initra 0.60 tools for generating an initramfs ii module-init-tools 3.2.2-3tools for managing Linux kernel mo Versions of packages linux-image-2.6.15-1-686 recommends: ii libc6-i6862.3.6-13 GNU C Library: Shared libraries [i -- debconf information excluded -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#324263: openvpn: Openvpn terminates in case of interrupted system call
David L. Anselmi wrote: Hi, I notice this behavior in openvpn 2.0.6, except that it is what gets logged after running: /etc/init.d/openvpn stop Could it be that your bug reports normal behavior when openvpn receives a TERM signal? No. The problem happened when no one was doing anything at all with the daemon. It is possible that the TERM signal also triggers the same behaviour. In that case could you close the bug? That is not the case. Then again, I didn't get this problem lately. Maybe it was solved by upstream? Checking again, sending SIGSTOP to the process, followed by SIGCONT, I get Interrupted system call, but openvpn does not terminate. I think we can say that this bug is resolved, probably by upstream. Shachar -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#354800: ITP: sshpass -- SSH wrapper for non-interactive interactive keyboard password authentication
Package: wnpp Severity: wishlist Owner: Shachar Shemesh [EMAIL PROTECTED] * Package name: sshpass Version : 0.02 Upstream Author : Shachar Shemesh [EMAIL PROTECTED] * URL : http://sourceforge.net/projects/sshpass * License : GPL Description : SSH wrapper for non-interactive interactive keyboard password authentication SSH's (secure shell) most common authentication mode is called interactive keyboard password authentication, so called because both because it is typically done via keyboard, and because openssh takes active measures to make sure that the password is, indeed, typed interactively by the keyboard. Sometimes it is necessary, however, to fool ssh into accepting an interactive password non-interactively. This is where sshpass comes in. . SECURITY NOTE: There is a reason openssh insists that passwords be typed interactively. Passwords are harder to store securely and to pass around securely between programs. If you have not looked into solving your needs using SSH's public key authentication, perhaps in conjunction with the ssh agent (RTFM ssh-add), please do so before being tempted into using this package. -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.8-2-686 Locale: LANG=en_US, LC_CTYPE=he_IL (charmap=ISO-8859-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339028: chicken-setup tries to load libchicken.so (dependency problem)
Package: chicken Version: 1.63-2 Severity: grave Justification: renders package unusable chicken-setup tries to load libchicken.so (as opposed to libchicken.so.0. This file is only available if chicken-dev is installed. Either chicken-setup is moved into chicken-dev, or the incorrect load is fixed. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.8-2-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages chicken depends on: ii libc6 2.3.5-7GNU C Library: Shared libraries an ii libpcre3 6.4-1.0.1 Perl 5 Compatible Regular Expressi chicken recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#337392: Chicken missing directory bug
Trent Buck Wrote: This is trivial to fix by changing usr/lib in debian/chicken.dirs to usr/lib/chicken (unconfirmed, still building). Actually, according to the FHS (http://www.pathname.com/fhs/pub/fhs-2.3.html#THEUSRHIERARCHY), /usr/lib should be read-only and shareable between installations. It is not right to write to it not as part of a package installation. I'm not familiar enough with chicken to suggest a definitive alternative, but either /usr/local/lib/chicken or /var/lib/chicken should do better (probably the former). Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336039: Incorrect upstream download address in /usr/share/doc/usbutils/copyright
Package: usbutils Version: 0.71-6 Severity: serious Justification: Policy 12.5 The upstream location of the package points to http://usb.cs.tum.edu/download/usbutils/. However, since around version 0.11, the correct address should be either http://www.linux-usb.org/ or (if direct download link is preferred) http://sourceforge.net/project/showfiles.php?group_id=3581package_id=142529 -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-1-686-smp Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages usbutils depends on: ii libc6 2.3.5-7 GNU C Library: Shared libraries an ii libusb-0.1-42:0.1.10a-21 userspace USB programming library usbutils recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333055: ITP: xparam -- a general-purpose librariy for parameter handling in C++
Package: wnpp Severity: wishlist Owner: Shachar Shemesh [EMAIL PROTECTED] * Package name: xparam Version : 1.22 Upstream Author : Ronnie Maor and Michael Brand [EMAIL PROTECTED] * URL : http://xparam.sourceforge.net/ * License : Revised GPL, LGPL compatibile Description : a general-purpose librariy for parameter handling in C++ XParam is an extensible, type-safe, non-intrusive, object-oriented tool for general-purpose object serialization and deserialization in C++, good for parsing command-line parameters and cross-program/cross-platform communication. It can handle named parameters as well as object streams. It recognizes class hierarchies, abstract interfaces, and polymorphism, and can therefore serve as a plug-in management framework -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.8-2-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#330670: A suggested method for fakeroot to handle open and chroot
Clint Adams wrote: As things stand, most of the cross-platform work we need to do can be copied, almost verbatim, from strace. Have you started any code? Sadly, no. I doubt I'll have time for that in the near future, much though I'd like to :-( -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#330670: A suggested method for fakeroot to handle open and chroot
Package: fakeroot Version: 1.2.10 Severity: wishlist Revise the method in which fakeroot communicates with the faked daemon: - The library will not override any of the libc symbols. Instead, a syscall type table is held inside. - During the preload stage, fakeroot opens a socket/whatever to the daemon, and asks it to ptrace the process. It also passes the daemon the address of the symbol table. - The daemon knows what socket number the process uses to communicate with it (probably a high value to avoid collision. We'll assume it's 510). - Whenever a write with fd 510 is registered at the debugging daemon, the content is pulled from the process memory and placed in the appropriate registers. This allows the library to perform system calls directly. - (Almost) any other syscall is redirected to the library for interception and possibly replacement. Advantages: - Can intercept open without races. - Can emulate chroot. - Can emulate root for statically linked and non-standard executeables. - Can kill all faked processes when the daemon is killed. - Can emulate a no-LD_PRELOAD environment (remove variable on SO load, restore it upon execve). Also - can make sure that our LD_PRELOAD is always first. Disadvantages: - Performance? Probably not serious, as only syscalls will ever trigger a ptrace breakpoint. - Will probably cause problems for recursive debuggers (i.e. - cannot run strace inside fakeroot). -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.8-2-686 Locale: LANG=en_US, LC_CTYPE=he_IL (charmap=ISO-8859-8) Versions of packages fakeroot depends on: ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#330670: A suggested method for fakeroot to handle open and chroot
Clint Adams wrote: - During the preload stage, fakeroot opens a socket/whatever to the daemon, and asks it to ptrace the process. It also passes the daemon the address of the symbol table. Is there a reason to preload a library for this instead of having a program which establishes communication with faked and then ptraces its child? It's theoretically possible to do it without a preload, but some things become much more difficult: 1. Without a local agent, i.e. - without our code running in the program's context, several things become much more difficult and platform dependent. Things like changing parameters, calling the syscall and then changing the results back are somewhat hairy to do from another process. Things like turning a single syscall into several become an exercise in agility that will be very hard to perform in a cross-platform way. 2. Making sure we remain attached after fork and exec isn't trivial (though possible, I guess). As things stand, most of the cross-platform work we need to do can be copied, almost verbatim, from strace. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#324263: openvpn: Openvpn terminates in case of interrupted system call
Package: openvpn Version: 2.0-1 Severity: important Openvpn occasionally terminates. The log file right prior to the termination has this to offer: Aug 18 13:08:25 angelina ovpn-server[3574]: event_wait : Interrupted system call (code=4) Aug 18 13:08:25 angelina ovpn-server[3574]: TCP/UDP: Closing socket Aug 18 13:08:25 angelina ovpn-server[3574]: /sbin/route del -net 10.255.1.0 netmask 255.255.255.0 Aug 18 13:08:25 angelina ovpn-server[3574]: ERROR: Linux route delete command failed: shell command exited with error status: 7 Aug 18 13:08:25 angelina ovpn-server[3574]: Closing TUN/TAP interface Aug 18 13:08:25 angelina ovpn-server[3574]: SIGTERM[hard,] received, process exiting It seems that openvpn mis-handles an interrupter syscall return type, and terminates. This seems like an oversight on behalf of the openvpn upstream. -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.8-2-686-smp Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages openvpn depends on: ii debconf 1.4.30.13Debian configuration management sy ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an ii liblzo1 1.08-1.2 A real-time data compression libra ii libssl0.9.7 0.9.7e-3 SSL shared libraries -- debconf information: openvpn/change_init: true openvpn/create_tun: false * openvpn/stop2upgrade: false openvpn/default_port: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#306755: ITP: argtable -- a cross platform ANSI C library for parsing GNU style command line arguments
Package: wnpp Severity: wishlist Owner: Shachar Shemesh [EMAIL PROTECTED] * Package name: argtable Version : 2.4 Upstream Author : Stewart Heitmann [EMAIL PROTECTED] * URL : http://argtable.sourceforge.net/ * License : LGPL Description : a cross platform ANSI C library for parsing GNU style command line arguments Argtable is an ANSI C library for parsing GNU style command line options with a minimum of fuss. It enables a program's command line syntax to be defined in the source code as an array of argtable structs. The command line is then parsed according to that specification and the resulting values are returned in those same structs where they are accessible to the main program. Both tagged (-v, --verbose, --foo=bar) and untagged arguments are supported, as are multiple instances of each argument. Syntax error handling is automatic and the library also provides the means for generating a textual description of the command line syntax. Argtable is identical in user experience to GNU getopt_long (and is, in fact, based on it), but runs on all posix platforms, Windows and Mac OSX. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.8-2-686 Locale: LANG=C, LC_CTYPE=he_IL (charmap=ISO-8859-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
