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
> 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
>
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
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
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
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%[>
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
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
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
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
Hi!
As expected, this does still happen on the 4.9.16 kernel in unstable at this
time.
Regards.
--
Manty/BestiaTester -> http://manty.net
> 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
> 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
> 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
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
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?
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,
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
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
> 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
> 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
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
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
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:
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 -
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
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
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...
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
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
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
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
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
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.
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
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
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
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
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
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
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
61 matches
Mail list logo
