Re: encrypted root fs on a slug and crypto-modules
I don't know how much load you're going to put on your proposed Kerberos KDC, but the extra CPU load placed on it by encrypting the filesystem may make it unresponsive, given the Slug's not-very-fast CPU. Let us know how it turns out. Rick On Feb 24, 2008, at 1:42 AM, Anders Lennartsson wrote: After using my slug for some time to serve files with Debian installed I thought I'd try using it for a kerberos kdc (tested and works ok) on an encrypted root file system (current experiment). Not much load and file access so this might be ok. But for encryption during a fresh install on the slug, it seems the installer fails to load some modules even though I have inserted an extra media with a swap partition and initiated this partition for swap before attempting to partition and encrypting the fs. In particular three modules are not found Feb 23 19:03:55 anna[9635]: DEBUG: resolver (ext2-modules): package doesn't exist (ignored) Feb 23 19:03:55 anna[9635]: DEBUG: resolver (crypto-modules): package doesn't exist (ignored) Feb 23 19:03:55 anna[9635]: DEBUG: resolver (libnewt0.52): package doesn't exist (ignored) and a short investigation gives that it seems natural because they are not built by the source package: http://packages.debian.org/source/etch/linux-kernel-di-arm-2.6 But is this the only problem or is there some other flaw in my plan on using an extra USB-memory for swap during the install? While the slug is not really up to the task of acting as an interactive workstation I have found that with swap it is surprisingly capable so I thought that it perhaps could do the install given enough swap. Thank you Anders -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#460419: omniorb4: FTBFS on arm: segmentation fault
Hello, I am now convinced this is a g++ bug. I could reproduce the FTBFS on qemu. Trying to compile omniorb4 with g++-4.1.3 20080114 (Debian 4.1.2-19) succeeds. I will try to write a reduced test case before submitting the bug report on g++-4.2. I need to check wether g++-4.3 is affected as well. Anyway, I'll prepare an upload using g++-4.1 on arm tomorrow to fix this FTBFS. Regards, Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: armel boxes for Debian
On Wed, Feb 20, 2008 at 07:44:30PM -0500, Joey Hess wrote: > Moritz Muehlenhoff wrote: > > We could just declare arm a second-class architecture for security updates, > > i.e. DSAs being released once all archs are available except arm and arm > > updates being released once available. For small to medium packages most > > updates would still be released in sync, since we're not available to > > release updates 24/7. > > Yeah, that's what I was suggesting. Ok, if that's an agreeable consensus to arm porters, we should add it to the Lenny release notes. > > > I'm also unsure based on Moritz's mail exactly what kind of speed > > > they're looking for from an arm security buildd. He mentioned something > > > on the order of 14 hours to build xulrunner -- would an arm box that > > > builds it in 9 hours[1] be a worthwhile improvement, or will that still > > > leave the security team waiting until the next day for arm to catch up? > > > > 9 instead of 14 would still help. I also think a second security buildd > > would help: It wouldn't address the spikes of giga packages like xulrunner, > > but it would help for cases, where several updates are building in > > parallel. > > The benefits I see from such a speedup are that it would let the arm > advisory arrive 5 hours faster (but still 7 hours after everything > else), and that it would increase the number of packages that wouldn't > need a delayed advisory for arm. Accurate? Yes, that's correct. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
