Bug#698640: gvfs-bin: gfvs-trash can not trash on fs that is bind mounted

; On Sat, 05 Aug 2023 at 06:30:01 +0200, Christian Pernegger wrote: > > Funnily enough this used to work, in fact it still does work if you > > remove the checks. It'll find a location to trash to (in the root of > > the mount/subvolume) just fine; and if it doesn't it error

Bug#698640: gvfs-bin: gfvs-trash can not trash on fs that is bind mounted

FWIW, the code that is responsible is in libglib2.0-0. Reasonably recent versions will refuse to use the trash on * mounted drives. I.e. I have a separate drive for bulk storage mounted via fstab on a directory in my home directory, no go. * btrfs subvolumes, even just somewhere under my home

Bug#907812: /sbin/mount.cifs: POSIX ACLs only work with vers=1.0 or noperm

Package: cifs-utils Version: 2:6.8-2 Severity: normal File: /sbin/mount.cifs Hello, a while back there was a change in the default protocol version for cifs mounts. That broke one use case of mine, where I mount a share [on Samba from Debian stable] for a specific user, whose permissions

Bug#871569: installation-reports: offline machine, install from ISO images -- use case feels neglected

inds me of physical copies of Steam games ...) It's possible that sets of fixed-size images aren't the right approach for today, maybe a few boot images plus signed "mirror dumps" in various sizes are the way to go, but in any case I believe that (mostly) offline systems should st

Bug#807996: /usr/bin/apt-cdrom: Re: apt: "apt-get update" gives 'repository cdrom://... does not have a Release file' warning

is it, anyway? Do the images not have the necessary files (why?), does apt-cdrom not handle them correctly ...? Regards, Christian Pernegger

Bug#858852: sabnzbdplus: new upstream version(s) 1.2.3/2.0.0RC1

Package: sabnzbdplus Version: 1.1.1+dfsg-1 Severity: wishlist Hi, I just wanted to give you a heads-up that 1.2.3 is out and 2.0.0 around the corner. The latter apparenly includes an optional binary module that should speed up yEnc decoding -- it'd be nice if that became part of the Debian

Bug#823664: Fwd: Debian security status of crabtree

Hello Michael, no, it seems to be fine now. The phantom kernel update appeared for the last time in the e-mail dated June 4th (CEST). Thank you, Christian 2016-11-14 9:45 GMT+01:00 Michael Stapelberg <stapelb...@debian.org>: > control: tags -1 + moreinfo > > Hi Christian

Bug#815927: bridge+bond has some limits

