Re: [gentoo-user] /usr/portage/distfiles for amd64 and x86 -- the same?
On Monday 13 Jun 2011 12:29:27 Pandu Poluan wrote: Are the distfiles in /usr/portage/distfiles identical for both amd64 and x86 Gentoo? Well in most cases if the versions of the packages installed are same then the distfiles are same. But sometimes certain ebuilds are masked for different archs so you'll have different versions installed on your x86 and amd64 machines, in that case the distfiles for those packages would be different. Also there mite be certain ebuilds that install binary files like flash those would be incompatible too. -- - Yohan Pereira A man can do as he will, but not will as he will - Schopenhauer
Re: [gentoo-user] /usr/portage/distfiles for amd64 and x86 -- the same?
On Mon, Jun 13, 2011 at 13:02, Yohan Pereira yohan.pere...@gmail.com wrote: On Monday 13 Jun 2011 12:29:27 Pandu Poluan wrote: Are the distfiles in /usr/portage/distfiles identical for both amd64 and x86 Gentoo? Well in most cases if the versions of the packages installed are same then the distfiles are same. But sometimes certain ebuilds are masked for different archs so you'll have different versions installed on your x86 and amd64 machines, in that case the distfiles for those packages would be different. Also there mite be certain ebuilds that install binary files like flash those would be incompatible too. Hmmm... But different distfiles will have different names, right? Rgds, -- Pandu E Poluan ~ IT Optimizer ~ Visit my Blog: http://pepoluan.posterous.com
Re: [gentoo-user] /usr/portage/distfiles for amd64 and x86 -- the same?
Pandu Poluan wrote: On Mon, Jun 13, 2011 at 13:02, Yohan Pereirayohan.pere...@gmail.com wrote: On Monday 13 Jun 2011 12:29:27 Pandu Poluan wrote: Are the distfiles in /usr/portage/distfiles identical for both amd64 and x86 Gentoo? Well in most cases if the versions of the packages installed are same then the distfiles are same. But sometimes certain ebuilds are masked for different archs so you'll have different versions installed on your x86 and amd64 machines, in that case the distfiles for those packages would be different. Also there mite be certain ebuilds that install binary files like flash those would be incompatible too. Hmmm... But different distfiles will have different names, right? Rgds, In the case of a binary, it should. If it didn't, portage wouldn't know which one it was getting. It may not be a good idea to put a amd64 binary on a x86 machine. May not work to well. So, they should be different. As mentioned before, flash would be one case, video drivers could be another if they are binaries as well. There may be others to. Dale :-) :-)
Re: [gentoo-user] /usr/portage/distfiles for amd64 and x86 -- the same?
On Monday 13 Jun 2011 13:15:39 Pandu Poluan wrote: But different distfiles will have different names, right? yea. i use my amd64 distfiles in my x86 chroot using the portage variable PORTAGE_RO_DISTDIRS. Any distfiles that are not present/incompaitable are downloaded by the chroot's portage. -- - Yohan Pereira A man can do as he will, but not will as he will - Schopenhauer
Re: [gentoo-user] USB Problems
john j...@arcticwolf.myzen.co.uk [11-06-13 07:28]: On Sun, 12 Jun 2011 16:57:11 -0500 Dale rdalek1...@gmail.com wrote: john wrote: On Sun, 12 Jun 2011 15:50:18 -0500 Dalerdalek1...@gmail.com wrote: Have you looked to see if that mobo has a USB problem and a BIOS update to fix it? Just curious. Dale :-) :-) Thanks Dale, Good thinking. Will have a look. Did upgrade earlier in the year but will have another look. Since the sticks work in other systems, they SHOULD be ok. Then it becomes a hardware issue. If they work in a OS then it makes me wonder if there is something about the BIOS itself. Maybe the BIOS has a issue that only affects it when it is being booted from. Just my weird thinking. Dale :-) :-) Thanks, 2.6.36 works fine 2.6.38-r6/r7 panic Have noticed that using device drivers as modules allows me to boot with memory stick already inserted. This previously would not work. But the problem still occurs when stick is hot plugged. So the issue is half solved At least I can access memory stick. So thanks there. Will try Vanilla sources tonight and report bug to lkml. BIOS is latest standard. SO can't upgrade there -- -- -- John D Maunder j...@arcticwolf.myzen.co.uk Hi John, just an suggestion: If trying vanilla sources it would be an idea, to download both: The vanilla version of the kernel you have encountered problems with and the newest shiny one: The kernel of all kernels - the king of the road of all versions: linux-2.6.39.1 ;) ...just for the case, the kernel hackers -- Linus and crew -- have fixed the bug already. Fingers crossed! Best regards, mcc
Re: [gentoo-user] Re: OT: Firefox - saved or not ot be saved...
Hartmut Figge h.fi...@gmx.de [11-06-13 07:32]: meino.cra...@gmx.de: there is one feature of forefox, which bugs me: On the same site (www.blenderswap.com) I click to files to download. One is a *.blend, the other one is a *.rar. When I click the *.blend, the file gets downloaded and stored on my hd at once - bad! When I click the *.rar, the file gets NOT downloaded at once and instead I am offered a dialog, which asks what to do. I looked into Preferences-Application, which lists filetypes and the according action and DONT find an entry for *.blend files. What happens depends on the Content-Type with which the server delivers the file. Here is an example. http://www.triffids.de/pub/blend/ Both files are identical text files, but hm.blend1 comes with text/plain and hm.blend2 comes with text/hafi. The last is unknown *g*, so it will be asked what to do. text/plain is well known and the browser will display its content. Where can I change the action selected by Firefox which gets executed for a certain filetype else? Look at the Content-Type of your *.blend. One way to do this is with HEAD which is part of libwww-perl. hafi@i5 ~ $ HEAD http://www.triffids.de/pub/blend/hm.blend2 200 OK Connection: close Date: Mon, 13 Jun 2011 05:21:15 GMT Accept-Ranges: bytes ETag: 942355-b-4a590cf7e03b1 Server: Apache Content-Length: 11 Content-Type: text/hafi Last-Modified: Mon, 13 Jun 2011 05:01:21 GMT Client-Date: Mon, 13 Jun 2011 05:21:15 GMT Client-Peer: 85.13.136.212:80 Client-Response-Num: 1 Hartmut -- Usenet-ABC-Wiki http://www.usenet-abc.de/wiki/ Von Usern fuer User :-) Hi Hartmut, Oh, yeah! GREAT! I didn't know of HEAD at all - this nice tool fixes the problem at once! Great help, thank you very much ! :))) Have a nice Pfingstmontag :) Best regards, mcc
Re: [gentoo-user] Re: OT: Firefox - saved or not ot be saved...
Look at the Content-Type of your *.blend. One way to do this is with HEAD which is part of libwww-perl. Easier to just use 'wget -S url' if you dont have libwww-perl installed.
[gentoo-user] Re: /usr/portage/distfiles for amd64 and x86 -- the same?
On 06/13/2011 08:29 AM, Pandu Poluan wrote: Please forgive my (probably) stupid question: Are the distfiles in /usr/portage/distfiles identical for both amd64 and x86 Gentoo? Usually. But an ebuild can specify a different distfile for x86 but use the same name. This isn't dangerous though, since the checksum will catch it. That means you can use the same distfiles directory for both, and if you come across an ebuild that does weird stuff, portage will bark and re-download the correct distfile.
[gentoo-user] Re: OT: Firefox - saved or not ot be saved...
Adam Carter: Look at the Content-Type of your *.blend. One way to do this is with HEAD which is part of libwww-perl. Easier to just use 'wget -S url' if you dont have libwww-perl installed. wget -S --spider url, hm? ;) Hartmut -- Usenet-ABC-Wiki http://www.usenet-abc.de/wiki/ Von Usern fuer User :-)
[gentoo-user] Questions about the magic Sys Req keys
Howdy, I just had a hard lock up. I had a random reboot the other day while I was sleeping as well. This was with gentoo-sources 2.6.39. I'm not sure what caused the one the other day but I had several days of uptime. The one I just had was also after a few days of uptime. I was logged into KDE when EVERYTHING froze. The mouse pointer wouldn't move. The clock stopped. The numlock light wouldn't even change when I hit the key for it. So, X was locked up pretty good. I also couldn't switch to a console either. This is the odd part. I tried to use the magic Alt SysReq keys to at least try to get a reasonable shutdown. They didn't work either. So, my question is this. What kind of lock up could keep the magic keys from working? This is on my new amd64 machine. It was totally stable until the kernel upgrade. I think this could be a kernel issue. I booted a older kernel and will test it for a few days but wanted to know what kind of lockups could keep the magic keys from working. After the hal/xorg deal, we all know how I hate hard resets. ;-) Thanks much. Dale :-) :-)
[gentoo-user] Re: Questions about the magic Sys Req keys
On 06/13/2011 12:18 PM, Dale wrote: So, my question is this. What kind of lock up could keep the magic keys from working? When the part of the kernel that handles sysrq also locked up :-P
Re: [gentoo-user] Questions about the magic Sys Req keys
Dale rdalek1...@gmail.com [11-06-13 11:24]: Howdy, I just had a hard lock up. I had a random reboot the other day while I was sleeping as well. This was with gentoo-sources 2.6.39. I'm not sure what caused the one the other day but I had several days of uptime. The one I just had was also after a few days of uptime. I was logged into KDE when EVERYTHING froze. The mouse pointer wouldn't move. The clock stopped. The numlock light wouldn't even change when I hit the key for it. So, X was locked up pretty good. I also couldn't switch to a console either. This is the odd part. I tried to use the magic Alt SysReq keys to at least try to get a reasonable shutdown. They didn't work either. So, my question is this. What kind of lock up could keep the magic keys from working? This is on my new amd64 machine. It was totally stable until the kernel upgrade. I think this could be a kernel issue. I booted a older kernel and will test it for a few days but wanted to know what kind of lockups could keep the magic keys from working. After the hal/xorg deal, we all know how I hate hard resets. ;-) Thanks much. Dale :-) :-) Hi Dale, this kind of locks happening - as far as I know - when the kernel itsself hangs or crash (null pointer dereferences and such). As long as the kernel does something (eats CPU cycles in a more or less senseful way) the sysreq magic does work since it is due to its nature located somewhere deep in the kernel just a little bit above the surface of the hardware...:) If the kernel crashes the lights may shine but there is no one at home anymore. Try to modularize as much as possible to seperate the good from the bad and the ugly. May be upgradeing the kernel to 2.6.39.1 may help also. Good luck! Best regards, mcc
Re: [gentoo-user] Threads changing Was: OT: website design
On Sunday 12 June 2011 13:12:51 David W Noon wrote: You should see this reply correctly threaded to your message, provided you are not reading the mailing list through Usenet downstream from the bofh.it server. Indeed. Thanks. -- Rgds Peter
Re: [gentoo-user] Questions about the magic Sys Req keys
I used to get this when using ati-drivers (radeon). This has not happened for a good year though. Sysreq not responsive but you could ssh into machine. Ssh maybe worth a try. If you do not have radeon then the advise is close to meaningless. JDM -Original Message- From: Dale rdalek1...@gmail.com Date: Mon, 13 Jun 2011 04:18:23 To: Gentoo Usergentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org Subject: [gentoo-user] Questions about the magic Sys Req keys Howdy, I just had a hard lock up. I had a random reboot the other day while I was sleeping as well. This was with gentoo-sources 2.6.39. I'm not sure what caused the one the other day but I had several days of uptime. The one I just had was also after a few days of uptime. I was logged into KDE when EVERYTHING froze. The mouse pointer wouldn't move. The clock stopped. The numlock light wouldn't even change when I hit the key for it. So, X was locked up pretty good. I also couldn't switch to a console either. This is the odd part. I tried to use the magic Alt SysReq keys to at least try to get a reasonable shutdown. They didn't work either. So, my question is this. What kind of lock up could keep the magic keys from working? This is on my new amd64 machine. It was totally stable until the kernel upgrade. I think this could be a kernel issue. I booted a older kernel and will test it for a few days but wanted to know what kind of lockups could keep the magic keys from working. After the hal/xorg deal, we all know how I hate hard resets. ;-) Thanks much. Dale :-) :-)
Re: [gentoo-user] Re: /usr/portage/distfiles for amd64 and x86 -- the same?
On Mon, 13 Jun 2011 10:42:43 +0300, Nikos Chantziaras wrote: That means you can use the same distfiles directory for both, and if you come across an ebuild that does weird stuff, portage will bark and re-download the correct distfile. That's true, although I have a common $DISTDIR shared among various architectures and can't ever recall this actually happening. -- Neil Bothwick Linux users do it without paying a Bill signature.asc Description: PGP signature
Re: [gentoo-user] Questions about the magic Sys Req keys
On Monday 13 June 2011 04:18:23 Dale wrote: So, my question is this. What kind of lock up could keep the magic keys from working? This is on my new amd64 machine. everything that kills the interrupt handler. everything that prevents the kernel from acting on interrupts it received everything that locks up the CPU
Re: [gentoo-user] USB Problems
On Monday 13 June 2011 08:42:23 meino.cra...@gmx.de wrote: john j...@arcticwolf.myzen.co.uk [11-06-13 07:28]: On Sun, 12 Jun 2011 16:57:11 -0500 Dale rdalek1...@gmail.com wrote: john wrote: On Sun, 12 Jun 2011 15:50:18 -0500 Dalerdalek1...@gmail.com wrote: Have you looked to see if that mobo has a USB problem and a BIOS update to fix it? Just curious. Dale :-) :-) Thanks Dale, Good thinking. Will have a look. Did upgrade earlier in the year but will have another look. Since the sticks work in other systems, they SHOULD be ok. Then it becomes a hardware issue. If they work in a OS then it makes me wonder if there is something about the BIOS itself. Maybe the BIOS has a issue that only affects it when it is being booted from. Just my weird thinking. Dale :-) :-) Thanks, 2.6.36 works fine 2.6.38-r6/r7 panic Have noticed that using device drivers as modules allows me to boot with memory stick already inserted. This previously would not work. But the problem still occurs when stick is hot plugged. So the issue is half solved At least I can access memory stick. So thanks there. Will try Vanilla sources tonight and report bug to lkml. BIOS is latest standard. SO can't upgrade there Hi John, just an suggestion: If trying vanilla sources it would be an idea, to download both: The vanilla version of the kernel you have encountered problems with and the newest shiny one: The kernel of all kernels - the king of the road of all versions: linux-2.6.39.1 2.6.39.1 still has the problem. and 2.6.38.X is of no use apart from figuring out where the bug was introduced - there are no more stable releases for .38 -- #163933
Re: [gentoo-user] Why does my boot-up sequence look... well... messy?
On Monday 13 June 2011 10:38:49 Pandu Poluan wrote: Hello, I've been scratching my head about this problem. I'm installing Gentoo x86 on XenServer. When I run the Minimal CD using HVM-mode, I got a nice, tidy/tabulated, and colorful output: See: http://i.imgur.com/Trus5.png Please don't use URL shorteners. They don't last long, they go away and the historical record is gone. Plus, not many people here will bother clicking the link. Just copy the output into the mail after snipping out the irrelevant parts. You are also cross-posting. Don't do that either. However, when I've successfully adapted the installation into PV-mode the output becomes messy: * The [ok] is no longer right-justified, but on a new line * The [ok] is no longer colored; just bland white See: http://i.imgur.com/etVww.png Now, what should I do so that the boot sequence again shows a tidy and colorful output? TIA Rgds, -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] Why does my boot-up sequence look... well... messy?
On Mon, Jun 13, 2011 at 18:24, Alan McKinnon alan.mckin...@gmail.com wrote: On Monday 13 June 2011 10:38:49 Pandu Poluan wrote: Hello, I've been scratching my head about this problem. I'm installing Gentoo x86 on XenServer. When I run the Minimal CD using HVM-mode, I got a nice, tidy/tabulated, and colorful output: See: http://i.imgur.com/Trus5.png Please don't use URL shorteners. They don't last long, they go away and the historical record is gone. Plus, not many people here will bother clicking the link. Just copy the output into the mail after snipping out the irrelevant parts. Are attachments okay in this list? You are also cross-posting. Don't do that either. Okay, I apologize for that. Won't do it again. Rgds, -- Pandu E Poluan ~ IT Optimizer ~ Visit my Blog: http://pepoluan.posterous.com
Re: [gentoo-user] RE: Kernel Modules
On Sat, Jun 11, 2011 at 08:35:52AM +0700, Pandu Poluan wrote: -original message- Subject: Re: [gentoo-user] Re: Kernel Modules From: Dale rdalek1...@gmail.com Date: 2011-06-11 03:05 I notice a really long list of things when I do this: eselect bashcomp list Is there a way to just enable them all? Is there some that should NOT be enabled, maybe for good reason? Personally, I do some cherry-picking and enable a bashcomp when I found out I need it. I have 2 concerns (which may or may not be true): 1. It will make bash (or the whole system) slower well, only when you are hitting tab ... ;) I know it can be annoying to have to wait a long time when you accidentally hit tab on a complex command..., but when you know how to do the explicit filename only completion... 2. For some commands I *might* want the standard completion meta-/ (or ESC then /) for the complete-filename, there are also others for some other things (variable, username...) man bash /Completing yoyo
Re: [gentoo-user] Why does my boot-up sequence look... well... messy?
On Sun, Jun 12, 2011 at 10:38 PM, Pandu Poluan pa...@poluan.info wrote: Hello, I've been scratching my head about this problem. I'm installing Gentoo x86 on XenServer. When I run the Minimal CD using HVM-mode, I got a nice, tidy/tabulated, and colorful output: See: http://i.imgur.com/Trus5.png However, when I've successfully adapted the installation into PV-mode the output becomes messy: * The [ok] is no longer right-justified, but on a new line * The [ok] is no longer colored; just bland white See: http://i.imgur.com/etVww.png Now, what should I do so that the boot sequence again shows a tidy and colorful output? it seems like this is the relevant bug: https://bugs.gentoo.org/show_bug.cgi?id=243184
Re: [gentoo-user] Why does my boot-up sequence look... well... messy?
On Mon, Jun 13, 2011 at 21:15, Paul Hartman paul.hartman+gen...@gmail.com wrote: On Sun, Jun 12, 2011 at 10:38 PM, Pandu Poluan pa...@poluan.info wrote: Hello, I've been scratching my head about this problem. I'm installing Gentoo x86 on XenServer. When I run the Minimal CD using HVM-mode, I got a nice, tidy/tabulated, and colorful output: See: http://i.imgur.com/Trus5.png However, when I've successfully adapted the installation into PV-mode the output becomes messy: * The [ok] is no longer right-justified, but on a new line * The [ok] is no longer colored; just bland white See: http://i.imgur.com/etVww.png Now, what should I do so that the boot sequence again shows a tidy and colorful output? it seems like this is the relevant bug: https://bugs.gentoo.org/show_bug.cgi?id=243184 Thanks! Just commented on that bug. Rgds, -- Pandu E Poluan ~ IT Optimizer ~ Visit my Blog: http://pepoluan.posterous.com
Re: [gentoo-user] Questions about the magic Sys Req keys
Volker Armin Hemmann wrote: On Monday 13 June 2011 04:18:23 Dale wrote: So, my question is this. What kind of lock up could keep the magic keys from working? This is on my new amd64 machine. everything that kills the interrupt handler. everything that prevents the kernel from acting on interrupts it received everything that locks up the CPU Thanks for all the replies. It appears I am on the right track. I most likely have a bad kernel. It's been a while since I had one of those. I guess one has to get through every once in a while. Oh, I have a nvidia card. Thanks Dale :-) :-)
Re: [gentoo-user] Argh: No KMail after KDEPIM upgrade
On Monday 13 June 2011 21:01:58 Alex Schuster wrote: Hi there! So I did the big KDE 4.6.3 - 4.6.4 upgrade. Stupid me, I did not want to do this yet, but I missed the -a switch to a @system update, and that pulled in kdelibs-4.6.4. After this, konqueror no longer worked, so I did the full upgrade. Along came the change to KDEPIM 4.6. On next login, Akonadi stuff was migrated, and some errors happened. The notice boxes closed automatically before I could make screenshots. Something with the migration of 'Standard-Kalender' to native backend failed, and some more stuff I do not remember. Did not look too bad though. Anyway, KMail has a problem now. I get this error: KMail encountered a fatal error and will terminate now. The error was: Failed to fetch the resource collection. look up the akonadi error log BTW, double-clicking a file in dolphin does no longer open it, but asks for the application to open it with. No known applications are shown. Hmm, I remember having this before, and there was some easy solution like running kbuildsycoca4, but this did not help here. /etc/xdg/menus/applications.menu is missing. Just create a symlink to kde-4-applications.menu -- #163933
Re: [gentoo-user] Argh: No KMail after KDEPIM upgrade
On Monday 13 Jun 2011 20:01:58 Alex Schuster wrote: Anyway, KMail has a problem now. I get this error: KMail encountered a fatal error and will terminate now. The error was: Failed to fetch the resource collection. It seems to work if I do not close this notice box, I can browse mails in my IMAP folders. I can compose new mails, but when I save as draft, kmail crashes. Did not try other things yet. Thanks for the heads up. You may want to try pointing your calendar, contacts, notes, alarm, in your SystemSettings/Personal Information to the files/directories that were previously pointing to. That's what I had to do here after the migration from kde3.5 to kde4 (but I'm running sqlite3 instead of mysql on my desktop). A couple of updates borked it and had to this again. YMMV - please report back if this works. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] USB Problems
On Mon, 13 Jun 2011 00:44:49 -0500 Dale rdalek1...@gmail.com wrote: john wrote: On Sun, 12 Jun 2011 16:57:11 -0500 Dalerdalek1...@gmail.com wrote: john wrote: On Sun, 12 Jun 2011 15:50:18 -0500 Dalerdalek1...@gmail.com wrote: Have you looked to see if that mobo has a USB problem and a BIOS update to fix it? Just curious. Dale :-) :-) Thanks Dale, Good thinking. Will have a look. Did upgrade earlier in the year but will have another look. Since the sticks work in other systems, they SHOULD be ok. Then it becomes a hardware issue. If they work in a OS then it makes me wonder if there is something about the BIOS itself. Maybe the BIOS has a issue that only affects it when it is being booted from. Just my weird thinking. Dale :-) :-) Thanks, 2.6.36 works fine 2.6.38-r6/r7 panic Have noticed that using device drivers as modules allows me to boot with memory stick already inserted. This previously would not work. But the problem still occurs when stick is hot plugged. So the issue is half solved At least I can access memory stick. So thanks there. Will try Vanilla sources tonight and report bug to lkml. BIOS is latest standard. SO can't upgrade there We know how hard it is to fix a flakey problem. It could be anything or it could be the half asleep geek in the chair. That last one gets me a LOT. ;-) Dale :-) :-) Ok the half 10th of geek has finally found the issue (I think) Tried vanilla sources 2.6.38-r7 still the problem occurs Tried vanilla sources 2.6.39 - had no keyboard support at all. Got to loogn prompt but could not write and no sysreq. Went to work and borrowed an old keyboard with old style attchement (can't remember what these are called but they have purple ends - serial ps/2??) No issues with any version of any kernels plugging in usb sticks. Include gentoo and vanilla. I have a roccat keyboard (which I guess is fairly exotic). This is somehow causing the problem. How I'm not sure. Using a standard keybaord and no problem. So if anyone comes across this problem I recommend try a nother keyboard. Will try studying all options in kernel to see if I can cure this. There are roccat options but these are for macros and don't help. But there maybe more other subtle ones available. Regards Thanks for your help -- -- -- John D Maunder j...@arcticwolf.myzen.co.uk
[gentoo-user] KDE4 + python3.1 == no system-config-printer-kde ?
Hi everybody, Is it me missing out on something or does KDE4 (namely PyKDE4) is borked when default python is set to 3.1? # eselect python list Available Python interpreters: [1] python2.7 [2] python3.1 * # eselect python list --python3 Available Python 3 interpreters: [1] python3.1 * # eselect python list --python2 Available Python 2 interpreters: [1] python2.7 * # grep python /etc/make.conf pygrub python python3 pulseaudio qalculate qt3 qt3support with all of the above PyKDE4 compiles, however kde-base/system-config-printer-kde-4.6.3 barfs: Traceback (most recent call last): File /usr/share/apps/cmake/modules/FindPyKDE4.py, line 8, in module import PyKDE4.pykdeconfig with a bit of look-around it seems like pykde4 has: RESTRICT_PYTHON_ABIS=2.4 which boils down to (what seems like) pykde4 is built only for 3.1 # epm -ql pykde4 | grep pykdeconfig /usr/lib64/python3.1/site-packages/PyKDE4/pykdeconfig.py should I be performing some other waving in the air to make this whole thing fly? It seems like a bug to me, but I'd rather confirm I'm not missing something before reporting it.
