Bug#993716: bridge-utils: IPv6 network bridge fails after upgrading Buster to Bullseye
Hi! I'm CCing Josué because this seems to be more on ifupdown's side than on bridge-utils. > > auto br0 > > iface br0 inet static > > address 10.10.10.1 > > netmask 255.255.255.0 > > bridge_ports none > > bridge_stp off > > bridge_fd 0 > > > > iface br0 inet6 static > > address 2001:db8::2 > > netmask 64 > These stanzas are missing the "bridge_hw" entry which can be a MAC > address or the name of the interface whose MAC to take. Thus your > bridge ends up being connected to nothing. I know we are having quite some trouble with the random bridge mac address, but this doesn't seem to be one of those cases. For what I see this is a problem with DAD, the bridge is created without any port attached to it, so the kernel doesn't allow it to transition from: 18: br0inet6 X/64 scope link tentative \ valid_lft forever preferred_lft forever to: 18: br0inet6 X/64 scope link \ valid_lft forever preferred_lft forever This is because without any port on the bridge the kernel cannot do any DAD. So, without trasitioning it remains on tentative all the time, and thus the script /lib/ifupdown/settle-dad.sh from the package ifupdown exits with a timeout message, like the one you are seing and an error status of 1, thus breaking the network setup. I have thanged the exit 1 to an exit 0 on that script and everything works like expected, this is a nasty workaround while we don't arrive to a better solution, the other solution would be to attach something to the bridge, maybe even a dummy port or similar. Josué, we've had the idea of integrating bridge setup (now on bridge-utils) into ifupdown, I wouldn't mind doing this for Bookworm, I would continue to take care of this part to the best of my knowledte even if it is on ifupdown. Maybe it it is the time to do that. As for this bug, the workaround I describe is not a valid solution, but maybe we can check on the settle-dad script to see if the device is a bridge without any interface added to it, and thus not transitioning, and return with a 0 on the timeout in that case? About integration... we have talked about that on some bugs that are somehow half way between bridge-utils and ifupdown, last one may be #939713, I would try to rewrite everything on the ifupdown scripts to depend on ip and not brctl, so that ifupdown wouldn't depend on bridge-utils. We can start some other thread on this if you want or we can talk about this on irc or mail, whatever. As for this bug... I believe it is on the ifupdown side, so I think we should reasign it, unless you see a way to fix this problem on the bridge-utils side, but I can't think about any fix on bridge-utils side right now. Regards. -- Manty/BestiaTester -> http://manty.net
Bug#992158: Race in ifup maybe related to brctl failure in pre-up of network interface
> Thank you for your assistance. With hint for the relevant man > page "bridge-utils-interfaces" I found the bridge setup working > using the configuration > > auto br0 > iface br0 inet static > address 192.168.1.1 > network 192.168.1.0 > netmask 255.255.255.0 > bridge_ports none > bridge_hw 86:aa:aa:aa:aa:aa > > With that there is no race observed, I deem this bug report as > invalid. Yes, that looks ok for a setup where you don't want to add any ports to a bridge. > I tested without the legacy stuff, worked, making this bug report > irrelevant. Testing how far the change can be backported is > done on demand later, not relevant here (Bullseye). I don't remember any reason why current bullseye package can't be used at buster or prior versions. Regards. -- Manty/BestiaTester -> http://manty.net
Bug#992158: Race in ifup maybe related to brctl failure in pre-up of network interface
Hi! First I'd like to thank Dennis for his good support, as always ;-) > > $ ifup virtbr0 > > Cannot find device "virtbr0" > > ifup: failed to bring up virtbr0 > > It is because the "bridge_ports" directive is missing. From the > manpage bridge-utils-interfaces(5): > >bridge_ports interface specification > this option must exist for the scripts to setup the bridge. > > Either specify "bridge_ports none" or "bridge_ports enp2s0 enp2s1" (or > whatever your physical interfaces are named). That's it, you always have to specify the bridge_ports directive so that we treat the interface as a bridge. > > I also reactivated "systemd-udevd": ... > > # systemctl reload /lib/systemd/network/80-bridgeutils.link > > Failed to reload lib-systemd-network-80\x2dbridgeutils.link.mount: Unit > > lib-systemd-network-80\x2dbridgeutils.link.mount not found. I really believe that this contribution from Dennis should not be needed, so I'd appreciate if you could test without this extra stuff, which hasn't really been thoroughtly tested and test with the standard setup, if we identify a problem with the standard bridge_hw setup we'll go over it. If you test it like that, please provide feedback to know if it worked and if we can close the bug or not. Regards. -- Manty/BestiaTester -> http://manty.net
Bug#984510: purging squid with squid-openssl installed removes files anyway
Hi! I'd like to receive comments on this one, I have already pushed a solution to salsa that involves not removing the files and noting that on the comment we echo on postrm so that it now tells you to remove both cache and logs. I have also explained on the NEWS file that you must have at least -6 version in order to be able to do a purge without loosing your logs and config. The config will get automatically removed when it must be (if you purge squid and squid-openssl) so it shouldn't be removed on postrm anyway, so that works as expected, also if cache and logs dirs are empty dpkg will remove them and echo a warning that he could not remove them if they aren't empty. Maybe we could do better and try to remove in case we don't have any of our packages left or similar, but I also thought that logs are important, police may ask via judges for logs or similar, so preserving them... is a good thing I believe. So... what do you guys think? Should we upload that as -6 or do you want to do it some other way? Regards... -- Manty/BestiaTester -> http://manty.net
Bug#984510: purging squid with squid-openssl installed removes files anyway
Package: squid Version: 4.13-5 Severity: serious File: /usr/sbin/squid Hi! Today I tried to move from squid to squid-nossl and clean up afterwards, it all went ok when I did the installation of squid-openssl, squid got removed and everything worked as expected, but when I purged squid with squid-openssl installed, squid postrm script did... # dpkg --purge squid (A ler a base de datos ... 605846 files and directories currently installed.) Purging configuration files for squid (4.13-5) ... Purging logfiles... Removing the config-file .. Please, remove /var/spool/squid yourself. Which means that it removed squid.conf and the log directory without asking anything, it is curious that it left the cache files around for me to remove, but removed all the usefull info I had around. The code in question is this: echo "Purging logfiles..." rm -rf /var/log/squid if [ -f /etc/squid/squid.conf ]; then echo "Removing the config-file .." rm -f /etc/squid/squid.conf fi The problem here is... how to we deal with this? Regards... -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-4-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=gl_ES.UTF-8, LC_CTYPE=gl_ES.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages squid-openssl depends on: ii adduser 3.118 ii init-system-helpers 1.60 ii libc62.31-9 ii libcap2 1:2.44-1 ii libcom-err2 1.46.2-1 ii libcrypt11:4.4.17-1 ii libdb5.3 5.3.28+dfsg1-0.8 ii libdbi-perl 1.643-3+b1 ii libecap3 1.0.1-3.2+b1 ii libexpat12.2.10-2 ii libgcc-s110.2.1-6 ii libgssapi-krb5-2 1.18.3-4 ii libkrb5-31.18.3-4 ii libldap-2.4-22.4.57+dfsg-2 ii libltdl7 2.4.6-15 ii libnetfilter-conntrack3 1.0.8-3 ii libnettle8 3.7-2.1 ii libnsl2 1.3.0-2 ii libpam0g 1.4.0-6 ii libsasl2-2 2.1.27+dfsg-2.1 ii libssl1.11.1.1j-1 ii libstdc++6 10.2.1-6 ii libsystemd0 247.3-1 ii libxml2 2.9.10+dfsg-6.3+b1 ii logrotate3.18.0-2 ii lsb-base 11.1.0 ii netbase 6.2 ii squid-common 4.13-5 Versions of packages squid-openssl recommends: ii ca-certificates 20210119 ii libcap2-bin 1:2.44-1 Versions of packages squid-openssl suggests: ii apparmor 2.13.6-9 pn resolvconf pn smbclient pn squid-cgi pn squid-purge pn squidclient pn ufw pn winbind -- Configuration Files: /etc/squid/squid.conf [Errno 2] Non hai tal ficheiro ou directorio: '/etc/squid/squid.conf' -- no debconf information
Bug#900821: vers=2.1 won't solve it
Hi! I have tested vers=2.1 parameter on a current Buster installation and at least if the server is a Samba (samba as in Buster with a standard setup) the version of the protocol won't solve anything, the wget still breaks: Saving to: 'STDOUT' -16%[> ] 1.01M --.-KB/s in 0.008s 2018-12-03 13:55:39 (124 MB/s) - Read error at byte 1056768/6538880 (Bad address). Retrying. The only working solution still is EnableSendFile On This was tested with: ii linux-image-4.18.0-2-amd644.18.10-2+b1amd64 Linux 4.18 for 64-bit PCs ii samba 2:4.9.2+dfsg-2 amd64 SMB/CIFS file, print, and login server for Unix ii apache2 2.4.37-1amd64 Apache HTTP Server Regards. -- Santiago García Mantiñán
Bug#900821: linux-image-4.9.0-6-amd64: apache reads wrong data over cifs filesystems served by samba
Hi! I have rechecked everything again. Salvatore, I'm testing on an up to date buster running kernel 4.17.17-1 and I still see the kernel warning messages and the downloads are breaking and wget still shows this king of messages: 2018-08-29 13:45:31 (122 MB/s) - Read error at byte 1056768/6538880 (Bad address). Retrying. So I see no progresses with newer versions or anything like that. Don't know what are the differences between your setup and mine, maybe it is the file length? What seems to work ok is the workaround of setting EnableSendfile to on, this avoids the original problem I had found on Stretch and also the problems I later found on buster with the kernel warnings and broken downloads. Hope this helps. Regards. -- Manty/BestiaTester -> http://manty.net
Bug#799097: Provided patch fixes broken cgi
Hi! As the pachage on Jessie or on unstable wouldn't work on my stretch setup, I was just getting an error on the cgi instead of the expected web page with version 0.7-5.1. I gave the patch that Vladimir sent a chance and it has worked ok, the cgi now works. Thanks Vladimir for providing the patch. I wonder if somebody can take the right decision on what working version we should provide and provide it, having a broken version doesn't help our users. Regards. -- Manty/BestiaTester -> http://manty.net
Bug#799097: Status of this bug?
Hi! Looks like the result of this bug was to remove the package from Stretch, the bug seems still open and no patch over the package has been posted. I think we should provide a working package for people coming from Jessie with this package installed and finding that the old package won't work on Stretch and that the one on unstable doesn't work either :-( Any patch to test? Regards... -- Manty/BestiaTester -> http://manty.net
Bug#858556: Ready for -3 I believe
Hi! I have just pushed some changes to Amos fix and other fixes for some "dirty" test cases I had found. Please test and report back, tomorrow I'll do some final tests and upload if nobody sees any problem. Regards. -- Manty/BestiaTester -> http://manty.net
Bug#858078: Still happens on 4.9.16
Hi! As expected, this does still happen on the 4.9.16 kernel in unstable at this time. Regards. -- Manty/BestiaTester -> http://manty.net
Bug#858556: In case the code is not anywhere...
> Maybe it was just that the original code had to be at the > upgrade|install-upgrade > block of the case? > > But why is the -d /etc/squid3 checked? I followed this two questions doing some tests on my system and it looks to me as we should be happy with this patch: --- /tmp/squid.preinst 2017-03-26 01:27:31.201012140 +0100 +++ debian/squid.preinst2017-03-26 00:59:34.433577481 +0100 @@ -26,6 +26,8 @@ /etc/squid3/errorpage.css /etc/squid/errorpage.css 3.5.4-1~ squid3 -- "$@" fi +case "$1" in + upgrade|install-upgrade) # # If the squid (2.7) package was being used previously protect # the squid.conf file, which was not tracked as a conffile. @@ -34,12 +36,9 @@ # Except when a squid3 package was used, since we do want the # debconf questions to appear as the packages get merged. # -if dpkg --compare-versions "$2" lt '2.8' && test -d /etc/squid3; then +if dpkg --compare-versions "$2" lt '2.8'; then mv /etc/squid/squid.conf /etc/squid/squid.conf.pre3.5_upgrade fi - -case "$1" in - upgrade|install-upgrade) ;; abort-upgrade) exit 0 Which basically means to move the check to the upgrade|install-upgrade section and remove the check for the squid3 dir. My tests of both an upgrade from 2.7 and from jessie's squid3 work ok. Amos, I don't know what your idea with this code was, so I'd like to talk about it a bit before uploading a new version. Regards. -- Manty/BestiaTester -> http://manty.net
Bug#858556: In case the code is not anywhere...
> Just in case you didn't have it and if I understood it well... I came up > with this in a quick attempt: Did I say this was just a quick attempt? Maybe it was just that the original code had to be at the upgrade|install-upgrade block of the case? when you are on an upgrade the parameters are for example: upgrade 2.7.STABLE9-4.1+deb7u2 3.5.23-2 But why is the -d /etc/squid3 checked? if we had the /etc/squid3 dir, then doesn't it mean that we had squid3 package around? I don't get this part. Maybe it is just too late, time to go to bed. Regards... -- Manty/BestiaTester -> http://manty.net
Bug#858556: In case the code is not anywhere...
> So... I guess you had some code that is missing here, isn't it? Just in case you didn't have it and if I understood it well... I came up with this in a quick attempt: V="$(dpkg --status squid 2>/dev/null|sed -n "s/^Version: \(.*\)/\1/p")" if [ -n "$V" ] && dpkg --compare-versions "$V" lt '2.8' && test -d /etc/squid3; then mv /etc/squid/squid.conf /etc/squid/squid.conf.pre3.5_upgrade fi Regards... -- Manty/BestiaTester -> http://manty.net
Bug#858556: what is happening
Hi Amos! The problem seems to be on how you commited your implementation of my idea to protect squid.conf from squid 2.7, it reads like this: # # If the squid (2.7) package was being used previously protect # the squid.conf file, which was not tracked as a conffile. # Use '< 2.8' version to catch backports and security versions. # # Except when a squid3 package was used, since we do want the # debconf questions to appear as the packages get merged. # if dpkg --compare-versions "$2" lt '2.8' && test -d /etc/squid3; then mv /etc/squid/squid.conf /etc/squid/squid.conf.pre3.5_upgrade fi I think you missed something here, $2 seems to be blank, which gives something like this: dpkg --compare-versions "" lt '2.8' && echo yes yes So... I guess you had some code that is missing here, isn't it? Regards. -- Manty/BestiaTester -> http://manty.net
Bug#858556: Bug #858556 as you reported on #801564
Hi! Just to be able to replicate your setup, as our initial tests didn't catch this one: what packages did you have on jessie (I'm assuming squid3 + squid3-common from jessie, or did you have any other installed? The package did have the default config files or where they modified in some way? Did you have any config stuff left from previous squid 2.7 from wheezy around? Any other info you consider special on your setup? Regards... -- Manty/BestiaTester -> http://manty.net
Bug#854841: eth4 hardcoded
Package: bridge-utils Version: 1.5-12 Severity: serious I somehow missed a hardcoded eth4 name for $dev on the bridge-utils.sh script. I'll be uploading a new version fixing this. Sorry about this. Regards. -- System Information: Debian Release: 9.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-1-amd64 (SMP w/1 CPU core) Locale: LANG=gl_ES.UTF-8, LC_CTYPE=gl_ES.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages bridge-utils depends on: ii libc6 2.24-9 bridge-utils recommends no packages. Versions of packages bridge-utils suggests: ii ifupdown 0.8.19 -- no debconf information
Bug#725417: Thanks a lot
Hi! I've been preparing a new version of mbr which will change the format and not overwrite the disk-id, but I have not finished yet and I don't have time lately, so your upload is very welcome. Thanks again. Regards. -- Manty/BestiaTester -> http://manty.net
Bug#725417: Neil's reply
Hi! Sorry for not updating this, Neil replied at last to my mails with this: -- Hi Santiago, Sorry for not responding before. I got half way through replying and then got distracted. I'm afraid I don't have the time to maintain the MBR any more. I would appreciate it if you could find someone else to maintain it. Cheers, Neil. -- I then asked him how to proceed to fix our problem and he answered: -- It's been 6 years, so I don't remember all that much. I think you'll need to change the configuration mechanism as there's a pointer to it at the end of the MBR. I can't really remember the details. Perhaps it would be sensible to withdraw support for configuring one version of the MBR using the installer from a different version. It might be better to get the configuration details from a config file rather than the previously installed MBR. Cheers, Neil. -- So... first of all, sorry about being a bit missing, I don't seem to find the time that these things require. I'm about to upload a new version with lennart's patch for now, just to avoid breaking other windows installations and I'll then take a look at how can we give the new mbr format support (Ideas welcome). Regards... -- Manty/BestiaTester -> http://manty.net
Bug#801564: A possible way to solve this.
> Now that I have gone over this again... it should have been .dpkg-dist, not > .dpkg-new, which is how dpkg unpacks the original file, not how it keeps it > if we say we want to keep user settings. I have done a final test doing a move /etc/squid/squid.conf to /etc/squid/squid.conf.pre_3.4_upgrade at preinst and then at postinst I moved /etc/squid/squid.conf (the newly installed conf) to /etc/squid/squid.conf.dpkg-dist and also a sed of /etc/squid/squid.conf.pre_3.4_upgrade > /etc/squid/squid.conf The result on /ets/squid was: -rw--- 1 root root 169404 Out 28 19:34 squid.conf.pre_3.4_upgrade -rw-r--r-- 1 root root 1817 Out 28 19:53 errorpage.css -rw-r--r-- 1 root root 285765 Out 28 21:34 squid.conf.dpkg-dist -rw-r--r-- 1 root root 169440 Out 28 21:34 squid.conf The output messages were the same ones as yesterday, with squid running at the end using the config file generated from the old squid.conf file. Regards. -- Manty/BestiaTester -> http://manty.net
Bug#801564: A possible way to solve this.
Hi! I've been doing some tests on this and I think I may have come to a way to work around this. The first thing is that we must keep the user settings, but /etc/squid/squid.conf is not marked as a conffile, anyway keeping the user settings in mind I did the following: At preinst move /etc/squid/squid.conf to /etc/squid/squid.conf.pre_3.4_upgrade Then at postinst we have the new dpkg squid.conf file installed without any warning so I did: move /etc/squid/squid.conf to /etc/squid/squid.conf.dpkg-new sed /etc/squid/squid.conf.pre_3.4_upgrade >/etc/squid/squid.conf We should take care of other things like permissions of the file, ... but that's just the idea and it seems to work on my tests. This is the output with squid/oldstable installed: # dpkg -i squid-common_3.5.10-2_all.deb squid_3.5.10-2_amd64.deb (A ler a base de datos ... 255231 files and directories currently installed.) Preparing to unpack squid-common_3.5.10-2_all.deb ... Unpacking squid-common (3.5.10-2) over (2.7.STABLE9-4.1+deb7u1) ... Preparing to unpack squid_3.5.10-2_amd64.deb ... Unpacking squid (3.5.10-2) over (2.7.STABLE9-4.1+deb7u1) ... A configurar squid-common (3.5.10-2) ... A configurar squid (3.5.10-2) ... A instalar a nova versión do ficheiro de configuración /etc/init.d/squid ... A instalar a nova versión do ficheiro de configuración /etc/logrotate.d/squid ... A instalar a nova versión do ficheiro de configuración /etc/resolvconf/update-libc.d/squid ... Filtering squid.conf manager ACL. [] Restarting Squid HTTP Proxy: squid2015/10/28 01:04:23| WARNING: (B) '::/0' is a subnetwork of (A) '::/0' 2015/10/28 01:04:23| WARNING: because of this '::/0' is ignored to keep splay tree searching predictable 2015/10/28 01:04:23| WARNING: You should probably remove '::/0' from the ACL named 'all' 2015/10/28 01:04:23| WARNING: (B) '127.0.0.1' is a subnetwork of (A) '127.0.0.1' 2015/10/28 01:04:23| WARNING: because of this '127.0.0.1' is ignored to keep splay tree searching predictable 2015/10/28 01:04:23| WARNING: You should probably remove '127.0.0.1' from the ACL named 'localhost' 2015/10/28 01:04:23| WARNING: (B) '127.0.0.1' is a subnetwork of (A) '127.0.0.1' 2015/10/28 01:04:23| WARNING: because of this '127.0.0.1' is ignored to keep splay tree searching predictable 2015/10/28 01:04:23| WARNING: You should probably remove '127.0.0.1' from the ACL named 'localhost' 2015/10/28 01:04:23| WARNING: (B) '127.0.0.0/8' is a subnetwork of (A) '127.0.0.0/8' 2015/10/28 01:04:23| WARNING: because of this '127.0.0.0/8' is ignored to keep splay tree searching predictable 2015/10/28 01:04:23| WARNING: You should probably remove '127.0.0.0/8' from the ACL named 'to_localhost' 2015/10/28 01:04:23| WARNING: (B) '0.0.0.0' is a subnetwork of (A) '0.0.0.0' 2015/10/28 01:04:23| WARNING: because of this '0.0.0.0' is ignored to keep splay tree searching predictable 2015/10/28 01:04:23| WARNING: You should probably remove '0.0.0.0' from the ACL named 'to_localhost' 2015/10/28 01:04:23| WARNING: (B) '0.0.0.0' is a subnetwork of (A) '0.0.0.0' 2015/10/28 01:04:23| WARNING: because of this '0.0.0.0' is ignored to keep splay tree searching predictable 2015/10/28 01:04:23| WARNING: You should probably remove '0.0.0.0' from the ACL named 'to_localhost' 2015/10/28 01:04:23| ERROR: Directive 'hierarchy_stoplist' is obsolete. 2015/10/28 01:04:23| ERROR: Directive 'upgrade_http0.9' is obsolete. 2015/10/28 01:04:23| ERROR: Directive 'broken_vary_encoding' is obsolete. 2015/10/28 01:04:23| ERROR: Directive 'extension_methods' is obsolete. . ok Processing triggers for man-db (2.7.0.2-5) ... And this is what my /etc/squid looks like after the install: -rw--- 1 root root 169404 Out 28 00:58 squid.conf.pre_3.4_upgrade -rw-r--r-- 1 root root 1817 Out 28 01:01 errorpage.css -rw-r--r-- 1 root root 285765 Out 28 01:04 squid.conf.dpkg-new -rw-r--r-- 1 root root 169440 Out 28 01:04 squid.conf Of course the squid.conf is based on the old 2.7 version and we have the .dpkg-new file like if we had told dpkg to keep the old config. Hope that helps. Regards. -- Manty/BestiaTester -> http://manty.net
Bug#801564: A possible way to solve this.
> Of course the squid.conf is based on the old 2.7 version and we have the > .dpkg-new file like if we had told dpkg to keep the old config. Now that I have gone over this again... it should have been .dpkg-dist, not .dpkg-new, which is how dpkg unpacks the original file, not how it keeps it if we say we want to keep user settings. Regards. -- Manty/BestiaTester -> http://manty.net
Bug#801907: Workaround
Investigating how squid behaved with jesred I found a workaround while we don't find a proper solution, this is really ugly but it works for me in the meanwhile: regex ^http://matchedurl url=http://replacementurl This is working for current jessie 3.4.8-6+deb8u1 but may not work on any other version, I didn't even look at squid's code to see how this works, I just guessed this would work with a few tests, so it may not work for anybody else. Regards. -- Manty/BestiaTester -> http://manty.net
Bug#801907: No longer works with squid3 as of jessie or later
Package: jesred Version: 1.2pl1-19 Severity: grave Tags: upstream Hi! Like it happened before (see #505199) squid has changed again the way on which they are interfacing with url rewriters and has done it in an uncompatible way so that jesred doesn't work anymore (see: http://www.squid-cache.org/Doc/config/url_rewrite_program/) In particular the output that jesred is giving squid3 is no longer working, I've done a couple of tests and something like: OK status=30X url=http://whateveryouwant ... would make squid cause a redirect 30X and something like OK rewrite-url=http://whateveryouwant ... would make squid fetch http://whateveryouwant transparently for the client. Maybe there is a compatibility flag that I've missed and wich would make jesred still work, after all it is still named all over the squid web page with no reference to it not working at all, but I haven't found it. I hope we can fix this and keep jesred usefull and in the distro. Regards. -- System Information: Debian Release: 8.2 APT prefers stable APT policy: (990, 'stable'), (500, 'unstable'), (500, 'oldstable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.3.0-rc5-amd64 (SMP w/4 CPU cores) Locale: LANG=gl_ES.UTF-8, LC_CTYPE=gl_ES.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: sysvinit (via /sbin/init) Versions of packages jesred depends on: ii libc6 2.19-18+deb8u1 ii squid3 3.4.8-6+deb8u1 Versions of packages jesred recommends: ii apache2 [httpd] 2.4.10-10+deb8u3 jesred suggests no packages. -- no debconf information
Bug#774461: Confirmation of the fix
Hi! I've also been impacted by this bug and I can also confirm that Ben's kernel fixes it. Regards. -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#725417: This would not be a simple fix
Hi! I think this bug can be fixed, at least on the standard version of mbr (not on the Y2K version, but machines needing that won't run Windows7 or later anyway). The problem is that the changes needed point to an upstream change, that's why I tried to contact Neil, the upstream author, but failing to do so I tried to do it through Santiago Vila, the previous maintainer, but he also seems to have failed. > So to change this would change the data structure format in a totally > non backwards compatible way (so older install-mbr versions would no > longer recognize this as an install-mbr's mbr). That's what I saw and thus I said, this is something to be done by upstream. > So moving the data structure is almost certainly doable. Should it be? > Is there a maintainer upstream for this code anymore? Well, we haven't been able to contact him at his chiark address and don't know of any other way to contact him. > If nothing else, making install-mbr recognize that the existing mbr > contains non zero disk signature in bytes 440 to 443 and either > or 5A5A in bytes 444 to 445 and spitting out a warning that this disk > appears to be in use by a modern MBR using OS, and not just letting you > overwrite it might be a good idea. I agree on this as the least we can do to fix this, but I'd rather have an upstream new binary version of the mbr, as doing it at Debian doesn't seem the right thing to do. If finaly agree that we don't have an upstream for mbr we may then do the changes by ourselves, but I'd like to try to contact him one more time (I'll do this right now). Feel free to try to contact him, I suspect that antispam may be dropping the mails, so maybe you are more lucky. If you have it clear, please send patches for this or suggest the new locations, ... Here goes one of my last mails to Neil dated 11th July: Hi! I have tried to contact you from my Debian account, then from my own domain and now from gmail, as I saw your servers have very strict email policies, let's see if this time the mail reaches you :-) I have received a bug on Debian (https://bugs.debian.org/725417) that explains that new MS Windows need what is called a Disk signature on the mbr, and if we use install-mbr to write our mbr this signature gets changed, and then windows stops booting. The bugreport talks about 4 bytes, but it is really 6 bytes that need to be moved away, 6 just before the partition table data. I started looking at this with the idea of patching this on the non Y2K version, as this one was already too tight, however even the normal version seems to be too tight, we had only 5 bytes of padding space on this version. On the other hand, on the 6 bytes that are being used for the Disk signature you had placed the pointer to the data area, so the pointer should be relocated, this is... unless we don't care about those two bytes right where we have the pointer, as the signature is right on the four previous ones and then at 1BC our pointer. This seems to work ok at least with Windows 7. The place were we have our signature should be a h word or 5A5Ah if it is copy protected, at least acording to wikipedia, but Win7 seems to work anyway. Well, what do you think about all this? Regards. -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#646620: Another stable server having the same issue but with weird results
Hi! I was revising other servers and found severl others having the same issue, this one is a bit extrange as the upgrade that took place is the same as the one on the i686 server I reported a bit earlier, the differences are: 1- on time, this server due to mirrors timings did the upgrade on the 29th while my previous reported stable server had done the upgrade on the 30th 2- on sizes, as this new server has more things installed (like X server) 3- on the result, on this server the process holding things was not samba, even though it also has samba and it was upgraded, this time is hald, while hal was not upgraded This are the packages upgraded for the previous report, I had forgotten to add this: 2012-01-30 07:44:01,945 INFO Packages that are upgraded: base-files bzip2 cifs-utils dpkg libbz2-1.0 libc-ares2 libc-bin libc6 libgnutls26 libperl5.10 libwbclient0 linux-base linux-image-2.6.32-5-686 locales mdadm module-init-tools mutt perl perl-base perl-modules samba samba-common smbclient smbfs And this is for the machine of this report, the one having hald holding things: 2012-01-29 06:47:39,904 INFO Packages that are upgraded: base-files bzip2 cifs-utils dpkg dpkg-dev dselect firmware-linux-free libbz2-1.0 libc-bin libc6 libc6-i686 libdpkg-perl libgnutls26 libmtp8 libperl5.10 libpq5 libpurple0 libsmbclient libwbclient0 linux-base linux-image-2.6.32-5-686 locales mdadm module-init-tools mutt perl perl-base perl-modules pidgin pidgin-data samba samba-common smbclient smbfs tzdata xserver-common xserver-xorg-core These are the processes being run: root 2380 0.0 0.0 4416 544 ?Ss Jan18 0:44 /usr/sbin/cron root 7222 0.0 0.0 4568 580 ?SJan29 0:00 \_ /USR/SBIN/CRON root 7227 0.0 0.0 1796 312 ?Ss Jan29 0:00 \_ /bin/sh -c test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily ) root 7230 0.0 0.0 1720 236 ?SJan29 0:00 \_ run-parts --report /etc/cron.daily root 7238 0.0 0.0 0 0 ?ZJan29 0:00 \_ [apt] 112 10652 0.0 0.1 14540 816 ?Ssl Jan29 0:21 /usr/sbin/hald root 10653 0.0 0.0 3492 320 ?SJan29 0:00 \_ hald-runner root 10673 0.0 0.0 3560 476 ?SJan29 8:53 \_ hald-addon-storage: polling /dev/hda (every 2 sec) 112 10682 0.0 0.0 3376 260 ?SJan29 0:00 \_ hald-addon-acpi: listening on acpid socket /var/run/acpid.socket This is how FDs looked: ls -l 7230/fd total 0 lr-x-- 1 root root 64 2012-02-16 20:31 0 -> pipe:[2400509] lrwx-- 1 root root 64 2012-02-16 20:31 1 -> /tmp/tmpfUFqgNb (deleted) lrwx-- 1 root root 64 2012-02-16 20:31 2 -> /tmp/tmpfUFqgNb (deleted) lr-x-- 1 root root 64 2012-02-16 20:31 3 -> pipe:[2400529] lr-x-- 1 root root 64 2012-02-16 20:31 5 -> pipe:[2400530] ls -l 10652/fd total 0 lrwx-- 1 root root 64 2012-02-16 20:31 0 -> /dev/null lrwx-- 1 root root 64 2012-02-16 20:31 1 -> /dev/null lrwx-- 1 root root 64 2012-02-16 20:31 10 -> socket:[2407830] l-wx-- 1 root root 64 2012-02-16 20:31 100 -> pipe:[2400529] l-wx-- 1 root root 64 2012-02-16 20:31 101 -> pipe:[2400530] l-wx-- 1 root root 64 2012-02-16 20:31 103 -> /var/log/apt/history.log.1 (deleted) lrwx-- 1 root root 64 2012-02-16 20:31 11 -> socket:[2407834] lr-x-- 1 root root 64 2012-02-16 20:31 12 -> pipe:[2407886] l-wx-- 1 root root 64 2012-02-16 20:31 13 -> pipe:[2407886] lrwx-- 1 root root 64 2012-02-16 20:31 14 -> socket:[2407888] lr-x-- 1 root root 64 2012-02-16 20:31 15 -> anon_inode:inotify lr-x-- 1 root root 64 2012-02-16 20:31 16 -> /proc/mdstat lrwx-- 1 root root 64 2012-02-16 20:31 17 -> socket:[2407904] lr-x-- 1 root root 64 2012-02-16 20:31 18 -> /proc/10652/mounts lrwx-- 1 root root 64 2012-02-16 20:31 2 -> /dev/null lrwx-- 1 root root 64 2012-02-16 20:31 20 -> socket:[2408112] lrwx-- 1 root root 64 2012-02-16 20:31 21 -> socket:[2408185] lr-x-- 1 root root 64 2012-02-16 20:31 3 -> pipe:[2407826] l-wx-- 1 root root 64 2012-02-16 20:31 4 -> pipe:[2407826] lr-x-- 1 root root 64 2012-02-16 20:31 41 -> /var/lib/dpkg/status (deleted) lr-x-- 1 root root 64 2012-02-16 20:31 43 -> /var/lib/dpkg/status (deleted) lr-x-- 1 root root 64 2012-02-16 20:31 45 -> /var/lib/dpkg/status (deleted) lr-x-- 1 root root 64 2012-02-16 20:31 47 -> /var/lib/dpkg/status (deleted) lr-x-- 1 root root 64 2012-02-16 20:31 49 -> /var/lib/dpkg/status (deleted) lr-x-- 1 root root 64 2012-02-16 20:31 51 -> /var/lib/dpkg/status (deleted) lr-x-- 1 root root 64 2012-02-16 20:31 53 -> /var/lib/dpkg/status (deleted) lr-x-- 1 root root 64 2012-02-16 20:31 55 -> /var/lib/dpkg/status (deleted) lr-x-- 1 root root 64 2012-02-16 20:31 57 -> /var/lib/dpkg/status (deleted) lr-x-- 1 root root 64 2012-02-16 20:31 59 -> /var/lib/dpkg/status (deleted) lr-x-- 1 r
Bug#646620: On Wheezy too
I've just realised that on my workstation running Wheezy this has also happened on the 10th this month, this time the one that was sharing the pipes with run-parts was the cron that had been restarted, this was the upgrade: 2012-02-10 08:13:11,007 INFO Packages that are upgraded: cron debianutils initscripts less libmail-spf-perl rxvt-unicode spf-tools-perl sysv-rc sysvinit sysvinit-utils And this is what the cron's fd looked: lr-x-- 1 root root 64 Feb 16 20:14 0 -> /dev/null l-wx-- 1 root root 64 Feb 16 20:14 1 -> /dev/null l-wx-- 1 root root 64 Feb 16 20:14 2 -> /dev/null lrwx-- 1 root root 64 Feb 16 20:14 3 -> /run/crond.pid lr-x-- 1 root root 64 Feb 16 20:14 44 -> /var/lib/dpkg/status (deleted) lr-x-- 1 root root 64 Feb 16 20:14 46 -> /var/lib/dpkg/status (deleted) lr-x-- 1 root root 64 Feb 16 20:14 76 -> /var/lib/dpkg/status (deleted) lr-x-- 1 root root 64 Feb 16 20:14 78 -> /var/lib/dpkg/status (deleted) lr-x-- 1 root root 64 Feb 16 20:14 80 -> /var/lib/dpkg/status (deleted) lr-x-- 1 root root 64 Feb 16 20:14 83 -> /var/lib/dpkg/status (deleted) lrwx-- 1 root root 64 Feb 16 20:14 85 -> /dev/null lrwx-- 1 root root 64 Feb 16 20:14 86 -> /var/log/unattended-upgrades/unattended-upgrades-dpkg_2012-02-10_08:13:11.007815.log l-wx-- 1 root root 64 Feb 16 20:14 87 -> pipe:[1910384] l-wx-- 1 root root 64 Feb 16 20:14 88 -> pipe:[1910385] lr-x-- 1 root root 64 Feb 16 20:14 89 -> pipe:[1911272] l-wx-- 1 root root 64 Feb 16 20:14 91 -> /var/log/apt/history.log Pipes shared with run-parts were 1910384 and 1910385, it is weird that this cron has all this dpkg and upgrades files opened, without knowing anything about apt or dpkg internals it looks to me that we are not cleaning something when apt or dpkg does the upgrade and services are restarted or similar, what do you think? Ideas? Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#646620: Happening again, this time it was samba having open pipes
This has happened to me on the update of the 30th of January on several servers, I just had the time to check one of them and saw that it was samba that was sharing the pipes with run-parts and thus stopping it and leaving apt defunct. This server runs i386 stable and has a 686 based kernel and runs with anacron, no crons had run since the 30th of January, which can be quite a problem on a server, no logs rotated or anything :-( Ideas? tests? Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#646620: happened again today
Hi! I have found this again today on my desktop at work which is running testing, as the problem was with testing it didn't happen on any of the previous machines showing this as they run stable. root 1005 0.0 0.0 12472 908 ?Ss 07:58 0:00 /usr/sbin/anacron -s root 1251 0.0 0.0 4044 572 ?SN 08:03 0:00 \_ /run-parts --report /etc/cron.daily root 1257 0.0 0.0 0 0 ?ZN 08:03 0:00 \_ /[apt] The problem today has exactly the same behaviour as the last time on stable, exept that today the problem of the sons blocking the apt were not only apache but also udevd, in fact I killed apache like I had done before and apt is still waiting for udevd. Today's upgrade on my machine looked like this: 2011-12-13 08:04:18,623 INFO Initial blacklisted packages: 2011-12-13 08:04:18,647 INFO Starting unattended upgrades script 2011-12-13 08:04:18,647 INFO Allowed origins are: ['origin=Debian,label=Debian-Security,archive=stable', 'o=Debian,a=stable', 'o=Debian,a=testing'] 2011-12-13 08:05:04,058 WARNING package 'openjdk-6-jdk' upgradable but fails to be marked for upgrade (E:Unable to correct problems, you have held broken packages.) 2011-12-13 08:05:05,572 WARNING package 'openjdk-6-jre' upgradable but fails to be marked for upgrade (E:Unable to correct problems, you have held broken packages.) 2011-12-13 08:05:06,947 WARNING package 'openjdk-6-jre-headless' upgradable but fails to be marked for upgrade (E:Unable to correct problems, you have held broken packages.) 2011-12-13 08:05:44,034 INFO Packages that are upgraded: apache2 apache2-mpm-worker apache2-utils apache2.2-bin apache2.2-common asterisk asterisk-config asterisk-modules base-passwd bash busybox cups cups-bsd cups-client cups-common cups-ppdc dconf-gsettings-backend dctrl-tools debianutils dmsetup e2fslibs e2fsprogs eject evolution-exchange fakeroot gimp gimp-data iceweasel iso-codes kbuild libapr1 libcomerr2 libcorosync4 libcups2 libcupscgi1 libcupsdriver1 libcupsimage2 libcupsmime1 libcupsppdc1 libdevmapper1.02.1 libdvbpsi7 libdvdnav4 libdvdread4 libfftw3-3 libflite1 libgail-3-0 libgimp2.0 libgl1-mesa-dri libgl1-mesa-glx libglapi-mesa libglibmm-2.4-1c2a libglu1-mesa libgtk-3-0 libgtk-3-bin libgtk-3-common libgudev-1.0-0 libidn11 libjasper1 libmozjs8d libnet-http-perl libnetaddr-ip-perl libpci3 libperl5.14 libpython2.7 libraptor2-0 libservlet2.5-java libslang2 libss2 libtasn1-3 libtext-iconv-perl libudev0 libvte-common libvte9 libwireshark-data libwireshark1 libwiretap1 libwpd-0.9-9 libwps-0.2-2 libwsutil1 libxenstore3.0 libxerces2-java libxml-commons-resolver1.1-java lvm2 openjdk-6-jre-lib pciutils perl perl-base perl-doc perl-modules python2.7 python2.7-minimal seabios twinkle udev vim vim-common vim-runtime w3m wireshark wireshark-common xmlto xserver-common xserver-xorg-core xserver-xorg-video-nouveau xul-ext-firebug xulrunner-8.0 2011-12-13 08:05:44,048 INFO Writing dpkg log to '/var/log/unattended-upgrades/unattended-upgrades-dpkg_2011-12-13_08:05:44.034974.log' 2011-12-13 08:10:50,063 INFO All upgrades installed So sadly we are still having this problem on current wheezy's packages, at least on setups like mine. I still have the apt and udev around waiting to see if this is going to block the cronjobs tomorrow like it had done on one of my servers or if you want me to test something. How can I help to see what's wrong with this? Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#648604: users are not logged in
Package: lightdm Version: 1.0.6-1 Severity: critical Hi! I have found that when you log into lightdm my user is not shown as logged in, wtm doesn't have a trace about it according to last and neither w or pinky show it as logged in. This is a serious problem as there are scripts that rely on this data to be accurate to protect the system, for example the lid scripts from acpi should trigger xscreensaver to protect the system and they don't as they rely on pinky showing the user, which as I say doesn't atm. I have seen #639988 talking about a dependency on accountsservice and I said, no bug, my fault, I'm missing accountsservice, but the fact is that I have it installed and even with it installed I'm not getting this data. My system gnomity tends to zero, so if any of this stuff relys on any gnome stuff (if like it's said on #639988 accountsservice is too gnomish this may be the case) I may be missing that part. However it is, I really think that lightdm should depend, not suggest or recommend any needed package for it to be able to mark the users as logged into the machine in order for other parts of Debian not to break because of this lack of information. If you need any other info on my setup just ask for it. Regards. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.1.0-1-amd64 (SMP w/1 CPU core) Locale: LANG=gl_ES.UTF-8, LC_CTYPE=gl_ES.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages lightdm depends on: ii adduser3.113 ii consolekit 0.4.5-1 ii dbus 1.4.16-1 ii debconf [debconf-2.0] 1.5.40 ii libc6 2.13-21 ii libglib2.0-0 2.28.8-1 ii libpam0g 1.1.3-4 ii libxcb11.7-3 ii libxdmcp6 1:1.1.0-3 ii lightdm-gtk-greeter1.0.6-1 Versions of packages lightdm recommends: ii xserver-xorg 1:7.6+9 Versions of packages lightdm suggests: ii accountsservice 0.6.15-1 -- debconf information: lightdm/daemon_name: /usr/sbin/lightdm * shared/default-x-display-manager: lightdm -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#646620: Still not able to reproduce it
Yesterday I downgraded the apache packages of one of the affected servers and found that I was not able to replicate the problem. As we still have no real clue on what caused this and I cannot cause more distrubances by testing on the real server I thought I may make a backup of the server this weekend and then replicate it on a virtual machine where I can play with it downgrading all the packages to the pre-upgrade situation. How does that sound to you? Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#646620: unable to reproduce it
I have setup a virtualbox machine downgraded apache and then run the upgrades with the normal cron daily launched from /etc/crontab without any positive results, I'm thinking about downgrading one of the real machines that got hanged and see if it happens with just the apache upgrade or if we need to downgrade more stuff that could be playing some role here. what do you think? Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#646620: Any news on this bug?
> Sorry for the slow reply, I was traveling. No problem, I just don't want this to get forgotten. > I wonder if there is anything else missing to make this reproducable, > is there anything special on your apache setup or anything else that > might help me to reproduce the issue? Well, I'm not aware of anything, they were different computers under different environments, some had anacron, others just plain cron, some were running directly against the repositories, others going through proxies, I have tracked 3 or four machines with this problem wich were as you can see in quite different environments, even different locations and Internet providers. On the apache specifics, some of them have quite some changes on virtualhost configs, I mean, adding a few webs and things like that, but nothing serious, a couple of them have libapache2-mod-php5 to run squirrelmail, but then there is onother one which doesn't and is quite a plain default install just to serve a couple of static files. > Yes, this is definitely a critical bug in my book too, I just need > some more clues (or a way to reproduce) to figure out how to fix it :/ Well I don't now how to help you here, I still have the machine in the hanged status around if you need any other info from it and I can try to send whatever you want from the other ones. Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#646620: Any news on this bug?
Do you need any other info to help solve this bug? I really think that having the upgrades block daily cron jobs on a stable machine is something that should not happen, thus I think we should try to get this solved asap. Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#646620: Same problem on another machine
Knowing that it was apache who was messing with all this problem I have looked at some of the other apaches around and found another machine in the very same state, however not all of my apaches were on this state. I have stopped and then started apache on this newly discovered machine and apt has ended like expected. Regards... -- Santiago García Mantiñán -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#646620: More info on the problem
First I want to tell you that yesterday I upgraded the system manually
without any problem, in fact, previously I had installed reportbug to send
the bugreport, you can see all this on apt history following.
> Do you have anything in the logs (e.g. /var/log/unattended-upgrades.log or
> /var/log/apt/history.log) from around this time that might give a clue why
> this happend?
/var/log/apt/history.log:
Start-Date: 2011-10-10 06:54:12
Upgrade: libkrb5-3:amd64 (1.8.3+dfsg-4squeeze1, 1.8.3+dfsg-4squeeze2),
libk5crypto3:amd64 (1.8.3+dfsg-4squeeze1, 1.8.3+dfsg-4squeeze2),
openssh-server:amd64 (5.5p1-6, 5.5p1-6+squeeze1), base-files:amd64
(6.0squeeze2, 6.0squeeze3), linux-image-2.6.32-5-amd64:amd64
(2.6.32-35squeeze2, 2.6.32-38), update-inetd:amd64 (4.38+nmu1,
4.38+nmu1+squeeze1), libpcap0.8:amd64 (1.1.1-2, 1.1.1-2+squeeze1),
aptitude:amd64 (0.6.3-3.2, 0.6.3-3.2+squeeze1), apache2-mpm-prefork:amd64
(2.2.16-6+squeeze3, 2.2.16-6+squeeze4), grub-pc:amd64 (1.98+20100804-14,
1.98+20100804-14+squeeze1), apache2-utils:amd64 (2.2.16-6+squeeze3,
2.2.16-6+squeeze4), apache2:amd64 (2.2.16-6+squeeze3, 2.2.16-6+squeeze4),
apache2.2-common:amd64 (2.2.16-6+squeeze3, 2.2.16-6+squeeze4),
libkrb5support0:amd64 (1.8.3+dfsg-4squeeze1, 1.8.3+dfsg-4squeeze2),
openssh-client:amd64 (5.5p1-6, 5.5p1-6+squeeze1), linux-base:amd64
(2.6.32-35squeeze2, 2.6.32-38), apache2.2-bin:amd64 (2.2.16-6+squeeze3,
2.2.16-6+squeeze4), firmware-bnx2:amd64 (0.28, 0.28+squeeze1), ssh:amd64
(5.5p1-6, 5.5p1-6+squeeze1), tzdata:amd64 (2011d-0squeeze1, 2011k-0squeeze1),
libssl0.9.8:amd64 (0.9.8o-4squeeze2, 0.9.8o-4squeeze3), openssl:amd64
(0.9.8o-4squeeze2, 0.9.8o-4squeeze3), grub-common:amd64 (1.98+20100804-14,
1.98+20100804-14+squeeze1), libgssapi-krb5-2:amd64 (1.8.3+dfsg-4squeeze1,
1.8.3+dfsg-4squeeze2)
End-Date: 2011-10-10 06:55:38
Start-Date: 2011-10-25 21:01:53
Commandline: apt-get install reportbug
Install: python-reportbug:amd64 (4.12.6, automatic), reportbug:amd64 (4.12.6)
End-Date: 2011-10-25 21:01:57
Start-Date: 2011-10-25 21:13:37
Commandline: apt-get upgrade
Upgrade: libpam0g:amd64 (1.1.1-6.1, 1.1.1-6.1+squeeze1), libfreetype6:amd64
(2.4.2-2.1+squeeze1, 2.4.2-2.1+squeeze2), libpam-modules:amd64 (1.1.1-6.1,
1.1.1-6.1+squeeze1), libpam-runtime:amd64 (1.1.1-6.1, 1.1.1-6.1+squeeze1)
End-Date: 2011-10-25 21:13:50
This seems to show that the upgrade happening on the 10th ended the upgrades
correctly.
This is what /var/log/unattended-upgrades/unattended-upgrades.log shows from
previous day, problematic day and next day:
2011-10-09 06:46:14,445 INFO Initial blacklisted packages:
2011-10-09 06:46:14,445 INFO Starting unattended upgrades script
2011-10-09 06:46:14,445 INFO Allowed origins are: ["('Debian', 'stable')",
"('Debian', 'squeeze-security')"]
2011-10-09 06:46:15,690 INFO No packages found that can be upgraded unattended
2011-10-10 06:53:53,709 INFO Initial blacklisted packages:
2011-10-10 06:53:53,709 INFO Starting unattended upgrades script
2011-10-10 06:53:53,709 INFO Allowed origins are: ["('Debian', 'stable')",
"('Debian', 'squeeze-security')"]
2011-10-10 06:54:11,138 INFO Packages that are upgraded: apache2-mpm-prefork
apache2-utils apache2.2-bin apache2.2-common aptitude base-files firmware-bnx2
grub-common grub-pc libgssapi-krb5-2 libk5crypto3 libkrb5-3 libkrb5support0
libpcap0.8 libssl0.9.8 linux-base linux-image-2.6.32-5-amd64 openssh-client
openssh-server openssl ssh tzdata update-inetd
2011-10-10 06:54:11,139 INFO Writing dpkg log to
'/var/log/unattended-upgrades/unattended-upgrades-dpkg_2011-10-10_06:54:11.138913.log'
2011-10-10 06:55:38,157 INFO All upgrades installed
2011-10-11 06:51:55,205 INFO Initial blacklisted packages:
2011-10-11 06:51:55,205 INFO Starting unattended upgrades script
2011-10-11 06:51:55,206 INFO Allowed origins are: ["('Debian', 'stable')",
"('Debian', 'squeeze-security')"]
2011-10-11 06:51:56,459 INFO No packages found that can be upgraded unattended
> Does this mean that since the 10th no other cron.daily runs for apt happend?
I thought this was the case, and that's why I set the Severity to Critical
but as you can see on the unattended-upgrades log on this machine
unattended-upgrades was run normally on the next day, so cron.daily was
running.
However I have connected to another machine (i386 based) also experimenting
this problem to see how it was behaving and found that indeed this was the
case, no cron.daily was run since the 9th, no logs rotated or any other
cron.daily jobs run. On this machine I have already killed the stale
process and cron.daily is now running normaly, so I wont be able to provide
info of the running processes like on the amd64 based. Here is the
/var/log/unattended-upgrades/unattended-upgrades.log part from the i386
machine that shows this:
2011-10-08 07:58:29,216 INFO No packages found that can be upgraded unattended
2011-10-09 07:36:53,499 INFO Initial blacklisted packages:
2011-10-09 07:36:53,508 INFO Starting unattended upgrades scr
Bug#646620: apt-get defunct when run on unattended-upgrades
Package: unattended-upgrades
Version: 0.62.2
Severity: critical
This is the status of this machine right now:
root 1718 0.0 0.0 22912 1040 ?Ss Sep13 0:02 /usr/sbin/cron
root 29687 0.0 0.0 33292 1100 ?SOct10 0:00 \_
/USR/SBIN/CRON
root 29688 0.0 0.0 11072 1304 ?Ss Oct10 0:00 \_
/bin/sh -c test -x /usr/sbin/anacron || ( cd / && run-parts --report
/etc/cron.daily )
root 29689 0.0 0.0 11076 676 ?SOct10 0:00 \_
/bin/sh -c test -x /usr/sbin/anacron || ( cd / && run-parts --report
/etc/cron.daily )
root 29690 0.0 0.0 3852 588 ?SOct10 0:00
\_ run-parts --report /etc/cron.daily
root 29692 0.0 0.0 0 0 ?ZOct10 0:00
\_ [apt]
As you can see it is 25th Oct now and the apt that is in a zombie state is
from the 10th, I've seen this happen on i386 and amd64 arches at least in
stable, I can't confirm if this has happened on testing/sid as well, but I
think I has happened to me on those as well before.
It seems weird I have not found this bug as it is hitting me from some time
now on machines at work and at home, I tried to look at /proc a bit to find
info on the process but didn't know what to look for and didn't find
anything relevant.
I hope to hear back from you soon and leave the process in that state in
case you want to have a look at some of the data of the running process or
similar.
Please tell me how to proceed from here as I don't know what info to add I
can tell you that this doesn't always happen, it happens from time to time.
I'm setting some of the machines with APT::Periodic::Verbose 3; to gather
some info on other machines that are also seing this.
Any other ideas on what to do?
Thanks in advance.
-- System Information:
Debian Release: 6.0.3
APT prefers stable
APT policy: (990, 'stable'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32-5-amd64 (SMP w/8 CPU cores)
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages unattended-upgrades depends on:
ii apt 0.8.10.3+squeeze1 Advanced front-end for dpkg
ii apt-utils 0.8.10.3+squeeze1 APT utility programs
ii debconf [debconf-2.0] 1.5.36.1 Debian configuration management sy
ii lsb-release 3.2-23.2squeeze1 Linux Standard Base version report
ii python2.6.6-3+squeeze6 interactive high-level object-orie
ii python-apt0.7.100.1+squeeze1 Python interface to libapt-pkg
ii ucf 3.0025+nmu1Update Configuration File: preserv
unattended-upgrades recommends no packages.
Versions of packages unattended-upgrades suggests:
ii bsd-mailx 8.1.2-0.20100314cvs-1 simple mail user agent
-- Configuration Files:
/etc/apt/apt.conf.d/50unattended-upgrades changed:
// Automatically upgrade packages from these (origin, archive) pairs
Unattended-Upgrade::Allowed-Origins {
"${distro_id} stable";
"${distro_id} ${distro_codename}-security";
// "${distro_id} ${distro_codename}-updates";
// "${distro_id} ${distro_codename}-proposed-updates";
};
// List of packages to not update
Unattended-Upgrade::Package-Blacklist {
// "vim";
// "libc6";
// "libc6-dev";
// "libc6-i686";
};
// Send email to this address for problems or packages upgrades
// If empty or unset then no email is sent, make sure that you
// have a working mail setup on your system. The package 'mailx'
// must be installed or anything that provides /usr/bin/mail.
Unattended-Upgrade::Mail "root@localhost";
// Do automatic removal of new unused dependencies after the upgrade
// (equivalent to apt-get autoremove)
//Unattended-Upgrade::Remove-Unused-Dependencies "false";
// Automatically reboot *WITHOUT CONFIRMATION* if a
// the file /var/run/reboot-required is found after the upgrade
//Unattended-Upgrade::Automatic-Reboot "false";
// Use apt bandwidth limit feature, this example limits the download
// speed to 70kb/sec
//Acquire::http::Dl-Limit "70";
-- debconf information:
* unattended-upgrades/enable_auto_updates: true
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#626175: The Squeeze version fails to build from source
This is a known problem with some kernels, it is solved on the new version on testing, you may either build that one or we can try to fix this one, it is just the tests that don't run well on some kernels (modern ones have stopped allowing certain system calls from normal users, it'll build well as root). If you find using the new version good enough for you I'll close the bug, if not, I can try to fix this, but I don't think uploading a new version to stable is worth the trouble. The version on testing compiles and works ok on squeeze, I have tested it on i386 and amd64. Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#519347: FTBFS: seems to fail when building with libzrtpcpp-dev 1.3.0-1
Package: twinkle Version: 1:1.4.2-1 Severity: serious I was trying to build the version for testing and it was failing to build with errors regarding zrtp, I upgraded to libzrtpcpp-dev 1.4.3-3 (the version in unstable and it built ok. I suggest you build-depend on the 1.4 version of zrtp so that it builds cleanly. Regards. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.29-rc6 Locale: LANG=gl_ES.UTF-8, LC_CTYPE=gl_ES.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages twinkle depends on: ii libasound2 1.0.16-2 ALSA library ii libboost-regex1.34.1 1.34.1-15 regular expression library for C++ ii libc6 2.9-4 GNU C Library: Shared libraries ii libccgnu2-1.7-01.7.1-1 A GNU package for creating portabl ii libccrtp1-1.7-01.7.1-2 Common C++ class framework for RTP ii libgcc11:4.3.3-3 GCC support library ii libgsm11.0.12-1 Shared libraries for GSM speech co ii libmagic1 4.26-2File type determination library us ii libncurses55.7+20081213-1shared libraries for terminal hand ii libqt3-mt 3:3.3.8b-5Qt GUI Library (Threaded runtime v ii libreadline5 5.2-3.1 GNU readline and history libraries ii libsndfile11.0.18-2 Library for reading/writing audio ii libspeex1 1.2~rc1-1 The Speex codec runtime library ii libspeexdsp1 1.2~rc1-1 The Speex extended runtime library ii libstdc++6 4.3.3-3 The GNU Standard C++ Library v3 ii libx11-6 2:1.1.5-2 X11 client-side library ii libxext6 2:1.0.4-1 X11 miscellaneous extension librar ii libxml22.6.32.dfsg-5 GNOME XML library ii libzrtpcpp-1.4-0 1.4.3-3 ccrtp extension for zrtp/Zfone sup ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime twinkle recommends no packages. Versions of packages twinkle suggests: pn kaddressbook (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#505473: crashes when viewing www.eroski.es
Package: mozilla-plugin-gnash Version: 0.8.3-6 Severity: grave Hi! I've been testing gnash for some time and found that the version in testing crashes when entering www.eroski.es (machine using testing with linux kernel from testing, arch i386) I had gnash set to pause on load. I have upgraded to the version on unstable and works ok, so this bug only applies to the version on testing, as specified on the bug. Here are some of the messages I'm getting: Nov 12 20:29:12 ace kernel: [ 7483.486080] gtk-gnash[4206]: segfault at 65 ip b6ce1518 sp b6396cf0 error 4 in libfontconfig.so.1.3.0[b6cd9000+29000] Nov 12 20:29:12 ace kernel: [ 7483.524596] gtk-gnash[4208]: segfault at 7d ip b6cfd223 sp b6445eb0 error 4 in libfontconfig.so.1.3.0[b6cf5000+29000] Nov 12 20:29:12 ace kernel: [ 7483.559721] gtk-gnash[4201]: segfault at 1d ip b6c93223 sp bfc24be0 error 4 in libfontconfig.so.1.3.0[b6c8b000+29000] Nov 12 20:29:12 ace kernel: [ 7483.564482] gtk-gnash[4207]: segfault at 0 ip b6d15ad3 sp b6453da0 error 4 in libfontconfig.so.1.3.0[b6d03000+29000] Nov 12 20:29:13 ace kernel: [ 7484.366769] gtk-gnash[4215]: segfault at 21 ip b6d1a223 sp b6462eb0 error 4 in libfontconfig.so.1.3.0[b6d12000+29000] Nov 12 20:29:13 ace kernel: [ 7484.416192] gtk-gnash[4212]: segfault at 662f3c77 ip b6cfead3 sp bf888670 error 4 in libfontconfig.so.1.3.0[b6cec000+29000] Regards. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core) Locale: LANG=gl_ES.UTF-8, LC_CTYPE=gl_ES.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages mozilla-plugin-gnash depends on: ii gnash 0.8.3-6free Flash movie player ii libc6 2.7-15 GNU C Library: Shared libraries ii libgcc1 1:4.3.2-1 GCC support library ii libstdc++64.3.2-1The GNU Standard C++ Library v3 ii libx11-6 2:1.1.5-2 X11 client-side library ii libxi62:1.1.3-1 X11 Input extension library mozilla-plugin-gnash recommends no packages. mozilla-plugin-gnash suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#505199: jesred: doesn't work with squid3
To confirm this morning's bug I have just cleanly installed squid and squid3 with the same jesred config for both and just adding the line "url_rewrite_program /usr/lib/squid/jesred" to the default Debian config (Lenny's current versions). With squid 2.7.STABLE3-1 jesred works ok, but with 3.0.STABLE8-1 it doesn't. So... that will give you my squid configs (default ones with the url_rewrite_program line added) and this morning's mail will give you the jesred.rules I use (rest of jesred config files are the default ones). Hope that helps replicating the problem. Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#505199: jesred: doesn't work with squid3
Package: jesred Severity: grave Justification: renders package unusable I'm using testing on i386 arch with latest packages for lenny. The squid setup is almost the default one, being the bigest change that I'm using transparent proxying by specifying "http_port 80 transparent". While trying to upgrade a setup from squid 2.6 to squid3 I found that the url rewriting scheme was not working, jesred gets the urls but doesn't act uppon them. The problem here seems to be that 2.6 sends petitions like this: http://url 127.0.0.1/localhost - GET - While 3.0 sends something like this: http://url 127.0.0.1/localhost - GET myip=127.0.0.1 myport=80 My setup doesn't include any urlgroup so my jesred.rules reads... regex file.mp3$ http://no.mp3/allowed.html regexi ^http://domain.name http://other.domain.name/url.cgi If I manually run jesred and pass to it a couple of urls matching this rules and ending with a "-" to specify no urlgroup, then it works ok, and if I send the same info ending with the new "myip=127.0.0.1 myport=80" jesred won't match. This is a real execution tests that includes those rules: # /usr/lib/squid/jesred JESRED running as UID 0: writing logs to stderr 1226324254.959 Freeing up old linked lists 1226324254.960 Loading IP List from /etc/jesred.acl 1226324254.960 Reading Patterns from config /etc/jesred.rules 1226324254.961 JESRED (PID 3105) started http://domain.name 127.0.0.1/localhost - GET myip=127.0.0.1 myport=80 http://domain.name 127.0.0.1/localhost - GET - http://other.domain.name/url.cgi 127.0.0.1/localhost - GET 1226324319.787 127.0.0.1/localhost http://domain.name http://other.domain.name/url.cgi 4 As you can see, the new squid scheme doesn't seem to work, while the old one does work. If you need any other info just ask for it. Regards... -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-amd64 (SMP w/2 CPU cores) Locale: LANG=gl_ES.UTF-8, LC_CTYPE=gl_ES.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#503315: Can you add some info, please?
Hi! I'd like to look at this bug from the swfdec side, but I don't even have a url or file that is causing this. Could you please send us a url or file to reproduce this bug? Maybe it would also be good to know what other add-ons do you have installed on your mozilla and any other info that you may see relevant to reproduce this, otherwise I cannot do much. Thanks in advance. Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#499876: libswfdec 0.8
On Oct 21 2008, Sam Morris wrote: > Hi there! Is there any chance you could make your packages of libswfdec > 0.8 available elsewhere? I would like to try out swfdec 0.8. :) I have uploaded them here: http://people.debian.org/~manty/swfdec0.8/ Hope that helps. Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#499876: swfdec-mozilla - FTBFS: Not available build dep: libswfdec-0.8-dev
> Package: swfdec-mozilla > Version: 0.8.0-1 > Severity: serious > > There was an error while trying to autobuild your package: > > E: Couldn't find package libswfdec-0.8-dev libswfdec-0.8-dev was uploaded at the same time as I uploaded swfdec-mozilla, that was back on the 12th of september but it hasn't yet been installed :-( As soon as the ftp masters install the new swfdec, we'll be able to build this new version of swfdec-mozilla. Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#493307: Flash support on Debian
Hi guys! I'm the maintainer of swfdec-mozila which has recently received this bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=493307 The thing is that if you install swfdec-mozilla (which happens when you install for example gnome, which depends on it) you cannot use any of the other packages providing a flash plugin for mozilla derivatives. I've been talking to Miriam (who maintains the gnash plugin) and she has sugested to use alternatives for this, like having /usr/lib/mozilla/plugins/mozilla-flash.so linked to /etc/alternatives/mozilla-flash.so or something similar, and have our plugins installed out of /usr/lib/mozilla/plugins. The name doesn't have to be this one, it could be any other. Would this scheme pose any problem with any of your packages? Do you have any other idea to solve this problem? Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#477404: FTBS on amd64
Package: vdr-plugin-xineliboutput Version: 1.0.0~rc2-14 Severity: serious There seems to be a problem with latest versions which is causing the plugin not to build, you can see it on... http://buildd.debian.org/fetch.cgi?pkg=vdr-plugin-xineliboutput&arch=amd64&ver=1.0.0%7Erc2-16&stamp=1208728321&file=log&as=raw I'm wondering if the problem is on the plugin or on the libs :-? so if the problem is on the libs this bug should be reassigned. Regards... -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.25 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/dash Versions of packages vdr-plugin-xineliboutput depends on: ii libc6 2.7-10 GNU C Library: Shared libraries ii libgcc1 1:4.3.0-3 GCC support library ii libstdc++64.3.0-3The GNU Standard C++ Library v3 ii vdr 1.4.7-3Video Disk Recorder for DVB cards vdr-plugin-xineliboutput recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#477037: swfdec0.5: CVE-2008-1834 local privilege escalation
> CVE-2008-1834[0]: > | swfdec_load_object.c in Swfdec before 0.6.4 does not properly restrict > | local file access from untrusted sandboxes, which allows remote > | attackers to read arbitrary files via a crafted Flash file. Version 0.5 was a development version, we have 0.6.4 on the archives and I'm waiting for it to enter testing, which should happen in a few days. I'm wondering if we can request the removal of swfdec0.5 along with its dependencies (swfdec-mozilla and swfdec-gnome old versions) so that the new ones can enter testing, we've been waiting for arm for more than a month now, and I don't think this will change in the near future, and that is stopping the stable versions from replacing the old development ones :-( Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#476501: New version of libxine1 makes the package uninstallable
Package: vdr-plugin-xineliboutput Version: 1.0.0~rc2-14 Severity: grave There is a new version of libxine1 on the archives which makes this package uninstallable because of its dependency on libxine1 (<< 1.1.12), typically this should be solved by recompiling vdr-plugin-xineliboutput against the new libxine1, however I see you also have bug #473434 open which seems to address this in a better way for the future, so having a look at it doesn't seem a bad idea. Regards... -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.25-rc9 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/dash Versions of packages vdr-plugin-xineliboutput depends on: ii libc6 2.7-10 GNU C Library: Shared libraries ii libgcc1 1:4.3.0-3 GCC support library ii libstdc++64.3.0-3The GNU Standard C++ Library v3 ii vdr 1.4.7-3Video Disk Recorder for DVB cards vdr-plugin-xineliboutput recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#475904: swfdec-mozilla: new stable upstream version 0.6.4 (security release)
> A new version is available on http://swfdec.freedesktop.org/ > http://lists.freedesktop.org/archives/swfdec/2008-April/001321.html If you read that announcement well you'll see that it is for swfdec (the libs) not for swfdec-mozilla, and version 0.6.4 of swfdec has already been uploaded to unstable. Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#472548: new libxine1 on sid makes vdr-plugin-xineliboutput packages uninstallable
Package: vdr-plugin-xineliboutput Version: 1.0.0~rc2-13 Severity: grave The package should be compiled against the new version of libxine1, I have compiled it without any problem and seems to work ok (I'm using libxine1-xvdr). If you need help with the package, want me to NMU or whatever just ask. Regards! -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.25-rc6 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/dash Versions of packages vdr-plugin-xineliboutput depends on: ii libc6 2.7-9 GNU C Library: Shared libraries ii libgcc1 1:4.3.0-2 GCC support library ii libstdc++64.3.0-2The GNU Standard C++ Library v3 ii vdr 1.4.7-3Video Disk Recorder for DVB cards vdr-plugin-xineliboutput recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#456844: same bug on libboost-regex-dev (1.34.1-2.1) and on -3
Hi! I was updating from my own version of -2 compiled against the new libicu to the newly uploaded -2.1 version (which should more or less be the same as my version) when I noticed that the new libboost-regex-dev still depends on libicu36-dev instead of libicu-dev, for what I see you forgot to change that on the Depends of libboost-regex-dev on the control file. This also seems to happen on -3 version which is currently in experimental. Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#431227: KDE related?
Hi! I can run kiax here without any problem here, I don't have KDE libs installed. So I'm wondering if this has something to do with kde stuff on kiax :-??? Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#401845: Tries to use gconf but you don't need have gconf2 installed
Package: gaim Version: 1:2.0.0+beta5-6 Severity: serious Hi! When I tried to upgrade to -6 I got this message: Setting up gaim-data (2.0.0+beta5-6) ... /var/lib/dpkg/info/gaim-data.postinst: 6: gconf-schemas: not found dpkg: error processing gaim-data (--configure): subprocess post-installation script returned error exit status 127 Errors were encountered while processing: gaim-data Looks to me that you are trying to use gconf-schemas on machines that don't have gconf2 installed like mine (no gnome or kde here). I have added a "&& [ -x /usr/sbin/gconf-schemas ]" to the "if" of the postinst and thus I could configure gaim without problem. Regards! -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.19 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages gaim depends on: pn gaim-data (no description available) ii libatk1.0-0 1.12.3-1 The ATK accessibility toolkit ii libavahi-compat-howl0 0.6.15-2 Avahi Howl compatibility library ii libc6 2.3.6.ds1-8GNU C Library: Shared libraries ii libcairo2 1.2.4-4The Cairo 2D vector graphics libra ii libdbus-1-3 1.0.1-2simple interprocess messaging syst ii libdbus-glib-1-2 0.71-3 simple interprocess messaging syst ii libfontconfig12.4.2-1generic font configuration library ii libgcrypt11 1.2.3-2LGPL Crypto library - runtime libr ii libglib2.0-0 2.12.4-2 The GLib library of C routines ii libgnutls13 1.4.4-3the GNU TLS library - runtime libr ii libgstreamer0.10-00.10.10-2 Core GStreamer libraries and eleme ii libgtk2.0-0 2.8.20-3 The GTK+ graphical user interface ii libgtkspell0 2.0.10-3+b1a spell-checking addon for GTK's T ii libice6 1:1.0.1-2 X11 Inter-Client Exchange library ii libncursesw5 5.5-5 Shared libraries for terminal hand ii libpango1.0-0 1.14.8-2 Layout and rendering of internatio ii libperl5.85.8.8-6.1 Shared Perl library ii libsasl2-modules 2.1.22.dfsg1-5 Pluggable Authentication Modules f ii libsm61:1.0.1-3 X11 Session Management library ii libstartup-notification0 0.8-2 library for program launch feedbac ii libx11-6 2:1.0.3-4 X11 client-side library ii libxcursor1 1.1.7-4X cursor management library ii libxext6 1:1.0.1-2 X11 miscellaneous extension librar ii libxfixes31:4.0.1-5 X11 miscellaneous 'fixes' extensio ii libxi61:1.0.1-4 X11 Input extension library ii libxinerama1 1:1.0.1-4.1X11 Xinerama extension library ii libxml2 2.6.27.dfsg-1 GNOME XML library ii libxrandr22:1.1.0.2-5X11 RandR extension library ii libxrender1 1:0.9.1-3 X Rendering Extension client libra ii libxss1 1:1.1.0-1 X11 Screen Saver extension library Versions of packages gaim recommends: pn gstreamer0.10-alsa | gstreame (no description available) pn gstreamer0.10-plugins-base (no description available) pn gstreamer0.10-plugins-good (no description available) ii python2.4.4-1An interactive high-level object-o -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#399316: postinst breaks
> Nope, I am sure it's -n, because I simply don't want a newline. > There are no control characters when interacting with debconf. > > I have uploaded a version that fixes this. Could you please test -6? Sorry, this got lost on my inbox, I have updated to -6 when it hitted unstable and it got installed without any problem, so I suppose that the problem is gone now. Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#400617: It seems FAM was not really wanted
Hi, I believe your bug got too late as the new samba has hit testing today, for what I saw FAM may not be a wanted feature, it is not listed on the build dependencies and in fact arches other than i386, like amd64 for example, don't seem to have a dependency on FAM. If FAM was really not intended I think we should disable it on our config and upload with high urgency to get a version without FAM to testing ASAP. Regards... -- Santiago García Mantiñán
Bug#399316: postinst breaks
Package: mdadm Version: 2.5.6-5 Severity: serious I don't have much info on this one and also the description is not good, but that's all I saw, I upgraded to latest unstable version and postinst fails, going back to the version in testing works perfectly. I even purged mdadm so that I didn't have any old posibly corrupt stuff around but that didn't help either. This is what happens on configuring the package: Setting up mdadm (2.5.6-5) ... -e If your system has its root filesystem on an MD array (RAID), it needs to be started early during the boot sequence. If your root filesystem is on a logical volume (LVM), which is on MD, all constituent arrays need to be started. If you know exactly which arrays are needed to bring up the root filesystem, and you want to postpone starting all other arrays to a later point in the boot sequence, enter the arrays to start here. Alternatively, enter 'all' to simply start all available arrays. If you do not need or want to start any arrays for the root filesystem, leave the answer blank (or enter 'none'). This may be the case if you are using kernel autostart or do not need any arrays to boot. Please enter a space-separated list of devices, 'all', or 'none'. You may omit the leading '/dev/' and just enter e.g. "md0 md1", or "md/1 md/d0".: unknown option debconf: whiptail output to the above errors, giving up! dpkg: error processing mdadm (--configure): subprocess post-installation script returned error exit status 255 Errors were encountered while processing: mdadm E: Sub-process /usr/bin/dpkg returned an error code (1) The above error was when running apt-get upgrade without any LANG on the environment, I typically have [EMAIL PROTECTED] and the message I get before the unknown option is the same one (in english). I'm currently running one of the 2.6.29 rc versions, but I have tested this right now with linux-image-2.6.18-1-k7 (booted with this kernel and then downgraded to testing version and tried to upgrade to unstable again) and it had the same behaviour. I believe that the info that follows will give you enough info to know what I can posibly have around to triger this, if you find something is missing just ask for it. Regards! -- Package-specific info: --- mount output /dev/md1 on / type ext3 (rw,errors=remount-ro) proc on /proc type proc (rw,noexec,nosuid,nodev) sysfs on /sys type sysfs (rw,noexec,nosuid,nodev) devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620) /dev/md0 on /org type ext3 (rw) //rut/ on /rut type smbfs (rw) --- mdadm.conf # mdadm.conf # # Please refer to mdadm.conf(5) for information about this file. # # by default, scan all partitions (/proc/partitions) for MD superblocks. # alternatively, specify devices to scan, using wildcards if desired. DEVICE partitions # auto-create devices with Debian standard permissions CREATE owner=root group=disk mode=0660 auto=yes # automatically tag new arrays as belonging to the local system HOMEHOST # instruct the monitoring daemon where to send mail alerts MAILADDR root # definitions of existing MD arrays ARRAY /dev/md1 level=raid1 num-devices=2 UUID=7c5670d2:4f54e411:411e9714:06c414bd ARRAY /dev/md3 level=raid1 num-devices=2 UUID=1a0e867b:10db3608:1fdec9ed:ef4caaf2 ARRAY /dev/md0 level=raid0 num-devices=2 UUID=4c6bd397:87a82545:da8f260e:16a8eca0 # This file was auto-generated on Thu, 16 Nov 2006 17:55:28 +0100 # by mkconf $Id: mkconf 240 2006-10-26 20:42:03Z madduck $ --- /proc/mdstat: Personalities : [raid0] [raid1] md1 : active raid1 hdd3[0] hda3[1] 10040512 blocks [2/2] [UU] md3 : active raid1 hdd5[0] hda5[1] 401472 blocks [2/2] [UU] md0 : active raid0 hdd6[0] hda6[1] 285265920 blocks 64k chunks unused devices: --- /proc/partitions: major minor #blocks name 3 0 156290904 hda 3 13212968 hda1 3 3 10040625 hda3 3 4 1 hda4 3 5 401593 hda5 3 6 142633071 hda6 2264 156290904 hdd 2265 722893 hdd1 2267 10040625 hdd3 2268 1 hdd4 2269 401593 hdd5 2270 142633071 hdd6 9 0 285265920 md0 9 3 401472 md3 9 1 10040512 md1 --- initrd.img-2.6.19-rc5: --- /proc/modules: -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.19-rc5 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages mdadm depends on: ii debconf [debconf-2.0]1.5.9 Debian configuration management sy ii libc62.3.6.ds1-8 GNU C Library: Shared libraries ii lsb-base 3.1-20 Linux Standard Base 3.1 init scrip ii makedev 2.3.1-83creates device files in /dev Versions of packages mdadm recommends: ii module-init-tools 3.3-pre3-1 tools for managing Linux ker
Bug#375894: kiax DFSGness not taken seriously
Package: kiax Version: 0.8.51.dfsg-1-1 Severity: serious Hi! We had a package that we knew was dfsg compliant, I had removed the lib stuff which had several license problems because of that and then renamed it to dfsg as we had agreed that it was dfsg compliant, now... I found of a bad taste that a new "dfsg" package was uploaded, as I had objected to the DFSGness of this new package, today I have looked at it more carefully and I found out what had been said before, please somebody correct me if I'm wrong, but... 1- the echo cancellation stuff doesn't have a license we can use to say it's free, this has been discussed before (see Emil Stoyanov [1] message to the list) and I didn't read anybody saying that it was no longer like that 2- the iLBC stuff is stil non-free as it used to be that way and it hasn't changed its license. Other than that, having a program include on its sources at least 4 of our already packaged libs and use those sources to compile them statically instead of using our tested libs seems a really bad way of packaging something. So... after having a package that could go into Debian because it was free, we have now come back to the sources that our ftp masters had rejected because they were non-free. This really seems nonsense to me, I don't know if I have to take this as a joke or what, who didn't read the list or didn't at least didn't look at the sources that he was packaging, or... I just can't explain this, please somebody explain this for me. I had to check twice that what I was looking at were the sources coming from cc39dab9cb55afbe9722a6f4ad2bb5f0 kiax_0.8.51.dfsg-1.orig.tar.gz and not from the old non-free version we used to have, and in fact all non-free stuff is in there. I hope I'm missing something with all this, otherwise I don't know what we are playing at, this seems completely nonsense and a Debian developer should be more cautious with what he uploads at least once he knows there are problems with licenses on some parts of a software. Regards... -- Manty/BestiaTester -> http://manty.net [1] http://lists.alioth.debian.org/pipermail/pkg-voip-maintainers/2006-May/004800.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#366148: ost_check2.m4 provided by -doc in i386 while by -dev in other arches
Package: libcommoncpp2 Severity: serious While tracking a FTBFS on twinkle I found out that ost_check2.m4 was missing for i386's libcommoncpp2-dev and that it is provided by libcommoncpp2-doc. This means that if a program needs ost_check2.m4 so that aclocal can produce a good output, the program must depend on the libcommoncpp2's doc on i386 so that it can be compiled, which is of course nonsense. On the other side... other arches however provide ost_check2.m4 on libcommoncpp2-dev which makes libcommoncpp2-dev and libcommoncpp2-doc conflict as they both provide /usr/share/aclocal/ost_check2.m4 on every arch but i386 (I have just tested this on amd64). I have rebuilt libcommoncpp2 on current sid right now in case the bug could be fixed by a rebuild but ost_check2.m4 was still in the -doc package and not in the -dev. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#352243: Will be solved soon (libsysfs2 on its way)
Sorry about this, I just thought libsysfs2 was already on unstable and that I was late about the libsysfs2 transition already as we had talked about a shorter timeframe, so I didn't check to make sure libsysfs2 was there. Anyway, Martin is about to upload libsysfs2 this week (around tomorrow) or so seems to be the plan if he doesn't delay it :-) When that happens this bug will disapear an we'll all be happier. Sorry about the inconveniences, if somebody wants to install previous unstable version of bridge-utils, which has all the dependencies correctly satisfied in unstable, he can get the version from testing, which is the same one as we used to have in unstable previous to this premature upload of mine. Regards... -- Manty/BestiaTester -> http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