Hello, I'm not saying it isn't a kernel issue, but even if it were a kernel issue it could be worked around in the tools / in their Debian integration. Some boots everything does come up up ok, bar the error messages already quoted; other times there is no connectivity until the bridge (and

Bug#836932: login to blank screen after upgrade to 0.9

Hello again! > So the problem is neither xrdp nor the X server. I'll concede that testing might be horribly broken at the moment, especially in the GTK3 department. But considering MATE, xfce4 and LXDE all work for local logins, but under xrdp 0.9 MATE and LXDE give an empty background and xrdp4

Bug#840132: xrdp-sesman.service sometimes fails to start on boot

Hello, reportbug did notify me about a newer version, however the newest one to be downloaded via packages.debian.org (yes, for unstable) was still the one I had. I'll get around to testing newer versions eventually, but for now I'm back on 0.6.1. At least that one more or less works (w/ xfce)

Bug#836932: login to blank screen after upgrade to 0.9

Hello, I really don't know what to tell you, I've no idea where to even start debugging this ... Yes, I get an X server process and lots of session related ones -- it's running, just not on my xrdp screen. No, I hadn't read the new README.Debian, but I can't see how it's relevant, as I'm using

Bug#840132: xrdp-sesman.service sometimes fails to start on boot

Package: xrdp Version: 0.9.0~20160601+git703fedd-3 Severity: normal Hello, since xrdp still doesn't work for me I've been doing a lot of experiments to get it to cooperate, including a lot of rebooting to get back to a clean slate. I've noticed that sesman doesn't always start automatically on

Bug#826534: reportbug xrdp gives: IndexError: list index out of range

See #836583 for a potential fix. Cheers, C.

Bug#836583: "reportbug xrdp" fails

Hello, since, in my experience, trying stuff on a fresh sid install has never fixed anything, I dug a little deeper. Turns out the xrdp upgrade (0.6 branch --> 0.9 branch) had left a conffile mess in /etc/pam.d: sesman.orig xrdp-sesman -> sesman [dangling symlink] xrdp-sesman.dpkg-new Removing

Bug#836932: login to blank screen after upgrade to 0.9

Package: xrdp Version: 0.9.0~20160601+git703fedd-3 Hi again, so I've had the previous xrdp (0.6.1?) and vnc4server working flawlessly for months but with vnc4server dropped from testing and the X backend supposedly so much better than VNC I decided to take the plunge and upgrade to 0.9. No joy.

Bug#836586: unknown external IP in xrdp.log after upgrade?!?

2016-09-05 11:01 GMT+02:00 Dominik George : >> Yes, it's connected to the internet, no it's not reachable from >> outside the LAN (on any port). > > Can you please double-check that? I've a dedicated jessie box on firewall / NAT router duty, no forwarded ports. I can't rule

Bug#836586: unknown external IP in xrdp.log after upgrade?!?

> Are you sure this is in fact the one connection you are closing? I don't see what else it could be, certainly nothing legitimate. The only access to the box was me testing xrdp, running a tail -f alongside. > Is the system connected to the internet (and reachable from there on the RDP > port)?

Bug#836586: unknown external IP in xrdp.log after upgrade?!?

Package: xrdp Version: 0.9.0~20160601+git703fedd-3 Tags: security Hi, while trying to debug why xrdp has stopped working here after the upgrade to 0.9 -- login works fine but dumps one in front of an empty solid teal screen instead of the expected MATE session --, I stumbled across the following

Bug#836583: "reportbug xrdp" fails

warnings.warn(str(e), _gtk.Warning) *** Welcome to reportbug. Use ? for help at prompts. *** Note: bug reports are publicly archived (including the email address of the submitter). Detected character set: UTF-8 Please change your locale if this is incorrect. Using 'Christian Pernegger <perneg...@gmail.

Bug#823493: A20-OLinuXIno-LIME2 also affected

ion, but as a stopgap it's fine. Cheers, C. 2016-05-11 13:42 GMT+02:00 Ben Hutchings <b...@decadent.org.uk>: > Control: tag -1 important > > On Wed, 2016-05-11 at 10:37 +0200, Christian Pernegger wrote: >> Hi, >> >> I just wanted to say that this bug broke my LIME2 as well, in a

Bug#823493: A20-OLinuXIno-LIME2 also affected

Hi, I just wanted to say that this bug broke my LIME2 as well, in a get the ladder out, retrieve box, open it, and attach serial cable kind of way. A lot of the boards affected will be just as headless (for the A20 at least Debian doesn't even have a local console by default, much less a graphics

Bug#823664: Fwd: Debian security status of crabtree

This is the most recent e-mail. (Still no update in sight.) Thank you, Christian -- Forwarded message -- From: Date: 2016-05-09 2:00 GMT+02:00 Subject: Debian security status of crabtree To: r...@crabtree.southpark.chp Security report based on the jessie

Bug#816272: [Pkg-clamav-devel] Bug#816272: clamav-freshclam: logrotate errors out with "gzip: stdin: file size changed while zipping"

2016-05-06 23:56 GMT+02:00 Sebastian Andrzej Siewior < sebast...@breakpoint.cc>: > The question is now, what did you do to make the logrotate message go > away? Was it the upgrade to current stable or something else? Ok, now I've got it, sorry. The problem did occur until shortly before the

Bug#823664: debsecan: reports new and available kernel security updates that, well, aren't

Package: debsecan Version: 0.4.17 Severity: normal Hi, the nightly e-mail report lists both "new security updates" and "available security updates" for linux-image-3.16.0-4-amd64, with multiple issues each. However, aptitude insists everything is current. At first I thought, something's just

Bug#816272: clamav-freshclam: logrotate errors out with "gzip: stdin: file size changed while zipping"

astian Andrzej Siewior < sebast...@breakpoint.cc>: > On 2016-04-05 10:43:13 [+0200], Christian Pernegger wrote: > > Hi, > Hi, > > > no error e-mail this week, yay! > > > > It looks like this is/was a duplicate of #788652 in the end (at least > > the

Bug#719624: Upgrading xrdp

Hi, might I suggest keeping the old and new xrdp packages in parallel for a while? Maybe call the latter xrdp-git, then fold it into xrdp once there is a release? It sounds to me like there were quite a lot of (upstream) changes between the two and I'm not sure how clean the upgrade path is,

Bug#816272: [Pkg-clamav-devel] Bug#816272: Bug#816272: clamav-freshclam: logrotate errors out with "gzip: stdin: file size changed while zipping"

Hi, no error e-mail this week, yay! It looks like this is/was a duplicate of #788652 in the end (at least the clamav-freshclam part of it). If you agree, please close & merge as appropriate. Thank you, Christian

Bug#820069: dhcpcd5: configures interface without being asked to

Package: dhcpcd5 Version: 6.0.5-2 Severity: normal Hi, this box has its network interface configured statically in /etc/network/interfaces. dhcpcd5 is installed but should not be active at this time. (I would have liked to use DHCP, but neither dhcpcd5 nor isc-dhcp-client work properly on a

Bug#819896: sabnzbdplus: new upstream version (1.0.0)

Package: sabnzbdplus Version: 0.7.20+dfsg-1 Severity: wishlist Dear Maintainer, I'd love to see the Debian package(s) updated to the newly released 1.0.0. Regards, Christian -- System Information: Debian Release: stretch/sid APT prefers testing-updates APT policy: (500,

Bug#811473: systemd: timer with WakeSystem=yes doesn't always start the service it's supposed to trigger

l wakes up every night but hasn't triggered for 3 days in a row). Nothing pertinent in the journal even at log-level debug. Cheers, C. 2016-01-29 15:54 GMT+01:00 Christian Pernegger <perneg...@gmail.com>: > Hello, > > it seems like 216 has a change that might affect this, namely g

Bug#819370: Acknowledgement (rdiff-backup: does not follow symlinks to directories given on the command line)

Hi, the same error occurs on local-to-local runs if the source is a symlink (to a directory), so it's a regression, if in fact it ever did work. What confused me at first was the check via rpin.isdir() in Main.py, which at first glance looks like Pythons's os.path.isdir(), which does follow

Bug#819370: rdiff-backup: does not follow symlinks to directories given on the command line

Package: rdiff-backup Version: 1.2.8-7 Severity: normal Hi, I'm trying to backup a path that ends in a symlink (pointing to a directory) *from* a remote machine. This fails on the remote side: Fatal Error: Source /.snapshots/latest is not a directory (Note that adding a trailing slash to the

Bug#816272: [Pkg-clamav-devel] Bug#816272: Bug#816272: clamav-freshclam: logrotate errors out with "gzip: stdin: file size changed while zipping"

Hi again, sorry for the delay. TBH I was hoping againt hope that this'll just go away. I've gotten two more error e-mails in the meantime: 21st: /etc/cron.daily/logrotate: error: error running non-shared postrotate script for /var/log/clamav/freshclam.log of '/var/log/clamav/freshclam.log '

Bug#818940: mate-tweak: doesn't start [No module named 'gi']

Package: mate-tweak Version: 3.5.7-1 Severity: important Hi, mate-tweak fails to launch for me: chris@fatbeard:~$ mate-tweak Traceback (most recent call last): File "/usr/bin/mate-tweak", line 24, in import gi ImportError: No module named 'gi' Regards, Christian -- System

Bug#818936: xrdp: pam config should behave more like a "normal" local session

Package: xrdp Version: 0.6.1-2+b1 Severity: normal Hi, /etc/pam.d/sesman is rather bare bones at the moment, silently breaking things under xrdp-sesman that work fine when logged in locally. For instance libpam-gnome-keyring doesn't work. For now I've copied lightdm's pam config file over

Bug#818880: dhcpcd5: sometimes removes route to local network on wakeup

Package: dhcpcd5 Version: 6.9.3-1 Severity: important Hi, I've a couple of systems that spend a lot of time in suspend and should ideally use DHCP for network configuration. isc-dhcp client doesn't work in that scenario because it'll never renew the lease (#812186), so I switched to dhcpcd5.

Bug#812186: isc-dhcp-client: does not renew lease (poss. interaction w/ systemd suspend/resume)

Package: isc-dhcp-client Version: 4.3.3-8 Followup-For: Bug #812186 Hi, I'd just wanted to add that - version 4.3.3-8 (currently in testing) still has this problem - dhcpcd5 works fine So I'm switching my affected machines to dhcpcd5 for now, but in the long rung I'd like to stay with the

Bug#818526: xrdp: says it's using local keymap even when it isn't (incl. workaround)

Package: xrdp Version: 0.6.1-2+b1 Severity: normal Hi, I installed xrdp, connected from Ubuntu 15.10 (Wily) using whatever remote desktop client is in their default install ... -- and it worked. Even the German keyboard layout, umlauts and everything. From prior experience with VNC-based

Bug#818152: [Pkg-xfce-devel] Bug#818152: lightdm: can no longer manage multiple X servers

2016-03-14 17:20 GMT+01:00 Yves-Alexis Perez : > First you should try to investigate whether it's possible to port your setup > to logind. I've found an ugly workaround: 1) Start the Xvnc instances standalone (e.g.via systemd). 2) Add lightdm to them using "dm-tool

Bug#818268: libc-bin: provide a (debconf) setting to revert to previous default of preferring IPv4 addresses

Package: libc-bin Version: 2.21-9 Severity: normal Tags: ipv6 Hi, on my jessie systems localhost resolves to 127.0.0.1 (expected), on this stretch one it it's ::1 (unexpected). The latter also breaks services that don't listen on IPv6, so calling up "http://localhost:8080/; in iceweasel, for

Bug#818243: netbase: localhost resolves to IPv6 by default

Package: netbase Version: 5.3 Severity: normal Dear Maintainer, first of all, I do apologise if I got the wrong package, please move as appropriate. This is so basic I didn't know where to start. On this newly installed stretch system localhost resolves to '::1' by default, making local servers

Bug#818152: lightdm: can no longer manage multiple X servers

Package: lightdm Version: 1.16.7-1 Severity: important Tags: upstream Hello, I've just spent the better part of a day trying to get lightdm to spawn multiple instances as suggested in the config file and various older forum posts and howtos -- just to finally find out that it doesn't do that

Bug#818084: cinnamon-session: starting session fails if nm-applet (network-manager-gnome) is not installed

Package: cinnamon-session Version: 2.8.2-1 Severity: normal Dear Maintainer, title pretty much says it all. If nm-applet is not present, the cinnamon session will fail to lauch. Yet network-manager-gnome is only Recommended by cinnamon. Please either add a full Depends or, better yet, remove

Bug#817030: [pkg-cryptsetup-devel] Bug#817030: cryptsetup: no keyscripts support in conjunction with systemd

2016-03-07 12:01 GMT+01:00 Guilhem Moulin : > There is #800147 already. I think I'll lay off reporting bugs for a while now. The last few I missed were at least archived and did not show up in reportbug, this one did (it was still in the scroll buffer) ... I'm sorry. Does

Bug#817030: cryptsetup: no keyscripts support in conjunction with systemd

Package: cryptsetup Version: 2:1.6.6-5 Severity: important Hi, At least since jessie (I've pretty much skipped wheezy on the affected systems) keyscripts do not work, unless handled in the initramfs. So everything needed for the rootfs is fine, as is anything tagged with the initramfs option,

Bug#816272: [Pkg-clamav-devel] Bug#816272: clamav-freshclam: logrotate errors out with "gzip: stdin: file size changed while zipping"

2016-03-05 23:07 GMT+01:00 Sebastian Andrzej Siewior : > every other? I assumed twice a day. That's correct, of course, my mistake. > Btw: is this the cron/ anacron package or systemd's cron stuff? just plain cron (3.0pl1-127+deb8u1) > When you select `cron' in debconf

Bug#816272: [Pkg-clamav-devel] Bug#816272: clamav-freshclam: logrotate errors out with "gzip: stdin: file size changed while zipping"

2016-03-04 22:10 GMT+01:00 Sebastian Andrzej Siewior : > I copied your debconf and it seems to work here. Can you check your logs > if the freshclam log runs at the same time as your logrorate script? > I have no idea why but it seems to be the case. Adding `delaycompress'

Bug#814996: [Aptitude-devel] Bug#814996: aptitude: purge does not "stick" the first time

2016-03-01 18:53 GMT+01:00 Manuel A. Fernandez Montecelo : > Perhaps. But in any case, even if the underlying problem was actually a > different one, if several people cannot reproduce it in 0.7.x and there > are reasonably indications that it was fixed, it means that

Bug#814996: [Aptitude-devel] Bug#814996: aptitude: purge does not "stick" the first time

Hi, I'm not so sure. For one, #570492 is ancient and for me at least the bug is new in jessie. Also it being fixed "in the 0.7 series" does not help jessie users at all. Regards, Christian 2016-03-01 13:52 GMT+01:00 Manuel A. Fernandez Montecelo < manuel.montez...@gmail.com>: > Control: tags

Bug#816276: systemd: shutdown fails if swap can't be deactivated

2016-02-29 17:20 GMT+01:00 Michael Biebl : > This looks like a duplicate of > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=805133 Indeed it does, I do apologise. In my defence, I did filter for "swap" in reportbug and it didn't show up (still doesn't, actually). Thanks,

Bug#816276: systemd: shutdown fails if swap can't be deactivated

ss hanging indefinitely? Shouldn't systemd either retry or fail gracefully (i.e., ignore the problem)? (For this specific use case I'll also look into giving the vm more RAM and having the host swap out more, but I do not know yet if parts of vm memory can be efficiently swapped out host-side.) Regards,

