Bug#639830: mdadm: alternative md-device names
On 26.05.2012 18:11, Michael Tokarev wrote: [] > when generating the image. The only possible case I can think > of is when you listed > > INITRDSTART=/dev/md0 > > (the same as for root filesystem in fstab), but using /dev/md/0 > in mdadm.conf -- in this case, mkinitramfs reports: > > W: mdadm: I am supposed to start /dev/md0 from the initial ramdisk, > W: mdadm: yet I cannot find the array in the configuration file. > W: mdadm: I am thus reverting to starting all arrays. > > But actually it does not start anything during initramfs, in the > way you observed. There's one more possibility: both places actually listed /dev/md/0, but that device - which is just a symlink to ../md0 - did not exist during (re)creation of initramfs, so due to already mentioned change the previous piece of the script switched from md/0 to md0. > Is (was) that the case, can you remember/comment ? I think we should stop using any prefixes for the devices anywhere in all scripts, stripping /dev/md and /, and always generate /dev/md/X - which will create both md/X and mdX. This is ugly, but will keep the system bootable... There's another possibility -- to try to detect such a disparity (when one place uses one name and another place uses alternative name) and fail if found. But I like this version less, -- it is less ugly in case of the device nodes it creates, but it has more chances to make the system unbootable... Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#658701: mdadm: should send email if mismatches are reported by a check
Neil, can you comment on the change to Monitor offered in the mentioned bugreport please? On 12.04.2012 23:28, Michael Tokarev wrote: > Neil, re http://bugs.debian.org/658701 , how do you think, > is it okay if mdadm --monitor will send email in case check > found mismatches, the same way it sends email about other > more critical errors? > > I think Russell has a good point here, but there's one more > source of mismatches we have in kernel - some "sporadic" > mismatches in raid1 and raid10, especially when these are > used as swap space... > > In Debian we've several bugreports already requesting more > attention to mismatch_cnt, see: > > http://bugs.debian.org/658701 (this one) > http://bugs.debian.org/599821 > http://bugs.debian.org/588516 > > Thank you! > > /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#639830: mdadm: alternative md-device names
On 26.05.2012 19:03, Cristian Ionescu-Idbohrn wrote: [] >> Note also that you still have the same inconsistency -- you list >> /dev/md/0 in mdadm.conf, but use /dev/md0 as root filesystem. I >> can't say it works by design, more by a chance, it is better to >> use consistent naming there. > > Alright. You possibly mean changing /etc/fstab? Is /dev/md/0 the > preferred device name (and /dev/md0 an alias) or the other way around? Well. This is an interesting question. I'd say it is similar to /dev/sdXY and /dev/disk/by-*/*. Which is "primary" and which is "alias" is impossible to say. In real life, /dev/disk/* is a symlink to /dev/sdXY, so /dev/sdXY is a device node and /dev/disk/* is an alias. But /dev/sdXY, while "primary" according to this "definition", is actually some random XY, it may change on next reboot (or even during system runtime), -- say, because you unplugged and replugged the corresponding drive. But /dev/disk/* will always have the same name and will always point to _current_ incarnation of the drive in question. So based on this, it is really impossible to say which is primary and which is alias - it depends on your PoV. For md devices, things currently are similar: /dev/mdX is actual device node, while /dev/md/X is a symlink. And for md device names it is actually possible to not have such a double naming, by always using only one /dev/md/X name -- for the actual _device_ node, not a symlink. But this means compatibility will be broken, which is a no-no. So we have what we have: historical naming scheme plus "more user-friendly" naming scheme. Note that the /dev/md/X name may be some string, not only number -- like, /dev/md/myfancyraid5array. It will be a symlink to something like ../md128 (with 128 is next free number >=128). But if X is a number <128, it will be the same X in /dev/mdX as in /dev/md/X, and the same minor number too. Traditionally there were only /dev/mdX names (0 <= X <= 127 IIRC), and when "free" naming were introduced /dev/md/ prefix was used, but now for these traditional mdX names we've two alternative naming schemes, neither of which is "primary" or "main". BTW, the same thing can be said about dm nodes, and there we'v some disparity too. LVM has always used /dev/mapper/* names, but these has always been symlinks to /dev/dm-XX (where XX is just next free number). These dm-XX names weren't mentioned much in documentation, but you may see them in output from various tools like df, or in kernel messages - and now it is more difficult to map from dm-XX to the actual array name in /dev/mapper/*. And they actually have two naming schemes -- /dev/mapper/vg-vn and /dev/mapper/vg/vn, -- neither of which is "primary" either. >> W: mdadm: I am supposed to start /dev/md0 from the initial ramdisk, >> W: mdadm: yet I cannot find the array in the configuration file. >> W: mdadm: I am thus reverting to starting all arrays. > > Yes, I do recall those messages ;) Okay, this is *excellent* Cristian! I was worried about these -- if you didn't see the warnings, it means the problem is elsewhere. Now when you confirmed you've seen them, I can be sure I identified the issue correctly. The only question left is how to fix it (which I mentioned in another email), I'll think about it more... Thank you! /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#674843: roxterm is unable to start new tab/window when current directory does not exist
Source: roxterm Version: 2.6.3-1 Severity: normal This is another variant of #639687. When current directory of the shell running inside a roxterm window gets removed, there's no way to start a new window/tab: roxterm complains that it can't chdir to a deleted directory because that directory does not exist, and refuses to open new tab/window. Steps to reproduce: open roxterm window with shell mkdir /tmp/dir cd /tmp/dir rmdir /tmp/dir try to open new roxterm window/tab It might warn about the fact that the directory does not exist, or it may not (I'd say displaying a warning is sort of annoying in this case, just like with root-owned child process), but it definitely should not fail to create new window/tab, which may just start with user's home directory just like in the case with root-owned child process. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#674919: Fails to start with -fsdev
tags 674919 + moreinfo unreproducible thanks On 28.05.2012 20:00, Wakko Warner wrote: > Package: qemu-kvm > Version: 1.0+dfsg-11 > Severity: important > > I'm using libvirt 0.9.9-3+b2 to start VMs with kvm. I just upgraded qemu-kvm. > I am no longer able to start VMs where I have defined a file system device. > My previous version was 1.0+dfsg-9 > > This is what I see: > # LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin > HOME=/root USER=root LOGNAME=root /usr/bin/kvm -S -M pc-0.14 -cpu core2duo > -enable-kvm -m 512 -smp 1,sockets=1,cores=1,threads=1 -name iscsiinit -uuid > 128a255b-23db-a249-53ad-4226bc2f129e -nographic -nodefconfig -nodefaults > -chardev > socket,id=charmonitor,path=/var/lib/libvirt/qemu/iscsiinit.monitor,server,nowait > -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown > -drive file=/vm/iscsiinit.qcow2,if=none,id=drive-virtio-disk0,format=qcow2 > -device > virtio-blk-pci,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0 > -fsdev local,security_model=mapped,id=fsdev-fs0,path=/var/local/kvm/kernel > -device > virtio-9p-pci,id=fs0,fsdev=fsdev-fs0,mount_tag=kernel,bus=pci.0,addr=0x3 > -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 > -usb -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 > char device redirected to /dev/pts/5 > > (process:14897): GLib-CRITICAL **: g_thread_pool_new: assertion > `g_thread_supported ()' failed > worker thread initialization failed > # > > Removing the > -device > virtio-9p-pci,id=fs0,fsdev=fsdev-fs0,mount_tag=kernel,bus=pci.0,addr=0x3 > I get this: [works] I can't reproduce this. It works here with 1.0+dfsg-11 just fine: $ kvm -fsdev local,security_model=mapped,id=fsdev-fs0,path=/var -device virtio-9p-pci,id=fs0,fsdev=fsdev-fs0,mount_tag=kernel,bus=pci.0,addr=0x3 -M pc-0.14 -nodefaults -vga std What I'm doing wrong? Maybe there are some other options which interfere, but I've no time right now to experiment further. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#674919: Fails to start with -fsdev
On 29.05.2012 07:56, Wakko Warner wrote: [] > (process:14897): GLib-CRITICAL **: g_thread_pool_new: assertion > `g_thread_supported ()' failed > worker thread initialization failed [] > You know what, forget all of the above. My libglib version is 2.28.6-1. I > extracted the library from libglib2.0-0_2.32.3-1_amd64.deb and ran: > LD_LIBRARY_PATH=/junk/kvm/glib/lib/x86_64-linux-gnu > /junk/kvm/qemu-kvm-1.0-11-debian/usr/bin/kvm -fsdev > local,security_model=mapped,id=fsdev-fs0,path=/var -device > virtio-9p-pci,id=fs0,fsdev=fsdev-fs0,mount_tag=kernel,bus=pci.0,addr=0x3 -M > pc-0.14 -nodefaults -vga std > and it works fine. > > The fix for this bug might be to just depend on a newer version of > libglib2.0-0. I upgraded this package on my system and qemu-kvm and > everything is happy. Thank you Wakko, thank you very much for finding this. Trying different glib version is something I'd do at the very end if I had to debug this problem, so it is very unlikely I'd found it even if I really tried... ;) And note I'd start with squeeze version (see below) and that'd failed to reproduce the issue too :) Now, it is actually interesting. libglib2.0-0 version in squeeze is 2.24.2-1, and that version actually _works_. I don't have 2.28.6-1 version around (I know about snapshot.d.o). It is even more interesting that the problem only manifests itself when using this -fsdev option. When qemu-kvm is compiled against current version of libglib2, the dependency placed for the package is ">= 2.24.0" (this is a manual dependency from soversions file in libglib package). That file becomes out of date quite often, for many and especially complex packages, since it is difficult to watch for the symbol or behavour changes carefully. The difference between -9 and -11 packages regarding glib is that -9 were compiled against older libglib package (pre-2.32), while when I compiled -11, some 2.32.x version were current. So this sort of proves this theory, which becomes a mismatch between more recent libglib headers or library and older runtme library (which is all about that soversions file). Hmm. I'll try to take a look at all this when I've some spare time (as I already mentioned I'm quite busy currently). But at least, can we downgrade the severity of the bug now, please? :) And thank you very much, once again, for the great work you did by finding the real cause, really, much apprecated! /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#674391: autofs upload [update]
On 01.06.2012 16:23, Michael Tokarev wrote: > On 01.06.2012 16:15, Dmitry Smirnov wrote: >> Hi Michael and William >> >> Dmitrijs called off his NMU and expressed his interest to join our team >> while I updated repository with more changes. > > I'm doing some last-minute changes too, which we discussed > before (namely, including the initscript). > > The ftbfs with kmod/module-init-tools is due to my change, > I removed the ugly config.h patching in > 450dfb2c4fc1d6caf7653a3bef33c2aa5e897361. > In order to fix the issue right, the easiest solution is > to set ac_cv_path_MODPROBE=/sbin/modprobe before invoking > ./configure. Ditto for the related test which I also removed > in the same commit, for linux /proc filesystem (HAVE_LINUX_PROCFS). Ok. This is just too much wrong. Dmitry, your two changes, both marked as fixing #674391, are wrong and needs revered. First, a small thing, the kmod change, c6ac061e12208cdf32291223b27caeefec6ce241. Here's the changelog difference from it: [Dmitry Smirnov] - * update upstream patches to avoid patching 'configure' (Closes: #674391) + * added 'kmod' to Build-Depends to fix FTBFS (Closes: #674391) + * update upstream patches to avoid patching 'configure' * use 'autoconf' to regenerate 'configure' Now please tell me how this kmod thing is relevant for #674391? It is wrong, and it is very confusing, since I started thinking about entirely different thing and not about the real problem. The change itself is right, well, sort of, -- it fixes the issue as the package isn't built correctly without /sbin/modprobe (even if it never uses /sbin/modprobe to start with, which is a different issue). But the misplacing of the Closes/FTBFS line is troubling. I reverted this whole commit. And second, the more serious change, which actually tries to fix the FTBFS mentioned in #674391. You took a wrong approach with this, by taking patches from upstream and removing patching of configure. This way, we're patching upstream patches, the result is a unverifiable mess. (Why upstream keeps configure in git is another question, to which there's no sane answer). The proposed by Dmitrijs approach -- using dh-autoreconf or similar, plus maybe patching Makefile to not remade configure.in (which is another strange thing to do) -- is the way to go here. dh-autoreconf will save all autoconf-related files and will restore them in `clean' target, making whole thing working. Alternatively, if you think dh_autoreconf is too heavy somehow, it is possible to save configure.in and configure in debian/rules "configure" step and restore them in "clean" target without using helpers/addons, it is just as easy. Now, we need to re-run autoconf anyway. I'm reverting this change too, because it is just the wrong thing to go. I'll try to fix this mess in a most accurate way, but we have more and more work to resolve with upstream, the package (upstream code) is in rather bad state. Dmitrijs: #674391 contains another change which everyone missed now, about gold and --no-as-needed, which should be incorporated too, I think. Oh well. /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#674391: autofs upload [update]
On 01.06.2012 18:42, Dmitry Smirnov wrote: > Hi Michael, > >> Dmitry, your two changes, both marked as fixing #674391, >> are wrong and needs revered. >> >> First, a small thing, the kmod change, >> c6ac061e12208cdf32291223b27caeefec6ce241. >> Here's the changelog difference from it: >> >> [Dmitry Smirnov] >> - * update upstream patches to avoid patching 'configure' (Closes: #674391) >> + * added 'kmod' to Build-Depends to fix FTBFS (Closes: #674391) >> + * update upstream patches to avoid patching 'configure' >> * use 'autoconf' to regenerate 'configure' >> >> Now please tell me how this kmod thing is relevant for #674391? > > Please feel free to undo my latest change introducing 'kmod' to Build-Depends. > > Initially I thought I already fixed #674391 but today when I was > building in pbuilder there were FTBFS. I did not tracked it to your > change and thought that I could have been wrong regarding diagnosis of > reported FTBFS' cause and that it was related to recent changes in > 'sid'. (It would be nice if you try to avoid breaking master with > incomplete commits or mark them as such) > I realised that this change was unrelated from one of your earlier > emails and since I already mentioned to you what I did I thought you > would realise what's happened. Ok. Asi I said, this was a minor thing, confusing but minor -- misplaced Closes: comment. >> And second, the more serious change, which actually tries to >> fix the FTBFS mentioned in #674391. > > Not 'tries' - it fixes it. > > >> You took a wrong approach with this, by taking patches from >> upstream and removing patching of configure. This way, we're >> patching upstream patches, the result is a unverifiable mess. >> (Why upstream keeps configure in git is another question, to >> which there's no sane answer). > > Wait a sec., before criticising, consider that we don't have to patch > with pristine patches. I'm not sure why do you call it 'unverifiable' > - I'm quite concerned regarding not having hack-ish workaround for > upstream mess. > > Removing junk from upstream patches reduces the size of archive and > allows us to have nice and tidy packaging. I worry not at all about sizes of archive at this level. The "junk" you removed takes so tiny fraction, especially in compressed form, it is not even funny to mention that. But the thing is: what you call "junk" is what the upstream author applied. Yes patching configure or, generally, keeping all these generated files in git is not a good idea, and should be addressed upstream for sure. But you took upstream patches, and please respect their authorship. Once you modified these, they're not upstream anymore, and their origin is unclear. Now I looked at the upstream patches and I have strong feeling that these must be regenerated to at least include git hashes from upstream repository, -- this is what i call "verifiable". When the amount of patches grows like this, and they are being modified here and there, it becomes impossible to understand what actually changed, ie, auditing the resulting mess is almost impossible. I can partially understand such a situation when one need to backport a later patch to earlier source, and it _has_ to be changed since the code in earlier version was different. But such a backporting best be keept at minimum, maybe for only critical changes. You, instead, takes upstream patches directly, there's just no _need_ to modify them to start with. I think you took wrong way with these patches to start with -- if you take all upstream patches anyway, I'd have just one diff with all of them autogenerated by git diff, without modifying the content. But that's a different story, and _that_ is what makes the packaging nice and tidy. > I was experimenting with different approaches for hours and what I did > is the clean and nice alternative to some other things I tried. > Why do you protect those junky hunks in upstream patches?? These junky hunks is what upstream have. >> The proposed by Dmitrijs approach -- using dh-autoreconf or >> similar, plus maybe patching Makefile to not remade configure.in >> (which is another strange thing to do) -- is the way to go here. >> dh-autoreconf will save all autoconf-related files and will >> restore them in `clean' target, making whole thing working. > > We can do it, but it would be nice to discuss why it is better (if it is). > At the moment I do not like this approach. > > dh-autoreconf is great and I use it in some of my packages but here it > looks like it would be unnecessary overkill just for the sake of > having dirty patches for generated files. Dmitry, this really makes me a bit concerned. This is 3rd discussion I'm having with you. First was about keeping upstream in git - okay, I don't want to "force" it on you if you dislike it. Second was "wrong" approach I took with default/autofs patch, and there we had quite hot discussion till I explained things to you. Now it is 3rd case in a row when
Bug#674391: marked as done (autofs: FTBFS: dpkg-buildpackage: error: dpkg-source -b autofs-5.0.6 gave error exit status 2)
Lucas, can you please verify the new release actually fixes the bug you reported? We made some changes in attempt to fix this issue, but Dmitry says it still fails to build, and I can't reproduce it locally. Thank you! /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#675592: override: autofs5:oldlibs/extra autofs5-hesiod:oldlibs/extra autofs5-ldap:oldlibs/extra
Package: ftp.debian.org Following the autofs package rename (from autofs5 to autofs), the old package names become dummy/transitional, hence oldlibs/extra. New packages are autofs, autofs-hesiod and autofs-ldap. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#652573: busybox-udeb: debian stable busybox udhcp client does not support /32 netmasks
On 18.12.2011 22:28, Michael Tokarev wrote: > On 18.12.2011 22:23, Michael Tokarev wrote: >> On 18.12.2011 22:16, Petter Reinholdtsen wrote: >>> >>> Package: busybox-udeb >>> Version: 1:1.17.1-8 >>> >>> The Debian/Squeeze installer fail with /32 netmasks provided from DHCP. >>> >From https://bugs.busybox.net/show_bug.cgi?id=4604 >: >>> >>> debian stable busybox udhcp client does not support /32 >>> netmasks. Changing the netmask to <32 works. >> >> The /32 netmask for a host is at least non-standard. I'm not sure >> it is ever possible to _use_ such a netmask on an ethernet interface >> on any other system but linux - it definitely is impossible to use >> on windows, not sure about *bsd and others. Peter, can you give some more details please, maybe some hints on how to setup the test environment / dhcp server? Looking at the dhcp client code in busybox - either current 1.20 or squeeze 1.17 version, I don't see where it might not work. The /32 (255.255.255.255) netmask should Just Work. So in order to do something with this bugreport (as opposed to just forgetting about it entirely), I need some reproducer/verifier... Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#652573: busybox-udeb: debian stable busybox udhcp client does not support /32 netmasks
On 02.06.2012 23:59, Conrad Wood wrote: [] > In some "cloud" environments, including ours, we configure an ethernet device > with a single /32 IP Address. Say, for example 5.6.7.8/32. The Default > Gateway is, for example, 9.10.11.12. The linux kernel and BSD happily work as > desired and send out an arp request out of the ethernet device and route > _everything_ to the default gateway. > Configuring this manually is straightforward and works as desired. > Using the ISC-DHCP client also works as desired. It picks up IP, Netmaks and > gateway perfectly well. > However, in the installer, with the busybox dhcp client, it stalls and claims > it is unable to configure the network interfaces. Anything _apart_ from /32 > (say /31, /30 etc.) works ok. But then the gateway won't be reachable, as the > kernel then tries to do 'propper(?)' routing instead of just forwarding the > packets. Did you try using busybox dhcp client on an already installed system, as opposed to the debian installer? I just tried - dnsmasq as dhcp server, and squeeze busybox - it accepts the /32 netmask just fine and configures the interface accordingly. I had to overwrite "netmask" option on the server, setting it explicitly, and I verified with tcpdump that the server sends correct DHCP reply with the right netmask. But I'm not actually sure how debian installer configures the network... Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#635548: CVE-2011-2716
On 03.06.2012 13:43, Thijs Kinkhorst wrote:
> Hi all,
>
> Reading the bug about CVE-2011-2716, I think the only question left is this:
>
>>> So, in all cases the variable is enclosed in double quotes.
>>
>> Yes this look secure. What about the udeb script?
>> /debian/tree/busybox-udeb/usr/share/udhcpc/default.script:
>> do_resolv_conf() {
>> local cfg=/etc/resolv.conf
>>
>> if [ -n "$domain" ] || [ -n "$dns" ]; then
>> echo -n > $cfg
>> if [ -n "$domain" ]; then
>> echo search $domain >> $cfg
>> fi
>>
>> for i in $dns ; do
>> echo nameserver $i >> $cfg
>> done
>> fi
>> }
>>
>> Not quoted in thsi case.
>
> Does this still need to be fixed? If it is fixed then I think we can
> consider this issue done.
The version of busybox currently in experimental verifies
all the strings returned by dhcpd and if any bad char is
found, it replaces the whole thing with literal string
"bad" when exporting the variable to the script. So
there should be no need to quote anything anymore.
I haven't closed this bug becaue I merely forgot about it,
and because I also wanted to recheck all open bugs when
finally uploading busybox 1.20 to unstable. My current
changelog contains mentions of closing of this bug, too.
Thank you for the reminder, this means these serious issues
weren't forgotten! And indeed they weren't!.. :)
/mjt
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#639529: summary: please add entry to /etc/nsswitch.conf
On 03.06.2012 12:21, Andreas B. Mundt wrote: > Hi, > > first, thank you all for the work on a refurbished autofs package! I > would like to draw your attention to #639529, as it would be great to > fix this before the wheezy freeze and it's just a minor modification. > > Let me sum up, as the lengthy history of the issue might be confusing: > > The name service switch functionality allows to assign different > resources for various informations like passwords, groups etc. > The resource to use is defined in "/etc/nsswitch.conf". Everybody > using the autfs-ldap package needs to add: > > "automount: files ldap" Will it be bad if this line will be left out after removing autofs-ldap package, ie, when automount nsswitch entry is listing non-existing lookup method? I guess I should try... I mean, is it a bug to leave "ldap" in there on autofs-ldap removal? Because I want to minimize messing up with this file as much as possible. For example, the user might reorder the entries after installation, but on removal and reinstall we'll move "ldap" entry there to the end, which might be considered a bug too... Thanks, /mjt > to "/etc/nsswitch.conf". This activates the look up of mount points > in LDAP. For example, this has to be done in debian-edu and > debian-lan. > > The patches already attached above make sure the line needed is added > on installation and removed after purging the autofs-ldap package. > Modifying "/etc/nsswitch.conf" is fine, cf. [1]. A similar patch has > been applied to sudo-ldap, cf. #639530. > > Thanks, > > Andi > > > > [1] Modifying nsswitch.conf shouldn't be a problem, quoting from > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=610600#34>: > > "Usually, policy forbids that a package modifies the "configuration > file" of another package, but in this case /etc/nsswitch.conf is not a > conffile in dpkg sense but just a default. This is on purpose so that > packages that need to modify such file do so without having to ask me > about that. > > Therefore, I think we should just modify sudo-ldap so that the > required line is added to /etc/nsswitch.conf on postinst and removed > on purge, as only users of sudo-ldap need such line, i.e. please do > not rely on base-files and just do with nsswitch.conf whatever is > required for it to work with your package." > > > -- > > -- > > A N D R E A S B. M U N D T > > GPG key: 4096R/617B586D 2010-03-22 Andreas B. Mundt-- >Andreas B. Mundt-- > > > > > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#672112: qemu-kvm VM W2K3 quest reloads (crashes) when there are several VM and some server load.
tags 672112 + moreinfo unreproducible pending thanks On 08.05.2012 17:23, Tomas Martišius wrote: > Package: qemu-kvm > Version: 1.0+dfsg-11 > > Severity: serious > > qemu-kvm VM W2K3 quest reboots (crashes with blue screen) when there are > several VM on intel xeon server and some server load/IO wait. I haven't ran w2k3 guests for a while. Now I tried running my old guest, but I can't reproduce the problem. So please provide steps to reproduce. > After qemu-kvm package rebuilt using latest (2012-04-27) source from git > problem does not shows any more. That's good to know. So I'll mark this bugreport as "done" automatically once we upload next release of qemu-kvm. Tagging as "pending". So thank you for the best bugreport out there -- completely useless since it has no details whatsoever and is already fixed... ;) /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#672287: -M pc-0.12 -vga std aborts
Package: qemu-kvm Version: 1.0+dfsg-1 Severity: normal Tags: patch, upstream Using -vga std and -M pc-0.12 results in qemy assertion fault right at virtual machine startup: $ kvm -vga std -M pc-0.12 kvm: /build/buildd-qemu-kvm_1.0+dfsg-11-i386-hf29ru/qemu-kvm-1.0+dfsg/memory.c:1239: memory_region_add_subregion_common: Assertion `!subregion->parent' failed. Aborted This case is important to support, since -M pc-0.12 is used by libvirt by default for virtual machines installed on a squeeze host, and -vga std is quite common setting too. This is an upstream bug, with a fix posted: http://thread.gmane.org/gmane.comp.emulators.qemu/150066 /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#671701: RFS: autofs/5.0.6-1 [ITA] -- kernel-based automounter for Linux
On 06.05.2012 10:16, Dmitry Smirnov wrote: > On Sun, 6 May 2012 15:24:10 Michael Tokarev wrote: >> And note that whole 5.0.6-allow-for-kernel-packet-size-change.patch >> is NOT NEEDED, it should be reverted upstream. *SIGH*, we spent >> a ton of time and emails discussing this matter, please find >> the recent LWN feature article about it (a good summary), or >> LKML threads. The patches are now added to all stable trees. >> >> The two patches -- linux kernel version check and this one -- >> should be reverted upstream and not included in debian package. > > Thanks for this, I trust you that we don't need > 5.0.6-allow-for-kernel-packet-size-change.patch > > However it is not too easy to just drop this patch because it will break the > chain of upstream patches. Possibly we need to apply all upstream patches and > then use our new patch to revert some of their changes... Or maybe consider > ignoring upstream patches... What do you think would be the best? > > Dropping kernel version check is a bit challenging as well due to multiple > references to this code. If you're sure it will be a cause for any troubles > perhaps we could modify the code of 'linux_version_code' function instead of > dropping it completely... I exchanged a few emails with Ian, and the plan is to keep all this stuff (but fixing the version check to allow 2-component version strings). With new kernel interface it does not really matter if we read larger or smaller packet, so the patch in question -- 5.0.6-allow-for-kernel-packet-size-change.patch -- makes no difference anyway, the code will work with or without that patch. For older kernels it makes no difference too, since the version check will prevent new code from being used. So the userspace change is just useless, but it isn't wrong. It merely adds bloat and confusion, but not make the code misbehave. So we may just let it be there, especially since upstream really wants it to be there (Ian says it is for documentation purposes). I never said the code is wrong, but I really wanted to check with Ian before going further. This issue took quite some discusion and time already, so I decided to at least understand the final intentions. > Unfortunately this is a bit beyond my competency so I hope you have some > ideas. And there's no need to do that, really. I'm checking the package now, it all appears to be quite good (as I already mentioned initially). I'm verifying now whenever the transition works correctly. Did you test this place? Is it possible to downgrade back to current version (and name) of the package? Thank you! /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#671701: RFS: autofs/5.0.6-1 [ITA] -- kernel-based automounter for Linux
On 09.05.2012 22:42, Michael Tokarev wrote: [] > I'm checking the package now, it all appears to be quite good (as I > already mentioned initially). > > I'm verifying now whenever the transition works correctly. Did you test > this place? Is it possible to downgrade back to current version (and > name) of the package? It all appears to work fine, as far as I can see. So I uploaded the thing. It needs a bit more of work still. For example, the already mentioned kernel version check (should be in upstream git soon if not already). The Recommends: module-init-tools is wrong, it should be kmod | m-i-t nowadays (m-i-t is a transitional package). I'm not really sure this should be Recommends (see #416597 for initial reason) -- the initscript uses modprobe and lsmod unconditionally and produces quite bad output if m-i-t | kmod isn't installed, so I guess the initscript should be fixed somehow. I'll see if it is possible to let the kernel to autoload the module automatically when mounting autofs filesystem, so maybe whole thing isn't really needed. But overall, the package looks good, and we'll still have the opportunity to fix remaining stuff ;) Thank you all for the good work! /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#671646: qemu-kvm: [PATCH] better parse usb alt_interfaces
On 05.05.2012 19:07, David Fries wrote: > Package: qemu-kvm > Version: 1.0+dfsg-12 > Severity: normal > Tags: patch > > Dear Maintainer, > > qemu-kvm stops parsing the USB descriptor table when it sees an > alternative interface entry that doesn't match the currently set guest > request preventing the guest from communicating to any device > using an alternative interface other than zero. More details in the > quilt patch header. You're attaching an upstream commit 96dd9aac37d30f3425088f81523942e67b2d03ac from Gerd Hoffmann which rewrites usb_linux_update_endp_table function. It has been included into current qemu git tree, and will be in the next qemu release, 1.1, which is about to be out. So I'll hold it for the time being, it will be fixed in the next release. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#672458: installation-reports: IPv6 privacy extensions should be enabled by default
On 11.05.2012 12:32, a debian user wrote: > Package: installation-reports > Severity: wishlist > > Dear Maintainer, > > I know that I can enable the IPv6 privacy extensions after the installation of > debian. > > But I think it is important that I can enable the IPv6 privacy extensions for > the installation in the debian installer. > > The problem is that debian sends my unique MAC-dress to some servers during > and after > the installation of debian if the privacy extensions are disabled. Which problem is that, specially? Sigh, with this From address it is unlikely we'll have any answer.. /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#672520: syslinux-common: spins on boot, never shows the boot menu
On 11.05.2012 22:19, Julien Cristau wrote: > Package: syslinux-common > Version: 2:4.05+dfsg-3 > Severity: grave > Tags: d-i > Justification: renders package unusable > > Steps to reproduce: > - in a d-i checkout, run "make -C build build_netboot" > - boot the resulting build/dest/netboot/mini.iso > > With 2:4.05+dfsg-2 I get the expected boot menu. With -3 nothing > happens, with the CPU apparently spinning without making progress. This > badly affects the d-i dailies. This happens when syslinux is compiled using gcc-4.7. The same code compiled using 4.6 works fine. 4.7 produces non-working pxelinux and regular ldlinux. When pxelinux.0 is run inside qemu-kvm virtual machine, i see the following: ... !PXE entry point found (we hope) at 9BE2:0456 via plan A UNDI code segment at 9BE2 len 08A8 UNDI data segment at 9C6D len 2D28 Getting cached packet 01 02 03 My IP address seems to be C0A8583C 192.168.88.60 ip=192.168.88.60:192.168.88.4:192.168.88.4:255.255.255.0 BOOTIF=01-52-54-00-12-34-56 SYSUUID=---- TFTP prefix: Trying to load: pxelinux.cfg/defaultok _ And the machine stays at this place eating 100% CPU - most of the time. Sometimes qemu-kvm produces the following: KVM internal error. Suberror: 1 emulation failure EAX=00016b40 EBX=00016b40 ECX= EDX=00016b30 ESI=00015e30 EDI=00016b40 EBP=c006fd4c ESP=0002 EIP=0008 EFL=0007 [-PC] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =9c6d 0009c6d0 00809300 CS = 00809b00 SS =9c6d 0009c6d0 00809300 DS =9c6d 0009c6d0 00809300 FS =9c6d 0009c6d0 00809300 GS =9c6d 0009c6d0 00809300 LDT= TR =0008 0580 0067 8b00 GDT= 0009c730 0037 IDT= CR0=0010 CR2= CR3= CR4= DR0= DR1= DR2= DR3= DR6=0ff0 DR7=0400 EFER= Code=00 00 00 00 00 00 00 00 ff ff 80 00 00 00 00 02 00 00 00 51 c2 16 00 00 00 00 00 00 00 00 40 00 00 00 00 02 00 00 00 42 bf 16 00 00 00 00 00 f0 90 FWIW. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#664088: mdadm fails to initialize components for bitmap
12.05.2012 16:46, ka...@karme.de wrote: [] > finally got around to do some more testing > looks like it depends on the metadata version in use > using metadata 1.2 adding a bitmap to a raid created without bitmap > doesn't work: Yes it is about version 1 metadata. This bug should be fixed in mdadm currently in unstable, version 3.2.4-1. Can you verify it works for you correctly please? I closed this bug but maybe we have some more issues there? Thank you! /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#670993: busybox: Please use dpkg-buildflags for hardening support
On 14.05.2012 23:13, Jonathan Nieder wrote: > Michael Tokarev wrote: > >> That's the constructs like this: >> >> bb_error_msg_and_die(bb_msg_memory_exhausted); >> >> where bb_msg_memory_exhausted is declared as extern char *. >> This is a poor-man implementation of internal constant >> string folding done by gcc for years. > > How about this patch? It fixes a few bugs, if I understand correctly > (for example, "stat -Z " passes that string > to vasprintf, allowing privilege escalation if a privileged script > uses a user-specified string in that argument). I fear it would > increase the text size, though. > > A better patch might involve introducing a separate > > bb_error_msgf > > function for callers that want to pass a format and letting > bb_error_msg take a simple string, or turning bb_msg_memory_exhausted > et al into string literals as you suggested. I'm not upstream, but I still don't think this is a right approach. Almost all uses of bb_error_msg and friends are supposed to use static/constant strings, and introducing additional "%s" is just unnecessary. If I were upstream I'd reject this approach. But if you think it is okay, please ask upstream about this approach -- I definitely don't want to carry such a patch in Debian. The stat -Z case is a real bug however, and should be fixed spearately. But this is - IMHO - a different story. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#673043: new ifupdown does not understand comments in interfaces, breaking existing setups
Package: ifupdown Version: 0.7~rc3 Severity: serious The new ifupdown package does not recognize comments in middle of lines in /etc/network/interfaces anymore. For example, I have the following on one of our hosts: iface eth0 inet static address 192.168.177.7 netmask 255.255.255.192 # /26, 0..63 gateway 192.168.177.5 And now, ifup -v eth0 gives the following: ip addr add 192.168.177.7/255.255.255.192 # /26, 0..63 broadcast + dev eth0 label eth0 Not enough information: "dev" argument is required. Which results in no network. This setup has been working for many years and such comments are used heavily here, describing many options, and now it does not work anymore. So I've choosen severity "serious", I think it should be fixed before wheezy (preferrable), or, failing that, some automatic conversion/upgrade procedure must be run to make network/interfaces compatible with the new way of things. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#673043: new ifupdown does not understand comments in interfaces, breaking existing setups
On 15.05.2012 21:20, Michael Tokarev wrote: > > iface eth0 inet static > address 192.168.177.7 > netmask 255.255.255.192 # /26, 0..63 Interesting. The manpage actually says that in-line coments are NOT supported, but I've never actually noticed this till today. It has always worked, and I guess it was more by incident not by design. But I'd say it is a wrong design, since using comments like this is very handy and natural thing to do, too. Pity... :( /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#673043: new ifupdown does not understand comments in interfaces, breaking existing setups
On 15.05.2012 21:32, Andrew Shadura wrote: > Hello, > > On Tue, 15 May 2012 21:26:17 +0400 > Michael Tokarev wrote: > >> Interesting. The manpage actually says that in-line coments are >> NOT supported, but I've never actually noticed this till today. >> It has always worked, and I guess it was more by incident not by >> design. But I'd say it is a wrong design, since using comments >> like this is very handy and natural thing to do, too. Pity... :( > > I don't know, they could be a good idea but I'm afraid their > introduction can possibly break something now. Introduction? Please fix the manpage instead, to document actual behavour. It's always worked so far, it is the new version which broke it, despite the words in the manpage... Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#673043: new ifupdown does not understand comments in interfaces, breaking existing setups
Ok, a few more words about the situation. Indeed, the in-line comments has never been actually supported. They were supported indirectly, by shell which is used to run all commands generated from various pieces of interface definition. What changed in latest version is the way how resulted command is generated. In particular, the argument of "route" parameter has been used last in the resulting command, now it is somewhere in the middle (when using "ip" command), so the resulting line becomes incomplete. Apparently this is one of very few cases were in-line comments actually were supported (indirectly) but now are not anymore, due to different usage of arguments. So the "bug" isn't as catastrophic as I first thought, and in other parts of /etc/network/interfaces (eg, up|down lines) it is still supported, the same indirect way. So my suggestion - either actually do nothing on upgrade, in a hope that everyone reads the fine manuals (not like me :) and hence don't use inline comments in interfaces file at all, or check if "netmask" parameter contains "#" character and just warn about it in postinst. It might be okay to try to automatically fix the problem, but I think it is not really necessary. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#673104: mdadm-3.2.4 can not add members to an array (regression), expected to be fixed in 3.2.5
Package: mdadm Version: 3.2.4-1 Severity: serious Tags: upstream patch http://neil.brown.name/git?p=mdadm;h=d9751e06a601b5576b1b9e2c8126584083110ca5 http://thread.gmane.org/gmane.linux.raid/38356 There are a few other problems in 3.2.4 (not regressions) which should be fixed in 3.2.5. This bug is here to prevent 3.2.4 from entering testing. /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#673174: debsums does not understand multiarch packages
Package: debsums Version: 2.0.51 Severity: normal When debsums is installed, reportbug calls it for any package it is called for. But if there's a multiarch library in this list, reportbug will fail: $ reportbug libopenal1 Getting status for libopenal1... Verifying package integrity... There may be a problem with your installation of libopenal1; the following problems were detected by debsums: debsums: package libopenal1 is not installed Do you still want to file a report [y|N|q|?]? This is because there's no /var/lib/dpkg/info/libopenal1.list, the file list is in /var/lib/dpkg/info/libopenal1:i386.list (in my case anyway). I'm not sure if this is reportbug issue or debsums issue, but I'd say debsums should definitely understand "arch-less-named" multiarch-enabled packages, using default dpkg architecture perhaps, so that it will be possible to use more natural debsums -c libopenal1 instead of debsums -c libopenal1:i386 Thanks, /mjt -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (x86_64) Kernel: Linux 3.0.0-amd64 (SMP w/2 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages debsums depends on: ii debconf [debconf-2.0] 1.5.42 ii libdpkg-perl 1.16.3 ii libfile-fnmatch-perl 0.02-1+b2 ii perl 5.14.2-9 ii ucf3.0025+nmu3 debsums recommends no packages. debsums suggests no packages. -- debconf information excluded -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#667604: Low network speed with -vnc option
On 05.04.2012 18:24, Svante Signell wrote: [] > Thank you for a prompt feedback. Network speed is now 1.7 Mbps (not as > large as 2.6 Mbps but much better than 0.3 Mbps) but I'm testing this > remotely. Have to have physical access to the host to find out the real Did you have a chance to test actual speed with the patch applied? I want some confirmation - if the patch causes speed to decrease from 2.6Mbps to 1.7Mbps that's not good at all. > speed. You can close this bug now. Thanks again. The bug will be closed when the fixed versions will be uploaded. Thank you for the testing! /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#668522: spice-vdagent package lacks (long) description
Package: spice-vdagent Version: 0.10.1-1 Severity: normal The spice-vdagent package provides only the short one-line desrciption, but lacks the extended/long multi-line description text. This basically means it is impossible to understand what this package is for or what it is doing. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#668537: please provide xspice package
Source: xserver-xorg-video-qxl Version: 0.0.17-1 Severity: wishlist Since 0.0.16 version, xspice bits has been merged into x86-video-qxl source tarball, built with --enable-xspice configure flag. Please provide either a separate package, say, xserver-xorg-xspice, or enable xspice in the same xserver-xorg-video-qxl package. Note: README.xpsice in x86-video-qxl-0.0.17.tar.gz still refers to external xspice git repository, -- this is an error just in the README.xspice file. Actual build is done just by adding --enable-xspice configure flag, with appropriate dependencies (libspice-server). Thank you! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#666950: postfix-sqlite is missing, and main postfix package now links with libpq5
On 12.04.2012 18:51, Debian Bug Tracking System wrote: >[LaMont Jones] >* Link with and use sqlite when building dict_sqlite. add sqlite > dictionary to dynamicmaps.cf. Closes: #666950 Hmm. This is not what the bug is about, isn't it? Quoting my bugreport again: > New postfix release (2.9) includes new map type sqlite, in > /usr/lib/postfix/dict_sqlite.so. As done with other optional > maps, this should go into a separate package. This is related > to #93 -- build deps are okay already, but not compile > flags (CCARGS&Co). Shouldn't we introduce postfix-sqlite package, as done for all other map types with external dependencies (unlike those like regexp provided by glibc), instead of shipping dict_sqlite.so in the main postfix package? I think this bug should be reopened, but before doing so I want to hear the reasoning about why postfix-sqlite subpackage has not been introduced. Thank you! /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#666950: postfix-sqlite is missing, and main postfix package now links with libpq5
reopen 666950
severity wishlist
tags 666950 + patch
retitle 666950 sqlite support should be in separate package, not in main
postfix package
thanks
On 12.04.2012 20:22, Michael Tokarev wrote:
> On 12.04.2012 18:51, Debian Bug Tracking System wrote:
>>[LaMont Jones]
>>* Link with and use sqlite when building dict_sqlite. add sqlite
>> dictionary to dynamicmaps.cf. Closes: #666950
>
> Hmm. This is not what the bug is about, isn't it? Quoting my bugreport
> again:
>
>> New postfix release (2.9) includes new map type sqlite, in
>> /usr/lib/postfix/dict_sqlite.so. As done with other optional
>> maps, this should go into a separate package. This is related
>> to #93 -- build deps are okay already, but not compile
>> flags (CCARGS&Co).
>
> Shouldn't we introduce postfix-sqlite package, as done for all
> other map types with external dependencies (unlike those like
> regexp provided by glibc), instead of shipping dict_sqlite.so
> in the main postfix package?
>
> I think this bug should be reopened, but before doing so I want
> to hear the reasoning about why postfix-sqlite subpackage has
> not been introduced.
Ok, the reasoning is that libsqlite3-0 package is "almost"
essential, that is, it gets used by tools usually installed
on a system, f.e. python-twisted, or aptitude.
But I found that out of 200+ servers in use here, only
one has this library installed, and that's only due to
python-twisted which is a dependency of pyicqt which we
run on this one server. All the rest run postfix and
don't have it installed.
Another argument was that libsqlite is small compared
with other map types which are made separate. This
goes in contrast with cdb support which is smallest
of all them, yet is a separate postfix-cdb package.
So "small size" (which isn't exactly small, the library
is about 700kb on i386) is not an argument either.
I'm providing a patch which splits dict_sqlite into a
separate postfix-sqlite package, against current
version of postfix package, 2.9.1-3. The support
files are based on those from pgsql map. I verified
that the new packages are installable correctly.
Thanks!
/mjt
diff --git a/debian/control b/debian/control
index fcffbba..4b61ea6 100644
--- a/debian/control
+++ b/debian/control
@@ -64,6 +64,15 @@ Description: PostgreSQL map support for Postfix
This provides support for PostgreSQL maps in Postfix. If you plan to use
PostgreSQL maps with Postfix, you need this.
+Package: postfix-sqlite
+Architecture: any
+Depends: ${shlibs:Depends}, ${misc:Depends}, postfix (= ${binary:Version})
+Description: SQLite map support for Postfix
+ ${Description}
+ .
+ This provides support for SQLite maps in Postfix. If you plan to use
+ SQLite maps with Postfix, you need this.
+
Package: postfix-dev
Architecture: all
Section: devel
diff --git a/debian/postfix-sqlite.README.Debian b/debian/postfix-sqlite.README.Debian
new file mode 100644
index 000..e57593d
--- /dev/null
+++ b/debian/postfix-sqlite.README.Debian
@@ -0,0 +1,2 @@
+The postfix-doc package contains documentation on how to configure this
+map type. See /usr/share/doc/postfix/html/SQLITE_README.html
diff --git a/debian/postfix-sqlite.copyright b/debian/postfix-sqlite.copyright
new file mode 100644
index 000..8c8014e
--- /dev/null
+++ b/debian/postfix-sqlite.copyright
@@ -0,0 +1,318 @@
+This is the Debian GNU/Linux prepackaged version of Postfix, a mail transport
+agent.
+
+Postfix was created by Wietse Venema ; the Debian
+package has been assembled by LaMont Jones from sources
+available from http://www.postfix.org, and can be cloned from git via:
+ git clone git://git.debian.org/~lamont/postfix.git
+
+
+Copyright (c) 1999, International Business Machines Corporation
+and others. All Rights Reserved.
+
+The following copyright and license applies to this software:
+
+IBM PUBLIC LICENSE VERSION 1.0 - SECURE MAILER
+
+THE ACCOMPANYING PROGRAM IS PROVIDED UNDER THE TERMS OF THIS IBM PUBLIC
+LICENSE ("AGREEMENT"). ANY USE, REPRODUCTION OR DISTRIBUTION OF THE
+PROGRAM CONSTITUTES RECIPIENT'S ACCEPTANCE OF THIS AGREEMENT.
+
+1. DEFINITIONS
+
+"Contribution" means:
+ a) in the case of International Business Machines Corporation ("IBM"),
+ the Original Program, and
+ b) in the case of each Contributor,
+ i) changes to the Program, and
+ ii) additions to the Program;
+ where such changes and/or additions to the Program originate
+ from and are distributed by that particular Contributor.
+ A Contribution 'originates' from a Contributor if it was added
+ to the Program by such Contributor itself or anyone acting on
+ such Contributor's behalf.
+ Contributions do not include additions to the Program which:
+ (i) are separate modules of sof
Bug#668034: mdadm: Typo in 4b. Can a 4-disk RAID10 survive two disk failures?
tags 668034 + squeeze thanks On 08.04.2012 16:42, Olaf van der Spek wrote: > Package: mdadm > Version: 3.1.4-1+8efb9d1+squeeze1 > Severity: wishlist > > Hi, > > FAQ.gz: > In two thirds of the cases, yes[0], and it does not matter which layout you > use. When you assemble 4 disks into a RAID10, you essentially stripe a RAID0 > across two RAID1, so the four disks A,B,C,D become two pairs: A,B and C,D. > If A fails, the RAID6 can only survive if the second failing disk is either > C or D; If B fails, your array is dead. > > RAID6 should be RAID10 in the second to last line. This has been fixed for wheezy, see #637068. /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#668035: mdadm: Default to mailing root
tags 668035 + moreinfo thanks On 08.04.2012 16:54, Olaf van der Spek wrote: > Package: mdadm > Version: 3.1.4-1+8efb9d1+squeeze1 > Severity: wishlist > > Hi, > > Just got this mail: > /etc/cron.daily/mdadm: > mdadm: No mail address or alert command - not monitoring. > run-parts: /etc/cron.daily/mdadm exited with return code 1 > > Can't you default to mailing root or just using syslog? How did you generate /etc/mdadm/mdadm.conf ? The mdadm postinst script creates this file which includes MAILADDR statement, and the question about mail address is asked using debconf. Thank you! /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#668035: mdadm: Default to mailing root
On 12.04.2012 23:02, Olaf van der Spek wrote: > On 12-4-2012 20:59, Michael Tokarev wrote: >>> Can't you default to mailing root or just using syslog? >> >> How did you generate /etc/mdadm/mdadm.conf ? The mdadm >> postinst script creates this file which includes MAILADDR >> statement, and the question about mail address is asked >> using debconf. > > I don't know, it's a dedicated server from http://www.hetzner.de/en/ Well, this does not help much. Anyway, I think the current behavour is right. Mdadm package installation procedure ensures that some email address gets configured in mdadm.conf (there's a debconf question about it and the address defaults to root). It is possible to remove the configuration item, but that's entirely up to the user ofcourse. Do you agree it's okay to close this bug? Thank you! /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#668035: mdadm: Default to mailing root
On 12.04.2012 23:20, Olaf van der Spek wrote: >> Anyway, I think the current behavour is right. > > Why? > Can't you default to mailing root or just using syslog? It _is_ the current situation already - to mail to root. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#658701: mdadm: should send email if mismatches are reported by a check
Neil, re http://bugs.debian.org/658701 , how do you think, is it okay if mdadm --monitor will send email in case check found mismatches, the same way it sends email about other more critical errors? I think Russell has a good point here, but there's one more source of mismatches we have in kernel - some "sporadic" mismatches in raid1 and raid10, especially when these are used as swap space... In Debian we've several bugreports already requesting more attention to mismatch_cnt, see: http://bugs.debian.org/658701 (this one) http://bugs.debian.org/599821 http://bugs.debian.org/588516 Thank you! /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#664088: mdadm fails to initialize components for bitmap
On 31.03.2012 01:28, Markus Hochholdinger wrote: > Package: mdadm > Version: 3.2.3-2 > Followup-For: Bug #664088 > > Dear Maintainer, > > seems I've been stumbled over this bug. I'm running wheezy and can reproduce > a crash: > mdadm --grow /dev/md0 --bitmap=none > mdadm --grow /dev/md0 --bitmap=internal > > A few seconds after this, the system is still alive, I see the newly created > bitmap in /proc/mdstat, and then the system crashes: > [ 342.437949] md0: bitmap file is out of date (0 < 322) -- forcing full > recovery > [ 342.437967] created bitmap (1 pages) for device md0 > [ 347.949946] BUG: unable to handle kernel NULL pointer dereference at > 0008 > [ 347.949969] IP: [] bitmap_endwrite+0x138/0x199 [md_mod] > [ 347.949991] *pdpt = 02660007 *pde = > [ 347.950010] Oops: [#1] SMP Oh. This is a kernel bug, kernel should not crash like this even if incorrect bitmap is created. Marcus, what's your kernel version? Thank you! /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#668035: mdadm: Default to mailing root
On 12.04.2012 23:33, Olaf van der Spek wrote: > On 12-4-2012 21:29, Michael Tokarev wrote: >> On 12.04.2012 23:20, Olaf van der Spek wrote: >> >>>> Anyway, I think the current behavour is right. >>> >>> Why? >>> Can't you default to mailing root or just using syslog? >> >> It _is_ the current situation already - to mail to root. > > Then it shouldn't be complaining about a missing MAILADDR line, should it? I don't see why not. If you modified debian-generated config file and removed the setting, it will complain, exactly as in this bugreport. My point is that when the package gets installed, it creates the right config file with proper email address, and I said exactly this several times already. I don't really want to change default in the source, this adds unnecessary changes from upstream which trivially can be, and _are_ already handled in the config file. What I don't understand? Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#664088: mdadm fails to initialize components for bitmap
On 13.04.2012 00:22, Markus Hochholdinger wrote: > Hello Michael, > > Am 12.04.2012 um 21:38 Uhr schrieb Michael Tokarev : >> On 31.03.2012 01:28, Markus Hochholdinger wrote: >>> Package: mdadm >>> Version: 3.2.3-2 >>> Followup-For: Bug #664088 >>> Dear Maintainer, >>> seems I've been stumbled over this bug. I'm running wheezy and can >>> reproduce a crash: mdadm --grow /dev/md0 --bitmap=none >>> mdadm --grow /dev/md0 --bitmap=internal >>> A few seconds after this, the system is still alive, I see the newly >>> created bitmap in /proc/mdstat, and then the system crashes: [ >>> 342.437949] md0: bitmap file is out of date (0 < 322) -- forcing full >>> recovery [ 342.437967] created bitmap (1 pages) for device md0 >>> [ 347.949946] BUG: unable to handle kernel NULL pointer dereference at >>> 0008 [ 347.949969] IP: [] bitmap_endwrite+0x138/0x199 >>> [md_mod] [ 347.949991] *pdpt = 02660007 *pde = >>> [ 347.950010] Oops: [#1] SMP >> Oh. This is a kernel bug, kernel should not crash like this even if >> incorrect bitmap is created. >> Marcus, what's your kernel version? > > Linux 3.2.0-2-686-pae from wheezy. This was obvious from your initial message, but I wasn't clear. I meant to ask what kernel PACKAGE version is that. Sigh, how many times I suggested kernel folks to include debian package version in the kernel OOPs test, but has been ignored every time... :( > Hm, perhaps I could use mdadm from squeeze to check weather the kernel also > crashes. I doubt it is easily reproducible. The original bug in mdadm (which is fixed upstream btw, in git, not any released version) does not initialize bitmap, leaving some garbage in it. Obviously not every garbage triggers the bug in kernel. So if another attempt will not crash your kernel it does not tell anything. I asked for the kernel package version in order to clone and reassign this bugreport to kernel properly. Thanks! /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#653473: qemu-kvm: 1.0 breaks openbsd, netbsd, freebsd, scsi
tags 653473 - moreinfo + confirmed upstream severity 653473 important thanks Replying to an old bugreport, see http://bugs.debian.org/653473 for full prior history. This topic popped up again today, I did another bisection of a netbsd networking problem, and discovered that: a) I can reproduce these issues (with netbsd at least) now on my machine, so I can bisect them; b) the patch I mentioned previously -- http://thread.gmane.org/gmane.comp.emulators.qemu/130695 -- hasn't found its way into any qemu tree, neither stable 1.0.1 nor master git branch. c) the patch mentioned in that thread actually fixes the issues with both netbsd and openbsd, mentioned in this bugreport. So.. hum. I mark this bug as important, since these are really important guests to support. Waiting for the upstream to shed some light as of why it hasnt been applied. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#668594: qemu-kvm: Suboptimal virtio/vhost-net performance on Debian KVM hosts compared to others
On 13.04.2012 13:46, Hans-Kristian Bakke wrote: > Package: qemu-kvm > Version: 1.0+dfsg-9 > Severity: normal > > I cannot get optimal network througput on KVM guest using Debian Wheezy (and > stable) as KVM host. > It is not horribly bad, just not good compared to relevant alternatives. > > I have tried Ubuntu Server 11.10, Proxmox 1.9, Proxmox 2.0 and Fedora 17 > Alpha as 1:1 replacement for the Debian KVM host using the same guests (just > preserving the LVM volumes between installs) and they all manage about 20 > gbit/s guest to guest using a simple iperf test, while Debian only manages > about 2.3 gbit/s with high CPU usage. The CPU usage is generally much higher > on all guest network activity on Debian and are in some cases not able to > even saturate a gigabit link (when coming from other subnet) without maxing a > CPU core where the other KVM hosts barely breaks a sweat. > > Disc IO is very good and the guests feels snappy so it doesn't seem like > there is something really wrong, just something suboptimal with the > networking. > The issue follows only the host OS as the guests have been the same in all > comparisons (Debian Wheezy) > > > To reproduce: > > Install Debian Wheezy in guests (minimal with SSH and ntp) > Install iperf via apt-get > Configure network > > Run test: > guest1: iperf -s > guest2: iperf -c -i 2 -t 3 > > My results: > > - Guest to guest performance via local bridge: ~2.3 gbit/s, very high CPU > usage on vhost-$PID and kvm process on host > - Physical server to guest on same subnet: ~940 mbit/s but with very high CPU > usage on vhost-$PID and kvm process on host > - Physical server to guest via router: ~850 mbit/s with very high CPU usage > on vhost-$PID and kvm process on host (why is routed traffic slower than > switched on the guest??) > - Physical server to kvm host via router (just to verify that the router is > not the issue): ~940 mbit/s with almost no CPU usage > > Expected results after comparison with other KVM hosts everything else the > same: > - > - Guest to guest performance via local bridge: ~20 gbit/s, high CPU usage > - Physical server to guest on same subnet: ~940 mbit/s with low CPU usage on > vhost-$PID and a bit higher on kvm process on host > - Physical server to guest via router: ~940 mbit/s with low CPU usage on > vhost-$PID and a bit higher on kvm process on host > - Physical server to kvm host via router (just to verify that the router is > not the issue): ~940 mbit/s with almost no CPU usage (the same as my current > results) > > Compare results with other OSes on same machine (guest to guest via bridge): > Ubuntu Server 11.10 (virtualization host): ~19 gbit > Proxmox VE 2.0: ~20 gbit/s > Fedora 17 alpha: ~20 gbit/s Which versions of qemu[-kvm] are used on these? Did you try older versions of qemu-kvm from snapshot.debian.org? It really looks like qemu-kvm-specific, not kernel-specific, and qemu-kvm in Debian is very close to upstream 1.0.1 version, so I'm not sure where to look at. I've another bugreport at hand claiming that vhost-net, but this time with macvtap not bridge, has a speed regression between 1.0+dfsg-8 and 1.0+dfsg-9 (bridge mode unaffected). 1.0+dfsg-9 is the (debian) revision where I added a 1.0.1 diff (I didn't re-upload the new source). Maybe this is related somehow - please try -8 release too, for comparison. Unfortunately I can't help here at all, as I don't reach any speeds comparable with what you have, and mine don't change much. But I haven't tried installing any other OS (from a list you mentioned too), -- I don't like to repartition my only hdd to do so. > I have tried: > > - Replacing Debian Wheezy with Debian Squeeze (stable, kernel 2.6.32-xx) - > even worse results This kernel does not support vhost-net, it was 2.6.35 or .38 addition. > - Replacing kernel 3.2.0-2-amd64 with vanilla kernel 3.4-rc2 and config based > on Debians included config - no apparent change > - Extracted the kernel-config file from Fedora 17 alphas kernel and used this > to compile a new kernel based on Debian Wheezys kernel source - slightly > worse > > results > - Installing Proxmox VE 2.0 kernel in Debian. Results are the same > - ...in addition to exchanging Debian with Ubuntu Server 11.10, Fedora 17 > alpha, Proxmox 1.9 and 2.0 and ESXi 5 which all have expected network > performance using virtio. > > > Please optimize KVM/vhost in Debian so it performs like the other > alternatives. With pleasure, but I need some help ;) Thank you! /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#646249: qemu-kvm: vm not reachable
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=646249) This might also be related to this kernel bug: https://bugzilla.kernel.org/show_bug.cgi?id=42829 Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#640139: Won't start when using spice
Upstream committed two patches which should fix this issue. Two commits: http://git.qemu.org/?p=qemu.git;a=commit;h=a13ccc991a852cf12f2c05f537c40ce239ae464f Author: Alon Levy Date: Wed Mar 21 18:17:18 2012 +0200 ui/spice-display: use uintptr_t when casting qxl physical addresses http://git.qemu.org/?p=qemu.git;a=commit;h=34d14c6d8c7af0d2457cf5730fe5a65a878c509d Author: Peter Maydell Date: Wed Mar 7 13:36:48 2012 + ui/spice-display.c: Fix compilation warnings on 32 bit hosts Takes care of this. Apparently 0.10 version of spice-server actually fixed 32bit issues too. I'm verifying it all now, and will include the fixes into the next release if it works. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#652326: libspice-server errors out on startup on 32bit
retitle 652326 libspice-server does not work on i386 (32bit) severity 652326 important thanks Apparently the next version of spice will actually work in i386. This is JFYI, and actually I don't have more details on this, just, well, rumors. The "errors out on startup" bit was due to spice-related bugs in qemu, not spice itself. Retitling as such, and fixing severity. I wasn't able to apply the qemu-side fixes to 1.0 version easily, will try to do something with this for the next release of spice. Thank you! /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#668594:
On 15.04.2012 13:51, Hans-Kristian Bakke wrote: > Per you request I downloaded qemu-kvm_1.0+dfsg-8_amd64.deb from > snapshot.debian.org and lo and behold: 19.1 gbit/s! Thank you very much for testing this! > In other words there is a massive network efficiency regression > between -8 and -9. Even though there are no network related changes > between the versions I noticed that I had to change machine=pc-15 to > pc-14 in my .xml-files for -8 to start the machines. > Is there some significant internal changes in kvm going on between 8 > and 9 perhaps (enough to increase the pc-number)? pc-15 has been forgotten since qemu version 0.15, the 0.15 machine definition has been added only in 1.0.1 version, 1.0 didn't recognize it. There hasn't been any significant changes in between. As for the network-related issues, indeed, this is something which is quite unexpected. I browsed all changes between 1.0 and 1.0.1, but I don't see a single change which may have this effect... I'll dig further into this in a few next days, but since I can't reproduce this I may need more of your help... Can I rely on a bit more of your testing please? > Thank you for your help! > > This issue obviously have to be solved for future updates. Yes, definitely. Besides, are you sure you're using bridge networking, not macvtap networking? Thank you! /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#668594: testing
On 16.04.2012 00:41, Hans-Kristian Bakke wrote: >> As for the network-related issues, indeed, this is something which >> is quite unexpected. I browsed all changes between 1.0 and 1.0.1, >> but I don't see a single change which may have this effect... > > I am no dev but I would guess that several gbit/s of TCP-traffic may > trigger any regressions in other parts of the KVM subsystems too, so > perhaps it isn't directly linked to the networking? I built 4 executables on current wheezy/amd64, available at http://www.corpit.ru/mjt/tmp/kvm1.0-network-speed-tests.tar.gz (and signed with my Debian gpg key, in http://www.corpit.ru/mjt/tmp/kvm1.0-network-speed-tests.tar.gz.asc -- the same key I use to sign my regular uploads to Debian archive, it should be in your apt keyring). These files are, obviously, temorary.. ;) The tarball contains the following files: kvm1.0 kvm1.0+2061800b85ddcc9b34b5ccbfaa87f7e8b94626a6 kvm1.0+a25808dc5baee83f36e0cdab998eb6c0024156fa+7e2191ae9898cc957a3d1991aff0e40f2e0f44a4 kvm1.0+fe5c13ebf1161d0f324229cfb36cb5fb87ec6248 These are /usr/bin/kvm binaries. So you extract these to some temp place and run your guest(s) using one of the 4 binaries instead of /usr/bin/kvm. kvm1.0 should be fast, the same as 1.0+dfsg-8 (I need a verification of this, too, as a starting point). The other 3 are 3 possible -- very remotely but still -- changes from between 1.0-8 and 1.0-9 which may show the bad speed. The long hex numbers are GIT commit IDs, which can be looked at git.qemu.org, like this http://git.qemu.org/?p=qemu.git;a=commit;h=COMMITID f.e. for the first one above: http://git.qemu.org/?p=qemu.git;a=commit;h=2061800b85ddcc9b34b5ccbfaa87f7e8b94626a6 (the pre-last is actually 2 but related commits). Please test them and see if the speed drops with any of them. As I already pointed out, all changes appears to be unrelated to networking, so these are wery wild guesses only, and neither may show our bad behavour. And especially if first, simple, kvm1.0 variant _does_ show the bad speed already, there's no need to try others, since the prob might be somewhere else entirely: this binary is equivalent to what was in 1.0-8 but rebuilt using current toolchain from wheezy. Thank you very much! /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#668594:
On 16.04.2012 10:25, Hans-Kristian Bakke wrote: >> And especially if first, simple, kvm1.0 variant >> _does_ show the bad speed already, there's no need >> to try others, since the prob might be somewhere >> else entirely: this binary is equivalent to what >> was in 1.0-8 but rebuilt using current toolchain >> from wheezy. > > Interesting. I tried your binaries now and the first "kvm1.0" binary > you provided me _does_ have the bad performance (~2.3 gbit/s). > Returning to the "old" -8 binary gives full performance again. In that case it must be some toolchain issue, not something in qemu-kvm itsel... Sigh, I wish I was able to reproduce it locally... :( Now, the fun task for me is to figure out which versions of gcc/binutils/etc were used to build -8 version :) And this basically means that a backported version of -9 should work fine, since it will use older and proven toolchain. Lemme try... Thank you for the help and support so far! /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#665046: qemu-kvm: bad network performance using vhost and macvtap
On 22.03.2012 19:05, Michael Tokarev wrote: > On 22.03.2012 15:06, Anthony Bourguignon wrote: >> Package: qemu-kvm >> Version: 1.0+dfsg-9 >> Severity: important >> >> Hello, >> >> I encountered an issue with version 1.0+dfsg-9 of qemu-kvm (it worked fine >> with 1.0+dfsg-8). The network performances are really bad when I'm using >> vhost and macvtap (bridge mode). Here is the cmdline launch by libvirt : [] > There was no network-related changes between -8 and -9. > Macvtap performance has always been awful from the ground up, > but this is due to kernel not qemu. Reportedly it become a > bit better with latest kernels but I haven't checked. > At any rate using macvtap isn't a good idea at this stage. Another user encountered a similar issue, but this time, his qemu-kvm is about 10 times slower in bridged mode, and again, 1.0+dfsg-8 works okay for him. I wonder if this is the same issue... It shows differently, but the effect is very similar, and the same version is affected. Here's the other bugreport: http://bugs.debian.org/668594 I'm trying to investigate further... Thank you for your patience, /mjt > /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#673904: 64-bit package reports nonsensical CPU, breaks GMP
tags 673904 + wontfix thanks As I explained several times, this problem must be fixed on both sides - both gmp and qemu, and it is "more correct" to fix it in gmp side. The problem im gmp is that it uses "abort()" statements in cases where it detects "impossible", to its "thinking", CPU. Instead of these aborts(), it should just use whatever default optimization modes it already uses for these "default" cases. Ie, just changing "abort()" into "break" in the mentioned code in gmp is enough to fix it on gmp side. For qemu side, I don't want to make a Debian-specific change for this. If upstream decides to change default CPU type, Debian will inherit that change, and I'll happily backport it to the Debian package if that happens in some later upstream release. This is exactly why I started that discussion on qemu-devel list. So tagging as wontfix for now. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#673904: 64-bit package reports nonsensical CPU, breaks GMP
[] > As I explained several times, this problem must be fixed > on both sides - both gmp and qemu, and it is "more correct" > to fix it in gmp side. The problem im gmp is that it uses > "abort()" statements in cases where it detects "impossible", > to its "thinking", CPU. Instead of these aborts(), it should > just use whatever default optimization modes it already uses > for these "default" cases. Ie, just changing "abort()" into > "break" in the mentioned code in gmp is enough to fix it on > gmp side. > > For qemu side, I don't want to make a Debian-specific change > for this. If upstream decides to change default CPU type, > Debian will inherit that change, and I'll happily backport it > to the Debian package if that happens in some later upstream > release. This is exactly why I started that discussion on > qemu-devel list. One additional note. I think I can manage a patch that will use kvm64 cpu type in case -enable-kvm is specified, and qemu64 if not. It will differ from upstream, which I dislike, but it should fix at least the current issue. ..Which is, indeed, can be trivially fixed "externally" by invoking qemu with the right options, explicitly specifying required CPU type and other machine details. That to say: this bugreport is only about default value of an option (-cpu), which has this value since the day one. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#674410: Bug#674413: Please add vhost-net device to udev rule
merge 674410 674413 tags 674410 + wontfix thanks 24.05.2012 16:52, Wolfram Gloger wrote: > Package: qemu-kvm > Version: 1.0+dfsg-11 > Severity: wishlist > > Please consider the appended patch for the udev rule file, > so that group kvm can use vhost-net. > > Regards, > Wolfram. > > --- debian/qemu-kvm.udev~ 2012-01-19 09:10:34.0 +0100 > +++ debian/qemu-kvm.udev 2012-05-24 14:39:01.0 +0200 > @@ -1 +1 @@ > -KERNEL=="kvm", GROUP="kvm", MODE="0660" > +KERNEL=="kvm|vhost-net", GROUP="kvm", MODE="0660" My opinion is that vhost-net should be in its own group, due to extra possible security implications and because, just like with /dev/kvm, this rules file does not belong to qemu[-kvm] package, since qemu is not only user of these devices. I don't, however, just refuse to fix this bug - I see the need to do something like that, and hopefully will address this in the near future. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#677049: [trivial] please don't hardcode /bin/sleep path
On 11.06.2012 19:45, Julien Cristau wrote: > On Mon, Jun 11, 2012 at 14:21:05 +0400, Michael Tokarev wrote: >> Two scripts in initramfs-tools currently hardcodes path to sleep >> as /bin/sleep, because busybox sleep (which were used when >> busybox is in used) didn't accept fractional secounds. Fractional >> secounds are accepted by busybox sleep since version 1:1.18.5-1, >> so it is safe now to stop hardcoding the path. >> > It's not safe without Breaks on older busybox (or Depends on the newer > one). Yes it's not safe, I know. I tried to understand whenever a versioned Recommends does the trick (there's already a versioned recommends in initramfs-tools against busybox), and, later, what does a versioned recommends _does_, or a Breaks is needed instead. So from a trivial change in one package it turned into a bit less trivial question about the package relationship. /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#677254: busybox: FTBFS[kfreebsd]: error: storage size of 'info' isn't known
tags 677254 + upstream pending forwarded 677254 https://bugs.busybox.net/show_bug.cgi?id=5300 thanks On 12.06.2012 21:19, Samuel Thibault wrote: > Christoph Egger, le Tue 12 Jun 2012 18:19:03 +0200, a écrit : >> Your package failed to build on the kfreebsd-* buildds: >> >> LD procps/built-in.o >> CC procps/kill.o >> CC procps/pidof.o >> CC procps/ps.o >> procps/ps.c: In function 'ps_main': >> procps/ps.c:638:17: error: storage size of 'info' isn't known >> procps/ps.c:698:3: warning: implicit declaration of function 'sysinfo' >> [-Wimplicit-function-declaration] > > (same on hurd-i386) Yes I know. Already patched, verifying... /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#669114: vgabios doesn't have QXGA VBE resolution entries
On 17.04.2012 16:04, Sven Schnelle wrote:
> Package: vgabios
> Version: 0.7a-2
> Severity: wishlist
>
> I'm using kvm + vgabios on a QXGA resolution screen. Unfortunately, it doesn't
> have this resolution in its VBE tables. Here's a patch to add it:
>
> diff -Naur vgabios-0.6c.ori/vbetables-gen.c vgabios-0.6c/vbetables-gen.c
> --- vgabios-0.6c.ori/vbetables-gen.c2012-04-17 11:17:30.129152478 +0200
> +++ vgabios-0.6c/vbetables-gen.c2009-01-25 16:46:08.0 +0100
> @@ -73,9 +73,12 @@
> { 1920, 1200, 16 , 0x187},
> { 1920, 1200, 24 , 0x188},
> { 1920, 1200, 32 , 0x189},
> +{ 2048, 1536, 16,, 0x18a},
> +{ 2048, 1536, 16,, 0x18b},
> +{ 2048, 1536, 16,, 0x18c},
> +{ 2560, 1600, 16 , 0x18d},
> +{ 2560, 1600, 24 , 0x18e},
> +{ 2560, 1600, 32 , 0x18f},
> -{ 2560, 1600, 16 , 0x18a},
> -{ 2560, 1600, 24 , 0x18b},
> -{ 2560, 1600, 32 , 0x18c},
You're changing existing mode IDs this way. Why?
Thanks,
/mjt
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#677528: qemu-kvm: "KVM internal error" for some values of -m
severity 677528 normal tags 677528 + upstream confirmed thanks On 14.06.2012 19:24, Jakub Wilk wrote: > Package: qemu-kvm > Version: 1.1~rc+dfsg-1 > Severity: minor > > $ kvm -m 1.4g > KVM internal error. Suberror: 1 Wow. Just.. wow. I'm raising the severity to normal, it is definitely not a minor thing. [] > This used to work until very recently. Did you _ever_ tried 1.1 version before? > Also, it still works fine with "-m 1400m" or "-m 1.5g". Yes, that works. Thank you for the bugreport! /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#676950: qemu-kvm: Windows XP fails on Bulldozer CPUs
On 15.06.2012 00:10, Gary Dale wrote: > I finally bit the bullet to try a fresh install from the command line. After > much gnashing of teeth, the command line I came up with is: > > virt-install -n ghostwheel --cpu kvm64 -c > "/home/garydale/Downloads/WindowsXPPro64.iso" --os-variant=winxp64 --disk > path=/var/lib/libvirt/images/ghostwheel.img,size=20,format=raw > --controller=sata --ram=1024 --graphics vnc -v virt-install is difficult thing, you can't really control qemu-kvm using it. Also, --controller=sata is unlikely to work with qemu-kvm 1.0. Please try something much simpler. Like this: qemu-img create ghostwheel.img 20G <= this will zero-out the file if it exists. kvm -cdrom WindowsXPPro64.iso -drive file=ghostwheel.img,cache=unsafe -m 1G -cpu qemu64 (it will open an X window with guest console. Ofcourse it needs permissions to access /dev/kvm, but this is trivial to achieve, just add yourself to kvm group). [] > BTW: I also tried to create a fresh virtual machine using virt-manager and > failed. I get "Uncaught error validating install parameters: 'NoneType' > object has no attribute 'set_parent'" when I try to create any Windows XP > virtual machine. This is a bug in virt-manager/libvirt. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#677504: lintian fixes
On 14.06.2012 16:39, Sergey B Kirpichev wrote: [lots of good stuff] Guys. I'm leaving for a 2-week vacation (I had no vacation for 2 years in a row, and can't stand anymore). I'll try to review this stuff while being in a sea beach, maybe will commit something. But to me, much more important issue is the timing issue we have in initramfs. Namely, there are a few known valid setups which does not work with mdadm currently. #675452 and #664581 are two examples of this, arrays will not start if any of the component devices are on USB storage which is slow to initialize, and so on. There are a few possible solutions there, but it is all quite fragile and touching very important area... So, if you do have some time and are willing to help, that's where to look at :) Thank you for your patience and efforts! /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#676950: qemu-kvm: Windows XP fails on Bulldozer CPUs
On 15.06.2012 01:46, Gary Dale wrote: > On 14/06/12 04:26 PM, Michael Tokarev wrote: >> kvm -cdrom WindowsXPPro64.iso -drive file=ghostwheel.img,cache=unsafe -m 1G >> -cpu qemu64 > I get an error about SDL: I told you it will open an X window. Give it a $DISPLAY. /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#676950: [Bulk] Re: Bug#676950: qemu-kvm: Windows XP fails on Bulldozer CPUs
On 15.06.2012 02:11, Gary Dale wrote: [] > It doesn't open an X window. It complains about: > > No protocol specified > Could not initialize SDL(No available video device) - exiting > > Now I seem to have SDL installed. However, searching through the kvm > documentation to find information about SDL is almost as hard as searching > through the SDL documentation... *sigh* Run xterm without qemu-kvm and get it to work. First. Next qemu-kvm will work too. /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#677528: qemu-kvm: "KVM internal error" for some values of -m
forwarded 677528 http://thread.gmane.org/gmane.comp.emulators.kvm.devel/92493 thanks On 15.06.2012 02:41, Jakub Wilk wrote: > * Michael Tokarev , 2012-06-14, 23:25: >>> $ kvm -m 1.4g >>> KVM internal error. Suberror: 1 >> >> Wow. Just.. wow. >> >> I'm raising the severity to normal, it is definitely not a minor thing. >> >> [] >>> This used to work until very recently. >> Did you _ever_ tried 1.1 version before? > > Hmm. Now that I think of it, probably no, not with such options. I bisected the issue, and reported it upstream. It is one particular commit. http://thread.gmane.org/gmane.comp.emulators.kvm.devel/92493 So it is issue new to 1.1. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#677520: Corrected some typos in autofs init file
14.06.2012 17:56, Steve Petruzzello wrote: Package: autofs Version: 5.0.6-2 Severity: wishlist Hi, Here is a patch correcting minor typos in /etc/init.d/autos. Well. these are not typos, these were old attempts to internationalize the messages initscript produces: > - log_action_begin_msg $"Stopping $prog: " > + log_action_begin_msg "Stopping $prog" The construct $"" tells shell to lookup the string in question in a intl. messages database and display localized version if found. The script is almost completely rewritten in the current git version, I plan to upload it soon. http://anonscm.debian.org/gitweb/?p=collab-maint/autofs.git;a=blob;f=debian/autofs.init;hb=HEAD Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#678042: seabios - Please enable Xen support
18.06.2012 23:14, Bastian Blank wrote: Package: seabios Version: 1.7.0-1 Severity: wishlist Please enable Xen support in seabios. It will be used by the next Xen release and maybe the version in Wheezy. Do you know what's the outcome of this? As far as I remember, it is just a config option, but it is not enabled by default, do you know why? Kevin, can you comment please? Thank you! /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#677504: lintian fixes
16.06.2012 13:34, Sergey Kirpichev wrote: On Fri, Jun 15, 2012 at 12:47 AM, Michael Tokarev wrote: I'll try to review this stuff while being in a sea beach, maybe will commit something. Unfortunately I can't do anything from here at all. The wifi in the hotel works, but they've everything filtered out except of outgioing tcp ports 80 and 443, and these have quite short expiration timeout too (about 30 sec). So I can only browse the web, which is not how I can review anything at all :( I'm on a tinc vpn which I've set up to work over tcp port 443, but it reconnects every 30 secs approx, and is very very slow - to d/load the message I'm replying to (about 6Kb) it took about 20 reconnects, and I've no idea how much will it take to send this message. I looked at the patches, it all look quite well, but I can't commit anything from here anyway. Would be nice, if you take look on #556610 too. Yes, but this one is a feature/enhancement. I'm not sure we ever want to go this route -- the result smells too complicated. Well, the sizes of the typical arrays are increasing, and hence the time required to complete the checks, so it becomes more and more important, so we have to do something with that. But to me, much more important issue is the timing issue we have in initramfs. Â Namely, there are a few known valid setups which does not work with mdadm currently. Â #675452 ... So, if you do have some time and are willing to help, that's where to look at :) Comment was added. Yes, I've seen these. But at this point before wheezy release I don't want to enable asyncronous array processing like this. Once we enable that in in the initramfs, we have to enable it in regular userspace too, so that other parts of arrays will be processed later. This has to be supported from initramfs to regular userspace and whole thing has to be switched to asyncronous processing, which needs quite good testing in various usage scenarios out there. For now, the most appropriate course of actions, I think, is to run udevadm settle before mdadm --assemble and, if after --assemble, the root device is not there still, sleep a few seconds and repeat WHOLE series of scripts in initramfs again, up to a configured amount of times. This should already work for cryptoloop which should not ask for a password again if the device is already configured, and this should work for lvm on top of md raid too, with lvm not being asyncronous like md is. This is just an opinion anyway, maybe incremental/asyncronous mode isn't that difficult. Except it does not solve non-incremental lvm anyway. Thanks, /mjt who hopes he'll be able to send this reply out somehow -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#670898: ifrename starts before module-init-tools when no interfaces exists yet
Package: ifrename Version: 30~pre9-8 Severity: normal Package ifrename provides an initscript to rename existing interfaces, so this should work without udev. But it has no dependencies on module-init-tools (or kmod) listed, so insserv sorts it before module-init-tools in rcS.d, and it is the module-init-tools who loads modules, and who may load NIC-related drivers too. The result is that it runs before m-i-t and hence does not see any network interface, so actual renaming is not happening. (Note again: this is the case when no udev is being used). I tried to add "Should-Start: module-init-tools" to it, but that results in ifrename sorted the same as ifupdown, but obviously ifrename should run strictly before ifupdown. So I also added "Should-Start: ifrename" to ifupdown, but that turned into a cyclic dependency somehow. So I ended up calling ifrename explicitly from ifupdown, which is ugly but at least lets the system boot and be accessible over the network. This all is not relevant when udev is used, because ifrename provides necessary udev hooks, and udev is run definitely before ifupdown. But with udev, the ifrename initscript is not needed at all. So we should either fix the initscript, or drop it. I'd vote for the first approach... Thanks! /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#670993: busybox: Please use dpkg-buildflags for hardening support
On 01.05.2012 08:23, Steve Langasek wrote: > +CFLAGS := $(filter-out -Werror=format-security,$(CFLAGS)) Why do you filter this -W option? Also, I'd rather use EXTRA_CFLAGS not CFLAGS alone, or the other way around (allowing EXTRA_CFLAGS), but I'll have to check. Thanks! /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#671131: It seems that memory leak in kvm very seriously
On 02.05.2012 06:28, Cun Zhang wrote: > Subject:It seems that memory leak in kvm with Windows XP guest very seriously > Package: qemu-kvm > Version: 1:1.0+dfsg-11 > Severity: normal > > Dear Maintainer, > > After I upgrade the kernel to 3.2.0, the WinXP guest in the kvm VM > become so slow, and I found memory leak seems happen. When the guest > start, it just need only less then 300M memory. However with serveral > operating to start/close softwares, 2G memory is used out in the > guest. Momery isn't freed when all softwares are closed. Interesting. You say that the problem is related to the kernel upgrade, yet you're filling the bug against qemu-kvm. > I start guest OS with the following commands: > > kvm -m 2048 -smp 2 -soundhw ac97 -hda /media/sda5/WindowsXP.ovl -rtc > base=localtime,clock=host -net nic,vlan=0 -net user,vlan=0 -vga std -vnc > :3 -usbdevice tablet & You assigned 2Gb memory to your guest, and you complain that the guest uses 2Gb memory. I don't see the logic here. Why do you think guest should free memory back to the HOST - if guest has 2Gb at its disposal and don't even KNOW that it is running in some virtual environment? It just uses whatever it "thinks" it physically has, where's the problem? > More information can be provided if you give me several detailed debug > suggestion. Yes please. The main question is: which behavour do you consider a leak, which behavour you expect and why. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#671136: Boot failed: Could not read from CDROM (code 000c) debian guest in KVM VM on debian host
On 02.05.2012 08:33, bug...@i2pmail.org wrote: > Package: kvm > Version: 1:0.12.5+dfsg-5+squeeze8 > > This bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=670997 can also be > about kvm itself (or qemu?) not about cdrom images, so reporting it there. > > Debian stable + backports KVM is unable to boot debian stable 64 bit > netinstall, while working for 32 bit version. > > The errors seen in KVM BIOS is: > Boot failed: Could not read from CDROM (code 000c) > No bootable device. > > Host system information: > > kvm 1:0.12.5+dfsg-5+squeeze8 > qemu 0.12.5+dfsg-3squeeze1 Note these are not from backports. > $ uname -a > Linux fenix 3.2.0-0.bpo.2-amd64 #1 SMP Sun Mar 25 10:33:35 UTC 2012 x86_64 > GNU/Linux > > More information in the other bug report > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=670997 Please provide the command line you use to start the guest. I just verified - both amd64 and i386 6.0.4 images work in qemu-kvm-0.12 from squeeze. ia64 image does not work with the message you indicated in the subject of the bugreport, but as has been said in #670997, it is not supposed to work. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#671197: stop postfix from spinning up disks every 5 mins on idle system (useful for laptops etc)
Package: postfix Version: 2.9.1-4 Severity: wishlist Postfix uses FIFOs for /var/spool/postfix/public/pickup and /var/spool/postfix/private/qmgr, according to upstream master.cf file. These are used as triggers, by writing a char into one of these files corresponding service gets waked up to do its job. qmgr is configured in master.cf to wake up every 5 minutes (300 sec), which is implemented by master(8) using the same mechanism: by writing a char into private/qmgr FIFO every 300 seconds. But each write to a named pipe results in corresponding inode mtime to be updated, which results in disk spinning up every 5 mins - in case no other activity is hapening on the system. The usage of FIFOs here is due to a bug in Solaris unix sockets implementation. Its been this way for a long time, since 19990321, with the following text in the HISTORY file: Workaround: from now on, Postfix on Solaris uses stream pipes instead of UNIX-domain sockets. Despite workarounds, the latter were causing more trouble than anything else on all systems combined. and with further comments in src/master/trigger_server.c, in trigger_server_main(): * XXX Initially this code was implemented with UNIX-domain sockets, but * Solaris <= 2.5 UNIX-domain sockets misbehave hopelessly when the * client disconnects before the server has accepted the connection. * Symptom: the server accept() fails with EPIPE or EPROTO, but the * socket stays readable, so that the program goes into a wasteful loop. * * The initial fix was to use FIFOs, but those turn out to have their own * problems, witness the workarounds in the fifo_listen() routine. * Therefore we support both FIFOs and UNIX-domain sockets, so that the * user can choose whatever works best. * * Well, I give up. Solaris UNIX-domain sockets still don't work properly, * so it will have to limp along with a streams-specific alternative. The final solution was to actually use FIFOs. But this is specified in master.cf actually, so can easily be changed, even after install. My suggestion is to ship default configuration to use "unix" socket type for pickup and qmgr, instead of the default "pipe". Everything else works fine with it, and this is something which was actually used initially, but the default changed as per above. The original solaris problem does not exist on linux. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#670993: busybox: Please use dpkg-buildflags for hardening support
02.05.2012 16:39, Bastian Blank пишет: > On Mon, Apr 30, 2012 at 11:00:38PM -0700, Steve Langasek wrote: >> On Tue, May 01, 2012 at 09:53:14AM +0400, Michael Tokarev wrote: >>> Why do you filter this -W option? >> Well, it causes a build failure if you don't. ;) I inherited this from the >> previous Ubuntu changes, so I haven't fully reviewed the reason for this >> change but I believe they're all in the category of things that are safe but >> that gcc can't prove are safe. > > Is there a patch forwarded to busybox upstream to fix the problems? That's the constructs like this: bb_error_msg_and_die(bb_msg_memory_exhausted); where bb_msg_memory_exhausted is declared as extern char *. This is a poor-man implementation of internal constant string folding done by gcc for years. archival/libarchive/data_extract_to_command.c: In function ‘xputenv’: archival/libarchive/data_extract_to_command.c:41:3: error: format not a string literal and no format arguments [-Werror=format-security] cc1: some warnings being treated as errors I'm not sure a patch for this should be sent to upstream, unless it will patch out all this stuff to rely on gcc to do the work. But even there, it wont save from using slightly different wording for the same message... So I'm filtering out this -Werror=format-security indeed. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#645336: -device XXX replacements for -serial & -usbdevice not working (libvirt uses them)
Ping? Any information about this bug? (see also the initial bug, #645337) On 29.01.2012 19:58, Michael Tokarev wrote: > tags 645336 + moreinfo > thanks > > On 14.10.2011 19:26, martin f krafft wrote: >> Package: qemu-kvm >> Version: 1:0.14.1+dfsg-4 >> Severity: normal >> >> Instead of the classic command line switches like -serial and >> -usbdevice, libvirt invokes kvm with the more generic syntax, e.g. >> >> -device serial,… >> -device usb_host,… > > Do you have a reference on this - I mean from libvirt side, > not from qemu[-kvm] side? > > Libvirt usually does it the other way around: it adopts its > code based on changes in qemu. So new devices/syntaxes > appears in qemu first, and only after that they're being > used in libvirt. > > In particular, -device serial does not exist and never did, > but instead the right device is isa-serial, and that one > existed for a very long time. > > For -device usb-host (correct spelling is usb-host not usb_host), > this option exists and works. In order to use it, you have > to declare usb bus first. I verfied it in 0.14 -- > > kvm -usb -device usb-host,vendorid=xx,productid=yy > > works just fine. > >> Unfortunately, kvm does not seem to support those, and the device is >> not made available to the guest. If I manually influence the command >> line and use the classic command line switches, then it works, >> however. > > I'm not sure if I understand what you're saying here. > >> The reason why libvirt uses those generic -device lines is due to >> hotplug support. Apparently -device … is hotpluggable, while >> -usbdevice is not. > > Hot-UN-pluggable you mean? Because you can't hot-plug something > which is already plugged. > > Anyway, all usb devices - regardless if you specified them as > -device usb-foo or -usbfoo or used usb_add at runtime -- all of > them are hot-unpluggable. Ditto for almost all pci devices. > But devices like isa-serial (and anything on isa bus) is not > hot-(un-)pluggable, by definition, because ISA bus does not > support this feature and so there's no way for a guest to > handle it even if it'll be supported by qemu itself. > >> It would be good if kvm would support those generic device >> specifications, not only because it advertises them in its manpage, >> but mostly because libvirt makes use of them already. > > It does already, it looks like. > > Can you provide some more background for all this? > > Thanks! > > /mjt > > > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#665821: kvm: emulation failure when aros (icaros) attempts to reboot
On 29.03.2012 18:38, Michal Suchanek wrote: > Excerpts from Michael Tokarev's message of Mon Mar 26 14:54:34 +0200 2012: >> 26.03.2012 16:36, Michal Suchanek wrote: >>> Package: qemu-kvm >>> Version: 1:1.0+dfsg-9 >>> Severity: normal >>> >>> >>> When you select the reboot option in aros kvm writes: >>> >>> KVM internal error. Suberror: 1 >>> emulation failure >>> EAX= EBX=0351 ECX= EDX=039f >>> ESI=02fa1770 EDI=fc0dd840 EBP=010e1864 ESP=010e1820 >> >> This error comes from the host kernel. > > There is a patch in upstream kvm git which is probably going to get into > the Linux kernel and Wheezy+1, eventually. > > The patch does not apply to current Debian kernel sources. Which patch is that, can you show some details please? Thank you! /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#671340: ipxe: include undionly.kkpxe
03.05.2012 14:03, Kasatkin Nikolay wrote: > Package: ipxe > Version: 1.0.0+git-20120202.f6840ba-3 > Severity: wishlist > > Dear Maintainer, please consider including undionly.kkpxe in ipxe package. > We use undionly.kpxe for netbooting computer classes in our university. But > there are mainboards that can boot only with undionly.kkpxe, because of buggy > BIOS. So for now we compile ipxe manually to boot those computers over the > net via iPXE. If undionly.kkpxe will be included in ipxe package we will boot > our classes without compiling iPXE manually. How useful this undionly.kkpxe thing is, generally? The thing is: ipxe has really a TON of various options and configuration variations, packaging all these isn't practical. So we decided to package only one, the most universal variant. For other usages, recompiling from source is the best way to go, since you as a user know best which configuration do you need, exactly. It is not like ipxe is changing 10 times a day, so frequent recompile/reinstall isn't necessary: you compile it only when you hit some limitation or bug, in your version. It is not like ipxe is the place where most recent features are always requireed, either. So I'd say keep it the way the package currently is, and compile site-specific versions as needed, locally. And mark this bugreport as wontfix. Unless ther's a very good reason why this undionly.kkpxe can be useful for a much wider userbase. Also, when including other options, I'd say they should be made available using some configuration mechanism (such as debconf), to be included in a bootloader configuration -- like ipxe.lknl currently handled. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#671627: RFH: spice - Simple Protocol for Independent Computing Environment
On 05.05.2012 17:34, Liang Guo wrote: > Package: wnpp > Severity: normal > X-Debbugs-CC: debian-de...@lists.debian.org > > Hi, > > I'm looking for co-maintainers of package spice. Current spice > embeds celt051, an obsolete version of celt, so we intend to > remove celt051 support in spice, but I don't have enought time, > sufficient knowledge and necessary equipments to complete this > job, if someone interesting on this package, please let me know. I can help. I was about to package it anyway, but found out that you already packaged it just a day or two before me looked ;) So I started sponsoring your packages until you become a DD. I have a patch locally that removes references to celt from the code, just like a POC, the code builds but I never actually tried to run it yet, since my main development machine runs 32bit userspace, and spice has issues on 32bits (only very recent git version apparently fixes this long-standing issue). So, if you accept me as a co-maintainer, I can try my best to work it out, especially if upstream will finally release some more or less working version ;) Thank you for your efforts, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#671471: pulseaudio: /usr/share/alsa/pulse-alsa.conf may be old or corrupted
severity 671471 grave thanks I don't know who's bug/issue it is (it might be alsa bug after all), but it is definitely not just "important": it breaks all audio on the system, after pulseaudio update no application produces sound anymore - vlc, xine, mplayer, alsa tools, qemu, and (proprietary) flash plugin - in addition to being completely silent - also plays video (eg youtube) at about double framerate (ie, two times faster than normal). That's breaking other applications, hence the severity. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#603699: debian spice package
On 06.05.2012 08:21, Serge E. Hallyn wrote:
> Just saw http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=671627 (someone
> forwarded it to me). Glad it seems to have worked out :) If you want
> more help pls let me know, but if you're comfortable as is that's great.
Well, it hasn't worked out yet, as I wrote in #671627 I had no
good conditions to do the work before since spice didn't work
in 32bits, and while I had a patch for some time I had no idea
if it works or not.
Yesterday I did some testing, but again I've no idea if it works
or not -- I don't know how to test sound transmitted using spice!
The current version of the patch is attached, for anyone to
experiment. I'll try to do my best afer a short vacation we all
russians have these days due to the Victory Day (World Wide War II),
I'll be back in May-10.
Thank you!
/mjt
diff --git a/client/audio_channels.h b/client/audio_channels.h
index d38a79e..8f8a186 100644
--- a/client/audio_channels.h
+++ b/client/audio_channels.h
@@ -18,7 +18,9 @@
#ifndef _H_AUDIO_CHANNELS
#define _H_AUDIO_CHANNELS
+#if HAVE_CELT051
#include
+#endif
#include "red_channel.h"
#include "debug.h"
@@ -45,7 +47,9 @@ private:
void handle_start(RedPeer::InMessage* message);
void handle_stop(RedPeer::InMessage* message);
void handle_raw_data(RedPeer::InMessage* message);
+#if HAVE_CELT051
void handle_celt_data(RedPeer::InMessage* message);
+#endif
void null_handler(RedPeer::InMessage* message);
void disable();
@@ -57,8 +61,10 @@ private:
WavePlaybackAbstract* _wave_player;
uint32_t _mode;
uint32_t _frame_bytes;
+#if HAVE_CELT051
CELTMode *_celt_mode;
CELTDecoder *_celt_decoder;
+#endif
bool _playing;
uint32_t _frame_count;
};
@@ -96,8 +102,10 @@ private:
Mutex _messages_lock;
std::list _messages;
int _mode;
+#if HAVE_CELT051
CELTMode *_celt_mode;
CELTEncoder *_celt_encoder;
+#endif
uint32_t _frame_bytes;
static int data_mode;
diff --git a/client/playback_channel.cpp b/client/playback_channel.cpp
index 802a4d3..caf6424 100644
--- a/client/playback_channel.cpp
+++ b/client/playback_channel.cpp
@@ -151,8 +151,10 @@ PlaybackChannel::PlaybackChannel(RedClient& client, uint32_t id)
Platform::PRIORITY_HIGH)
, _wave_player (NULL)
, _mode (SPICE_AUDIO_DATA_MODE_INVALID)
+#if HAVE_CELT051
, _celt_mode (NULL)
, _celt_decoder (NULL)
+#endif
, _playing (false)
{
#ifdef WAVE_CAPTURE
@@ -169,7 +171,9 @@ PlaybackChannel::PlaybackChannel(RedClient& client, uint32_t id)
handler->set_handler(SPICE_MSG_PLAYBACK_MODE, &PlaybackChannel::handle_mode);
+#if HAVE_CELT051
set_capability(SPICE_PLAYBACK_CAP_CELT_0_5_1);
+#endif
}
void PlaybackChannel::clear()
@@ -182,6 +186,7 @@ void PlaybackChannel::clear()
}
_mode = SPICE_AUDIO_DATA_MODE_INVALID;
+#if HAVE_CELT051
if (_celt_decoder) {
celt051_decoder_destroy(_celt_decoder);
_celt_decoder = NULL;
@@ -191,6 +196,7 @@ void PlaybackChannel::clear()
celt051_mode_destroy(_celt_mode);
_celt_mode = NULL;
}
+#endif
}
void PlaybackChannel::on_disconnect()
@@ -214,8 +220,10 @@ void PlaybackChannel::set_data_handler()
if (_mode == SPICE_AUDIO_DATA_MODE_RAW) {
handler->set_handler(SPICE_MSG_PLAYBACK_DATA, &PlaybackChannel::handle_raw_data);
+#if HAVE_CELT051
} else if (_mode == SPICE_AUDIO_DATA_MODE_CELT_0_5_1) {
handler->set_handler(SPICE_MSG_PLAYBACK_DATA, &PlaybackChannel::handle_celt_data);
+#endif
} else {
THROW("invalid mode");
}
@@ -224,8 +232,11 @@ void PlaybackChannel::set_data_handler()
void PlaybackChannel::handle_mode(RedPeer::InMessage* message)
{
SpiceMsgPlaybackMode* playbacke_mode = (SpiceMsgPlaybackMode*)message->data();
-if (playbacke_mode->mode != SPICE_AUDIO_DATA_MODE_RAW &&
-playbacke_mode->mode != SPICE_AUDIO_DATA_MODE_CELT_0_5_1) {
+if (playbacke_mode->mode != SPICE_AUDIO_DATA_MODE_RAW
+#if HAVE_CELT051
+&& playbacke_mode->mode != SPICE_AUDIO_DATA_MODE_CELT_0_5_1
+#endif
+ ) {
THROW("invalid mode");
}
@@ -265,9 +276,6 @@ void PlaybackChannel::handle_start(RedPeer::InMessage* message)
start_wave();
#endif
if (!_wave_player) {
-// for now support only one setting
-int celt_mode_err;
-
if (start->format != SPICE_AUDIO_FMT_S16) {
THROW("unexpected format");
}
@@ -284,6 +292,10 @@ void PlaybackChannel::handle_start(RedPeer::InMessage* message)
return;
}
+#if HAVE_CELT051
+// for now support only one setting
+int celt_mode_err;
+
if (!(_celt_mode = celt051_mode_create(start->frequency, start->channels,
frame_size, &celt_mode_err))) {
THROW("create celt mode failed %d", celt_mode_err);
@@ -292,6 +304,7 @@ void PlaybackChannel::handle_start(RedPeer::I
Bug#671701: RFS: autofs/5.0.6-1 [ITA] -- kernel-based automounter for Linux
On 06.05.2012 07:14, Dmitry Smirnov wrote: > Package: sponsorship-requests > Severity: normal > > Dear mentors, > > I am looking for a sponsor for package "autofs" > > * Package name: autofs >Version : 5.0.6-1 Hello Dmitry. I'm very much interested in this package myself, and wanted to do some packaging as well, but got distracted by other things, and especially by the famous 32/64bit user<=>kernel space interface issues we found recently (there was several threads on LKML about it and a feature LWN article). I looked at your packaging, it looks sane at first, but you did quite a few things all in one go, so it makes me a bit nervous. Especially, did you test transition from autofs5 to autofs, does it work correctly? I'd love to sponsor this package, and maybe to become a co-maintainer if that's welcome in any way, but unfortunately I've no time in a few days to work with it, -- as you may know, we all russians have a long weekend, due to the Victory Day, so I'll be unavailable (and away from computers) up to May-10. Can you wait for a few days please? :) Unless someone else wants to sponsor this package ofcourse! I will try to find some time in these days to check it all too, but I can't promise. BTW, Monday (tomorrow) have a good chance to have me semi-available :) Thank you, especially for doing this packaging! The new packaging and the care with which you do things - I like it! /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#671701: RFS: autofs/5.0.6-1 [ITA] -- kernel-based automounter for Linux
On 06.05.2012 09:01, Michael Tokarev wrote:
> On 06.05.2012 07:14, Dmitry Smirnov wrote:
>> Package: sponsorship-requests
>> Severity: normal
>>
>> Dear mentors,
>>
>> I am looking for a sponsor for package "autofs"
>>
>> * Package name: autofs
>>Version : 5.0.6-1
There's one more issue with the new package. I already
told Ian about it, but apparently he ignored it. This
new code being added as a patch to debian package,
originally from upstream author:
++static inline unsigned int linux_version_code(void)
++{
++struct utsname my_utsname;
++unsigned int p, q, r;
++
++if (uname(&my_utsname))
++return 0;
++
++p = (unsigned int)atoi(strtok(my_utsname.release, "."));
++q = (unsigned int)atoi(strtok(NULL, "."));
++r = (unsigned int)atoi(strtok(NULL, "."));
++return KERNEL_VERSION(p, q, r);
++}
This will break with 2-number kernel version string. There
were several tools who assumed 3-component version string
and who broke when 3.0-rc come out, so Linus decided to
postprone defaulting to 2-component version. Many packages
has been fixed since, but here autofs introduces a new bug
of the same theme.
Note that actually the version check isn't really necessary
since the issue for which it has been added is now resolved
in the kernel.
Thanks,
/mjt
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#671701: RFS: autofs/5.0.6-1 [ITA] -- kernel-based automounter for Linux
On 06.05.2012 09:21, Michael Tokarev wrote:
> On 06.05.2012 09:01, Michael Tokarev wrote:
>> On 06.05.2012 07:14, Dmitry Smirnov wrote:
>>> Package: sponsorship-requests
>>> Severity: normal
>>>
>>> Dear mentors,
>>>
>>> I am looking for a sponsor for package "autofs"
>>>
>>> * Package name: autofs
>>>Version : 5.0.6-1
>
>
> There's one more issue with the new package. I already
> told Ian about it, but apparently he ignored it. This
> new code being added as a patch to debian package,
> originally from upstream author:
>
> ++static inline unsigned int linux_version_code(void)
> ++{
> ++struct utsname my_utsname;
> ++unsigned int p, q, r;
> ++
> ++if (uname(&my_utsname))
> ++return 0;
> ++
> ++p = (unsigned int)atoi(strtok(my_utsname.release, "."));
> ++q = (unsigned int)atoi(strtok(NULL, "."));
> ++r = (unsigned int)atoi(strtok(NULL, "."));
> ++return KERNEL_VERSION(p, q, r);
> ++}
>
> This will break with 2-number kernel version string. There
> were several tools who assumed 3-component version string
> and who broke when 3.0-rc come out, so Linus decided to
> postprone defaulting to 2-component version. Many packages
> has been fixed since, but here autofs introduces a new bug
> of the same theme.
>
> Note that actually the version check isn't really necessary
> since the issue for which it has been added is now resolved
> in the kernel.
And note that whole 5.0.6-allow-for-kernel-packet-size-change.patch
is NOT NEEDED, it should be reverted upstream. *SIGH*, we spent
a ton of time and emails discussing this matter, please find
the recent LWN feature article about it (a good summary), or
LKML threads. The patches are now added to all stable trees.
The two patches -- linux kernel version check and this one --
should be reverted upstream and not included in debian package.
Thanks,
/mjt
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#671701: RFS: autofs/5.0.6-1 [ITA] -- kernel-based automounter for Linux
On 06.05.2012 09:45, Dmitry Smirnov wrote: >> ++p = (unsigned int)atoi(strtok(my_utsname.release, ".")); >> ++q = (unsigned int)atoi(strtok(NULL, ".")); >> ++r = (unsigned int)atoi(strtok(NULL, ".")); >> ++return KERNEL_VERSION(p, q, r); >> ++} >> >> This will break with 2-number kernel version string. There >> were several tools who assumed 3-component version string >> and who broke when 3.0-rc come out, so Linus decided to >> postprone defaulting to 2-component version. Many packages >> has been fixed since, but here autofs introduces a new bug >> of the same theme. > I'm not sure if I fully understand the implications... > As far as I know it works well with 3.2 kernel... > Any suggestions are welcome. If the kernel version number will be, say, 3.2 instead of 3.2.0, the 3rd atoi() above will crash, since strtok() will return NULL. Linus expecially reverted the change which he made before 3.0 went out -- change to return 3.0 instead of 3.0.0. This has been done merely in order to let userspace to fix the errors like the above, since it turned out there were lots of userspace code like this which "thought" that kernel version string will always gave 3 components. Most or all code has been fixed by now to allow either 2 or 3 components. But this _new_ code repeats the same bug again. I'll talk with Ian about all this -- maybe he'll just revert/rebase it in his autofs tree, I dunno yet. > By the way, many thanks to you for your work on 'mdadm' package. > I'm in your debt for this. > Eventually I might be available for help but you're doing great already. :) Um... thank you for your apprecation but.. I'm doing almost nothing :) I'm waiting for the next version which should be out RSN to package it -- it should close a few bugs right away. But I have done almost nothing with the scripts -- like "check" cron job suggestions or other stuff in that area... But this is a different topic entirely :) Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#669184: qemu-kvm: Virtio network drops in case of a heavy load
On 18.04.2012 04:14, Vugar Dzhamalov wrote: > Package: qemu-kvm > Version: 1.0+dfsg-9 > Severity: important > > It seems that I am getting into something very similar to these bug reports: > > https://bugzilla.redhat.com/show_bug.cgi?id=554078 > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=576838 > > At the same time while running it with e1000 I don't get any similar issues. Please provide actual data from your systems. Both bugreports you references are old and fixed long ago, so "something very similar" needs quite a bit of details since it is a new bug. Describe what you do, what actually happens, what messages from host and guest you're getting etc. > I've never done any bug reporting prior to this one so if you would like me > to > provide you with any further info I'll try to do my best. Thanks You're welcome. Let's try the above first... Thank you! /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#625716: kvm: cannot boot from USB
On 18.04.2012 18:51, intrigeri wrote: > Hi, > > Michal Suchanek wrote (05 May 2011 13:41:01 GMT) : >> Booting this way from an Ubuntu USB install media is also very slow >> but at least I can confirm the media is bootable. > > I'm going to file a wishlist bug about USB2 redirection soon, > that will be about performance matters. Doesn't usb2 redirection work already? > #625716, though, is purely about ability to boot from USB at all, > which apparently works, so it should be closed, shouldn't it? Note that #625716 is tagged with "squeeze", as in, 0.12 (squeeze) version of qemu-kvm does not boot from an usb device, because the bios it uses does not have proper usb support. It is fixed in more recent versions of qemu/bios, but it wont be fixed in squeeze. So it shouldn't be closed. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#669184: qemu-kvm: Virtio network drops in case of a heavy load - Follow-up on virtio_net drop
On 23.04.2012 11:54, Vugar Dzhamalov wrote: [] I'll take a look. For the next time, please don't send me content of your /usr/bin or any other directories. Just _versions_ of the software affected, and, most important, the steps you did to (re)produce the issue. This includes the way you start your guests too - this is your kvm command line. > Is there anything else I can do here to help with this? Thank you. Yes. What's the guest kernel details please? What is your kvm command line? Also, does it happen with regular bridge networking too, or only vde? Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#669184: qemu-kvm: Virtio network drops in case of a heavy load - Follow-up on virtio_net drop
Okay, I re-created your configuration with vde_switch, and I found the kvm command lines you used in one of the files -- you sent just too much information so really important bits got lost in the noize initially. I'm doing a copy test from one guest /dev/zero to another guest /dev/null. It copied 120 Gigs of data so far, and counting. Should it stop somewhere as per your bugreport? How can I make it stop/stall? Thank you! /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#669184: qemu-kvm: Virtio network drops in case of a heavy load - Follow-up on virtio_net drop
On 26.04.2012 12:24, Vugar Dzhamalov wrote: > > Thank you for doing this. I am very appreciate and sorry for wasting your > time > with this. > Lets be honest here I've reported it more than a week ago and so far no one > else joined the discussion. I guess it is quite obvious that there is > something wrong with my setup rather than anything else... I'm not sure I understand. You have a problem which looks very much like a bug. The fact that no one else joined this discussion tell exactly nothing, since at this state, bugs are much more difficult to hit, since most obvious bugs which are hit by all users are fixed ages ago. Again, the fact I can't reproduce it does not mean it does not exist, but it most likely means my setup is (slightly) different than yours and something which we overlooked does not let me to hit this bug. Lack of other users hitting this bug does not mean the bug does not exist. We should actually find what is going on - either a real bug in the code or something "wrong" in your setup or something else, before deciding what to do next. > I've launched 64 bit CentOS 6.2 as two guests in the same manner as I did > with > two 64bit Debian testing (wheezy) guests in the previous attempt and got the > same issues with the virtio NIC. There is something wrong with my setup... > > I've found following in my /var/log/syslog > > > kernel: [201326.063213] kvm: 17363: cpu0 unhandled rdmsr: 0xc001100d > kernel: [201326.063226] kvm: 17363: cpu0 unhandled rdmsr: 0xc0010112 > kernel: [201326.193885] kvm: 17363: cpu0 unhandled rdmsr: 0xc0010001 These are accesses by the guest to model-specific CPU registers (MSRs). Qemu must emulate these but it does not emulate all of them (and we can't even know all of them since CPUs are different). What you see here are: 0xC001100d CPU_ID_HYPER_EXT_FEATURES (information about extended features of hypervisor) 0xc0010112 MSR_K8_TSEG_ADDR (some AMD K8-specific register) 0xC0010001 MSR_K7_EVNTSEL1 (some AMD K7-specific register) Guest just probes various features of the CPU to know what a CPU can do, poking around what it knows. Qemu merely reports it didn't know what to do with these, and returned some sort of failure to the guest, which, at this stage, was fully prepared to handle. So these are all harmless. > I can't see anything else I can do at this stage. I can use e1000 - it is > more than sufficient for my current needs. Thank you. This is very good that you have a workaround - it means I can do some more urgent work before I'll take a look at this again. But the probleb appears to be here and we need to find it and fix it or at least understand why and where it happens. (And yes I'd be very glad to close this bugreport so I'd have less bugs to deal with :) Thank you! /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#639529: summary: please add entry to /etc/nsswitch.conf
On 03.06.2012 15:15, Andreas B. Mundt wrote:
[]
>>> "automount: files ldap"
>>
>> Will it be bad if this line will be left out after removing autofs-ldap
>> package, ie, when automount nsswitch entry is listing non-existing lookup
>> method? I guess I should try...
>
> Apart from leaving cruft back, I guess it should not hurt.
>
>> I mean, is it a bug to leave "ldap" in there on autofs-ldap removal?
>
> Not sure if "leaving cruft behind" is a bug in this case.
Not really - automount may start complaining or failing. But
apparently it does not. I mean the situation when we leave
`automount: files ldap' line in there on removal of autofs-ldap
package, when autofs package itself is still installed and
functioning.
And I really dislike this way of leaving ldap entry in place
in this case, even if automount itself appears to be working
fine - I'd say it works by incident not by design, as it should
complain about such an error.
So, on autofs-ldap removal, we should remove ldap entry from
automount nsswitch.conf line. And here we've a few other issues
to sort out. For example, say, we added `files ldap' into it
automaticlaly, and the user later changed that to `ldap': in
this case we can't remove just the ldap entry, since the line
will be wrong in this case.
And we definitely can not remove whole line too, like is done
in sudo-ldap case: we also have hesiod map which should be
handled the same way!
So... I'm not sure what to do really. Too much smarts often
becomes dumber than doing nothing at all... :)
[]
> From what I learned in the discussions about "/etc/nsswitch.conf", I suspect
> the order of entries does not matter.
> (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=639530#10>)
Well, automount (or any other lookup "consumer" for that matter) should
choose one entry from several available. For example, you can't
expect getpwnam("root") returning TWO entries, if passwd: entry in
nsswitch lists, eg, `files, ldap' and BOTH has definition for the
root user. So order definitely does matter.
Thanks,
/mjt
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#675798: 5.0.6-2 breaks NFSv4
On 03.06.2012 16:31, Jamie Heilman wrote: > Package: autofs > Version: 5.0.6-2 > Severity: important > > For reasons I haven't entirely taken the time to figure out, the > changes between 5.0.6-1 and 5.0.6-2 have destroyed my ability to > automount NFSv4 shares. My configs are dead simple, my entire > auto.master is simply: "/home /etc/auto.home" and /etc/auto.home > contains: "jamie -vers=4 canarsie:/home/jamie" > > After upgrading to 5.0.6-2 automount never gets as far as exec'ing the > mount command; the most immediately obvious difference from 5.0.6-1 is > that it appears to attempt to communicate to the portmapper on > canarsie (my nfs server) and fails (understandbly---I'm running NFSv4 > only, no portmapper listening externally, nor is it necessary). This is interesting. Autofs package has native support for NFS from the ground up, but apparently this support has never been activated in debian package, because autofs configure script checks for presence of /sbin/mount.nfs to decide whenever to compile in NFS support and uses stubs it mount.nfs hasn't been found. But on buildds that file doesn't exist. In 5.0.6-2, I explicitly told configure that we do have mount.nfs, so NFS support has been activated, whatever it means. I'm running 5.0.6-2 version currently, and it is definitely able to mount nfs4 shares - I've an NFS4 server right here which IS used with automount. But please take a look at the configuration (/etc/default/autofs) -- for example, there's MOUNT_NFS_DEFAULT_PROTOCOL setting which might help. Does it work if you enable portmapper/rpcbind on the server? (It is enabled here) Thank you! /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#675796: postrm bugs prevent purge/downgrade/etc
tags 675796 + pending thanks On 03.06.2012 16:36, Jamie Heilman wrote: > Package: autofs > Version: 5.0.6-2 > > The autofs package's postrm script it calls "ucfr -p autofs5 $CONFF" > for CONFF in /etc/auto.master /etc/auto.net /etc/auto.misc > /etc/auto.smb /etc/default/autofs; which no longer works as all of > those files have been registered as being owned by package "autofs" > in 5.0.6-2. I basically rewrote this file just today. It will be fixed in the next upload. We had a few issues with transitioning from autofs5 to autofs, and not all of them are - apparently - fixed yet. Well, hopefully this one is the last ;) But I'm not sure I want to preserve ability to downgrade to the old autofs5 package - that will require a bit more work. It is definitely doable, but I'm not sure if it is worth the effort. Thank you! /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#639529: summary: please add entry to /etc/nsswitch.conf
On 03.06.2012 16:55, Andreas B. Mundt wrote: > On Sun, Jun 03, 2012 at 04:06:37PM +0400, Michael Tokarev wrote: > I guess autofs doesn't use "nsswitch.conf" at all, does it? Apparently it does -- this is the very end of default /etc/auto.master file: # Include central master map if it can be found using # nsswitch sources. # # Note that if there are entries for /net or /misc (as # above) in the included master map any keys that are the # same will not be seen as the first read key seen takes # precedence. # +auto.master When I put a map into "automount" line in nsswitch.conf which does not exist, it logs the following line into daemon.log: automount[1519]: ignored unsupported autofs nsswitch source "xyz" the same happens with ldap if it is in that line and there's no /usr/lib/autofs/lookup_ldap.so file found. But wait. What else uses nsswitch automount entry if not automount itself? >> So, on autofs-ldap removal, we should remove ldap entry from >> automount nsswitch.conf line. And here we've a few other issues >> to sort out. For example, say, we added `files ldap' into it >> automaticlaly, and the user later changed that to `ldap': in >> this case we can't remove just the ldap entry, since the line >> will be wrong in this case. > > Right. > >> And we definitely can not remove whole line too, like is done >> in sudo-ldap case: we also have hesiod map which should be >> handled the same way! > > No idea about hesiod. Does it use "nsswitch.conf"? It is configured the same way as ldap: using nsswitch.conf. All maps also can be used directly as well, by specifying map-type properly in /etc/auto.master. >> So... I'm not sure what to do really. Too much smarts often >> becomes dumber than doing nothing at all... :) > > Yes, again things are more complicated than expected on a first > sight... So the only question remains: do you have other users of automount entry in nsswitch.conf except of autofs package itself (where it has other mechanism too) ? I'm about to mark this bug as a wishlist wontfix really... ;) Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#635548: CVE-2011-2716
On 03.06.2012 15:29, Thijs Kinkhorst wrote: [] > Good! Will you ensure that 1.20 ends up in wheezy? Yes I very much like to have at least this version in wheezy. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#675796: postrm bugs prevent purge/downgrade/etc
On 03.06.2012 17:35, Michael Tokarev wrote: > tags 675796 + pending > thanks > > On 03.06.2012 16:36, Jamie Heilman wrote: >> Package: autofs >> Version: 5.0.6-2 >> >> The autofs package's postrm script it calls "ucfr -p autofs5 $CONFF" >> for CONFF in /etc/auto.master /etc/auto.net /etc/auto.misc >> /etc/auto.smb /etc/default/autofs; which no longer works as all of >> those files have been registered as being owned by package "autofs" >> in 5.0.6-2. > > I basically rewrote this file just today. It will be fixed > in the next upload. We had a few issues with transitioning > from autofs5 to autofs, and not all of them are - apparently - > fixed yet. Well, hopefully this one is the last ;) Actually, this very bug you quote is already fixed in 5.0.6-2. It was the previous version, 5.0.6-1, which were buggy in this place. /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#675798: 5.0.6-2 breaks NFSv4
retitle 675798 autofs requires portmapper on server even for NFSv4 mounts tags 675798 confirmed upstream thanks On 03.06.2012 17:31, Michael Tokarev wrote: [] > Does it work if you enable portmapper/rpcbind on the server? > (It is enabled here) I just verified - and indeed, with no rpcbind running on the server, automount does not work anymore, ie, it requires portmapper on the server even for NFSv4 mounts. Retitling as appropriate. The setting in /etc/default/autofs -- MOUNT_NFS_DEFAULT_PROTOCOL -- has no effect on this. Can you tell me please how did you manage to install server without rpcbind -- provided the server is running Debian too? :) And now, I'm not sure what to do with all this. Maybe it is better to stop automount from messing up with the filesystems completely, and let the real tools to do the work? I dunno, and I don't really know what advantages the in-autofs NFS handling gives, over nfs-utils utilities. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#675798: autofs & NFS
On 03.06.2012 18:39, Michael Tokarev wrote: > On 03.06.2012 17:31, Michael Tokarev wrote: > [] >> Does it work if you enable portmapper/rpcbind on the server? >> (It is enabled here) > > I just verified - and indeed, with no rpcbind running on the > server, automount does not work anymore, ie, it requires > portmapper on the server even for NFSv4 mounts. Retitling > as appropriate. And this is indeed the case. The whole logic in autofs around this is wrong in so many ways I'm afraid to count!.. :( For now I suggest to actually run rpcbind on the server, this issue needs to be dealt with upstream. Neither version of the code is right. Since there's an easy workaround for you, and this issue does not default settings (you have to explicitly disable rpcbind on the server for it to stop working), and even more -- it actually _works_, but with a several-second timeout (at least here, please reply if it is not the case for you), I downgrade this bugreport to wishlist severity. For added fun, in 5.0.6-1 here /net map does not work at all, the daemon segfaults on first access. I haven't looked, may be that's fixed by some patch from upstream git, -- there were several mentions of SIGSEGVs there. 5.0.6-2 actually works, but /net map does not work at all if portmapper is not running on the server I'm trying to access (it can't get list of mounts in that case). For even more added fun, the portmapper call it tries to perform can be finished immediately, since the server replies with the appropriate ICMP (port unreachable), yet automount relies on timeouts only. In order to activate checking for port unreachable replies, the (UDP) socket needs to be in connected state, that's just one extra syscall and these stupid timeouts will go away. Overall, the code quality is very very low, I'm not sure it is possible to maintain this package without very serious work with upstream first. Oh well. /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#675798: autofs & NFS
On 03.06.2012 23:38, Jamie Heilman wrote: [] >> For now I suggest to actually run rpcbind on the server, this >> issue needs to be dealt with upstream. Neither version of the >> code is right. > > Hell no. The entire reason I bothered with v4 is because it gets rid > of the external portmapper requirement, rpc.statd, rpc.mountd, and > rpc.lockd. All of which was working just fine until 5.0.6-2 came along. Please stop shouting - I based my analysis/suggestions on some assumptions and actually even asked if that's the case. Note I didn't downgrade the bug severity, awaiting your comments/confirmation. >> Since there's an easy workaround for you, and this issue does >> not default settings (you have to explicitly disable rpcbind >> on the server for it to stop working), and even more -- it >> actually _works_, but with a several-second timeout (at least >> here, please reply if it is not the case for you), I downgrade >> this bugreport to wishlist severity. > > Don't assume the server is a Debian system and that you know its > defaults, even though it happens to be in this case. Regardless, > I'm not going to change my server config to satisfy the new, > broken, requirements of this package, I'll rebuild the damned thing > myself from here on out if I have to. The sane thing would be to just > revert the build instructions until such time the native NFS support > in automount correctly supports NFSv4 mounts without needless rpc > usage. If you want fighting, you're ofcourse free to rebuild anything, but I don't think it is productive. You now demonstrated your usage case and that is enough to convince me or anyone else that I took a wrong way, and the issue is quite a bit more complex. Note again that NFSv4 does not work with autofs still -- namely, its /net map still requires portmapper. And note - also again - that even without turning on this "HAVE_NFS" thing, it were working just by a chance. I'll take another look at what the two options (with and without "NFS Support") gives. But I want to understand: why all this shouting from you? Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#675798: 5.0.6-2 breaks NFSv4
On 03.06.2012 23:15, Jamie Heilman wrote: > Michael Tokarev wrote: [] >> I dunno, and I don't really know what advantages the in-autofs NFS >> handling gives, over nfs-utils utilities. > > Then why did you enable it? Because it is how the code is supposed to work initially. The previous (working) behavour is a fallback for older (pre-2.6.25) kernel and older (pre-1.1.1) nfs-utils. /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#675798: autofs & NFS
04.06.2012 05:34, Dmitry Smirnov wrote: > Michael, please excuse me for adding my portion of rant. > > Generally speaking assumptions and changes to package' logic outside > of packaging updates would be safer to avoid when we should release > ASAP due to freeze time. > > Even to me the change in package behaviour you introduced was unexpected. > (another concern is new updated patch set). > > From my non-DD co-maintainer prospective, the package was released > with too many changes (contrary to my suggestions), too fast (for > amount of changes introduced) and without enough testing. It is OK to > make serious changes to the package if we have enough time for safe > release or at least if there is a working version in 'testing'. Yes. You did too many changes at once. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#676001: Processed: reassign 676001 to busybox
On 05.06.2012 00:45, Debian Bug Tracking System wrote: > Processing commands for cont...@bugs.debian.org: > >> reassign 676001 busybox > Bug #676001 [initramfs-tools] initramfs-tools: busybox's switch_root doesn't > handle /proc or /sys moving > Bug reassigned from package 'initramfs-tools' to 'busybox'. When reassigning bugs like this, care to explain the reasoning too, so that it wont be necessary to send a followup questions like this one? I disagree it is a busybox problem, and don't think it is a switch_root business (be it from busybox or from util-linux). There are a few special directories which needs to be moved or umounted. This includes /proc, /dev, /sys and not mentioned here /run. These directories might be mounted in the new root already, or there may be some option passed to initramfs to not mount these, or there may be other local policy or whatever decisions. All that can't be handled and can't be known to switch_root -- this is exactly why we have initramfs/init as a script, to be able to handle various local usecases/policies and made it extendable. Also, as shown by Vagrant in the initial bugreport, it is really trivial to fix it in initramfs. The fact that util-linux is doing this does not make it right thing to do. Why do you think it is a busybox bug? Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#652573: busybox-udeb: debian stable busybox udhcp client does not support /32 netmasks
retitle 652573 busybox ip addr add ip.add.re.ss/32 does not work thanks On 05.06.2012 14:18, Jens Ott - Profitbricks wrote: > Michael, > Conrad, > > as far as I am aware, the problem is NOT the dhcp-client of busybox > itself but the hook-script used in debian. Find attached a hook-script > which I use in my home-brewn rescue and which used to work also with > /32 (sorry don't have an environment to test at hand, so I could not > proove). So IMHO actually only the hook-script in debian is screwed up. Thank you Jens for the reply. Now I see what's going on. It is not udhcpc, and not the udhcpc script either. It is busybox's `ip' utility. # busybox ip -4 add 192.168.77.10/32 dev dummy0 ip: invalid argument '192.168.77.10/32' to 'ip' # busybox ip -4 add 192.168.77.10/31 dev dummy0 # _ And this is exactly what's used in the udeb script: bound|renew) ip -4 addr add "$ip/$subnet" dev "$interface" So I'm retitling the bugreport accordingly, and will try to fix it now, when it is clear where the problem is, exactly. Thank you very much guys for the help! /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
