Loading ...
Sorry, an error occurred while loading the content.

Re: The future of the NSLU2-Linux project - your input is required!

Expand Messages
  • wouter@grep.be
    In article , ... Hi, Since I m one of these influential (ahem) Debian Developers involved with those
    Message 1 of 37 , Jan 1, 2006
    • 0 Attachment
      In article <1135924601.25782.250765015@...>,
      "Rod Whitby" <list.nslu2-linux@...> writes:
      > Around that same time, we convinced a couple of influential Debian
      > Developers to help us set up some machines to build the Debian sid
      > (unstable) set of packages. The project donated two slugs for this
      > purpose (Bob and Wendy) and those slugs have currently built just over
      > 10% of Debian unstable. It is unknown whether two slugs are enough to
      > keep up with the continual changes in Debian unstable in the long run.
      > Those packages can be found at http://armeb.debian.net/debian-armeb/ and
      > can be used with OpenDebianSlug.


      Since I'm one of these 'influential' (ahem) Debian Developers involved
      with those build machines (namely, the person handling the logs coming
      from bob and wendy, the machines in question), I think it'd be nice to
      react to this, to provide the most up-to-date information.

      First, bob and wendy are now (after an initial shaky period, especially
      regarding wendy's stability) running great, compiling packages in an
      automated manner, 24/7; and in addition to that, Velin Pavlov offered me
      access to his box with the intent of setting up a buildd on that
      machine. As Rod said, a bit over 10% of the packages in Debian unstable
      are built (713 out of 6126 packages at the time of writing). Interested
      parties can get more information and nice little statistics on

      Since I am handling the buildd logs, and since I am a Debian Developer,
      these packages could eventually be uploaded to the Debian archive,
      turning the built packages into a proper Debian port without having them
      to be rebuilt, should you want to do so.

      That being said, there is one little issue. I do think that 3 machines
      should be enough to get ~90% or more of the archive built; but to
      effectively do so, the machines should have more RAM. To demonstrate
      this, please have a look at
      <http://samba.grep.be/~wouter/wendy-trashing.txt>, which shows the
      output from a vmstat run while wendy was compiling a C++ program (the
      boost source package, to be exact). As you can clearly see, wendy needs
      to use a lot of swap, which horribly slows down the builds: both bob and
      wendy are capable of building about 10-20 C packages a day, but usually
      need multiple days for one C++ package; this is because the C++ compiler
      requires a lot more memory than the C compiler.

      If this project wants to pursue the goal of ending up as an official
      Debian architecture, then this will need to be remedied somehow.

      .../ -/ ---/ .--./ / .--/ .-/ .../ -/ ../ -./ --./ / -.--/ ---/ ..-/ .-./ / -/
      ../ --/ ./ / .--/ ../ -/ ..../ / -../ ./ -.-./ ---/ -../ ../ -./ --./ / --/
      -.--/ / .../ ../ --./ -./ .-/ -/ ..-/ .-./ ./ .-.-.-/ / --/ ---/ .-./ .../ ./ /
      ../ .../ / ---/ ..-/ -/ -../ .-/ -/ ./ -../ / -/ ./ -.-./ ..../ -./ ---/ .-../
      ---/ --./ -.--/ / .-/ -./ -.--/ .--/ .-/ -.--/ .-.-.-/ / ...-.-/
    • Adrian Day
      John, ... It s definitely not a kernel crash. It just kills the current ssh session. I m at work now but will attempt to delve a little deeper into this when I
      Message 37 of 37 , Jan 31, 2006
      • 0 Attachment

        On 1/31/06, John Bowler <jbowler@...> wrote:
        > From: Adrian Day
        > >Running 'ls -lR /' will lock a ssh session.
        > Well, can you still ping the slug? (I.e. does it still
        > respond to ping?)
        > I've never managed to lock a system (i.e. a hard kernel lock
        > or a crash) by doing that, or the pretty much identical
        > command "find /", and I do it quite a lot (it's a quick and
        > easy way of getting CPU load).
        > What gets locked exactly? Assuming the ping doesn't respond,
        > does the power button work? What if you run a shell script to
        > toggle the disk 1 led on/off:
        > while true; do echo -n 100 >/sys/class/leds/disk-1/brightness; sleep 1; echo -n 0 >/sys/class/leds/disk-1/brightness; sleep 1; done
        > Does that keep going? (Running in another ssh session). What
        > happens when the LED is being made to flash from the kernel:
        > echo timer >/sys/class/leds/disk-1/trigger
        > echo 1000 >/sys/class/leds/disk-1/frequency
        > Does it lock up then? (That would indicate a kernel crash).

        It's definitely not a kernel crash. It just kills the current ssh
        session. I'm at work now but will attempt to delve a little deeper
        into this when I get home. I'm not alone - Jean Fabrice has
        experienced similar problems - I'd posted something about this a week
        or so back.

        Like I said, I'll spend some time looking into this in more detail.
        It's the least I can do compared to the considerable effort you and
        others have put into the slug.

      Your message has been successfully submitted and would be delivered to recipients shortly.