Bug#816272: clamav-freshclam: logrotate errors out with "gzip: stdin: file size changed while zipping"

g > run-parts: /etc/cron.daily/logrotate exited with return code 1 No configuration of clamav or freshclam has been done (yet), apart from the debconf settings at the bottom of this mail. Regards, Christian Pernegger -- Package-specific info: --- configuration --- # Automatically created by the

Bug#816174: debsecan: clarify report category "fixed vulnerabilities"

Package: debsecan Version: 0.4.17 Severity: wishlist Hi, I have to admit that I'm confused about the meaning of the report headers in the nightly report. Does "fixed vulnerabilities" mean fixed in the archive, as in I should go download an update or is it fixed on the system? Regards, Christian

Bug#814996: aptitude: purge does not "stick" the first time

> So a couple of more questions... > > Did you just dicover this recently I did two fresh jessie-installs in the past two months, my first (my other Debian boxes are still on wheezy or squeeze). Both new systems exhibit this problem and have from the beginning, the older ones do not. Cheers, C.

Bug#815927: bridge-utils: bridge over bonding not configured reliably

Package: bridge-utils Version: 1.5-9 Severity: normal Hello, I've been trying to set up a bridge over a bond of two interfaces in order to provide connectivity to a vm or two. Just the bond itself works fine, but as soon as I include the bridge things get unpredictable. Sometimes it works,

Bug#814996: aptitude: purge does not "stick" the first time

Hello, > I cannot reproduce this behaviour. Lucky you! I've since found out that I don't even have to quit and restart aptitude for this to trigger: mark package for purging, [g],[g] --> package is purged (as expected) [g] again --> package shows up marked for installation (instead of nothing

Bug#814996: aptitude: purge does not "stick" the first time

is excessive. This occurs on both fresh jessie installs I have. Regards Christian Pernegger -- Package-specific info: Terminal: xterm $DISPLAY not set. which aptitude: /usr/bin/aptitude aptitude version information: aptitude 0.6.11 compiled at Nov 8 2014 13:34:39 Compiler: g++ 4.9.1 Compiled against

Bug#813886: sysstat: allow daemon and cron jobs to be disabled more completely

a debconf setting that does more than change /etc/default/sysstat, another to split the "passive" components (*stat) from the "active" ones (sa*) into separate packages. Regards Christian Pernegger -- System Information: Debian Release: 8.3 APT prefers stable-updates APT p

Bug#811473: systemd: timer with WakeSystem=yes doesn't always start the service it's supposed to trigger

on the suspend, sleep and hybrid-sleep targets as a workaround. The band-aids seem to be holding, no missed backups for ~1 week. Regards, Christian Pernegger On 22 January 2016 at 10:39, Christian Pernegger <perneg...@gmail.com> wrote: > Hello again, > > I just wanted to documen

Bug#811473: systemd: timer with WakeSystem=yes doesn't always start the service it's supposed to trigger

6:21 CET 23h left Don 2016-01-21 13:30:30 CET 20h ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service [...] Workarounds galore, of course, but I'd still prefer this function to work as documented. Regards, Christian Pernegger On 19 January 2016 at 10:36, Christian Pernegger <

Bug#812190: timesyncd: insufficient documentation / timesyncd.conf(5) does not exist

). The latter man page is not on my system. Regards, Christian Pernegger -- Package-specific info: -- System Information: Debian Release: 8.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores

Bug#812186: isc-dhcp-client: does not renew lease (poss. interaction w/ systemd suspend/resume)

-time glitch. Is it possible that it doesn't like the way systemd handles suspend/resume? Regards, Christian Pernegger P.S.: The leases file shows two leases for some reason. -- System Information: Debian Release: 8.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500

Bug#811544: cpufrequtils: Disable init scripts by default (not needed anymore)

is loaded by the init scripts by default, already *is* the kernel default. So the init scripts are just expensive noops. Maybe they're still needed in some cases but I think the default should be off (with a working low prio debconf question to enable). Regards, Christian Pernegger -- System I

Bug#786393: systemd: keyscript crypttab ignore, but booting ok with a annoying 1m30 delay

Package: systemd Version: 215-17+deb8u2 Followup-For: Bug #786393 Hello, I just wanted to add that one can disable systemd's cryptsetup-related functionality [systemd-cryptsetup-generator] on the kernel command line as a workaround: luks=no # disables everything luks.crypttab=no # disables

Bug#638026: azureus: doesn't start because it can't find swt

Package: azureus Version: 4.3.0.6-1.1 Severity: important azureus fails to start, apparently because it can't find awt. It's looking for a /usr/share/java/swt.jar, which does not exist. Moving ~/.azureus out of the way does not make any difference. Workaround: symlink swt.jar to

Bug#638031: l7-protocols: better patterns (working ones)

Package: l7-protocols Version: 20090528-3 Severity: wishlist I've been playing around with QoS these last few days, using l7-filter-userspace as classifier. Sadly some patterns don't seem to work: worldofwarcraft: The unidentified packets l7-filter -v dumps look nothing like the pattern.

Bug#613825: new upstream version (0.134)

Package: pan Version: 0.133-1.1 Severity: normal FYI, it's up to 0.135 now. Cheers, C. -- System Information: Debian Release: 6.0.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU

Bug#634109: cryptsetup: initramfs hook: deps determined for lvm on dm-crypt are incomplete

Package: cryptsetup Version: 2:1.1.3-4squeeze2 Severity: normal Tags: patch Given a vg with multiple encrypted pvs, only one of which contains the root lv, the initramfs-hook will only pull in the pv that actually holds the root lv. Any other pvs in the same vg are not set up to be decrypted at

Bug#633978: diffutils: diff -r reports spurious differences

Package: diffutils Version: 1:3.0-1 Severity: normal I've just migrated our media server to new disks using cp -ar and just to make sure everything went over alright I compared the old and the new set with diff -rq, with the attached result. (Sorry for the German locale: - 'Nur in' = 'Only in'

Bug#633978: diffutils: diff -r reports spurious differences

The diff.log.gz that you sent shows that there is indeed something wrong in your system, but it is yet to be seen that you don't have filesystem corruption somewhere, or bad RAM chips. Those were my first thoughts as well, so I ran fsck on both filesystems -- they were fine -- and I also

Bug#633005: iscsitarget: upstream changelog included twice

Package: iscsitarget Version: 1.4.20.2-1 Severity: minor The upstream changelog is included twice, as /usr/share/doc/iscsitarget/changelog.gz and /usr/share/doc/iscsitarget/ChangeLog.gz. -- System Information: Debian Release: 6.0.2 APT prefers stable-updates APT policy: (500,

Bug#633006: stunnel4: accept = localhost:PORT only listens on IPv6

Package: stunnel4 Version: 3:4.29-1 Severity: normal Tags: ipv6 I've recently upgraded from lenny to squeeze and stunnel4 stopped working. My accept = lines all have localhost:PORT and apparently that caused stunnel to only listen on ::1 and not on 127.0.0.1 as well, which is somewhat

Bug#553526: pan: segfault in libc-2.7.so [malloc(): memory corruption (fast)]

Package: pan Version: 0.132-3.1 Severity: normal pan reproducably (at the moment) crashes when trying to open or update any group. The crash leaves a line like the following in dmesg: pan[3067]: segfault at 0 ip 7f6b5eb9ecba sp 7fffafc0bbf0 error 4 in libc-2.7.so[7f6b5eb69000+14a000]

Bug#419571: cryptsetup: another usecase: boot from lvm on md on (multiple) dm-crypt

Package: cryptsetup Version: 2:1.0.6-7 Followup-For: Bug #419571 I have another usecase for this wishlist item, one that'll hopefully expedite its implementation :-) Current mainstream CPUs seem to be able to do ~100MiB/s per core in aes-cbc-essiv:sha256 mode, assuming a 256 bit key. Since

Bug#551952: initramfs-tools: make the order of script execution more robust/flexible/intelligent

Package: initramfs-tools Version: 0.92o Severity: normal At the moment the order boot scripts are executed in depends solely on 'prereqs' that are - at least in the scripts on my system - rather static. While the admin can *add* scripts under /etc/initramfs-tools there is no elegant way to

Bug#551203: /sbin/mount.cifs: option to force legacy behavior of symlinks, even if CIFS extensions are enabled

Package: smbfs Version: 2:3.2.5-4lenny7 Severity: normal File: /sbin/mount.cifs This is about the behaviour of symlinks on CIFS shares. If the client is a Windows machine / doesn't support the CIFS extensions, symlinks will be resolved on the server and thus transparent on the client. I. e. if

Bug#473130: file-roller doesn't see all files in multi-part .rars

file-roller does not handle newer multi-part .rar files (.partNN.rar) correctly. Looking at the upstream bugreport I see that it doesn't reflect the problem. It's not that file-roller doesn't support multi-volume archives, as in Sorry, multi-volume archives not supported at the moment. The

Bug#549530: mdadm: checkarray caused machine lockup

The behaviour is reproducible. Running checkarray --all always hangs the box after some time with the symptoms described. That's true even in single user mode with no other accesses. I will now check if checking (no pun intended) the arrays serially works. As this looks more like a kernel bug in

Bug#549530: mdadm: checkarray caused machine lockup

Package: mdadm Version: 2.6.7.2-3 Severity: normal Tonight's checkarray triggered a slew of SATA errors, which finally caused the machine to lock up completely (see attached syslog). Possibly the hardware is flakey, but then I've been stressing it a lot in the last few weeks without any

Bug#481030: I have it too

I confirm that after removing gstreamer stuff (and other packets) from debian-multimedia.org and installing the ones provided by official debian, this bug does not appear anymore on my machine. Must be a different bug, then - the d-m stuff is fine here. My workaround was to disable a bunch of

Bug#474114: logrotate: current version still affected

reassign 474114 stunnel4 retitle 474114 should daemonize properly so logrotate does not get zombiefied thanks This still smells like a workaround, though. Is it possible/desirable to fix logrotate to be less picky? If not I guess the bug should be moved to stunnel4. It's not logrotate being

Bug#474114: logrotate: current version still affected

Try it as: /etc/init.d/stunnel4 restart /dev/null 21 The order can matter. It may also be useful to try adding a /dev/null too. Using /etc/init.d/stunnel4 restart /dev/null 21 last night's cron.daily run did *not* result in a defunct logrotate. :-) I hope it's not too

Bug#481030: gnome-settings-daemon: Ubuntu's launchpad also has a bug about this

Package: gnome-settings-daemon Version: 2.22.2.1-1 Followup-For: Bug #481030 Relevant bugreports over at Ubuntu, including various possible workarounds: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/204850

Bug#498188: vnc4server: full gdm+gnome session no longer fully works on top of VNC

In this case I can see the bug report as a wish to support XInputExtension, which is currently not supported in VNC. That is a wishlist bug. I don't even know what the missing XInputExtension does or if it's relevant to the problem, after all the log entry is only tagged warning. Ok,

Bug#498188: vnc4server: full gdm+gnome session no longer fully works on top of VNC

How do you disable them? Every time I start the VNC sever I get this error about not being able to start gnome-settings-daemon. Install gconf-editor and run it. Go to apps/gnome_settings_daemon/plugins and uncheck the active boxes under the respective plugin's category. I disabled mouse,

Bug#498188: vnc4server: full gdm+gnome session no longer fully works on top of VNC

I'm not fully sure why this report has been filed on vnc4? Is it vnc that crash or some gnome program? The bug manifests in some gnome program (gnome-settings-daemon) but it occurs only in conjunction with VNC. The exact same config runs fine atop xorg. It's entirely possible that VNC is

Bug#498188: vnc4server: full gdm+gnome session no longer fully works on top of VNC

In this case I can see the bug report as a wish to support XInputExtension, which is currently not supported in VNC. That is a wishlist bug. I don't even know what the missing XInputExtension does or if it's relevant to the problem, after all the log entry is only tagged warning. For the

Bug#474114: logrotate: current version still affected

Package: logrotate Version: 3.7.1-3 Followup-For: Bug #474114 Just wanted to say that this bug still isn't fixed and I still care :-) Cheers, C. -- Package-specific info: Contents of /etc/logrotate.d insgesamt 48 -rw-r--r-- 1 root root 141 29. Mär 2007 acpid -rw-r--r-- 1 root root 84 16.

Bug#498188: vnc4server: full gdm+gnome session no longer fully works on top of VNC

Package: vnc4server Version: 4.1.1+X4.3.0-30 Severity: normal I had a pretty nice setup going on multiple machines, where gdm would manage a bunch vnc4 servers and provide a full gnome session on them, i. e. one could connect to one of the VNC displays without a password and would be presented

Bug#481030: gnome-settings-daemon: bug is still present

Package: gnome-settings-daemon Version: 2.22.2.1-1 Followup-For: Bug #481030 I'd just like to say that this issue is still present and very annoying. If there's anything I can do to help debug this please advise. Cheers, C. -- System Information: Debian Release: lenny/sid APT prefers

Bug#471729: cryptsetup: crude solution

Package: cryptsetup Version: 2:1.0.6-6 Followup-For: Bug #471729 In the end, I did this: #!/bin/sh #set -x UUID= # UUID of the USB stick's fs here UUID_PATH=/dev/disk/by-uuid/$UUID MNT_DIR=/usb-key KEYFILE=$MNT_DIR/$1 IN_FD=/proc/self/fd/2 if ! lsmod | grep -q usb_storage; then echo 2

Bug#474114: logrotate: current version still affected

I can't reproduce this. logrotate is exiting, but isn't getting picked up by the caller. Is your /etc/cron.daily/logrotate different to: #!/bin/sh test -x /usr/sbin/logrotate || exit 0 /usr/sbin/logrotate /etc/logrotate.conf No, it's the same. Also, what's in your

Bug#497778: nufw: not installable - exit code 10 during confugure

Package: nufw Version: 2.2.15-2 Severity: important I can't install nufw on a freshly installed lenny machine. Transcript below. Regards, C. $ LANG=C sudo aptitude install nufw Reading package lists... Done Building dependency tree Reading state information... Done Reading extended state

Bug#497778: nufw: not installable - exit code 10 during confugure

Verbose output below. Thanks for helping, C. $ sudo /var/lib/dpkg/info/nufw.postinst configure 2.2.15-2 + . /usr/share/debconf/confmodule ++ '[' '!' '' ']' ++ PERL_DL_NONLAZY=1 ++ export PERL_DL_NONLAZY ++ '[' '' ']' ++ exec /usr/share/debconf/frontend /var/lib/dpkg/info/nufw.postinst

Bug#492721: linux-image-2.6.24-etchnhalf.1-686: doesn't boot on Via EPIA EK

Thanks Christian. This is looking like #464962 Yes it is. Looks like a bunch of fringe CPUs got downgraded from a kernel perspective. running the 486 flavor is probably the best option for your system. Ok. I wonder what that'll do to performance ... it's slow enough as it is. Well, I can

Bug#492721: linux-image-2.6.24-etchnhalf.1-686: doesn't boot on Via EPIA EK

Package: linux-image-2.6.24-etchnhalf.1-686 Version: 2.6.24-6~etchnhalf.4 Severity: important The 2.6.24-etchnhalf kernel will not boot at all on my VIA EPIA EK. I was rather looking forward to being able to use a stable distro kernel (2.6.18 doesn't support power management on the CPU, which is

Bug#481030: gnome-settings-daemon: gnome-settings-daemon still not working (under vnc4server)

Package: gnome-settings-daemon Version: 2.22.2.1-1 Followup-For: Bug #481030 While I originally had a gnome-settings-daemon fails to start bug on the local (xorg) display as well, this seems to have been fixed at some point. The main use case of the affected boxes is however to provide full

Bug#483882: cryptsetup: /etc/crypttab noauto setting is ignored

Package: cryptsetup Version: 2:1.0.6-1 Severity: normal This box is ignoring the noauto option in /etc/crypttab, it asks for the passphrase for sda6_crypt during boot, no matter what. I've regenerated the initramfs image multiple times. Other Debian testing boxes I have are unaffected and even

Bug#481030: gnome-settings-daemon: 'failed to start' error messages at login, themes et al not working

Package: gnome-settings-daemon Version: 2.22.1-2 Severity: important This issue was originally reported as #476802. That bug has since been marked as fixed, even though the fix apparently has nothing to do with my problem. Anyway, on every graphical login, done via gdm, I get a number of error

Bug#476802: gconf2: gconfd fails to start at login

Any progress? The bug's still closed / pending-fixed but there's no fix ... :-) Thank you, C. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

  1   2   3   >